mycre
mycre

SRE的组织闭环在不同的公司和不同的业务线可能会有不同的方式进行闭环，我现在所有企业是以提供IAAS层服务的，由于设备量是万为单位的，根据需求，企业在原有专业组和各软硬件设备提供商之外，组建了CRE架构团队、总控调度团队、质量管控团队。这里对其分工和google体系中的提到内容也简单的做下比照和介绍。

CRE团队（SRE是站点可靠性工程师，我们将其改为云可靠性工程师，后面两者有时会混用，其作用可以理解为一样的）的主要职责是以软件思想和工具思路解决大多数的手工工作并提高效率；专业组侧重于日常维护、平台分析和配合CRE生产工具，并逐步向CRE团队中靠拢；总控是前期是主要CRE服务的对象，其通过on-call调度和工具的使用，指明问题的调度和升级方向（也会有一些直接通过工具完成解决）；质量主要是基于事件和故障进行分析，指出需要优化的点和需要提高的目标；CRE基于质量分析结果又产生新的需求和新的优化工具的产生。最终的结果是通过几个闭环设计，实现大部分的操作都可以通过工具化实现无人驾驶。

一、CRE团队

这里的CRE团队首先是以虚拟团队的概念提出的，这点在google体系的组织中也提到过没有SRE的SRE实践、寻找第一位SRE、组建SRE团队。我所在的企业也经历了这一过程。首先是在没有SRE工程师的情况，先从SRE的理念和做事做起，慢慢的演化出第一个SRE工程师，以这个工程师开始组建虚拟团队，通过需求和工具生产，拉入专业组的专家进入SRE虚拟团队，在工具完成后，虚拟团队中的人员回归到之前的专业组。通过工具的历练，完成部分专业组人员到SRE人员的理念和角色转换，并逐步完成SRE团队的组建。这里的SRE团队是比较重要的一环，其既可以认为是起始环，也可以认为是终止环，而且是上面另外三个小组相关的架构环。

这里SRE工作的职责主要是：工具需求的评估立项和建设，完成工具向总控和专业组的交付（前期以向总控交付为主），协助总控完成SRE中的on-call角色转换，通过分析质量反馈的问题进行新的需求和优化。

二、专业组团队

这个和大多数企业中技术部门组织架构对应，其工作职责就是完成硬件的更换、版本的升级、设备的监控、工具和环境的部署等等这类工作。当然这里面会不乏有想法的人，他们会比较认同devops理念，也会自己开发出一些工具。但想要完成SRE的转换，有时会发现还缺一些什么。这个团队在企业中是重要的资源，这部分技术工程师是向SRE转换的主要力量。不过专业组也有很大一部分初始会对SRE很是排斥，理由很简单，比如：我们搭建的监控工具很好啊，每次出现事件或故障都能报出来，为什么SRE还要再造炉子生产出一个新的监控平台出来？为什么老是提SLI、SLOt这种东西，我做好自己的事不就完了。

三、总控

这里为什么没叫监控团队，没叫on-call团队，我们希望就是这个团队能在事件和故障中能把所有的流程都控起来了，起到一个统一调度的作用。所以这个团队是最初SRE团队的服务客户，其次才是其他团队。

第一阶段：SRE向该团队提供的工具是收敛类的判断工具，如业务是否受影响、降质还是阻断。同时还要给其设计匹配的升级调度、人员拉通机制，其也通过不断总结形成极期具有建议性的问题处理建议。

第二阶段：当度过这个初级阶段，SRE就需要通过一些工具和自动化的自愈手段，将一些二线人员才能处理的事件移交到总控，其有了更多的手段完成事件的闭环或事件的诊断，甚至能对二线给出的结果进行有力的质疑，实现更小的MTTI（故障发现）和MTTR（故障恢复）。

第三阶段：通过线上化的数字调度及中台化的工具，可以实时掌控所有的状态，并通过工具操作来代替大部分专业组人员的工作。对后线专业组的处理可能更好的把控。

第四阶段：就是CRE团队完全融合了，实现了google提到的CRE团队人员的轮值。

四、质量

质量组的作用主要是通过总控调度事件分析和追踪故障问题的深度挖掘，形成各种问题待办及工具需求。形象的比喻其就就“督军+要帐的”。前期这部分工作可能是以手工记录和协调分析为主，后面在运营分析过程中会逐步实现数字化，为SLO的制定也会提供参考。

五、总结

这上面提到的CRE团队还是相对狭义的，在团队演变过程中，其会转换部分专业组团队人员，合并总控on-call，纳入部分质量人员，对于这个狭义的分工职责我有有一个形象的比喻：CRE是造各式“兵器”和研究“兵法”的团队，总控是冲在最一线的“战士”，专业组是经验丰富的“老兵”，质量是“督军”。广义上来说，SRE是要为产品的可靠性（云的可靠性）服务的，所以SRE的工作是需向全局的，不单单只是传统中的运维或者devops中的结合。