为什么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成为卓越软件的终极计划。
皮特-丹休
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA认证。
在博客上深入了解我们最新的安全编码见解。
我们广泛的资源库旨在增强人类对安全编码技术提升的方法。
获取关于开发者驱动的安全的最新研究
我们广泛的资源库充满了有用的资源，从白皮书到网络研讨会，让你开始使用开发者驱动的安全编码。现在就去探索它。
为什么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成为卓越软件的终极计划。
