DevOps 实践中的“道法术器”

IT 服务管理指的是传统 IT 管控方面的工作，DevOps 没有否定流程管理，但希望流程管理是轻量化、精简、最小级的流程，是精益管理的思路。要把现有流程中浪费资源、对生产力影响不大的环节精简或者优化。以将 DevOps 的实践理论框架执行到具体项目里，总结了以下几个层次。

1、第一个是“道”

如果准备实施 DevOps，就要先找到所要交付的 IT 服务的业务价值点，要先找业务导向性明显的项目去落地 DevOps，这样团队会更清楚应该关注什么。例如，一些管理系统在项目里落地 DevOps 的时候，除非管理思路特别明确，否则不同团队之间在描述共同价值的时候并不太容易，团队合作的基础就会大大削弱。所以在选择 DevOps 试点项目的时候，要找到高业务价值的系统去做尝试，然后建立开发、交付、反馈的机制。换句话说，就是一定要把需求、开发、测试、运维这几个不同团队的人聚在一起，先弄清楚我们要做的 IT 系统是如何为业务服务的，支撑的业务是如何运营并为公司盈利的，这样团队才能找到沟通和交流的共同语言。

2、第二个是“法”

要引入什么策略来实现 DevOps 的实践，站在具体的策略上来说，应该从以下 6 个方面来考虑。

• 管理模式敏捷化：具体引入何种策略取决于管理模式的敏捷化，因为敏捷管理其实是 DevOps 最核心的思想。没有敏捷管理，单纯做 DevOps 工具是无法做好流水线的，原因就在于没有敏捷这种组织结构和文化来真正驱动 DevOps。

• 流程管理统一化：根据具体实施项目的背景和组织文化，对原有的 ITSM 流程进行精简和标准化。

• 持续集成与测试：搭建持续集成流水线很简单，但要搭建自动化测试框架并集成就比较困难了，因为传统项目基本上很难实现整个交付过程中自动化的测试。在互联网项目里，需求分析是以用户故事场景来驱动的，这样会带来一个好处，测试验收的案例是天然形成的，因为需求是根据业务使用的每一个步骤定义出来的。我们平时在网上使用支付宝，应用场景是先选购一个商品，然后打开支付页面，选定账号，提交订单，最后输入密码。每一步的场景定义都很清楚，这样可以很方便地做自动化测试。对比来说，一个电信运营商的业务支撑系统的应用场景是一堆复用的场景，也就是说，语音套餐是一个过程，宽带如何复用或者互相影响，这个场景其实很复杂。一开始做需求分析很难把这个场景故事化，这样就没有办法搭建很全面的自动化测试使得代码真正流转过去。当然，DevOps 也不强调测试一定要全部自动化，通常来说我们希望单元测试、验收测试等需要在持续集成的流水线上自动执行，功能测试和性能测试等也应该尽可能地自动化实现。

• 持续部署与交付：即需要对所有环境进行统一的定义和管理，并在此基础上制订自动化交付的管理策略，并以自动化部署和验证的方式实施。

• 持续运营与监控：程序部署完成之后，还需要一系列自动化的方式来对业务运营情况进行管理和监控，如果程序设计足够服务化和弹性，那么就可以将运营监控的工作集中于业务的连续性监控，这是一种理想的运营模式，但是需要业务服务架构的支持。

• 持续评估与反馈：站在运营管理的角度，需要将生产系统的运行情况进行持续评估，并反馈到所有的项目成员那里。

3、第三个是“术”

用什么方式来开展这方面的工作，要关注哪些具体的事情。这些事情包括开发环境构建自动化、持续构建自动化、质量分析效率化、测试环境构建自动化、持续测试自动化、持续部署自动化、系统运维监控自动化、需求开发测试运维的流水线可视化、Scrum+KANBAN+ITIL+DevOps 流水线自动化平台支撑等。

4、第四个是“器”

在 DevOps 成熟的开源社区里有很多工具都可以直接拿来用，这些工具可以帮助我们搭建自己的 DevOps 流水线。