• SRE是DevOps在google的具体实践。
• 一件事儿有可能发生就真的很有可能发生。P01是阿波罗8号上面的一个程序，一旦被人按下，就有可能造成数据丢失，当时是有个程序员的孩子在模拟器上玩儿的时候发现的，这个时候程序员打算修复，但是被上级拒绝了，只能写到playbook里面，一单触发bug，需要重新上传数据。结果，终于有一天，一个宇航员触发了这个P01的程序，差点没回来。
• 错误预算。这个概念听起来特别新，但是放佛又是情理之中的事情。google的文化里面，尊重事实，允许犯错，但是在一个季度里面有一定的错误预算，如果快用完了，就老老实实的减少发布，避免超支。
• 发布是由程序员进行的。理由是，程序员更了解自己的程序。
• 灾难演练，备份恢复。无论何时，运维的心中都要有一个概念，即使发生灾难，那么我们还是可以生还的。在google的这么多年运维中，整个集群被抹掉全部数据的时候是有的，但是他们也就这么过来了，因为有备份，因为有预案。
• 12小时。监控数据存放在内存中的数据是12小时，能够保障在线拍错时有足够的历史数据，也能避免内存占用量过大。超时之后，被回收，或者写入硬盘。
• 区域。google将生产环境按区域划分，任何改动都以区域为代为进行，运行两个市里可以保障在数据中心维护或者意外情况下产生的单点故障问题。
  

[color=rgba(0, 0, 0, 0.75)]

on-call

[color=rgba(0, 0, 0, 0.75)]

• 事故。事件分析、处理、总结大概需要花费6个小时。因此，google认为，每12小时的轮值周期最多处理2个紧急事件。
• 在面临挑战时。一个人会主动或非主动（潜意识）地选择两种处理方式之一，以来只觉，自动化、快速行动；理性、专注，有意识地进行认知类活动。
• 工单。每个工程师每天工单数量<5,每次轮值报警时间<2。多了，SRE压力会大，小了，SRE会对生产环境生疏。
• DiRT,Google每年举办一次持续数天的全公司灾难恢复演习，针对理论性和世纪星的灾难进行演练。
  

[color=rgba(0, 0, 0, 0.75)]

有效的故障排查手段

[color=rgba(0, 0, 0, 0.75)]

• 值得警惕的是，理解一个系统应该如何工作并不能使人成为专家。只能靠调查系统为何不能正常工作才行。
• 系统正常，只是该系统无数异常情况下的一种特例。
• 故障报告的包含。定位 > 检查 > 诊断 > 测试/修复 > 修复。
• 当你听到蹄子的声音时，应该先想到马，而不是斑马。而且尤其要注意的是，当所有的可能都存在的时候，我们应该优先考虑最简单的解释。
• 相关性不等于因果关系。
• 故障报告。不是最后的，应该是出现问题的时候，报告应该采用一直的格式，写清预期是什么，实际的结果是什么，以及如何重视。
• 在故障出现的时候，保持飞机飞行是第一位的，故障和排除是次要目标。如果一个Bug有可能导致不可恢复的数据损坏，停止整个系统要比让系统继续运行更好。
• 检查。必须能够检查系统中每个组件的工作状态，以便了解整个系统是不是在正常工作。
• 对问题现象的解析
     
  • 现象：一个Spanner集群出现延迟过高的情况，RPC请求超时
  • 为什么：Sanner服务器的任务实例把CPU占满了，无法处理用户发来的请求。
  • 哪里： Spanner服务器的CPU消耗在了哪里？通过采样（profiling）得知该任务正在将日志记录排序，写入磁盘。
  • 解决方案： 重写该正则表达式，避免使用回溯（backtracking）。在代码中寻找类似的问题。考虑使用RE2，该类库保证不适用回溯，同时保障运行时间与输入呈线性关系。
    
