醒醒吧，开发运维（DevOps）工程师是一种视觉假象！

Posted 2021-04-16 云头条

IT专业人员和开发人员不可能十八般武艺样样精通。相反，提倡专业化、鼓励贵企业组织加强合作，才能在开发运维（DevOps）方面取得实质性、持续性的进展。

如今，打造一支通力合作、行动快速的开发运维部门是一项复杂但又很关键的任务。科技行业充斥着一大堆最佳实践，它们承诺可以帮助许多公司实现这个目标。其中一些建议有很大的意义。但是许多建议导致结果很平庸，而企业组织在开发运维方面绝不能凑合着就行。

我从事开发运维已有一段时日了，作为一名技术团队领导人，我发现，提倡专业化、在几乎任何企业组织鼓励合作，才能在开发运维方面取得实质性、持续性的进展。

这年头大家都在热议：开发人员需要成为全栈通才（full-stack generalists），拥有从前端开发到后端开发的各项专长。这实在很可笑。很少有几个人在每个方面都足够优秀，因而能做到全方位创新。

相反，企业组织应该提倡专业化。这倒不是指遏制最尖端发展机会的专业化，而是指一大批技能娴熟的人员齐聚一堂，为企业组织共同提供推动开发运维项目成功所需要的一切资源。

关键在于把专家们聚集起来，他们不光能够理解客户价值这个最终目标，还能够理解各自在实现这个目标过程中扮演的角色。这就意味着，要了解从提出想法到客户针对运行中的系统给予反馈的整个环节。他们需要擅长各自从事的工作，但是又清楚地了解对方，并体现出相互体谅、欣赏和合作的精神。

不仅仅针对技术界

结合这种罕见但很重要的专业化和合作才是许多行业确保成功的秘诀。当说唱组合Run-D.M.C.和空中铁匠乐队（Aerosmith）决定合作、重新制作《Walk this Way》这首歌时，Run-D.M.C.没必要成为摇滚乐队，空中铁匠乐队也没必要成为饶舌组合。相反，他们彼此坚持各自的专长，又深入了解对方，因而彼此得以精诚合作，取得单枪匹马无法取得的成绩。

我在科技行业也时不时见到这一幕。

在我职业生涯的早期阶段，我供职于CustomInk，这是一家网上服装公司。一个不知名的程序错误不断地把我们的服务器弄得一团糟，迫使我们在每周一重新配置系统，或者将系统推倒重来。这浪费了大量的时间，而且这个过程让我们无法有效地扩展系统。

幸好，我们的团队中有一名才华横溢的系统管理员，他发现这个错误其实是内存泄漏。要是我们的团队中没有这项专门的技能，我们就查不出这个问题的根源。此外，我们还有一位开发人员，他拥有修复代码的技能。当然，系统管理员不得不与这位开发人员通力合作，拿出修复方案。借助专业化和合作，我们消除了一大痛点，然后重新开发功能特性。

我见到一再上演的一个更普通的例子是，当开发人员对数据库管理员表示反感时。从我的角度来看，这种厌恶常常搞错了对象；换句话说，开发人员不该厌恶数据库管理员。不是所有的代码都是优秀的代码。一名厉害的数据库管理员可以帮助开发人员确定应用程序代码的　结构，从而确保性能最佳。另外，通过彼此合作，他们各自的专业化技能相辅相成，让整个团队更强大，因而开发出最好的应用程序。

远离全栈通才

你具体该如何同时鼓励专业化和合作呢？一种方法就是岗位轮换培训。以开发团队为例，让他们花些时间在销售、支持和客户服务上，看看他们开发的软件在如何影响客户。他们吸取的经验教训不仅会有益于本职工作，还有助于了解他们的工作如何推动业务发展。

我带领我的CustomInk团队参观了手工工艺品电商平台Etsy，那样我们就能了解我们公司外面的人在如何对待开发和运维。我们参观完后离开时有所启示，因而敢于大胆尝新。

至于塔吉特百货公司（Target），它开发出了The Dojo（http://target.github.io/devops/the-dojo），这套方法用来增强新的技术实力，可以把来自整个公司的人员聚集起来。不仅可以学到新的实践和新的工作流程，还可以学到搞项目管理的新方法。在The Dojo中完成项目后，人们回到公司里各自的部门，但掌握了更丰富的知识，并受到新型工作方法的启示。

光专业化还不够

我的经历表明，如果专业化没有与合作协同起来，企业几乎不可能获得所需的那种速度。你必须消除阻止中层从业人员为公司搭建桥梁的一个个孤岛。

开发人员与运维人员不一样。财务分析员不是工程师，销售员不是会计师。透明的沟通、能够稳妥地失败以及促进跨团队协作的一种体系，这些将把每个人召集起来，共同支持最终的结果：确保客户满意。

如果充分利用贵企业组织的专业化技能组合和融洽感情，并将它们充分融合起来，就能获得出色的开发运维能力，并长期保持下去。

相关阅读：