DevOps 实施经常失败。以下是原因(以及如何推进)。





0/5 (0投票)
DevOps 为积极的变革奠定了文化基础,但从那里转向一个将“安全”融入“DevSecOps”的环境是必要且不那么痛苦的转变。
与“区块链”、“大数据”和“数字化颠覆”一样,“DevOps”是另一个在大型组织的 IT 部门中被广泛使用的术语,但对于这个术语,开发经理面临着重大的变革,具体取决于公司 SDLC 的成熟度。
许多人(正确地)认识到需要更快的软件开发生命周期;一个更精确的过程,与业务目标紧密结合,允许开发团队和运维团队之间更清晰的工作流程和协作。DevOps 本质上是“敏捷”开发的成熟版,已准备好应对现代企业不断创新、快速部署的需求。
问题是,很少有公司在 DevOps 实施中真正取得成功。如果没有整个业务的正确支持、培养和理解,它很快就会成为那些“不要提及战争”的项目之一,每个人都只是继续以他们以前的任何功能障碍进行操作。
对于安全专业人员来说,这是一个很好的倡议,但它仍然没有像理想那样从一开始就将安全团队融入其中;然而,安全仍然可以比瀑布方法更早地注入到流程中(是的,这是一个旧的流程……然而,许多组织仍然采用这种方法),从而降低修复 bug 的成本并帮助避免潜在的灾难。
那么,问题出在哪里?这又回到了一个事实:成功执行更新的方法是无法买到的。一个有效的程序不仅仅是几个花哨的新工具、头衔和团队会议。它不会总是那么容易,但从长远来看,花时间修复一个有缺陷的策略(或者从一开始就以正确的方式实施它)会痛苦得多。最终,它将使您的开发人员能够开发出更高质量的软件,并为更好的安全结果铺平道路。
让我们分解一下
放开“敏捷”的束缚
存在一种误解,认为组织必须在敏捷或 DevOps 之间做出选择,走上其中一条道路,永不回头。
事实是,当两者都被视为并作为一个整体实施时,开发过程才能发挥最佳作用。DevOps 并非敏捷开发的重塑;相反,它是敏捷开发的延伸。当期望流程与敏捷完全相同,或者与敏捷完全不同时,问题就会出现。敏捷支持跨职能团队的原则,从一开始就将设计师、测试人员和开发人员聚集在一起,并在整个项目中致力于开放的沟通渠道。其目标是停止孤立交付并减少重复处理,这两者都是 DevOps 流程的优势。然而,DevOps 更进一步,将开发人员、系统和运营人员引入其中,以提供强大的端到端技能,其最终目标是向客户提供完整的、功能性的软件。安全性也更早被考虑,尽管即使在这种环境中,独立的应用程序安全团队仍然相当常见。
在转向以 DevOps 为中心的过程中不可避免的痛点期间,孤立开发的风险可能会再次出现。您通常可以让最初的敏捷团队一起工作,而安全和运营的补充仍然在机器中寻找自己的位置;没有人确切知道如何将他们纳入其中,他们应该做什么以及他们的总体目标。
DevOps 离不开清晰定义的目标、跨职能的入职培训以及与所有各方的直接沟通。当然,会有一个需要仔细变更管理的调整期,但让每个人都就 DevOps 功能将带来的改进达成共识是成功的一半。
值得庆幸的是,DevOps 越来越强调将安全最佳实践作为流程的一部分,从而揭开了这一步骤的神秘面纱,并弥合了安全团队与其他人之间的鸿沟。正如我之前所说,我们在从一开始就赋予开发人员安全编码能力方面还有很长的路要走,但成功实施 DevOps 方法论是构建一个成熟的 DevSecOps 计划的绝佳基础,将安全作为首要目标和共同责任,并为开发人员提供他们在这个过程中茁壮成长所需的支持。
自动化并非万能(也并非最安全)
DevOps 的主要特点,在某种程度上,是软件开发过程的自动化。持续集成和持续交付(CI/CD)原则是这一概念的基石,正如您可能知道的,它们非常依赖工具。
工具很棒,确实如此。它们可以为软件交付过程带来前所未有的速度,以相对无缝的轻松管理代码仓库、测试、维护和存储元素。如果您在一个 DevOps 流程中管理一个开发人员团队,这些工具和使用它们的人是交付高质量软件的关键部分。
然而,虽然机器人总有一天可能会取代我们的工作并囚禁我们,但它们还没有达到那个程度。过度依赖工具和自动化会留下巨大的错误窗口。扫描和测试可能无法发现所有问题,代码可能未经检查,这会带来巨大的质量(更不用说安全)问题。攻击者只需要一个后门就可以窃取数据,而放弃质量和安全控制中的人为因素可能会导致灾难性的后果。
“最佳方案”是确保您在人员和工具之间取得平衡。工具应该作为您信任的团队的助手,以实现项目目标。您应该
- 为人们分配足够的时间,让他们熟悉所选的 DevOps 工具链
- 专注于有效的协作(以及工具如何支持这种协作)
- 解决流程中的任何空白,无论是技能/知识方面的还是基于工具方面的。
简而言之,不要仅仅“武装”起来,然后听天由命。
DevOps 不是一个流行词,它是一种文化。您正在培养您的文化吗?
在最好的时候,变革管理也很艰难。对未知的恐惧甚至会阻止最杰出的团队成员发展他们的技能和拓展他们的视野。
你看,仅仅说“我们来做 DevOps”并让运营团队搬离办公桌并不能奇迹般地实施成功的流程。许多人会感到困惑,长期服务的团队成员会感到不满。沟通期望至关重要,言行一致也同样重要。DevOps 既代表着一种文化运动,也代表着一种开发方法,团队应该秉持跨职能、协作的心态。
开发经理需要为他们的团队提供支持,并在可能不舒服的调整期内提供帮助。
一个优秀的 DevOps 文化是什么样的?
- 个人被授权将他们的专业知识贡献给一个流程,而不仅仅是领导者
- 团队之间开放、诚实和尊重的沟通
- 每个人都对在开发过程中构建质量(并希望是安全性)的总体目标负责
- 每个人都对业务中 DevOps 的定义、路线图以及每个人的角色如何/什么/为什么达成共识。
当我说这是卓越安全的基础时,我相信大多数元素都有助于为我们(迅速)需要达到的目标铺平道路:DevSecOps 最佳实践。
将重心转向 DevSecOps
多年来,我一直强调在组织中建立积极安全文化的重要性,而 DevSecOps 正是促进将安全作为一项共同责任,并使其成为软件开发过程伊始的首要目标。
正确的工具、知识和支持对于实现安全最佳实践、减少已发现的漏洞以及让团队认识到保护我们数据的重要性至关重要。DevOps 为积极变革奠定了文化基础,但转向一个将“安全”融入“DevSecOps”的环境是必要且不那么痛苦的过渡。确保每个人——尤其是开发人员——理解他们的角色、价值、期望,以及整个项目目标和过程中的步骤。而且您必须确保他们拥有成功所需的一切——不要随意给他们任何旧培训,也不要为了交付代码的速度而牺牲安全性。帮助整个团队理解其重要性,以及他们可以轻而易举地产生巨大的积极影响。
公司范围内的安全意识是必须的,但您的开发人员可以通过正确的团队领导倡导者、正确的工具和时间来掌握安全编码,成为第一道防线。
不确定如何开始 DevSec?获取安全的五点战术开发。