71 lines
7.9 KiB
Markdown
71 lines
7.9 KiB
Markdown
|
# 10 | 谷歌SRE运维模式解读
|
|||
|
|
|
|||
|
|
前面我和你分享了一些关于运维组织架构和协作模式转型的内容，为了便于我们更加全面地了解先进的运维模式，今天我们再来谈一下谷歌的SRE（Site Reliability Engineer）。同时，也期望你能在我们介绍的这些运维模式中找到一些共通点，只有找到这些共通点，才能更深刻地理解，并借鉴到真正对我们有用的东西。
|
|||
|
|
|
|||
|
|
专栏的第一篇文章我们介绍了Netflix的NoOps模式。这个模式并不意味着不存在任何运维工作，只是Netflix将这些事情更紧密地融入到了日常的开发工作中，又做得非常极致，所以并没有很明显地体现出来。
|
|||
|
|
|
|||
|
|
但是，谷歌的SRE却是一个真实具体的岗位，也有明晰的岗位职责。从借鉴意义上来讲，SRE可以给我们提供更好的学习思路和样板。
|
|||
|
|
|
|||
|
|
SRE这个概念，我应该是2014年下半年的时候听到的。当时可接触的资料和信息有限，只知道是谷歌对运维岗位的定义，负责稳定性保障，就没有更多其他的认识了。
|
|||
|
|
|
|||
|
|
后来，有越来越多在谷歌工作或接触过这个岗位的专家开始在公开演讲中分享这个概念。同时，《SRE：Google 运维解密》，这本由多名谷歌SRE亲笔撰写的图书也开始在国内广泛流传，让我们对很多细节有了更加细致的了解。
|
|||
|
|
|
|||
|
|
## SRE岗位的定位
|
|||
|
|
|
|||
|
|
首先，SRE关注的目标不是Operation（运维），而是Engineering（工程），是一个“**通过软件工程的方式开发自动化系统来替代重复和手工操作**”的岗位。我们从SRE这本书的前面几个章节，可以看到谷歌不断强调SRE的工程能力。我简要摘取几段：
|
|||
|
|
|
|||
|
|
> Common to all SREs is the belief in and aptitude for developing
|
|||
|
|
> software systems to solve complex problems.
|
|||
|
|
> 所有的SRE团队成员都必须非常愿意，也非常相信用软件工程方法可以解决复杂的运维问题。
|
|||
|
|
>
|
|||
|
|
> By design, it is crucial that SRE teams are focused on engineering.
|
|||
|
|
> SRE模型成功的关键在于对工程的关注。
|
|||
|
|
>
|
|||
|
|
> SRE is what happens when you ask a software engineer to design an
|
|||
|
|
> operations team.
|
|||
|
|
> SRE就是让软件工程师来设计一个新型运维团队的结果。
|
|||
|
|
|
|||
|
|
与之相对应的，还有一个很有意思的地方，整本书中提到Operation的地方并不多，而且大多以这样的词汇出现：Operation load，Operation overload，Traditional/Manual/Toil/Repetitive Operation Works。你可以仔细体会一下，这些大多就是传统的纯人工操作模式下的一些典型词汇。
|
|||
|
|
|
|||
|
|
我们可以看到，从一开始，谷歌就没把SRE定义为纯操作类运维的岗位，也正是**谷歌换了一个思路，从另外一个维度来解决运维问题，才把运维做到了另一个境界**。
|
|||
|
|
|
|||
|
|
## SRE岗位的职责
|
|||
|
|
|
|||
|
|
书中对SRE的职责定义比较明确，**负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作**。如果站在价值呈现的角度，我觉得可以用两个词来总结，就是“**效率**”和“**稳定**”。
|
|||
|
|
|
|||
|
|
接下来，详细说下我的理解和分析。
|
|||
|
|
|
|||
|
|
SRE的能力模型，不仅仅是技术上的，还有产品设计、标准规范制定、事后复盘总结归纳这些技术运营能力，同时还需要良好的沟通协作能力，这个就属于**职场软技能**。
|
|||
|
|
|
|||
|
|
SRE，直译过来是网站稳定性工程师。表面看是做稳定的，但是我觉得更好的一种理解方式是，**以稳定性为目标，围绕着稳定这个核心，负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作**。
|
|||
|
|
|
|||
|
|
分解一下，这里主要有“管理”和“技术”两方面的事情要做。
|
|||
|
|
|
|||
|
|
* **管理体系上**，涉及服务质量指标（SLI、SLA、SLO）、发布规则、变更规则、应急响应机制、On-Call、事后复盘机制等一系列配套的管理规范和标准制定等。
|
|||
|
|
* **技术体系上**，以支持和实现上述标准和规范为目标，涉及自动化、发布、监控、问题定位、容量定位，最终以电子流程串联各个环节，做到事件的闭环。
|
|||
|
|
|
|||
|
|
可以看到技术上的平台和系统是用来支撑管理手段的。谷歌的运维其实并没有单独去提自动化、发布、监控等内容，而是通过稳定性这个核心目标，把这些事情全部串联在一起，同时又得到了效率上的提升。
|
|||
|
|
|
|||
|
|
我们来看几个主要的系统。
|
|||
|
|
|
|||
|
|
* **自动化**。是为了减少人为的、频繁的、重复的线上操作，以大大减少因人为失误造成的故障，同时提升效率。比如谷歌内部大名鼎鼎的Borg系统，可以随时随地实现无感知的服务迁移。现在，它的开源版本，已然成为业界容器编排体系标准的Kubernetes。
|
|||
|
|
* **持续交付**。谷歌非常重视持续交付。由于它的需求迭代速度非常快，再加上是全球最复杂的分布式系统，所以就更加需要完善的发布系统。
|
|||
|
|
* **问题定位**。这块跟监控相关但又有不同。我看到谷歌SRE这本书中并没有提到太多Tracing的内容，更多的是讲监控和问题管理层面的跟踪机制。其实，关于问题定位，谷歌的Dapper大名鼎鼎，功能很强大，国内外很多跟踪系统和思路都参考了Dapper的理论。这块也是为了能够快速定位问题，保障稳定而产生的，国内分享的大多关于全链路跟踪和分析、限流降级、开关和预案系统、强弱依赖等都属于这个范畴，我认为这块应该更准确地定义为分布式服务治理相关的内容。
|
|||
|
|
* **各类分布式系统**。如分布式锁、分布式文件、分布式数据库，我们熟知的谷歌三大分布式论文，就是这些分布式系统的优秀代表，也正是这三大论文，开启了业界分布式架构理念的落地。
|
|||
|
|
|
|||
|
|
这些系统大都是以稳定性为导向，同时带动了日常运维效率的大幅度提升，有了监控和全链路这样的问题发现和定位手段，也大大提升了我们对故障处理和问题定位的效率。容量管理，不仅仅可以保障容量充足，还能最大程度地保障资源分配的合理性，尽可能减少浪费，对于成本管控也大有好处。所以，围绕着稳定性这个核心目标，不仅达到了稳定的目的，还获得了高效的运维效率。
|
|||
|
|
|
|||
|
|
所以，SRE的理念通过稳定性这个核心点，将整个运维体系要做的事情非常系统紧密地整合起来，而不是一个个孤立的运维系统。所以，**SRE是一个岗位，但更是一种运维理念和方法论**。
|
|||
|
|
|
|||
|
|
## 如何借鉴和落地
|
|||
|
|
|
|||
|
|
在国外，SRE岗位的薪资，和SWE软件开发工程师相比，要平均高出25%。从实际的岗位要求上看，SRE的技能要求也要比SWE更高、更全面，所以这样的人才是比较紧缺的。即使在国外，除了谷歌、Facebook以及Netflix这样超一流的科技公司能够招聘到，或者内部培养出较多这样的人才，其它公司的SRE、PE或者应用运维也无法完全达到上面的要求。
|
|||
|
|
|
|||
|
|
在国内，就更难一些，那怎么做呢？一个思路就是我们之前讲组织协作模式转型时提到的，就是要依靠团队的力量、发挥团队的力量，如果是单个团队不能完成的事情，就跨团队协调完成。所以，SRE岗位的要求很高，但是我们可以靠团队中具备不同能力的人协作，共同达成SRE的职责和目标。
|
|||
|
|
|
|||
|
|
最后，还是我反复强调的观点，**要想做好运维，就得跳出运维的局限，要站在全局的角度，站在价值呈现的角度，站在如何能够发挥出整体技术架构运维能力的角度，来重新理解和定义运维才可以**。
|
|||
|
|
|
|||
|
|
通过今天的内容，你对于SRE有什么新的理解或者疑问？结合前面的内容，你能够挖掘出哪些共通点呢？欢迎你留言与我讨论。
|
|||
|
|
|
|||
|
|
如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
|
|||
|
|
|