opskumu
commented
6 years ago 第一章 介绍
不能将碰运气当成战略 -- SRE 俗语
Dev/Ops 分离的团队模型问题：
- 1、直接成本。团队规模和系统负载成线性相关，共同增长
- 2、间接成本。分属不同部门，容易产生分歧，逐渐会演变成目标与方向上的分歧以及形成内部沟通问题，甚至最后上升到部门之间的信任和尊重层面。
Google 的解决之道：SRE
SRE 团队通过雇佣软件工程师，创造软件系统来维护系统运行以替代传统模型中的人工操作。
SRE 团队组成
- 第一类，团队中 50%~60% 是标准的软件工程师
- 第二类，其他 40%\~50% 基本满足 Google 软件工程师标准，但是同时具备有一定程度的其它技术能力的工程师。（UNIX 系统内部细节和 1\~3 层网络知识是 Google 最看重的两类额外技术能力）
SRE 团队成员特点
- 对重复性、手工性的操作有天然的排斥感
- 有足够的技术能力快速开发出软件系统以替代手工操作
SRE 就是用软件工程的思维和方法论来完成以前由系统管理员团队手动完成的任务。倾向于通过设计、构建自动化工具来取代人工操作。
Google 经验法则，50% 的精力花在真实的开发工作上。如何确保？不断度量每个团队的工作时间分配，团队轮值等。
DevOps VS SRE？
DevOps 是 SRE 核心理念的普适版，SRE 是 DevOps 模型在 Google 的具体实践。
SRE 方法论
SRE 职责：可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、紧急事务处理以及容量规划与管理
所有的产品事故都应该有对应的事后总结，无论有没有触发警报。事后总结应该包括以下内容：事故发生、发现、解决的全过程，事故的根本原因，预防或者优化的解决方案。
确保长期关注研发工作
Google 讲 SRE 团队的运维工作限制在 50% 以内，剩余时间花在研发项目上。
在保障服务 SLO 的前提下最大化迭代速度
产品研发部门和 SRE 之间可以通过 “错误预算” 的概念，消除组织架构冲突来构建良好的合作关系。
监控系统
监控系统是 SRE 团队监控服务质量和可用性的一个主要手段。一个监控系统应该只有三类输出：
- 紧急警报（alert） 意味着收到警报的用户需要立即执行某种操作
- 工单（ticket）意味着接受工单的用户应该执行某种操作，但是并非立即执行
- 日志（logging） 平时没有人需要关注日志信息，但是日志信息依然被收集起来以备调试和事后分析使用
应急事件处理
可靠性是 MTTF（平均失败时间）和 MTTR（平均恢复时间）的函数，评价一个团队将系统恢复到正常情况的最有效指标，就是 MTTR。
通过事先预案并且将最佳方法记录在 “运维手册” 上通常可以使 MTTR 降低 3 倍以上。Google SRE 将大部分工作重心放在 “运维手册” 的维护上，同时通过内部模拟灾难恢复的演习项目不断培训团队成员。
变更管理
SRE 的经验告诉我们，大概 70% 的生产事故由某种部署的变更而触发。变更管理的最佳实践是使用自动化来完成以下几个项目：
- 采用渐进式发布机制
- 迅速而准确地检测到问题的发生
- 当出现问题时，安全迅速地回退改动
需求预测和容量规划
需求预测和容量规划简单来说是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。
资源部署
资源的部署（provisinging）是变更管理与容量规划的结合物。
效率与性能
服务利用率指标通常依赖于服务的工作方式以及对容量的配置与部署上，通过密切关注服务的容量配置策略，进而改进其资源利用率，可以非常有效地降低系统的总成本。
序
世界上第一位 SRE，
Margaret Hamilton, MIT 教授