SRE(系统稳定性工程师)

承诺保障50%以上的时间有助于让SRE更加有时间发现系统问题并解决，从而构建 出真正有价值的系统，最终实现一个良性循环。

变更速度通常来源于自动化测试，记得刚开始我们的nginx变更，都是通过手改 +gerrit review的方式来变更，有的运维同事会自己把配置

拉下来，然后自己通过-x测试，或者让开发绑定那个外网ip的hosts测试，这样 带来的一个问题就是让变更带来了不确定性。因为nginx类似

这些工具，看似加一个location有可能会带来灾难级别的问题，当发现的时候通 常已经影响了很多的用户。所以后来我们引入docker，通过

配合puppet的方式通过域名方式拉取指定公共集群的指定配置，最终的效果就是， 你要测试一个域名，这个域名的配置，所有nginx.conf,

等等都和实际部署的前端集群一模一样，而不同的就在于你的变化，比如你少了 一个location或者多一个location。后来我们把这个集成

到了工单，极大的提高了变更的安全性，也让开发和运维更加放心。而这些，都 需要时间，所以目光需要放长远。

我觉得这里的意思是希望监控系统能发挥到最大价值。这个价值在于你在关键的 时候收到了最重要的消息，比如哪个服务器挂了，哪个服务

此时不可用，而这些都是我们定义好的，并且分级好的，比如服务器挂了我们收 到了一条IM消息，如果没显示有人处理，就会电话到对应的

负责人。而这些监控有恰好出现了所有该出现的群里，比如IDC机房群，业务群。 这个恰好其实很难。

MTTR恢复时间表示我们业务从发生问题到解决问题的时间，这个在后面的篇幅也 还有。具体应该怎么做呢？记得当时组内流传一句话，当我们

业务反馈问题超过2分钟解决不了的时候，就应当组内通知，升级。所以一个问 题出现，我们要能够快速梳理出来问题的本质，并且快速反应，

这对运维工程师来说就是形成"肌肉记忆"。如果你不熟悉系统命令，那就完了， 因为其他人都在等着你，所以这是一种强迫学习的好办法！

做好变更管理非常重要，一般一个故障出来以后，我们首先是检查当天是否有发 布或者有变动，依次询问其他人和组内。这个是快速定位的办法。

一般故障系统里面可能80%以上都是变更导致的。而这些能说是人的原因吗？我 们有个ITIL系统，所有的事情其实都是对事不对人，但能真正做

到吗？我们能做的就是平台化，自动化这些，让这些问题降低到最少，每个SA都 可能背了几个印象深刻的事故，哈哈。

需求和容量规划是一个面试经常问到的问题，说实话，我之前回答的并不好。但 这确实是很多团队忽略的。主要在于第一不熟悉常见的容量模型，

第二没有把我们当时的容量模型说清楚，至少怎么评估的。

从文中看，包含自然增长（比如使用人数，资源用量）和非自然增长（比如广告， 业务推广，新功能），需要有一个准确的容量评估模型，

必须要有周期性的压力测试。

这里细想我们领导也是在做的，当时我也在负责部分采购事情。比如需要一个新 的nginx集群，按照一台3万Qps来说，一个业务需要6万Qps，可能

就给分配三或者考虑公用（考虑负载均衡），我们内部大部分还是使用OSPF等价 路由+vip的方式实现负载均衡，这个方式把转发流量交给交换机。而

lvs+dr我们内部也在用，但是相对较少。

至于一台能承载3万Qps，这个数据其实就来源于第一，经验，第二，理论最大最 小，第三实际测试。

我们有一个质量保障部门专门负责一些测试，而对于运维内部，其实一直是相对 缺少这样一种容量单机测试系统一直在运行。如果有了这个，一台

什么配置的有什么样的QPS，那我们买机器就会多很多选择，所以这里体现了容 量规划的意义，省好多钱。

