读书笔记 摘要
SRE是Site Reliability Engineer的简称，从名字可以看出Google的SRE不只是做Operation方面的工作，更多是保障整个Google服务的稳定性。
监控系统
监控系统是 SRE 团队监控服务质量和可用性的一个主要手段。所以监控系统的设计和策略值得着重讨论。最普遍和传统的报警策略是针对某个特定的情况或者监控值，一旦出现情况或者监控值超过阈值就触发 E-mail 报警。但是这样的报警并不是非常有效：一个需要人工阅读邮件和分析报警来决定目前是否需要采取某种行动的系统从本质上是错误的。监控不做任何事情是不可能的，有三种有效的监控输出：
警报
意味着收到警报的用户需要立即执行某种操作，目标是解决某种已经发生的问题，或者是避免即将要发生的问题。
这使我所拥有的每个设备都会产生大量的噪音。如果我在 5 分钟内没有回应，它会找到我的替代者，他的工作是采取行动。
我所在的 SRE 团队有一个送花规则，如果问题落到替代者来处理，这对主负责人来说是个悲剧，你将需要给替代者送去花和一张卡。
工单
意味着接受工单的用户应该执行某种操作，但是并非立即执行。系统并不能自动解决目前的情况，但是如果一个用户在几天内执行这项操作，系统不会受到任何影响。
日志
平时没有人需要关注日志信息,但是日志信息依然被收集起来以备调试和事后分析时使用。正确的做法是平时没有人主动阅读日志,除非处理其他请求的时候被要求这么做。
应急事件处理
可靠性是 MTTF（平均失败时间）和 MTTR（平均恢复时间）的结合结果。评价一个团队将系统恢复到正常情况的最有效指标，就是 MTTR。任何需要人工操作的事情，都只会延长恢复时间通过事先预案并且将最佳方法记录在“运维手册”上通常会使 MTTR 降低 3 倍以上。
变更管理
SRE 经验告诉我们，大概 70% 的生产事故由某种部署的变更而触发。变更管理的最佳实践可使用自动化来完成以下几个项目：
采用渐进式发布机制。
迅速而准确地检测到问题的发生。
当出现问题时，安全迅速地回退改动。
这三点可以有效地降低变更给 SRE 和最终用户带来的时间成本和服务质量的下降。通过将人工因素排除在流程之外，这些操作将不再受到经常发生在人身上的“狼来了”思想以及对大量重复性劳动的关注疲劳所影响。于是，变更执行的速度和安全性同时得到了提高。
预测需求和规划容量
需求预测和容量规划简单来说就是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。这里并没有任何特别的概念，但是我们发现行业内有许多团队根本没有这个意识和计划去满足这个要求。一个业务的容量规划，不仅仅要包括自然增长(随着用户使用量上升,资源使用率也上升)，也需要包括一些非自然增长的因素（新功能的发布、商业推广，以及其他商业因素在内）。
容量规划有几个步骤是必须的：
必须有一个准确的自然增长需求预测模型
规划中必须有准确的非自然增长的需求来源的统计
必须有周期性压力测试，
因为服务容量对可用性来说是极为重要的，很自然的，SRE应该主导容量规划的过程。同时，也意味着需要主导资源部署的过程。
资源部署
资源的部署与配置是变更管理与容量规划的结合物。在我们的经验里，资源的部署和配置必须能够非常迅速地完成，而且仅仅是在必要的时候才执行，因为资源通常是非常昂贵的。而且这个部署和配置的过程必须要确保能够正确地执行完毕，否则资源就仍然处于不可用状态。增加现有容量经常需要启动新的实例甚至是集群，这通常需要大幅度修改现有的集群配置 ( 配置文件、负载均衡、网络等 )，同时还要执行一系列测试，确保新上线的容量可以正确地服务用户。因此新资源的部署与配置是一个相对比较危险的操作，必须要小心谨慎地执行。
小结
站点可靠性工程师(SRE)代表了对行业现存管理大型复杂服务的最佳实践的一个重要突破。由一个简单的想法“我是一个软件工程师，这是我如何来应付重复劳动的办法” 而生，SRE 模型已经发展成一套指导思想，一套方法论，一套激励方法，和一个拥有广阔空间的独立职业。本书的其余部分探讨了 SRE 的详细方法。
原创文章，作者：zero，如若转载，请注明出处：http://www.178linux.com/72484
评论列表（1条）
内容主要介绍了工作SRE的职责与管理，写的很详细，排版也很不错，继续努力