为什么企业 DevOps 实践总是失败?

2019 年 8 月 27 日

为什么企业 DevOps 实践总是失败?

与“区块链”和“大数据”相似,“DevOps”这个术语目前是大型组织IT部门中的另一个流行语。


很人已经认识到需要更快的软件开发生命周期;需要符合业务目标的更精确的过程,以及允许开发团队和运营团队之间更清晰的工作流和协作。DevOps 本质上是敏捷的、成熟的,并随时准备接受不断创新和快速部署的现代业务需求。


对于安全专业人员来说,这是一个非常好的创新方案:我们可以更早地将安全性注入到过程中,从而降低 bug 修复成本,并能避免潜在的故障。


问题是,很少有公司能够真正成功地实现 DevOps。如果没有在企业范围内提供恰当的支持、培训并获得理解,它很快就会变成一个“累赘”。


那么,实践 DevOps 的问题在哪里呢?目前 DevOps 的实践方案有好几种,但是一个有效的方案不仅仅是花哨的新工具、标题和团队会议,DevOps 并不是一件容易的事情,从长远来看,花时间来修复一个有问题的策略(或者从一开始就以正确的方式来实施它),就会减少一点痛苦。最终,它将带来质量更高也更安全的软件。


挣脱敏捷的束缚


有一种误解认为,一个组织必须在敏捷或 DevOps 之间二选一,选择一条路径,一条路走到黑。


但事实上,如果我们同时考虑两者,并将两者作为一个整体实现时,开发过程会达得最好效果。DevOps 不是敏捷开发的一个再造,而是它的一个扩展。如果期望过程完全是敏捷开发,或者完全不是敏捷开发,往往会把事情搞砸了。


敏捷开发支持跨职能团队的原则,它从一开始就将设计人员、测试人员和开发人员聚集在一起,并致力于在整个项目过程中打开沟通通道。它的目标是禁止孤立的交付并减少双重处理,这两者也是 DevOps 过程中的优势。然而,DevOps 更进一步,它将系统、安全性和操作也引入其中,以提供一个健壮的、端到端的技能集,最终目标是向客户交付完整的、功能强大的软件。


在转向更多以 DevOps 为中心的过程中,一个不可避免的痛点是孤立开发的风险可能会再次出现。通常,我们可以让最初的敏捷团队在一起工作,额外添加安全性和操作,但是这样做的难点是没有人非常确定该怎样引入它们,引入它们应该做什么以及它们的总体目标是什么。


如果没有明确的目标、跨职能的管理和与各方的直接沟通,DevOps 就无法工作,企业需要给一段适应期,需要谨慎的变更管理,如果所有团队成员都深刻理解了 DevOps,那就成功了一半。


DevOps 越来越重视将安全最佳实践作为过程的一部分,它揭开了该步骤的神秘面纱,并弥合了安全团队与其他人之间的差距。如前所述,让开发人员从一开始就能够安全地进行编码, 我们仍然还有很长的路要走,但是 DevOps 方法论的成功实施是在开发团队中构建安全技能的良好基础。


自动化不是万能的,也不是最安全的


DevOps 方法论的另一个特点是,它在一定程度上实现了软件开发过程的自动化。这个概念的基石是持续集成和持续交付(CI/CD)原则,正如你所想的那样,它们非常依赖于工具。


工具确实很棒。它们可以为软件交付过程带来前所未有的速度,且能以相对无缝的方式轻松地管理代码库、测试、运维和存储等。


然而,尽管有一天机器人可能会抢走我们所有的工作,并禁锢我们,当然现在这种情况肯定还没有出现,但是对工具和自动化的严重依赖,可能会在未来为这种情况埋下祸根。扫描和测试可能无法发现所有的问题,代码可能未检查,这会带来巨大的质量问题,更不用说过程中的安全性问题了。攻击者只需要一个后门就可以利用它来窃取数据,在质量和安全控制中放弃人为操作可能会造成灾难性的后果。


折衷的办法是确保人和工具的平衡。工具应该作为值得我们团队信任的助手,帮忙我们实现项目目标。我们应该做到如下几点:


  • 分配足够的时间来让大家熟悉所选择的DevOps工具链。

  • 专注于有效的协作(以及工具是如何支持协作的)。

  • 处理过程中的任何隔阂,无论它们是基于技能/知识的还是基于工具的。


简而言之,不要只依赖工具并做最好的打算。


DevOps 不是一个流行语,是一种文化


即使是在最理想的情况下,变更管理也是困难的。对未知的恐惧甚至可以阻止最优秀的团队成员提高他们的技能和扩展他们的视野。


