对于业务运维工程师来说什么最重要要，答案就是稳定性。更多文章可以关注微信公众号“SRE说”

稳定性概述

1.1 稳定性为什么重要

• 稳定性对于SRE来说 就是 10000前面的这个1 无论1后面几个0，一旦这个1没有做好，那么最终的结果只能等于0，稳定性也是SRE的最核心的R
• 稳定性好比一个人的健康，如果没有一个健康的身体，其他都是徒劳无功
• 如何稳定性做不好带给公司和个人的都将会是一个难以想象的损失，同时稳定性不仅仅在互联网领域在航天领域、工业领域都是最核心的保障。

这里看几个有名的case

• 切尔诺贝利核电站故障令人深刻
• 2020年4月10日，从早上9点20开始华为云出现故障，华为云登录、管理后台无法访问。
• 2017年的百度1228的故障，也是令人深刻

据不完全统计统计每年因为稳定性的故障导致公司的损失高达数十亿元，稳定性的重要性，一句话来说是企业前进的基础

1.2 隐藏稳定性因素有哪些

按照生命周期来说，1）架构和代码，2）部署合理性，3）容量管理，4）上线变更，4）数据安全，5）外部故障

1.3 如何衡量一个系统是否稳定

明确的指标，sla要能反映目前的健康情况

系统性的衡量方案，上线变更、容量部署、监控报警、预案执行、备份和恢复、审计的能力

1.4 指标的定义

SLA的定义是至关重要的好的sla可以直接反馈出问题来，如果sla定义不清楚那么问题发现肯定也会延迟。简答来说SLA需要直接反映当前的服务状态，

• 场景的定义 1-5xx/总pv。这里就是对5xx直接的关注。
• 1-pvlost/总pv，这里更关心pvlost。
• 如果一个服务有多个功能那么如何定义sla，第一种是取最小，第二种是取平均，第三种是取权重。

故障次数：重大故障的发生次数也是衡量稳定性的关键之一 ，比如重大case发生太多对产品和企业将是致命的

mttr：平均修复时间（Mean time to repair，MTTR），是描述产品由故障状态转为工作状态时修理时间的平均值。故障发生到故障修复时间，这个直接关系响应能力

1.5 稳定性全貌

上面讲了稳定性的重要性，这里讨论一下稳定性的覆盖面是哪些。这里发一张图，这里可以参考别的大牛的图和自我的理解完善的一张图

来自自身理解和业界文章

这里根据我的经验给一些比较核心和重点的事情

第一道防线：监控

监控是第一道防线直接关系到问题的快速发现，监控如何做，做哪些。监控的有效直接关系到发现问题的快慢，后续我会介绍监控应该如何做。

第二道防线：容量 （足够和精确的弹药）

这里提两个事情容量平台和全链路压测

容量平台：通过足够的数据积累（业务特征：比如节假日特性、压测、qps、机器容量等等来提供一个准确的容量预估）

全链路压测：发现其中的短板和容量极限

第三道防线：日常隐患消除分级发布和智能checker

灰度发布：侧重哪些用户命中哪些实例（对应到不同的产品功能），也可以是不同用户命中不同的代码分支。代码已经提前部署好。

分级发布：侧重代码怎么部署到众多实例上，关注的是代码部署过程，其核心是提高可用性、尽早止损。

分级发布四要素：变更顺序、变更检查、变更干预、回滚

第四道防线：能解决80%以上的网络问题-单机房自愈、

单机房自愈的思想是四步，快速感知、快速决策、快速切流。单机房的切流量速度关系到整个稳定性的内功考量，比如部署是否合理、容量是否充足、监控是否及时、决策是否及时、是否有切流的平台和工具。

第五道防线：紧急情况下的处理—机制和预案

紧急情况是指一些重大变更，重大问题发生，但是还没有造成业务的影响，比如idc双路断电，电池在维持；空调断线，蓄水池在维持等等情况这期间有一些缓冲时间，如何把这段时间收益最大化

第六道防线：灾难情况下的处理—备份和恢复

这个是我们最不愿意看到的情况，比如有人故意破坏，有人错误的操作等等造成也全面的瘫痪，如果没有备份的话将会是一个永久的伤害，另外恢复的时效直接关系到最终的影响范围。

