赵成的运维体系管理课
赵成
蘑菇街平台技术总监
立即订阅
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讲)
结束语 | 学习的过程，多些耐心和脚踏实地
赵成的运维体系管理课
登录|注册
03 | 标准化体系建设（上）：如何建立应用标准化体系和模型？
赵成 2017-12-24
今天我专门来讲讲标准化这个工作。可以说这项工作是运维过程中最基础、最重要的，但也是最容易被忽视的一个环节。
我做过多次公开演讲，每次讲到这个环节，通常会有单独的一页 PPT，就放四个字，字号加大加粗，重复三遍，这四个字就是“标准先行”，然后演讲过程中会大声说出“标准先行，标准先行，标准先行”，重要的事情说三遍，目的就是想反复强调这件事情的重要程度，一定不要忽视。
我们运维工作的开展常常不知从何下手，或者上来就冲着工具和自动化去了，却始终不得章法，工具做了一堆，效率却并没有提升。其实绝大多数情况下，问题和原因就是标准化这个基础工作没做扎实。
首先，让我们来看看为什么标准化这个事情如此重要。
为什么要做标准化？
标准化的过程实际上就是对运维对象的识别和建模过程。形成统一的对象模型后，各方在统一的认识下展开有效协作，然后针对不同的运维对象，再抽取出它们所对应的运维场景，接下来才是运维场景的自动化实现。
这有点像我们学的面向对象编程的思想，其实我们就是需要遵循这样一个思路，我们面对的就是一个个实体和逻辑运维对象。
在标准化的过程中，先识别出各个运维对象，然后我们日常做的所有运维工作，都应该是针对这些对象的运维。如果运维操作脱离了对象，那就没有任何意义。同样，没有理清楚对象，运维自然不得章法。
比如我们说扩容，那就要先确定这里到底是服务器的扩容，还是应用的扩容，还是其它对象的扩容。你会发现，对象不同，扩容这个场景所实施的动作是完全不一样的。
如果把服务器的扩容套用到应用的扩容上去，必然会导致流程错乱。同时对于对象理解上的不一致，也会徒增无谓的沟通成本，造成效率低下。自然地，这种情况下的运维自动化不但不能提升效率，还会越自动越混乱。
这就是为什么我每次都会连续强调三遍“标准先行”的原因。虽然这个事情比较枯燥和繁琐，但是于纷繁复杂中抽象出标准规范的东西，是我们后续一系列自动化和稳定性保障的基础。万丈高楼平地起，所以请你一定不要忽略这个工作。
好，总结一下标准化的套路：
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《赵成的运维体系管理课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(12)
宵伯特在我的理解中，可扩展的应用设计，应用可以根据现有的基础设施资源进行有效的分配，确保各个模块之前能够达到均衡的负载，所以在水平扩展，弹性伸缩和自动化扩缩容时，主要调节的也就是基础的处理资源，例如服务器，带宽等，在现在的云服务和微服务架构下，更多的也就是服务实例。
对于对象属性的识别，需要参考该对象属性在系统中的状态管理情况，而在业务逻辑层面，对于对象关注相对强势的，应该是领域驱动设计了吧。作者回复: 感谢你的留言，回答地很精彩！对于第二个问题，状态管理是一部分，领域驱动的方法论也是个很值得借鉴的思路，后面文章会讲到。
2017-12-25 11
岑崟磨刀不误砍柴工，标准化就是这个磨刀的过程。之前对于工具化、自动化往往就是撸起袖子就干，结果在实施的过程中发现工具化、自动化本身就是一个负担。相同的需求，不同的实施人员，得到的结果不尽相同。所以标准化越早开展越好，可以从最简单的最容易识别的对象开始，对于那些业务系统建成已有些时间的，更适合逐步的改变，结合当下流行的DevOps思想，让研发也一起参与其中，效果更好作者回复: 你一定有过亲身经历，已经感同身受了。
2017-12-26 5
Matthew_Yin敏捷开发，devops这些感觉和应用运维更贴近，运维人员转型也容易，但是传统网络，系统和存储这些硬件运维的方向在哪？多数人不具备开发能力，但是随着工具化，自动化的开展和普及，这些岗位势必会受到冲击。楼主能不能给一些指导性的建议，谢谢2018-05-23 2
白下醍醐灌顶
就第一个问题而言 作者已经说的很清楚了 对象
水平扩容 弹性伸缩对象是什么？
缓存？
无状态容器？
数据库？
存储？
服务器等基础设施？
基于RPC的服务
基于HTTP的服务
对象不同涉及到的弹性伸缩 水平扩容的的流程 方法都不一样
不同对象 需要建立不同运维模型
不同对象本身涉及到了关联和不同属性2018-04-12 2
foxracle个人理顺一下逻辑：为了让用户，运营，开发，测试，运维统一术语和视角以及价值观，应用是唯一能通用的术语，只是各个人看到的应用大小粒度不一样，那运维的工作自然就都是面向应用来开展的。而运维的具体工作内容是用应用的运维场景来描述的，所以运维体系建设也应该是以捕捉具体运维场景来开展的，就好比面向对象的需求分析是通过use case来落地一样。在理顺所有运维场景之后，才开始去识别场景中的具体对象，对对象进行建模，理清对象之间的关系。这样来看的话，所谓标准先行也仅仅是对象建模的自然产物，另一种说法而已作者回复: 你的理解没有问题，在运维工作中，标准化更为重要，且更容易被忽略。
2018-01-09 1
思涵_芳瑞文章中提到的应用扩容和服务器扩容是什么区别？另外应用本身不仅仅指微服务应用吧？作者回复: 我后面专门有一篇文章介绍第一个问题，你可以先思考一下。
第二个问题，不仅仅指微服务应用，单体或分层应用也适合，但是在微服务架构下应用这个概念的作用会更突出。2018-01-04 1
春生儿这个实际上就是先做cmdb对吧作者回复: 从自动化角度，CMDB一定是优先做，这个后面文章会讲到。不过标准化写几篇文章是想讲清楚自动化之前要做哪些准备和分析梳理的工作，这个比直接做CMDB要重要的多。
2017-12-28 1
向日葵运维人员将来的趋势应该是逐渐变成平台的构建者2019-09-09
牧野静风受益良多，作为一个传统的运维，发现后期的维护越来越繁杂，很多东西无法自动化处理，比如，所有的应用日志如何归集分析，语言，标准，编程习惯都不一样，统一化平台很难；另外随着应用的增加，比如定时Job,想做个管理平台，发现很不好分析，数据结果不一致，报错信息有些有，有些没有，很麻烦；标准化是一切自动化，效率化的前提，后面来推行，就很难了2019-07-19- 水手刚读到此章，日常混乱无章的运维工作，顿时找到了头绪，谢谢。2018-05-15
FOX学习收藏，少走弯路2018-02-13
微光这种关联关系 能通过什么方式来自动发现，人为维护太繁重了作者回复: 不同对象间的关联关系管理方式是不同的，我建议你可以先分类下都有哪些关联关系，再看管理方式
2018-01-20
收起评论