职业探索--运维体系-SRE岗位/CRE岗位/运维岗位-服务心态-运维职业发展方向-运维对象和运维场景

参考来源：
极客时间专栏：赵成的运维体系管理课
极客时间专栏：全栈工程师修炼指南
赵成大佬在鹏讯云社区的文章（77篇）
有了CMDB，为什么还要应用配置管理
故障没有根因，别再找了
如何理解CMDB的套路
故障复盘的简洁框架-黄金三问
数据中心运维管理方案（超详细）–数据中心场景的运维工作场景
https://www.uwintech.cn/2 --EasyOps一站式运维平台，关于运维专业化公司(优维科技)的介绍
关于 SRE 这个角色，你可以参看 Google 自己的描述，以及 SRE 这个词条

运维的组织架构

从实际的人员管理以及技能维度来划分的话，互联网公司的运维团队差别不大，基本会分为如下几个岗位：
基础运维，包括 IDC 运维、硬件运维、系统运维以及网络运维；
应用运维，主要是业务和基础服务层面的稳定性保障和容量规划等工作；
数据运维，包括数据库、缓存以及大数据的运维；
运维开发，主要是提供效率和稳定性层面的工具开发。

这个实体的组织架构，相当于是从技能层面的垂直划分。
基础运维更擅长硬件和操作系统层面的运维；
应用运维可能更擅长业务稳定性保障、疑难问题攻关以及技术运营等；
数据运维就不用多说了，DBA 本身就是专业性极高的一个岗位；
运维开发则是支持上述几个岗位日常运维需求的，是否能将人力投入转换成工具平台支持，就看这个团队的能力。

SRE岗位

书籍：《SRE：Google 运维解密》
SRE 关注的目标不是 Operation（运维），而是 Engineering（工程），是一个“通过软件工程的方式开发自动化系统来替代重复和手工操作”的岗位。我们从 SRE 这本书的前面几个章节，可以看到谷歌不断强调 SRE 的工程能力。

书中对 SRE 的职责定义比较明确，负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作。如果站在价值呈现的角度，我觉得可以用两个词来总结，就是“效率”和“稳定”。

SRE 的能力模型，不仅仅是技术上的，还有产品设计、标准规范制定、事后复盘总结归纳这些技术运营能力，同时还需要良好的沟通协作能力，这个就属于职场软技能。

SRE，直译过来是网站稳定性工程师。表面看是做稳定的，但是我觉得更好的一种理解方式是，以稳定性为目标，围绕着稳定这个核心，负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作。

分解一下，这里主要有“管理”和“技术”两方面的事情要做。

管理体系上，涉及服务质量指标（SLI、SLA、SLO）、发布规则、变更规则、应急响应机制、On-Call、事后复盘机制等一系列配套的管理规范和标准制定等。
技术体系上，以支持和实现上述标准和规范为目标，涉及自动化、发布、监控、问题定位、容量定位，最终以电子流程串联各个环节，做到事件的闭环。

–
SRE（Site Reliability Engineer，网站可靠性工程师），这个角色最早很可能是 Google创造出来的，从名称上也可以看出，这个职位的工程师所致力于解决的问题，就是网站可靠性的问题，这里的“可靠性”，包括可用性、延迟、容量等多个方面。

在“时间就是金钱”的压力环境下，严谨而大胆，快速定位和解决问题，但更重要的是，帮助不同的团队“防患于未然”，比如主导和把关新建服务的可靠性设计。SRE 有时要解决基础设施的问题，有时要分析服务端的压力来源，有时则要搞定网页上造成大量用户访问困难的“小 bug”。很显然，一个狭窄领域知识的工程师，是不可能胜任这样的岗位的，对于从端到端俯瞰整个流程的能力，Web 全栈工程师有着天然的优势。

CRE 岗位

CRE（Customer Reliability Engineering），直译过来就是客户稳定性工程师。

CRE 出现的根本目的，就是消除客户焦虑，真正地站在客户的角度去解决问题，同时对客户进行安抚、陪伴和关怀。

通常的售后支持，都是你问什么问题，我就回答什么问题，能马上解决的就马上解决，不能解决的就转到后端处理，然后让客户等着，承诺多长时间内给出答复。这种流程标准，严格执行 SLA 规范，对于一般问题还好，但要是真的出现大问题就不行了。

CRE 这个角色一定是站在客户角度解决问题。加入客户的“作战室”（War Room），和客户一起排查，问题不解决，自己不撤退；还会随时通报进展，必要的时候会将故障升级到更高的级别，寻求更专业的资源投入以共同解决；同时根据客户的不同反应进
行不同方式的安抚。

