liu

在一篇关于开发者生产力的研究论文中，作者提出了一个难以回避的悖论：如果你问某位开发者今天是否“高效”，大多数人都能相当清楚地判断自己这一天是否富有成效。对个人而言，判断自己当天是否进入了心流状态并不困难；受心情、工作内容和外部干扰影响，他们甚至可能对自己的生产力给出较高或较低的评价。 然而，一旦把同…

10 月 22 日星期一，某海外云服务商发生了一次服务故障。由于该故障导致多个热门网站宕机数小时，事件引发了广泛关注。某海外流媒体服务提供方也受到了一定影响，但对终端用户造成的实际影响较小。 从高可用架构、故障隔离和可用区疏散的角度来看，这次事件具有较强的参考价值。回顾此次事件，我们有一些应对措施做…

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

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

事情总会出错，这就是现实。当软件交付结果不如预期时，真正重要的不是失败本身，而是团队接下来如何应对。对于希望提升软件交付效率、DevOps 实践水平和组织绩效的团队来说，能否正确面对失败，往往决定了团队能否持续成长。 海外某些技术研究团队的研究表明，那些鼓励信任的团队文化——允许提出质疑、支持合理冒…

客户可靠性工程中的错误预算管理方法 错误预算是服务可靠性管理中的重要工具，它可以帮助团队在功能发布速度与系统稳定性之间取得平衡。当服务超出服务级别目标（SLO）时，团队不应只依赖直觉决策，而应通过错误预算消耗分析，判断问题来源，并采取合适的发布控制、可靠性改进和风险缓解措施。对于研发团队而言，借助 …

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

想判断一个 DevOps 团队的软件交付能力是否优秀，不能只依赖主观感受，而应通过可量化的研发效能指标进行评估。经过多年研究，海外某 DevOps 研究团队提出了四项能够反映软件交付团队绩效的关键指标： 部署频率：组织成功将代码发布到生产环境的频率。 变更前置时间：从代码提交到正式发布所需的时间。 …

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

软件系统本质上是动态的，也因此天然并不稳定。对于 SRE（站点可靠性工程）而言，提升软件可靠性，并不只是增加更多流程、工具或代码，而是持续在系统稳定性、开发敏捷性与架构简洁性之间寻找平衡。本文将从复杂性治理、无用代码清理、极简 API、模块化设计和简化发布等角度，讨论为什么软件简洁性是系统可靠性的前…