• 最后一个修改。系统也有惯性，运行的好好地，修改了一个东西，出了问题，很有可能是这个修改的东西造成的。
• 生产日志。设计良好的系统应该有详尽的生产日志。记录整个架构中新版本部署或者配质检的更新。
• 有时候安全部门的扫描，有可能会造成程序运行异常哦。
  

[color=rgba(0, 0, 0, 0.75)]

紧急事件响应：
* 东西早晚要坏的，这就是生活。
* 当出现问题时。别惊慌失措！这不是世界末日，你也并不是一个人在战斗！
* SRE为什么要保持一些非常可靠的、西成本备份访问系统运行，因为我们这种情况下就会用到！
* 不应该小看运气的成分。
* 不管风险看起来有多小，也要经过严格完整的部署测试。
* 时间和经验一再证明，系统不但一定会出问题，而且会以没有人能够想到的方式出问题。google学到的是，所有的问题都有对应的解决方案，虽然一个面对疯狂报警的工程师来说，它可能不是那么显而易见。如果你想不到解决办法，那么就在更大的范文内寻求帮助。非常重要的是，一单紧急事件过去之后，别忘了流出一些事件书写时候报告。
* 向过去学习，而不是重复它。

[color=rgba(0, 0, 0, 0.75)]

紧急事故管理

[color=rgba(0, 0, 0, 0.75)]

• 提出那些大的，甚至不可能的问题：
     
  • 假设整栋大楼的电源坏了怎么办？
  • 加入网络设备被泡在半米深的水里怎么办？你怎么处理？找谁联系？谁来付钱？有毒应的应急计划么？你知道如何应对么？你知道你的系统会如何应对么？
  • 如果上述问题正在发生，你能够立刻最小化灾难损失么？坐在你旁边的人能够做到同样的事么？
    
• 无流程管理的事故。
     
  • 过于关注技术问题。忽略通过其他手段环节当前服务的问题。
  • 沟通不畅。
  • 不请自来。
    
• 事故流程管理最佳实践
     
  • 划分优先级：控制影响范围，恢复服务，同时为根源调查保存现场。
  • 事前准备：事先和所有事故处理参与者一起准备一套流程
  • 新人：充分新人每个事故处理参与者，分配职责后让他们自动行动。
  • 烦死：在事故处理过程中注意自己的情绪和精神状态。如果发现自己开始惊慌失措或者感到压力难以承受，应该寻求更多的帮助
  • 考虑替代方案：周期性地重新审视目前的情况，重新评估目前的工作是否应该继续执行，还是需要执行其他更重要或者更紧急的事情
  • 联系：平时不断地使用这项流程，直到习惯成自然
  • 换位思考：上次你是事故总控负责人么？下次可以换一个职责试试。鼓励每个团队成员熟悉流程中的其他角色。
    
  
  

[color=rgba(0, 0, 0, 0.75)]

　事后总结：　从失败中学习

[color=rgba(0, 0, 0, 0.75)]

• 学习是避免失败的最好办法。
• 目的是为了保证该事故被记录下来，理清所有的根源性问题，同时最关键的是，确保实施有效的措施使得未来重现的几率和影响得到降低，甚至避免重现。
• 不是一种惩罚措施，而是整个公司得到一次学习机会。确实会消耗团队的一定时间和精力。
• 事后总结条件为：
     
  • 用户可见的宕机时间或者服务质量降级程序达到一定标准
  • 任何类型的数据丢失
  • on-call工程师需要人工介入的事故（包括回滚、切换用户流量等）
  • 问题解决耗时超过一定限制
  • 监控问题（预示着问题是由人工发现的，而非报警系统）
    
