《SRE: Google 运维解密》读书笔记1

计算机软件系统离开人通常是无法自主运行的。那么究竟应该如何去运维一个日趋复杂的大型分布式计算系统呢？

系统管理员模式

雇佣系统管理员(systemadmin)运维复杂的计算机系统，是行业内一直以来的普遍做法。

系统管理员负责将现成的软件组件部署于生产环境中，对外提供业务服务。系统管理员的主要工作在于应对系统中产生的各种需要人工干预的事件，以及来自业务部门的变更需求。随着系统变得越来越复杂，组件越来越多，用户流量不断上升，相关的事件和变更需求也会越来越多。于是公司需要招聘更多的系统管理员，来应对日益增多的时间。系统管理员的日常工作和研发工程师相差甚远，通常分属于两个不同的部门：开发部(Dev)和运维部(Ops)。

这种模型具有很多优势。对新公司来说，这种模式在行业内具有广泛的参考案例。市场上具有相关从业经历的人也很多，招聘相对容易。很多第三方工具厂商及系统集成厂商都有现成的工具和软件解决方案帮助一个相对初级的系统管理员团队应对简单的系统维护操作，避免重新发明轮子。

但是，这样做以及相应造成的Dev/Ops分离的团队模型存在一些无法避免的问题。

1、直接成本。直接成本相对清晰，因为系统管理员团队大部分依赖人工处理系统维护事件以及变更的实施。随着系统复杂度的增加，部署规模的扩大，团队的大小基本与系统负载成线性相关，共同增长。

2、间接成本。研发团队和系统运维团队分属两个部门所带来的间接成本没有直接成本那么清晰，但往往比直接成本大得多。从本质上来说，由于研发团队和运维团队背景各异，技术能力与工具使用习惯差异巨大，工作目标也截然不同。两个团队对产品的可靠程度要求理解不同，具体执行中对某项操作的危险程度评估与可能的技术防范措施也有截然不同的理解。这些细节上的分歧累积起来，最后逐渐演变成目标与方向上的分歧及形成内部沟通问题，甚至最后上升到部门之间的信任与尊重层面。这种情形是谁也不愿意见到的，但确实时时上演的。

Google 的解决之道：SRE

SRE 这种模型是 Google 尝试着从根本上避免产生这种矛盾的结果。 SRE 团队通过雇佣软件工程师，创造软件系统来维护系统运行以替代传统模型中的人工操作。

SRE 方法论中的主要模块，就是 SRE 团队的构成。SRE 团队成员具有如下特点：

(a) 对重复性、手工性的操作有天然的排斥感。

(b) 有足够的技术能力快速开发出软件系统以替代手工操作。

同时， SRE 团队和产品研发部门在学术和工作背景上非常相似。因此，从本质上来说， SRE 就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。 SRE 倾向于通过设计、构建自动化工具来取代人工操作。

SRE 模型成功的关键在于对工程的关注。如果没有持续的、工程化的解决方案，运维的压力就会不断增加，团队也就需要更多的人来完成工作。如果一个产品非常成功，用户流量越来越大，就需要更多的团队成员来重复进行同样的事情。为了避免这一点，负责运维这个服务的团队就必须有足够的时间编程，否则他们就会被运维工作所淹没。

Google 的经验法则是, SRE 团队必须将 50% 的精力花在真实的开发工作上。

Google SRE 模型在运维大规模复杂系统时有很多优势。 由于 SRE 在调整 Google 系统的过程中常常直接参与开发、修改代码， SRE 文化在 Google 内部基本代表了一种快速、创新、拥抱变化的文化。 SRE 模型不仅消除了传统模型中研发团队和运维团队的冲突焦点，反而促进了整个产品部门水平的整体提高。因为 SRE 团队和研发团队之间的成员可以自由流动，整个产品部门的人员都有机会学习和参与大规模运维部署活动，从中获得平时难以获得的宝贵知识。

虽然 SRE 模型带来了一些优势，但也存在一些问题。 Google 面对的一个持久性的难题就是如何招聘合适的 SRE。首先，SRE 要和产品研发部门招聘传统的软件开发工程师竞争。其次，由于 SRE 要求同时具备多项技能，市场上具有相关从业背景和经验的人就更少了。由于 SRE 模型也比较新，行业内关于如何建立和维护 SRE 团队的相关信息并不多。最后，SRE 团队已建立之后，由于 SRE 模型中为了提高可靠性需要采取一些与常规做法违背的做法，需要强有力的管理层支持才能推行下去。

DevOps 还是 SRE ?

DevOps 的核心思想是尽早将 IT 相关技术与产品设计和开发过程结合起来，着重强调自动化而不是人工操作，以及利用软件工程手段执行运维任务等。这些思想与许多 SRE 的核心思想和实践经验相符合。 可以认为 DevOps 是SRE 核心理念的普适版， SRE 是 DevOps 模型在 Google 的具体实践。

SRE 方法论

Google SRE 的几个核心方法论（先列标题，细节以后分期更新）：
(1)确保长期关注研发工作；
(2)在保障服务 SLO 的前提下最大化迭代速度；
(3)监控系统；
(4)应急事件处理；
(5)变更管理；
(6)需求预测和容量规划；
(7)资源部署；
(8)效率与性能。

开始“读书笔记计划”，希望自己能坚持下去。