稳定性总结

稳定性的重要性

• 用户体验

  • 小红书

    7月26日晚微博社区开始陆续反馈小红书启动崩溃，并冲上微博热搜。

    7月27日凌晨 2:47 官方发布第一个解决办法卸载重装，官方“劝删”行为引起了部分用户的不满，该条微博下有网友留言称不敢相信官方解决技术故障问题竟然是让删除APP重装，也有用户表示按照方法删除重装后依然打不开APP。

• 营收损失

  • 滴滴：k8s非规范变更

    滴滴弹性云内部的 kubernetes 版本升级在两个月以前就已经在所有机房升级完成，整个升级过程中0故障且业务无感知。kubernetes v1.20版本已经在滴滴弹性云中稳定运行了几个月。因此此次故障猜测是由于误操作导致 kubernetes master 组件由 v1.20 回退至 v1.12 导致。

  • 美团外卖：机房电力故障

• 公司声誉

  • 阿里云：冷机系统故障

  • 微信、QQ ：机房冷却系统故障

  • 阿里云：控制台服务异常 详情

• 商业竞争

一些大公司重大事故：

什么是稳定性

    稳定性(High availability)是可靠性工程中的一个概念，主要是指系统能长时间的运行在一个确定的状态，能够在期望的时间内正常处理用户请求，并且输出符合预期的结果。 核心概念就是让我们的业务系统长时间运行在预期状态，这里的稳定性预期状态包括系统的功能、性能、用户体验等方面，我们通常可以用“正常对外服务时间”来评价稳定性的好坏。具有良好稳定性的系统能够在各种各样的压力和负载时，仍然保持高效、可用。

可用性一般使用 （1 - 故障时长/总运行时长）来度量，一般在 99.9% ~ 99.999%

• 90%（1个9的正常运行时间）：这意味着10%的停机时间，也就是说在过去的30天里停机了3天

• 99%（2个9的正常运行时间）：意味着在过去30天中有1%，或者说7.2小时的停机时间

• 99.9%（3个9的正常运行时间）：意味着0.1%，或者说43.2分钟的停机时间

• 99.95%（3.5个9的正常运行时间）：意味着0.05%，或者说21.6分钟的停机时间

• 99.99%（4个9的正常运行时间）：意味着0.01%，或者说4.32分钟的停机时间

• 99.999%（5个9的正常运行时间）：意味着0.001%，或者说26秒的停机时间

影响稳定性的因素

外因

• 基础设施故障

  • 机房断电

  • 网络中断

  • 带宽过载

• 外部流量过载

  • 特殊天气导致外卖订单变多

  • 节假日等因素

• 第三方服务

  • https证书

  • 域名过期

  • 域名解析

  • 云厂商服务

内因

• 不规范变更 (eg: 数据类型问题 int8 int32；基础组件配置、连接数、内存大小 等配置；软件版本升级； )

• 未测试需求直接上线

• 上线的需求产品不知道

• 上线的新需求有bug

• 上线后没有线上验证

• 系统设计方案存在缺陷

• 系统代码实现存在缺陷

影响可用性的因素

• 故障发生频率

  • 变更流程管控

  • 测试覆盖度（单元测试、集成测试）

  • 代码质量

• 故障影响范围

  • 分级发布

  • 流量隔离

  • 用户隔离

• 故障恢复时长

  • 故障发现

  • 故障止损

  • 关键预案

稳定性怎么实践

稳定性没有银弹

听了很多道理，仍然躲不过坑，就像炒股一样，知道很多但是一直亏钱，但是建立一些正确的思维和做事方式还是可以取得非常好的结果。

请问IDC运维机房门口应该摆/拜哪位先贤？

系统正常，只是该系统无数异常情况下的一种特例。 —— John Allspaw

稳定性更像是一场修行，重要的是从自己错误和别人错误中总结规律，学习成长，稳定性能力的提升，虽然无法保证不出问题，但从确实可以达到长期来看更高的可用性水平。

一个高水平的架构师或技术负责人，把一个系统可用性多提升一个九，或者两个九，这是完全可能达到的。

稳定性实践要点：

• 引入正确方法论

  • SRE Google 运维解密

  • 凤凰项目：一个IT运维的传奇故事

• 故障案例学习

  • 从别人错误中学习，很多低级问题导致的故障

  • 学习同行或者跨行业的案例

• 系统架构能力提升

  参考：云设计模式、架构和实现

  • 容灾架构

    • 多 AZ、机房 部署

    • 异地多活

  • 防御雪崩（eg：西二旗地铁故障）

    • 排队

    • 降级（eg：电视节目抢红包案例，可以加随机数去应对）

    • 熔断

  • 柔性可用

    • 分布式系统 CAP 理论，最终一致性，trade-off (关键取舍)

      

• 树立风险意识

  切尔诺贝利事件原貌

  由于操作员急于求成，功率被过度降低，使反应堆处于一个不正常的状态。好在此时反应堆没有致命的危险，只是需要等待一些时间才能正常工作。但是，临场的副总工程师迪亚特洛夫过于相信自己的经验，不想停堆等待，便命令操作员提高功率。

  为了提高功率操作员拔出大量控制棒，211根控制棒最后仅仅剩下寥寥可数的6根。4号反应堆的能量瞬间增加，能量没有宣泄的出口，失去控制，状态也越加不稳定，最终引发了热能爆炸。

  引以为戒才是历史留给人类的另一种财富

  • 风险敏感

  • 底线思维

  • 决策完备

