运维框架
运维思考：运维管理与运维自动化一文中我们从运维工作中提取了运维框架（红色代表缺失），由基础设施层、数据层、应用层、管理层、展示层组成，生成了我们最终的运维体系。
下面我们从以下几个问题入手来深入探讨。
1
运维框架为什么要分层呢？
我认为有以下几点：
运维是面向团队而不是个人，分层能够让团队中每个人找到自己的工作的重点、明确运维的管理思路与目标。
分层其实是将运维工作进行了逻辑上的拆解，形成了上下文。因此我们做的某些操作并不是孤立的，会牵扯到不同的层次，是可以有生命周期的。
例如：服务器上架，就涉及到以下几个层面：
（1）基础设施层：服务器、操作系统等
（2）应用层：基础组件、中间件等
（3）管理层：无人值守、cmdb、监控等
（4）展示层：zabbix、蓝鲸等
在没有分层的情况下，我们就会孤立的重复操作，而忽略其实我们可以通过一套自动化流程彻底解决问题。分层可以帮助我们更好的进行知识点梳理与盘点，对运维工作形成良性补充。
再说你就要说我吹NB了，但至少在我眼中是非常重要的，帮我理清了管理思路。
2
既然运维框架如此重要，那是如何生成的呢？
最终的运维框架其实并不是一蹴而就的，也是逐渐演化而来的，最初版如下：
最初版的运维框架粒度粗，但其核心要素为：
分为基础设施、系统应用、平台服务几个层次
基础组件、业务组件、公共组件
开发技术栈分类
无论运维框架如何演进，以上要素都会以不同形式存在，因此我们在此阶段需要好好梳理，为以后打好坚实的基础。
此阶段的缺点是系统应用服务偏离了，关联到业务上了，虽然运维是支撑业务的，但运维框架旨在梳理运维架构，为运维提供架构支撑。因此在后续单独分离应用层，从业务实现上分离出基础服务、业务应用、中间件三个共性特点。
运维规范
终于来到重点了，运维规范是如何生成的？
运维规范从来不是凭空捏造的，需要从碎片化的运维工作提取事实依据来生成
碎片化的运维工作存在于运维框架各个层面，因此运维规范按框架分层提取
明白以上两点后，我们就可以按照运维框架中的各个层次来提取了。当然由于运维框架的不断演进，因此运维规范是持续生成，不断补充到运维工作中。
1.基础设施服务
操作系统安装规范
目录管理规范
系统配置（初始化）规范
JDK安装规范
网络设备配置规范
等等
2.系统应用规范
系统上线规范
进程管理规范
备份管理规范
hosts规范
等等
3.平台服务规范
监控管理规范
系统巡检规范
日志收集规范
跳板机管理规范
CI/CD规范
等等
规范生成如图：
规范最关键
当你有了规范后，是否应用了一段时间就不再更新了呢？
如果发生这种情况，我觉得主要是以下几个原因：
规范的总结成了工作的负担；
规范的风格不统一，团队不同成员因格式五花八门，非常混乱；
规范的文字太多，阅读耗时，成了摆设；
另外，规范一定是可持续的，再结合以上问题，在最终生成规范时，运维团队需要明确规范的目的，使规范轻装上阵。
为解决这个问题，我给规范本身也定制了一个规范：
总结
运维规范只是自动化的前提，有了规范只是完成了万里长征的第一步，接下来我们只需要严格按规范去执行、不断的进行优化，剩下的都是水到渠成的事儿了。
