事件响应的基础
如今，虽然组织受益于云的可访问性、高效和便利性，但他们在进行涉及将他们的业务迁移到云服务的数字化转型时会面临许多挑战。
你的组织可能面临的一些常见的挑战包括：
- 服务中断次数的增加
- 无有效的事件跟踪和响应方法（所有方法都是临时且保守的）
- 无法接受的解决时间
- 解决时间没有得到降低或者正在不断增长
- 难以找到信息和状态
- 重复出现相同的问题和错误
若要解决这些挑战，需要在坚实的基础上构建一个定义完善的事件响应计划。
基础和支柱
打造基础的目的是在此基础上支撑和维持结构。 在此学习路径的单独简介模块中，我们讨论了可靠性工作构建在基础的监视水平上并且事件响应在层次结构中正位于此基础的上方。
事件响应也有自身的基础。 有三大支柱来支持良好的事件响应计划：
- 名册
- 角色
- 轮换
在本单元中，你将了解这些支柱的定义以及它们在设计事件响应策略中所扮演的角色，此策略会使你朝着你的可靠性目标迈进一步。
名册
拥有一个良好的计划是必不可少的，但如果没有人来执行它，那也是无用的。 因此，最佳的起点是确定应对问题做出响应的人员以及如何在需要他们做出响应时通知他们。
解决这一难题的最佳方式是设计一个名册。 名册是被分配到待命团队的人员列表。 此团队应由多名工程师组成。 这些团队成员应具有处理会在环境以及事件响应训练中发生的问题类型的知识和技能。
不过，只有名字列表还不够。 你需要构建一个框架，确定在任何给定的时间点待命的人员以及每个人要执行的工作。 这就是角色发挥作用的地方。
角色
角色为混乱或至多临时的响应带来了秩序。 为此，它定义特定情况下假设每个人要进行的特定工作以及每个人在“命令链”中所处的位置。角色可能因组织或甚至是事件类型而异，但以下角色通常应在有组织的事件响应团队中占有一席之地：
- 主要响应者：这是“重点人物”，通常是第一个到场的人，即事件发生时第一个被召集的待命工程师。
- 次要响应者：这是主要响应者没空时充当备用人员，或者在需要另外一个人一同处理时可以参与的人。
- 行业专家 (SME)：这些深入了解你的特定方面操作的人员。 如果主要和次要响应者需要将问题上报给具有更多专业知识的人员，则可以上报给他们。 他们并非随时都处于待命状态，但在需要他们的专业知识时，则可以召集他们。 你应该保存一份涉及多种行业的 SME 列表（例如数据库、前端、网络基础设施、Web 应用和网络安全等）。
- 事件指挥者：对于会影响许多不同的组件以及/或者需要许多不同的团队和系统展开协作的大型事件或服务中断，这是一个非常重要的角色。 事件指挥者将负责协调与响应和修正活动相关的大量对话和工作。 事件指挥者需要关注“大局”，他们需要密切留意发生的情况以及谁正在执行什么工作。 对于在不干预或不撤消每名工程师其他工作的情况下确保他们保持专注并且努力进行他们各自的修正工作而言，事件指挥者是一个绝佳的角色。
- 抄写员：抄写员的角色是尽可能详细地记录事件相关的对话。 团队通常会使用电话网桥、电话会议或视频聊天来让所有人了解发生的情况，这无疑有助于创造对话的空间。 但是，我们很难详细掌握和了解工程师们谈论的内容以及执行的工作，除非这些内容被转录下来。 因此，抄写员是可以帮助我们尽可能详细记录相关内容以供日后回顾的人。 抄写员会尽可能捕获所有数据 - 不仅包括团队成员正在进行的工作，还包括他们说的话，甚至是他们的感受或体验。
- 交流协调者：可以将这名人员视为事件的“公共关系经理”。 交流协调者与事件指挥者协同工作，将事件的相关信息分享给没有参与主动处理事件以及从事件中恢复的那些人。 可能包括客户、销售和营销团队、客户支持，以及组织内外部需要知道所发生的的情况以及响应和修正进展状态的其他利益干系人。
轮换
现在，你有了响应团队人员的名册并且为他们分配了适当的角色。 接下来，也就是最后一步是创建轮换，这是为每个待命的人员分配班次的安排。
有多种不同的方法来划分班次。 班次安排可能会是一个复杂的策略过程。 不应随机分配班次；应花点心思进行安排，使安排的班次对于团队成员而言尽可能有效，并且尽可能使他们感到满意。
用于安排班次的一些方法包括：
- 全天候：这是团队成员在连续几天内待命的轮换。 这是分配班次覆盖的一种简单方法，但必须要注意限制持续时间。 超过三到四天的班次轮换对于工程人员的整体健康状况会造成不利的影响 - 从而导致整个系统的可靠性降低。
- 遵循日间班次：这是一种排班模型，使工程师仅在他们正常的工作时间期间计划他们的待命班次，随后在他们的工作日结束时将他们的待命责任移交到位于不同时区的同事的手上。
这些只是可能分配班次的一些示例方法。 重点是以最适合响应团队中各名成员的方式划分班次。 自定义班次的方法有很多，特别是对于工程师需要更多弹性的周末。 当出现了与工作无关的工作时，工程师应该能够轻松将待命的角色移交给其他人。