开发、运维、安全和质量保证之间的壁垒阻碍了软件开发，但这些壁垒并非不可避免。了解如何拆除这些障碍
译自 Breaking Down the Wall in DevOps，作者 Laura Santamaria 是 Dell Technologies 的首席开发者倡导者，她喜欢学习和解释事物的工作原理，以弥合工程学科之间的差距。 她是 Cloud Native Compass 播客的共同主持人，并且是... 的策展人
墙。
这句话经常用来描述 DevOps 世界里阻碍团队协作的那堵隐形的墙。比如，你可以说开发团队会“把代码扔过墙”给运维团队。这堵墙在心理和情感上成为通往理想乌托邦的障碍，那里开发、运维、安全和质量保证 (QA) 团队全都手牵手，在一片花丛中欢快地跳舞，准备携手解决每一个问题。
但这道障碍到底是什么呢？既然我们知道它存在，为什么我们就是不能让这堵墙消失呢？不管有多少人说 DevOps 已经过时(或者陈旧或废弃)同时试图引诱你去关注最新的、最闪亮的事物，这堵墙仍然存在。这道屏障可能在组织内部会移动——毕竟，每个开发人员似乎都想拥有一个平台(这是讽刺意味)——但它总是存在的，即使基础设施的责任会下移。
在现代组织中，这堵墙代表了所有权的障碍，是团队在此会面并交接对产品某部分责任的转移点。仅仅让开发人员成为基础设施的所有者，就像许多人最初在团队迁移到大规模服务提供商时所尝试的那样，只是改变了墙的位置。这道屏障仍然存在并且仍然是一个问题。
在任何这些转变点，都可能发现冲突。从运维团队对复杂依赖关系提出质疑，到开发团队要求其他人将他们的项目视为黄金典范，无论你怎样尝试移动这堵墙，在交接的时刻都会产生冲突。一些组织会将所有人放在同一个团队，但责任的交接仍然存在。让一个人从头到尾全权负责也并不那么简单，因为那个所有者会根据不同人的专长，在流程的不同步骤中把责任分配给不同的人。
这些转变点也代表着测量标准的改变。开发以发布了多少新功能来衡量。运维以获得或维持了多少正常运行时间来衡量。安全性以有多少系统没有被入侵来衡量。QA 以客户反馈中出现的 bug 数量少来衡量。
从高层来看，管理层对这堵墙的存在可能感到困惑；毕竟，我们都只是想要保持公司正常运转和客户满意，不是吗？然而，当一个开发人员通过这堵墙把错误传递给运维团队时，运维团队的正常运行时间就会下降。当运维团队决定再推迟一周更新操作系统来维持稳定性时，安全团队对遭到入侵的担忧就会增加。当一个人的工作可能会受到别人选择的威胁时，他们根本无法接受更加宽广的视角。相反，本能反应是通过满足他们的考核指标来保护自己。因此，这堵墙依然存在。
如果你想在一个组织中推动变革，你可以尝试使用工具来克服这堵墙，并带来文化转型。或者，你可以先尝试通过调整所有权的分配来改变文化，然后再选择工具。组织转型就是为了给组织带来根本性的改变以取得改进。所以文化组织转型就是给组织文化带来根本性的改变，这不一定就是给组织带来改进的文化本身的根本性改变。因此，推倒这堵墙的初步步骤之一可能是调整公司的考核体系，让所有人从同一起点开始，最后达到同样的目标。这种测量标准的根本性改变可以通过让人们关心其他团队的结果来改善文化。
从更实际的角度来看，真正消除这堵墙并不意味着摒弃所有权——没有所有者的项目这个想法本身就非常荒谬——或者让一个人从头到尾全权负责某个事物。它也不意味着隔离你系统的各个层面让它们永远由一个团队所有。真正消除这堵墙就是让所有权的转移更加无缝和不那么冲突。
我们常被告知，一个健康的组织应该非常重视强有力的沟通和心理安全感(以及其他一些事情)。你可以做一些关键的事情来减少冲突：在软件开发生命周期(SDLC)开始时使用共同语言，这样在交接时就不会有意外。通过足够快的调整幅度做出足够小的变更，使错误的影响很轻微且暂时的，这样可以降低问题的严重性。快速解决技术债务，避免任何团队因为必须一直维护一些永远无法修复的东西而过载。
这就是 DevOps 的真正目标。DevOps 的目标不是依靠更多工具来扩展这堵墙。相反，目标是侵蚀它，将其减少到你可以轻松跨越它的程度，同时分担所有权的负担——就像携手将野餐篮子一起拿到隔壁田野里一样。