DevOps-实践心得

基于最近几年从事与DevOps的相关实践，对这篇文章的观点深有体会，所以记录在这里。加粗部分是我比较深有体会的，但是对于最后作者对于“运维”有些悲观，我有点不敢苟同，反而对于运维的要求其实是更高了，”自动化-容器化-集群-智能化“代替了传统的“人肉”

1. DevOps 的本质

DevOps从本质来讲只是倡导开发运维一体化的理念（MindSet）。这个理念的提出是为了解决很多企业面临的转型挑战，也就是将业务数字化，并且缩短数字化业务上线的周期，快速试错，快速占领市场。

DevOps并没有改变固有的软件生命周期：需求，设计，开发，测试，交付。但伴随着基础设施，软件设计方法等的改变，软件开发的思路，或者方式产生了比较大的变化。

DevOps带来的最大好处是，软件生命周期数据链路的打通

这不仅仅是运维和开发的结合。从顶层视角看，这是业务和生产的紧密结合。以前从业务和开发是脱节的。想要查看需求的实现进度，需要大量的人工汇报，更别提运营了。而现在以一个微服务实现一个特性的粒度来看，可以从需求，开发，测试，部署一直追溯到这个特性运营情况。这也是DevOps成为数字化企业基因的原因，业务和生产实现了完美的结合。

从敏捷实践的角度来讲，你会发现开发组织中参与者好似生物体中的神经元，大家各司其职，自成一体，接受反馈，并向外主动反馈。团队的自组织使得工作更加自然，能产生更大的效能。由以前的项目经理驱动，改为自我驱动的协作方式。每个人都可以给相关的团队以及责任人提需求，大家有机的协调在一起。

2. 一个DevOps改造案例

这里给大家分享一个改造案例，公司A存在的问题：

1. 软件交付周期很长，一年只能交付一个大版本，以及一个小版本。
2. 人员分工不明确，一个决定的做出往往需要很多人参与。
3. 用大量的时间挖掘需求。在真正的开发期，会发现用户的需求仍在改变。需求分析的时间被浪费。
4. 采用瀑布模式开发，在不同时期，某些角色的人员会无事可做。
5. 在软件交付过程中，开发与运维人员需要花费大量的时间去协调产品安装，配置中出现的问题。

改造步骤：

• 第一阶段：
  行动：为了实行DevOps，公司A为不同的生命周期购置了支撑工具，涵盖JIRA, PagerDuty，GitHubEnterprise，Jenkins等。公司针对每个工具都进行了专门培训，专人管理。

  结果：大家开始将不同的工具应用到软件生产的各个环节中，统一的工具塑造了统一的工作方式，创造了工作契约。统一工具的运用确实对软件交付带来了一些积极的改变。

• 第二阶段：

  问题：各个工具仍旧是割裂的，代码管理和任务管理无法协调。开发人员声明已经完成的工作，测试人员却发现无法找到构建来完成测试。运维人员和开发人员只是利用了同一种工具，而没有做到工作产物的共享。

  行动：公司A开始关注工具所提供的能力而不是功能，将不同工具的关键交付物连接起来，形成可追溯的管理。开发人员发现提交的代码可以产生可用构建后才声明功能完成。并且用同一个任务来追溯开发到上线的工作。尤在开发与运维结合方面，运维人员可以利用开发人员已经实现的部署设计，进行发布演练，确保软件平滑交付。

• 第三阶段：

  问题：有了好的工具，但是公司A发现虽然开发到运维的路通了，但是软件质量却难以保证，甚至在产品发布日期邻近的时候，仍有很多未完成的任务，测试团队顶着很大的压力，最终还是会发生不少测试逃逸，产品的技术欠债比较大。

  行动：在开发阶段采取分支开发的方法，功能实现并且通过一定的代码测试之后才能合并到主干。开发人员负责部分的测试任务，由于对产品比较熟悉，所以加快了测试效率。专门的测试团队会承担例如性能测试等更加专业的测试任务。有节奏的控制软件开发的进度，在软件发布的稳定期严格控制代码提交，每个新功能的开发负责人会和运维人员一起进行发布演练，DevOps的好处终于开始见效。

• 第四阶段：
  问题：团队前期在需求分析中会花费大量的时间进行文档编写，但开发开始后，开发人员会花费大量的时间对文档进行理解，并且用户对需求的调整最终导致文档失去维护的意义；大家的主动性不强，需要领导的督促才能进行工作安排。

  行动：公司A意识到他们之前只是采用看似敏捷的方式，实际瀑布的方式做开发。比如说项目经理变成了Scrum主管，周会变成了每天的站会。在进行调研分析后，公司A决定开始进行敏捷实践。分阶段的按照重要程度以及优先级进行需求规划，周期性的互动使得客户在第一时间可以看到期望的需求被逐步实现，双方都避免最后一科的意外。开发人员发现可以对自己负责的任务有话语权之后，大大激发了积极性，大家开始主动的从Backlog中寻找重要的任务去实现。

从以上的例子可以看出，一个好工具的运用会对工作产生积极的影响，但是更核心的是人做事思维，以及人与人之间的协作方式才会体现DevOps的好处，我想从这点大家可以看到为什么DevOps是一种Mindset。

3. 微服务、容器和DevOps的关系

微服务只是一种设计思路，或者说他给出了如何用正确的方法来进行SOA的实施。理论上来讲他的确和DevOps没什么关系，但是从如何实践DevOps的角度来讲，微服务是非常有意义的。此外，随着诸如Spring Cloud以及微软Fabric等SDK的完善，微服务开发模式也逐步完善，实现了概念的落地