• 对事不对人。如果因为某些“错误的”举动就公开指责或者羞辱某个人或团队，那么人么你就会自然地逃避时候总结。
• 我们不能修好某个人，但是可以通过改善系统和流程从而更好地协助他在设计和维护大型系统时，做出更多“正确”的判断。
     
  • 指责：我们需要重写整个复杂后端系统。在过去三个季度中，它每周都在出问题。我们一点一点修复它的问题已经烦透了！真的，如果我再收到一个报警，那我就自己重写了。
  • 对事不对人：通过重写整个后端系统可能可以避免那些烦人的报警信息继续发生，目前版本的维护手册非常冗长，学习成本很高。相信通过重写，可以减少报警信息，未来的oncall工程师会感谢我们的。
  • 最佳实践： 避免指责，提供建设性意见
    
  
  

[color=rgba(0, 0, 0, 0.75)]

对事不对人的时候总结有的时候比较男鞋，因为时候总结的格式清晰地表明了触发事故的原因。从时候总结中排除指责的因素可以使人们砸向上级汇报问题的时候更有自信。同时我们也不应该因为某个团队和个人经常写时候总结而对他们产生怀疑。一个充满相互指责风气的环境很容易让人将事故和问题掩盖起来，从而对整个组织酿成更大的灾难。

• 1
  

[color=rgba(0, 0, 0, 0.75)]

• 写作和知识共享
     
  • 实时写作：使得写作过程可以很快地手机数据和想法。
  • 开放的评估系统：使大家都可以参与进来提供解决方案，以及提高对事故处理细节的覆盖程度
  • 邮件通知：可以砸文档中给其他用户发消息，或者引入其他人来共同填写文档
  • 文档检查
         
    • 关键的灾难数据是否已经被手机起来了
    • 本次事故的影响评估是否完整
    • 造成事故的根源问题是否足够深入
    • 文档中记录的任务优先级是否合理，能否及时解决了根源问题
    • 这次事故处理的过程是否共享给了所有相关部门
      
    
    

• 建立事后总结文化

     
  • 本月最佳事后总结
  • Google+时候总结小组
  • 事后总结阅读俱乐部
    

• 最佳实践： 公开奖励做正确事的人

  
  

• SRE是DevOps在google的具体实践。
• 一件事儿有可能发生就真的很有可能发生。P01是阿波罗8号上面的一个程序，一旦被人按下，就有可能造成数据丢失，当时是有个程序员的孩子在模拟器上玩儿的时候发现的，这个时候程序员打算修复，但是被上级拒绝了，只能写到playbook里面，一单触发bug，需要重新上传数据。结果，终于有一天，一个宇航员触发了这个P01的程序，差点没回来。
• 错误预算。这个概念听起来特别新，但是放佛又是情理之中的事情。google的文化里面，尊重事实，允许犯错，但是在一个季度里面有一定的错误预算，如果快用完了，就老老实实的减少发布，避免超支。
• 发布是由程序员进行的。理由是，程序员更了解自己的程序。
• 灾难演练，备份恢复。无论何时，运维的心中都要有一个概念，即使发生灾难，那么我们还是可以生还的。在google的这么多年运维中，整个集群被抹掉全部数据的时候是有的，但是他们也就这么过来了，因为有备份，因为有预案。
• 12小时。监控数据存放在内存中的数据是12小时，能够保障在线拍错时有足够的历史数据，也能避免内存占用量过大。超时之后，被回收，或者写入硬盘。
• 区域。google将生产环境按区域划分，任何改动都以区域为代为进行，运行两个市里可以保障在数据中心维护或者意外情况下产生的单点故障问题。
  

[color=rgba(0, 0, 0, 0.75)]

on-call

[color=rgba(0, 0, 0, 0.75)]

• 事故。事件分析、处理、总结大概需要花费6个小时。因此，google认为，每12小时的轮值周期最多处理2个紧急事件。
• 在面临挑战时。一个人会主动或非主动（潜意识）地选择两种处理方式之一，以来只觉，自动化、快速行动；理性、专注，有意识地进行认知类活动。
• 工单。每个工程师每天工单数量<5,每次轮值报警时间<2。多了，SRE压力会大，小了，SRE会对生产环境生疏。
• DiRT,Google每年举办一次持续数天的全公司灾难恢复演习，针对理论性和世纪星的灾难进行演练。
  

