阻碍您采用DevOps的三大因素

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

不，不是泛指的“你”。就是您。与一线人员相比，企业高管对DevOps的热情远没有那么高，原因可能就在以下三个关键问题之一。

高绩效组织不仅采用了DevOps，更是全面接纳了这一理念。Puppet Labs具有开创意义的《DevOps现状报告》在过去两年中一直印证了这一点，我认为来年该报告还会再次强化这种关联。多项行业调查和研究显示，各组织正在采用DevOps。但正如它们过去采用敏捷、精益应用开发方法一样，“采用”并不总是我们通常理解的含义。事实证明，组织所说的在应用开发中“采用敏捷”，实际上只是相对较少的项目使用了敏捷方法，并不意味着它们已经不留余地地在每个项目中全面采用敏捷方法。

DevOps似乎也是如此。受访者正积极采用这种方法，并已取得成效，但高管整体上似乎仍对此态度冷淡。根据我们的《应用交付现状》调查，DevOps的“战略影响”同比仅上升2个百分点，从2016年的15%升至2017年的17%。云架构师和自认为从事“DevOps”工作的人员可能正全力推进DevOps计划，甚至已将其投入生产环境，但高管在接受这种方法方面仍然落后。这实际上意味着，“组织”未必已全面接受DevOps。

有三个关键问题可能导致IT和业务领导层未能真正积极接纳DevOps。

1. 时间。任何需要转型思维的内部IT项目，无论是从传统架构迁移到云端、从单体架构转向微服务，还是从手动操作转向自动化，有时都被视为只会浪费时间。这些项目不会直接推动业务增长，因此业务利益相关者可能很难支持在此类项目上投入时间。DevOps的支持者应向业务领导者明确说明开展此类项目的目标和预期收益。无论是节省成本，还是提高IT响应能力，都应让业务部门了解预期投资回报，从而争取其认同和支持。节省一分钱或许等于赚到一分钱，但投入一分钱往往能带来十分钱的回报。现在投资DevOps，组织将在未来获得回报。
   
2. 中断。没有哪位IT领导者愿意成为业务中断的原因。现在投资DevOps计划可能会造成中断，尤其是当所有人都知道需要加快生产流程，而该计划却导致流程放缓时。要实现生产自动化和编排，往往需要调整支撑日常业务的系统，因此，任何涉及此类调整的计划都可能造成不必要的中断。事实上，依赖过时的手动方法来配置、扩展和管理系统，可能才是真正的中断因素，即使今天不是，明天也可能是。顺畅生产环境的一项重要特征，是能够按需响应容量和服务需求。随着数字化转型带来的需求不断增长，IT不堪重负，实现这一点也会越来越困难。没有风险，就没有回报。与应用组合增长到当前规模的2倍或更大时相比，现在承担风险可能反而风险更低。
   
3. 供应商锁定。IT领导者普遍担心，所做的选择会导致“供应商锁定”。好消息是，大多数支持自动化和编排的网络设备与系统都基于HTTP、REST和JSON等开放标准协议与概念。因此，前期投入的时间应用于系统设计和架构，尽可能充分利用API和模板，将在日后带来回报。如果集成的设备或系统要求通过API逐步重现CLI发出的命令，几乎必然会导致供应商锁定。模板的一大优势在于，它可以减少对设备和系统专用API的依赖，从而将相关依赖限制在少量命令内，便于日后迁移到新系统或应用。请确保基础设施支持基于REST的API，并尽可能使用模板，以便日后轻松从系统和环境中迁出。

当然，还有其他顾虑，但在采用技术和方法时，数据中心长期以来主要反复面临这三个关键问题：需要时间、可能造成业务中断，而且很可能形成锁定。开展尽职调查，审慎规划实施方式，并秉持“现在投入、日后受益”的理念，有助于缓解这些顾虑，提高成功构建稳固而灵活基础的可能性。这样的基础不仅能支持数字化转型，还能加速转型进程，满足企业当前及未来发展的需要。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章