关于SRE问题的一些思考

背景

最近在看赵成老师的SRE实战手册课程，开篇中有一张关于SRE的问题清单，个人觉得可以引发强烈的思考，特意取出放在这里，有些我提供了自己的看法，未答复的问题，欢迎读者在评论中解答。

问题清单

问题与答复

1.SRE到底是什么？到底能帮我们解决什么问题？

SRE(Site Reliability Engineer)网站可靠性工程师，为企业站点解决稳定性的问题，非稳定性表现例如：站点响应速度慢，活动导致功能不可用等; 如果要追溯SRE为何出现，要解决什么问题，我们可以追溯它的起源。

2.类似的方法论还有DevOps，AIOPS，以及最新的混沌工程，他们之间有什么区别？

DevOps的核心是做全栈交付；SRE的核心是稳定性保障，关注业务活动；混沌工程的核心是不断破坏并修复它以此来加强稳定性，可以理解为稳定性保障的一种实践方法；DevOps与SRE的共性是：都使用软件工程解决问题。DevOps的诞生是由于互联网商业市场竞争加剧，企业为减少试错成本，往往仅推出最小可行产品，产品需要不断且高频的迭代来满足市场需求，抢占市场(产品的迭代是关乎一整条交付链的事)，高频的迭代则会促使研发团队使用敏捷模式，敏捷模式下对运维的全栈交付能力要求更严格，则运维必须开启DevOps来实现全栈交付；因为不断的迭代交付(也就是俗称的变更)是触发故障，非稳定性的根源，而互联网产品/服务稳定性缺失会造成用户流失，甚至流到竞争对手那里， 因此关注业务稳定性也变得十分重要，SRE由此诞生。SRE要保障业务稳定性的实践方式之一是混沌工程。

3.SRE涉及范围如此之大，我们到底应该从哪里入手建设

SRE的建设基础应该在IT成熟度较高的组织中，例如DevOps成熟度基本满足业务需求，业务监控，基础监控，全链路跟踪监控都已初具规模。寻求一个业务稳定性相关的痛点(例如高并发导致功能不可用，响应慢等)，对该痛点制定合格水平线，且需要相关方达成一致。对关键业务链路指标进行统计分析，而后为合格水平线展开活动

4.在稳定性技术体系的建设上，我们做了大量工作，为什么还是故障频发，频频诱惑，难道单纯的技术保障还不够吗？

5.每次出故障，我们都觉得响应速度和处理效率已经很高了，但是为什么业务部门和领导任然不满意，总是指责我们开发和维护的系统不稳定？

6.每次故障之后，最害怕的就是开复盘会，开着开着就变成了*会，有时候问题还没定位清楚，就开始推诿扯皮谁应该背锅了，真不知道开复盘会的目的是什么？

7.引入了SRE，我们团队的能力应该怎么提升？组织架构应该怎么匹配？

建立SRE能力模型与成熟度模型

8.SRE的要求这么高，作为个人，我应该如何提升自己的能力达到SRE的要求？

个人认为IT技术迭代较快，难以用一个技术栈或能力清单来证明达到了SRE的要求，这里只给一些自己的建议：认真研读SRE体系，理解SRE理念，用思想领导技术；挑选认为正确的可以解决自身业务问题的理念，将其引入组织进行实践，去检验它是否为真理。实践结果如果正确则放大它，实践中需要什么就学什么，跟着时代不断产出SRE最佳实践就算是一名合格的SRE了吧！