• 提升管理能力

  • 防单点：关键数据和流程做好冗余和备份

  • 规范化：例行操作规则化，消灭琐事，用工程化、自动化解决问题

  • 防懈怠：培养意识和文化建设

    管理要素：

    • 嵌套式职责分离：事件总控、事件处理团队、发言人、规划负责人
    • 通知中心：受到事故影响的部门或者负责人需要实时跟事故总控负责人联系
    • 实时事故状态文档：确保关联的每个人知道事故的进展
    • 明确公开的职责交接文档：确保后续处理的人能够最快投入处理

海恩法则：

• 一是事故的发生是量的积累的结果；

• 二是再好的技术，再完美的规章，在实际操作层面，也无法取代人自身的素质和责任心。

海恩法则

稳定性怎么落地

树立稳定性意识

做对的事情，把事情做对。

建立 变更规范、上线规范、树立稳定性文化 是一个非常关键且收益非常高的事情。

    人的意识是最重要的，专业能力可以锻炼培养。如果意识不足或松懈，好的能力以及机制流程也会形同虚设。

    永远要敬畏线上，敬畏客户体验。面向线上的稳定性战术上可以基于专业度锻炼后自信，但战略和思想上必须持续如履薄冰、三省吾身。

    线上稳定性保障是作为技术人自己专业度的追求和必须保持初心，始终保持敬畏。不因为业务繁忙、个人心情状态、团队是否重视而有变化，只要职责在，就要守护好。技术主管以及系统owner要有持续感知稳定性隐患和风险，保持锐度，集中性以及系统性查差补漏。

    一个用户反馈背后必然有多个实际线上问题，只是这个用户无法忍受，知道反馈路径以及对这个产品有热爱或强依赖才选择反馈的。彻底定位一个voc，就是修复了一类线上问题。而且到用户反馈的程度，这个线上问题就已经有一定程度用户体验影响了。

    技术团队要有一个voc日清机制，针对线上voc问题对用户做好日内响应答复，也是一个不错对于这个意识的数字化衡量。

    稳定性建设不容忽视，稳定性是前缀1和0的关系，稳定性是业务持续发展的必要条件。

voc: Voice of Customer

稳定性建设概览

稳定性治理

    上线前、上线中、上线后三个阶段进行总结稳定性治理

核心要点

• 预防为先

  • 需求开发中优先考虑系统稳定性（eg：容量评估、强弱依赖梳理、单元测试、压力测试、灰度测试、系统测试、回滚预案 等）

  • 日常演练和压测不可少，应急预案一定要有（eg：数据库故障、缓存故障、网络故障、磁盘故障 等）

  • 每个报警不要放过，每个报警及时响应处理

  • 每个用户反馈要重视，定位到根本原因

  • 完善监控体系，提炼核心指标，保障报错及时感知（eg：mysql 慢查询、redis 慢查询、接口p99耗时、接口失败率 等）

    • 延迟：服务处理某个请求所需要的时间。能够区分请求成功和失败这点很重要

    • 流量：使用系统中的某个高层次的指标针对系统负载进行度量。比如每秒 HTTP 请求数量等。

    • 错误：请求失败的速率，显示、隐式、或者是策略性导致的失败。

    • 饱和度：系统中某种受限资源的具体度量，比如 CPU 、内存等

• 变更规范

  • 很大一部分故障都是由于变更导致的，需要制定变更规范，而且要遵守变更规范

  • 操作窗口期设定（避开高峰期、避开节假日）

  • 分级发布（蓝绿发布、金丝雀发布 [灰度发布]、滚动发布）和 效果检查

  • 故障及时通告，严禁故意隐瞒（让公司其他业务和领导感知、降低故障影响时长）

• 应急处置

  • 遇到故障先止损，然后再定位原因

  • 应急手册

  • on-call，check list 建设

• 复盘改进

  • 线上问题要复盘，不论是否为定级故障，不论问题大小

  • 故障需要在3日内复盘，相关改进工作要抓牢和落实

  • 故障复盘和记录，建立经验库，积累经验教训，降低故障发生和重发

• 琐事改进

  • 琐事被定义为手动性、重复性的、可以被自动化的、突发的、没有持久价值的、与服务同步线性增长的

  • 救火很重要，但是疲于一直救火，会阻止你去思考该如何从本质上去解决问题

  • 任何需要人工操作的事情都只会延长恢复时间。一个可以自动恢复的系统即使有更多的故障发生，也要比事事都需要人工干预的可用性更高

编码军规

需要一个 stop doing list

参考文档：

SRE与稳定性建设

• 系统稳定性建设实践总结-阿里云开发者社区

• SRE（运维）最重要的是什么

• 稳定性全系列（一）：如何做好系统稳定性建设

• 稳定性全系列（二）：如何做线上全链路压测

• 系统稳定性治理最佳实践

• 换个角度聊系统稳定性建设

• 互联网大厂，常见研发线上事故总结

• 【研发管理】-谈系统稳定性建设之认知篇

• 读《SRE：Google运维解密》一点思考

• 从70万字SRE神作，我提炼出7千字精华与君共勉

• 《SRE Google 运维解密》笔记

• 《SRE Google运维解密》读书笔记

• SRE体系

• 《SRE Google运维解密》-谷歌公司

工具技术

• 写给工程师的十条精进原则

• 灰度发布、蓝绿发布、滚动发布，有什么区别？

• 饿了么工具框架技术

• Design principles - AWS Well-Architected Framework

• 代码评审的18个军规

故障复盘

• 互联网人故障复盘流程 | 人人都是产品经理

• 故障治理：如何进行故障复盘-腾讯云开发者社区-腾讯云

• 运维必备规章制度：故障分级和处罚规范 – 运维派 - 掘金