亚洲bet356体育什么是自动化运维？

　　亚洲bet356体育什么是自动化运维？本文以本人练习自动化运维时长两年半，总结了一些经验教训，如有不对的地方请指正，欢迎互相交流。

　　个人认为：自动化运维是指通过运维工具来解决生产中大量、繁杂的事务，监控生产环境变化、自动响应并处置事件等问题，从而提升运维效率、降低重大问题发生的概率、更全面的保障生产环境。

　　不过相较于传统运维，自动化运维会更加的偏向开发一些。所以自动化运维和运维开发的区别就在于前者是以实现流程化的需求为核心而后者更多的以产品或者说以运维平台为核心。不过两者的本质没有太大的差别。

　　所以站在运维的角度来说自动化运维弥补了传统运维的人效低、响应慢，极大的提升了生产力，让人专注于生产中的关键问题。站在开发的角度来说自动化运维面向生产环境(对象)，挖掘生产环境更多的属性，总结业务生命周期的规律，找到维护业务的逻辑，从而更全面的感知、保障生产环境，两者殊途同归。

　　传统运维的侧重点在于快速响应需求和排查出现的故障以及各类文档报告，业内戏称为“被动运维”或“救火式运维”。

　　传统运维对个人的要求是精通某一个细分领域即可，例如：网络运维、数据库运维、系统运维。但是现在的业务的逻辑越来越复杂了。为了支撑业务，各类高可用集群，各类安全、网络、服务器等设备层出不穷，而只精通某一细分领域仅能应对生产环境的某一个维度。运维的横向领域的跨度较大，个人很难精通方方面面。同时随着业务体量的增加，生产环境变得庞大起来，一些小概率的故障会变得频繁， 层出不穷的需求消耗的人力越来越多。传统运维不足以快速响应需求了。

　　另一方面，很多小公司、中小型的项目的运维体系不健全，出现关键问题的概率较小，业务逻辑简单，无需专家级的运维人员。更多的时候需要“打杂”的人即可。这些“打杂”的事情大多简单、琐碎、无聊、无意义。

　　我相信如果有得选，没人会把生命浪费在没有意义的事情上。我们需要自动化的手段来解决问题，例如：

　　业务经常在半夜的某个时间点的服务发生异常，按照以往的惯例，极大概率是运维部门、开发部门、安全部门三方互相甩锅，最后不了了之。

　　服务器改造/新增少则几百多则上千，需要装系统并初始化加固。由于生产环境不得接入dhcp的规定，只能登录带外管理界面去手动挂载镜像安装。

　　护网期间需要从态势感知、ips、waf这类的安全设备上查看攻击信息，并在防火墙上下发封禁策略，下班前还要统计攻击事件并上报。

　　以上这些问题都能通过自动化的方式一键解决，但有个前提：你得熟悉业务流程，每一个步骤要做的事情，把每件事情转化为代码，同时还要把这些步骤串联起来。也就是说，要先明白运维业务的逻辑才能更好的进入自动化运维的领域尝试解决运维的问题。

　　现在流行的开源的工具已经很多了，例如：ansible就可以做到批量执行命令，zabbix可以部署监控，nginx可以做代理等等。目前市面上的技术能够支撑我们干很多事情了，但现实是我们干活的自由是有界限的。

　　有一些是一刀切的禁令，例如：某些公司的生产不允许执行定时任务、不允许接入dhcp服务。

　　另一些是硬性要求的流程，例如：更换服务器系统或者升级bios需要关闭服务器，需要暂停业务，要走重大业务保障流程，要先提变更方案，上报各级审批，审批通过才能执行，这个周期会很长。

　　不论这些约束有多奇葩，多令人费解，但个人认为这些约束存在的意义在于降低或避免生产上的重大事件出现的概率。

　　在实际干活中，这些约束经常会带来很大的困扰，例如：项目上的内网的网络环境不得接通互联网，部署软件装离线环境会特别麻烦（依赖地狱），催的特急，有时候不得已会用笔记本联通热点反向代理流量给服务器。

　　自动化运维定位介于开发和运维之间(运维和开发的交集)。根据公司业务情况的不同，工作内容上的侧重点也不同。根据本人过往的经验来说大部分情况下是80%开发、20%运维。

　　个人认为，自动化运维的工作领域也分业务层面的运维和开发和运维工作层面的运维和开发。前者更侧重开发能力，后者更侧重运维能力(本人属于后者)。在外包盛行的时代前者比较稀有。作为一个普通人很难能够找到一家拥有自己的核心产品和研发团队的公司。同时也很难找到大规模体量设备的项目磨练专业技能。

