共计 5017 个字符，预计需要花费 13 分钟才能阅读完成。
| 导读 | SRE 是 Site Reliability Engineering 的简称，它是源起于谷歌内部产品技术保障过程中演进而来的运维新模型，并且定义了新岗位的职责范围。区别于传统运维模式，SRE 强调自动化系统，主张通过软件工程方式开发出一些场景化的自动化运维工具来替代重复和手工操作。本场 Chat 中我们将通过一些国外 SRE 实践的案例来介绍一下 SRE 自动化的演进。 |
内容包括：
自动化系统对 SRE 的价值；
自动化系统演进的历程；
国外互联网企业 SRE 自动化应用案例；
国内运维领域自动化实践。
SRE 是 Site Reliability Engineering 的简称，它是源起于国外互联网企业的一个词语或者新定义的一个岗位。在传统的系统管理员模式时代这个角色我们叫运维，国外称做 Operation。
Google SRE 的 VP 叫 Ben Treynor，2003 年的时候他加入公司第一个任务就是组建一个 7 人的“生产运维小组”。但很快他发现根据 Google 机器增加的速度，按照传统的运维模式是无法快速满足运维可靠需求的。由于他自己本身就是一个资深的软件开发人员，他就按照组建一个研发团队一样来组建这个运维团队。招收了许多研发工程师，这些工程师具有开发能力，又了解一些系统管理的知识，最主要的是他们鄙视重复劳动。他们把一些最佳实践、方式、流程、方法都固化成代码，用这种方式去应对规模性的扩张，去应对复杂度的上升。
典型的 SRE 活动分为：软件工程、系统工程、琐事、流程负担四个部分。其中我们可以看到有一类工作它与日常运维服务直接相关，但是在 SRE 里面被定义为低效工作，在 Google 还是用一个专门的词语 - 琐事（Toil）来进行描述。
琐事是运维服务中手动的，重复的，战术性的工作。它的增长与服务的增长呈线性关系。这一部分的工作是可以被自动化的。Google 公开提出 SRE 要保证至少 50% 的时间在软件工程项目上，因为如果不加以控制，琐事会变得越来越多，并迅速占据 SRE 人员的大部分时间。减少琐事和扩大服务规模的工作就是 SRE 中的 E(Engineering)。
从这张片子我们可以看出自动化对于 SRE 而言的价值主要来自于性能和效率两方面。提到自动化很多人肯定首先想到的是效率的提升，其实相对单纯提升效率而言 SRE 人员更强调系统性能和快速灵活之间的平衡。自动化通过剔除操作中由于使用人工手动执行带来的不一致性，确保“一致性地执行范围明确、步骤已知的程序”从而保障系统性能，这才是自动化的首要价值。
自动化系统可以提供一个可以扩展的、广泛适用的平台。平台可以将问题集中化，规模化地处理系统的错误，也能比人能更持续更频繁地运行任务。而且由于平台可以暴露自身的性能指标，也可以帮助我们发现以前流程中不易察觉的细节。当然平台化的基础在于正确地设计和实现。而自动化对于效率带来的提升我们就更加容易理解。虽然我们经常会对比分析编写一个自动化程序所花费的精力和时间和取消手动节省的部分，但是应该看到一旦自动化得以实现，将会把某个操作与具体的操作者解耦，所以在我们进行衡量的时候，自动化所节省的时间和精力应该来自于所有的使用者。
一位负责 Google 数据中心集群上线流程的 SRE，Joseph Bironas, 曾经说过：“如果我们持续产生不可自动化的流程和解决方案，我们就继续需要人来进行系统维护。如果我们要雇佣人来做这项工作，就像是在用人类的鲜血、汗水和眼泪来养活机器。这就像是一个没有特效但是充满了愤怒的系统管理员的 Matrix 世界。”
Google SRE 的自动化历程经历了以上几个阶段。第一阶段是完全依赖手动操作的无自动化阶段，然后使用外部维护的特定系统的自动化脚本来进行操作，特定的系统自动化逐步演进为通用的系统自动化，然后用内部维护的自动化系统替代外部维护的自动化系统，最终演化为纳入运维平台无需人工触发的自动化系统。
谷歌的资源管理系统 Borg 就是一套典型的谷歌 SRE 长期使用的自动化应用发布系统。为什么资源管理这么重要，因为规模太大，运营成本成为演进的唯一障碍。从技术上来讲，统一的资源管理系统非常难实现，基础设施的好坏决定了此系统的能力。尤其在分布式环境下，不同业务场景下对物理服务器的要求也不完全一样。谷歌的 Borg 能做到统一的资源管理的前提，就是有 GoogleFS、BigTable、Chubby、GSLB 等核心技术的支撑，SRE 是此系统的使用者，为了系统可靠性不断的反馈和改进对 Borg 系统的使用要求，得以至今 Borg 仍然是谷歌内部使用的应用发布系统。
首先，Borg 系统是完全分层的系统架构。从最基础的文件系统到最上面的负载分流，每层的技术栈在谷歌内部都是唯一的，这样做的好处是可以积累经验复用。国内企业的系统架构，在发展过程中也会经历分层组织的架构，抛开人的因素，很多分层是多套系统组合在一起搭建而成。从表面上来看，我们降低了成本，但是其实增加了人力的维护成本。在这个问题点上，国外系统的先进性可以放一放，我们在选择技术的时候应该怎么办？从经验上来讲，同行分享的拼接多套开源系统组成的一层体系是一种走捷径的办法，短期效应明显。一旦企业业务高速发展，每次重构都是毁灭性的推倒重来工具。从我经历的大大小小多种企业系统中，我深刻体会出这种变革动力。在 SRE 里面，工具的变革思路不是用新的开源工具替换旧的开源工具，而是我们的可靠性诉求应该简化工具选型的数量，并在此基础上真正的考虑自己的需求，最终还是要走向自研的自动化系统的道路。
第二，Borg 系统的的基础架构技术足够先进，是不是 SRE 有点多余？显然，技术的先进并不能代替 SRE 的方法论。当前业界最流行的 DevOps 理念中并没有对于成本、可靠性的更多描述，重点关心的是自动化、提高生产力等种种实践。这些实践解决不了业务场景持续发展的最核心问题，就是业务可靠性与成本控制之间的制衡。SRE 的方法就是为了用最低的成本获取最大的业务收益。所以，SRE 岗位招募的是一个会写代码的系统运维工程师，如果只是做运维，单纯的开发人员肯定留不住。所以拔高认知纬度，从软件工程的高度，来解决当前企业内部的业务体系。从笔者切身的体会，我们一家研发产品的技术公司，内部包含测试系统、项目管理系统、流程控制系统、发布系统等等。不管公司大小，都会需要。在没有 SRE 的驱动下，我们会选择一个工具来填补空白。但是系统和系统之间并不是关联的，内部又没有人能真正驱动这个事情的迭代。最后，我们让运维或者开发来简单的解决这个问题，实际情况是没法彻底的解决这个问题。
第三，SRE 在国外互联网公司随处可见，国内却很少有这样岗位或者思想的传播，是不是文化差异导致的？笔者认为国内运维体系在不断演进的过程中，发展速度肯定是慢于国外当前的认知水平导致的现状。但是随着淘宝网的崛起，阿里的技术保障部其实就是国内 SRE 的最佳验证。SRE 的收益是非常明显的，但是在中小企业中推广企业会非常困难。核心问题点在于国外的技术服务商体系非常健全，当中小企业想做一些 SRE 的转变的过程中，可以获取一大批技术服务提供商的方案。并且企业愿意花费一部分费用在此类技术的预研过程中。国内企业期望购买的技术应该是成熟技术，不愿意投入精力花费在基础设施之上。对于成本的控制，也是基于人力成本的考虑之上，很难有技术提供商能有运营空间。那么在这样的困境之下，云计算业务的发展可以起到润滑剂的作用。也就是说，共享技术经济可能是一种 SRE 落地国内的方式。比如笔者所在的数人云，一套落地 SRE 理念的轻量级应用管理平台，通过和企业的合作，完成企业需要的平台建设。在这个合作过程中，演化出来的系统作为附加值，由数人云平台在其他企业中推广获得双赢。从结果上来看，企业获得了 SRE 的成功实践成果，技术服务商获得了 SRE 实践的机会。
第四，SRE 都是善用工具的。我们解决问题的方式的变化，从解决问题到深度分析问题，并且给一个解决这个问题的模型和检查清单。比如 Netflix 公司的 SRE 在解决 Linux 系统性能的时候提供给 SRE 的清单：
限于国内运维领域的发展正在快速迭代，笔者从最为关注的三个领域问题作为突破口为大家分解当前自动化实践的现状。
1. 监控报警
国内监控报警工具品种繁多，但是真正能落地的流行方案少之又少。传统企业最常用的是应该是 Zabbix，另外国内小米开源的互联网企业级监控工具 Open-Falcon 也是一个选择。但是这两种场景下，都没法回避一个非常直接的问题，那么就是如何用最短的路径分析出你的问题并且解决业务场景下的实际问题。从监控的角度，有系统级别的，业务级别的，服务级别的多重维度。从 SRE 的角度处理问题，都是先容量规划，而不是按照先验经验按照各种系统滞后在规划。所以从一开始，工具不是最棘手的问题。就拿 Zabbix 作为例子，可以监控的纬度就是系统的健康，数据库的 QPS，Redis 的内存。但是如果遇到网站变慢，从监控的角度我是无能为力的。必须要有全链路的分析才可以判断出来问题，并解决这个问题。如果按照 DevOps 的经验，我们不太可能提出这种问题，只是当遇到问题的时候，怎么自动切换服务器，或者自动扩容的方案来解决问题。成本的控制在 DevOps 的场景之下是不受控制的，管理者只能强制预算成本，上下游都无法充分了解业务运营到底需要多少成本。
2. 日志监控
国内日志监控大量使用 ELK（Elasticsearch, Logstash, 和 Kibana）技术栈。这套技术栈非常流行，也解决了大量企业内部日志的问题。但是在实际场景中，业务日志的管理仍然是非常痛苦的。一个是实时日志的查询，二个是历史日志的汇聚。怎么有效提供日志查询的使用，去哪儿运维团队共享过一个方法，通过在 Apache Mesos 之上，为内部部门提供随需而启动的 ELK 服务，让开发者随时查询自己的业务日志和分析自己的日志。查询完之后，就自动销毁这个 ELK 服务实例。笔者认为这种创新方式其实就是 SRE 思想的实践。
3. 持续集成和发布系统
国内运维使用最多的工具就是用 Jenkins 来完成持续集成和发布。但是我们往往是只要能用上 Jenkins 就停止了深度的实践。从 SRE 的角度来讲，我们首先分析出持续集成的业务痛点是什么，因为在持续集成的过程中，会接入测试系统。所以笔者认为持续集成的目的是为了让产品质量得到持续的改进。有了核心的目标之后，我们管控的就不仅仅是 Jenkins 的 Job 是如何管理的，而是测试的效率是否能提高，集成的时间是否能缩短。建立一个目标清单，然后在纳入到 SRE 的改进过程中，就一定会产生出不一样的结果。持续发布是另外一个话题，其实难题在于用户对于发布的理解并不彻底。发布包括灰度发布、测试发布、滚动发布、回滚发布等多种场景。并且每种场景都应该是可以回退的。怎么解决这个问题，单靠 Jenkins 是无法解决这个问题的，你需要扩展工具来满足，比如一套轻量级应用管理平台的辅助。
从业界的发展历程来看，技术的标准化是一个必然的演进过程，运维自动化其实就是标准化的一种体现。从入手 SRE 的第一步开始，应该整理和梳理工作职责，把需要解决的问题都文档成检查清单。方便业务上的快速实施。紧接着就是可视化这些业务指标和场景，帮助公司降低运营成本，量化服务体系的目标。对于有能力的企业，在发展过程中会把各种资源的接口统一，这个历程会非常长，从笔者的经验来看，应该小步迭代，按照实际效果谨慎执行。因为不计成本的平台化，只是光鲜的政绩，并没有有效的解决成本问题。自动化的最高形式肯定是智能化系统，但是从笔者的角度来看，可能大家的科幻片看多了，反而淡化了软件工程的目的，就是用科学的方法来最大化软件收益。但是绝对不是高度智能的自愈体系。这种人工智能体系在笔者看来是软件工程的另一个纬度的体现，就有如诺基亚手机和苹果手机之间的对比，SRE 的模型解决的是如何用好当前的工具链发挥诺基亚手机的最大价值，而不是被人工智能体系所替换。也许，在未来的某一天，SRE 会直接退休，让机器人来代替整个运维体系，但是 SRE 终将会在科技历史上记录下深深的烙印。
