背景mysql
"个人代码太完美了，不可能有bug!" 不知道你们有没有过这样的自信。咱们团队的代码观：“是代码必定是有bug的。要考虑好充分的兜底以及紧急预案。”程序员
不能将碰运气当成战略 --《SRE Google运维解密》sql
WHAT数据库
编写代码的「八荣八耻」编程
1. 产品命名：以简单有趣为荣，以平庸难记为耻。缓存
2. 单个方法：以短小精悍为荣，以冗长费神为耻。架构
3. 代码维护：以持续重构为荣，以停滞不前为耻。并发
4. 编程思想：以面向对象为荣，以面向过程为耻。框架
5. 程序设计：以开关上线为荣，以自信编码为耻。运维
6. 接口定义：以用户易用为荣，以复杂歧义为耻。
7. 断言分支：以实时报警为荣，以忽略分支为耻。
8. 报警策略：以定时调整为荣，以放弃维护为耻。
WHY
SRE（Site Reliability Engineering站点可靠性工程师)。在《SRE Google运维解密》里提到世界上第一个SRE，玛格丽特教授。
玛格丽特带着她的小女儿拉夫劳伦一块儿来到公司，在飞行模拟测试时，拉夫劳伦偷偷地按下了控制台上的DSKY键。整个模拟程序意外崩溃，发射程序终止。玛格丽特和组员调试后发现，拉夫劳伦意外触发了P01子程序的执行。若是在火箭飞行过程当中执行这段程序，后果不堪设想。
玛格丽特为此提交了一个软件改动，申请在飞行程序中增长一项特殊状态检查避免这个问题。但NASA管理层认为这个错误发生的可能性过小，没有经过。玛格丽特只能在飞行手册中添加一段文字：请勿触发P01程序。
几天后，阿波罗8飞船执行任务时，宇航员意外触发了P01程序。幸亏玛格丽特的飞行手册更新中提到了这种情形，并提供了有效的解决办法。
不管对一个软件系统运行原理掌握得多么完全，也不能阻止人犯意外错误。--玛格丽特教授
HOW
这里主要介绍三种开关：版本切换开关、调参配置开关、灰度流量开关。
版本切换开关
新版本上线，上线若是发生问题，一个解决方法是：回滚代码。线上服务由多台机器组成，滚动回滚是须要较长的时间的。通常来讲须要几分钟到几十分钟不等。更有效的方法是在编码阶段对于改动都设置开关。出现问题当即切换到老版本。
稳定性的要务之一：「消除临时代码」。因此通常运行两周版本确认稳定后要将切换开关及原来的老版本代码下线。
开关咱们团队用的是配置管理实现的，开源的有zookeeper的实现。美团用的是OCTO的MtConfig。
调参配置开关
举一个场景：mysql数据库常常是被认为很是稳定的基础设施，甚至有的团队在作架构设计的时候原则是：消息中间件挂了，咱们须要thrift直连降级；缓存挂了，咱们降级直接走持久层。可是若是mysql挂了，咱们就挂。
mysql挂的场景确实很少见，常见的状况是咱们本身没有用好。好比：容量没有作合理预估。好比创建物理链接时间时长不合理。数据库链接有一堆参数设置，建议放到配置管理里去配置。
缘由：随着在线上的运行，QPS升高，不断加新功能等形成的对数据库压力。有可能形成预估或者测算出合理的参数再也不合理，为了应对突发问题，建议测算值做为默认值，同时可动态修改配置。
灰度流量开关
大功能上线通常须要灰度，以避免不符合预期形成较大损失。一个建议的策略是若是自己QPS较高，那么能够按照SLA(Service-Level Agreement服务等级协议)可容许的错误预算来设置灰度粒度。
好比，系统从年初一直运行良好，没有出现过问题。此次要上线了。对外承诺SLA3个9。那么第一次灰度的流量能够按系统0.1%来灰度，那么就算出现问题了，三天内能够恢复，也能够保证咱们的SLA。
总结
不要靠巧合编程 --《程序员修炼之道》
相关阅读