单机房止损

这里参考百度的单机房故障处理来结合我的一些工作经验来说一下单机房止损的意义

2.1 背景和意义

• 2015年6月 某公司云服务香港IDC节点电力故障崩溃12小时
• 2016年5月 某公司杭州电信接入故障，服务中断小时级别
• 2016年11月 某公司某机房运营商误操作网络异常
• 2017年1月 某业务天津机房故障，服务数小时无法提供服务
• 2017年6月 北京某处机房掉电，多家互联网公司受影响

强悍的单机房止损能力几乎可以解决80%以上的稳定性问题，可以让业务无感知，在还没有反应这是一个故障的时候已经把问题解决在了萌芽之中。

2.2 单机房止损的标准和等级

为什么需要有标准呢，因为单机房止损不可能一步到位，需要一点一点来实现，需要一级一级来提升，这里推荐百度的定义L1-L4，目前百度大部分的业务集中在L3层级，

为什么L4很难实现呢，这里需要折衷自动化和稳定性的因素。自动感知和决策是一个非常难做的事情，主要是决策。比如A机房故障，决策切流，往哪里切，切到B吗。所有的业务都切过去，B机房挂了。

2.3 单机房止损实现

按照两层内网和外网，外网靠dns解析变更，内网靠接入层的调度

外网dns+vip的方式，一旦一个机房有问题通过dns变更来解析到另外一个机房

内网是统一接入以后，有统一接入调度到其他的机房，所以内网的切流要快于外网

在百度这是两套很强悍的系统，可以参考章老师的BFE相关的介绍

2.4 单机房止损关键

• 快速感知：依赖强大的监控
• 架构支持：没有交叉耦合
• 容量足够：单机房可以承受足够的容量
• 快速切换：平台支持
• 快速决策：人工决策和机器决策

快速感知：百度这个监控集合了 内网、外网、业务表现三方面的感知做快速决策

架构支持：

这里首先需要是两个以上机房，如果是一个机房的话也就没有必要了

• 逻辑服务隔离：程序部署隔离，杜绝跨逻辑单元混联，将故障隔离在 逻辑服务隔离 逻辑服务单元范围内
• 消除单点：平台架构上具备主备切换的执行能力
• 依赖解耦 ：上下游之间解耦，具备流量调度能力

容量足够

一个机房切空之后另外两个机房容量可以作出支持容量N+1：冗余或者降级状态下具备N+1冗余 。月度在线压测，容量过载熔断信号，实时计算容量负载

快速切换

这里需要有切换平台的支持，因为百度有bfe，bgw，等强大的平台支持，所以执行的前提有已经具备。不够可以利用nginx的自动切换功能也可以快速实现

快速判断

这里需要把以上信息作出综合的判断是否要切换，能不能切换

总结来说智能体现在三部分

• 感知：更加快速和准确的感知有单机房的故障
• 决策：更加精准的决策
• 执行：依赖大量的平台自动化做快速的响应

2.5 收益

看一下百度在其中一次故障之后的表现，2017/06/17 16:19 北京某处机房 掉电，受影响业务120s内完成接入 层的故障感知和止损决策;2分钟 内完成服务层止损

分级发布

3.1 什么是分级发布

分级：将一个完整过程划分多种粒度逐步覆盖的过程，比如法律和政策的发布，先要试点，然后在推广，比如改革开发的城市顺序 ，为了防止大规模风险的波动，通过分级来观察，把影响控制在一个可控范围之内。互联网的分级场景，滚动更新、canary部署、按阶段推出，例如：GoogleLab等

3.2 分级发布和灰度发布的区别

灰度发布：灰度侧重业务角度，比如用户、地域等覆盖，侧重哪些用户命中哪些实例（对应到不同的产品功能），也可以是不同用户命中不同的代码分支。代码已经提前部署好。

分级发布：分级更侧重代码和部署，侧重代码怎么部署到众多实例上，关注的是代码部署过程，其核心是提高可用性、尽早止损。也是运维上的专业表达

3.3 分级发布的意义

