开篇词｜SRE是解决系统稳定性问题的灵丹妙药吗？ https://time.geekbang.org/column/article/212686
这两年，近距离地接触了很多不同类型、不同规模的企业 IT 团队，我发现他们为了提升用户价值的交付效率，都在积极采用微服务、容器，以及其他的分布式技术和产品，而且也在积极引入像 DevOps 这样的先进理念。这些公司选择了正确的架构演进方向和交付理念，效率自然是提升了一大截。这样的情况，是不是也发生在你的公司、发生在你自己身上？这时候你会发现，效率提升了，但挑战紧跟着也来了：在引入了这么多先进的技术和理念之后，这种复杂架构的系统稳定性很难得到保障，怎么办？这个问题其实不难回答，答案就是 SRE。这几年业界对 SRE 的关注越来越多，大家也几乎达成了共识，Google SRE 就是目前稳定性领域的最佳实践。也可以说，SRE 已经成为稳定性的代名词。
DevOps核心是做全栈交付，SRE的核心是稳定性保障，关注业务所有活动，两者的共性是：都使用软件工程解决问题;
DevOps的诞生是由于互联网商业市场竞争加剧，企业为减少试错成本，往往仅推出最小可行产品，产品需要不断且高频的迭代来满足市场需求，抢占市场(产品的迭代是关乎一整条交付链的事)，高频的迭代则会促使研发团队使用敏捷模式，敏捷模式下对运维的全栈交付能力要求更严格，则运维必须开启DevOps来实现全栈交付；因为不断的迭代交付(也就是俗称的变更)是触发故障，非稳定性根源，而互联网产品/服务稳定性缺失会造成用户流失，甚至流到竞争对手那里， 因此关注业务稳定性也变得十分重要，SRE由此诞生。希望看完赵老师的课程后对理论能有所提升。
比如，你想要找到建设 SRE 体系的切入点，最好的办法就是建立稳定性的标准化。有时你会和周边团队就稳定性问题产生一些争执，说到底就是因为你们没有达成共识的、统一的衡量标准。Google SRE 已经给我们提供了很好的标准化手段，也就是 SLO。你看，这个问题不就得到解决了吗？
我会把 SLO 作为引入 SRE 的切入点，因为它就相当于我们稳定性标准化的基础。同时，SLO 也是稳定性保障的共识机制，有了这个共识，我们才能更好地管理稳定性，消除掉来自周边团队的很多不理解和不认可。
关于建设 On-Call 的流程机制，我给你分享了我自己团队的“On-Call 关键 5 步法”，咱们再一起复习一下：