稳定性，我们都在聊些什么
稳定性的内容范畴
Google SRE 工程师在 2013 年提出了一个 7 层金字塔模型，用来描述系统可靠性(Dickerson's Hierarchy of Service Reliability)，这个模型几乎涵盖了稳定性话题下的所有内容范畴：
稳定性的治理方案
稳定性治理的两个重要原则：
- 控制新增，治理存量。控制那些爆发问题的蔓延，周期性、有节奏地安排那些疑难的存量问题修复。
- 先急后缓，先易后难。优先修复那些爆发的问题，优先解决相对容易、修复周期短的问题。
稳定性治理的几个关键环节：
稳定性建设一般性参考思路
技术视角
从技术上来看，稳定性的指导思想：
变更红线
有这么一条不成文的规律："90% 以上的稳定性问题都是由变更引起的"，因此互联网各个厂商对于变更都尤为重视。比如阿里就有一个"变更红线"原则："可发现、可预案、可灰度"，以一次新需求发布为例：
- 首先，新的功能会引入新风险，如在线上出现风险了，要有能够及时发现风险的手段，此为可发现。
- 然后，发布前，要针对可能出现的问题做好预案，当发现了问题后立即执行相应的预案，此为可预案。
- 最后，发布时，主动观察是否会有问题产生，逐步开放线上流量，此为可灰度。
有效监控
建立有效监控是及时发现线上问题的最重要的手段，而针对应用系统具体需要监控的哪些要点，笔者找到以下一份比较靠谱的参考：
摘自：《稳定性治理方法论》
有效预案
建立有效预案是保障线上问题发生时能有条不紊及时止损的最重要的手段，而针对不同的应用系统具体要建立哪些预案，则根据实际情况各有不同。但是也不乏共性，共性就在于你要对你负责的应用系统进行全面的梳理，首先要了解哪些环节可能出现哪些问题。
管理视角
从管理上来看，稳定性包括以下几个方面：
而站在团队管理者的角度，思考稳定性建设的问题，其实就是在思考如何提高团队的输出质量，而相应的流程机制、标准规范建设通常是必经之道。关于稳定性流程机制，一般性指导意见：
稳定性，难就难在没有银弹
"稳定性，难的不是技术，难就难在没有银弹，只能靠大量的细节来落地做好稳定性这个系统工程的事情，这意味着的是大量的投入，能不能在稳定性这件事上保持持续的一定的投入，甚至当成做业务功能实现一样的必须的投入，这才是真正做好稳定性最难的，毕竟就算有指导思想、解决方案、能力，但没有相应的投入，那自然只能有一定的取舍。"
------毕玄：稳定性，难的不是技术，而是......
稳定性，它至关重要但又是一个长期的挑战。 正如我们常说的："出现问题并不可怕，可怕的是问题重复出现"，一定程度上我们默认了线上问题无法被完全消灭，我们努力在阻止已知问题重复发生，同时想尽办法降低线上风险的可能性，缩小故障发生后的爆炸半径。
稳定性，难就难在没有银弹，需要依赖大量的资源投入、大量的细节落地才能做出效果。尽管有成熟的技术指导思想、稳定性建设方法论，我们依然很难做好稳定性：
- 稳定性的资源投入无法保障。当前商业竞争如此激烈的互联网环境里，资源要优先保障给商业需求的交付，在稳定性上的资源投入总是有限的，导致当下很多公司的其实是"滚动式"稳定性治理，一阵一阵的。
- 稳定性的环节冗长细致入微。稳定性建设涉及软件开发整个生命周期，想每个环节同时都做到理想状态几乎不可能。
- 稳定性的结果不容易被认可。稳定性即使做的好，也是很难被认可的。做的好，不出问题，不懂的人不知道你做了什么；做到不好，出了问题，不懂的人又跳出来说你到底做了什么。
但是，我们依然要保持清醒，稳定性建设没有银弹，需要细节和耐心。