据统计故障其中有50%以上是来自变更导致的，而分级发布是拦截有风险变更的第一道防线，比如阿里云故障8小时1未按照分级发布的规范来做直接推全导致，删除用户数据，赔偿用户百倍时间。

3.4 分级发布的四要素

• 变更顺序
• 变更检查
• 变更干预
• 快速回滚

3.5 技术方案

这是一个通用的技术方案，当然可以按照自己的顺序来变更，这里强调的是要有变更检查能力，和快速止损的能力。

这里有个前提是需要做好机房隔离

3.6 如何衡量做的好不好呢

初级定义：没有基本的隔离域，上线或配送全并发。

中级定义：有隔离域划分，但人工干预能力、自动检查能力不具备或偏弱。

高级定义：隔离域完备，具备较完善的人工干预能力，具备基本的自动检查能力。

3.7 智能检查

分级发布的一个核心点是，必须要做大量的检查，这样就会给上线效率造成很大的影响，因为可能是多人ci，一个人上线，那么这个上线的同学可以不清楚别人业务的指标是否正常，是否检查完整性会有大打折扣，另外，检查必然会有大量的时间浪费，那么是否可以有一个工具来实现所有指标的自动化和智能化检查呢。这个就是智能检查的出现

智能在哪里呢，异常指标的判断，一个上线可能有几百上千的指标，不可能去定义每个指标的检查算法，那么这个智能检查就会集成一些默认算法指标，以及上下游的服务。

智能检查-实现方案

智能checker

分级发布在推动过程中可能遇到很大的难度，很多研发同学可能觉得这个检查是一个比较耗时的事情。checker与AI的结合就是智能checker，解决这种不是明确指标阈值的情况。比如曲线波动等情况

3.8 最后

分级是一个非常大的系统，详细的细节不会在这里深入的介绍了，这里重点说一下想法和思路，大家可以根据自己的业务来定制。

容量平台

容量对于业务的意义就好比，精力对于人的意义一样。一个人能做多少事情是跟精力有关系的，通过容量来衡量一个服务能承担多少流量。 同时容量跟成本一个相互制约的东西，对于业务来说需要综合考虑到容量和成本之间关系对于人来说我们需要管理我们的精力，对于业务来也需要管理容量

4.1 容量平台是解决哪些问题

第一 资源预估：管理容量就是为了让业务能有足够的资源来承担流量增加，判断按照当前的增长，多长时间需要是否扩容 ，判断当前的流量曲线是否有异常，同时防止退化

第二 服务编排，如何部署服务更加合理，如果是容器服务需要考虑，cpu、内存、磁盘等不同服务的不同部署方案

第三 释放人力 ，目前的容量评估和机器分配，都是靠人工来评估，会消耗大量的人力

第四 提前预估，节假日活动的容量评估，需要根据前一年的数据来做预估

第五 预算采购：在预算采购提交过程及时评估容量的增长情况，跟用户增加是否一致

4.2 容量平台的核心要素

第一：容量收集、计算、展示，这个也是最关键的，

• 收集：需要把业务的容量数据统一收集，比如qps、cpu、内存等等跟容量相关的数据。
• 计算当前容量的水位，水位的表示有很多，比如cpu、内存等等目前业界主流就是CPU
• 展示，实时展示

第二容量的预测

• 节假日容量的预估
• 来年的容量预估

第三容量规划

• 基础设施的规划等等，不过很少有公司和业务能达到这一步，主要是规划都是从下到上；一般都是idc买好机房业务在按照idc的来部署

4.3 容量平台做之前需要想好的问题—如何可持续发展

其实场景对于每个公司来说是差不多的，而且容量这个理解开展的已经很早了，早在10年之前就已经开始了，而且想法和思路几乎都是一样的，为什么有的公司进展的比较好而有的公司却做了一遍又一遍，几乎每个业务都重新来一遍，并且找出了很多之前不适合的理由

很多公司都在反复的进行第一步，那么如何才能使得容量平台持续发展。

• 通用：一定要用一些通用的语言，尽量剥离和嵌入自身的服务
• 可扩展性：业务是变化的，而且是不断涌现的，一定模块化和插件化，通用部分一定要跟业务本身完全剥离，而且需要可定制。
• 简单：使用起来一定要简单，如果太复杂这个平台就会无法可持续发展

