SRE之道
运维工程师，更传统的名字叫做系统管理员（Sysadmin），是负责维护和管理IT基础设施的核心角色，长期承担着保障系统稳定运行的重要职责。
另一个听起来更时髦的岗位，SRE1，因与运维工程师工作内容有重叠，常常被视为“高级运维工程师”，甚至被誉为”运维天花板”。
1 Site Reliability Engineering
2 与之相反的思考是：Choose Boring Technology
之所以有这种误解，我认为最主要的原因是那些声称采用了SRE实践的（大）公司，公开分享的内容都专注于如何将《Site Reliability Engineering》一书中提出的各种概念应用到自己的环境中，以及对不断涌现的新工具的追逐。2这种对“术”的过度关注，让我们忽略了对其本质的思考。
The closer you look, the less you see.
SRE的本质并不能用简单的一句保障业务稳定性来概括。而《Site Reliability Engineering》带来的新概念和工具3，是为了达成软件开发速度与质量之间平衡的结果，不是原因。
3 SLO，SLI等等
4 有主动的因素也有被动的因素
5 既包含广义的服务也包含开发过程的微服务
是的，SRE的本质，我认为是为了平衡生产制造速度过快4而导致最终产品/服务 5质量下降的矛盾。
回到2000年
Google是SRE概念的发明者，并且将实践经验总结成《Site Reliability Engineering》一书。 SRE这个词汇也在这本书出版后流行了起来。
彼时（2000年左右）的Google属于初创公司，雅虎是当时的顶流网站。敏捷开发流行，作为技术起家的Google也同样采用Release early, release often文化，很长时间Google的产品都带有BETA标签。新功能快速迭代和新产品的快速上线有助于Google更快的获得更多用户，占领市场6。
6 这个策略至今在竞争市场上依然有效
快速的迭代和发布，意味着引入更频繁的变更，也意味着系统和服务出现错误的概率会更高。
软件系统或服务经常出错，甚至崩溃/不可用，轻则导致用户流失，市场竞争力下降，造成公司经济损失。重则可能会对公共安全和生命安全造成威胁7。Google当时所面临的是第一种情况，也是现在大多数互联网公司所面临的情况。
7 想想如果控制城市的电网系统或者负责民航的指挥系统出问题会怎样
另一方面，用户规模的快速增长，导致增加更多的硬件资源和支撑型的组件，这又会增加额外的复杂性和不确定性，同样会提升系统或服务出错的概率。
Borg，Kubernetes的前身，就是那时开发的8。
9 2004年，Google IPO
2003年9，正是在这样的背景下，Google的SRE团队成立。我们现在得到的信息是什么？
- 快速迭代和服务质量（可靠）的冲突
- 市场竞争和用户规模的快速增长的压力
在那个时候，还不流行小而美这种不追求规模的创业理念。大家都想变大，Google也是。想要变大就必须在这两者之间寻求一种平衡。 SRE团队要解决的就是高速迭代和高质量服务之间的矛盾。
缓冲
Google选择在这两者之间设置一条缓冲带：当缓冲充足时，让迭代尽可能的快，而当缓冲快要填满时，降低迭代速度，甚至暂停迭代，直到缓冲区有足够的空间，并且给这个缓冲起了一个名字–错误预算（Error Budget）。
The structural conflict is between pace of innovation and product stability, and as described earlier, this conflict often is expressed indirectly. In SRE we bring this conflict to the fore, and then resolve it with the introduction of an error budget.
软件制品的生命周期分两部分：生产和运行。产生阶段通常由产品开发团队负责，部署运行阶段则交由运维团队或者负责。
生产阶段为了更快的推出新功能，往往采用敏捷开发理念，让产品和功能的迭代速度变快。正如上图所描述的，更频繁的变更带来的是服务脆弱的风险。SRE团队则采取”反敏捷”的方式来平衡这种风险。
错误预算让产品每次迭代的质量可度量10，Google通过服务等级目标（SLO）来计算错误预算的数值。这里，错误预算和SLO，以及SLO的下级指标SLI都是为了解决速度和质量矛盾的产物。
10 也基于两个团队对此的共识
缓冲的两侧
左侧，是产品服务的开发侧。右侧，是产品服务的运行侧。
软件工程学科的存在让我们将太多注意力集中在左边，而右边长久以来由松散的脚本和人力经验支撑，直到Google将右边工程化，平衡才得以实现。
非常有趣的是，在有些企业中，当右侧团队尝试用工程思维解决问题时，比如尝试运用数学方法和统计理论构建告警，得到了来自左侧团队的评价是「一个告警而已，搞那么复杂干什么」
更糟糕的情况，左侧团队几乎不使用任何工程化方法和理论进行产品开发工作。
工程化（Engineering），我指的是运用科学理论和数学工具进行产品研发。构建规模化的产品和服务，不能仅仅依靠对编程工具的熟练掌握，更不能期望通过这种方式构建可靠的产品和服务。
SRE之道
寻求创新速度和服务质量间的平衡，正是SRE之道。
实现这种平衡，要求我们采用多种手段11：自动化，数据化，可视化…
11 甚至是文化变革
采用SRE方法之所以困难，一个重要的原因是，我们在进行自动化，数据驱动开发，业务可观测的过程中，常常不记得这么做究竟是为了什么。
Tools were only components in processes, working alongside chains of software, people, and data. Nothing here tells us how to solve problems universally, but that is the point. Stories like these are far more valuable than the code or designs they resulted in. Implementations are ephemeral, but the documented reasoning is priceless. Rarely do we have access to this kind of insight.