在之前我们是这样的，A业务淡定地说，我们需要一个nginx集群，下周就用。运 维说，啥？服务器买了吗？需要多大规模的，能公用之前的资源吗？

需要走C-D-E流程。然后我们从资源池找到3台机器，通知机房，帮忙搬到F机房 （因为那里有ospf机架），然后等机房回复老哥我弄好了，我们又联系

网络工程师，大佬帮忙交换机配置下ospf，我这边已经配置好了。大佬过了一会 说，我看了下没问题，你的vlan对的吧，是xxx.xxx.xxx.xxx/28，嗯，

对的，ping一下看下，好的，通了，good！然后卡卡卡，puppet整好配置，起好 名字，一顿操作，终于nginx和配置环境搞好了。紧接着，自己本地

绑定hosts测试，发现ok，于是邮件或者工单通知业务，ospf集群已经搭建好， 请及时测试！这可能就是一个资源部署的过程，在物理机为主的系统中，

大家会发现其实还是有很多的限制，其实这也是为什么云计算为什么那么快推广 的原因吧！

而SRE能做的就是加速这里面的流程。

我记得刚开始就是有个活，我们要统计监控中cpu使用率长期小于10%的服务器并 安排合并或者迁移。当各个事业部发现自己的服务器成本为什么那么高的

时候，就开始关心每个服务器的用途，如果SRE能够优化这里面的东西，和容量 规划那里一样，就是真金白银。这里是存在风险的，老业务的遗留，

新业务的冲击等等，其他团队的配合时间，对SRE都是挑战。好的运维团队应该 是团队之间的加速机器，减少沟通成本。

machine为物理服务器，server为软件服务器，通过Borg管理物理服务器，实现 编排和分配。

◎ ../images/sre-google-topol.jpg（图片来源sre google运维解密）对于 google来说：

• 约10台服务器构成一个机柜rack
• 数台机柜组成一组机柜，一排row
• 一排或者多排组成物理集群cluster
• 一个数据中心datacenter包含多个集群
• 多个相邻的datacenter组成一个园区campus

每个datacenter内部的所有服务器由于互联，引入jupitor交换机（多达几万个 端口）通过虚拟网络实现

大二层网络。

每个datacenter之间通过B4（骨干网）链接，基于SDN（Software Defined Networking, 软件定义网络）（使用 openflow标准协议），好处是 提供

海量带宽和优化网络连接。openflow可以参考 这个视频。可以发现也 有流表等数据结构，通过pipeline来实现最终的包的传递。

在google，之前使用的是Borg，现在也许用的是Kubernetes，总之是通过虚拟化 实现资源更合理的使用，更方便的扩展，和现在的云差不多，相当于

一个大的私有云。我记得刚开始工作大部分业务都使用的是物理机，后来由于各 种需要都陆续迁移到了云主机。要给业务的爆炸式增长，比如海淘那

一类的app，我们只需要在比如双11，618等时间点前准备好对应的资源，并且充 分测试，其他时间完全可以释放给其他业务使用。

类似于serverless的比如aws的lambda，其实本质上也是把计算能力等资源分配 到实际服务器上，而用户并不关心，用户只关心我给你数据流，给我

要的结果，从而真正实现服务化。这个最早也容易让人想起新浪有个博客服务好 像，只需要定义自己的代码，就可以能够在网页运行。

google的存储通过加强版GFS Colossus实现，也就是共享存储。这里我觉得可能 会有一些问题，比如共享存储的带宽，可能会出现排队等。

不过资源确实非常节省，现在每个云产品也有对应的共享存储方案。

通过openflow时间软件定义网络，并且有GSLB，可以根据地理位置进行dns解析， 这个我们工作的时候，公司内部也有，我估计是符合这种协议就可以，

一个dns的解析可以设置国内国外，甚至江苏省，浙江省这样。猜测实现还是通 过一个ip地址数据库实现dns协议的转换。

