大家好，这里是作业帮技术团队。欢迎接收我的第30次推送，以下是今日的内容。

出品 | 作业帮基础架构团队

 要点简述 

• 运维思路：明确运维对象，从服务全生命周期出发，划分阶段，提炼关键点，构建运维场景，沉淀运维平台。

• 稳定体系：崇尚从“三位一体”体系上解决问题，故障预防远比故障应急更为有效。通过标准化建设、容器部署、服务治理、规范变更、多活架构、防控裂变等手段，延长MTBF时间以达到高稳定诉求。若预防环节拦不住，就拥抱故障处理方法论，通过预案、监控定位、机制等手段最大化缩短MTTR时间。

• 转型探索：云原生对岗位冲击很大，需要提升岗位认知，健全能力模型，重视运维能力服务化，用工程化方法全新定义和重构运维，深度拥抱开源，力求共性运维。

背景介绍

1.技术概况

作业帮业务大体可分为几种类型，有工具场景，有电商场景，有在线直播场景，有智能硬件场景等。这些业务背后，服务数量已达数千级别，NS数量已达上百级别，域名数量已达数千级别，节点数量已经上万级别。此外，技术栈也遍地开花，语言多达近十种类，主流开发语言是Go和PHP。在如此规模化的业务背后，有两大技术底座支撑，一个是以容器技术和服务治理为代表的云原生架构，另一个是以专线组网构建公有云多云多活的运维架构。

2.团队分工

怎样高效运维这样量级的业务？先看基础技术的团队分工，自底向上，按IaaS，PaaS，SaaS类型进行划分，最底层IaaS主要负责向上提供计算、网络、存储等资源；中间PaaS，切为三块，有以数据存储、消息队列等为主的中间件服务，有以容器技术和服务治理为主的云原生架构服务，有以真合规为目标的安全服务；再往上就是业务应用，有流量、营销、直播、中台支撑等。这些不同分工背后，自然就衍生配套的运维岗位，最底层的IaaS，衍生了CloudOps、NetOps和FinOps，中间件服务衍生了MiddleOps，云原生架构衍生了InfOps，安全服务衍生了SecOps，业务应用衍生了SRE。

运维实践

谷歌把服务生命周期划分为五个阶段。它认为，从 Idea 确定那一刻，服务就诞生了，然后进行架构设计，接着进行开发，再灰度/全量放量，最后到该服务弃用，终结生命。转化到运维视角来看，在架构设计阶段，就开始进行标准化建设；在开发阶段，就开始进行服务准入；在放量阶段，就开始进行持续交付和持续运营；最后就是服务下线。服务生命周期几个阶段中，我们是怎么介入运维的？

标准化建设

关键思路表现为：

1. 规范前置：强制植入运维规范和架构规范，力求共性运维、架构归一、开箱即用，力求通过标准规范来挡住大面稳定性问题。

2. 架构重塑：践行云原生架构理念，以业务服务为中心，让业务聚焦价值、敏捷交付，通过容器技术磨平底层资源差异，通过服务治理磨平多云环境差异。

关键实践表现为：

1. 偏向运维：服务归一，主要进行混部解除和域名拆分，虚机时代，为了提升资源利用率，大量服务混部在一起，给运维带来灾难性的麻烦，比如混部态下，ODP服务间上线互相干扰，没法按服务维度精准封线和权限管控，没法进行精准容量评估等。

域名拆分，就是从www公共域名拆分出来，让每个业务拥有独立域名，方便南北向流量调度和容器化迁移。部署归一，主要定义部署环境规范，把发布环节分为Tips（预发）、Small（灰度）、Online（全流量）三个烟囱式生产环境，并要求它们代码同构、配置同构、路由同构和环境同构。若用CD平台部署，代码同构很容易搞定，配置同构则稍有复杂，我们借助服务发现特点，把配置异构细节隐藏到服务发现背后实现，让它对业务透明。

网络归一，主要把专线接入点归一到IDC POP点，物理专线归一到传输专线，网络探测协议归一化到BFD协议，QoS控制归一化到CPE等。机型归一，主要收敛到主流通用机型，并借助容器部署磨平机型差异，同时不让SaaS业务触摸到机器，避免合规风险。