仅仅喊口号“我们在做 DevOps”,或者是移动运营团队的办公地点,并不能真正实现成功的开发过程,同时也会让很多人感到困惑,甚至是不满。DevOps 不仅是一种开发方法论,也是一种文化运动,一个团队应该有跨职能协作的心态。


一种伟大的 DevOps 文化是什么样子的呢?


  • 授权个人在开发过程中运用他们的专业知识,而不是仅授权领导者。

  • 团队之间建立开放、诚实、相互尊重的沟通机制。

  • 在开发过程中,每个人都要对实现开发过程中构建质量和安全性的总体目标负责。

  • 每个人应该对业务中DevOps的定义、路线图以及每个人角色的方式/内容/原因都有相同的理解。


多年以来,我一直强调在开发团队中构建积极的安全文化的重要性,DevOps 也不例外。


正确的工具、知识及支持对于实现安全最佳实践是至关重要的,我们可以看到发现的漏洞正在减少,并且团队开始认识到保护数据的重要性。对于 DevOps,我们必须积极地为变革奠定文化基础:确保每个人都了解自己的角色、价值和期望、以及开发过程中的整个项目目标和步骤。


原文链接:


https://devops.com/why-devops-implementation-is-often-unsuccessful-and-how-to-fix-it/


2019 年 8 月 27 日 09:474828
用户头像

发布了 126 篇内容, 共 51.7 次阅读, 收获喜欢 315 次。

关注

评论

发布
暂无评论
发现更多内容

云服务的可服务性经典6问

华为云开发者社区

服务 计算

图解HTTP权威指南(一)| HTTP报文

李先生

运维 HTTP

比特币10年:从2个披萨涨到2万美金,背后的三个“神秘人”

CECBC区块链专委会

比特币

Reactive Spring实战 -- 理解Reactor的设计与实现

binecy

reactor Reactive SpringBoot 2

脑洞:如何用一个整数来表示一个列表?

Python猫

Python

倍频程与钢琴调式的距离

阿里云视频云

音频技术 音频

PostgreSQL:您可能需要增加MAX_LOCKS_PER_TRANSACTION

PostgreSQLChina

数据库 postgresql 开源

LeetCode题解:55. 跳跃游戏,贪心,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

量化交易系统开发搭建案例

薇電13242772558

区块链 策略模式

TypeScript | 第二章:类、接口和之间的关系

梁龙先森

typescript 前端 七日更

“区块链+社会治理”模式获居民点赞

CECBC区块链专委会

区块链 区块链投票

大连市税务局局长赵福增:用区块链打破部门间“信息孤岛”

CECBC区块链专委会

区块链 汽车

大作业1

追风

架构师一期

【Java入门】流

HQ数字卡

Java 七日更

GitHub上3天1W赞的程序员学习路线!入门进阶都非常实用

Java架构之路

Java 程序员 架构 面试 编程语言

OPPO小布助手正在改变普罗米修斯的世界

脑极体

大众汽车“芯片荒”,折射汽车芯片的漫漫“自主替代”路

脑极体

Redis实战丨阿里架构师耗时三年写出的Redis实战文档PDF

Java成神之路

Java 程序员 架构 面试 编程语言

13W字!腾讯高工手写“Netty速成手册”,3天能走向实战

周老师

Java 编程 程序员 架构 面试

由于不知线程池的bug,某Java程序员叕被祭天

Java架构师迁哥

2020,谁是中国ToB行业最有影响力的企业?

ToB行业头条

架构师训练营W10作业

Geek_f06ede

测开之函数进阶· 第2篇《纯函数》

清菡

测试开发

阿里开发10年,全部心血汇聚成到这份文档里,拿到30W的offer没问题

Java架构之路

Java 程序员 架构 面试 编程语言

阿里架构师478页Java工程师面试知识解析笔记pdf,一份2021年通往阿里的面试指南

Java架构之路

Java 程序员 架构 面试 编程语言

学透这份300页的2020最新java面试题及答案,一线大厂offer随便拿

Java架构之路

Java 程序员 架构 面试 编程语言

英特尔宋继强:迈向可持续的千倍速计算未来

intel001

距离 Java 开发者玩转 Serverless,到底还有多远?

阿里巴巴云原生

Java Serverless 微服务 云原生 中间件

volatile,synchronized可见性,有序性,原子性代码证明(基础硬核)

叫练

volatile 多线程 synchronized 原子性 指令

神比喻:低代码开发像自动驾驶汽车,零代码开发像无人驾驶汽车!

低代码指南

程序员 软件 开发者 低代码 开发工具

MSHA x Chaos 容灾高可用实践

阿里巴巴云原生

数据库 高可用 云原生 中间件 容灾

为什么企业 DevOps 实践总是失败?-InfoQ