SRE

本文将探讨如何与受影响的客户共同回顾事故分析报告，从而获得更具可操作性的洞察，并帮助客户改进其系统架构和运维实践。对于采用 SRE 体系的团队而言，事故复盘、服务等级目标（SLO）和错误预算不仅能帮助平台方改进服务，也能帮助客户提升自身系统的可靠性。文中还将提供一个基于通用 SRE 事故分析报告模板…

你有没有想过，当一家大型海外互联网公司的核心服务出现问题时，内部会如何进行 SRE 事件管理和故障响应？在技术行业里，我们常用“救火”来形容处理线上故障的过程。 当然，和真正的消防员不同，工程师面对的大多数事件通常不会直接危及生命安全。尽管这个比喻并不完全贴切，但 SRE（站点可靠性工程师）与其他领…

如果你运营任何类型的互联网服务，就会知道生产事故几乎不可避免。无论架构设计多么稳健，发布流程多么严谨，最终总会有某些因素叠加失控，导致客户无法正常使用你的服务。 你努力打造用户喜爱的产品，不断推出新功能，既是为了提升现有用户的满意度，也是为了吸引更多新用户。然而，发布新功能，或者引入任何形式的变更，…

SRE 参与：做什么、怎么做，以及为什么做 在现代软件工程和服务可靠性建设中，SRE 参与模式决定了一个服务能否更早、更系统地满足生产环境要求。本文将围绕 SRE 参与、生产就绪评审（Production Readiness Review，PRR）、早期参与模型以及 SRE 平台化实践，讨论服务可靠…

站点可靠性工程师（SRE）的一项核心职责，是量化所维护系统的可靠性。可靠性测试是 SRE 提升系统稳定性、降低故障风险、优化 MTTR 与 MTBF 的重要手段。SRE 通常会把传统软件测试技术应用到大规模系统中，以完成这项工作。可靠性既可以从历史角度衡量，也可以从未来角度衡量：前者通过分析监控系统…

作为 SRE（站点可靠性工程师），我们维护的是大规模、复杂的分布式系统。我们不断为服务添加新功能，引入新系统。鉴于系统规模庞大、变化速度极快，故障和中断不可避免。当故障发生时，我们会修复根本问题，使服务恢复正常运行。然而，如果没有一套正式的事后复盘流程来从故障中吸取经验教训，同样的问题就可能反复出现…

在 SRE，也就是站点可靠性工程中，我们希望把时间投入长期的工程项目，而不是日常运维工作。由于“运维工作”这个说法容易引起误解，我们使用一个更精确的术语：琐务。 琐务管理是 SRE 实践中的核心议题。识别并减少琐务，不仅能提升工程效率，也能帮助团队更好地保障服务可靠性、扩展系统规模，并避免工程师长期…