2. 偏向架构：服务发现归一，主要把东西向服务发现归一化到SVC，南北向服务发现归一化到DNS。早期服务发现使用BNS，后来演化到ZNS支持多云能力，它俩都属于大中心式架构，再后来演化到当前SVC模式，一改往日风格，从中心式架构模式转变到集群内自治的服务发现模式，避免云间互为影响。框架归一，主要收敛PHP框架到ODP，Go框架归一化到ZGIN框架。组件归一，就是自建关键组件服务，并让它们类型归一，比如去MemCache、去NMQ等。大数据组件采买云PaaS服务。通信归一，主要使用统一的标准通信协议，比如HTTP，TCP等，去业务自定义的协议。

服务准入

服务准入阶段，主要思路是让业务做选择题，不要让他们做填空题。同时给业务建立标准化理念，才能享用开箱即用的配套运维服务。

持续交付

持续交付概念略做泛化，它覆盖到所有变更交付场景，包括业务变更和运维变更。主要思路：

1. 拥抱方法论。变更方向，业界方法论比较成熟，严格按照变更五条军规抄作业就可以。

2. 重构变更面。引入主责思路，划分工作边界，变革合作方式，把带有业务逻辑的变更下移到业务，把运维属性的变更上移到运维。

3. 交付平台化。运维变更也是引发故障的变量，变更方式上最好不要依赖人的专业性，而是通过平台沉淀军规/SOP，让SRE都可以低成本操作和互备。

关键实践主要体现在业务更变和运维变更上。

1. 业务变更。代码变更，有敏捷发布和瀑布流发布模式，敏捷发布主要给ToC业务，瀑布流发布略偏传统，主要给ToB业务，它们往往需要积攒一个周期的代码，然后集中一个时间窗口一次性发布，并在灰度环境观察一段时间，没问题后再放全量。配置发布，集成到CD流程，并从集中式配置推送，重构到按服务粒度进行推送。任务发布，引入审批环节，质量把关后再上线。数据存储变更主要通过DBA工单平台进行交付。

2. 运维变更。主要有机器交付，节点交付，域名交付，EIP/LB交付，路由交付，容量交付，作业交付，预案交付，迁移交付，组件交付，非标交付等。除了EIP/LB这种多云异构大，以及非标交付外，我们基本都具备了工单平台交付能力，让业务提单，SRE聚焦审批把关。标准化建设之后，变更质量大有好转，但微服务拆分后，运维需求频次也随之增涨，工单平台化有效提升运维交付效率，少数几个SRE就可以满足全业务的需求。

持续运营

稳定性建设大体可分为业务质量，架构归一和运维管控三部曲，每个维度背后都有各自对应的若干服务。

通常，业务若想更快迭代起来，其实是需要架构进行很好的服务治理；同时，业务若想更稳迭代起来，其实是需要运维进行优雅的管控；运维也要通过技术手段多盯架构，防止架构裂变造成稳定性问题；架构也需要多加考虑，怎样设计以及演进才不会导致运维失控。

除此之外，不管是业务，运维，还是架构，若想要稳定性能力得到极致提升的话，背后都需要进行标准化建设。当然，这些还不够，从底层逻辑出发，让业务聚焦价值，我们还要变革全新合作方式。从运维角度看，把带有业务逻辑的事情下移到业务，比如配置发布、任务发布、接入层掺杂的业务逻辑下移等。从业务角度看，把非业务逻辑的事情，左移到架构，比如服务发现、统一鉴权、流量调度等。从架构角度看，把ToC控制面上移到运维，比如容量管理、流量调度等，总不能让业务直接穿透运维管控直撸我们的容器吧。最后，这三者之外，还有一个威力巨大的组织建设，才能够确保刚才讲的事情良性运转起来。

这就是作业帮三位一体的稳定性体系，如下图所示。

磨合出以上体系之后，我们自然就产生这样的运营思路。

1. 强化主责意识，明确服务提供方责任主体，业务问题回归到业务，运维问题回归到运维，架构运维回归到架构，各找各妈，各回各家。

2. 强化平台理念，避免运动式重复人肉投入，注重沉淀可持续运营能力，我们认为平台是最能看懂和最易传承的方式。

3. 强化数据驱动，建立多维度运营平台，开放数据分析能力，将运营问题归属到责任方，并善用TC威力，驱动整个体系持续优化演进。

持续运营 - 多活架构

多活架构建设，属于业界老话题，任意一个中大厂都会或深或浅卷入其中。从业界来看，多活已有成熟方法论，但缺乏成熟的标准指导。很多人善于把多活架构从0到1建好，但往往运营不善，最终功亏一篑。这里主要从运营面，讲讲我们不一样的打法。

