Site Reliability Engineering 阅读笔记

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

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

承认故障是不可避免的.

SRE vs DevOps

SRE职责:

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

避免重复, 要懒, 自动化

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

衡量指标: 请求成功率

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

日常组成

简单化 带来可靠性

实践职责:

Software Engineering at Google

比较认同并实践的点:

个人想法

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

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

HOME