The book: https://landing.google.com/sre/books/

软件开发过程的比喻: 生娃 (软件开发), 抚养成人 (服务维护). 十月怀胎不容易, 但不能生下来就不管了, 需要花费更大的精力, 不断关注调整.

承认故障是不可避免的.

SRE vs DevOps

SRE职责:

• 可用性
• 响应延迟
• 监控告警
• 发布流程
• 资源利用率和容量预估 (简单来说在够用的前提下省钱)

SLO (Service Level Objective) -> SLA (Service Level Agreement)

避免重复, 要懒, 自动化

风险管理: 成本和收益 可用性, 和安全性一样, 是需要平衡和折衷的

衡量指标: 请求成功率

Error Budget: 调和开发和运维的矛盾, 为了上线新功能, 必须要先关注并且做好系统稳定性的工作. 一个比较容易实践的标准.

日常组成

• SWE software engineering / 开发工程师
• SE system engineering, configuration / 配置工程师
• RE release enginerring / 发布工程
  • 关注从源码到部署的整个过程

简单化 带来可靠性

• 乏味是种美德 => 消除意外复杂度
• 删除无用/冗余代码的爽快感

实践职责:

• 监控
• 应急事件处理
• 事故事后盘点
• 测试, 发布
• 容量规划
• 软件开发
• 产品设计

Software Engineering at Google

比较认同并实践的点:

• 大代码仓库共享, 减少分支
• 严格代码准入制度
• 最小变更提交
• 小步频繁发布
• 故障复盘文化
• 定期重构代码实现, 减少不必要的复杂性, 以及新同事加深对于服务的理解

个人想法

考虑到Google的体量, 书里提到的问题, 可能我们在整个职业生涯中也许都不会遇到. 没有必要特别强调自动化, 维护成千上百集群和几台服务器部署的系统. 在业务快速迭代的过程中, 自动化反而带来各种不灵活性. 在体量没有到达某个临界点前, 一味追求大公司高达上的方案是没有意义的. 规模决定了要解决的问题的本质.

现在单纯的运维和开发的职责分野是不适合的, 大部分情况开发嫌运维蠢或者怂, 而运维嫌开发乱搞, 很容易有矛盾. 开发同学, 尤其是后端, 必然是需要自己负责部署, 以及解决线上问题的; 开发运维, 需要深入到业务中来, 针对部署过程中的种种问题提供解决办法, 或者提供自动化工具, 否则很容易沦为日常被使唤的角色.