14、云环境中的性能测量、事件响应、无责复盘与混沌工程实践

云环境中的性能测量、事件响应、无责复盘与混沌工程实践

1. 性能测量

在进行系统管理和运维时，需要借助一些指标来跟踪系统的成熟度和运行状态。常见的指标包括：
- 平均故障间隔时间（MTTF） ：系统从开始运行到首次发生故障的平均时间。
- 平均修复时间（MTTR） ：系统发生故障后，恢复到正常运行状态所需的平均时间。“修复时间”也被称为“补救时间”“恢复时间”或“恢复时长”，都指将服务恢复到服务级别目标所定义的运行状态所需的时间。
- 平均无故障时间（MTBF） ：系统两次相邻故障之间的平均时间。

此外，还有一些指标可视为MTTR的不同阶段，例如“平均检测时间（MTTD）”“平均通知时间”和“平均确认时间”，因为MTTR涵盖了从事件发生到完全缓解的所有阶段。

为了让组织团队朝着公司愿景协同工作，可以基于跟踪数据定义一组目标与关键成果（OKRs）。OKRs不应仅关注服务，还应考虑客户满意度和员工士气。

使用微软工具跟踪这些指标时，具体方法取决于所涉及的工具。例如，若使用Azure Monitor警报和GitHub Issues进行事件跟踪，可以使用Power BI来收集和测量相关指标：
- 平均修复时间 ：测量从Azure Monitor警报触发（警报属性）到GitHub Issues关闭的时间差。
- 平均无故障时间 ：测量连续GitHub Issues创建时间之间的平均时间。
- 其他指标 ：受所使用工具的元数据暴露/收集能力影响。例如，与Azure DevOps相比，GitHub Issues在分配用户和状态更改方面提供的历史信息较少。

可以通过Power BI Desktop的GitHub（Beta）集成连接到存储库的数据集，轻松创建上述指标的报告。

2. 事件响应演示

以下演示展示了应用上述概念的实际方法：
当满足Azure警报条件时，会使用警报操作组触发一个逻辑应用（Logic App）。逻辑应用将执行以下工作流：
1. 创建一个Microsoft Teams频道用于讨论。
2. 发布一个包含事件详细信息的自适应卡片（Adaptive Card）。
3. 使用Microsoft Teams Shifts定义值班时间表，逻辑应用会在频道消息中提及值班工程师进行通知。
4. 创建一个GitHub Issue用于事件跟踪。
5. 基于从GitHub Issues事件跟踪解决方案中提取的数据生成Power BI报告。

此外，还有一个未实现的附加功能：事件解决后，可以将所有活动信息（频道帖子、文件、问题跟踪活动等）收集起来进行高级分析。具体步骤如下：
1. 将事件数据（Teams频道 + GitHub Issues）导出到Azure存储账户Blob。可以使用另一个逻辑应用、GitHub Actions或其他自动化工具，结合REST API调用从上述工具中导出信息。Microsoft Graph API可用于与Microsoft服务（如Teams、Outlook、OneDrive等）进行交互和获取信息。
2. 使用Azure认知搜索（Azure Cognitive Search），这是一种云搜索服务，能够摄取数据、使用认知服务丰富数据（例如从PDF文件或事件解决过程中使用的截图中提取数据）、对数据进行索引，并提供强大的搜索体验。
3. 创建一个Azure Bot，通过查看Azure搜索中索引的历史数据来帮助解决事件。

3. 无责复盘

事件不可避免，虽然通常被视为负面事件，但也是学习和改进系统的机会。无责复盘是基于诚实、学习和问责的过程，包含以下要点：
- 构建事件补救时间线和收集文档 ：这对于理解根本原因和创建成功的学习过程至关重要，需要收集警报详细信息、涉及的值班工程师、基于Azure DevOps工作项和GitHub Actions的事件跟踪历史和数据，以及基于Microsoft Teams和Slack的讨论内容。
- 避免指责 ：不指责任何人，避免人类寻找责任工程师的自然倾向，假设员工已尽最大努力。应关注系统而非个人，这对组织来说是最困难但影响最大的改变。

不同的组织文化对信息流动有不同影响，如Westrum组织文化分为以下三类：
| 组织文化类型 | 合作程度 | 信使待遇 | 责任承担 | 跨部门协作 | 失败处理 | 创新接纳 |
| — | — | — | — | — | — | — |
| 病态（权力导向） | 低合作 | 信使被打压 | 推卸责任 | 不鼓励跨部门协作 | 失败则找替罪羊 | 创新被扼杀 |
| 官僚（规则导向） | 适度合作 | 信使被忽视 | 责任范围狭窄 | 容忍跨部门协作 | 失败追求正义 | 存在创新问题 |
| 生成（绩效导向） | 高合作 | 信使得到培训 | 风险共担 | 鼓励跨部门协作 | 失败引发探究 | 创新得以实施 |