风险时刻存在，服务器可能会宕机，网线可能会被碰到，外部可能会攻击等，一 般风险和成本相互制衡。而SRE需要在这里面保持较好的风险平衡，为了达到多 少的可用率，在平常评估风险的时候至关重要。

一个99.9%和99.999%的可用率对风险的变更影响可想而知。

如果不加以控制，琐事会越来越多，人的成就感也会越来越低，把有限的精力投 入到了无限的琐事上去，会很难受。

因为琐事会造成中断，而且会造成恶性循环。记得刚工作的时候每个SA都要值班， 按天，到自己的时候就开始人dumb麻木

起来。一个无情的工单处理机器。那一天基本没有啥自己的时间，因为消息会有 非常多，会同时有几个人在咨询你，问你，

然后还要把工单带着做。每个人的手速都被调教地非常快而准。那天能吃饭也是 开心的。

后来随着工单彻底自动化，我们写了若干个自动处理程序，一切变得更加顺畅了。 值班基本上没事情了。以前多的VPN咨询

也因为明智的摊给IT而留在记忆里面。在琐事的情况下能学习到东西吗？是能学 到一些的，但是人会没有其他精神去学习别

的，这也是自动化的好处，不过好在我们一人轮一天。大家也互相帮忙，团队异 常融洽。

和琐事相对的似乎是工程工作。每一个都是琐事的反义词。

工程工作有长久价值，需要创造性和主观性，具备通用性，有助于减少琐事。

• 软件工程 代码部分，自动化脚本（shell, python, perl so on），自动化工具或者框 架（可能每个团队小组都会有自己的平台），如果没搞大平台的情况下，这个 时候大家都会有一些自己的东西。
• 系统工程 配置变更，编写对应文档，调整负载均衡等集群的部署，架构等方面咨询和设 计工作。
• 琐事 重复性无价值的手工的劳动。
• 流程负担 招聘，会议，总结，培训等等。

• 增加对应软件工程投入，引入自动化平台
• 不相关业务匀给其他部门
• 适当减少流程性工作，把时间匀给自动化相关思考
• 定期头脑风暴相关优化措施，automate everything

• 分析长期趋势

数据当前的数据量，数据的增长速度

• 跨时间范围比较

例如使用了A架构后的性能提升多少，比对两个不同时间范围的性能参数即可

• 告警 出现故障时候有人可以及时修复
• 构建监控台页面 监控台页面有助于了解服务的实际情况
• 临时性的回溯分析（在线调试） 刚刚只看到了请求增大了，有没有其他情况，比如CPU资源利用率等等？事故 评审review溯源需要

• 设置监控指标需要简洁高效
• 添加白盒和黑盒监控

• 四个黄金指标

  • 延迟 服务器处理请求的时间
  • 流量 对系统负载需求进行的一种度量指标，比如网络流量，请求数
  • 错误 请求的失败率
  • 饱和度saturation 服务容量有多满，服务是否需要扩容，比如磁盘剩余空间85%
• 用直方图比例适合衡量指数型增长等参数指标 比如fio的统计输出，1ms以内的占80%，1-2ms以内的占15%，2ms以上占5%
• 尽量简化监控指标SLO 简化到看一眼就知道哪里有问题了，比如xxx域名解析异常比xxx网站现在无法 访问要好

• 设计SLO的适合要考虑

  • 这个指标的宽容度，什么告警媒介，是否应当被忽略（紧急程度），避免狼来了问题
  • 是否显示需要的数据,告警是否有依赖性，尽量保证不要重叠，是否具有可操作性
  • 这个谁应该处理，应该很明确，告警到正确的群或者地方

一个监控系统的指标应该是现象性，精确到技术栈会让监控更清晰

邮件告警通常会让监控成为噪声，解决的好办法是搭建一个dashboard用于处理 非紧急的告警。

