运维规范管理

运维框架

1.运维框架为什么要分层

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

2.既然运维框架如此重要，那是如何生成的？

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

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

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

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

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

运维规范

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

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

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

1.基础设施服务

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

2.系统应用规范

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

3.平台服务规范

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

规范生成如图：

规范最关键

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

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

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

总结

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