生成型文化环境在复盘活动中有诸多好处，如高合作和跨部门协作能促进更好的合作、打破部门壁垒、形成跨职能团队；信使得到培训和失败引发探究能让员工及时分享潜在问题、消除指责、以问题驱动改进；风险共担使质量、可用性、可靠性和安全性成为每个人的责任。

在无责对话中，提问应聚焦于技术而非工程师，例如避免问“谁进行了修改数据库架构的更改？”，而应问“是什么原因导致修改数据库架构从而引发了故障？”。可以使用Azure DevOps Wiki和GitHub Wikis等工具作为集中存储库，捕获和分享学习经验和最佳实践，复盘也可能会产生后续行动以避免未来发生类似事件。

4. 无责复盘最佳实践

为了使复盘过程成功，可以考虑以下建议：
1. 明确负责人和角色 ：事件指挥官/经理负责推动讨论并提供收集的数据和反馈。
2. 筛选复盘事件 ：并非所有事件都需要进行复盘，只有高严重性事件或耗时超过预期的事件（设定一个阈值）才可能需要。
3. 提出恰当问题 ：提问应关注系统而非个人，问“如何”或“什么”比问“为什么”更好，因为“为什么”问题往往带有评判性。一些组织使用5 Whys技术进行根本原因分析，但要注意避免间接指责。
4. 注意语言使用 ：避免使用规范性语言（如“不满意”或“不负责任”）进行评判。
5. 关注正反两方面 ：不仅要关注出现的问题，还要关注做得好的方面，以便在后续事件中借鉴。
6. 控制会议时长 ：会议时间控制在60 - 90分钟左右。
7. 庆祝学习成果 ：认可和庆祝从复盘中获得的经验教训。

5. 混沌工程简介

混沌工程是一门通过对系统进行实验，以增强系统在生产环境中承受动荡条件能力信心的学科。它主要通过对生产运行系统进行实验，识别系统运行中的漏洞和缺陷，从而提高系统的可靠性。

例如，一个工作负载数月来运行良好，但突然出现CPU峰值导致应用程序崩溃。除了排查CPU峰值的根本原因，了解系统为何会因CPU峰值而崩溃同样重要。如果能模拟CPU峰值的发生，工程和开发团队就可以通过发布修复程序、更新架构以实现更容错的设置来解决问题。

混沌工程不仅仅是注入故障触发因素使生产环境崩溃，因为故障通常不是由单一失败引起，而是一系列事件的结果。例如，CPU峰值可能是由于数据库操作延迟、网络连接问题等原因导致。因此，在模拟CPU峰值时，还需要考虑所有可能导致CPU压力的副作用。

混沌工程并非新兴事物，早在2008年左右，Netflix的软件工程师在将数据中心从本地迁移到公共云时就开始采用。由于本地数据中心和公共云管理存在差异，Netflix的工程师需要创建更具弹性的服务架构。

6. 混沌猴子工具

2010年左右，Netflix开发了一个内部的混沌编排工具——混沌猴子（Chaos Monkey），并于2012年将其作为开源产品发布。混沌猴子会随机终止生产环境中运行的虚拟机实例和容器，让工程师更频繁地接触故障，从而激励他们构建更具弹性的服务。

使用混沌猴子的要求是，必须使用Spinnaker（Netflix使用的持续交付平台）来管理应用程序。混沌猴子应该可以与Spinnaker支持的任何后端（如AWS、Google Compute Engine、Azure、Kubernetes、Cloud Foundry）配合使用，并且已经在AWS、GCE和Kubernetes上进行了测试。

Netflix使用混沌猴子来验证其生产运行工作负载（即我们使用的流媒体服务）的稳定性，主要目的是检测系统在关键组件被关闭时的响应情况，以便发现整体拓扑中存在的弱点，并让工程团队进行改进。

7. 混沌工程原则

混沌工程的原则可以概括为以下几点：
- 关注事件序列 ：传统的故障和中断测试通常只关注单一场景，而生产运行的工作负载中的事件很少由单一原因引起，更多是一系列事件的结果。混沌工程侧重于对系统实现这一系列动作的模拟，模拟越复杂，对系统可靠性的信心就越高。
- 提前识别弱点 ：无论系统架构是传统虚拟机、更复杂的容器化架构，还是面向无服务器和微服务的架构，都应在系统作为关键任务或业务关键的生产工作负载运行之前识别出其中的弱点和不足。从基于虚拟机的混沌猴子开始，随着架构变得更加复杂，如容器化工作负载、微服务和无服务器架构，识别弱点的难度也会增加。
- 主动发现问题 ：混沌工程是主动的，旨在提前识别弱点，以便更好地应对可能出现的问题。虽然理论上可以在问题出现之前进行缓解，但在实际的公共云环境中，由于无法管理整个架构工作负载的完整堆栈，很难做到全面规划。

