SRE运维思考与实践

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

团队分工

怎样高效运维这样量级的业务？我们可以先看下作业帮基础技术的团队分工。

自底向上，团队按 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 业务触摸到机器，避免研发黑屏登机后不讲武德造成运维失控。

1. 偏向架构。

服务发现归一，主要把东西向服务发现归一化到 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 带来前所未有的冲击，倒逼我们深度思考，转型探索。

转型思考

岗位思考

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

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

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

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

能力探索

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

1. 产品能力：特别强调一下，并不是让每个 SRE 都成为人人都是产品经理，而是有意识地把工作痛点转化为产品若干功能需求点，而不是坐地抱怨，因为 SRE 是距离线上环境和稳定性问题最近的团队。
2. 开发能力：SRE 也是技术工种，显然需要开发能力。纯粹依靠 DEV/架构不靠谱，远水救不了近火，缺乏开发能力，就不能把事情精细化地做好。若大家都做开发，那跟 DEV 有何区别？边界在于 DEV 搭中台，SRE 依托中台建场景。
3. 运营能力：要求有意识地使用已有工具体系或者建设工具进行技术全方位运营，善用数据说话。
4. 拥抱开源：身处云原生时代，可能以上三个能力都具备之后，开源已经做得很完美了，这时候需要打开眼界，真心拥抱开源，融合开源产品，低成本应用到运维实践中。

方向探索

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

1. 需求交付：可以建立统一运维需求交付面，弥补 DevOps 视角缺失，拉近 SRE 和业务距离，提升运维交付体验，让业务快速迭代。
2. 技术运营：充分发挥 SRE 岗位角色，健全业务全局视角能力。构建底层业务数据模型，掌握服务全生命周期元数据，在此基础上，结合运营标准规范沉淀运维场景和建立运营平台。
3. 稳定体系：持续健全稳定性机制，流程规范，故障全生命周期管理，沉淀和演进稳定性方法论，定义和重构稳定性完备的工具链体系。
4. 左移业务：运维左移，深入业务，抽象和沉淀其通用运维场景，并推进共性运维。一些好的 AI 能力，往往需要深度学习业务场景和行为特点。同时把规范前置到业务架构萌芽阶段等等。

未来展望

对于未来，我们主要有两点展望：第一是能力升级，第二是运维服务化。

为了更加适应云原生时代，始终坚持和深化技术信仰，升级团队技术能力，通过技术手段成就业务。其次要深化运维服务化理念，运维的价值最终会体现到业务身上，但体现该价值最好的方式就是运维服务化，最大限度地给业务赋能。能力升级，就是为了更好地进行运维服务化。而运维服务化则打开了一扇窗，给 SRE 更多的成长空间，让他们能够升级迭代，就像太极理念一样，让这个团队生生不息。

作者介绍：

邓瑞龙，作业帮 SRE 负责人

聂安安，作业帮运维负责人