其他分享
首页 > 其他分享> > 【经验分享】DevOps时代,敏捷运维是必然的趋势

【经验分享】DevOps时代,敏捷运维是必然的趋势

作者:互联网

在DevOps到来之前,我们更多的是讨论极限编程、敏捷开发和Scrum等方法论,而很少关注运维体系的建设和提高运维的效率。DevOps时代,我们关注的是从业务出发,提高整个价值链的交付速度,从而为企业获得竞争力和生产力。今天我们就来谈谈如何实现敏捷运维,助力运维人员转型。

01 新的业务和技术架构对运维提出了更高的挑战

一方面,随着互联网时代和数字化转型的到来,通过科技创新和开拓新业务来提高企业核心竞争力和生产力,比如银行业的网贷、信贷、网上银行、API Bank和区块链等业务,同时新的业务对科技部门提出了更高的要求:在安全稳定的前提下,快速的交付业务功能,从而实现业务价值。那么科技部门就必须提高业务端到端的交付效率,主要包括持续集成(需求管理、源码管理、编译构建、代码扫描和自动化测试)、持续部署(配置管理、基础资源和组件自动部署、应用自动化发布)和持续运营(监控、数据分析和业务运营)。

另一方面,随着业务的高速发展以及超大规模业务体量的驱动下,大部分企业引入了更为灵活的微服务架构。我们知道,微服务架构是从单体架构或分层架构演进而来的,从一个单体工程拆分出n个独立模块,如下图所示:

注:上图出自于赵成老师的书籍《进化:运维技术变革与实践探索》

引入微服务架构后,软件架构的细化拆分和灵活多变大大提升了开发人员的开发效率,继而提升业务需求的响应和迭代速度。但是随之而来的是架构复杂度大大增加,对后续的交付和运维带来了极大的难度和挑战。

02 配置管理(标准化)和自动化是亟需解决的运维问题

在传统的模式下,研发团队和运维团队分歧的焦点主要在软件新版本、新配置的变更和发布速度上。研发团队最关注如何能够快速地构建和发布新功能,而运维团队更关注的是如何能在他们值班期间避免发生故障。换句话说,研发部门想要“随时随地发布新功能”,而运维部门则想要“一旦系统在生产环境正常工作了,就不要再进行任何改动”。所以在传统意义上这两个部门的目标是互相矛盾的。

在DevOps模式下,只有一个共同的目标,旨在通过合适的准时制(JIT)业务流程来最大化业务产出,例如增加销售和利润率、提升业务速度、或尽量降低运营成本。DevOps知识体系由三大支柱(规范敏捷、持续交付、IT服务管理)和一个基础(精益管理)组成。

注:上图出自于EXIN DevOps Master 白皮书

很多企业成功了应用了Agile、Scrum和XP等方法论,即使提高了开发效率,但对业务速度提升还是觉得远远不够,原因在于:表面上看起来是开发过程的瓶颈,但在调查中发现开发过程并非瓶颈,相反是业务流程应该被改进。所以我们应该从业务的目标出发,度量并改进和优化端到端的业务流程,比如:提高系统发布频率、降低发布失败率。

如上图,我们调研了一些企业的IT管理工具后发现,从需求管理、代码管理到持续集成已经有一系列的开源或商用工具支撑了,同时也具备了一系列的监控平台,包括基础监控(Zabbix、Prometheus和IBM Tivoli)、APM(应用性能管理)、NPM(网络性能管理)和BPC。但是配置管理中心和运维自动化几乎是空白的,仍然依靠人工运维和脚本化运维。由此可见,配置管理和运维自动化是目前持续交付最大的瓶颈,从而影响到整个业务流的效率。实现运维自动化和提高运维效率,进而实现敏捷运维,是亟需解决的问题。

03 敏捷运维的重点在于运维场景服务化工具的快速落地

在本文中,我把“敏捷运维”定义为:IT运维团队根据业务的需求,快速响应运维要求,并实现运维场景服务化工具的快速落地。这里请注意重点在于“服务化工具”的落地,而不是单纯的解决一次性的运维需求,我们再来看看似曾相识的几个运维场景:

帮忙创建N台XX配置的XX操作系统的虚拟机,今天下班之前需要;

帮忙提取XX机器下的XX日志;

