前言
面试的时候经常问到的一个点就是怎么保障线上的稳定性。这里就按照我的经历结合看过的一些书总结一下。
SRE 的定义
SRE 本身就是要用软件工程的方法论来解决运维领域的问题。我觉得作为一个职场人，很多时候我们不能把自己局限在自己职位的视角，要以更多的角度去看问题，才能更好的解决问题。我对自己的定位就一个软件工程从业者。就 SRE 来说，要能从整个软件生命周期来看待运维所面临的问题。
下面就来说说保障稳定性，主要从以下的方面入手：
软件生命周期管理
- SRE 在项目初期就参与进去，在设计阶段就应该把高可用，可扩张性等非功能性需求考虑进去
- 产品的不同阶段对可用性要求不同，不能一概而论，我们工作的首要目标是辅助业务成功
CICD
问题越早发现，解决的成本就越低
- 做好 CI，并且严格执行，比如单元测试通过率，代码重复率等必须明确标准
- 将部署和发布解耦，比如金丝雀，灰度，蓝绿等
- 功能开关
请求的全生命周期
也可以称之为端到端的请求监控
- 客户端打点的监控
- 后端全链路的服务治理
- 服务分级，不能太多，google 之前是 4 级，最近看的是 6 级，不是越多越好
- 防止连锁故障
- 限流，降级
- 超时，重试
- 各级缓存，区分容量缓存和延迟缓存
标准化
因为我做的运维工作大部分是从 0 到 1 或者从 1 到 10 的这种，所以对标准化的体会很深。标准先行，是一个很重要的原则，标准定义的对不对、好不好其实不太重要，关键是一定要有，并且要能落地，符合这两点就可以开始做了。然后要尽量符合精益的原则，有问题可以用改。
监控和告警
这里说几个点吧
- 过度追求 100% 的可用性是没有实际价值的，要定义一个产品、研发等所有利益干系人都认可的 SLO
- 告警要分级，我比较推崇 Google SRE workbook 中的做法。这里面把告警分了三级
- 所有的告警都应该有人跟进，做得好的话，对应的告警要有工作手册
还有就是监控分为：
- 基础设施监控，CPU，内存等
- 应用监控，流量，延迟，负载，错误四个黄金指标
- 业务监控
变更管理
- 管控规范流程定义，所有变更可监控、可灰度、可回滚
- 所有变更可追溯、可评审
- 变更自动化
自动化
我觉得对自动化总结的比较好的就是，事情做第一遍的时候手动就搞了，第二遍的时候就开始发现重复性了，要开始想怎么自动化，第三次就要做的时候就要把这个事情自动化掉。
简单性
简单性，架构的稳定性一定是对简单性不断追求的结果。软件工程的第一要务就是控制其复杂度。
事后总结
无指责的回顾会议
SRE 的道
上面说的都是具体方法，也就是术的部分，有句话我印象比较深刻“有道无术，术尚可求也。有术无道，止于术。”就是做事情的时候不要只是去做，而是要明白我们这么做背后的原则，下面是我觉得比较重要的道：
- 任何一个运维对象的添加，我们都应该谨慎
- 胆大心细，做事情要敢做并且要思考全面
- 取势明道优术，要弄清楚具体的背景，方案要能落地
- 尽量给别人解决问题，不要给别人添加问题
- 优先做重要的事情，识别出紧急但不重要的事情，想明白怎么做 20% 的事情，解决 80% 的问题。
