赵成的运维体系管理课
赵成
蘑菇街平台技术总监
立即订阅
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讲)
结束语 | 学习的过程，多些耐心和脚踏实地
赵成的运维体系管理课
登录|注册
39 | 云计算和AI时代，运维应该如何做好转型？
赵成 2018-01-17
今天我们来聊一聊，在云计算和 AI 时代，运维应该如何做好转型？今天的内容可以说是我们前面运维组织架构和协作模式转型的姊妹篇。针对运维转型这个话题，谈谈我的思考和建议。
我们先来看业界的三个典型案例，一个来自国外，一个来自国内，最后一个是我自己团队的案例，都非常具有代表性。
先看国外 Netflix 的模式。
Netflix 从一开始就强调开发人员进行自助化运维。我们第一篇文章中就介绍到，Netflix 内部的运维工作全部都由开发人员完成，平台也由开发自己完成，只保留极少的 Core SRE 角色专门响应和处理严重等级的故障。类似的还有亚马逊，无论是其电商业务，还是 AWS 公有云服务，全部都由开发搞定。
这样的团队因为其技术前瞻性，微服务以及分布式这样的技术架构早已落地，再加上其超强的技术能力，所以可以从一开始就这样来做。
再看国内阿里的模式。
阿里技术团队在 2016 年左右，也开始进行“去 PE”的组织架构调整，原来需要 PE 完成的运维工作，全部由开发承担。原来的 PE 要么转岗去做工具平台开发，要么作为运维专家做产品规划和设计，还有一部分无法适应调整的 PE 就只能离开了。之前在业务稳定性保障过程中起到核心作用的 PE，随着各类工具平台的逐步完善，在高度自动化之后，最终也只能面临职业和技能上的转型。
这种模式，与 Netflix 正好相反，也就是一开始技术能力无法满足要求的时候，能靠人就先靠人，然后过程中不断完善各类自动化平台。
最后，再说说我自己的团队，发展过程中的模式。
我大致回顾了一下，发现从去年年初到目前，将近两年的时间里，我自己的团队也没有招聘新的应用运维人员了。并不是没有合适的人，我总结了一下主要有两个原因。
第一个原因，随着自动化逐步完善，效率不断提升，单个 PE 能够支持的业务变得越来越多；同时，很多事情开发都可以自助完成。
第二个原因，我有意识地招聘具备开发能力的人员，他们入职后一方面参与各类平台的开发，另一方面还要定期轮岗做一些运维工作。后来我发现，只要有效进行引导，同时具备运维和开发能力是不成问题的。
所以，结果就是，应用运维的岗位需求已经没有这么强烈了。从趋势上看，跟阿里的发展过程非常相似。不过这个过程，我从来没有刻意地设计过，基本算是顺其自然。
从上面的这几个案例来看，无论哪种情况，就运维来说，随着日常重复的人工操作被逐步自动化之后，如果还是固守原有的工作模式和思路，能做的事情、能够提供的价值，一定会越来越少。终究有一天，我们会面临和阿里 PE 同样的转型问题，而且这个转型是在可预见的短期内就会到来。
既然预见到了趋势，那下面我们就来谈谈应该如何面对。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《赵成的运维体系管理课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(4)
赵成从实际情况看，无时无刻不在经历变化，而且不仅仅是运维。
跟上趋势的唯一办法，就是不断更新自己的知识和技能体制。2018-01-18 6
haormj现在个人负责的内容不是直接和用户业务逻辑挂钩，而是和平台建设相关的一些内容，因为目前公司处于发展阶段，规模也比较小，所以想建立公司自己的DevOps平台。
之前的系统，对应用的管理没有结合kubernetes和docker，系统现在也不稳定，所以想转变思路，跟上潮流，对于应用配置的管理还有困惑，还有就是不知道如何管理不同云平台的服务，例如redis。希望能够多多交流作者回复: 建议先把应用体系建起来，redis的实例一定是某个应用使用的实例，从申请的时候就把他们关联起来，再从生命周期的角度去看有哪些运维场景。
套路就是这样的，可以先一点点来。2018-01-17 3
黄无由阿里去pe的文章哪里可以找到？作者回复: s.geekbang.org
搜索 阿里巴巴运维体系变迁史2018-01-20 2
luoweiro
技术的发展和业务的发展就像火车头和轨道的关系，业务发展快要车头带，业务发展边界取决于车轨铺设范围，而平衡两者才决定商业价值最大化。
反过来看运维和开发，其实运维体现的是一种能力，开发体现的是实现工具，和火车头&车轨有相似之处，在基础设施建设方面运维更像车头发动机，工具开发相当于铺设车轨，两者都能发挥最大效应才会有更高的效能，所以对于运维开发来说两方面的能力均需要具有。
对于跨界轮岗，转岗其实也是一种好的培养综合能力的方式，当然阿里运维转开发虽是16年提出，但是这种综合能力培养其实是从早几年就开始了，达到一定点后自然爆发了。
从运维开发的角度来看，未来一定是：“会写几行代码的运维，能自助运维的开发” 的格局。作者回复: 这个比喻很棒！
2018-01-19 2
收起评论