浅谈DevOps

        笔者做过一些时间技术管理，3年之前说到项目管理和交付，谈的最多的就是敏捷开发、持续集成、持续交付，最近几年谈起来必说DevOps。我想谈谈我的理解，首先抛出3个问题：（1）DevOps就是敏捷开发加CI持续集成么？（2）DevOps似乎要投入很多人力，小公司有搞这个的必要么？（3）我们应该如何优化开发流程向DevOps靠拢？

        DevOps的目的是为了高效交付，打破开发developement和operations之间的壁垒。在好些年前，笔者参加电信项目的开发，都是开发人员写完代码、自测，然后测试人员经过几轮测试，然后提交版本给专业的运维人员去部署、运维升级。因为电信项目升级严格，当时一个项目一年发布给运维的版本可能只有2-3个，但是这个过程中需求可能会持续变化。所以当时项目的痛点是快速响应需求变化、快速迭代，打破开发和测试各自为战的特点；于是采用敏捷开发的思路，将以前分隔开的开发团队和测试团队融合管理，按照某个需求特性feature组成敏捷小组，借助敏捷管理过程比如scrum来管理需求开发，借助持续集成工具如jenkins来整合开发、单元测试、集成测试、系统测试、构建发布多个过程。那么按照这个思路，DevOps是不是把运维人员加入到敏捷团队，持续集成工具进行一些运维的扩展就行了？不完全是这样，我们是需要对整个开发过程进行改造，当然敏捷开发过程是必不可少的。

        改造整个开发过程，似乎工作量很大，需要很多人力，技术团队只有几个或10来个人的小型公司没法做吧。其实恰恰相反，人力少执行更快，可以更高效进行敏捷开发和运维响应，但是由于人力有限，部分开发活动可以以变通的形式进行。在人力少的情况下，天然的就是谁开发谁运行。在人力少的情况下，其实部分开发人员都是身兼多种角色的。比如开发初期可能就是需求分析人员、开发阶段即是开发人员又兼职部分测试工作、部署阶段就变成了运维人员，这依然符合敏捷实践。（说到这里，顺便提一句，有一些团队管理者认为应该一个萝卜一个坑，每个角色都用专门的人来做，这样更专业效率更高。其实实施起来人力浪费很严重，也限制了开发人员的职业发展。高效的敏捷团队是鼓励所有人进行角色变换的，比如说在不同开发阶段或者做不同的feature时就可以变换角色。）在人力少的情况下，部分开发活动可以进行简化，比如需求输出文档和设计文档输出形式、运维工具简化、操作文档简化等。

        现有的敏捷开发流程应该要进行如下的一些改造来契合DevOps开发过程。（1）整个敏捷开发团队要加入运维人员；（2）需求分析阶段要引入运维需求，包含可部署性、监控、可扩展等；（3）开发阶段运维人员要参与交付测试；持续集成和持续交付流程要衔接起来；（4）升级和部署阶段使用经过检验的开发运维工具提高效率。比如通过配置工具、容器工具实现自动化快速部署。