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