XX系统明天要正式上线,今晚大家做好通宵的准备;

这个周末是年度的灾备切换演练,大家做好加班的准备;

对于以上的运维场景是否觉得很熟悉和痛苦呢,若是有对应服务化的工具你就可以这样回复以上的需求了:

我们提供了“云资源管理平台”自助申请功能,您提交资源要求申请即可,审批通过后会自动创建好资源,并将结果邮件给你;

我们提供了“日志查询”自助服务工具,您可以按需查询和检索对应系统下的日志内容;

我们提供了“应用发布自动化”自助服务工具,可以实现应用的一键发布和上线;

我们提供了“灾备切换演练”自助服务工具,使用实现灾备切换的一键完成,整个过程在30分钟内完成,并提供全程可视化实时展示页面,直观的看到过程进展。

唯有快速构建服务化工具,才能真正实现敏捷运维,体现运维的价值,实现运维转型。

04 引入PaaS体系和运维场景工具,解决当前运维压力

很多运维人员会抱怨说,我们现在每天都加班哪有什么时间来构建运维工具呢?但随着AI和微服务时代的到来,面向新技术、新架构和新业务,运维人员该何去何从呢?我这边总结了运维建设的三个阶段:

手工/脚本化运维:依靠人肉运维,运维人员长期处于被动支持的情况,7*24小时随时待命,人员稳定性都难以保障,更不用谈提升运维团队能力了;

烟囱自动化:借助商业产品和开源工具来解决一部分的运维压力,人员压力得到了一定的释放。但带来了另外的两个问题,一是运维人员的能力仍然没有提到提升;二是构建了一系列的烟囱式工具难以实现全链路调度自动化,当然数据化和智能化运维就更加困难了;

平台化建设:引入PaaS体系和运维场景工具,解决当前运维压力的同时,通过API网关向下治理企业内部烟囱式系统实现一体化管理,向上提供运维开发平台,让运维人员低门槛的构建个性化运维场景工具,实现运维能力的提升。

围绕PaaS平台搭建的工具在少数互联网巨头中已经有相对成熟的体系,也有在持续的对外输出,我们可以看看过往一些基于腾讯蓝鲸的PaaS平台,嘉为输出的一些范例:

数据中心运维自动化工具:

应用运维自动化工具:

05 运维开发平台,助力运维转型

通过第一步,开箱即用的运维工具解决了当前的运维压力,将运维日常重复的手工工作服务化和自助化,这样将运维人员的精力和时间空出来才有可能进入第二步,开始传统运维到运维开发的转型。此时运维人员又有顾虑:我们很少写代码,就怕我们Hold不住。但事实上,运维开发的门槛没有想象中那么高,况且运维人员才是真正懂运维流程的,没有比运维人员来开发运维工具更合适的人了。

面向开发人员,PaaS体系提供了很多的 “开发者服务”,让开发者可以简单、快速地创建、部署和管理运维工具。

以蓝鲸平台为例,它提供了完善的前后台开发框架、API 网关(ESB)、调度引擎、公共组件等模块,帮助开发者快速、低成本、免运维地构建支撑工具和运营系统。PaaS 平台为一个应用(运维工具)从创建到部署,再到后续的维护管理提供了完善的自助化和自动化服务,如日志查询、监控告警、运营数据等,从而使开发者可以将全部精力投入到应用的开发之中。主要功能有:支持多语言的开发框架 / 样例、免运维托管、运营数据可视化、企业服务总线(API 网关)、可拖拽的前端服务(MagicBox)等。

06 提升团队能力,真正成功实现运维转型

打造PPP(人员、平台和流程),提升运维团队能力体系,我们很清楚的看到敏捷的趋势、也有很多优秀的互联网公司把成熟的方案进行输出,作为进取的运维团队除了优化系统的结构外,更是要透过学习和实践确保适用于新的体系。

DevOps时代的到来,让我们重新定义运维团队的目标和价值,构建运维场景服务化工具的落地和运维开发转型只是一个过程,而结果往往是激动人心的:通过提高运维效率,助力数字化转型,提高企业竞争力和盈利能力才是终极目标。

标签:运维是,运维,服务化,DevOps,业务,自动化,敏捷,工具
来源: https://blog.csdn.net/weixin_42556618/article/details/118692804