什么是SRE
最早接触SRE这个名词还是在跟CloudFlare进行一些业务合作的时候，当时他们有一个专门的SRE团队来负责整个CDN系统的稳定性。 本着好奇的心态去了解，发现SRE的全称是（Site Reliability Engineering，aka：站点可靠性/稳定性工程师）成为一名合格的SRE需要同时具备研发（Dev）和运维（OP）的能力。同时它又不仅仅是2个职能的叠加，而是一种对系统稳定性、可用性、团队持续迭代喝持续建设的体系化解决方案。
如何做一名SRE
研发和SRE的区别
那些跟我一样从研发开始接触稳定性工作的选手在刚开始时可能会有类似的问题那就是对于稳定性相关的工作不知道如何下手，完全摸不着头脑。此外，研发和SRE在面对问题时，解决问题的思路也不一样，这也增加了适应新工作岗位的难度。
举例来说，当线上生产环境出现一个『问题』时，作为研发来说会认为这是一个『bug/错误』需要修复。而对于SRE来说，他们会认为这是一种『风险/故障』。也因此，两者对于『问题』的处理方式是不一样的。
··· 研发： 了解业务 -> 定位问题 -> 修复问题 -> 测试回归 -> 灰度发布验证 -> 正式发布验证 -> 问题修复 SRE： 了解业务归属 -> 定位问题范围 -> 协调相关人员接入排查 -> 评估影响范围 -> 决策修复方案 -> 方案实施 -> 问题验证 -> 问题修复 ···
从上面的流程可以看到，作为研发遇到问题时，更关注的是问题是否解决。至于问题解决中对于生产环境的影响可能没有那么关注。 而作为一名SRE，更关注的是故障影响范围，优先考虑止损，之后才是问题修复。
因此，如果想成为一名SRE，需要在观念上进行转变，将自己的思路切换到『SRE的节奏』上来。
谁适合做稳定性？
我一直信奉一个原则： 态度大于能力，能力大于技能。
因此，如果想在团队中推广SRE理念的话，可以先看看有没有人主动站出来揽这份职责，如果有的话那是极好的。如果没有的话，就建议从以下几点对候选人进行考察：
···
- 优先选择更有责任感的同学。负责是第一要素，能做到主动承担责任，对生产环境中遇到的问题能够做到主动响应的同学一定适合做SRE；
- 优先选择经验丰富的同学。考虑到SRE工作的特殊性，它同时要求精通业务和线上运维能力，因此经验丰富的同学在遇到问题时，比新人会更快速的定位问题、找到接口人、从而提高线上问题的响应速度，也就提高了生产环境的稳定性； ···
谁不合适做稳定性？
软件工程里有一句名言：没有银弹（There is no silver bullet），因此当我去调研一个方向时，我最关注的时这个方向的能力边界，要弄清楚它适合做什么，不适合做什么。这样才能在做技术选型时选出更合适的方案。 那什么样的同学不适合做SRE呢？我个人有一些建议：
···
- 过于『老实』的人，这里的『老实』是指那些喜欢划定边界、不愿意主动想优化办法的同学。因为稳定性这个事儿它是需要不断优化再优化，没有尽头的。就像堤坝一样，不主动升级、优化，那早晚会决堤。
- 不喜欢流程的人， 这里的『不喜欢流程』是指喜欢不按照流程操作的同学，比如上线流程中有『灰度发布』这个环境，但是可能他评估之后认为不经过灰度就可以直接上线，因此就绕过了『灰度发布』，这样的同学也不适合SRE。 ···