查看原文
其他

运维思索:运维规范如何生成?

木讷大叔爱运维 木讷大叔爱运维 2022-07-13

点击上方蓝色字体,关注我们




读完需 4 分钟

 速读需 2 分钟 



前面的文章老说“运维管理”、“运维自动化”,可能大家都听烦了,大道理谁都会说,能不能来点干货,把这些“大白话”落地?


我自己也不断在想是否应该将这些分享出来,因为都是自己在工作过程中的个人理解,都是野路子。但换个角度,运维的工作并不是简单的修修补补,而是给业务赋能,让自己实现价值的,因此接下来的文章更多的是进行落地。


运维框架

运维思考:运维管理与运维自动化一文中我们从运维工作中提取了运维框架(红色代表缺失),由基础设施层、数据层、应用层、管理层、展示层组成,生成了我们最终的运维体系。

下面我们从以下几个问题入手来深入探讨。


1

运维框架为什么要分层呢?


我认为有以下几点:

  • 运维是面向团队而不是个人,分层能够让团队中每个人找到自己的工作的重点、明确运维的管理思路与目标。

  • 分层其实是将运维工作进行了逻辑上的拆解,形成了上下文。因此我们做的某些操作并不是孤立的,会牵扯到不同的层次,是可以有生命周期的。
    例如:服务器上架,就涉及到以下几个层面:
    (1)基础设施层:服务器、操作系统等
    (2)应用层:基础组件、中间件等
    (3)管理层:无人值守、cmdb、监控等
    (4)展示层:zabbix、蓝鲸等
    在没有分层的情况下,我们就会孤立的重复操作,而忽略其实我们可以通过一套自动化流程彻底解决问题。

  • 分层可以帮助我们更好的进行知识点梳理与盘点,对运维工作形成良性补充。

  • 再说你就要说我吹NB了,但至少在我眼中是非常重要的,帮我理清了管理思路。


2

既然运维框架如此重要,那是如何生成的呢?


最终的运维框架其实并不是一蹴而就的,也是逐渐演化而来的,最初版如下:

最初版的运维框架粒度粗,但其核心要素为:

  • 分为基础设施、系统应用、平台服务几个层次

  • 基础组件、业务组件、公共组件

  • 开发技术栈分类


无论运维框架如何演进,以上要素都会以不同形式存在,因此我们在此阶段需要好好梳理,为以后打好坚实的基础。


此阶段的缺点是系统应用服务偏离了,关联到业务上了,虽然运维是支撑业务的,但运维框架旨在梳理运维架构,为运维提供架构支撑。因此在后续单独分离应用层,从业务实现上分离出基础服务、业务应用、中间件三个共性特点。


运维规范

终于来到重点了,运维规范是如何生成的?

  • 运维规范从来不是凭空捏造的,需要从碎片化的运维工作提取事实依据来生成

  • 碎片化的运维工作存在于运维框架各个层面,因此运维规范按框架分层提取


明白以上两点后,我们就可以按照运维框架中的各个层次来提取了。当然由于运维框架的不断演进,因此运维规范是持续生成,不断补充到运维工作中。


1.基础设施服务

  • 操作系统安装规范

  • 目录管理规范

  • 系统配置(初始化)规范

  • JDK安装规范

  • 网络设备配置规范

  • 等等

2.系统应用规范

  • 系统上线规范

  • 进程管理规范

  • 备份管理规范

  • hosts规范

  • 等等

3.平台服务规范

  • 监控管理规范

  • 系统巡检规范

  • 日志收集规范

  • 跳板机管理规范

  • CI/CD规范

  • 等等


规范生成如图:


规范最关键

当你有了规范后,是否应用了一段时间就不再更新了呢?

如果发生这种情况,我觉得主要是以下几个原因:

  1. 规范的总结成了工作的负担;

  2. 规范的风格不统一,团队不同成员因格式五花八门,非常混乱;

  3. 规范的文字太多,阅读耗时,成了摆设;


另外,规范一定是可持续的,再结合以上问题,在最终生成规范时,运维团队需要明确规范的目的,使规范轻装上阵。


为解决这个问题,我给规范本身也定制了一个规范:


总结

运维规范只是自动化的前提,有了规范只是完成了万里长征的第一步,接下来我们只需要严格按规范去执行、不断的进行优化,剩下的都是水到渠成的事儿了。


最后,我的“野路子”就是这么来的,希望对大家有所启发,不喜勿喷!


运维思索:cmdb与zabbix监控系统的融合

一套包含完整前后端的系统如何在K8S中部署?

Prometheus+k8s之告警通知

滴滴夜莺:从监控告警系统向运维平台演化

Jenkins多分支流水线:Webhook按分支触发自动构建



关注我们




您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存