CRE 还会发挥谷歌多年积累下来的非常宝贵的线上运维经验，在日常就跟客户沟通传递一些稳定性保障的知识。
CRE 可以按照谷歌总结出来的类似 SRE 的标准规范，对客户线上系统进行稳定性标准评审，并给出专业的建议。如果客户同意遵守这样的标准规范执行，在后续出现故障时，CRE 就完全可以按照非常成熟的 SRE 的运作模式去协作用户处理故障，这样就会大大提升 CRE 和客户的协作效率，为故障快速处理赢得更多宝贵时间。同时 CRE 也可以发挥更大的专业作用，而不是之前的对客户系统不熟悉，空有一身绝世武功，却使不上劲。

服务心态

总结了一下，是不是有服务心态，表现在我们的做事方式上，就是我们是否能够站在对方的角度考虑问题、解决问题。

1. 多使用业务术语，少使用技术术语

与合作部门沟通协作，特别是对于非技术类的业务部门，尽量多使用业务语言来表达。在讨论一个需求时，如果表达的都是 API、缓存、数据库、消息队列等等这些专业术语，估计业务部门的同学肯定是跟不上我们的思路的，这样的沟通通常无法正常地进行下去，所以就会
经常出现业务同学说业务的事情，技术同学说技术的事情，两边不能达成一致，矛盾就产生了。

技术是实现业务功能的一种手段和方式，所以一定是从业务角度出发考虑技术解决方案，而不是从技术角度出发让业务来适配技术。

尝试用业务语言去沟通，用对方能够听得懂的表达方式去表达你的技术观点。为了让业务人员理解你的想法，就自然会用业务的思路去思考和解决问题了。这个需要一点点改变，可以先从尝试开始。

2. 学会挖掘问题背后的真正诉求

外部提出的一个问题，可能并不一定是真正的问题，而是问题的一个解决方案。
遇到类似问题，可以不着急动手做，先多问自己和对方几个问题，比如：
为什么要这样做？
谁要求做这件事情的？
这样做的目的是什么？
这样做是为了解决什么问题？

这一点其实也是站在对方角度去考虑，去思考对方要解决的问题是什么，而不是解决我们的问题。通常情况下，两三个问题后，一般就会暴露出背后最原始的那个需求了。正所谓“磨刀不误砍柴工”，问题和背景搞清楚了，思路和方案就是顺其自然的事情了。

3. 解决问题的时候关注目标，而不是聚焦困难

两种不同的思考问题的方式，带给人的感受也是完全不一样的。

随着云计算技术的深入发展，公有云事业也不断拓展，运维领域的分工也在不断地精分细化，而每个细分领域对专业技术的要求也越来越高，专业的服务化程度也越来越高。我想这是一个好现象，让原来非常模糊的运维行业范畴变得越来越清晰、越来越具体。
一方面我们要不断提升自己的技术能力，另一方面也要注意自身服务意识的培养，让自己的能力得以发挥，创造更大的价值，获得更好的回报。
所以，CRE 这个角色，既具备良好的专业技术能力，又有非常强的问题解决能力，同时还要具有优秀的客户沟通和关怀能力。

运维职业发展方向

1.一线维护

这个团队是负责产品的交付服务和后续的客户服务工作。从技能上，很像传统运维，主要是对网络设备、硬件主机和操作系统层面要熟练。一方面要负责交付的项目管理；另一方面，也是非常重要的一点，要对一线客户满意度负责，也就是客户反馈的所有问题，甚至是客户工作中表现出来的喜怒哀乐都要关注。

一线维护，最重要的就是必须要有非常强的服务意识。

2.二线技术支持

因为一线维护面对的是单个具体的运营商，在遇到一些问题的时候，往往没有经验，但是二线因为要面对某个产品全球的局点问题，所以在经验上更容易沉淀和积累。当某个一线团队遇到没有经验的问题时，二线有可能就可以很快很好地帮忙解决，而不用直接透传到三线。
同时，二线还要做好统筹协调，因为一线过来的问题不仅仅是产品本身问题，也可能是网络设备、硬件、操作系统、存储甚至数据库等的问题，这就需要二线帮助一线协调专家资源进行处理，而不是一线再一个个找人，这时一线只管反馈问题即可。

二线技术支持，大多由产品研发或者一线维护经验的人员抽调上来的，即使没有这些经验，也要下放到一线去锻炼很长时间，两三年都有可能，所以技术和经验上都相对更加全面，同时能够有较强的推进协调能力。

3.三线研发维优

到了三线就是研发团队中的运维团队了，这个团队在华为叫做维优团队。这个团队就很牛了，一般都是从开发骨干精挑细选出来的，一方面是为了锻炼人，另一方面也是为了在出现问题时，能够有最专业、能力最强的人响应处理，因为电信级业务是国计民生的基础设施，
一般传递到三线的问题，都是比较严重或者疑难的了，必须投入精兵强将第一时间解决问题。

处理问题的过程中，还会不断完善工具体系，提升日常维护和问题定位的效率。因为三线同样要面对全球局点问题，所以 7*24 响应，而且常年无休，比我们现在互联网运维的工作负荷要大得多，所以这个团队成员一般做个 1~2 年就会转岗晋升，不然身体肯定是承受不住的。

