监控系统是SRE 团队监控服务质量和可用性的一个主要手段。所以，监控系统的设计策略值得着重讨论。最普遍的和传统的报警策略是针对某个特定的情况或者监控值，一旦出现情况或者监控值超过阈值就触发 E-mail警报。但是这样的报警策略并不是非常有效∶一个需要人工阅读邮件和分析警报来决定目前是否需要 ...

产品研发部门和SRE 之间可以通过消除组织架构冲突来构建良好的合作关系。在企业中，最主要的矛盾就是迭代创新的速度与产品稳定程度之间的矛盾。正如上文所说，其表现形式可能是间接的。在SRE模型中，我们选择正面面对这种矛盾，使用的工具是错误预算。 "错误预算"起源于这样一个理念∶任何产品都不 ...

上文已经讨论过，Google将 SRE 团队的运维工作限制在50%以内。SRE 团队应该将剩余时间花在研发项目上。在实践中，SRE管理人员应该经常度量团队成员的时间分配，如果有必要的话，采取一些暂时性措施将过多的运维压力转移回开发团队处理。例如∶将生产环境中发现的Bug 和产生的工单转给研发管理人员去分 ...

DevOps 这个名词是在2008年年末流行起来的，截止到本书写作时（2016年初），这个单词的具体意义仍在不断改变中。这个名词的核心思想是尽早将 IT 相关技术与产品设计和开发过程结合起来，着重强调自动化而不是人工操作，以及利用软件工程手段执行运维任务等。这些思想与许多 SRE 的核心思想和实践经验相 ...

SRE 这种模型是 Google尝试着从根本上避免产生这种矛盾的结果。SRE 团队通过雇佣软件工程师，创造软件系统来维护系统运行以替代传统模型中的人工操作。 SRE 究竟是如何在 Google起源的呢? 其实我的答案非常简单∶SRE就是让软件工程师来设计一个新型运维团队的结果。当我在 2003年加入 Google 的时候 ...

雇佣系统管理员（sysadmin）运维复杂的计算机系统，是行业内一直以来的普遍做法。这些系统管理员负责将现成的软件组件部署于生产环境中，对外提供某种业务服务。系统管理员的主要工作在于应对系统中产生的各种需要人工干预的事件，以及来自业务部门的变更需求。随着系统变得越来越复杂，组件越来越多， ...

软件工程有的时候和养孩子类似∶虽然生育的过程是痛苦和困难的，但是养育孩子成人的过程才是真正需要花费绝大部分精力的地方。但是，传统软件工程专业花费了很多精力讨论软件的开发过程，而不是其后的维护过程。有统计显示，一个软件系统的40%~90% 的花销其实是花在开发建设完成之后不断维护过程中的。 ...

如果用一个词语来描述 Google 的历史，那就是不断地"扩大规模"（scaling up）。Google的成长经历，是计算机行业中数一数二的成功故事，标志着整个社会向 IT 为中心的商业模式的转变。Google 很早就开始实践 IT 与商业模式的结合，也是向社区推广DevOps 理念的先行者。本书就是由来自公司各个部门，切身 ...