下载掌阅APP，畅读海量书库
立即打开
提供产品给用户使用的过程中所产生的资源服务，都属于运维架构范畴，包括客户端、服务器中的所有系统软件。
在打造整个运维架构的过程中，诞生了运维架构师这样的岗位，他们对整个产品所使用的各项资源、服务进行规划，将这些资源、服务进行合理化的维护，最终保障服务的整个生命周期。
笔者曾经见过一个“运维人员如何成为运维架构师？”的帖子。帖子中的回答是：“当运维人员能从开发的角度思考问题的时候，就会成为运维架构师。”在本书中，笔者要对这句话进行补充：“当运维人员能从开发的角度思考问题，并能结合业务给出解决方案时，就会成为运维架构师。”当然运维架构师的岗位职责远比这句话复杂得多，涉及的场景更是变化多端，在这里我们先列举一些运维架构中的常见场景，如果读者感兴趣，也可以在自己所属团队内部实践，形成类似如图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的基建底层。
我们应该都听到过这样一句话，“离开业务谈技术都是耍流氓”。在互联网爆发的那几年，出现了一群技术狂热者，他们每天会花大量的时间研究前沿技术，然后想方设法将这些技术带入团队。笔者并不反对这样的行为，因为笔者也这样干过，但最终妥协了，一方面是因为为了追逐技术所打造的服务，很难保障稳定性，这和SRE任务相悖，另一方面是因为追逐技术的时间成本很高，在业务优先的现阶段，要懂得取舍。当然如果你所在的技术团队人才满满，并且有足够多的人力去钻研，而且公司也愿意为此埋单，这肯定是一件令人兴奋的事情，但如果没有，请回到现实。
笔者这里说的并不是不让团队去突破新技术，而是要在基于业务可以保障SLA的前提下，最大化地发挥技术的价值。
另外，我们也要记住一点，不管我们用什么样的技术实现功能，时间久了都会存在技术债，问题是未来这个技术债是你自己还，还是留给你的“接班人”还。技术方案里没有最好的，只有最适合的，适合什么呢？适合业务，特别是在互联网增量已经减少的现今。
时至今日，笔者很难给自己定义清晰的工作范畴，因此也无法说出SRE和运维的工作边界在哪里，而且笔者也不太想去定义，把自己限制在条条框框里，比如运维人员不应该去开发业务，运维人员也不应该去打造网关平台等诸如此类的想法。
我们会逐步发现，在面对任何问题的情况下，即便是业务问题，我们也能够基于经验和方法论快速整理出一套解决方案，而前提就是我们要将自己的技术和工作经历进行扩展。所以在工作中跨部门的事情越多，多部门共建的事情越多，甚至主导其他部门的事情越多，你就会越发觉得有无限可能，而我们要先给自己明确地不设边界。
图1-2来自《SRE生存指南：系统中断响应与正常运行时间最大化》一书，它是作者Nat Welch基于Mikey金字塔进行微调修改后得到的新金字塔。
图1-2 Mikey金字塔
Nat Welch曾提到过，“这个7层金字塔围绕着沟通设计。每一层都建立在前一层的基础之上。它被沟通所包围，因为每一层都需要沟通才能成功。”
在本书中，我们的运维架构中有部分章节是符合金字塔模型的，一来这是方法论的实践顺序，二来这也是SRE思维自然而然产生的上下文。另外，关于沟通的艺术，我们也有很多地方会讲解到，欢迎感兴趣的读者进行实践，如有问题可以通过公众号“SRE基础架构”找到我们，谢谢！
在理解业务的基础上，给自己的工作不设边界，通过SRE知识逐步地改进运维架构，这会是本书接下来要讲解的核心。热身部分已经完成，欢迎读者继续第2章的阅读。