SRE Google 运维解密，是 SRE 畛域的启蒙之作，讲述了 Google 的 SRE 实际，SRE 就是从 Google 流传进去的。本文是读书笔记，第一篇，概述 SRE 方法论。帮大家把书读薄，当然，也退出了一些我的集体了解，心愿对你有帮忙。
为何须要 SRE
传统的 sysadmin 的形式，偏手工运维，机器越多所需运维工程师越多，对于 Google 的体量（毛估估当初大略有几百万台机器）和增长速度，老本（人工成本、治理老本等）不可接受。
因为指标不同、技术背景不同、对可靠性了解不同，传统运维和产品研发团队之间，很容易造成微小的鸿沟，有时会回升到部门之间的信赖和尊重层面。比方拿变更举例，研发部门想要：“随时随地公布新性能，没有任何拦截”，传统的运维团队想要的则是：“一旦一个货色在生产环境中失常工作了，就不要再做任何改变”。这样的两个团队，是没法很好的单干的，尤其是在 Google 的体量和增速下，得改。解法就是 SRE。
Google SRE 概述
Google SRE 的创始人是 Benjamin Treynor Sloss，研发出身，2003 年退出 Google，被任命领导一个 7 人小组（当初，SRE 团队曾经上千人了），负责“生产环境保护”。Google 过后的增速是十分快的，如果依照传统的玩法，招人的速度齐全无奈匹配机器增速，怎么做这个“生产环境保护”的工作呢？
Benjamin Treynor 是资深研发，天然就会思考用软件工程的伎俩来解决遇到的各类问题，所以 Google SRE 首先，得具备研发技能，用研发技能来解决各类生产保护反复工作。他们具备如下特质：
- 对重复性、手工性的操作有人造的排挤感
- 有足够的技术能力疾速开发出软件系统以代替手工操作
然而，做过运维的人都晓得，总有一些日常运维的工作无奈防止，有时基本没工夫写代码，比方解决工单、手工操作，尤其是在基础设施平台工程不齐备的状况下。这可咋整？
Google 提出了 50% 的准则，即日常运维的工夫不能超过 50%，即须要至多拿出一半以上的工夫来做工程研发，釜底抽薪，用工程伎俩解决手工操作。那有的时候，日常运维工作沉重，超过了 50% 工夫分配原则，怎么办？把相干工作交给产品研发团队的 leader，让他来帮忙消化掉一部分工作。研发 leader 一看，运维侧的工作好多啊，是不是咱们的软件不够鲁棒、很多应该主动解决的逻辑没有主动解决，就会去改良，造成正向循环。当然，这个机制须要公司管理层强力推动。如果遇到一个研发团队说，运维的活你们运维干不完，干不完能够招人啊，管理层也不作为，就完了。
DevOps 还是 SRE
Benjamin Treynor 认为，SRE 是 DevOps 模型在 Google 的具体实际， 带有一些特地的扩大 。
SRE 技能组成
理论的人员组织来看，SRE 团队分两类人，一类就是纯研发，一类是具备八九成研发能力，同时还懂一些 UNIX 常识、网络常识。如果国内运维团队想要转型为 SRE 组织，就这个技能要求就很难达成（其实除了 Google，其余国外的公司也很难做到）。咋办？
国内的组织的做法：一个人能力无限，弄个团队来顶上，团队里既有只懂研发的人，又有只懂网络的人，又有只懂操作系统的人，应该就能够了吧。集体的认识是，这个做法根本是对的，然而不齐全够。因为尽管是一个团队，然而不同的小组或集体的常识依然是无奈齐全共享的，这使得在做工程决策、实际的时候，没法做到像 Google SRE 那样如臂支使。
略微改良一下的做法是：团队里依然要招聘一两个 SRE 专家，权且称为 SRE COE，既懂开发又懂运维的那种，兼顾所有工作，而后那些单方面的技能人才，辅助 SRE COE 来实现工作，绝对会更靠谱一些。
SRE 方法论
SRE 团队的职责：可用性改良，廷迟优化，性能优化，效率优化，变更治理，监控，紧急事务处理以及容量布局与治理。要转型的团队留神了，用软件工程的伎俩达成以上指标，就阐明你们团队转型胜利了:)
在保障服务 SLO 的前提下最大化迭代速度
变更是万恶之源，生产环境中的故障，大略有 70% 都是变更引起的。屁股决定脑袋，运维团队就心愿尽量别有变更，研发团队要上线新 feature，那就须要频繁变更，咋整？Google 提出了“谬误估算”的理念。
产品首先得确定 SLO，比方某个服务的季度 SLO 指标是 99.99%，那不可用的 Quota 估算就是 0.01%，每个月依照 30 天来算，一个季度 90 天，容许的不可用分钟数是：
90 * 24 * 60 * 0.01% = 12.96 分钟 ≈ 13 分钟 只有服务的季度不可用时长低于 13 分钟，轻易折腾，然而一旦超过了 13 分钟，阐明 Quota 用光了，就不能随便上线了，非得要上线，行么？也行，VP 审核通过吧。那意思就是：你看这个研发团队，上线老是出问题，不可信赖，当初又要上线了，SRE 是不筹备放行了，VP 大佬来决策吧，VP 大佬也非要容许上，那就上。
咋样，这个办法听着不错吧。贵司能够试试。这里要留神，服务要想缩小故障时长，是须要有良好的基础设施保障的，比方研发上线发现问题，想回滚，后果部署零碎不牢靠，这找谁说理去。所以，谬误估算这个办法能够用，然而不同的公司，SLO 的阈值得审慎制订，没有金刚钻不揽瓷器活，基础设施很烂，SLO 就定低点吧。
SLO 谁来定？
SLO 应该是业务来定，然而 SRE 要提供一些信息，通知业务达成什么样的 SLO 要付出什么样的老本 ，业务有了这些信息了，再来确定制订什么样的 SLO。比方某个业务不盈利，就是个试验性质的业务，SLO 低一点很失常，具体要看业务自身的决策，所以 SLO 的制订须要业务拍板。
监控零碎
外围要学习的是：每个须要告诉到人的告警，必须对应 Runbook，即预案手册。如果一个告警收回来，没有人响应，没有相应的动作执行，这个告警就是有效的。Runbook 链接个别配置在告警规定里，比方 Grafana、Nightingale、Datadog 的告警规定配置，都反对这么干。告警规定的 Runbook 预置率是一个很好的告警治理指标。
有些告警能够不必立刻解决，然而至多得创立个工单留待后续解决。
应急事件处理
提前准备好 Runbook，即预案手册，比即兴施展，成果好 3 倍。
变更治理
要自动化！要自动化！要自动化！自动化实现以下我的项目：
- 采纳渐进式公布机制
- 有良好的监控零碎，能够疾速发现问题
- 当问题产生时，能够平安回滚
需求预测和容量布局
要思考的点包含：
- 天然增量：随着用户天然增长带来的增量
- 非天然增量：比方市场流动
- 周期性压测：这点很要害，这点很要害，这点很要害，通过压测才晓得你的零碎瓶颈在哪个微服务，能力把零碎原始资源和业务容量对应起来
资源部署
扩容须要部署资源，变更也须要，这就是 Borg 的作用，其余公司能够采纳相似 Kubernetes 的计划。不论应用什么计划，可能疾速、正确的实现部署，最大化资源应用，就能够了。
效率与性能
SRE 也须要关注服务性能，晋升了性能，其实就是进步了资源利用效率，同样的硬件能够撑持更大量的客户。NetFlix 有专门的 Performance 工程师，Google 的话 SRE 一并干了这个事件。
小结
SRE 团队的职责：可用性改良，廷迟优化，性能优化，效率优化，变更治理，监控，紧急事务处理以及容量布局与治理。咱们要用软件工程的思维来解决这些问题，完活。留个问题：
SRE 要不要批改业务代码？
比方减少一些监控埋点，或者优化一个算法晋升软件性能，或者换了一个更正当的存储？欢送大家留言探讨 :)