
为什么DevOps实施常常失败(以及如何解决)
本文最初发表于 DevOps.com。现已更新并修订。
与"区块链"、"大数据"和"数字颠覆"类似,"DevOps"一词是当前大型企业IT部门中另一个流行的术语。
许多人(正确地)认识到加速软件开发生命周期的必要性——一个更精确、与商业目标紧密对齐的流程,能够实现更清晰的工作流,并促进开发与运维团队之间的协作。DevOps本质上是一种"敏捷"开发模式,它经过精心设计,能够满足现代企业对持续创新和快速部署的需求。 对安全专业人员而言,这堪称绝佳举措:我们能将安全防护更早地融入流程,从而降低漏洞修复成本,并避免开发过程中可能发生的灾难性后果。
问题在于,真正成功实施DevOps的企业寥寥无几。若缺乏企业内部的充分支持、激励与理解,它很快就会沦为白象项目——就是那种"别提战争"的项目。
那么问题出在哪里?这是一场值得探讨的讨论,而我认为存在多种方式来推进DevOps实践,这些方法将有助于顺利推进。 有效的DevOps实践绝非仅靠添置新工具、设立花哨头衔或召开团队会议就能实现。这个过程未必轻松,但花时间修正失败的策略(或从一开始就正确实施),长远来看会省去更多麻烦。最终,这将转化为更高质量、更安全的软件产品。
让我们来分解它:
松开"敏捷"围裙的系带。
存在一种误解,认为组织必须在敏捷(Agile)与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实践绝非仅靠添置新工具、设立花哨头衔或召开团队会议就能实现。这个过程未必轻松,但花时间修正失败的策略(或从一开始就正确实施),长远来看会省去更多麻烦。最终,这将转化为更高质量、更安全的软件产品。
让我们来分解它:
松开"敏捷"围裙的系带。
存在一种误解,认为组织必须在敏捷(Agile)与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实践绝非仅靠添置新工具、设立花哨头衔或召开团队会议就能实现。这个过程未必轻松,但花时间修正失败的策略(或从一开始就正确实施),长远来看会省去更多麻烦。最终,这将转化为更高质量、更安全的软件产品。
让我们来分解它:
松开"敏捷"围裙的系带。
存在一种误解,认为组织必须在敏捷(Agile)与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实践绝非仅靠添置新工具、设立花哨头衔或召开团队会议就能实现。这个过程未必轻松,但花时间修正失败的策略(或从一开始就正确实施),长远来看会省去更多麻烦。最终,这将转化为更高质量、更安全的软件产品。
让我们来分解它:
松开"敏捷"围裙的系带。
存在一种误解,认为组织必须在敏捷(Agile)与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)
