稳定性建设四要素：人、工具、预案、目标
稳定性建设四个方向：根基牢（45%）日常（30%）预案（15%）容量（10%）
一、稳定性建设四要素
人、工具、预案和目标。
（1）人
主导是开发、测试和运维，还有安全、产品等参与，在OKR中背负一部分，合规化，有迹可循，
1）编码规范：对外接口命名、统一异常父类、异常码规范、对外抛异常还是返回错误码、统一三方库版本、哪些场景必须用内部公共库、埋点日志怎么打、统一日志、监控切面实现等
为什么统一异常父类和异常码：统一后，很多切面就可公共库做，如监控、出入口日志打印，异常拦截，压测标识透传、特殊的字段埋点等。例：可能不同模块异常父类不同的，订单模块异常父类OrderException、交易支付TradeException，OrderException和TradeException的父类BizException（定义在通用共公共库中），统一200代表正确码，异常6位数字（前3位模块，后3位异常类型），
2）公共库：内部公共库（也升级迭代），如日志库、HTTP库、线程池库、监控埋点库等，都“久经考验”应强制用，。
3）项目结构规范：统一结构快速接手项目
4）数据库规范：库名、表名、索引、字段、分库分表规范明确，分表数不用2的幂（很多人认为计算分表时用位运算更快，这个开销相比数据库操作可忽略），1024张表用质数（接近1024的1019），数据分的更均匀。
（2）工具
能做什么？做到什么程度？如何降低稳定性工作成本？
日志采集分析检索（滴滴Arius）、监控告警（滴滴Odin Metrics）、分布式追踪系统（Google的Dapper、滴滴把脉）、自动化打包部署（滴滴One Experience）、服务降级系统（滴滴SDS）、预案平台（滴滴911）、根因定位（记录所有故障发生前所有系统变更事件）、放火平台等。
内部公共库，接入Odin Metrics和把脉几乎不要做额外工作（接入把脉要提日志采集工单，头疼），不要吝啬工具投入，用或参考开源框架
（3）预案
故障时通知：团队内其他成员、Leader（寻求帮助）和客服、上游业务开发等可能影响方
选出协调者，什么情况选
协调者职责：排查和止损，避免介入同学重复工作，持续和影响方沟通。
操作开关谁决策：对于排查问题和止损同学来说，查代码看开关名，关掉一个功能需多个开关，什么条件能操作
止损方式、原则，善后方案谁拍板
（4）目标
星辰花将故障分成P0至P5六个等级，P0、P1、P2属重大：
二、稳定性建设四个方向
（1）根基牢（45%）
CR：闭环搞定，时间长容易懈怠，大于4人日项目进小黑屋CR
设计：讲最终和淘汰方案！
提测：补单测、自测、联调、通过用例
上线流程：小流量集群灰度（单量少城市做小流量集群），再线上灰度，观察线上大盘和日志，有问题快回滚
（2）日常工作在（30%）
监控告警、及时消灭线上小隐患、跨团队沟通、复盘、定期会议来总结
（3）预案（15%）
去定位和止损复杂的线上问题时。紧急预案重要，动态预案才有效
1）分场和完善：分场景整理如MySQL、MQ、发单接口故障。如有损，副作描述清楚。
2）验证预案：借助放火平台和降级系统，给主流程非核心依赖注入故障
（4）容量（10%）
老板问你明年单量要Double要预算，要规划你凭什么给？压测容量来预估。摸到分布式系统中“短木板”才知道系统吞吐量（容量）
投入10%的精力来摸容量、扩容量、水位预警等。线上有大约10%故障和容量有关，扩容三点：
1）全链路压测：老瓶颈可能消失，新的出现，之前结果失效，定期去摸这个阈值。
2）扩容演练：紧急时候，弹性云扩容比修改阈值重新上线更快
3）多活建设
