DevOps十大问题
- 2022-06-27 10:00:00
- 丛斌博士
- 转贴：
- 公众号
- 475
DevOps是近十年最重要的软件工程实践，也是我这几年一直关注的。它为解决长期困扰我们的开发和运维的天然矛盾提供了一套新模式，其前景令人期待。
对任何一家IT组织来说，开发的责任就是快速响应客户的IT需求，快速交付新功能或更改的功能。而运维的责任则是为客户提供稳定、可靠、安全的IT服务，避免任何可能导致破坏生产环境的变更部署。
分开看Dev和Ops，无疑是一对矛盾体。通常场景是，为了取悦客户，别管三七二十一，客户的要求都尽量满足，然后研发团队精力严重透支，疲于奔命的救火模式成为必然。过程中各种捷径，积累各种技术债务，带病迭代交付司空见惯。而研发的技术债务首先让运维受害。面对日益膨胀、复杂的应用系统和支持体系，由于缺乏对研发交付软件的信任，任何变更都让运维团队如履薄冰。再者缺乏必要的文档说明，让运维为定位每个小问题头疼。而运维的问题反过来会吃掉研发资源，系统越变越大，运维和研发背的雪球也越来越重。如果各自的考核指标分别反映了各自责任的话，将使二者变成激烈的对抗关系，受害的是用户和组织业务目标的实现。
所以，在敏捷运动出现瓶颈时，DevOps的出现真如雪中送炭，许多有识之士意识到其解决开发运维矛盾的潜力，无数书籍、咨询、培训、工具、成熟度模型扑面而来。一位我认识了二十年之久的朋友，Gene Kim，毅然从网络安全领域，全身心投入到DevOps运动中来，如今已是其重要的领军人物之一。
写了数本DevOps畅销书的Gene Kim
在天时地利人和的背景下，DevOps却依旧有雷声大雨点小的感觉，带来的效果还是远不如人意。我个人总结了下列DevOps十大问题，非权威的一家之言。
问题一：缺乏明确的DevOps愿景
DevOps可以加速软件开发，交付，部署，但每个组织有不同的痛点及需求。没有明确DevOps愿景，对具体解决的问题达成共识，会让转型运动变成飞来飞去的无头苍蝇。借用下CMMI 2.0的理念，DevOps的愿景必须和组织的业务目标紧密结合起来，其成功的标准应该是业务指标的提升，也就是建立明确的DevOps改进和业务目标的可追溯性。
下列问题的答案可以帮助建立你的DevOps愿景，帮助你规划管理好DevOps转型之旅：
- 现有的软件研发流程存在哪些漏洞？
- 需要注意哪些痛点？
- 如何创建“DevOps路线图”？
- 如何培训团队开始使用DevOps？
- 实施DevOps的最终目标和期望是什么？
问题二： 忽略了文化和心态的改变
不少追求DevOps的组织并没有真正理解DevOps，仅将其当做建立工具链的事。没有关注文化，整体开发模式，心态上的改变。要知道，DevOps不仅仅是团队协作、工具链、软件开发模式、敏捷和质量、开发和运维团队的桥梁，它更是一种全新的文化。工具无法建立新的文化，解决文化理念的问题。
- 洞悉DevOps之前的情况、使用的工具和软件研发团队的行为规范
- 确定团队现在的做法，确定团队应该的做法及为什么这样做
- 不仅要用工具培训他们，还要让他们理解DevOps背后的原则
- 建立高层管理人员的习惯会使这一转变更加容易
- 领导者需要为DevOps实践和行为制定标准
问题三：不匹配的过程
在不少推动DevOps和CMMI的组织中，常听到这样的问题：我们已经做了DevOps，还需要CMMI吗？这个问题需要单独探讨，不在本文范围。但不少组织在导入DevOps时，忽略了重塑研发交付过程是不争的事实。DevOps推动了研发过程的 “前伸后仰” ，通过平台工具实现端到端的需求驱动的研发管理，以及CICD pipeline为中心的质量管控模式，形成了可视透明的质量门。显然重塑整个研发交付过程是DevOps转型的重要一步，忽略这一步必定造成不匹配的过程，影响DevOps的持续推动和改进。
问题四：没有正确理解自动化和速度的关系
没有管控好的自动化是危险的。不少朋友可能听过股票实时交易公司Knight Capital的故事，他们通过自动化手段，让用户可以更快速、便捷地完成交易。不幸的是，在开发一个新的app时，这个app调用了一个已经废止但没有删除的内部功能。几分钟之内，这个app做了数十亿美金的交易，后果是公司支付了6.4亿美金罚款后宣布倒闭。不少DevOps转型的组织，没有正确地意识到，是在哪些方面实现了自动化，忘记了自动化虽然强大，但有其局限。不应忘记人机结合的力量，以便更好地管控风险。这里给大家几点建议：
- 改变不会在一夜之间发生；给团队足够的时间适应DevOps环境
- 平衡好速度、约束，让使用DevOps工具链的好处最大化
- 工具不能替代协作，团队之间的协助是DevOps中必须遵循的实践
- 不要期望过早取得好结果；推动DevOps需要比你预期更多的时间
问题五：忽略了DevOps对人的影响
这也是DevOps失败的一个重要原因。DevOps不仅影响研发和运维，它牵扯到许多环节的人。要DevOps取得成功，组织需要确定合适的人，对他们进行培训，给他们时间体验DevOps文化，让他们在学习的同时最大限度地关注其行为的后果。
DevOps应该更关注人和文化，超过关注找到高效、快速交付软件的工具。把视角转向人，那就看到了DevOps的重要驱动因素。反之，你会成为又一个失败的反面教材。
问题六：缺乏坚实的基础架构建设
正如CMMI 2.0中II实践域指出的，DevOps基础架构的建立需要一个深思熟虑的策略来规划、验证、同步和监控DevOps工具链。通过持续的检查和度量分析，不断完善DevOps过程实践，在努力中争取获得预期的结果。由于资源等问题，不少DevOps组织没有建立一个必要的支持体系，有效支持DevOps的落地和不断改进。CMMI中的II给出了建立这样的基础架构的要点。
问题七：让DevOps成了脱离客户的独角戏
没有客户介入的DevOps会让其价值大打折扣，虽然国内许多IT成熟度较高的客户推动了DevOps的推广，但自说自话的情况也比比皆是。许多客观原因造成了这种情况：内部环境和客户现场环境的差异，客户不愿做额外投入等。但DevOps的组织需要让客户了解，他们是DevOps最大的受益者，这是个高性价比的投入。
问题八：不适用于DevOps的软件架构
这个问题牵扯到比较复杂的技术问题，如何将现有软件架构迁移成为适用于DevOps模式的架构是许多DevOps组织面临的一个挑战，毕竟重构软件架构不是一件容易事。
问题九：研发过程管理和质量管控的物理和逻辑分离
绝大多数DevOps组织有两个不同的管理平台，一个平台实现从需求跟踪到环境发布的所有管理要求；一个平台通过建立工具链（如，CICD pipeline）实现质量相关管理功能，例如：静态代码扫描，接口测试，安全扫描，压力/性能测试等活动。二者物理分离会造成一些不便，但逻辑分离则会带来严重的后果。一些组织没有从顶层、端到端考虑二者的关系，导致flow的脱节。在这方面，CMMI可以助力DevOps，实现系统和一致的规划管理。
问题十·：和CMMI的脱节
在做CMMI评估和诊断时，发现DevOps和CMMI的脱节是一个普遍问题。后面会专门就如何让二者相辅相成写篇文章。四年前，CMMI研究院就计划推出关于DevOps场景的CMMI实施，可惜至今没有看到实质的成果。一方面，CMMI可以助力DevOps转型，另一方面，CMMI可以从DevOps实践中完善一些核心实践。在等待研究院发布其研究结果的同时，DevOps和CMMI组织也可以总结优秀实践，更新CMMI的生命力，实现DevOps的初衷，改善软件世界。
| 联系人： | 阿道 |
|---|---|
| 电话： | 17762006160 |
| 地址： | 青岛市黄岛区井冈山路157号中南金石国际广场A座3202室 |