对于每个季度可以进行on-call统计紧急告警的必要性和执行效率等问题

• 创建账户

比如创建VPN账户，创建服务器账户，创建数据库账户

• 服务器上下线

服务器上下线本身包含很多流程，如果把流程整合自动化，最终合并到机房工单 或者机房能看到，

会非常方便，下线通常包含去掉dns，去除cmdb中的记录，移除应用，机房处理 等等

• 软件或者硬件安装

安装特定软件，比如docker，java，redis等等

安装特定硬件，比如raid磁盘格式化，nvme驱动安装等等

• 版本发布

对于一些应用比如web应用发布重启等等

• 配置更改

配置分发修改，比如puppet等iac工具

• 其他

其他就是一些每个团队自己的任务了，比如dba有对应的修改表结构，这些通常 是自动的命令，

只需要审批，review等流程就可以自动化执行了，这个我们一般是放到工单的自 动化流程，

可以参考activi这种bpmn工具

还有一部分是通过配置分发工具，我们之前是通过puppet分发的

当然也可以把部分放到cmdb的应用配置等地方用于发布

• 手动操作

手动执行大部分步骤

• 脚本化

各个模块的脚本编写

• 平台化

各个脚本等进行安全梳理和优化，并且开始有统一管理平台，操作权限逐渐可以 下放

• 平台+自治系统

系统更加有弹性，处于自治状态，无人值守

这里有一点要说明的是，引入Borg系统也是google自动化的重要步骤

通过API去对资源进行控制和通过物理服务器上下线等操作是完全不一样的使用 体验，也是

自动化的更高更精细的境界，说白了就是引入私有云管理服务，屏蔽了硬件服务 器带来的风险

和分配，实现真正的服务自治，避免人工成本。这也是所有的大型互联网公司为 什么要发展自

几的私有云设施，但是随着大量使用云服务，云底层的变更（比如网络和存储） 也需要谨慎处

理，否则将会带来大规模的灾难。

每个公司都应该有一个发布系统，而谷歌在写SRE这本书的时候叫Rapid（迅速）。

◎ ../images/sre-rapid01.jpg

可以发现基本就是一个网关，通过解释配置语言BluePrint，负责分发对应的持 续集成任务，

任务会找构建机器，构建单元测试和其他流水线，产生artifacts并且进入版本 管理。

通过Sisyphus，自动化发布框架，我理解应该是一个流程平台，最终实现负载部 署

比较高级的CI/CD通常是纽带联系起来的，CI把预定义的测试流程跑完以后自动 上线，或者通过一个测试确认按钮继续。

CI和CD个人认为不应当认为是两个步骤，而是有明确相关的上下文关系。

配置管理通常是不稳定性的来源，一般需要运维和开发等共同维护。解决版本的 办法和冲突有几种，

• 比如通过打包工具打成包版本，配置文件分版本，这样两个版本包和配置包的依赖减少，减少出错

成本

• 都是主分支对应的配置文件，通过其他区分
• 从外部存储读取

一般来说，未按照我们的需求，"无意为之"这种，称为意外复杂度。

在运维场景里面，是不希望这样的，减少的方式是

• 当别人尝试引入意外复杂度，及时提出抗议

这就是为什么领导通常会拒绝特别奇怪的需求，非场景化的需求，如果一个团队 全是这种需求，

而且无所避免，那真是一个灾难！

• 努力消除运维系统的复杂度

自己用的系统，作为运维非常有必要，哪里不舒服，其实自己都知道，需要一个 有执行力的团队

慢慢会惊奇地发现，越来越好了！相反就是人人都在说自己在忙，又不知道在忙 什么。

随着软件不断开发，软件代码会越来越多，让软件越来越臃肿，后续的维护会非 常麻烦，

所以多尝试负代码，重构代码。让代码活起来，而不是Shit Mountain。

文中提到了两个实践，

• 最小API