Docker可谓是一种敏捷化的虚拟化技术（较之虚拟机而言）。其实微软Fabric或者CloudFoundry也都脱离开容器的概念提供了微服务开发的解决方案，所以这两者并不是强绑定的关系。但是容器用不可变配置架构实现了微服务从开发到运维的质量保真度，这恰好解决了粒度小，数量多的微服务所带来的运维难题。再加上K8S，Swarm等容器云的支持，docker容器已经形成了事实上的标准。

如何利用这个强大的运行环境帮助企业敏捷，推进业务数字化，并且加快业务的投产？ DevOps为上面所说的开发模式提供了软件生产线。

所以总结的来讲，企业业务敏捷是DevOps发展的直接推动力，容器云，以及微服务为DevOps提供了技术可行性。而敏捷帮助提高DevOps工作效能。

对于团队的拆分，这个问题真的要结合产品规模来看。团队的拆分有很多办法，贝索斯说的two pizza team，是建议一个团队中的人尽可能少，不要超过两个Pizza能吃饱的规模。用敏捷实践来讲，可以分为多个特性团队，以及维护团队，不同的团队各司其职，合理分工。在我以前的实践中，三个人可以做一个Feature，来交付一个月迭代的工作量。

当然将原有的巨石应用分割成更小的微服务是挑战很大的事情。因为理论上的微服务的设计对现有的团队组织结构，以及工程师设计能力都带来了一定的挑战。有些组织按照DDD（领域驱动的设计）的方式去实践微服务，会发现以前一个应用的复杂度变得很高，对项目管理来讲也是一件头疼的事情。现在有个比较新的看法就是，大家宣称做微服务（MicroService）的时候，实际上做的是迷你服务（MiniService）。迷你服务的粒度较之微服务的粒度更粗一些，关注度由一个域Domain，变成了能力。一个迷你服务提供一种能力，这种能力的提供也许是跨越多个域的。

最好的方法是以一个团队能承担的任务划定微服务的界限比较好，这样以来，不论是任务管理，代码构建，产品部署都会比较好做。

更关注服务的能力，这样也会减少因为跨域而带来的复杂事物处理

4. 为什么落地DevOps还是那么难？

我认为DevOps概念对市场的教育工作已经完成了，并且它宣传在国内有点泛滥的趋势，甚至一些以前做项目管理工具的厂商也宣传他们在做DevOps。究其原因在于DevOps的概念太大，几乎可以成为软件工程的代名词。

至于落地的痛点，我觉得有以下几个：

1. DevOps对于组织来讲是一个系统工程化的投入，在贯彻的过程中，需要一个组织建立标准，统一纪律，而这个过程往往需要组织中的强力部门自始至终的贯彻执行。

2. DevOps对组织现存的管理方式，或者人员知识结构多少带来了一些挑战。

3. 认为购置了工具就是DevOps，却忽略了工具产物之间的联系。

4. 认为有了全生命周期的工具就是DevOps，忽略了软件过程方法的运用，所以很多组织停留在用旧的方法使用新的工具上。

开启DevOps工具和文化缺一不可。DevOps的最高目标是让组织内的人都具有相同的工作理念，最终形成一种工作文化。而有些倡导者谈到如何去培养这种文化就显得有点空谈了。我认为在形成DevOps文化的过程中，敏捷实践必不可少。过去的敏捷实践更多的是在开发阶段，而现在DevOps的理念下，其实可以很顺畅的将部署阶段的事情也纳入敏捷实践中。让合适的人去做合适的事。当然团队文化的改变需要一个过程。

我认为以敏捷方法为核心配合以下三个方面来开启DevOps。

• 看板：以任务的状态为核心，管理在制品的生产情况。任务是自组织团队的工作契约。

• 基线：以工件的版本为核心，选取合格的交付物。比如说开发团队决定哪个代码提交版本，或者编译的构建版本为最终交付的版本。度量指导基线的产生。

• 流水线：以生命周期的阶段为核心，控制基线交付物的投产。比如说一个合格的代码基线目前处于编译态，还是部署态。自动化工具围绕管道互相集成。

其实工具和文化最终的落实还是要靠人的提高，特别是通过上一段举出的例子。

DevOps会重新塑造IT组织的研发系统，从工具到文化，再到方法。因此参与这个生态系统的所有人都应该关注。

• 从开发的角度看：开发人员会变得更加业务化，有更多的机会和客户交流。开发人员将从以前对代码负责，转向编译构建负责，对测试负责，甚至对部署物负责。敏捷可以让需求足够的小，这样就可以让一个开发人员变得全生命周期化了。

• 从运维的角度看：其实运维的前景是有些悲观了，至少运维的规模要缩减很多。

  原因有三。首先，自动化部署工具的发展，使得部署工作提前了，以前碎片化的脚本，被更加规范化的部署设计代替，用设计驱动脚本生成，这都是自动化的。其次，基础环境的改善使得开发环境和生产环境的差异性极大缩小了，企业完全可以制造一个和生产环境一样的预发环境，来保证交付的成功率。容器技术的不可变配置也保证了同样的镜像在不同的环境中不会出现太大的差异。最后，运维工作相对开发工作来讲，可以自动化，甚至运用人工智能的空间都比较大。我们已经看到百度已经开始AIOps。