4.4 今天重点讨论容量平台的方案

1）基本的容量平台

2）谷歌推出的容量平台介绍

基本的容量平台

• 前端展示：水位展示，容量展示，元信息（模块的属性）
• 后端模块：实时水位计算，容量极限计算，容量预警
• 采集模块：
• DB：元数据（模块信息和关联关系），容量信息（qps，cpu等）

4.5 介绍一下谷歌的容量管理-auxon

基于意图的容量规划

解释一下什么是意图 一共分为四个级别

• Level1：我需要50个cpu的资源，必须在集群x，y，z中，为服务foo使用
• Level2：我需要50个cpu资源，在地理区域yyyy任意三个，为服务foo使
• Level3：我想要满足foo在每个地理区域的需求增长，同时保障N+2冗余
• Level4 ：我们想要foo以99.999%的可靠性运行

Google的经验 level3 最佳

• 意图配置信息 （机器入口）
• Auxon 配置语言引擎 （数据转换）
• auxon求解器（核心）
• 资源分配计划（最后结果）

谷歌的理念还是很先进的但是这个意图就涉及到了模型的抽象和理解是一个非常难的环节，目前在业界还没有看到很好的实现

压测和容量的关系

压测平台是一个不得不提的平台，压测是容量的验证，一般在节假日或者重大活动的时候会使用，日常的压测也是需要的

压测的方案基本上分为两种，一种是线上流量切到某个机房集中测试，另一个方案通过构造一些词表，通过发压机来发压，压测平台就不在这里重大介绍了，后续有机会在跟大家讨论分享

最后

容量管理是一个长久的话题，当一个公司发展到一定阶段的时候一定会遇到这个，没有绝对好的容量平台，只有合适的。后续的发展肯定是压测容量一体化、平台化、AI化。

数据备份

5.1 数据备份和从零恢复的区别

• 数据备份讲究的是数据的最终可恢复，和数据完整性，这个讲究的是最终是否恢复
• 从零恢复讲究的是程序大部分能尽快恢复，这个讲求的速度

5.2 为什么需要有数据备份机制呢

看一下这些的例子

• 谷歌数据中心遭雷击导致0.000001%数据被永久删除
• 美国知名云服务商DigitalOcean主数据库遭到删除，持续5小时
• 携程误删除生产代码导致1宕机，损失约1300万美元，股价下跌11%
• 下厨房数据误删除，导致数据丢失长达2个月之久
• GitLab误操作导致300GB生产数据误删除，约丢失5037个项目
• 华为员工误删除南宁移动用户数据，面临5亿罚款
• 腾讯云故障致客户数据丢失，遭千万索赔

5.3 为什么这里不讨论从零恢复呢

• 极端灾难概率小，业务几乎没有出现过
• 从零恢复容易退化：程序、公共平台变化快，并且数据是恢复的制约因素
• 出现数据遗漏的情况

5.4 如何来做备份呢

这里是一个通用的备份系统一个分为四层

备份存储层—常用的有磁带、文件系统、云服务等等，比如阿里云

备份传输层—常见的技术p2等

备份中间层—这层需要保障数据备份时候的可靠和完整

备份管理层—提供给用户一个操作的入口和运维入口

5.5 备份资源如何平衡

我们需要整体考虑到资源问题

分层和数据流动的配合，常见的做法冷、温、热三种方案

5.6 如何保证备份数据的有效性

这里需要两个手段，数据校验，和恢复演练。数据校验会在后面的文章中介绍到，今天看一下恢复演练

恢复演练

如果每个业务都恢复那么恢复的成本就会特别高，

参考一下美国选举。

相同类别汇聚，每个类型选取1-2进行恢复即可

最后数据备份和恢复是最后一道防线也是最有效的防线，一定不能放松

雪崩和热点

讨论一下稳定性中比较常见但是非常严重的问题雪崩问题。我之前负责过一个业务，三天两头就雪崩，搞得大家都极度的奔溃，当时唯一的大招就是重启，配合着封禁。

