《SRE运维之道》书摘：SRE反模式

所谓“反模式”，不是常见的“很久很久以前”那类的失败故事，而是我们见过的，不只是一两次，而是一次又一次重视的可怕错误。反模式是有引力的坑，往往只差那么一点点就能彻底成功。也就是那种看似常识的决定，但并不是明智的决定。

反模式1：站点可靠性运维
新的任务不能总是用旧的工具和方法来实现的。

反模式2：人类盯着屏幕
如果必须等待人类发现错误，你已经落伍了。

反模式3：事件响应时一窝蜂
眼睛盯着球：但你的脚要留在自己负责的区域。

反模式4：根本原因=人为错误
如果一个善意的人都能造成“破坏”，那意味着它就没有正常工作过。

反模式5：丢报复
轮值不是别人的事情。

反模式6：马戏团表演模式！
精英战士（英雄文化）是一个陷阱。

反模式7：警报可靠性工程
监控是为了确保业务数据的稳定流动，而不是为了产生稳定的警报流。

反模式8：雇佣他人来遛狗
配置管理不应用作拐杖

反模式9：减速带工程
预防所有错误，这对于任何视图把事情做完的人来说都是不可能的，因为代价高昂，而且很烦人。

反模式10：设计阻塞点
构建更好的工具和框架，以减少服务启动的辛劳。

反模式11：批评太多，鼓励不够
SRE是一种吸引力，而不是压力。

反模式12：推迟生产环境发布
过于谨慎的推新会产生更大的问题。

反模式13：优先避免故障而不最求快速恢复（MTTF>MTTR）
失败是不可避免的，善于处理他，而不必尝试完全避免它。

反模式14：依赖性地狱
依赖项控制是失败域控制。

反模式15：笨拙的治理
你不能像开超级巨轮一样操纵蚊子舰队。

反模式16：考虑不周的SLO
SLO既不是主要技术度量，也不是静态度量。

反模式17：让人恼火的API接口
单纯服务器端的SLO只能保证客户端的故障。

反模式18：修复运维团队
组织产生他们重视的结果，而不是某个部门追求的结果。

那么，这就足够了吗？
最重要的事情是过程（最根本的SRE过程）：持续审视我们和同行遇到麻烦的地方，然后不仅为我们自己的组织创造学习机会，而且把那些失败的目录编成故事，可以分享到整个行业。