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

2,607 阅读4分钟

这是我参与8月更文挑战的第4天,活动详情查看:8月更文挑战

简述

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

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

运维框架

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

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

1.运维框架为什么要分层呢? 我认为有以下几点:

  • 运维是面向团队而不是个人,分层能够让团队中每个人找到自己的工作的重点、明确运维的管理思路与目标。
  • 分层其实是将运维工作进行了逻辑上的拆解,形成了上下文。因此我们做的某些操作并不是孤立的,会牵扯到不同的层次,是可以有生命周期的。 例如:服务器上架,就涉及到以下几个层面: (1)基础设施层:服务器、操作系统等 (2)应用层:基础组件、中间件等 (3)管理层:无人值守、cmdb、监控等 (4)展示层:zabbix、蓝鲸等 在没有分层的情况下,我们就会孤立的重复操作,而忽略其实我们可以通过一套自动化流程彻底解决问题。
  • 分层可以帮助我们更好的进行知识点梳理与盘点,对运维工作形成良性补充。
  • 再说你就要说我吹NB了,但至少在我眼中是非常重要的,帮我里清了管理思路。

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

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

33.png

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

  • 分为基础设施、系统应用、平台服务按个层次
  • 基础组件、业务组件、公共组件
  • 开发技术栈分类

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

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

运维规范

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

  • 运维规范从来不是凭空捏造的,需要从碎片化的运维工作提取事实依据来生成
  • 碎片化的运维工作存在于运维框架各个层面,因此运维规范按框架分层提取

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

1.基础设施服务

  • 操作系统安装规范
  • 目录管理规范
  • 系统配置(初始化)规范
  • JDK安装规范
  • 网络设备配置规范
  • 等等

2.系统应用规范

  • 系统上线规范
  • 进程管理规范
  • 备份管理规范
  • hosts规范
  • 等等

3.平台服务规范

  • 监控管理规范
  • 系统巡检规范
  • 日志收集规范
  • 跳板机管理规范
  • CI/CD规范
  • 等等

规范生成如图:

34.png

规范最关键

当你有了规范后,是否应用了一段时间就不再更新了呢? 如果发生这种情况,我觉得主要是以下几个原因:

  1. 规范的总结成了工作的负担;
  2. 规范的风格不统一,团队不同成员因格式五花八门,非常混乱;
  3. 规范的文字太多,阅读耗时,成了摆设;

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

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

35.png

总结

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

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