1. 固化运营能力，构建多活信息化平台，结合运营场景沉淀多维度运营数据，逐渐脱离人肉重复投入，让它具备可持续的运营价值，并安全ToC。

2. 健全跨云观测，深入业务，摸清业务代码和配置特点以及服务依赖行为，结合跨云专线CPE流量特点和内核eBPF的建连数据，建立跨云观测能力，感知跨云流量详情。

3. 云间常态断网，挺进无人区，强势落地多云间常态断网，力求从根上解决问题，防止非标问题新增或者多活架构裂变，并建立多云度量视角，约束架构行为，引导业务改造。

4. 独立视角验收，引入混沌工程思想，安全打破其爆炸半径规范之说，从线上进行全局单云故障注入演练，并且引入QA视角，让他们从用户角度客观验收多活能力。

持续运营 - 预案平台

前面提到，标准化建设、服务准入、持续交付和多活架构，主要从故障预防层面，狠下功夫，多管齐下，力求延长MTBF时间来达到高稳定性诉求。若预防环节拦不住，接下来就要想尽办法缩短MTTR时间。

有多活架构之后，怎样放大它的价值，预案就是最好的切入点。我见证过不少中大厂对预案的定义模糊不清，掺杂太多业务属性，最终运维都不敢操作，所以有必要对预案进行全新定义和重构。

1. 预案定义：预案是高度固化的复杂操作集合体，底层需要复杂技术支撑，最终需要抽象为一键盲切的能力。不要遇到故障的时候给操作人太多决策思考和使用成本，谁值班谁就有能力无脑操作。

2. 预案边界：预案最好不要带有业务逻辑，若有，就把它下移到业务层实现。

3. 预案稳定：预案属于强控制面，它的稳定性需要比业务的稳定性还要高，数据存储需要单元化多主部署，且不允许有循环依赖，尤其是入口账号体系的依赖。

4. 预案编排：预案不光是高度固化的复杂操作集合体，它也可以带有技术含量，我们引入编排思想，将原子预案编排为场景预案和全局预案，最后把业务预案、运维预案、自定义预案的差异磨平，一键操作。自定义预案是技术亮点，它把自定义的命令、脚本、或者其他复杂API调用沉淀到git仓库中，然后通过作业平台固化其操作方法，最后编排到场景预案进行打平，达到一键盲切效果。

持续运营 - 流量调度

运维聚焦在南北向全局的流量调度，架构聚焦在东西向长尾流量调度，业务聚焦在特征流量调度，比如按lesson进行分流。调度对象是域名，从公网入口开始调度，流量一旦进入本云之后，单云闭环，除底层数据存储之外，不允许有跨云流量请求。调度方式有两，一种是DOH按权重进行精准调度，另一种是DNS按解析线路进行非精准分流调度。

持续运营 - 监控定位

监控告警偏向上层运维，问题定位偏向服务可观测，怎么合二为一为我所用？

1. 建基础，按可观测三个黄金指标进行切入。标准化建设之初，约定日志规范，产出4个场景8类日志，固化到框架中。指标采集主要是基础指标、服务指标和业务指标。链路注册，主要在入口生成或者透传链路ID，在Mesh统一注册链路相关的信息，让业务低成本接入，开箱即用。

2. 搭中台，日志中心，我们摈弃传统ELK烧钱方案，而是根据日志场景写多读少的特点，巧妙地自建分块存储和冷热数据分离的多级数据存储方案，支撑业务半年以上优雅日志检索。链路追踪主要拥抱开源工具Jaeger。监控中台主要使用普鲁米修斯Victoria Metric方案，结合Grafana和OpenFalcon一起用。

3. 造场景，首先建立服务视角，让业务聚焦服务价值。第二建立运维宏观定位和问题排查视角，上能宏观定位，下可微观排查。同时，几千个服务监控报警，若眉毛胡子一把抓，就容易失焦，这时我们就要对它区别对待，联动服务等级元数据，以达到收敛监控和报警关注面。最后就是对它进行红绿灯建模打分，构建全局视角。

产品形态如下图所示，第一个就是宏观定位大盘，从大盘飘红的地方，可以下钻到异常服务详情，从服务详情站位，可以快速下钻到Mesh入向调用详情、出向调用详情、以及失败链路调用详情，也可以横向钻到服务容量和变更事件等。

持续运营 - 容量监控

