运维的本质到底是服务，是服务于业务，因为运维是用技术解决业务问题，运维的价值要依托于业务才能体现。运维不是因为技术高深，或者管理了几万台服务器而很牛逼，也不是能玩转很多开源工具而很牛逼，这都不是运维的关键。

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

最初版的运维框架粒度粗，但其核心要素为：
分为基础设施、系统应用、平台服务几个层次
基础组件、业务组件、公共组件
开发技术栈分类
无论运维框架如何演进，以上要素都会以不同形式存在，因此我们在此阶段需要好好梳理，为以后打好坚实的基础。
此阶段的缺点是系统应用服务偏离了，关联到业务上了，虽然运维是支撑业务的，但运维框架旨在梳理运维架构，为运维提供架构支撑。因此在后续单独分离应用层，从业务实现上分离出基础服务、业务应用、中间件三个共性特点。
运维规范
终于来到重点了，运维规范是如何生成的？
运维规范从来不是凭空捏造的，需要从碎片化的运维工作提取事实依据来生成
碎片化的运维工作存在于运维框架各个层面，因此运维规范按框架分层提取
明白以上两点后，我们就可以按照运维框架中的各个层次来提取了。当然由于运维框架的不断演进，因此运维规范是持续生成，不断补充到运维工作中。
1.基础设施服务
操作系统安装规范
目录管理规范
系统配置（初始化）规范
JDK安装规范
网络设备配置规范
等等
2.系统应用规范
系统上线规范
进程管理规范
备份管理规范
hosts规范
等等
3.平台服务规范
监控管理规范
系统巡检规范
日志收集规范
跳板机管理规范
CI/CD规范
等等
规范生成如图：

