站点可靠性工程师

事件响应和危机管理

事件响应包括监控、检测和应对计划外事件或中断，其目标是最小化平均事件解决时间 (MTTR) 并满足服务级别协议 (SLA)。

事件响应和危机管理的一些最佳实践：

快速检测、响应和遏制对于确保事件在最短时间内得到缓解并避免进一步影响至关重要。
建立强大的值班系统，简化值班日程安排并纳入运维 Runbook 以实现有效的事件缓解。
建立有效的事后分析流程。根因分析通常应包括以下内容：
- 影响分析 - 确定因此事件受影响的系统、内部流程、终端用户以及可能造成的财务影响。
- 根因和解决方案 - 对事件进行根因分析，并确定实施防护措施的机会，以避免未来再次发生类似情况。
- 监控和告警 - 确定已设置的 metric 和告警阈值是否报告了正确的信号，以及是否有预防潜在事件的机会。
- 行动项和学习 - 分配行动项负责人并跟进。建立反馈机制将事件中的经验教训纳入产品生命周期以避免未来故障非常重要。

服务级别目标和关键 metrics

SLI（服务级别指标）是实际的测量值/metrics。示例包括：响应时间（毫秒）、系统正常运行时间百分比、每百万请求的错误率、每秒请求吞吐量、资源利用率（CPU、内存等）。

SLO（服务级别目标）是使用 SLI 设定的目标。它们定义了"良好服务"的含义。例如：95% 的请求将在 200ms 内完成、每月 99.9% 的正常运行时间、30 天内错误率低于 0.1%。SLI 和 SLO 之间的关系可以定义为：

SLI (metric) + 目标 + 时间窗口 = SLO 示例：响应时间 (SLI) + 低于 200ms + 30 天内测量 = SLO

SLI 和 SLO 的最佳实践如下

为 SLO 建立 SMART 框架
- 具体 (Specific)：明确的 metric 和阈值（"响应时间低于 200ms"）。
- 可衡量 (Measurable)：可以用监控工具跟踪。
- 可实现 (Achievable)：在系统能力范围内是现实的。
- 相关 (Relevant)：与用户体验相关。
- 有时限 (Time-bound)：在定义的时期内测量（例如 30 天）。
选择直接影响用户体验的 SLI。
根据业务需求设定现实的 SLO 目标。
定期监控和调整。
清晰的文档和沟通。
如果需要，为不同服务层级设置不同的 SLO。
确定关键 Metrics，例如：
- 延迟：衡量系统响应请求的时间，跟踪成功和错误的延迟。
- 流量：监控通过系统的请求或数据量，以了解使用模式和规模需求。
- 错误：跟踪系统内发生的错误频率和类型。
- 饱和度：监控 CPU 和内存等关键资源的利用率，以识别潜在瓶颈。

以下是一个 SLO 文档示例：

Service: User Authentication API SLO: 99.9% of authentication requests will complete in under 500ms Measurement Window: Rolling 30-day period SLI: Response time measured at server Exclusions: Planned maintenance windows

容量规划和扩展

容量规划和事件就绪是确保系统可靠性的基本要素。

一些最佳实践

实施全面的事件日历，包括预期用户流量模式、用户的地理分布、目标 AWS 区域、事件峰值时间等关键组件。
进行事件就绪测试，包括系统扩展验证、性能基准测试和容量阈值测试。
验证故障转移机制，如备份和恢复程序、区域切换 Runbook、事件响应协议、缓解程序。

基础设施管理的自动化和脚本

自动化是基础设施高效运营的关键。自动化创建了更可靠、可扩展和高效的基础设施，同时让团队能够专注于战略性举措而非日常维护。自动化的一些好处包括：

通过少量或无需人工干预增强系统可靠性。
改善可扩展性，允许应用程序根据流量和需求自动扩展。
快速和自动化的事件解决、降低错误率和改善 MTBF（平均故障间隔时间）。
降低运营成本和更好的资源利用。

一些关键的自动化策略包括

实施基础设施即代码 (IaC) 以及版本控制基础设施变更。
持续集成/持续部署 (CI/CD)，包括自动化测试和回滚能力。
具有集成健康检查和自动恢复功能的自愈系统。

SRE 团队的监控和告警策略

有效的监控和告警对于站点可靠性工程 (SRE) 团队主动确保分布式微服务应用程序的可靠性和性能至关重要。监控可能包含数百个微服务的分布式系统是一项挑战。无论架构多么复杂，我们都需要从识别关键 metrics 开始，并从它们对应用程序性能和用户体验的影响逆向推导。

收集全面的遥测数据

确保收集的遥测数据为每个架构组件的健康和性能提供充分的洞察。持续评估所收集数据的相关性和可操作性。

告警策略

定义可操作的告警 - 从遥测数据生成的告警应该是可操作的，允许 SRE 团队快速识别和响应问题。告警应基于有意义的、能预测潜在问题的阈值和模式。
优化告警路由和升级 - 实施明确定义的告警路由和升级流程，确保正确的团队和个人收到关键问题的通知。持续审查和改进告警路由以提高响应速度并减少告警疲劳。

Dashboard 和可视化

创建全面的 Dashboard - 开发提供应用程序状态整体视图的 dashboard，包括关键运营 metrics、成本和容量规划数据以及基础设施健康状况。确保 dashboard 包含能够有效预测和预防问题的阈值和指标。
启用数据驱动的决策制定 - 使用从 dashboard 获得的洞察来为数据驱动的决策过程提供信息，例如容量规划、性能优化和事件响应策略。

混沌工程和实验指南

混沌工程的目标是测试应用程序的可靠性，并了解应用程序如何响应中断事件，如停机、流量突然激增和其他外部事件。混沌工程帮助团队评估性能瓶颈、应用程序行为并实施策略以在真实场景中修复故障。

混沌工程的最佳实践

从小规模开始，逐步增加复杂性 - 这包括建立假设（例如，如果应用程序的流量增加 30%，它的表现如何），
定义稳态。
通过实验引入故障。
观察系统行为并采取纠正性恢复措施。
实施强大的监控 - 为了有效的混沌工程，确保您正在收集相关的遥测数据，如日志、metrics、traces 等。
始终有回滚计划 - 将混沌工程集成到 CI/CD 管道中，确保您能够自动化和测试您的回滚计划。
从每次实验中学习，记录发现，改善系统韧性，并将混沌工程集成到您的开发生命周期中。

通过系统地实施这些混沌工程实践，组织可以显著提高系统的韧性，减少意外停机时间，并构建更可靠的服务。请记住，目标不是制造混乱，而是构建能够承受混乱条件的系统。

事件响应和危机管理​

事件响应和危机管理的一些最佳实践：​

服务级别目标和关键 metrics​

SLI 和 SLO 的最佳实践如下​

容量规划和扩展​

一些最佳实践​

基础设施管理的自动化和脚本​

一些关键的自动化策略包括​

SRE 团队的监控和告警策略​

收集全面的遥测数据​

告警策略​

Dashboard 和可视化​

混沌工程和实验指南​

混沌工程的最佳实践​

参考资料​