[color=rgba(0, 0, 0, 0.75)]

有效的故障排查手段

[color=rgba(0, 0, 0, 0.75)]

• 值得警惕的是，理解一个系统应该如何工作并不能使人成为专家。只能靠调查系统为何不能正常工作才行。
• 系统正常，只是该系统无数异常情况下的一种特例。
• 故障报告的包含。定位 > 检查 > 诊断 > 测试/修复 > 修复。
• 当你听到蹄子的声音时，应该先想到马，而不是斑马。而且尤其要注意的是，当所有的可能都存在的时候，我们应该优先考虑最简单的解释。
• 相关性不等于因果关系。
• 故障报告。不是最后的，应该是出现问题的时候，报告应该采用一直的格式，写清预期是什么，实际的结果是什么，以及如何重视。
• 在故障出现的时候，保持飞机飞行是第一位的，故障和排除是次要目标。如果一个Bug有可能导致不可恢复的数据损坏，停止整个系统要比让系统继续运行更好。
• 检查。必须能够检查系统中每个组件的工作状态，以便了解整个系统是不是在正常工作。
• 对问题现象的解析
     
  • 现象：一个Spanner集群出现延迟过高的情况，RPC请求超时
  • 为什么：Sanner服务器的任务实例把CPU占满了，无法处理用户发来的请求。
  • 哪里： Spanner服务器的CPU消耗在了哪里？通过采样（profiling）得知该任务正在将日志记录排序，写入磁盘。
  • 解决方案： 重写该正则表达式，避免使用回溯（backtracking）。在代码中寻找类似的问题。考虑使用RE2，该类库保证不适用回溯，同时保障运行时间与输入呈线性关系。
    
• 最后一个修改。系统也有惯性，运行的好好地，修改了一个东西，出了问题，很有可能是这个修改的东西造成的。
• 生产日志。设计良好的系统应该有详尽的生产日志。记录整个架构中新版本部署或者配质检的更新。
• 有时候安全部门的扫描，有可能会造成程序运行异常哦。
  

[color=rgba(0, 0, 0, 0.75)]

紧急事件响应：
* 东西早晚要坏的，这就是生活。
* 当出现问题时。别惊慌失措！这不是世界末日，你也并不是一个人在战斗！
* SRE为什么要保持一些非常可靠的、西成本备份访问系统运行，因为我们这种情况下就会用到！
* 不应该小看运气的成分。
* 不管风险看起来有多小，也要经过严格完整的部署测试。
* 时间和经验一再证明，系统不但一定会出问题，而且会以没有人能够想到的方式出问题。google学到的是，所有的问题都有对应的解决方案，虽然一个面对疯狂报警的工程师来说，它可能不是那么显而易见。如果你想不到解决办法，那么就在更大的范文内寻求帮助。非常重要的是，一单紧急事件过去之后，别忘了流出一些事件书写时候报告。
* 向过去学习，而不是重复它。

[color=rgba(0, 0, 0, 0.75)]

紧急事故管理

[color=rgba(0, 0, 0, 0.75)]

• 提出那些大的，甚至不可能的问题：
     
  • 假设整栋大楼的电源坏了怎么办？
  • 加入网络设备被泡在半米深的水里怎么办？你怎么处理？找谁联系？谁来付钱？有毒应的应急计划么？你知道如何应对么？你知道你的系统会如何应对么？
  • 如果上述问题正在发生，你能够立刻最小化灾难损失么？坐在你旁边的人能够做到同样的事么？
    
• 无流程管理的事故。
     
  • 过于关注技术问题。忽略通过其他手段环节当前服务的问题。
  • 沟通不畅。
  • 不请自来。
    
