赵成的运维体系管理课
赵成
《进化: 运维技术变革与实践探索》作者
37256 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
开篇词 (1讲)
效率和稳定性最佳实践 (20讲)
赵成的运维体系管理课
15
15
1.0x
00:00/00:00
登录|注册

03 | 标准化体系建设(上):如何建立应用标准化体系和模型?

今天我专门来讲讲标准化这个工作。可以说这项工作是运维过程中最基础、最重要的,但也是最容易被忽视的一个环节。
我做过多次公开演讲,每次讲到这个环节,通常会有单独的一页 PPT,就放四个字,字号加大加粗,重复三遍,这四个字就是“标准先行”,然后演讲过程中会大声说出“标准先行,标准先行,标准先行”,重要的事情说三遍,目的就是想反复强调这件事情的重要程度,一定不要忽视。
我们运维工作的开展常常不知从何下手,或者上来就冲着工具和自动化去了,却始终不得章法,工具做了一堆,效率却并没有提升。其实绝大多数情况下,问题和原因就是标准化这个基础工作没做扎实。
首先,让我们来看看为什么标准化这个事情如此重要。

为什么要做标准化?

标准化的过程实际上就是对运维对象的识别和建模过程形成统一的对象模型后,各方在统一的认识下展开有效协作,然后针对不同的运维对象,再抽取出它们所对应的运维场景,接下来才是运维场景的自动化实现。
这有点像我们学的面向对象编程的思想,其实我们就是需要遵循这样一个思路,我们面对的就是一个个实体和逻辑运维对象。
在标准化的过程中,先识别出各个运维对象,然后我们日常做的所有运维工作,都应该是针对这些对象的运维。如果运维操作脱离了对象,那就没有任何意义。同样,没有理清楚对象,运维自然不得章法。
比如我们说扩容,那就要先确定这里到底是服务器的扩容,还是应用的扩容,还是其它对象的扩容。你会发现,对象不同,扩容这个场景所实施的动作是完全不一样的。
如果把服务器的扩容套用到应用的扩容上去,必然会导致流程错乱。同时对于对象理解上的不一致,也会徒增无谓的沟通成本,造成效率低下。自然地,这种情况下的运维自动化不但不能提升效率,还会越自动越混乱。
这就是为什么我每次都会连续强调三遍“标准先行”的原因。虽然这个事情比较枯燥和繁琐,但是于纷繁复杂中抽象出标准规范的东西,是我们后续一系列自动化和稳定性保障的基础。万丈高楼平地起,所以请你一定不要忽略这个工作。
好,总结一下标准化的套路:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《赵成的运维体系管理课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(19)

  • 最新
  • 精选
  • 宵伯特
    在我的理解中,可扩展的应用设计,应用可以根据现有的基础设施资源进行有效的分配,确保各个模块之前能够达到均衡的负载,所以在水平扩展,弹性伸缩和自动化扩缩容时,主要调节的也就是基础的处理资源,例如服务器,带宽等,在现在的云服务和微服务架构下,更多的也就是服务实例。 对于对象属性的识别,需要参考该对象属性在系统中的状态管理情况,而在业务逻辑层面,对于对象关注相对强势的,应该是领域驱动设计了吧。

    作者回复: 感谢你的留言,回答地很精彩!对于第二个问题,状态管理是一部分,领域驱动的方法论也是个很值得借鉴的思路,后面文章会讲到。

    18
  • 岑崟
    磨刀不误砍柴工,标准化就是这个磨刀的过程。之前对于工具化、自动化往往就是撸起袖子就干,结果在实施的过程中发现工具化、自动化本身就是一个负担。相同的需求,不同的实施人员,得到的结果不尽相同。所以标准化越早开展越好,可以从最简单的最容易识别的对象开始,对于那些业务系统建成已有些时间的,更适合逐步的改变,结合当下流行的DevOps思想,让研发也一起参与其中,效果更好

    作者回复: 你一定有过亲身经历,已经感同身受了。

    9
  • foxracle
    个人理顺一下逻辑:为了让用户,运营,开发,测试,运维统一术语和视角以及价值观,应用是唯一能通用的术语,只是各个人看到的应用大小粒度不一样,那运维的工作自然就都是面向应用来开展的。而运维的具体工作内容是用应用的运维场景来描述的,所以运维体系建设也应该是以捕捉具体运维场景来开展的,就好比面向对象的需求分析是通过use case来落地一样。在理顺所有运维场景之后,才开始去识别场景中的具体对象,对对象进行建模,理清对象之间的关系。这样来看的话,所谓标准先行也仅仅是对象建模的自然产物,另一种说法而已

    作者回复: 你的理解没有问题,在运维工作中,标准化更为重要,且更容易被忽略。

    2
  • 春生儿
    这个实际上就是先做cmdb对吧

    作者回复: 从自动化角度,CMDB一定是优先做,这个后面文章会讲到。不过标准化写几篇文章是想讲清楚自动化之前要做哪些准备和分析梳理的工作,这个比直接做CMDB要重要的多。

    2
  • 17
    分享标准化过程实践的经验:一开始基于目前的应用场景,抽象分析,定规范,出标准规范文档。随着业务的发展或前期分析不到位,导致之前的标准不太符合当前的应用场景。这个过程虽然知道不可避免,但是真正发生的时候,还是非常和痛。针对这种场景,不知作者是如何来处理的?

    作者回复: 定标准的过程本身就是需要迭代完善的,一开始没法完全考虑清楚是很正常的,就跟设计架构一样,一开始就想地很周全,设计的非常全面,也是不太现实的。 因为具体哪些点不符合我问题中没看出来,你可以再补充下。

    2
    1
  • 思涵_芳瑞
    文章中提到的应用扩容和服务器扩容是什么区别?另外应用本身不仅仅指微服务应用吧?

    作者回复: 我后面专门有一篇文章介绍第一个问题,你可以先思考一下。 第二个问题,不仅仅指微服务应用,单体或分层应用也适合,但是在微服务架构下应用这个概念的作用会更突出。

    1
  • 牧野静风
    受益良多,作为一个传统的运维,发现后期的维护越来越繁杂,很多东西无法自动化处理,比如,所有的应用日志如何归集分析,语言,标准,编程习惯都不一样,统一化平台很难;另外随着应用的增加,比如定时Job,想做个管理平台,发现很不好分析,数据结果不一致,报错信息有些有,有些没有,很麻烦;标准化是一切自动化,效率化的前提,后面来推行,就很难了

    作者回复: 万丈高楼平地起,标准化就是地基,地基打的坚实了,才会有上面的高楼大厦。

  • 指尖流逝
    这种关联关系 能通过什么方式来自动发现,人为维护太繁重了

    作者回复: 不同对象间的关联关系管理方式是不同的,我建议你可以先分类下都有哪些关联关系,再看管理方式

    2
  • 技术修行者
    标准化确实很重要,作者总结的非常好。 标准化的制定套路:1. 识别对象,2. 识别对象属性,3. 识别对象关系,4. 识别对象场景。 标准化的内容:1. 基础设施层面标准化,2. 应用层面标准化。 我的问题:如果我们的应用是全部托管在公有云上,那么基础设施层面的标准化是不是应该由各个云厂商来负责?还需要开发运维团队介入吗?
    1
    2
  • Matthew_Yin
    敏捷开发,devops这些感觉和应用运维更贴近,运维人员转型也容易,但是传统网络,系统和存储这些硬件运维的方向在哪?多数人不具备开发能力,但是随着工具化,自动化的开展和普及,这些岗位势必会受到冲击。楼主能不能给一些指导性的建议,谢谢
    4
    2
收起评论
显示
设置
留言
19
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部