规范最关键
当你有了规范后，是否应用了一段时间就不再更新了呢？
如果发生这种情况，我觉得主要是以下几个原因：
规范的总结成了工作的负担；
规范的风格不统一，团队不同成员因格式五花八门，非常混乱；
规范的文字太多，阅读耗时，成了摆设；
另外，规范一定是可持续的，再结合以上问题，在最终生成规范时，运维团队需要明确规范的目的，使规范轻装上阵。
一、运维的工作有哪些？
1.基础设施，包括网络、服务器、操作系统等工作；2.环境管理，包括开发环境、测试环境、生产环境等；3.部署，将应用或系统部署至不同环境；4.监控，对基础设施、应用或系统进行监控；5.告警响应，对告警通知的响应及处理；6.性能优化，对系统及相关组件如Nginx、Java、PHP、DB或网络等的性能进行优化；7.系统高可用，对应用系统中的单点进行高可用升级；8.SLA保障，保证业务系统的可用性，可根据SLA实现自动扩缩容；以上工作是根据运维管理框架进行提取，包含但并不限于以上几方面。
二、运维自动化
运维自动化可以实现的几个主要方面：
1.服务器上架自动化新服务器或虚拟机从创建到交付到不同环境，需要进行一系列的定制，如cpu、内存、磁盘、ip地址、内核参数优化、时间同步、ssh加固、防火墙、各种客户端安装；当然这还不够，若运维平台集成了cmdb、跳板机、zabbix等，服务器上架还需要注册到cmdb及跳板机、zabbix等管理工具；如还有其他工具也需要进行集成。总之，服务器上架自动化的最终目标是环境优化、安全可用、注册到一切管理工具。
2.环境定义自动化环境自定义分两种情况：（1）中小公司，测试环境包含所有的系统，即系统间是不隔离的，数据库中包含各种系统对应的库；（2）大公司，每套系统需要单独一套隔离的测试环境，各系统间不能互相访问；
对于环境定义的自动化比较适用于第二种情况，需要对需求部门快速创建资源。总之环境定义自动化的主要原则无论是哪种情况，都要进行不同程度的隔离，减少环境连错导致的问题。排查环境问题是运维比较恶心的一个问题。
3.部署自动化部署自动化的过程是不断进化的，大体分为：脚本＞批量＞自动化工具＞容器，从每个过程来看部署自动化已经有批量操作＞可用性＞易用性＞效率不断转变。部署自动化现在解决的不仅仅是部署本身了，还包括怎么才能更快，更容易屏蔽底层的不同。
注意：此处联想到《DevOps》思维导图中关于自动化中的提高速度，即自动化初步完成，还需要进行速度方面的优化。另部署自动化完成后，需要和监控进行联动，即系统的可用性监控、性能监控等需要自动添加到监控系统。
4.监控自动化从《系统监控体系》中我们知道监控对象分为从多个维度，每个维度可能用到的工具不一样，即监控自动化可能需要对接不同的工具。如：（1）自动添加可用性监控，如端口、url监控等（2）自动添加日志状态监控，如status、error等当然监控自动化不仅仅只针对监控，还要兼顾到故障恢复的自动化，即故障自愈。
5.版本发布自动化在服务器规模不大的情况下，版本发布要考虑摘节点、屏蔽告警等，需要和nginx、监控进行联动。如：（1）nginx实现平滑摘节点（2）调用api实现监控项的禁用及启动
五、运维自动化的几个阶段站得高，看得远。无论我们正在做哪个方面的自动化，从更高的层次了解运维自动化的各个阶段，对我们更有益处：1.操作自动化这个层次的特征是把一系列的手工执行的操作，用脚本或工具串联，在一定程度上解决了运维手动执行的问题。但是不同的场景需要不断调整脚本或工具，反而增大了出错概率。
2.场景自动化这个层次的特征是工具会根据外部环境判断如何运行，而这些判断条件是运维事先定义好的。此层次的运维系统需要各类环境数据来作为判断条件，同时还要能够变化操作行为。另，此层次的运维系统需要跟很多第三方系统对接（cmdb、网管系统）。
3.智能化此层次的运维系统具备数据核心（大数据存储，所有运营中的数据都会按关联关系集中存储），具备根据数据自己分析和判断、并自我决策和执行的能力。在此层次，运维的主要工作是为系统增添分析策略、运营和维护此智能运维系统，以及在系统执行的关键节点上介入做人工判断。
六、怎样做运维自动化
在我们思考怎么做运维自动化之前，我们需要意识到“企业的架构不是设计出来的，是演变而来的”。因此我们可以借助这个作为指导思想。
1.先解决痛点日常工作中，对常见问题进行分类和梳理，能做成工具的就工具化，能程序化操作的，就避免人为干预。至于是否基于cmdb，反而不太重要，特别是如果业务系统并没有那么大，服务器的变动也没那么频繁的话。
2.选择正确的阶段运维自动化一般沿袭这样的阶段：手动支撑＝＞线上标准规范化＝＞运维工具化＝＞平台自助化/自动化。选择适合自己当前业务发展阶段的运维自动化方式，不要一口吃成胖子。
另外，对于大中型运维自动化平台而言，CMDB和配置系统依然不可或缺。CMDB即配置管理数据库，一般用于统一管理IT数据、服务器数据资产等。CMDB数据的准确性和权威性，关系到运维自动化是否走在正确的路上。
七、总结1.运维自动化
在以上自动化过程中，在不同的自动化阶段需要对接不同的第三方系统，因此可以看出一条统一的ESB（企业系统总线）来实现对系统的接口对接是多么重要。但是也并不是没有ESB就不好，不同阶段解决的痛点不一样，只有适合业务发展的阶段的运维自动化才是最好的。
2.运维管理文章开头说运维管理主要目标是标准化/规范化，自动化，可视化/web化，从切身体验来看运维管理的目标也是随着运维自动化阶段的不同而变化的。例如现在公司已经初步做到场景自动化及智能化，虽然还不深入，在一定程度上我的运维工作也已经解放了80%左右，已经给我释放了大部分时间，我也在想运维管理是否应该步入下一个阶段：运维服务化？
理由：（1）运维自动化的价值在于，将运维从繁琐的、例行、容易发生人为事故的工作中脱离出来，做更有价值的业务运维和服务运维。所以，从这个角度来看，运维自动化既不是起点，也不是终点。运维自动化不是万能的，我们需要看清楚它的位置。
（2）运维的本质到底是服务，是服务于业务，因为运维是用技术解决业务问题，运维的价值要依托于业务才能体现。运维不是因为技术高深，或者管理了几万台服务器而很牛逼，也不是能玩转很多开源工具而很牛逼，这都不是运维的关键。对于运维来说，服务第一，技术第二。运维技术再牛，如果不能服务于业务，帮助业务取得成功，那价值也是有限的。
运维自动化之殇
运维自动化是我们的必经之路，那么，一定就是解决所有问题的灵丹妙药么？可能不尽然哦。潜在问题包括如下：
1）忽略权限和基线
运维自动化平台通常由DevOps开发（例如Python+Shell），更多的是以实现功能为主，可能对账号权限或服务器操作权限，未做特殊限制，这样问题就来了，例如：
是否针对运维自动化平台的服务器账号做了特殊限制，使得这个账号只能操作指定目录，只能重启Nginx、不能重启PHP？
是否做了超限检查？例如，对部分特殊请求如“rm-Rf”或超高数值调整做了二次过滤？
是否做了关键操作的双保险？例如，数据库合并类的危险操作，增加了一个检查人审核机制？
另外，运维自动化发布平台是否保存有程序基线，并有一键恢复功能？
大公司的业务系统，运行十多年，开发人员你来我往数以千计，而发布平台每次仅更新部分代码（类似缝缝补补）。这样的后果是，可能根本没有人有一套完整的业务系统代码。
如果执行任意系统命令+缺乏基线，两者兼备，刚好又有人触发了执行操作，那么灾难性的后果就会突然来临。
毕竟，对于历史悠久的大型业务系统而言，老代码往往没人敢动，而且严重SOA化，从零重建的难度之大，也许需要几十个小时。而又因为这种极端情况下，很难形成一个强一致性的版本，所以重建成功往往只是灾难的开始，之后就是开发、客服和DBA陷入长期的疲于奔命之中。
2）缺乏安全机制
运维自动化平台一般由非专业开发人员实施，而且是给内部人员使用，主观上容易忽略代码安全和系统安全。
“上帝节点”是安全灾难的起点。
之前没有运维自动化，小米加步枪的时代，上千台服务器相对独立，还有各种堡垒机、动态令牌或私钥登录服务器等安全措施，想一个命令删除大批量服务器的程序，还真不容易实现。
运维自动化平台已然是“上帝节点”，天然的实现了连接到大批量服务器（甚至可能直接是root权限）。这样，为广大的黑客朋友带来了无限想象空间。
有朋友可能会说，我放在公司内网了非常安全。其实，现在黑客可以很容易的扫描到内网所有域名，识别到疑似运维自动化平台的域名，然后用常规或非常规手段入侵，然后就“一锅端”了。例如：
你的运维自动化平台是基于通用框架如Django么。一个常识是，越是流行的框架，已知漏洞、甚至0day漏洞越多哦。
3）忽略专业性
运维自动化越是充分的公司，隐藏的风险就越大。
即使一个再优秀的运维自动化平台，也不能解决所有运维问题。所以，如果忽略了对人员专业能力的培养，那么在某些需要人工操作的场景（例如机房迁移这类重大调试），问题就会报复性的反弹和爆发。
一次专业的调试，体现在对调试时长和调试效果的掌控上。调试时长必须可接受、并可控。
例如一次跨机房迁移，停业务10小时甚至以上，是很难被接受的；停业务10分钟以下，则是很令人愉快的。但这个的专业化要求很多，包括如充分的演练、更多的任务前置，保证只有必须的操作在调试期间进行。
可控性主要体现在调试节奏的把握，例如是否有快速可操作的回滚措施，保证如果预计调试不能如期完成，能提前预警并快速切回之前的系统状态。
当有重大调试需求时，突然发现中级运维人员没那么多了，初级运维人员缺少专业化锻炼和练手机会，“手生”，主管不敢用之；高级运维人员都已“金盆洗手”多年，自己不敢上手。
4）自得和忽略人文关怀
运维自动化平台上线后，运维人员可能会产生一种主观的优越感，并严重阻碍后续工作的开展。以前是开发追着运维打，运维往往疲于奔命，心力憔悴。现在神器在手，容易“多年的媳妇熬成婆”。。。
其实运维自动化只是解决了运维部分工作效率的问题，远没有解决运维的全部问题，外部门对运维的不满，可能涛声依旧，例如经常容易犯的“老板着个脸，说话直接不拐弯；需求老不及时完成，完不成也不说”等等。
运维自动化越是充分的公司，高层管理者（技术VP或CTO）可能产生一种错觉，运维人员是否可以靠边站了？甚至夸张些说，是否可以“卸磨杀驴”了？这种意识层的错觉或者说自我心理暗示，会导致各种多米诺骨牌式的效应。
如果高层忽略人为关怀，在某些极端情况下，运维自动化平台的高权限人员，可能“有意”利用上述提及的平台缺陷，进行极具破坏性的事情。。然后灾难性的后果，可能长时间难以补救。
结语
运维自动化的价值在于，将运维从繁琐的、例行、容易发生人为事故的工作中脱离出来，做更有价值的业务运维和服务运维。
运维自动化，终归只是一个高级工具而已。运维的价值最终是要体现在业务上的：
体现的方式就是运维服务化，所以运维自动化（智能化）最终都要为运维的服务化服务。所以如何构建你的自动化系统最终要看你所支撑的业务需要什么样的服务。