不是在不能添加更多的时候，而是没有什么可以去掉的适合才达到完美。 - Antonie de Saint Exupery

一次只做一件事

• 模块化

包含代码的模块化，数据格式的模块化，说通俗点就是可以通过引入或者依赖的 方式，方便地

进行使用和移除

通过time series的方式存储到内存中，timestamp, name=value的形式，定时归 档到TSDB

通过键值对和索引等综合起来形成一个变量表达式

{var=http_requests,job=webserver_requests,instance=liuliancao_web:443,service=liuliancao_web,zone=cn_hangzhou}

这个变量表达式可能会返回一组结果series set，通过加上时间戳可以过滤我们 真正想要的结果

{var=http_requests,job=webserver_requests,instance=liuliancao_web:443,service=liuliancao_web,zone=cn_hangzhou}[3m]

在Prometheus对应聚合，当我们采集完数据以后，就需要对数据进行分析和处理，

比如最近的增长斜率，比如平均值等等，通过这些生成Prometheus的rules

可以参考 Prometheus awesome rules了解下规则的样子

当我们有了规则和表达式以后，我们就可以对计算出来的值进行阈值判定，

比如HTTP_STATUS_CODE为非200等等

黑盒监控和白盒的业务监控区别，通过探针方式进行监控

按照一定的时间比例进行时间或者金钱补贴，避免过度劳累带来的不幸福感

减少工程师的精神压力，避免依赖直觉等的非理性的情况，减少这些的方法通常 包括

• 清晰的问题升级路线
• 清晰的应急时间处理步骤
• 无指责，多通过平台维护避免认为和平台保障，对事不对人的文化氛围

SRE团队应当恰当的人数，让每个团队的人能够参与若干轮值，可以通过灾难演 练等

避免出现问题的时候，造成人员紧张等问题

非常安静，系统太稳定，很多时候也可能是需要去优化的时候了，是不是我们采 集的

指标过少？系统是否能够满足后续升级扩容等需求？

具体可以看sre这个图，◎ ../images/sre-12-1.png

一个故障产生，解决思路如下

• 确定故障情况

明确是什么故障，是否确实有这个故障

• 定位

最近有变更？服务是否正常？用户是否是特例？影响情况？

• 检查

通过一些工具获取必要的信息

• 诊断

对获取到的信息进行分析诊断

• 测试/修复

通过诊断的内容进行修复验证

• 治愈

修复好，通知服务正常

排除故障的时候，可能会有一些操作需要尽量避免

• 没有真正理解故障和现象

在故障理解上存在实际偏差，导致浪费宝贵的时间

• 因为自己操作的问题导致验证或者修改的时候存在偏差，造成测试假设失败
• 把问题过早判断为极低概率事件，方向刚开始就搞错
• 试图优先解决次要问题

没有发现这是主要问题带来的次要问题，应该优先解决主要问题

避免这些问题需要注意：

• 了解常见运维系统和组件的工作原理，了解分布式的运行基本模式和原理
• 优先考虑简单解释，而不是天马行空
• 相关性不等于因果，找到主要矛盾才是关键

莎士比亚搜索服务报错"the forms of things unknown"

这个阿里云经常会模拟机房事故，来显示自己的跨机房能力，虽然有些表演的味 道，但是

每次都会比较重要，因为通过这个可以不断验证我们的跨机房能力

引入故障模拟，可以验证和优化我们的流程，提高整个响应事件的决策水平等

通过事后总结，可以总结好的方面，比如响应及时，果断，很快找到原因并修复

总结不好的地方，比如没有统一的决策人，流程还存在不完善等等

每次事故以后保留操作记录和待办事项，应该有一个系统统计和记录我们的所有 事故或者事件的

处理过程，比如ITIL事件管理系统

多想一下机房断电这些问题，被入侵了怎么办，服务器硬盘坏掉怎么办，对于所 有业务

