我们将讨论事件响应，包括分类和故障排除，并展示现实生活中的例子。
站点可靠性工程 (SRE) 是一门关键学科，专注于确保现代系统和应用程序的持续可用性和性能。SRE 最重要的方面之一是事件响应，这是一个结构化过程，用于识别、评估和解决可能导致停机、收入损失和品牌声誉受损的系统事件。
本文讨论了事件响应的重要性，检查了分类和故障排除的关键要素，并提供了真实世界的示例来展示它们的实际应用。然后，我们将利用我们的洞察力创建一个理想的事件响应计划，各种规模的团队都可以利用该计划来有效地管理和缓解系统事件，确保最高水平的服务可靠性和用户满意度。
事件响应计划摘要
下表总结了我们将在本文中探索的事件响应计划所涉及的步骤。
制定事件响应计划分析
盘点您当前的系统和环境。哪些用户使用哪些系统，瓶颈是什么，故障点是什么？
准备
计算各种故障或中断的影响和严重程度。您是否拥有必要的资源来响应事件并快速使系统恢复在线？
模拟场景
制定计划，在发生故障时通知客户和必要的利益相关者（即法律和合规）。在通知客户时还会发生什么（例如，与生产支持团队接洽、设置 NOC 电话以及可能与供应商支持团队接洽）？
从回顾会议中学习
从试运行中收集经验教训。每个人都有他们需要的一切吗？缺少什么（通信、自动化或工具）？完成事件响应计划
探测
使用现代检测工具。确保有一个预定的支持团队可以收到事件通知并可以快速响应。
分流
观察眼前的问题。让可以在必要时帮助解决问题的同事和供应商参与进来。尽快将问题通知消费者和利益相关者。
解决和恢复
解决问题并确保修复工作正常并减轻影响。将决议和总体影响通知消费者和利益相关者。
为 Runbook 做贡献
调查、自动化并（如果可能）将解决方案添加到运行手册中。这样，如果问题再次出现，它将自动解决。
进行事后剖析
让所有参与分类和解决问题的同事参与进来。确定防止问题再次发生的方法。记录发生的事情以及将来如何预防。收集指标确保存储指标和报告以衡量历史 IR 有效性。不时审查它们以跟踪进度并确定任何自动化潜力或瓶颈。
分流
事件响应流程的第一步是分类，这涉及确定事件的严重性和范围。此阶段旨在评估情况并确定优先资源以解决问题。分类包括三个主要活动：检测、评估和优先级排序。我们将通过两个场景来说明这个过程。
检测
监控工具和警报系统可以使用预定义的标准（例如错误率或响应时间）识别潜在事件，异常检测和基于阈值的警报是常用方法。当客户报告问题时，也可能会通知值班人员。如果系统没有产生任何明显的症状或警报，值班人员必须根据用户报告的问题进行更深入的调查。
场景 1：用户抱怨在证券交易平台上下买单或卖单时，他们的订单没有被执行。这是一个没有任何明显警报的严重事件。
场景 2：监控工具检测到微服务的错误率突然飙升，从而触发 SRE 团队的警报。
评估
一旦检测到事件，SRE 团队必须评估其对系统及其用户的影响。这涉及了解问题的根本原因、受影响的组件和范围。
场景 1：客户支持团队注意到许多关于未履行订单的投诉。SRE 检查服务目录并确定负责订单路由的服务。
场景 2：SRE 团队发现错误率飙升是由于最近的部署在特定服务中引入了错误，仅影响了一部分用户。
优先次序
评估事件后，SRE 团队根据其影响和紧迫性分配严重性级别。严重性级别有助于确定资源的优先级并确定响应时间。如果可能，应更新状态页面以显示哪些服务受到影响以及估计的解决时间。
下表显示了事件的一些示例严重性级别。
严重等级重要性例子SEV-0批判的影响所有用户的完整系统中断或大量数据丢失情况SEV-1高的系统的显着降级或影响大量用户的无法使用的主要功能SEV-2缓和系统的部分降级或影响某些用户的次要功能无法使用SEV-3低的不会显着影响用户体验或系统性能的小问题场景 1：由于这是一个普遍的事件，因此它被归类为 SEV-0。
场景 2：SRE 团队将事件归类为 SEV-2 问题，因为它影响了少数用户，但不是完全的服务中断。
附加示例
让我们再详细看一个场景。在此示例中，由于连接到 Redis 缓存的问题，Web 应用程序遇到延迟增加和偶发错误。
系统总览
- 该应用程序采用三层架构，具有前端 Web 服务器、后端应用程序服务器和数据库服务器。
- 后端服务器使用 Python 和 Flask 构建，并依赖 Redis 进行缓存。
- 该系统在 AWS EC2 实例上运行，弹性负载均衡器 (ELB) 在实例之间分配流量。
- 监控和警报由 Prometheus、Alertmanager 和 Grafana 处理。
Redis 的Grafana 仪表板。
分流
- Prometheus 警报通知 SRE 团队 Web 应用程序中的延迟和错误率增加。
- 该团队检查了 Grafana 仪表板并确认该问题在过去 20 分钟内一直存在。
- SRE 团队确定受影响的组件，包括后端应用服务器和 Redis 缓存，并评估对用户的潜在影响。
下一步行动是排除故障并调查根本原因，最终按照本文下一部分所述解决问题。
疑难解答
对事件进行分类后，下一步就是进行故障排除以确定根本原因并找到解决方案。故障排除通常涉及数据收集、假设生成以及测试和验证。
数据采集
SRE 团队收集相关数据，例如日志、指标和跟踪，以更好地了解问题。这可能涉及查询监控工具、检查应用程序日志或使用分布式跟踪来识别有问题的请求。
场景 1： SRE 团队确定其中一台用于高性能计算的生产裸机的 RAM 使用量出现峰值。
场景 2：SRE 团队查询监控工具以收集有关受影响微服务的错误率、响应时间和资源利用率的数据。
假设生成
根据收集到的数据，该团队对事件的根本原因提出了假设。根据问题的性质，此步骤可能需要与其他团队协作，例如开发人员、服务所有者或网络工程师。
场景 1： 经过与 SRE 和开发团队的进一步调查，假设应用程序队列大小持续增长，导致 RAM 使用量激增。
场景 2：SRE 团队假设部署中的错误导致服务消耗过多资源，从而导致响应时间变慢和错误率增加。
测试和验证
该团队通过运行实验或修改系统配置来验证或反驳其理论来测试其假设。此步骤通常涉及测试和改进假设的迭代循环，直到找到根本原因。
场景 1：使用日志确认队列大小的增长。由于此故障排除事件是与多个团队协作完成的，因此应用程序所有者建议调查工作进程。如果一个或多个工作进程处于错误状态（挂起或僵尸化），建议重新启动或强制终止 ( kill -6 <pid>) 该进程，以便应用程序启动一个新的工作进程并继续从队列中取出物品。这将导致队列大小的减少。
场景 2：SRE 团队暂时将部署回滚到之前的版本，观察到错误率和资源消耗降低，从而验证了假设。
附加示例
我们现在将描述上一节中附加示例的故障排除过程。
故障排除
- 该团队检查了后端应用程序服务器的日志，并注意到间歇性的“Redis 连接错误”消息。他们使用 AWS CloudWatch Logs Insights 来搜索和分析这些日志。
# Example error message in the application logs
RedisError: Error 110 connecting to <redis_host>:<redis_port>. Connection timed out.
- SRE 团队检查 Datadog 中后端应用程序服务器和 Redis 缓存的黄金信号（延迟、流量、错误和饱和度）。他们发现 Redis 缓存正在经历高延迟。
- 该团队使用 AWS 管理控制台检查 AWS 资源（包括 EC2 实例和 ELB）的健康状况和指标。没有发现问题。
- 团队检查 Redis 缓存配置，发现连接池设置过低，导致应用在高负载下耗尽可用连接。
# Example Redis configuration in the Python application (before troubleshooting)
import redis
redis_pool = redis.ConnectionPool(host='redis_host', port=redis_port, db=0, max_connections=5)
redis_cache = redis.Redis(connection_pool=redis_pool)
解决
- 该团队将 Redis 连接池大小增加到更合适的值，从而降低可用连接耗尽的可能性。
# Example Redis configuration in the Python application (after troubleshooting)
import redis
redis_pool = redis.ConnectionPool(host='redis_host', port=redis_port, db=0, max_connections=50)
redis_cache = redis.Redis(connection_pool=redis_pool)
- 更新后的后端应用服务器部署完毕，时延和错误率恢复正常。
- SRE 团队通过检查 Datadog 仪表板并监控后端应用程序服务器和 Redis 缓存的黄金信号来验证问题是否已解决。
- 该团队将解决方案传达给利益相关者并进行事后分析以从事件中吸取教训并改进事件响应流程。
理想的事件响应计划
将以下详细步骤和示例纳入您的事件响应计划可以帮助您创建一个强大而有效的框架来指导您的 SRE 团队完成从事件识别到解决和持续改进的整个过程：
- 事件识别和分类：定义明确的标准来识别事件并对其严重性进行分类。这应该包括与性能相关的因素，例如延迟和错误率，以及系统可用性和网络事件。建立触发警报和升级事件的阈值。
- 沟通和升级协议：为 SRE 团队和其他利益相关者开发清晰的沟通渠道和升级协议。这可能包括使用 Slack、电子邮件或专用事件管理平台等工具。定义事件每个阶段的沟通期望，包括定期更新事件状态、解决进度以及严重程度的任何变化。
- 角色和职责：为事件响应过程的每个阶段的团队成员分配特定的角色和职责。这可能包括监督响应工作的事件指挥官、提供技术专业知识的主题专家以及让利益相关者了解情况的沟通协调员。确保所有团队成员都了解自己的角色，并接受过有效执行任务的培训。服务目录应该用于此目的。
- 事件响应程序：记录用于响应不同类型事件的分步程序，例如分类、故障排除和恢复。这些程序应根据您组织的特定基础设施、技术和服务进行定制。包括清单和流程图，以指导团队成员完成响应过程。
- 事件响应工具和资源：为 SRE 团队提供有效响应事件所需的工具和资源。这可能包括监控和警报工具、服务目录、日志聚合、分析平台以及对文档和运行手册的访问。
- 培训和模拟：尽管经常被忽视，但有关事件响应计划、程序、工具和资源的定期培训对于 SRE 团队最大限度地减少 MTTR 至关重要。虽然事件可能不会遵循一定的模式，但在培训上投入时间和预算将使 SRE 能够分类和解决问题，确保快速有效地恢复服务。
- 恢复和事后审查：建立从事件中恢复和进行事后审查的程序。这也可能发生在事后回顾会议上。这些审查应确定事件的根本原因，评估响应工作的有效性，并确定事件响应计划或基础设施中需要的任何改进。最重要的是，有可能得到这个关键问题的答案：“这件事会重演吗？” 运行手册和自动化武器库应根据答案进行更新。
- 持续改进：定期审查和更新事件响应计划，以确保它保持有效并与您组织不断变化的需求和技术保持一致。结合从真实事件和模拟练习中吸取的教训，以改进计划和程序。
结论
全面有效的事件响应计划对于站点可靠性工程团队快速有效地解决系统事件、最大限度地减少停机时间和潜在损失至关重要。
本文讨论了事件响应的重要性，并提供了真实示例来说明分类和故障排除的过程。通过遵循本文中概述的步骤和指南，SRE 团队可以制定针对其特定基础架构和技术堆栈的强大事件响应计划，确保快速检测、评估、确定优先级和解决事件。
定期培训、持续改进和事后审查将有助于保持计划的有效性，并使其与组织不断变化的需求保持同步。
通过投资于结构良好的事件响应计划，组织可以更好地保护其用户、收入和品牌声誉免受系统中断和故障的不利影响。
