点击蓝字关注我们
本文转载自博客园：倒骑的驴
这是16年国庆时的一篇读书笔记，最近线上故障频繁，重新读了下这篇读书笔记，觉得《Google SRE》非常棒，遂从简书再搬家到博客园，希望大家受益。
国庆长假，出门太堵，遂待在魔都，花了三天时间将《Google SRE》中文版翻了一遍，好书一本，不管是开发人员、运维人员还是架构师，都可以读一读，受益匪浅的。
鉴于自己是做开发的，所以对于运维相关流程化的内容没有涉猎。不过这部分内容对于运维Leader应当是大有裨益的。
01
SRE是个全能手，DevOps的实践者
SRE全称：Site Reliability Engineering，翻译过来就是：站点可靠性工程师。SRE的职责确保站点的可用，为了达到这个目的，他需要对站点涉及的系统、组件熟悉，需要关注生产运行时的状态，为此，他需要有很多工具和系统支撑其完成上述工作，比如自动化发布系统，监控系统，日志系统，服务器资源分配和编排等，这些工具需要他们自己完成开发和维护。
SRE是一个综合素质很高的全能手，需要懂服务器基础架构、操作系统、网络、中间件容器、常用编程语言、全局的架构意识、非常强的问题分析能力、极高的抗压能力（以便沉着高效地排障），他们还需要懂性能调优理论...
SRE的工作是Develop+Operate的结合，SRE是DevOps的实践者，他们的工作内容和职责和传统运维工程师差不多：发布、部署、监控、排障，目标一致。但是SRE的手段更加自动化，更高效，这种高效来源于自动化工具、监控工具的支撑，更因为其作为这些工具的开发者，不断优化和调整，使整个工具箱使起来更加得心应手，这也是DevOps的魅力所在。
02
分布式环境运维大不同于传统运维
我的理解：在分布式环境下，系统的复杂度增大、维护目标增多，按照传统的手工或者半自动维护来做，是不行的。
所以，需要转变思路：
事务性的工作工具化。
比如：版本发布、服务器监控。
让系统自反馈。
完善的监控告警机制，完善的日志记录和分析体制，可视化系统的健康状态，使得系统变得可追踪和调校。
分布式策略应对巨量运维对象。
负载均衡、流控、数据完整性、批处理的变得不一样，需要重新设计和实践。同时，更要重视连锁式故障。
03
分布式系统的核心——分布式共识
分布式共识问题是指“在不稳定的通信环境下一组进程之间对某项事情达成一致的问题”。
分布式共识系统可以用来解决：领头人选举、关键共享状态、分布式锁等问题。或者绝对点，所有的分布式问题都应当考虑到分布式共识的问题。
分布式共识的理论基础和实现都不是很好理解，抽时间搞清楚是大有裨益的，这里罗列一下几个关键词：
拜占庭问题
可复制状态机
Paxos算法
Zookeeper
Chubby
04
监控很重要！很重要！很重要！
监控是SRE眼睛的延伸。
监控系统应当解决两个问题：现象（什么东西出故障了？），原因（为什么出故障？）
现象—— 用户可感知的现象，比如：登陆不了、支付订单变慢；
原因—— 造成现象的潜在因素，可能只是中间因素或者相关因素，并非根本原因，根本原因需要SRE介入分析并确定。比如：login 服务CPU超过警戒值，订单服务器的CLOSE_WAIT状态的TCP链接数猛增等等。
四个黄金指标：时延、流量（PV）、错误、饱和度（服务器资源使用情况）。前三个是对服务进行监控，后一个是对服务器进行监控，当然也可以包含容器的状态监控，比如线程池、GC等。
几条箴言：
指标简化到不能再简化
关注长尾现象，要时延分布，而不是平均时延
慎重发出紧急警报，预防“狼来了”现象，紧急警报都是课操作的，且不能惯性得出结论的问题
警报不要重复，避免浪费SRE的注意力
05
排障
定位故障点。合理判定问题的严重程度，尝试尽快恢复服务或者缓解问题。
借助监控工具和日志工具检查系统或者服务状态。服务时延和错误率、系统资源使用状态情况、日志统计分析。
逐层检查和分解问题，解析问题现象，不断假设/验证地进行诊断，找到根本原因。
06
发布
自动化发布应当作为基础设施，第一优先级建设，他的重要性和自动化测试一样。之前参加的“软件工程的精益化管理”课程实验中，实践证明了自动化工具的威力很大，能够明显提升整个团队的生产力。
关于自动化发布的内容和分享网上非常多，而且国内各大互联公司分享出来的材料也是汗牛充栋，用到时可以学习。
07
反思 and 总结
这两个优点对于SRE很是重要，反思使得SRE从失败中学习教训，总结使SRE从时间中获得经验，个人和团队需要学习和践行这种精神，但是对事不对人。
Google的做法是：时事后总结机制。
08
追本溯源、怀疑一切
SRE是天生怀疑论者，怀疑一切，眼见为实，追本溯源是本性，感觉自己的性格还蛮适合的~
09
拥抱风险
传统运维是厌恶风险的，但是开发和产品却更关注变化速度，他们都希望迭代速度越快越好，但是这会给系统运行带来风险，所以这天生是矛盾。
为了解决风险和变化的矛盾，google提出了SLI-->SLO-->SLA的机制。
SLI——服务质量指标，如：延时、吞吐量、错误率、可用性等；
SLO——服务质量目标，服务的某个SLI的目标值，或者目标范围。比如：SLI<=目标值，min=；
SLA——服务质量协议（Agreement），服务（SRE）和用户（开发、产品）之间的一个明确的、或者不明确的协议，描述了在达到或者没有达到SLO之后的后果。或者可以转化为先行的KPI，比如系统可用性99.99%等。
开发和运维针对某个系统协商好一个SLA后，大家有一个量化的指标，一旦出现冲突时，算一下，看看是否违反SLA，如果违反，那么就升级走流程。这样既灵活，也有章可循。如果开发团队牛逼，代码质量高或者运气好，你可以迭代快，反之你需要慢点来，间接地，大家都对线上系统负责了。
10
反直觉的真理
1、不要承诺你的系统100%可靠。
因为这样会要其他人过分依赖于你，一旦你出问题，那么将成为众矢之的，相反的，你应当对自己的系统了如指掌，比如能承受的压力，可用性目标，一些明显的坑，一些不支持的属性等，广而告之。
2、有意识地破坏你的系统
不同于演练，而是真实生产系统，在可控范围内，人为制造故障，然后在有人值守的情况下，找到系统的短板和问题。这样等到真正的故障来临时，可以有章可循，快速解决问题。
主动暴露自己的不足好于别人突然揭发你，当然更重要的是要及时纠正不足。
11
线上排障实践
本文转载自博客园：倒骑的驴
原文链接：
https://www.cnblogs.com/daoqidelv/p/7818633.html
图书简介
内容简介
大型软件系统生命周期的绝大部分都处于“使用”阶段，而非“设计”或“实现”阶段。那么为什么我们却总是认为软件工程应该首要关注设计和实现呢？在《SRE：Google运维解密》中，Google SRE的关键成员解释了他们是如何对软件进行生命周期的整体性关注的，以及为什么这样做能够帮助Google成功地构建、部署、监控和运维世界上现存最大的软件系统。通过阅读《SRE：Google运维解密》，读者可以学习到Google工程师在提高系统部署规模、改进可靠性和资源利用效率方面的指导思想与具体实践——这些都是可以立即直接应用的宝贵经验。
任何一个想要创建、扩展大规模集成系统的人都应该阅读《SRE：Google运维解密》。《SRE：Google运维解密》针对如何构建一个可长期维护的系统提供了非常宝贵的实践经验。
作者简介
Betsy Beyer 是Google 纽约负责SRE 的一名技术文档作家。她之前曾为遍布全球的Google 数据中心与Mountain View 硬件运维团队编写文档。在搬到纽约之前，Betsy 是Stanford 大学技术性写作课程的讲师。她曾经学习国际关系与英文文学，并在Stanford和Tulane 获得学历。
Chris Jones 是Google App Engine 的一名SRE。Google App Engine 是一个PaaS 服务，每天处理超过280 亿个请求。他的办公室在旧金山，他之前的工作包括Google 广告统计、数据仓库，以及用户支持系统的维护。在之前，Chris 曾经在学校IT 行业任职，同时参与过竞选数据分析，以及一些BSD 内核的修改。他有计算机工程、经济学，以及技术政策学的学位。同时他也是一名有执照的职业工程师。
Jennifer Petoff 是Google SRE 团队的一名项目经理，工作地点在都柏林，爱尔兰。她曾经负责管理大型全球项目，包括：科学研究、工程、人力资源，以及广告等。Jennifer在加入Google 之前，曾在化工行业任职八年。她获得了Stanford 大学的化学博士与学士学位，同时她还拥有Rochester 大学的心理学学位。
Niall Murphy 是Google 爱尔兰团队广告SRE 的负责人。他拥有20 年互联网行业经验，目前是INEX（爱尔兰网络互联枢纽）的主席。他曾经写作以及参与写作很多科技文章与书籍，包括O’Reilly 出版的IPv6 Network Administration，以及很多RFC。他目前在参与书写爱尔兰互联网发展史。他拥有计算机科学、数学，以及诗歌学的学历（他当时一定是想错了！）。他目前与妻子和两个儿子居住在都柏林。
译者
孙宇聪，前Google SRE（2007-2015），山景城总部，曾参与构建运维Youtube 全球CDN网络，2008年奥运会直播项目，构建维护海量视频编码传输系统。后参与Google内部云平台运维工作，负责运维全球百万级别服务器集群，以及Borg、Omega等大规模集群系统。2015年加入Coding，任CTO一职。回国后，积极推动国内容器化运维架构升级。目前是开放运维联盟之应用运维规范制定组，高可用运维规范制定者。
关于我们
嘉为科技 —— IT解决方案与服务领先者，腾讯蓝鲸智云全国首家授权技术合作伙伴，拥有嘉维蓝鲸IT自动化运维、IT基础架构服务、应用软件开发、云计算四大系列业务，提供自本地到云端、从标准架构到定制开发的一系列优秀IT解决方案和服务，全新打造嘉维蓝鲸IT自动化运维解决方案、CMDB解决方案、DevOps解决方案等，提升客户信息化水平和市场竞争力，助力客户的业务发展。
嘉为集团 —— 成立于2001年，由嘉为科技和嘉为教育组成，于广州、深圳、北京、上海设有分公司，融IT服务和培训咨询于一体，为客户提供解决方案、运维支持、软件研发及培训教育服务。历经18年的发展和积累，嘉为已成为备受客户赞誉的行业翘楚。
长按识别二维码关注我们