三线研发维优，这个团队的成员就像军队中的突击队或尖刀连一样，总是冲在最前面，在高压状态下，解决最复杂、最棘手的问题，所以从选拔阶段，就有非常高的要求。最终经过这个团队磨练出来的人，技术能力、沟通协作能力以及全面解决问题的能力，都是非常突出的。自然地，在晋升发展方面就会有更大竞争优势。

这里我们不做过多发散，理解下来就是谁离客户最近，谁对客户负责，谁就能代表客户，谁就有最大的话语权，甚至是指挥权和决策权。体现在上述我们所说的运维机制上，就是：一线的声音，代表了客户声音；一线反馈到二线的问题，二线必须响应；二线传递到三线的问
题，三线必须响应。

客户第一

当然，问题级别不同，响应效率可以不同。同时，三线可以根据客户现场情况，以及问题严重程度，对问题进行升级，以知会到更高层级的主管进行关注。

在考核上，如果一线提交的问题，最终被定性为二线支持问题，或者三线研发质量问题，那二、三线的全年考核将会受到影响，如果是频繁出现问题，那就会受到严重影响，而且各级主管要承担连带责任。

这套机制的根本目的，还是为了促进整个体系能够以尽快解决问题、提升软件质量为目标。整个团队树立起这样的观念，就自然会对质量和问题有敬畏感，研发维优那个时候大多都是远程电话与一、二线沟通，潜意识里就会把一、二线作为他们的客户，同样保持谦卑和尊重。

从价值呈现的角度看运维岗位

运维能力的体现,一定是整体技术架构能力的体现。所以，要想做好运维就一定要跳出运维这个框框，从全局的角度来看
运维，要考虑如何打造和体现出整个技术架构的运维能力，而不是运维的运维能力。这一点是根本，一定要注意。如果我们仍然片面地从运维的角度看运维，片面地从运维的角度规划运维，是无法走出运维低价值的困局的。

当我改变了这个认知后，我的出发点就回归到了效率、稳定和成本这三个对于研发团队来说最重要的目标上来。从运维的角度来说，能够与这三个点契合的事情，我总结了以下五个。

1. 运维基础平台体系建设

这块主要包括我们前面提到的标准化体系以及 CMDB、应用配置管理、DNS 域名管理、资源管理等偏向运维自身体系的建设。这一部分是运维的基础和核心，我们前面讲到的标准化以及应用体系建设都属于这个范畴。

2. 分布式中间件的服务化建设

在整个技术架构体系中，分布式中间件基础服务这一块起到了支撑作用。这一部分的标准化和服务化非常关键，特别是基于开源产品的二次开发或自研的中间件产品，更需要有对应的标准化和服务化建设。这也是我们无意识地割裂运维与技术架构行为的最典型部分，这里容
易出现的问题，我们前面讲过，你可以回去再复习一下。

3. 持续交付体系建设

持续交付体系是拉通运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分。这个部分是整个软件或应用的生命周期的管理体系，包括从应用创建、研发阶段的持续集成，上线阶段的持续部署发布，再到线上运行阶段的各类资源服务扩容缩容等。开发和运维的矛
盾往往比较容易在这个过程中爆发出来，但是这个体系建设依赖上面两部分的基础，所以要整体去看。

4. 稳定性体系建设

软件系统线上的稳定性保障，包括如何快速发现线上问题、如何快速定位问题、如何快速从故障中恢复业务、如何有效评估系统容量等等。这里面还会有一些运作机制的建设，比如如何对故障应急响应、如何对故障进行有效管理、如何对故障复盘、如何加强日常演练等等。同样，这个环节的事情也要依赖前两个基础体系的建设。

5. 技术运营体系建设

技术运营体系也是偏运作机制方面的建设，最主要的事情就是确保我们制定的标准、指标、规则和流程能够有效落地。这里面有些可以通过技术平台来实现，有些就需要管理流程，有些还需要执行人的沟通协作这些软技能。

最终通过这样一个规划，我把团队以虚拟形式重新规划了不同职责，分别负责基础平台体系、分布式中间件服务化体系、持续交付体系和稳定性体系，基本就是上述的前四件事情。

对于最后一个技术运营体系，这一点作为共性要求提出。我要求团队每个成员都要具备技术运营意识。
具体来说，就是要能够有制定输出标准的意识和能力，
能够有规范流程制定的能力，同时能够将标准和流程固化到工具平台中，最后能够确保承载了标准和规范的平台落地，也就是平台必须可用，确实能给运维团队或开发团队带来效率和稳定性方面的提升。这些对个人的要求还是比较高的，要有一定的规划、设计和落地能力，能具备一整套能力的人还是少数，目前这块还是靠团队协作来执行。