赵成的运维体系管理课
赵成
蘑菇街平台技术总监
立即订阅
5576 人已学习
课程目录
已完结 48 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 带给你不一样的运维思考
免费
应用运维体系建设 (11讲)
01 | 为什么Netflix没有运维岗位？
02 | 微服务架构时代，运维体系建设为什么要以“应用”为核心？
03 | 标准化体系建设（上）：如何建立应用标准化体系和模型？
04 | 标准化体系建设（下）：如何建立基础架构标准化及服务化体系？
05 | 如何从生命周期的视角看待应用运维体系建设？
06 | 聊聊CMDB的前世今生
07 | 有了CMDB，为什么还需要应用配置管理？
08 | 如何在CMDB中落地应用的概念？
09 | 如何打造运维组织架构？
10 | 谷歌SRE运维模式解读
11 | 从谷歌CRE谈起，运维如何培养服务意识？
效率和稳定性最佳实践 (20讲)
12 | 持续交付知易行难，想做成这事你要理解这几个关键点
13 | 持续交付的第一关键点：配置管理
14 | 如何做好持续交付中的多环境配置管理？
15 | 开发和测试争抢环境？是时候进行多环境建设了
16 | 线上环境建设，要扛得住真刀真枪的考验
17 | 人多力量大vs.两个披萨原则，聊聊持续交付中的流水线模式
18 | 持续交付流水线软件构建难吗？有哪些关键问题？
19 | 持续交付中流水线构建完成后就大功告成了吗？别忘了质量保障
20 | 做持续交付概念重要还是场景重要？看“笨办法”如何找到最佳方案
21 | 极端业务场景下，我们应该如何做好稳定性保障？
22 | 稳定性实践：容量规划之业务场景分析
23 | 稳定性实践：容量规划之压测系统建设
24 | 稳定性实践：限流降级
25 | 稳定性实践：开关和预案
26 | 稳定性实践：全链路跟踪系统，技术运营能力的体现
27 | 故障管理：谈谈我对故障的理解
28 | 故障管理：故障定级和定责
29 | 故障管理：鼓励做事，而不是处罚错误
30 | 故障管理：故障应急和故障复盘
31 | 唇亡齿寒，运维与安全
云计算时代的运维实践 (6讲)
32 | 为什么蘑菇街会选择上云？是被动选择还是主动出击？
33 | 为什么混合云是未来云计算的主流形态？
34 | Spring Cloud：面向应用层的云架构解决方案
35 | 以绝对优势立足：从CDN和云存储来聊聊云生态的崛起
36 | 量体裁衣方得最优解：聊聊页面静态化架构和二级CDN建设
37 | 云计算时代，我们所说的弹性伸缩，弹的到底是什么？
个人成长 (5讲)
38 | 我是如何走上运维岗位的？
39 | 云计算和AI时代，运维应该如何做好转型？
40 | 运维需要懂产品和运营吗？
41 | 冷静下来想想，员工离职这事真能“防得住”吗？
42 | 树立个人品牌意识：从背景调查谈谈职业口碑的重要性
加餐 (4讲)
划重点：赵成的运维体系管理课精华（一）
划重点：赵成的运维体系管理课精华（二）
划重点：赵成的运维体系管理课精华（三）
新书 |《进化：运维技术变革与实践探索》
结束语 (1讲)
结束语 | 学习的过程，多些耐心和脚踏实地
赵成的运维体系管理课
登录|注册
10 | 谷歌SRE运维模式解读
赵成 2018-01-12
前面我和你分享了一些关于运维组织架构和协作模式转型的内容，为了便于我们更加全面地了解先进的运维模式，今天我们再来谈一下谷歌的 SRE（Site Reliability Engineer）。同时，也期望你能在我们介绍的这些运维模式中找到一些共通点，只有找到这些共通点，才能更深刻地理解，并借鉴到真正对我们有用的东西。
专栏的第一篇文章我们介绍了 Netflix 的 NoOps 模式。这个模式并不意味着不存在任何运维工作，只是 Netflix 将这些事情更紧密地融入到了日常的开发工作中，又做得非常极致，所以并没有很明显地体现出来。
但是，谷歌的 SRE 却是一个真实具体的岗位，也有明晰的岗位职责。从借鉴意义上来讲，SRE 可以给我们提供更好的学习思路和样板。
SRE 这个概念，我应该是 2014 年下半年的时候听到的。当时可接触的资料和信息有限，只知道是谷歌对运维岗位的定义，负责稳定性保障，就没有更多其他的认识了。
后来，有越来越多在谷歌工作或接触过这个岗位的专家开始在公开演讲中分享这个概念。同时，《SRE：Google 运维解密》，这本由多名谷歌 SRE 亲笔撰写的图书也开始在国内广泛流传，让我们对很多细节有了更加细致的了解。
SRE 岗位的定位
首先，SRE 关注的目标不是 Operation（运维），而是 Engineering（工程），是一个“通过软件工程的方式开发自动化系统来替代重复和手工操作”的岗位。我们从 SRE 这本书的前面几个章节，可以看到谷歌不断强调 SRE 的工程能力。我简要摘取几段：
Common to all SREs is the belief in and aptitude for developing
software systems to solve complex problems.
所有的 SRE 团队成员都必须非常愿意，也非常相信用软件工程方法可以解决复杂的运维问题。
By design, it is crucial that SRE teams are focused on engineering.
SRE 模型成功的关键在于对工程的关注。
SRE is what happens when you ask a software engineer to design an
operations team.
SRE 就是让软件工程师来设计一个新型运维团队的结果。
与之相对应的，还有一个很有意思的地方，整本书中提到 Operation 的地方并不多，而且大多以这样的词汇出现：Operation load，Operation overload，Traditional/Manual/Toil/Repetitive Operation Works。你可以仔细体会一下，这些大多就是传统的纯人工操作模式下的一些典型词汇。
我们可以看到，从一开始，谷歌就没把 SRE 定义为纯操作类运维的岗位，也正是谷歌换了一个思路，从另外一个维度来解决运维问题，才把运维做到了另一个境界。
SRE 岗位的职责
书中对 SRE 的职责定义比较明确，负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作。如果站在价值呈现的角度，我觉得可以用两个词来总结，就是“效率”和“稳定”。
接下来，详细说下我的理解和分析。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《赵成的运维体系管理课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(8)
luoweiro
赞博主精辟剖析！谈谈个人思考：
巨大流量对稳定性指标的冲击其实是量变引发了质变。不管是软件工程还是线上运维其实自然是一体，谷歌SRE其实更是无边界支撑线上业务的模式的实践。
另外，这和谷歌技术文化底蕴也有很大的关系，毕竟谷歌的工程师都是万里挑一的优秀人才，追求极致甚至是从他们进入公司都会耳濡目染，举个例子一个borg系统都做了十几年，不断优化完善。
而近几年一直火热的DevOps理念侧重点是为了提高研发应该具备的综合能力，在不依赖与运维的基础上，能在软件设计上多考虑可运维性，所以由此来看这也应运而生产生更多辅助产品来保障核心业务，而随着辅助产品逐渐逐渐完善也就逐渐催生业界更多优秀的解决方案。
稳定性很多时候是“望天收”的情况，也许幸苦一年建设的稳定性基础设施还不如蓝翔一铲子厉害。所以，建设过程中会逐渐考虑软件层面的高可用，这也是软件定义运维的意义。作者回复: 👍
2018-01-12 9
朱雯在一家创业公司做运维，现在做的事情是维护公司网络和报警。在您的专栏中提到的这些东西感觉和我差距太远了，是否因为道行太浅的缘故?作者回复: 后面我有一篇文章介绍个人能力建设方面的，到时可以看一下。
就留言中你提到的工作而言，如果非常例行化，个人感觉没有什么提升的话，建议还是尝试一些更有挑战性的工作。2018-01-14 3
宵伯特国内的情况大概是因为大多数的公司组织对于运维的职能概念停留在软件后期维护的层面，对于敏捷开发和devops也是一知半解，认知层次和视角都需要进一步的提升。好在如今的技术交流和组织沟通都是自由的，即便是随着技术的发展和产品规模的扩大，也会有越来越多的组织团队意识到该职位的重要性。2018-01-14 2- Penn理念是道，实践是术，能落地的方案最有力，期待实践部分的讲解。
作者回复: 后面会有，可以继续关注，也欢迎多留言讨论。
2018-01-12 2 
孙志宇收获好大，重新定义了我对运维的理解，谢谢老师！2019-03-31 1
三宝Site Reliability Engineering2018-02-07 1
魏红生要想做好运维，就得跳出运维的局限，要站在全局的角度，站在价值呈现的角度，站在如何能够发挥出整体技术架构运维能力的角度，来重新理解和定义运维才可以。2019-11-15
kevinsu运维需要不断挑战自己，不给自己设限制2019-05-16
收起评论