1.1　运维架构和SRE

在打造整个运维架构的过程中，诞生了运维架构师这样的岗位，他们对整个产品所使用的各项资源、服务进行规划，将这些资源、服务进行合理化的维护，最终保障服务的整个生命周期。

笔者曾经见过一个“运维人员如何成为运维架构师？”的帖子。帖子中的回答是：“当运维人员能从开发的角度思考问题的时候，就会成为运维架构师。”在本书中，笔者要对这句话进行补充：“当运维人员能从开发的角度思考问题，并能结合业务给出解决方案时，就会成为运维架构师。”当然运维架构师的岗位职责远比这句话复杂得多，涉及的场景更是变化多端，在这里我们先列举一些运维架构中的常见场景，如果读者感兴趣，也可以在自己所属团队内部实践，形成类似如图1-1所示的模式。

图1-1　运维架构梳理

如图1-1所示，我们将当前使用的资源梳理出来，这只是我们构建运维架构的第一步，在绝大部分的时间内，运维人员会针对这些资源进行管理，在管理的过程中实现成本、稳定、安全、效率四大使命。

下面我们再来聊聊SRE（站点可靠性工程师），它的核心关注点是生产环境下的服务可用性、延迟、容量和性能，在实现相关目标的过程中，需要利用各种软件来开发工具以达成路径。近几年的互联网公司都开始逐步建立自己的SRE团队，SRE岗位也变得热门起来。

从运维人员和SRE工程师的使命中，我们可以找到很多相同点，这似乎让我们感觉运维人员转型SRE工程师会很轻松，因为从大部分人可以接触到的信息看，运维人员和SRE工程师只差了写代码的工作，只要运维人员拿出部分时间放在写代码这件事情上，就能变成SRE工程师。这和将大象放到冰箱里分3步是一样的：打开冰箱门，将大象放进去，再关上冰箱门……但其实这并非易事，原因很多，比如：

（1）运维人员习惯性地认为自己是最后一道屏障，是“守门员”，不应轻易离开自己的位置，但作为SRE工程师却应该身在前线，基于对前线的理解和认知，打造适合的工具，形成团队共同使用的服务。

（2）运维工作中的脚本能力偏向于完成一个个单体任务，运维人员缺少大型项目开发经验，缺少团队开发的合作经验，并且部分需求的开发涉及高并发场景，如中间件开发，这和SRE工程师所需的开发能力有很大的区别。

（3）SRE是有性能优化指标的，但基于目前运维工作的任务和经验，有精力做性能优化的人实属少数派。

（4）运维人员对图1-1中的资源稳定性建设的看法更多地基于服务的高可用性，而SRE工程师需要对每一个基础设施的业务价值进行更深入的挖掘。比如，运维人员在公有云上开通了HTTPDNS服务，为了承诺SLA（Service Level Agreement，服务等级协议），同时在两个不同的云厂商开通HTTPDNS服务，业务调用时可以进行主备切换。但SRE工程师会更深入一层，会考虑HTTPDNS服务的调用量过大而导致成本增加，于是主动找到客户端开发人员进行协商，讨论HTTPDNS服务返回的数据在客户端缓存多长时间合适，并且将其加入应急预案，如果需要及时清理缓存，有什么手段可以快速生效。

（5）团队氛围不一样，稳定性建设不只是口号，如果运维人员只是将自己的头衔换成了SRE工程师，但工作氛围仍然是运维的氛围，转型效果会很差。

网上其实已经有很多讲解运维和SRE关系的文章了，笔者不会再重复说明。本书的主要目标就是讲解在运维架构整个生命周期的运营中如何加入SRE方法论，并给出一些实践案例，让SRE推进运维架构的改进，让运维架构支持SRE的基建底层。