都优先考虑冗余（硬盘冗余RAID，部署多个后端，无状态或者存db，机房机架冗 余）等等

• 发生业务问题，进入on-call状态 电话告警提示某服务不可用，紧接着，其他5个数据中心的3个提示不可用
• 发现错误日志提示某个服务模块不可用 开始尝试回滚版本，失败，联系模块开发 其他两个人表示只是看看，没有参与解决问题
• 业务高管提示你的上级，没有人通知他
• 公司副总裁问你什么时候能恢复服务 同时问你为什么，原因等，提出自己的一些解决办法，比如增加缓存大小
• 最后两个数据中心的也挂了
• 在你不知道的情况下，开发给另一个开发打个电话，修改了cpu亲和性 结果修改完配置后，服务读取了新的配置文件，彻底奔溃了

这个场景我们可能都经历过，如果没有合理的事故处理流程，对于刚入行的新人 来说。

• 发生业务问题，进入on-call状态 电话告警提示某服务不可用，紧接着，其他5个数据中心的1个提示不可用 A开始调查原因，随后5个数据中心的第二个也有问题了，升级到紧急事务处理 框架
• 联系事故处理人 戳了另一个人B，让他当事故总控负责人，事故总控负责人B就位，并开始记录 遇到的情况
• 事故处理人更新信息到邮件列表 B整理好邮件，发给了预先设置好的邮件列表，提示暂时没有收到影响，但是 可能会有第三个数据中心报错 当第三个数据中心的服务也挂了，B更新了邮件，并开始联系公关准备起草用 户通知通知用户，
• 联系开发处理 A和B商量后，决定联系开发，B此时联系开发负责人C， C上线了发现D也自愿加进来，总控B提醒C和D优先处理A交给他们的工作，并且 必须告知A 他们即将进行的任何操作，C和D阅读了邮件很快知道故障情况。
• 交接其他团队 到了下午，B的下班时间到了，于是召开了简短的电话会议，交接给另一个团 队了
• 事故时候处理 A第二天早上回到公司，发现有同事定位了具体问题，缓解了问题，同事将事 故做了了解。 问题解决了。A补充了一些细节，并且提出了一些后续措施供时候评审。

这个一般是领导通过层层决定的

当我们遇到一个事故的时候，通常要根据如下因素判断

• 是否需要引入其他团队
• 是否影响终端用户
• 几分钟后，是否得到解决

文中的最佳实践

• 规划优先级

控制影响范围，尽快恢复服务，同时尽可能地保留现场和命令记录等

• 事前准备

事先准备好一个事故处理流程，并演练

• 信任

充分信任每一个参与者，分配职责让他们自主行动

• 反思

如果自己确实短时间解决不了，需要升级

• 考虑替代方案

周期性地检查当前情况，看是否在处理更紧急和更重要的事情

• 换位思考

多更换角色，熟悉每一个职责

事后总结不是惩罚，而是整个团队的一次学习机会，什么时候进行事后总结？

• 影响用户
• 数据丢失
• oncall工程师需要手动接入的（比如回滚，切流量）
• 耗时超过预期的限制
• 不是监控先发现的

我们之前的写ITIL的条件是 和谁最相关就谁记录，所有的问题都要记录，标记 为事件和事故

比如出现dns解析问题就SA记录

出现应用的开发bug等问题就开发或者PE记录

出现数据库故障就DBA记录，把相关的跟踪人记录好就可以，然后每周评审

单元测试是最小的最简单的软件测试形式，测试一个软件单元，一个类，或者一 个函数的正确性

集成测试通过依赖注入等方式，创建各种依赖的mock环境，可以测试一系列组件 的在一起的工作情况

系统测试通过部署所有组件在一个未部署的系统上

系统测试分为如下类型：

如何引入测试模型？在一个建好的项目或者刚建的项目