容量监控和业务监控思路类似。它覆盖到CPU&GPU算力，容器宿主容量，云主机容量，子网IP容量，专线带宽容量，VPN容量等。

持续运营 - 其他运营

报警层面，构建全局通用服务报警大盘，力求扮演好故障第一跳角色，同时把未恢复和近期报警做一个快捷查询，方便支撑全局决策。权限运营主要感知关键权限点的异动，防止因运维失控，造成越界授权和越界操作。变更管控主要围绕五条军规落地。

环境变化

为何能在短时间建成这样体系和能力？主要有四大环境变化，它们互相关联，互相驱动。

1. 领域变化，当前云原生技术已经高度成熟，业界实践如火如荼。

2. 内部变化，技术团队务实，按照云原生理念进行架构重塑，屡试不爽。

3. 行业变化，互联网红利逐渐消退，也正因为这样，业务才有时间静下心来修炼内功。

4. 组织变化，强势老板带队，自上而下，由表及里，推崇技术信仰，践行主责文化。

也正因为这四个变化，同时也给SRE带来前所未有的冲击，倒逼我们深度思考，转型探索。

1.岗位思考

从团队分工可看出，每个运维角色背后都有自己的主营服务，唯独业务运维，它不是业务服务的提供方，而是依附业务，无限延伸和放大业务的价值。长期下去，容易演变为一个横向支持团队，大大弱化SRE方向的专业性。因此，运维服务化呼之欲出。

再回归初心，看看SRE的内在定义，它是Site Reliability Engineering首字母缩写，最后一个单词强调工程化而非工程师，关键点在于用工程化的思路和方法来定义和重构运维，让运维更加自动化，更加服务化，而不是狠砸工程师原地重复挖坑。

传统运维偏向被动执行，不出问题就好，作风求稳，重流程规范和SOP。云原生时代的运维，更强调构建业务数据度量业务风险，给出标准化解决方案建议，并主动作为，善于把流程规范和SOP固化到架构或者平台中去。

最后要认清SRE的岗位职责，让业务高效迭代，让业务稳定运行。

2.能力探索

对岗位有全新的认知之后，再看看云原生时代，SRE需要具备什么样的能力模型。我觉得主要有四点：

1. 产品能力：特别强调一下，并不是让每个SRE都成为人人都是产品经理，而是有意识地把工作痛点转化为产品若干功能需求点，而不是坐地抱怨，因为SRE是距离线上环境和稳定性问题最近的团队。

2. 开发能力：SRE也是技术工种，显然需要开发能力。纯粹依靠DEV/架构不靠谱，远水救不了近火，缺乏开发能力，就不能把事情精细化地做好。若大家都做开发，那跟DEV有何区别？边界在于DEV搭中台，SRE依托中台建场景。

3. 运营能力：要求有意识地使用已有工具体系或者建设工具进行技术全方位运营，善用数据说话。

4. 拥抱开源：身处云原生时代，可能以上三个能力都具备之后，开源已经做得很完美了，这时候需要打开眼界，真心拥抱开源，融合开源产品，低成本应用到运维实践中。

3.方向探索

能力模型具备之后，如何在云原生时代中找到自己的方向呢，我认为有四个方向还可以大展拳脚。

1. 需求交付：可以建立统一运维需求交付面，弥补DevOps视角缺失，拉近SRE和业务距离，提升运维交付体验，让业务快速迭代。

2. 技术运营：充分发挥SRE岗位角色，健全业务全局视角能力。构建底层业务数据模型，掌握服务全生命周期元数据，在此基础上，结合运营标准规范沉淀运维场景和建立运营平台。

3. 稳定体系：持续健全稳定性机制，流程规范，故障全生命周期管理，沉淀和演进稳定性方法论，定义和重构稳定性完备的工具链体系。

4. 左移业务：运维左移，深入业务，抽象和沉淀其通用运维场景，并推进共性运维。一些好的AI能力，往往需要深度学习业务场景和行为特点。同时把规范前置到业务架构萌芽阶段等等。

未来展望

1.能力升级

为了更加适应云原生时代，始终坚持和深化技术信仰，升级团队技术能力，通过技术手段成就业务。

2.运维服务化

深化运维服务化理念。运维的价值最终会体现到业务身上，但体现该价值最好的方式就是运维服务化，最大限度地给业务赋能。能力升级，就是为了更好地进行运维服务化。而运维服务化，则打开一扇窗，给SRE更多的成长空间，让他们能够升级迭代，就像太极理念一样，让这个团队生生不息。