8. 混沌工程的重要性和应用流程

混沌工程对于确保系统在复杂多变的生产环境中的可靠性至关重要。其应用流程可以用以下mermaid流程图表示：

graph LR
    A[确定目标系统] --> B[设计实验场景]
    B --> C[模拟事件序列]
    C --> D[观察系统响应]
    D --> E[分析结果]
    E --> F{是否发现弱点}
    F -- 是 --> G[进行改进]
    F -- 否 --> H[结束实验]
    G --> B

在实际应用中，首先要明确目标系统，即需要进行混沌工程实验的具体系统或服务。然后根据系统的特点和可能面临的风险，设计合理的实验场景。这些场景可以基于以往发生的实际事件，也可以是模拟可能出现的故障。

接下来，在生产环境中模拟这些事件序列，观察系统的响应情况。这一步需要密切监控系统的各项指标，如性能指标、可用性指标等。对观察到的结果进行详细分析，判断系统是否存在弱点。

如果发现了弱点，就需要对系统进行改进，如优化代码、调整架构等。改进完成后，再次进行实验，直到系统能够在各种复杂情况下稳定运行。

9. 混沌工程与其他运维理念的关系

混沌工程与SRE（Site Reliability Engineering）和DevOps等运维理念密切相关，但又有所不同。
| 运维理念 | 核心关注点 | 方法特点 | 目标 |
| — | — | — | — |
| SRE | 系统的可靠性和可用性 | 通过监控、自动化等手段保障系统稳定运行 | 确保服务达到预定的服务级别目标 |
| DevOps | 开发和运维的协作与流程自动化 | 强调开发、测试、部署等环节的快速迭代 | 提高软件交付的速度和质量 |
| 混沌工程 | 系统在故障情况下的鲁棒性 | 通过实验主动发现系统弱点 | 增强系统在生产环境中的可靠性 |

SRE更侧重于对系统的日常监控和维护，确保系统在正常情况下能够稳定运行。DevOps则注重开发和运维团队之间的协作，提高软件交付的效率。而混沌工程则是通过主动引入故障来测试系统的可靠性，发现潜在的问题并进行改进。

虽然它们的侧重点不同，但都是为了提高系统的整体性能和可靠性。在实际应用中，可以将混沌工程与SRE、DevOps相结合，形成更加完善的运维体系。

10. 混沌工程的挑战和应对策略

在实施混沌工程时，可能会面临一些挑战，以下是一些常见的挑战及应对策略：
- 实验风险控制 ：在生产环境中进行实验可能会对系统造成影响，甚至导致服务中断。为了控制风险，可以采用逐步增加实验强度、设置安全边界等方法。例如，在开始实验时，先使用较小的故障注入量，观察系统的反应，确保系统能够承受后再逐步增加。
- 数据收集和分析 ：实验过程中需要收集大量的数据，以便分析系统的响应情况。但数据的收集和分析可能会比较复杂，需要建立有效的数据收集和分析机制。可以使用专业的监控工具和数据分析平台，对实验数据进行实时监控和分析。
- 团队文化和沟通 ：混沌工程需要团队成员之间的密切配合和沟通。但在实际工作中，可能会存在团队成员对混沌工程的理解不一致、沟通不畅等问题。为了解决这些问题，需要加强团队培训，提高团队成员对混沌工程的认识和理解，建立良好的沟通机制。

11. 总结

通过对性能测量、事件响应、无责复盘和混沌工程的介绍，我们了解到在云环境中保障系统可靠性的重要性和方法。

性能测量可以帮助我们了解系统的运行状态，通过合理选择和使用指标，如MTTF、MTTR、MTBF等，以及利用微软工具进行数据收集和分析，可以更好地监控系统的性能。

事件响应流程能够在系统出现故障时，快速采取措施进行处理，减少故障对业务的影响。通过逻辑应用、Teams、GitHub等工具的配合，可以实现高效的事件响应。

无责复盘则是在事件发生后，通过客观分析和总结经验教训，避免未来发生类似事件。强调关注系统而非个人，营造良好的团队文化。

混沌工程通过主动实验，提前发现系统的弱点，增强系统在生产环境中的可靠性。虽然实施过程中会面临一些挑战，但通过合理的策略和方法，可以有效应对。

在实际工作中，我们应该将这些方法和理念相结合，不断优化系统的性能和可靠性，为业务的稳定运行提供有力保障。