北京最好皮肤科医院 http://pf.39.net/bdfyc/140106/4322698.html

导读：稳定性目前不再局限于大促时的保障和平时的稳定性轮值，越来越体系化。本文基于作者在业务团队工作过程中的沉淀，以及在盒马两年SRE的实战经验，从稳定性心态、监控体系、故障应急体系、资源体系、大促保障机制、日常保障机制等几个层面，就如何做好SRE的工作进行了分享。

前言年，当我第一次接触稳定性的时候，我是有些懵的，当时完全不知道稳定性是什么，也不清楚要做什么。在接下来的8年里，我先后在菜鸟、天猫、盒马从事中间件、业务系统、架构等方面的工作，期间一直穿插着负责稳定性和大促的保障工作。我的心态，大致经历过以下几个阶段：

low：完全不懂，觉得稳定性就是做别人安排好的一些表格和梳理，不知道自己该做啥，稳定性好low。

烦：各种重复的会议，做好了是应该的，做不好就是责任，很烦很焦虑。

知道该做什么，但是累：各种报警和风险，每天需要担心，想要不管又过不了自己心里那关；大促时候天天熬夜，各种压测，最终自己累得够呛。

发现结合点：发现在采用系统化思维之后，稳定性与系统自身的结合变得紧密，稳定性成为一种基线，找到了稳定性中的关键点和重点。

主动驱动：发现线上业务和线下业务的稳定性差别，理解并主动调整在不同业务团队采取的稳定性策略，探究在稳定性中的自动化、工具化，系统化建立稳定性机制。

形成体系：形成稳定性体系化思考，明确稳定性每一个点在业务团队大图中的位置，探究系统弹性建设。

近两年来，稳定性不再仅仅局限于之前的大促保障和平时的稳定性轮值，越来越体系化，在保障体系、监控体系、资源体系、质量保障、变更管控等多个方面，越来越系统。阿里的各个事业部，也纷纷成立专职的SRE安全生产团队。然而仍有很多人和业务团队，对于稳定性的理解和认知未形成一个体系化的机制，下面就结合我在业务团队系统稳定性上的认识，以及最近年在盒马的一些思考，做一个分享。什么是SRESRE（SitRliabilityEnginring，站点可靠性/稳定性工程师），与普通的开发工程师（Dv）不同，也与传统的运维工程师（Ops）不同，SRE更接近是两者的结合，也就是年末提出的一个概念：DvOps，这个概念最近也越来越流行起来。SRE模型是Googl对Dv+Ops模型的一种实践和拓展（可以参考《Googl运维解密》一书），SRE这个概念我比较喜欢，因为这个词不简单是两个概念的叠加，而是一种对系统稳定性、高可用、团队持续迭代和持续建设的体系化解决方案。那么要如何做好一个SRE呢，这是本文要探讨的话题。一心态态度1谁适合做稳定性？就像前言里我做稳定性前期的心态一样，稳定性最初上手，是提心吊胆、不得其门而入的，所以想要做好稳定性，心态最重要，业务团队想要找到合适做稳定性的人，态度也很重要。对于业务团队，要如何挑选和培养团队中最合适做稳定性的人呢？

必须选择负责任的人

负责任是第一要素，主动承担，对报警、工单、线上问题、风险主动响应，不怕吃苦；一个不负责任的人，遇到问题与我无关的人，边界感太强的人，难以做好稳定性的工作。

原则上不要选择新人

对于团队ladr而言，“用新人做别人不愿意做的工作”，这个决定比较容易做出，但是这也相当于是把团队的稳定性放在了一定程度的风险上，用新人做稳定性，其实只是用新人占了稳定性的一个坑而已。新人不熟悉业务，不了解上下游，最多只能凭借一腔热血，对业务和系统感知不足，容易导致线上风险无法被快速发现、故障应急无法迅速组织。

不要用过于"老实"的人

这里的“老实”的定义是不去主动想优化的办法，不主动出头解决问题，但是很能吃苦，任劳任怨，也很能忍耐系统的腐烂和低效；这样的人平时很踏实，用起来也顺手，但是却无法主动提高系统稳定性，有的时候反而会给系统稳定性造成伤害（稳定性就像大堤，不主动升级，就早晚会腐烂）。

业务团队如何支持稳定性SRE人员

给资源

稳定性从来不只是稳定性负责人的事情，而是全团队的事情，稳定性负责人要做的是建立机制，主动承担，但是稳定性意识，要深入到团队所有人脑子里，稳定性的事情，要能够调动团队一切资源参与。

给空间

