运维思考：自动化运维体系建设，能做到的少之又少！
各位小伙伴，近期技术文感觉发的有点多，不知是否给大家在工作中解决实际问题带来了一些灵感。为什么这么说呢？因为正是文章中涉及的细小知识点积少成多，让我从零碎繁忙的运维工作中得到了一定程度的解放。相信认真读过的小伙伴，一定会觉得工作中并非只有什么高大上的技术才能解决痛点，恰恰相反，正是那些我们平时忽视的细节才是问题的要害。那么只有切中要害，我们才能对症下药。
因此接下来一段时间，我可能会陆续分享运维过程中对一些问题的思考，希望给大家带来一定的启发。
本次分享的是运维管理与运维自动化的思考。
一、运维的工作有哪些？
1.基础设施，包括网络、服务器、操作系统等工作；
2.环境管理，包括开发环境、测试环境、生产环境等；
3.部署，将应用或系统部署至不同环境；
4.监控，对基础设施、应用或系统进行监控；
5.告警响应，对告警通知的响应及处理；
6.性能优化，对系统及相关组件性能进行优化；
7.系统高可用，对应用系统中的单点进行高可用升级；
8.SLA保障，保证业务系统的可用性，可根据SLA实现自动扩缩容；
以上工作是根据运维管理框架进行提取，包含但并不限于以上几方面。
二、运维现状
从“二八定律”来看，以上运维工作有80%可以通过繁琐的手动处理进行处理，有20%需要根据不同因素来进行特定处理。
而80%的工作我们可以借助自动化进行处理，而剩下的20%可以借助监控的多维监控，对问题进行收集、分析进一步判断处理。
三、运维管理
从运维现状来看，我们优先需要解决的是自动化的问题，而自动化的前提是标准化/规范化，而好的自动化需要配合可视化或web化，可以将我们80%或更多的工作进行优化。
因此目前我们总结的运维管理主要目标是标准化/规范化，自动化，可视化/web化。
其中标准化可根据运维实际情况进行制定；而可视化/web化，可以通过开源工具或web开发实现。
四、运维自动化
运维自动化可以实现的几个主要方面：
1.服务器上架自动化
新服务器或虚拟机从创建到交付到不同环境，需要进行一系列的定制，如cpu、内存、磁盘、ip地址、内核参数优化、时间同步、ssh加固、防火墙、各种客户端安装；当然这还不够，若运维平台集成了cmdb、跳板机、zabbix等，服务器上架还需要注册到cmdb及跳板机、zabbix等管理工具；如还有其他工具也需要进行集成。
总之，服务器上架自动化的最终目标是环境优化、安全可用、注册到一切管理工具。
2.环境定义自动化
环境自定义分两种情况：
（1）中小公司，测试环境包含所有的系统，即系统间是不隔离的，数据库中包含各种系统对应的库；
（2）大公司，每套系统需要单独一套隔离的测试环境，各系统间不能互相访问；
对于环境定义的自动化比较适用于第二种情况，需要对需求部门快速创建资源。
总之环境定义自动化的主要原则无论是哪种情况，都要进行不同程度的隔离，减少环境连错导致的问题。排查环境问题是运维比较恶心的一个问题。
3.部署自动化
部署自动化的过程是不断进化的，大体分为：脚本>批量ssh>自动化工具>容器，从每个过程来看部署自动化已经有批量操作>可用性>易用性>效率不断转变。部署自动化现在解决的不仅仅是部署本身了，还包括怎么才能更快，更容易屏蔽底层的不同。
注意：此处联想到《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）运维的本质到底是服务，是服务于业务，因为运维是用技术解决业务问题，运维的价值要依托于业务才能体现。运维不是因为技术高深，或者管理了几万台服务器而很牛逼，也不是能玩转很多开源工具而很牛逼，这都不是运维的关键。对于运维来说，服务第一，技术第二。运维技术再牛，如果不能服务于业务，帮助业务取得成功，那价值也是有限的。
点亮，服务器三年不宕机