关键词： SRE，运营，可靠性， 故障剖析
对运维而言，相比较英文单词 operation 与 site reliability engineering （SRE）, SRE 将运维划分为一种工程和开发任务，从一个侧面调节了开发人员与运维的矛盾。 SRE的起源来自于Google。 这种实践帮助优化了下面几个方面:
a. 运维自动化
b. 双方高效沟通
c. 促使开发人员编写更高效的系统方便运维
d. 解决运维需要维持系统稳定，与开发需要上线新功能的天生矛盾
针对网站而言，以下几个实践可能是非常有效的。
1. SRE 必须会编程， 且最多允许50%的苦力劳动
a. 可以有感知且实现自动化: SRE 人员应该能够用编码解决复杂问题。当执行重复的任务多次时，他们应该有感知的自发其开发自动化方式去实现任务。在实践中，这种感知往往更加重要。很多人可能做了很多次重复的工作，但都没有把其进行自动化的想法。
另外一个限制条件是只允许SRE 存在最多50%的需手工进行的苦力劳动。这从另一个侧面促使他们进行更好的自动化。
优先自动化的工作是所需工作量最小，但能带来最大效益的
b. 有足够的开发知识: SRE 人员应该可以理解和鉴别开发人员的工作。能无障碍的与他们进行沟通。能理解什么样的方式是可行的，什么样的方式是不可行的。
2. SRE 和开发人员来自同样的候选人群
一个目的是为了满足 1 中我们所说的需求，另一个目的是我们可以为一个项目分配一定数量的工程师，当我们增加了SRE的数量的时候，我们就不得不减少开发工程师的数量。这从而促使开发人员编写更高效的系统方便运维，以减小SRE人员的需求
3. 过度的运营需求将成为开发团队的需求， 且开发团队承担5%的运维工作
这都是为了让开发团队能够更好的感知运维的需求，开发更高效的系统。
可采用８／２法则，新版本迭代分为大的，和小的发行版本：在大的发行版本中花２０％的时间在运维需求上，其他时间在重要的新功能上；而在小的版本中包含一两个高优先的功能，其他８０％的时间在ｂｕｇ修复和稳定性维护上.
4. 使用错误预算（Error Budgets)
一般的网站的稳定性需求都为4个9 （99.99%）。Wifi 一般的可用性都低于99%， 所以一般来讲4个9的稳定性就足够了。在这种情形下，我们可以刻意的在每个季度预留一些不稳定（约13分钟）的时间做为新功能测试的代价。
每个季度，当这个13分钟的预留时间没有耗尽的时候，开发人员可以自由发布新的功能。当预留时间因为新功能的bug 而被耗尽则所有发布终止。这从另一个侧面促使开发人员开发更稳定的系统。也让运维部门不再需要费心的阻止新功能的发布以维持系统的稳定度。
在软件开发的Estimation time 中，也应专门预估一些时间在系统稳定性的改善上面
5. 每个值班最多处理两个故障
为减轻运维负荷，达到更高效的运维，把每个运维的值班时间，缩短为最多需要处理两个故障。
6. 制定SLA，并根据其计量和报告性能
开发人员和SRE都对SLA负责，也都有及时交付功能的职责。这样保持开发与ＳＲＥ的目标是一致的。而非只有ＳＲＥ对ＳＬＡ负责，但对及时交付没有责任。
7. 任务分配：不应该所有人的优先级都为紧急故障
一名SRE的最高优先级应为紧急故障。一名SRE的优先级应为常规ticket. 一名SRE的优先级应为运维优化。这三个优先级可以一人专注于一周。这样保证整个团队不会疲于奔命而无法做运维优化。运维优化应该是团队最为重要的任务。
8. 执行软启动(Soft Launch)，金丝雀( canary) / 灰度测试
软启动：不公开通告新功能的启动。这样避免流量爆增，可以提供一些缓冲在大多数用户发现问题前修复问题。
９. 进行故障的事后剖析，分析过程而非职责人
对事故的剖析必须执行，隐瞒事故只会导致同样的悲剧再次重演。
对故障进行事后剖析，重点在于故障过程和如何阻止下次再发生。即使是人为因素导致的故障也应该重点放在如何从制度上避免发生，而非强调个体的失误。最近比较出名的 饿了吗 运维事故中就可以看出，其实我们可以通过从（1）自动化角度避免需要重复这样机械的劳动； （2）当操作生产环境时加入二次确认和授权机制来保证事故不会重现；（3）减轻工作量，避免疲劳操作，而不是倚赖于人不会犯错，如犯错就要遭受解雇上面。
事故剖析中， 应使用第一人称，表露对事故发生的懊恼与愧疚，而不是采用新闻官腔。尽量避免使用“可能”等词语淡化事故造成的影响。如果没有影响，那你也就不会发布剖析报告了不是？
简单的内部剖析报告应包含以下内容：
标题:
报告状态：（故障是否修复）
概述： （发生的情况，受影响的用户，及避免再次发生的关键建议／需要领导批准的部分）
事故描述： （详细描述）含操作与时间轴
受影响用户：
解决方案：（感谢在其中提供帮助的人员列表）
归因分析：
未来建议：（应该是可计量的）
