你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 上的 SaaS 工作负荷的事件管理
软件即服务（SaaS）解决方案的独立软件供应商（ISV）必须为其客户运营解决方案。 这样做需要组织设置和文化来顺利处理意外的生产情况。 作为架构师，必须相应地设计管理流程和工具。
本文指导你调整组织的文化、流程和工具，以支持生产 SaaS 解决方案的事件管理。
了解作为服务提供商的责任
运营 SaaS 解决方案意味着你是客户的 24x7 IT 和运营部门。 你需要准备好正确的人员配备、文化、流程和工具。
设计注意事项
负责 24x7x365 支持。 运营 SaaS 解决方案要求组织始终做好事件响应的准备。 此准备包括始终让团队成员可用，因为事件发生在工作时间之外。
实时站点支持 涉及实时监视和响应影响系统可用性、安全、性能或部署的事件。 你或你的客户可以检测这些事件。 若要处理此类事件，你需要特定的技能，包括分析和解决压力下的问题的能力。
实时站点支持可能非常紧张，并且支持团队成员非常重要。 如果团队不熟悉此责任，请仔细规划过渡。 解决有关事件期间待命职责、补偿和管理不可用的问题。
风险：技能管理和期望管理。 并非所有工程师都适合 24x7x365 支持角色。 转换预先存在的团队以支持 SaaS 解决方案时，请确保设置适当的期望，并提供教育机会。建立现场文化。 请考虑如何管理支持案例和事件，以及升级的发生方式。 目标是确保团队成员了解自己的职责，并具备处理事件所需的技能和工具。
初创公司和小型组织可能为实时站点问题制定轻型计划。 工程师最初可以通过响应客户支持案例来充当一线支持。 成熟的组织或具有企业客户的 SaaS 提供商需要更结构化的支持和专用团队。
权衡：卓越运营和成本。 管理实时站点事件可能会因新功能或 bug 修复而偏离开发时间。 如果开发速度是个问题，请考虑雇用专用实时站点资源。
设计建议
| 建议 | 好处 |
|---|---|
| 介绍一个用于处理支持案例的一线团队。 对于复杂情况，此团队收集工程团队对其调查所需的信息。 供应商可以充当一线支持团队，并执行初始问题分析并解决简单问题。 |
避免过度负担工程团队承担事件处理责任，并处理其常规职责的中断。 |
| 投资一个待命函数，让工程师处理复杂案例、调查和采取行动。 如果可能，请轮换团队成员之间的待命责任，每个工程师一次接听几天。 |
使用明确定义的责任和升级路径，可以快速识别和解决问题，而不会中断工程工作流。 |
| 采购专用于事件管理的工具。 确保所有响应者都可以有效地访问和了解如何使用这些工具。 选择可以监视系统状态、跟踪客户报告的问题、识别问题、升级到待命工程师、管理无响应工程师以及启用生产更改的工具。 |
拥有适当的工具可帮助你的待命团队快速识别和解决事件，同时保持安全性和运营控制。 |
| 改进监视、部署、更新和其他常规管理操作。 | 通过投资运营成熟度，可以降低现场问题的可能性。 如果确实出现问题，则正确定义的操作可缩短解决时间。 |
定义响应计划
确认事件是不可避免的，并通过定义事件响应计划来为事件做好准备。 这种主动方法可防止你在第一次事件期间制定响应策略。
提前规划重大事件，这通常会影响客户使用服务的能力。 在发生事件时，此准备有助于最大程度地减少压力和复杂性。
设计注意事项
定义升级路径。 确保团队了解支持任务的升级过程。 在许多 SaaS 解决方案中，客户联系一个一线支持团队，然后与工程团队通信。 确保客户知道谁与谁进行交互，以及他们不应该绕过这些流程的原因。 此外，请确保工程团队知道何时以及如何寻求供应商的帮助，包括Microsoft的支持团队。
定义严重性级别。 不同的事件对你和你的客户的重要性不同。 处理重大生产中断的方式与解决次要 bug 的方式不同。 根据客户影响定义严重性级别，并为每个级别设置适当的期望和时间线。
需要会审的文档信息。 使文档保持最新状态对于有效的事件响应至关重要。 本文档包括系统的体系结构布局、组件级详细信息、所有者和关键联系人。 不准确或过时的信息可能导致事件响应团队浪费宝贵的时间，找出系统操作、责任以及事件的潜在影响。
规划与客户的有效沟通。 提供状态更新是事件管理的关键。 状态更新有助于客户了解事件的性质，并减少遇到类似问题的客户的支持案例量。
设计建议
| 建议 | 好处 |
|---|---|
| 向客户提供明确的事件报告过程，例如向你的一线支持团队提出支持案例。 | 确保发现和响应事件的一致性，从而缩短解决时间并防止信息丢失或被忽视。 |
| 记录体系结构布局、组件级详细信息、隐私或安全分类、所有者和关键联系人。 | 会审团队提供随时可用的信息，可以专注于调查和评估影响。 |
| 确保事件响应团队可以访问必要的资产和系统，例如日志。 它们还需要能够通过安全受控的过程进行生产更改。 | 通过确保团队不会浪费时间来更快地还原操作。 |
| 使用商业状态页，而不是生成自己的状态页。 | 使用商业状态页节省时间。 另一个组织托管的状态页在系统中断期间仍可供客户访问。 |
有条不紊地管理事件
遵守定义的计划对于避免在响应时间内即兴进行至关重要。 此方法有助于最大程度地减少管理这些情况的压力和复杂性。
设计注意事项
分配事件严重性。 使用事件响应计划确定事件严重性。 客户在事件期间经常感到沮丧。 请务必了解他们看到的影响，以便你可以确定优先级。 明确传达事件的严重性，以便客户有现实的期望。
保持冷静，清楚地思考。 事件可能很紧张和模棱两可，多个利益干系人要求注意。 对于谁在事件中带头，有一个明确的流程。 会审事件尽可能好，同时确认可能需要使用不完善的信息进行操作。 尽量继续控制局势。
组织领导可以通过保护正在积极调查或缓解事件的团队成员提供帮助。
与客户沟通状态。 更新状态页以发布足够信息。 及时沟通并提供所需的信息，例如估计的解决时间。 为客户提供频繁更新以保持信任。
设计建议
| 建议 | 好处 |
|---|---|
| 在事件期间，优先于发现恢复。 发生事件时，请快速确定还原操作的优先级，以最大程度地减少对客户的中断。 |
即使你还不了解导致问题的原因，也可以通过围绕受影响的组件进行路由或回滚更新来恢复。 |
| 在中断期间提供及时、清晰和频繁的更新。 | 可以灌输客户信心，减轻一线支持团队的负担。 |
| 在活动事件期间指定通信管理器。 此经理可能是一个人，或者你可以在事件之间轮换团队成员的责任。 | 通过为工程团队提供一个语音，你可以集中对话，减少对其他团队成员的干扰。 还可以防止在混乱的事件中向客户或利益干系人发送冲突信息。 |
| 确保为供应商（如 Microsoft）制定任务关键型支持计划。 | 如果发生中断，则需要与平台供应商（例如Microsoft）进行响应式通信，以帮助确定问题所在位置并缩短中断持续时间。 |
进行事后评审
从事件中恢复后，查看和分析从事件中学到的内容。 实施修正操作，包括技术更改、流程调整或更多培训。
设计注意事项
从事件中学习。 中断提供了宝贵的学习机会。 在事件后进行彻底审查，以确定教训并实施改进。 重大事件通常有多个原因。 评估解决方案的其他层（如操作流程）在升级之前是否可能会阻止或检测问题。 此外，请在解决方案中的其他位置查找可能也面临相同问题风险的类似模式。
与客户沟通。 许多 ISV 提供事件后通信，尤其是希望进行高质量更新的企业客户。 透明，为客户提供足够的信息来了解问题和缓解步骤。 但是，若要维护安全性和完整性，请避免共享有关解决方案体系结构或组件的过多内部详细信息。
设计建议
| 建议 | 好处 |
|---|---|
| 创建执行内部事件后评审的过程。 重点确定导致问题的原因。 考虑技术原因、流程如何促成中断，以及响应事件的方式。 |
内部事件后评审可帮助你从生产中断中吸取教训，并最大限度地减少再次发生类似问题的风险。 |
| 制定结构化计划以解决任何需要修正的项目。 包括明确的问责和时间线。 | 明确的问责有助于确保每个角色满足其功能期望，提高清晰度，并允许在所需级别进行透明报告。 |
| 发布面向客户的事后评审。 为客户提供足够的详细信息来了解问题和缓解步骤，而无需透露不必要的内部详细信息或系统体系结构。 事后通信应始终由人类编写和发布。 技术和非技术利益干系人应审查通信的准确性和清晰度。 |
此方法有助于保持客户的信心，并向他们保证你从事件中学到并正在解决已识别的问题。 |
下一步
查看设计区域后，转到评估工具以评估设计。