• 区分各个项目的重要程度
• 区分项目里面的重要的类和操作
• 区分跨团队的API
• 通过BUG引入测试用例，逐步完善，形成良性回归
• 引入一套完善的测试基础设施

这个基础设施在每次代码改动都进行构建，发现问题及时通知 这样大家会知道 变更

可以引入构建树等信息，列出具体被影响的内容，更加方便了解里面的变化

对于SRE自己开发的工具也应当走发布流程，否则是相当危险的

另外可以通过增加系统边界，监控等机制来满足避免某一危险特性被分发到线上 环境

引入一些意外因素，来模拟实际的灾难业务表现情况和一些熔断措施是否正常, 数据一致性能否保证

多个A记录指向nginx，dns带有健康检查

维护anycast ip，通过就近方式访问对应的服务

通过lvs直接路由的方式，配合各个实际RS（包含nginx）的dummy接口伪装处理消息，最后通过

自己把请求传回给用户，通过把服务部署在多个lvs集群上，在dns进行多个A记

录的设置。

三层交换配置ospf等价路由，通过类似5元组的方式进行hash到对应的真实的代

理服务器，代理服务器通过安装quagga来虚拟路由器实现ip伪装。

后端的状态分为

• 健康状态

后端可以处理请求

• 拒绝连接

后端处于无响应状态，端口failed

• 跛脚鸭状态

正在监听可以正常处理，但是已经准备停止

通过跛脚鸭状态，可以优雅停止，通过发送SIGTERM发送信号到该任务，后端会 在所有请求处理完成以后进行退出。

nginx有类似的heath健康检查插件，可以做类似的功能。

每个具体的服务维护一个长连接数量，类似nginx的keepalive机制。

由于qps数量可能和客户端，后端代码等多种方式有关，因此有时候使用qps这种 规划方案可能会有些问题。

更好的解决方案是使用可用资源，比如可用500CPU和1TB内存，按照可用资源进 行额度规划。

大部分时候简单使用CPU进行容量规划也可以工作地很好。

• 在有垃圾回收GC编程环境里面，内存的压力通常会编程CPU的压力（内存受限 的情况下GC情况会增加)
• 在其他编程环境里面，资源一般按照某种比例比如1cpu:4内存进行配置。

对用户或者服务配置限制，比如

• 邮件服务使用4000CPU（每秒使用4000个CPU）
• 安卓服务允许使用3000CPU

当用户或者服务超过配额，后端服务应该拒绝请求并返回配额不足错误。

当客户端监测最近错误是配额不足导致的时候，应该主动限制自己的请求速度减 少后端过载压力。和tcp的滑动窗口类似。

关注重要性也是在过载发生时候一个重要手段。把请求标记为

• 最重要 CRITICAL_PLUS
• 重要 CRITICAL
• 可丢弃 SHEDDABLE PLUS
• 可丢弃的 SHEDABLE

使用的CPU消耗程度/预留CPU 这一比例衡量资源利用率。

通过资源利用率超过一定阈值的时候开始拒绝请求。

大规模后端任务处于过载状态，需求不应该重试而应当传回给请求方。

在小部分后端任务处于过载状态时候，优先进行重试。

当时收到任务过载错误的时候，需要决定是否要重试，

增加最大请求次数的限制，比如已经失败了三次就不再尝试。

• 通过压力测试测试出服务器的极限 同时测试记录哪种资源会耗尽和其产生的，结构等场景
• 提供降级结果

当压力过大降级，返回降级结果

• 过载情况下主动拒绝请求

当前端或者后端进入过载模式的时候，可以尝试把请求标记为失败，避免雪崩

• 上层系统应该主动拒绝请求
• 进行合理的容量规划

当服务处理失败的时候我们需要进行重试，需要注意一下：

• 在重试之前进行必要的判断，确认是否要重试
• 重试请求时间最好指数型增加，避免无效重试
• 限制重试次数
• 增加全局重试的次数限制，用户重试过多则标记为失败
• 使用明确的返回码标记各种错误模式应当如何处理

