Google SRE工作手册

序言 I Mark Burgess 我很荣幸在为O’Reilly 推介了**本SRE 书之后，再度受邀为它的续集作序。与**本书不同的是，在这本书中作者们不再只是专注于讲述他们的故事，而是试图面向更广大的受众，分享他们**手的经验、实例，并给予不拘形式的指导。只需要稍加辨别，凡是具备一定现代行业眼界的IT 界人士都会认为这些宽泛的主题似曾相识。在这本书里，更多的不是技术规范，而是那些面向用户的服务，以及它们的可靠性目标。我们会发现，在业务实际的发展过程中，人机系统就应运而生了，该系统的目的是固有的，而非像外来陨石影响一个已知的基础设施那般。所有人机合作的部分都是它的重点。事实上，这本书的内容可以总结为以下几点： ?? 致力于设定清晰的、量化的服务承诺。 ?? 通过有限的监控指标，持续地觉知上述量化数值。 ?? 轮值人员随时待命，以保障实现所做出的服务目标承诺，同时避免过度人为干预， 谨防自动化形同虚设。 服务目标承诺是否（对所有相关的各方）能兑现，取决于它所依赖的服务是否稳定、 取决于主观意志和所有参与人员（例如，参见《Thinking in Promises》一书）。值得注意的是，人类对人机系统的看法容易受限于感知的范围，尽管自动化不能完全取代人类，但它却重新定义了人类所需要的规模，即起源于一个小小的想法，*终成长为用户遍布全球的大规模系统。 传授这些经验教训，本身也是一项挑战，况且在得到这些来之不易的知识的过程中， 本来就经历了很多个迭代。我们曾经对这些经验教训不断地提出质疑、反复试验、 屡次失败、反复演练，才使之日臻完善。书中包涵诸多值得深思和应用的内容，让 我们现在开始吧！ 序言 II Andrew Clay Shafer 在听说有人正在撰写第二本SRE 书，我就自告奋勇地提出想为此书写几句话。**本SRE 书的主旨，与我心目中一贯的DevOps 理念不谋而合，尽管它未必100% 适合Google 以外的公司，可是从做法可见其见地深刻。在首次阅读了**本SRE 书的主要章节：拥抱风险（第3 章）、服务质量目标（第4 章）和减少琐事（第5 章）之后，我就迫不及待地想与大家分享这些想法。“拥抱风险”引起了我的强烈共鸣， 因为我曾经也常使用类似的语言，激励传统组织的变革。第6 章（分布式系统的监控）则无疑是DevOps 的一个目标，既让人有时间去做更高级的创造性的工作，又让这些工作更人性化。我非常喜欢“服务质量目标（SLO）”。这为运维工作和新功能发布之间订立了契约，其过程、文字皆为我所喜爱。SRE、SWE（软件工程师）和业务需求方都达成了这样的共识：一个可用的服务才是有价值的，而SRE 的解决方案量化了这个目标，使做什么工作和优先级的确定有了依据。这个解决方案消除了传统的运维与开发之间固有的矛盾：将服务质量目标作为调节杠杆，一旦它低于了预期目标，就将保障稳定性的优先级置于开发新功能之上。这个简洁的构想优雅地解决了问题，因此矛盾也将不复存在了。我将这三个章节几乎推荐给了我所见过的每个人。即使他们都相当出色了，可是每个人仍然有必要了解。我已经将SRE 推荐给了我所有的朋友，你也开始向你的朋友们推广吧！ 在我*近十年的职业生涯里，我一直致力于帮助人们用更好的工具和流程来发布软件。人们有时候会说我为DevOps 做出了创造性的贡献，但我其实只是在许多不同的组织和项目中借鉴和窃取了他们的成功模式而已。当有人讨论“DevOps”的开发者时，一旦谈到我，我还是觉得很尴尬。除了对DevOps 的好奇之外，我不觉得自己是该领域的专家。我所设想到的DevOps 的灵感，皆来自于从身边朋友们那里所撷取到的信息，而我的这些朋友们，恰好就是那些构建互联网的人。我有幸能够接触到一些幕后英雄，他们部署和运营着世界上*著名的和令人难以置信的基础设施和应用系统。DevOps 囊括的优化方案，正是在互联网上快速发布、高可用性的软件所亟需的。从使用实体媒介发布软件，到通过供给服务发布软件，这个变迁推动了工具和流程的发展，提升了运维对价值流的贡献。如果软件系统停止了运行，那么它就毫无价值。这个变迁好的方面是，如果想要升级软件，那你就不必等待那个下周才能送到的包得里三层外三层的快递包裹。而对于另一些人来说，这却是个坏消息。而我只是恰好利用了恰当的机会和视角，向愿意接受的人们阐释了新形势下*成功的工作模式。 因字数限制，略^