为什么 DevOps 实施经常不成功（以及如何修复它）
本文最初发表于 Devops.com。现已更新并修订。
就像“区块链”、“大数据”和“数字颠覆”一样，“DevOps”一词是大型组织IT部门目前流行的另一个流行语。
许多人已经（正确地）认识到需要更快的软件开发生命周期；一个与业务目标紧密关联的更精确流程，从而使开发团队和运维团队之间能够建立更清晰的工作流程与协作机制。DevOps 本质上是 敏捷开发，所有开发人员都成长起来，随时准备应对现代业务不断创新、快速部署的需求。对于安全专业人员而言，这是一项了不起的举措：我们可以更早地为流程注入安全性，从而降低修复错误的成本并避免潜在的灾难。
问题在于，很少有公司能真正成功实施DevOps。如果没有整个企业的适当支持、培育和理解，它很快就会变成一头白象……你知道的，就是那些"别提战争"的项目之一。
那么，问题是什么？这是一个有趣的讨论，我相信有几种方法可以实现DevOps，这将使航行变得更加顺利。有效的计划不仅仅是一些花哨的新工具、头衔和团队会议。这并不总是那么容易，但从长远来看，花时间修复一个失效的策略（或从一开始就以正确的方式实施它）的痛苦要小得多。最终，它将带来更高质量和更安全的软件。
让我们分解一下：
解开“敏捷”的围裙带。
存在一种误解，认为组织必须在敏捷或DevOps之间做出选择，设定一条道路后就永远不能回头。
问题在于，当将二者视为整体来考量和实施时，开发过程才能发挥最佳效果。DevOps并非对敏捷开发的重塑；相反，它是敏捷开发的延伸。当人们期望这个过程发生变化时，往往会出现完全偏向敏捷或完全脱离敏捷的极端情况。
敏捷支持跨职能团队的理念，从项目伊始就将设计师、测试人员和开发人员聚集在一起，并承诺在整个项目中保持开放的沟通渠道。其目标是终结孤立交付并减少重复工作——这两点也是DevOps流程的优势所在。然而DevOps更进一步，将系统、安全和运维融入其中，以提供强大的端到端技能组合，其最终目标是向客户交付功能完备的软件。
在转向更以DevOps为中心的流程过程中，不可避免地会出现一些痛点，其中孤立开发的风险可能再次浮现。通常，最初的敏捷团队能够协同工作，而新增的安全和运维人员仍在计算机系统中寻找突破口；没有人能确定如何将他们纳入其中，他们应该承担什么职责，以及他们的总体目标是什么。
如果没有明确的目标、跨职能的入职以及与各方的直接沟通，DevOps 就无法运作。当然，会有一个调整期，需要仔细的变更管理，但让所有人对DevOps功能带来的增强达成共识，这已是成功的一半。
谢天谢地，DevOps也越来越重视安全最佳实践，将其作为流程的一部分，揭开这一步骤的神秘面纱，弥合安全团队与其他所有人之间的差距。正如我之前所说，从一开始就赋予开发人员安全编码的能力，我们还有很长的路要走，但DevOps方法的成功实施是开发团队内部培养安全技能的绝佳基础。
自动化并非万能（也并非最安全）。
在某种程度上，DevOps方法的另一特征是软件开发过程的自动化。持续集成与持续交付（CI/CD）原则是该理念的基石，正如你可能猜到的那样，它高度依赖工具。
工具确实很棒。它们能为软件交付过程带来前所未有的速度，并能相对无缝地管理代码仓库、测试、维护和存储等要素。
然而，尽管机器人终有一天可能夺走我们所有的工作并囚禁我们，但它们显然尚未做到。对工具和自动化的过度依赖为错误敞开了大门。扫描和测试可能无法检测到所有问题，代码可能未经审查，这会带来巨大的质量（更不用说安全性）问题。攻击者只需一个后门就能利用来窃取数据，而在质量和安全控制中放弃人为因素可能带来灾难性后果。
“平衡点”是确保人与人之间平衡的工具。工具应作为您信任团队的助手，以实现项目目标。您应该：
- 分配足够的时间让人们熟悉所选的 DevOps 工具链
- 专注于有效的协作（以及工具如何支持这种协作）
- 填补流程中的任何差距，无论这些差距是技能/知识还是基于工具的。
简而言之，不要只是“振作起来”，希望取得最好的结果。
DevOps 不是流行语，而是一种文化。你在成长吗？
即使在最顺利的时候，变更管理也充满挑战。对未知事物的恐惧甚至会阻碍最优秀的团队成员提升技能和拓展视野。
你看，仅仅说“让我们做DevOps”并让运维团队搬迁办公桌，并不能神奇地实现一个成功的流程。许多人会感到困惑，长期任职的团队成员将感到不满。期望的沟通至关重要，“走在路上”也是如此。DevOps既是一种开发方法，也是一种文化运动，团队应该以跨职能的协作思维来生活和呼吸。
优秀的DevOps文化是什么样子的？
- 个人有权为流程提供专业知识，而不仅仅是领导者。
- 团队之间开放、诚实和相互尊重的沟通
- 每个人都对将质量和安全纳入开发过程的总体目标负责。
- 对于企业中 DevOps 的定义、路线图以及每个人的角色如何/内容/原因，每个人都意见一致。
多年来，我一直强调在开发团队中建立积极的安全文化的重要性，DevOps 也不例外。
正确的工具、知识和支持对于实现安全最佳实践、减少已发现漏洞以及让团队认识到保护数据的重要性至关重要。借助 DevOps，你必须为积极变革奠定文化基础：确保每个人都了解自身角色、价值与期望、整体项目目标及流程步骤。
你掌握了吗？太棒了。现在，让我们转移注意力，提升安全性，让 DevSecOps 成为实现卓越软件的终极计划。
首席执行官、主席和联合创始人
Secure Code Warrior可帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全置于首位的文化。无论您是应用安全经理、开发人员、首席信息安全官还是任何与安全相关的人员，我们都能帮助您的组织降低与不安全代码相关的风险。
预约演示
首席执行官、主席和联合创始人
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA认证。
本文最初发表于 Devops.com。现已更新并修订。
就像“区块链”、“大数据”和“数字颠覆”一样，“DevOps”一词是大型组织IT部门目前流行的另一个流行语。
许多人已经（正确地）认识到需要更快的软件开发生命周期；一个与业务目标紧密关联的更精确流程，从而使开发团队和运维团队之间能够建立更清晰的工作流程与协作机制。DevOps 本质上是 敏捷开发，所有开发人员都成长起来，随时准备应对现代业务不断创新、快速部署的需求。对于安全专业人员而言，这是一项了不起的举措：我们可以更早地为流程注入安全性，从而降低修复错误的成本并避免潜在的灾难。
问题在于，很少有公司能真正成功实施DevOps。如果没有整个企业的适当支持、培育和理解，它很快就会变成一头白象……你知道的，就是那些"别提战争"的项目之一。
那么，问题是什么？这是一个有趣的讨论，我相信有几种方法可以实现DevOps，这将使航行变得更加顺利。有效的计划不仅仅是一些花哨的新工具、头衔和团队会议。这并不总是那么容易，但从长远来看，花时间修复一个失效的策略（或从一开始就以正确的方式实施它）的痛苦要小得多。最终，它将带来更高质量和更安全的软件。
让我们分解一下：
解开“敏捷”的围裙带。
存在一种误解，认为组织必须在敏捷或DevOps之间做出选择，设定一条道路后就永远不能回头。
问题在于，当将二者视为整体来考量和实施时，开发过程才能发挥最佳效果。DevOps并非对敏捷开发的重塑；相反，它是敏捷开发的延伸。当人们期望这个过程发生变化时，往往会出现完全偏向敏捷或完全脱离敏捷的极端情况。
敏捷支持跨职能团队的理念，从项目伊始就将设计师、测试人员和开发人员聚集在一起，并承诺在整个项目中保持开放的沟通渠道。其目标是终结孤立交付并减少重复工作——这两点也是DevOps流程的优势所在。然而DevOps更进一步，将系统、安全和运维融入其中，以提供强大的端到端技能组合，其最终目标是向客户交付功能完备的软件。
在转向更以DevOps为中心的流程过程中，不可避免地会出现一些痛点，其中孤立开发的风险可能再次浮现。通常，最初的敏捷团队能够协同工作，而新增的安全和运维人员仍在计算机系统中寻找突破口；没有人能确定如何将他们纳入其中，他们应该承担什么职责，以及他们的总体目标是什么。
如果没有明确的目标、跨职能的入职以及与各方的直接沟通，DevOps 就无法运作。当然，会有一个调整期，需要仔细的变更管理，但让所有人对DevOps功能带来的增强达成共识，这已是成功的一半。
谢天谢地，DevOps也越来越重视安全最佳实践，将其作为流程的一部分，揭开这一步骤的神秘面纱，弥合安全团队与其他所有人之间的差距。正如我之前所说，从一开始就赋予开发人员安全编码的能力，我们还有很长的路要走，但DevOps方法的成功实施是开发团队内部培养安全技能的绝佳基础。
自动化并非万能（也并非最安全）。
在某种程度上，DevOps方法的另一特征是软件开发过程的自动化。持续集成与持续交付（CI/CD）原则是该理念的基石，正如你可能猜到的那样，它高度依赖工具。
工具确实很棒。它们能为软件交付过程带来前所未有的速度，并能相对无缝地管理代码仓库、测试、维护和存储等要素。
然而，尽管机器人终有一天可能夺走我们所有的工作并囚禁我们，但它们显然尚未做到。对工具和自动化的过度依赖为错误敞开了大门。扫描和测试可能无法检测到所有问题，代码可能未经审查，这会带来巨大的质量（更不用说安全性）问题。攻击者只需一个后门就能利用来窃取数据，而在质量和安全控制中放弃人为因素可能带来灾难性后果。
“平衡点”是确保人与人之间平衡的工具。工具应作为您信任团队的助手，以实现项目目标。您应该：
- 分配足够的时间让人们熟悉所选的 DevOps 工具链
- 专注于有效的协作（以及工具如何支持这种协作）
- 填补流程中的任何差距，无论这些差距是技能/知识还是基于工具的。
简而言之，不要只是“振作起来”，希望取得最好的结果。
DevOps 不是流行语，而是一种文化。你在成长吗？
即使在最顺利的时候，变更管理也充满挑战。对未知事物的恐惧甚至会阻碍最优秀的团队成员提升技能和拓展视野。
你看，仅仅说“让我们做DevOps”并让运维团队搬迁办公桌，并不能神奇地实现一个成功的流程。许多人会感到困惑，长期任职的团队成员将感到不满。期望的沟通至关重要，“走在路上”也是如此。DevOps既是一种开发方法，也是一种文化运动，团队应该以跨职能的协作思维来生活和呼吸。
优秀的DevOps文化是什么样子的？
- 个人有权为流程提供专业知识，而不仅仅是领导者。
- 团队之间开放、诚实和相互尊重的沟通
- 每个人都对将质量和安全纳入开发过程的总体目标负责。
- 对于企业中 DevOps 的定义、路线图以及每个人的角色如何/内容/原因，每个人都意见一致。
多年来，我一直强调在开发团队中建立积极的安全文化的重要性，DevOps 也不例外。
正确的工具、知识和支持对于实现安全最佳实践、减少已发现漏洞以及让团队认识到保护数据的重要性至关重要。借助 DevOps，你必须为积极变革奠定文化基础：确保每个人都了解自身角色、价值与期望、整体项目目标及流程步骤。
你掌握了吗？太棒了。现在，让我们转移注意力，提升安全性，让 DevSecOps 成为实现卓越软件的终极计划。
本文最初发表于 Devops.com。现已更新并修订。
就像“区块链”、“大数据”和“数字颠覆”一样，“DevOps”一词是大型组织IT部门目前流行的另一个流行语。
许多人已经（正确地）认识到需要更快的软件开发生命周期；一个与业务目标紧密关联的更精确流程，从而使开发团队和运维团队之间能够建立更清晰的工作流程与协作机制。DevOps 本质上是 敏捷开发，所有开发人员都成长起来，随时准备应对现代业务不断创新、快速部署的需求。对于安全专业人员而言，这是一项了不起的举措：我们可以更早地为流程注入安全性，从而降低修复错误的成本并避免潜在的灾难。
问题在于，很少有公司能真正成功实施DevOps。如果没有整个企业的适当支持、培育和理解，它很快就会变成一头白象……你知道的，就是那些"别提战争"的项目之一。
那么，问题是什么？这是一个有趣的讨论，我相信有几种方法可以实现DevOps，这将使航行变得更加顺利。有效的计划不仅仅是一些花哨的新工具、头衔和团队会议。这并不总是那么容易，但从长远来看，花时间修复一个失效的策略（或从一开始就以正确的方式实施它）的痛苦要小得多。最终，它将带来更高质量和更安全的软件。
让我们分解一下：
解开“敏捷”的围裙带。
存在一种误解，认为组织必须在敏捷或DevOps之间做出选择，设定一条道路后就永远不能回头。
问题在于，当将二者视为整体来考量和实施时，开发过程才能发挥最佳效果。DevOps并非对敏捷开发的重塑；相反，它是敏捷开发的延伸。当人们期望这个过程发生变化时，往往会出现完全偏向敏捷或完全脱离敏捷的极端情况。
敏捷支持跨职能团队的理念，从项目伊始就将设计师、测试人员和开发人员聚集在一起，并承诺在整个项目中保持开放的沟通渠道。其目标是终结孤立交付并减少重复工作——这两点也是DevOps流程的优势所在。然而DevOps更进一步，将系统、安全和运维融入其中，以提供强大的端到端技能组合，其最终目标是向客户交付功能完备的软件。
在转向更以DevOps为中心的流程过程中，不可避免地会出现一些痛点，其中孤立开发的风险可能再次浮现。通常，最初的敏捷团队能够协同工作，而新增的安全和运维人员仍在计算机系统中寻找突破口；没有人能确定如何将他们纳入其中，他们应该承担什么职责，以及他们的总体目标是什么。
如果没有明确的目标、跨职能的入职以及与各方的直接沟通，DevOps 就无法运作。当然，会有一个调整期，需要仔细的变更管理，但让所有人对DevOps功能带来的增强达成共识，这已是成功的一半。
谢天谢地，DevOps也越来越重视安全最佳实践，将其作为流程的一部分，揭开这一步骤的神秘面纱，弥合安全团队与其他所有人之间的差距。正如我之前所说，从一开始就赋予开发人员安全编码的能力，我们还有很长的路要走，但DevOps方法的成功实施是开发团队内部培养安全技能的绝佳基础。
自动化并非万能（也并非最安全）。
在某种程度上，DevOps方法的另一特征是软件开发过程的自动化。持续集成与持续交付（CI/CD）原则是该理念的基石，正如你可能猜到的那样，它高度依赖工具。
工具确实很棒。它们能为软件交付过程带来前所未有的速度，并能相对无缝地管理代码仓库、测试、维护和存储等要素。
然而，尽管机器人终有一天可能夺走我们所有的工作并囚禁我们，但它们显然尚未做到。对工具和自动化的过度依赖为错误敞开了大门。扫描和测试可能无法检测到所有问题，代码可能未经审查，这会带来巨大的质量（更不用说安全性）问题。攻击者只需一个后门就能利用来窃取数据，而在质量和安全控制中放弃人为因素可能带来灾难性后果。
“平衡点”是确保人与人之间平衡的工具。工具应作为您信任团队的助手，以实现项目目标。您应该：
- 分配足够的时间让人们熟悉所选的 DevOps 工具链
- 专注于有效的协作（以及工具如何支持这种协作）
- 填补流程中的任何差距，无论这些差距是技能/知识还是基于工具的。
简而言之，不要只是“振作起来”，希望取得最好的结果。
DevOps 不是流行语，而是一种文化。你在成长吗？
即使在最顺利的时候，变更管理也充满挑战。对未知事物的恐惧甚至会阻碍最优秀的团队成员提升技能和拓展视野。
你看，仅仅说“让我们做DevOps”并让运维团队搬迁办公桌，并不能神奇地实现一个成功的流程。许多人会感到困惑，长期任职的团队成员将感到不满。期望的沟通至关重要，“走在路上”也是如此。DevOps既是一种开发方法，也是一种文化运动，团队应该以跨职能的协作思维来生活和呼吸。
优秀的DevOps文化是什么样子的？
- 个人有权为流程提供专业知识，而不仅仅是领导者。
- 团队之间开放、诚实和相互尊重的沟通
- 每个人都对将质量和安全纳入开发过程的总体目标负责。
- 对于企业中 DevOps 的定义、路线图以及每个人的角色如何/内容/原因，每个人都意见一致。
多年来，我一直强调在开发团队中建立积极的安全文化的重要性，DevOps 也不例外。
正确的工具、知识和支持对于实现安全最佳实践、减少已发现漏洞以及让团队认识到保护数据的重要性至关重要。借助 DevOps，你必须为积极变革奠定文化基础：确保每个人都了解自身角色、价值与期望、整体项目目标及流程步骤。
你掌握了吗？太棒了。现在，让我们转移注意力，提升安全性，让 DevSecOps 成为实现卓越软件的终极计划。
点击下面的链接并下载此资源的PDF。
Secure Code Warrior可帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全置于首位的文化。无论您是应用安全经理、开发人员、首席信息安全官还是任何与安全相关的人员，我们都能帮助您的组织降低与不安全代码相关的风险。
查看报告预约演示
首席执行官、主席和联合创始人
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA认证。
本文最初发表于 Devops.com。现已更新并修订。
就像“区块链”、“大数据”和“数字颠覆”一样，“DevOps”一词是大型组织IT部门目前流行的另一个流行语。
许多人已经（正确地）认识到需要更快的软件开发生命周期；一个与业务目标紧密关联的更精确流程，从而使开发团队和运维团队之间能够建立更清晰的工作流程与协作机制。DevOps 本质上是 敏捷开发，所有开发人员都成长起来，随时准备应对现代业务不断创新、快速部署的需求。对于安全专业人员而言，这是一项了不起的举措：我们可以更早地为流程注入安全性，从而降低修复错误的成本并避免潜在的灾难。
问题在于，很少有公司能真正成功实施DevOps。如果没有整个企业的适当支持、培育和理解，它很快就会变成一头白象……你知道的，就是那些"别提战争"的项目之一。
那么，问题是什么？这是一个有趣的讨论，我相信有几种方法可以实现DevOps，这将使航行变得更加顺利。有效的计划不仅仅是一些花哨的新工具、头衔和团队会议。这并不总是那么容易，但从长远来看，花时间修复一个失效的策略（或从一开始就以正确的方式实施它）的痛苦要小得多。最终，它将带来更高质量和更安全的软件。
让我们分解一下：
解开“敏捷”的围裙带。
存在一种误解，认为组织必须在敏捷或DevOps之间做出选择，设定一条道路后就永远不能回头。
问题在于，当将二者视为整体来考量和实施时，开发过程才能发挥最佳效果。DevOps并非对敏捷开发的重塑；相反，它是敏捷开发的延伸。当人们期望这个过程发生变化时，往往会出现完全偏向敏捷或完全脱离敏捷的极端情况。
敏捷支持跨职能团队的理念，从项目伊始就将设计师、测试人员和开发人员聚集在一起，并承诺在整个项目中保持开放的沟通渠道。其目标是终结孤立交付并减少重复工作——这两点也是DevOps流程的优势所在。然而DevOps更进一步，将系统、安全和运维融入其中，以提供强大的端到端技能组合，其最终目标是向客户交付功能完备的软件。
在转向更以DevOps为中心的流程过程中，不可避免地会出现一些痛点，其中孤立开发的风险可能再次浮现。通常，最初的敏捷团队能够协同工作，而新增的安全和运维人员仍在计算机系统中寻找突破口；没有人能确定如何将他们纳入其中，他们应该承担什么职责，以及他们的总体目标是什么。
如果没有明确的目标、跨职能的入职以及与各方的直接沟通，DevOps 就无法运作。当然，会有一个调整期，需要仔细的变更管理，但让所有人对DevOps功能带来的增强达成共识，这已是成功的一半。
谢天谢地，DevOps也越来越重视安全最佳实践，将其作为流程的一部分，揭开这一步骤的神秘面纱，弥合安全团队与其他所有人之间的差距。正如我之前所说，从一开始就赋予开发人员安全编码的能力，我们还有很长的路要走，但DevOps方法的成功实施是开发团队内部培养安全技能的绝佳基础。
自动化并非万能（也并非最安全）。
在某种程度上，DevOps方法的另一特征是软件开发过程的自动化。持续集成与持续交付（CI/CD）原则是该理念的基石，正如你可能猜到的那样，它高度依赖工具。
工具确实很棒。它们能为软件交付过程带来前所未有的速度，并能相对无缝地管理代码仓库、测试、维护和存储等要素。
然而，尽管机器人终有一天可能夺走我们所有的工作并囚禁我们，但它们显然尚未做到。对工具和自动化的过度依赖为错误敞开了大门。扫描和测试可能无法检测到所有问题，代码可能未经审查，这会带来巨大的质量（更不用说安全性）问题。攻击者只需一个后门就能利用来窃取数据，而在质量和安全控制中放弃人为因素可能带来灾难性后果。
“平衡点”是确保人与人之间平衡的工具。工具应作为您信任团队的助手，以实现项目目标。您应该：
- 分配足够的时间让人们熟悉所选的 DevOps 工具链
- 专注于有效的协作（以及工具如何支持这种协作）
- 填补流程中的任何差距，无论这些差距是技能/知识还是基于工具的。
简而言之，不要只是“振作起来”，希望取得最好的结果。
DevOps 不是流行语，而是一种文化。你在成长吗？
即使在最顺利的时候，变更管理也充满挑战。对未知事物的恐惧甚至会阻碍最优秀的团队成员提升技能和拓展视野。
你看，仅仅说“让我们做DevOps”并让运维团队搬迁办公桌，并不能神奇地实现一个成功的流程。许多人会感到困惑，长期任职的团队成员将感到不满。期望的沟通至关重要，“走在路上”也是如此。DevOps既是一种开发方法，也是一种文化运动，团队应该以跨职能的协作思维来生活和呼吸。
优秀的DevOps文化是什么样子的？
- 个人有权为流程提供专业知识，而不仅仅是领导者。
- 团队之间开放、诚实和相互尊重的沟通
- 每个人都对将质量和安全纳入开发过程的总体目标负责。
- 对于企业中 DevOps 的定义、路线图以及每个人的角色如何/内容/原因，每个人都意见一致。
多年来，我一直强调在开发团队中建立积极的安全文化的重要性，DevOps 也不例外。
正确的工具、知识和支持对于实现安全最佳实践、减少已发现漏洞以及让团队认识到保护数据的重要性至关重要。借助 DevOps，你必须为积极变革奠定文化基础：确保每个人都了解自身角色、价值与期望、整体项目目标及流程步骤。
你掌握了吗？太棒了。现在，让我们转移注意力，提升安全性，让 DevSecOps 成为实现卓越软件的终极计划。
%20(1).avif)
.avif)