做稳定性的人，往往面临一个尴尬场景：晋升困难，主要是因为在技术深度和业务价值两个方面，很容易被挑战，对于业务团队，一定要留给做稳定性的人足够的思考和上升空间，将稳定性与团队的技术架构升级、业务项目结合起来，共同推动。经过集团安全生产团队的推动，目前在阿里，SRE已经有了自己专门的晋升体系。

区分责任

当出现故障时，区分清楚责任，到底是稳定性工作没有做到位，还是做到位了，但是团队同学疏忽了，还是说只是单纯的业务变化。

3开发和SRE的区别都是做技术的，很多开发刚刚转向负责稳定性时，有些弯转不过来。举个例子：对于“问题”，传统的开发人员更多的倾向于是“bug/错误”，而SRE倾向于是一种“风险/故障”，所以，两者对“问题”的处理方法是不一样的：

开发：了解业务-定位问题-排查问题-解决问题

SRE：了解业务归属-快速定位问题范围-协调相关人投入排查-评估影响面-决策恢复手段

可见，开发人员面对问题，会首先尝试去探究根因，研究解决方案；而SRE人员首先是评估影响，快速定位，快速止损恢复。目标和侧重点的不同，造成了SRE思考问题的特殊性。所以，成为一名SRE，就一定要从态度和方式上进行转变，切换到一个“团队稳定性负责人”的角度上去思考问题。4SRE心态上的一些释疑下面这些疑惑，有很多是我最初做稳定性的时候面临的问题，这里给大家分享和解释一下我的解决方法：疑惑1：做好了是应该的，出了问题就要负责任不出问题，就是稳定性的基线，也是SRE的基本目标，所以这个话虽然残酷，但是也不能说错，关键在于：你要如何去做。如果抱着一个“背锅”/“打杂”的思想去做稳定性，那么“做好没好处、做不好背锅”这句话就会成为击垮心理防线的最重的稻草。应对这种心态的最关键一点，在于“做好”不出问题这条基线，要从下面3个方面去做：（1）及时、快速的响应这是最关键的一点，作为一个SRE，能够及时、快速的响应是第一要务，遇到报警、工单、线上问题，能够第一时间冲上去，不要去问是不是自己的，而是要问这个事情的影响是什么，有没有坑，有没有需要优化的风险？这是对自己负责；同时，快速的响应，还需要让你的老板第一时间知悉，这个不是在老板面前爱表现拍马屁，而是要让你的老板第一时间了解风险的发生，一个好的团队ladr，一定是对质量、稳定性和风险非常敏感的ladr，所以，你要将风险第一时间反馈。这是对老板负责。反馈也是有技巧的，不仅仅是告知这么简单，你需要快速的说明以下几个信息：

尽快告知当前告警已经有人接手，是谁接手的，表明问题有人在处理了（这一步叫“响应”）。

组织人员，快速定位问题，告知问题初步定位原因。（这一步叫“定位”）

初步影响范围是什么？给出大致数据。（这一步方便后面做决策）

有哪些需要老板、产品、业务方决策的？你的建议是什么？（这一步很关键，很多时候是：两害相权取其轻，你的评估和建议，直接影响老板的决策）

当前进展如何，是否已经止血？（这一步是“恢复”，要给出“进展”，让决策者和业务方了解情况）

需要注意的是：如果你响应了，但是没有及时的同步出来，等于没响应，默默把事情做了，是开发者（Dv）的思维，作为SRE，风险和进展的及时组织和通报，才是你应该做的。当然，你的通报要注意控制范围，最好优先同步给你的主管和产品进行评估，避免范围过大引起恐慌，要根据事情的严重程度来共同决定，这是对团队负责。及时、快速的响应，是保证不出问题的关键，也是SRE人员赢得领导、业务方、产品和其他合作方信任的关键，赢得信任，是解决“做好没好处、做不好背锅”的基石。（）把机制建立好，切实落地前面已经说过，“稳定性从来不只是稳定性负责人的事情”，这一点，要深入到团队每个人的心里，更要深入到SRE自己心里，一人抗下所有，不是英雄的行为，在SRE工作中，也不值得赞许，很多时候一人抗下所有只会让事情变得更糟糕。作为一个SRE，想做到“不出问题”这个基线，关键还是要靠大家，如何靠大家呢？就是要落地一套稳定性的机制体系，用机制的严格执行来约束大家，这套机制也必须得到团队ladr的全力支持，不然无法展开，这套机制包括：

稳定性意识

日常值班机制

报警响应机制

复盘机制

故障演练机制

故障奖惩机制

大促保障机制

比如，如果总是SRE人员去响应报警和值班，就会非常疲惫劳累，人不可能永远