SRE Google运维解密-第一章

1. 研发（Dev）与运维（Ops）分离导致的问题

   1. 直接成本：

       随着产品及项目增多，相应人员线性增加。
      

   2. 间接成本：

       研发与运维团队背景各异，技术能力与工具使用习惯存在差距，工作目标不同；
       研发与运维团队对产品可靠程度要求不同，具体执行某项操作的危险程度评估与技术防范措施不同。
      

   以上逐渐演变成目标与方向上的分歧及形成沟通问题，容易出现信任、尊重等问题

2. 如何减少更新故障—以下两点均不是最优

   1. 运维：给研发制定严格上线流程；
   2. 研发：不再大规模更新，而是转为功能开关调整、增量更新、补丁等方式绕过各种流程。

3. SRE方法论：
   SRE团队承担以下几类原则：
   - 可用性改进
   - 延迟优化
   - 性能优化
   - 效率优化
   - 变更管理
   - 监控
   - 紧急事务处理
   - 容量规划与管理

   针对以上内容制定一套完整的沟通准则和行事规范

4. 事后总结

   所有产品事故都应该有事后总结，无论有没有触发告警；
   如果一个产品事故没有触发警报，它的总结意义更大

   它揭示监控系统存在漏洞，事故总结应该包括：事故发生、发现、解决的全过程，事故的根本原因，预防或者优化的解决方案。

5. 服务可靠性目标需要考虑的方面

   • 基于用户使用习惯，服务可靠性要达到什么程度用户才会满意？
   • 如果这项服务的可靠程度不够，用户师范有其他替代选择？
   • 服务的可靠程度是否会影响用户对服务的使用模式？

6. 监控系统
   监控系统是SRE团队监控服务质量和可靠性的一个主要手段
   一个监控系统应该有三类输出：
   - 紧急警报 alert 必须立即处理
   - 工单 ticket 可延后处理
   - 日志 logging 仅收集相关信息

7. 应急事件处理

   MTTF：平均失败时间
   MTTR：平均恢复时间

   任何需要人工操作的事情都只会延长恢复时间，尽量减少人工干预，通过事先预案并且将最佳方法记录在运维手册。

8. 变更管理

   变更管理的最佳实践是使用自动化完成以下项目：

    1. 采用渐进式发布机制
    2. 迅速而准确检测到问题的发生
    3. 安全迅速的回退改动
   

9. 效率与性能

   高效的资源利用率需要：用户需求、可用容量、软件资源使用率来驱动