　　保持学习，才能创造机会。值得一提的是在初期大部分情况都是一个人面对的，不要期望有人跟你一起探讨技术，一起学习。因为运维这行的门槛很低，目前碰到的大部分人对这个行业的认知都是有偏差的。学习没有捷径，必须养成独立思考的习惯，一步一个脚印的走。

　　另外，之前个人认为团队很重要，起码让别人知道你在做什么，能收获到志同道合的朋友也不错。但，同事就是同事，工作中也有不少技术之外的事情，你没有办法指望你的工程师同仁们拥有工程师精神、认可工程师文化。所以就技术而言这条路注定是要一个人去走的。路上能不能碰到志同道合的人看缘分吧。

　　个人感觉国内自动化运维平台应用的比较好的是安全领域即soar。因为安全设备发展到今天使用门槛逐渐降低了，已经做到标准流程化了，各种层出不穷的安全设备界面繁多，用soar来统一对接是个很不错的选择，应用场景相对固定。

　　soar是一种技术能力，可供组织收集不同来源的安全威胁数据和警报，运用人机结合的方法进行事件分析与分类，根据标准流程辅助定义、排序和驱动标准化事件响应行为。

　　个人认为监控应该也纳入到自动化的体系中来，毕竟生产环境里面得有一双眼睛帮我们时时刻刻盯着。但目前个人了解到的做自动化平台的都没有监控。不过问题不大，可以用zabbix并配合自动化运维平台中的剧本、触发器来实现告警处置。

　　另外，自动化运维的成本还蛮高的，如果没有平台提供整套的解决方案的话，只能用脚本编写业务流程。如果是初级、中级阶段这个过程非常值得体验，能够锻炼人的逻辑思维，也能锻炼人的解决方案能力。这个过程的技术经验是能够提升非常大的。做自动化运维应当以问题为导向，解决问题才是健康发展的基础。

　　重点说下python，python是唯一一门允许我能够快速开发、迭代、学习门槛低的语言并且丰富的生态能找到各个领域使用的库。

　　想要把python写好是一件不容易的事情，python的弱类型在团队协作的时候特别蛋疼，良好的代码规范尤其的重要。有条件多看一看别人写的源码，学习不同的代码设计风格和理念，有助于提升开发的思维。

　　js在工作中使用到的不多，但可以通过它制作一些页面来展示个人的能力，推荐vue、element-ui。本人把js当工具用，暂时没有太多时间去熟悉它的细节。即便如此，配合fastapi写cmdb去实现功能足够了。

　　假设以开源项目：django开发cmdb、stackstorm作为自动化运维平台、zabbix为监控的体系。首先cmdb作为运维工作的起点，当前生产环境的所有设备的相关信息都体现在其中，需要考虑设备统一访问入口、权限管理、密钥管理、操作审计等。其次熟悉stackstorm特性，在插件编写上考虑通用性、可扩展性。最后考虑如何利用zabbix的实时数据，等等。这个过程要解决很多很多的问题，非常考验耐心。

　　大规模的运维经验也非常重要，能够碰到很多生产环境中的关键问题，例如性能/架构/io/调优等。这些核心问题决定了技术的上限。

　　另外，技术发展也是有哲学思想蕴含在其中的，一些比较经典的书籍和思想也值得去了解。例如：devops，微服务设计，敏捷开发。

　　运用到的技术领域看上去非常广，但实际上在应用中以深耕需求为主，通常由一个技术点慢慢扩展到其他的技术点。即根据现有的环境，去思考如何去实现功能，由一个小功能慢慢扩展演化更多的功能。期间会涉及的知识盲区，按需去补即可。初级阶段更多的是整合和应用不同的技术实现多样化的功能，熟练使用即可。进阶要看环境，如果有些技术当前的环境用不上，学了会很快就忘掉。进阶阶段会碰到各种各样的问题，例如：代码设计上的缺陷，某个底层的库报了个错百度查不到等等，解决问题需要耐心去了解技术原理、编程思想，跨过这道坎才能完善自己的知识体系结构。高级阶段要看项目，把自身的知识体系落地到实际应用中对综合性的要求特别高，这些经验需要靠时间积累。

　　在当前的阶段，自动化运维更多的解放了基础工作，对于关键问题仍然有很多路要去探索。同时自动化运维也是一把双刃剑，在高效处理任务的同时，也能在短时间内给业务带来灾难性的打击。