背景
"我的代码太完美了，不可能有bug!" 不知道大家有没有过这样的自信。我们团队的代码观：“是代码一定是有bug的。要考虑好充分的兜底以及紧急预案。”
不能将碰运气当成战略 --《SRE Google运维解密》
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。
总结
不要靠巧合编程 --《程序员修炼之道》
相关阅读
编写代码的「八荣八耻」(上篇)
《程序员修炼之道》解读
Elasticsearch的基本概念和指标
程序常用的设计技巧
到底多大才算高并发？
美团分布式服务通信框架及服务治理系统OCTO
学会用数据说话-分布式锁究竟可以多少并发？
大话高可用