通过自动处理日常安全事件，您的组织将能够更快地做出反应，减少人为错误，并显著提高生产力。
Greg Chase 翻译自 Greg Chase 的 5 种自动化事件补救方法，是 PagerDuty Automation 和 Rundeck 的产品营销总监。 他在软件公司的营销和工程部门工作了太多年，推广和构建自动化平台、开发人员工具和数据工程框架。 在加入Pagerduty之前，Greg曾在以下领域工作： 对于当今的数字化组织来说，软件问题往往会成为业务问题。 随着公司收入和客户体验的日益变化**，事故和中断以及相关的停机时间可能会对收入、客户满意度和员工生产力产生更大的影响。
事实上，许多 IT 中断在诊断和补救方面都是相当可控的，即使您只是暂时解决问题。 噪声服务的报警诊断通常从相同的步骤开始。 “立即修复”的补救措施通常是相同的，涉及简单的服务重启和容错切换。
这些重复操作非常适合应用自动化以加快响应速度，避免对主题专家 （SME） 造成干扰，减少错误并提高效率。
IT 运营人员必须尽快解决关键停机问题，这就是他们跟踪平均恢复时间 （MTTR） 和错误预算等指标的原因。 在这些情况下，无论谁的工作中断，服务恢复都具有最高优先级。
一旦满足服务级别目标 （SLO），提高 IT 支持效率就成为一个问题。 所有不太严重的事件、IT 事件和监视警报都可能增加支持成本并中断高级工程师的主要工作，从而减慢新功能的交付速度。 不幸的是，许多组织的情况远非理想。 研究表明，五分之一的组织会因 IT 事故和停机导致的计划外工作中断而遭受“高影响”（相当于 25% 或更多的生产力损失）。 对于47%的组织来说，影响是“重大的”，这意味着10%到25%的生产力损失。 这种消耗的很大一部分可以追溯到操作员，他们没有知识或访问权限来自己解决问题，需要将问题上报给高级工程师来解决。 造成这种情况的原因是，运营中心的许多急救人员缺乏对企业运行的各种系统的了解，并且很可能缺乏诊断和解决问题的技能，除非有明确的操作指南，例如运行手册。 他们也可能没有测试或修改生产环境所需的访问权限，无论是由于技能水平低，还是由于合规性要求，公司需要保持环境锁定。
在处理 IT 事件时，响应者经常被大量的警报和信号淹没，因此很难筛选出真正的问题并采取有效行动。 这导致他们不得不将问题上报给高级工程师，该工程师甚至会参与基本的分类任务，因为他们可以访问受影响的系统。 这些不必要的升级会占用工程师的大量时间，并分散他们开发项目的注意力。 此外，事件中可能涉及的人太多，他们会执行一些基本的检查，例如运行测试以证明他们的**不是导致问题的原因。 通过自动执行事件中重复性最强的步骤，您可以减少将问题上报给专家的需要，为初级响应者提供更多自主权，并最终实现完全自动化，而无需任何人工干预。 考虑一个典型的事件响应工作流：
采用 AIOps 来检测问题并从警报中标记事件是提高事件响应速度和效率的主要方法之一。 借助 AIOps，您可以避免响应者必须手动查看大量信息，并能够筛选出大量真正需要解决的重复噪音和误报。 通过让 AIOps 负责触发事件工作流，您可以自动执行从问题发现到解决的整个过程，包括问题解决、关闭，甚至最终修复。 上图显示了通过自动化改善事件响应的大量机会。 但是你应该从什么开始呢？平衡对自动化的信心、事件的价值或成本以及任务发生的频率。 对于具有可验证的自动诊断和修正步骤的常见事件，使用 AIOps 触发自动化是一个不错的选择。 然后，按照类似的流程确定事件响应策略的优先级。
对于严重故障，可自动执行诊断和修复步骤，以加快解决问题的速度。 然后，通过自动执行跨多个事件发生的后端诊断和修正操作，专注于提高效率。 对于低风险操作（例如只读诊断拉取），可以使用 AIOps 安全地自动执行和触发，即使它们被调用，也可以为下游人员提供所需的信息。
您可以自动执行常见的修正操作，并将其提供给响应者。 这种自动化可以利用机密管理工具（如保管库）在生产中启用特权操作，而无需共享凭据，从而更安全地委派给响应者。 当事件的可能原因很明显，并且修正自动化已经过验证时，你可以让 AIOPS 触发修正以进行自我修复，而无需调用任何响应者。
首先，您选择自动化会带来机会成本。 因此，找到对财务影响最大的任务是您成功的道路。 以下是五项关键设计原则，可帮助组织自动执行事件修复、显著减轻员工负担、释放创新人才并优化事件解决。 从简单开始：不要为每个事件创建过于复杂的自定义自动化。 构建基本任务和操作，并将它们作为更复杂工作流的组件进行重用。 从风险较低的操作开始，例如那些不会更改生产环境或可以通过较低访问权限执行的操作。 保持较短的执行时间。 避免跨越太多技术领域。
建立保护机制：每当自动化任务启动或停止时，通过电子邮件、事件响应仪表板、Slack 消息或其他方法发送通知。 避免循环，至少在组件自动化中是这样。 也许您的事件管理工作流会运行几次重试，但您希望这些规则可见，而不是隐藏在其他自动化中。 条件语句（如 if then else 语句）也是如此。 将这些留给事件响应工作流中可见的业务规则。 始终报告执行状态：成功、失败、错误。
提供有意义的结果：自动化必须对最终用户有意义，以便他们能够从输出中获得最大和直接的价值。 考虑您的用户是谁以及他们拥有哪些技能和背景。 请记住，许多一线响应者可能不具备高级专家所拥有的深入技术系统知识。 例如，您可能需要简化诊断信息，以改进和加快支持单一路由的决策。 这是关于获取原始数据并将其转换为最终用户实际需要的信息。
驱动器一致性：在上一点的基础上，确保广泛的人员能够支持更多操作的关键是提供一致且简化的最终用户体验。 这可能包括标准化样式、输入参数和目录显示。 您的组织可以在 Azure 环境中使用 Ansible，或者在 AWS 中使用 CloudFormation 和 Terraform，甚至可以结合使用 Bash 和 Python 脚本。 关键是要使最终用户体验在所有环境或工具中保持一致，这样个人就不需要专门研究各种工具。 您的响应者可以支持多少个应用程序？
记录流程：始终在呼叫点记录自动化。 有些流程可能不经常运行，因此您不应期望响应者记住几个月前的培训。 同样，一些组织的一线响应人员流动率很高，因此文档有助于填补培训可能不完整的内容。 这种文档应该以标准化的方式指导用户，以增强理解和可维护性。
自动化不是事件响应的灵丹妙药。 这个想法是让机器在可能的情况下承担手动和重复性任务。 当一个事件很复杂或很新时，就需要人工参与。 即使在需要专家干预的情况下，自动化流程也可以通过主动收集所需的详细诊断数据来加快工作速度，从而确定根本原因和纠正补救措施。 在数字优先的世界中，自动化应该是每个 IT 部门的首要任务。