运维思考:运维管理与运维自动化 | 8月更文挑战

各位小伙伴,近期技术文感受发的有点多,不知是否给你们在工做中解决实际问题带来了一些灵感。为何这么说呢?由于正是文章中涉及的细小知识点聚沙成塔,让我从零碎繁忙的运维工做中获得了必定程度的解放。相信认真读过的小伙伴,必定会以为工做中并不是只有什么高大上的技术才能解决痛点,偏偏相反,正是那些咱们平时忽视的细节才是问题的要害。那么只有切中要害,咱们才能对症下药。nginx

所以接下来一段时间,我可能会陆续分享运维过程当中对一些问题的思考,但愿给你们带来必定的启发。web

本次分享的是运维管理与运维自动化的思考。数据库

1、运维的工做有哪些?

1.基础设施,包括网络、服务器、操做系统等工做;
2.环境管理,包括开发环境、测试环境、生产环境等;
3.部署,将应用或系统部署至不一样环境;
4.监控,对基础设施、应用或系统进行监控;
5.告警响应,对告警通知的响应及处理;
6.性能优化,对系统及相关组件性能进行优化;
7.系统高可用,对应用系统中的单点进行高可用升级;
8.SLA保障,保证业务系统的可用性,可根据SLA实现自动扩缩容;api

以上工做是根据运维管理框架进行提取,包含但并不限于以上几方面。安全

32.png

2、运维现状

从“二八定律”来看,以上运维工做有80%能够经过繁琐的手动处理进行处理,有20%须要根据不一样因素来进行特定处理。性能优化

而80%的工做咱们能够借助自动化进行处理,而剩下的20%能够借助监控的多维监控,对问题进行收集、分析进一步判断处理。服务器

3、运维管理

从运维现状来看,咱们优先须要解决的是自动化的问题,而自动化的前提是标准化/规范化,而好的自动化须要配合可视化或web化,能够将咱们80%或更多的工做进行优化。markdown

所以目前咱们总结的运维管理主要目标是标准化/规范化,自动化,可视化/web化网络

其中标准化可根据运维实际状况进行制定;而可视化/web化,能够经过开源工具或web开发实现。架构

4、运维自动化

运维自动化能够实现的几个主要方面:

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实现监控项的禁用及启动

5、运维自动化的几个阶段

站得高,看得远。不管咱们正在作哪一个方面的自动化,从更高的层次了解运维自动化的各个阶段,对咱们更有益处:

1.操做自动化

这个层次的特征是把一系列的手工执行的操做,用脚本或工具串联,在必定程度上解决了运维手动执行的问题。可是不一样的场景须要不断调整脚本或工具,反而增大了出错几率。

2.场景自动化

这个层次的特征是工具会根据外部环境判断如何运行,而这些判断条件是运维事先定义好的。此层次的运维系统须要各种环境数据来做为判断条件,同时还要可以变化操做行为。
另,此层次的运维系统须要跟不少第三方系统对接(cmdb、网管系统)。

3.智能化

此层次的运维系统具有数据核心(大数据存储,全部运营中的数据都会按关联关系集中存储),具有根据数据本身分析和判断、并自我决策和执行的能力。
在此层次,运维的主要工做是为系统增添分析策略、运营和维护此智能运维系统,以及在系统执行的关键节点上介入作人工判断。

6、怎样作运维自动化

在咱们思考怎么作运维自动化以前,咱们须要意识到“企业的架构不是设计出来的,是演变而来的”。所以咱们能够借助这个做为指导思想。

1.先解决痛点

平常工做中,对常见问题进行分类和梳理,能作成工具的就工具化,能程序化操做的,就避免人为干预。
至因而否基于cmdb,反而不过重要,特别是若是业务系统并无那么大,服务器的变更也没那么频繁的话。

2.选择正确的阶段

运维自动化通常沿袭这样的阶段:手动支撑 => 线上标准规范化 => 运维工具化 => 平台自助化/自动化。选择适合本身当前业务发展阶段的运维自动化方式,不要一口吃成胖子。

另外,对于大中型运维自动化平台而言, CMDB和配置系统依然不可或缺。
CMDB即配置管理数据库,通常用于统一管理IT数据、服务器数据资产等。CMDB数据的准确性和权威性,关系到运维自动化是否走在正确的路上。

7、总结

1.运维自动化

在以上自动化过程当中,在不一样的自动化阶段须要对接不一样的第三方系统,所以能够看出一条统一的ESB(企业系统总线)来实现对系统的接口对接是多么重要。可是也并非没有ESB就很差,不一样阶段解决的痛点不同,只有适合业务发展的阶段的运维自动化才是最好的。

2.运维管理

文章开头说运维管理主要目标是标准化/规范化,自动化,可视化/web化,从切身体验来看运维管理的目标也是随着运维自动化阶段的不一样而变化的。

例如如今公司已经初步作到场景自动化及智能化,虽然还不深刻,在必定程度上个人运维工做也已经解放了80%左右,已经给我释放了大部分时间,我也在想运维管理是否应该步入下一个阶段:运维服务化?

理由:

  • 运维自动化的价值在于,将运维从繁琐的、例行、容易发生人为事故的工做中脱离出来,作更有价值的业务运维和服务运维。

    因此,从这个角度来看,运维自动化既不是起点,也不是终点。运维自动化不是万能的,咱们须要看清楚它的位置。

  • 运维的本质究竟是服务,是服务于业务,由于运维是用技术解决业务问题,运维的价值要依托于业务才能体现。运维不是由于技术高深,或者管理了几万台服务器而很牛逼,也不是能玩转不少开源工具而很牛逼,这都不是运维的关键。对于运维来讲,服务第一,技术第二。运维技术再牛,若是不能服务于业务,帮助业务取得成功,那价值也是有限的。

相关文章
相关标签/搜索