为每个请求设置一个timeout，超过时间则应当放弃该请求。

另外可以把整个请求标记一个总的deadline时间，超过deadline时间则不再传送。

对于请求延迟我们应当除了关注平均延迟也应当关注延迟分布，并且设置的截止 时间不应当比平均延迟大好几个数量级。

正常的集群的性能会比刚开机要好一点，因为刚开机有个初始化的过程，可能会 导致效率比较低。

所以可以考虑预热。

不要又调用回去了，可能导致死锁或者通信环路等问题。一旦负载高将会十分危 险。

正常分布式的系统的逻辑处理相对复杂，在一次故障中，有时候很难精确判断问 题，比如产生网络延迟，包被丢弃等。

• 脑裂问题

比如我们常用的keepalived, 通过对对方的ping或者命令来检查状态，如果中间 网络有问题，可能slave会觉得master有问题，slave触发脚本并且尝试抢占vip。

• 需要人工干预

某些系统，当系统无法判断是否能够进行主从切换的时候，这个时候需要引入认 为因素来控制切换流程。这样代价是运维压力大并且恢复效率差。

• 有问题的小组成员算法

比如通过gossip（consul的分布式实现方式）的方式把集群添加，当出现网络问 题的时候，可能会选择多个leader出来。同时接受写入和删除操作从而造成数据 丢失。

目前常见的解决分布式共识问题的方法是Paxos，Raft，Zab,Mencius等。 Paxos可以参考下

• paxos介绍
• paxos wiki
• paxos algorithm

Paxos分为三个角色，

• Proposer

提案者，提出对应的操作

• Acceptor

允许accept对应的提案

• Learner

只能学习收到的value

Paxos接受value的过程

• Proposers把value发送给Acceptors
• Acceptors对value进行accept
• 由于有每次只能选择一个value的要求，所以这个时候满足大多数原则的value 会被选择(chosen)，接受的value成为批准决议proposal

专业主义意味着要对自己负责的领域负责，在这里我们通常有一定的权威性，

我们运维来说，比如在部署发布的时就要为自己写的部署逻辑负责，一旦事情搞 砸了，

就是需要我们自己收拾残局。

当我们开始写的时候就要明白，一旦这个系统出现巨大的bug，就可能到之非常 大的损失，

所以一切谨小慎微总是没有错，做就要做到自己认为可交付的状态。

能就是能，不能就是不能，不要说试试看。 -尤达

文中举了一个例子，就是一个系统在没有充分测试的时候导致交付

从而产生的血淋淋的例子。最近我开发的一个编排系统也是有感觉，

领导的意思恰恰相反，他们希望我能把功能完善好再提交测试，而我

总是想测试自己都不觉得非常稳定的功能，而实际也后续进行了很多

稳定性修正。

对于说不，是建立在我们觉得系统的稳定性得不到保障而可能造成

生产环境的损失而言，对于系统的稳定，不妨稍微悲观一点，收敛一点

我们的自信，表现地更加沉稳一点。

我们依然可以和我们的经理和上级勇敢地说不。

不卑不亢地说明我们的理由，如果他们不能接受，至少我们也曾努力过，

看下是否有折衷的方案。

不要表现地尽量试试，而是评估具体的时间，这样让大家觉得你比较可靠和专业。

如果无法完成，就是自己的失责。

一个问题在于说不的同时，当目标很难达成的时候，我们应当提供大家都能接受

的方案，而不是一直在否定，也尽量少提供一些技术细节让别人拿捏，尽量从对 方

的角度去解释和分析问题。

当领导出现强迫希望我们试试的时候，我们可以保留好证据和适当越级反馈，

当然最好是和领导沟通后，提早暴露项目的风险，拯救项目。

• 确定所有需要的组件
• 确定每个组件对应的数量
• 确定容忍度
• 确定参考数据来源