SRE：Google运维解密 - (EPUB全文下载)

文件大小：0.59 mb。
文件格式：epub 格式。
书籍内容：

SRE：Google运维解密
第Ⅰ部分 概览
第Ⅱ部分 指导思想
第Ⅲ部分 具体实践
第Ⅳ部分 管理
第Ⅴ部分 结束语
附录A 系统可用性
附录B 生产环境运维过程中的最佳实践
附录C 事故状态文档示范
附录D 事后总结示范
附录E 发布协调检查列表
附录F 生产环境会议记录示范
参考文献
索引
关于编著者
封面介绍
第Ⅰ部分 概览
这一部分为SRE具体的工作提供了一些概括性介绍，以及SRE究竟与传统的运维存在哪些不同。
第1章：Ben Treynor Sloss,Google运维团队的高级副总裁，SRE名称的发明者，在这里提供了他对SRE的定义，描述了SRE 究竟与其他类似职位存在哪些不同。
第2章：对 Google 生产环境进行了介绍。本章通过介绍Google组建和运维生产环境的细节，为本书其他部分提到的各种专业术语和系统名词提供铺垫。
第1章 介绍
作者：Benjamin Treynor Sloss[1]
编辑：Betsy Beyer
不能将碰运气当成战略。
——SRE俗语
大家都知道，计算机软件系统离开人通常是无法自主运行的。那么，究竟应该如何去运维一个日趋复杂的大型分布式计算系统呢？
系统管理员模式
雇佣系统管理员（sysadmin）运维复杂的计算机系统，是行业内一直以来的普遍做法。
这些系统管理员负责将现成的软件组件部署于生产环境中，对外提供某种业务服务。系统管理员的主要工作在于应对系统中产生的各种需要人工干预的事件，以及来自业务部门的变更需求。随着系统变得越来越复杂，组件越来越多，用户流量不断上升，相关的事件和变更需求也会越来越多。于是公司需要招聘更多的系统管理员，来应对日益增多的事件。系统管理员的日常工作与研发工程师相差甚远，通常分属两个不同的部门：开发部（Dev）和运维部（Ops）。
这种模型具有许多优势。对新公司来说，这种模式在行业内具有广泛的应用案例可供参考。市场上具有相关从业经历的人也很多，招聘相对容易。很多第三方工具厂商及系统集成厂商都有现成的工具和软件解决方案帮助一个相对初级的系统管理员团队应对简单的系统维护操作，避免重新发明轮子。
但是，很少有人提及这样做以及相应造成的Dev/Ops分离的团队模型存在一些无法避免的问题。下面我们从两个大的方面来阐述。
1.直接成本。直接成本相对清晰，因为系统管理员团队大部分依赖人工处理系统维护事件以及变更的实施。随着系统复杂度的增加，部署规模的扩大，团队的大小基本与系统负载成线性相关，共同增长。
2.间接成本。研发团队和系统运维团队分属两个部门所带来的间接成本就没那么容易度量了，但是这些间接成本往往大得多。从本质上来说，由于研发团队和运维团队背景各异，技术能力与工具使用习惯上差距巨大，工作目标也截然不同。两个团队对产品的可靠程度要求理解不同，具体执行中对某项操作的危险程度评估与可能的技术防范措施也有截然不同的理解。这些细节上的分歧累积起来，最后逐渐演变成目标与方向上的分歧及形成内部沟通问题，甚至最后上升到部门之间的信任与尊重层面。这样的情形是谁也不愿意见到的，但却是时时上演的。
传统的研发团队和运维团队分歧的焦点主要在软件新版本、新配置的变更的发布速度上。研发部门最关注的是如何能够更快速地构建和发布新功能。运维部门更关注的是如何能在他们值班期间避免发生故障。由于绝大部分生产故障都是由于部署某项变更导致的—不管是部署新版本，还是修改配置，甚至有时只是因为改变了用户的某些行为造成了负载流量的配比变化而导致故障。这两个部门的目标从本质上来说是互相矛盾的。
极端来说，研发部门想要：“随时随地发布新功能，没有任何阻拦”，而运维部门则想要：“一旦一个东西在生产环境中正常工作了，就不要再进行任何改动。”由于两个部门使用的语境不同，对风险的定义也不一致。在现实生活中，公司内部这两股力量只能用最传统的政治斗争方式来保障各自的利益。运维团队常常宣称，任何变更上线前必须经过由运维团队制定的流程，这有助于避免事故的发生。例如：运维团队会列出一个非常长的检查清单，历数所有以前曾经出现过的生产事故，要求研发团队在上线任何功能之前必须将所有这些事故模拟一遍，确保不会重现。这个清单通常没有任何标准，每项事故的可重现程度、问题价值并不一定是一致的。而开发团队吃过苦头之后也很快找到了自己的应对办法：开发团队宣称他们不再进行大规模的程序更新，而是逐渐转为功能开关调整、增量更新，以及补丁化。采用这些名词的唯一目的，就是为了绕过运维部门设立的各种流程，从而能更快地上线新功能。
Google的解决之道：SRE
SRE 这种模型是Google尝试着从根本上避免产生这种矛盾的结果。SRE团队通过雇佣软件工程师，创造软件系统来维护系统运行以替代传统模型中的人工操作。
SRE究竟是如何在Google起源的呢？ 其实我的答案非常简单：SRE就是让软件工程师来设计一个新型运维团队的结果。当我在2003年加入Google的时候，我的任务就是领导一个由7名软件工程师组成的“生产环境维护组”。当时，我的整个职业生涯都专注于软件工程，所以很自然，我按照自己最习惯的工作方式和管理方式来组建了这个团队。时过境迁，当年的7人团队已经成长为公司内部1000余人的SRE团队，但是SRE团队的指导理念和工作方式还是基本保持了我最初的想法。
SRE方法论中的主要模块，就是SRE团队的构成。每个SRE团队里基本上有两类工程师。
第一类，团队中 50%～60% 是标准的软件工程师，具体来讲，就是那些能够正常通过Google软件工程师招聘流程的人。第二类，其他40%～50% 则是一些基本满足Google软件工程师标准（具备85%～99% 所要求的技能），但是同时具有一定程度的其他技术能力的工程师。目前来看，UNIX 系统内部细节和1～3层网络知识是Google最看重的两类额外的技术能力。
除此之外，所有的SRE团队成员都必须非常愿意、也非常相信用软件工程方法可以解决复杂的运维问题。Google一直密切关注这两类候选人在招聘通过 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。