读书笔记（SRE：Google运维解密）：第1章 概览

• SRE究竟是如何在Google起源的？
  SRE就是让软件工程师来设计一个新型运维团队的结果
   

• SRE团队成员具有如下特点：
  （a）对重复性、手工性的操作有天然的排斥感。
  （b）有足够的技术能力快速开发出软件系统以替代手工操作。
   

• Google的经验法则
  SRE团队必须将50%的精力花在真实的开发工作上
   

• DevOps
  核心思想是尽早将IT相关技术与产品设计和开发过程结合起来，着重强调自动化而不是人工操作，以及利用软件工程手段执行运维任务等
   

• SRE团队要承担以下几类职责：
  可用性改进，延迟优化，性能优化，效率优化，变更管理，监控，紧急事务处理以及容量规划与管理
   

• Google SRE的几个核心方法论
  （a）确保长期关注研发工作
  （b）在保障服务SLO的前提下最大化迭代速度
  （c）监控系统
  （d）应急事件处理
  （e）变更管理
  （f）需求预测和容量规划
  （g）资源部署
  （h）效率与性能
   

• 事故事后总结应该包括以下内容：
  （a）事故发生、发现、解决的全过程，
  （b）事故的根本原因，
  （c）预防或者优化的解决方案。
   

• 如果100% 不是一个正确的可靠性目标，那么多少才是呢？这其实并不是一个技术问题，而是一个产品问题。要回答这个问题，必须考虑以下几个方面：
  （a）基于用户的使用习惯，服务可靠性要达到什么程度用户才会满意?
  （b）如果这项服务的可靠程度不够，用户是否有其他的替代选择？
  （c）服务的可靠程度是否会影响用户对这项服务的使用模式？
   

• 监控系统应该只有三类输出
  （a）紧急警报（alert）
  （b）工单（ticket）
  （c）日志（logging）
   

• 评价一个团队将系统恢复到正常情况的最有效指标：MTTR

可靠性是MTTF（平均失败时间）和MTTR（平均恢复时间）

 

• 变更管理的最佳实践是使用自动化来完成以下几个项目：
  （a）采用渐进式发布机制。
  （b）迅速而准确地检测到问题的发生。
  （c）当出现问题时，安全迅速地回退改动。
   

• 一个业务总体资源的使用情况是由以下几个因素驱动的：
  （a）用户需求（流量）
  （b）可用容量
  （c）软件的资源使用效率