• 事故流程管理最佳实践
     
  • 划分优先级：控制影响范围，恢复服务，同时为根源调查保存现场。
  • 事前准备：事先和所有事故处理参与者一起准备一套流程
  • 新人：充分新人每个事故处理参与者，分配职责后让他们自动行动。
  • 烦死：在事故处理过程中注意自己的情绪和精神状态。如果发现自己开始惊慌失措或者感到压力难以承受，应该寻求更多的帮助
  • 考虑替代方案：周期性地重新审视目前的情况，重新评估目前的工作是否应该继续执行，还是需要执行其他更重要或者更紧急的事情
  • 联系：平时不断地使用这项流程，直到习惯成自然
  • 换位思考：上次你是事故总控负责人么？下次可以换一个职责试试。鼓励每个团队成员熟悉流程中的其他角色。
    
  
  

[color=rgba(0, 0, 0, 0.75)]

　事后总结：　从失败中学习

[color=rgba(0, 0, 0, 0.75)]

• 学习是避免失败的最好办法。
• 目的是为了保证该事故被记录下来，理清所有的根源性问题，同时最关键的是，确保实施有效的措施使得未来重现的几率和影响得到降低，甚至避免重现。
• 不是一种惩罚措施，而是整个公司得到一次学习机会。确实会消耗团队的一定时间和精力。
• 事后总结条件为：
     
  • 用户可见的宕机时间或者服务质量降级程序达到一定标准
  • 任何类型的数据丢失
  • on-call工程师需要人工介入的事故（包括回滚、切换用户流量等）
  • 问题解决耗时超过一定限制
  • 监控问题（预示着问题是由人工发现的，而非报警系统）
    
• 对事不对人。如果因为某些“错误的”举动就公开指责或者羞辱某个人或团队，那么人么你就会自然地逃避时候总结。
• 我们不能修好某个人，但是可以通过改善系统和流程从而更好地协助他在设计和维护大型系统时，做出更多“正确”的判断。
     
  • 指责：我们需要重写整个复杂后端系统。在过去三个季度中，它每周都在出问题。我们一点一点修复它的问题已经烦透了！真的，如果我再收到一个报警，那我就自己重写了。
  • 对事不对人：通过重写整个后端系统可能可以避免那些烦人的报警信息继续发生，目前版本的维护手册非常冗长，学习成本很高。相信通过重写，可以减少报警信息，未来的oncall工程师会感谢我们的。
  • 最佳实践： 避免指责，提供建设性意见
    
  
  

[color=rgba(0, 0, 0, 0.75)]

对事不对人的时候总结有的时候比较男鞋，因为时候总结的格式清晰地表明了触发事故的原因。从时候总结中排除指责的因素可以使人们砸向上级汇报问题的时候更有自信。同时我们也不应该因为某个团队和个人经常写时候总结而对他们产生怀疑。一个充满相互指责风气的环境很容易让人将事故和问题掩盖起来，从而对整个组织酿成更大的灾难。

• 1
  

[color=rgba(0, 0, 0, 0.75)]

• 写作和知识共享
     
  • 实时写作：使得写作过程可以很快地手机数据和想法。
  • 开放的评估系统：使大家都可以参与进来提供解决方案，以及提高对事故处理细节的覆盖程度
  • 邮件通知：可以砸文档中给其他用户发消息，或者引入其他人来共同填写文档
  • 文档检查
         
    • 关键的灾难数据是否已经被手机起来了
    • 本次事故的影响评估是否完整
    • 造成事故的根源问题是否足够深入
    • 文档中记录的任务优先级是否合理，能否及时解决了根源问题
    • 这次事故处理的过程是否共享给了所有相关部门
      
    
    

• 建立事后总结文化

     
  • 本月最佳事后总结
  • Google+时候总结小组
  • 事后总结阅读俱乐部
    

• 最佳实践： 公开奖励做正确事的人