为什么 DevOps 会失败?

由于对高质量应用程序快速交付的需求日益增加,企业对 DevOps 解决方案和服务的需求也在快速增长。报告显示,DevOps 市场规模预计将从 2017 年的 29.0 亿美元增长到 2023 年的 103.1 亿美元,预测期内的复合年增长率 (CAGR) 为 24.7%。

然而,距离 2008 年 Petrick Debois 在多伦多敏捷会议上提出 “ DevOps” 一词已有 14 年了,敏捷和 DevOps 模型在某种程度上仍然未能满足软件交付速度和质量的预期图景。Gartner 预测,由于领导方法的局限性,而非技术原因,到 2023 年,90% 的 DevOps 计划将无法达到预期。

要探究 DevOps 为什么会失败这个问题,不妨回到最原始的话题: DevOps 到底是什么?它是我们常挂在嘴边的 “团队协作”、“工具链”、“软件开发模型”、“敏捷性和质量”、“开发和运营团队之间的桥梁” 吗?它是,但又不仅于此。

文化是跨越鸿沟的武器

文化是一套加强组织结构的实践、标准、信念和结构,,其重要性不言而喻。如果没有文化,开发团队就无法掌握 DevOps 的精髓,开发和运维团队之间的鸿沟也就无法弥合。在 Gartner 2017 年企业 DevOps 调查中,88% 的受访者表示,团队文化是对企业扩展 DevOps 能力影响最大的、与人员相关的属性之一。

然而,组织忽略了让员工参与即将到来的变革的重要性,而是将精力集中在 DevOps 工具上。 对此,Gartner 研究总监 George Spafford 曾表示:“工具不是解决文化问题的方法。”

那么如何设置正确的 “DevOps” 文化?

●观察软件开发团队在 DevOps 之前的情况、工具和行为;

●确定 “他们做什么” 和 “他们应该做什么以及为什么”;

●不仅使用工具培训他们,而且让他们了解 DevOps 是一种哲学;

●通过建立高层管理的习惯,使这种转变更容易;

●领导者需要为 DevOps 实践和行为设定标准。

有许多方法和实践可以帮助实施 DevOps 并保证结果。大多数情况下,企业追求的是工具而不是文化转变,这成为 DevOps 失败的最大原因。

自动化并不意味着速度

Knight Capital 是一家实时股票交易公司,通过自动化技术,使得用户交易变得更快、更容易。然而,在为应用程序编写新代码时,新代码意外调用了旧功能 —— 该功能处于非活动状态但未从内部应用程序中删除。

结果,Knight 的应用程序在几分钟内就发出了价值数十亿的订单,该公司不得不支付 6.4 亿美元的罚款,从而导致破产。

这个教训值得令人深思。在持续集成和持续交付 (CI/CD) 原则下,DevOps 确实能够自动化软件开发过程,因为有大量工具可用于代码存储、测试和维护。但是,仍然有几点需要考虑:

●自动化是强大的,但人们不应该忘记机器与人结合的力量,以提高准确性;

●改变不会在一夜之间发生,要让团队有足够的时间在 DevOps 环境中工作;

●做好速度和风险之间的平衡;

●使协作成为团队之间的必要实践;

不要太早期待好的结果,扩展 DevOps 需要的时间可能比预想的更多。因此,使用任何自动化工具时,一定要提前规划、验证、同步和监控 DevOps 工具链。与此同时,DevOps 更关注人员和文化,而不是用于以最高效率快速交付软件的工具。在实践 DevOps 时,要将关注点转向人,因为他们是 DevOps 的基本驱动力之一。

开发和运维不应成为孤岛

DevOps 是 “开发” 和 “运维” 团队的合并,它象征着强有力的协作。然而,在很多企业,这两个团体在 DevOps 流程中形同孤岛,互不往来。

要想提高软件交付效率,必须要打破壁垒,营造团队氛围,让不同的团队必须一起工作,而不是在不协调的孤岛中工作。

有时,尽管基础设施和运营(I&O)领导者深知与 DevOps 协作的重要性及益处,但在采用新的工作方式时常常会面临文化阻力。因此,I&O 领导者应关注于可交付衡量的业务价值,与 DevOps 团队构建共同目标,从而鼓励彼此协作。

Gartner 高级研究总监 周玲也曾发文指出:“DevOps 的成功离不开有效的团队协作,需要团队成员目标一致、齐心协力。为了更好地支持 DevOps 团队,实现持续集成(CI)/ 持续交付(CD)和自动化,并为基础设施即代码(如 Terraform、Pulumi)或云管理平台提供能力,I&O 团队应规划价值流,明确相关团队中的利益相关者及运营需求。这些相关团队包括 DevOps 团队,或来自业务、技术、监管合规或安全和风险部门的融合团队。”

文化问题是 DevOps 的经典问题,不是一朝一夕就能解决的。不仅是 I&O 团队与 DevOps 团队的协作与融合,即使是 DevOps 团队内部也存在因为不同环节的人员对产品功能的理解和认识存在差异而导致整个项目朝着不同的方向发展。这种情况下,不可能推进 DevOps 的真正落地。

所以,尽管自动化工具不是一切,但是不可否认,其可以在一定程度上实现软件开发流程的定量标准化,成为实践 DevOps 最好的切入点。

以飞算推出的 SoFlu 软件机器人为例,这是一款覆盖了软件全生命周期的国产 DevOps 工具,包含后端全自动开发平台、前端全自动开发平台、全自动测试平台、全自动运维平台。而且,由于具备可视化的开发界面,门槛低,效率高,实现一 “人” 全栈解决:后端开发、前端开发、测试、运维,减少了企业对 IT 人才的依赖性,真正做到了 “一人一项目,十人抵百人”。

就连倪光南院士都曾对其大加赞誉:“SoFlu 软件机器人的价值在于通过标准化、自动化的流程,降低了从开发、测试到运维的门槛,将敏捷管理制度落地。一年半以来,我亲眼见证了 SoFlu 软件机器人的诞生和成长,很兴奋看到 SoFlu 软件机器人已经在金融、医疗、零售等多个行业得到应用和肯定,帮助企业大幅度的降本增效。”

良好的开端是成功的一半。实践 DevOps ,不妨从自动化开发平台 ——SoFlu 软件机器人开始。

现在可申请免费试用 SoFlu 软件机器人 30 天,了解更多软件开发信息,可添加微信: feisuan123,备注 “加群”,入群讨论。

(免责声明:本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿,凡在本网站出现的信息,均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性,但不保证有关资料的准确性及可靠性,读者在使用前请进一步核实,并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时,应及时向本网站提出书面权利通知或不实情况说明,并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后,将会依法尽快联系相关文章源头核实,沟通删除相关内容或断开相关链接。 )