如果重启速度足够快，那往往雪崩是可以恢复的，如果雪崩非常严重那么雪崩就是恢复不了，这个时候需要封禁，把流量拒掉。

6.1 故障回顾

后续经过跟研发团队的一起分析和改造终于解决了。详细分析一下过程，先从当时的故障报告看起

故障原因：上层的某个节点突然出现热点，导致php-cgi资源夯死，然后资源耗尽，端上无法感知是资源的问题，各层开始重试，最终引发服务的雪崩

下图是故障发生时的pvlost的图

这里分为三个阶段

• 第一阶段开始阶段服务还还没有雪崩，雪崩初期就开始止损点，比如可以切流，流量几乎无损
• 第二阶段服务开始雪崩，假设没有雪崩服务一直持续到最后业务恢复。预计的影响缩小到原来的1/10
• 第三阶段服务雪崩后影响到其他服务，假设没有收到影响到其他服务 预计的影响缩小到原来的1/2

6.2 原因分析

故障的原因事后总结了一下

发生的诱因：热点的出现导致的流量暴增

发生的根源：

• 内因是底层服务容量不足后，服务无法自我保护直到挂掉
• 另一个原因是上层业务无法感知，并且快速停止重试

影响扩大化：

• 核心服务没有隔离
• 止损效率不及时

6.3 解决方案

业务自我保护：后来经过改进业务会定期的压测，然后在加上限流策略，每一层都加上，这样当有流量暴增的情况下就可以自我保护

上层可以感知到底层的不足：上层如何感知到呢，这里需要整体定义一个错误码，比如577，当所有业务感知到577的时候各层业务就马上停止重试

重点服务隔离，两个层面隔离，机器层面的隔离，和业务层面的隔离。

包括垂直层面和水平层面

• 第一层：核心集群和非核心集群
• 第二层：按照不同流量隔离，比如电信、网通、移动、BGP层面
• 第三层：核心集群里面可以按照业务划分为三级，每一级用不用的资源

快速恢复

当故障发生时，如何快速恢复。这里主要是两点，第一是重启，如果重启足够快也可以恢复

第二是快速扩容， 如何快速扩容，常见的做法就是容器化，利用容器和虚拟化技术快速扩容。另外一种方式就是热备集群。当有问题的时候可以快速扩容。

6.4 最后在讨论一下热点

热点问题是常见的问题，比如微博的各种热点事件，运维工程师各种扩容等等。如何避免的解决热点问题，其实是一个全局的问题，热点最严重的后果就是导致雪崩，本文讨论如何解决热点、如何解决雪崩的问题

热点消除重点分为四个部分

• 封禁和限流
• 隔离
• 快速扩容
• cache

接入层：接入层是业务架构的第一层，需要做封禁和限流，目前全局限流比较难做，可以落实到单机限流。或者间歇性的封禁

逻辑计算层：这层通常是php后者java等，这一层处理做自身的限流之外，可以做服务隔离，把一些容易受到攻击的服务单独部署。即使有攻击也不会影响到其他业务

cache：比如上cdn。或者在各层之间加上相应的cache，可以缓存热点。

快速扩容：最后当所有的方案都无效的时候，就只能依靠快速扩容了，这个需要有平台的支撑，如果是以及虚拟化或者容器化后，快速扩容就可以得到满足了

存储层：存储层常见的做法：限流、cache、热点漂移，如果发现有局部热点存储系统就利用副本复制快速扩容解决热点问题

业务优化：每次发现热点之后就需要分析瓶颈点在哪里

6.5 总结 热点和雪崩其实是日常工作中常见的问题，往往是伴随一起存在的，需要多层来解决，这样不至于发生重大的灾难事件。本文讨论一下常见的解决思路。具体的解决方案需要根据实际情况来判断

总结

稳定性对于业务运维来说是必须要面对的问题，如果稳定性解决不要其他的问题就会是徒劳的。稳定性是一个很庞大的体系需要不断的探索。欢迎大家关注我们的微信公众号“sre说”来一起讨论

原文链接：https://blog.csdn.net/hei_ban/article/details/123312982?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165918469516782248547696%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165918469516782248547696&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-3-123312982-null-null.nonecase&utm_term=%E9%A6%99%E6%B8%AFcdn