您的 DevOps 尝试将会失败,如果缺少这 7 个部门的支持

实现客户价值不仅仅需要软件开发和 IT 运维。
263 位读者喜欢这篇文章。
Remote people connected on clouds

Opensource.com

当 Andrew Shafer 和 Patrick Debois 提出 DevOps 的概念时,目标是拉近开发人员和运维人员的距离,共同实现客户价值。DevOps 是一种持续学习和改进的文化。虽然自动化和工具可以带来一些改进,但拥有正确的文化才能产生更大的影响。知识和想法的共享所带来的文化增长是 DevOps 的价值创造所在。

开发和运维之间的巨大鸿沟

在许多公司中,开发人员和运维人员处于不同的组织结构中,并遵循不同的流程。通常,CEO 是指挥链中的第一个共同环节。这导致两个团队拥有不同的目标。开发人员想要为客户创建更多功能,而运维人员想要保持现有功能可用。这种紧张关系使得开发和运维之间建立健康的伙伴关系非常不可能。

传统上,开发人员可能永远不会知道他们引入的内存泄漏导致了服务的每周重启。或者运维人员可能不知道他们的操作系统补丁和重启过程导致了重要的功能退化。并且加在一起,他们已将潜在客户推向竞争对手。当开发人员和运维人员使用相同的流程和工具集时,他们能够协作并互相学习。

然后,开发可以将敏捷和 scrum 等概念引入运维学科,以加速产品组件的交付。运维人员可以介绍他们领域中需要如此多纪律的复杂性。这两个团队之间新发现的理解带来了巨大的增长机会。

同理心带来理解

这种学习和协作过程在团队之间孕育了同理心。同理心增强了理解,甚至可以带来更可预测的行为。开发人员现在可以预测他们的决策将如何影响运维人员。开发人员无需就每个决策都咨询运维部门,他们将能够根据他们对系统上下文的增加了解做出更好的决策。然而,客户价值的产生不仅仅局限于组织中的这两个团队。

当您考虑 DevOps 团队的结构时,当然您会从开发人员和运维人员开始。但是还有其他角色需要考虑,例如业务分析师,他们对于您的 DevOps 团队的成功同样重要。

业务分析师和其他与业务相关的角色应参与到开发过程中。这很可能是许多需求的来源,这些人将深入理解这些需求。将某些内容写在工单上并保证它被完全按照预期的方式解释是非常困难的。让业务团队每天都参与进来将减少返工和错过截止日期的情况。

DevOps 文化的战略联盟

那么公司的其他部门,即到目前为止尚未涵盖的职能部门呢?很多时候,这些团队被视为阻碍者或橡皮图章,任何互动都被推迟到最后一刻。这些团队应该首先参与进来,因为他们通常在决策中拥有很大的发言权。销售、营销、安全、财务、法律和人力资源可以从阻碍者和橡皮图章转变为拥护者和战略合作伙伴。让我们来看看这看起来像什么。

销售

销售团队应作为您的 DevOps 文化的一部分纳入其中。他们很可能也在产生需求,并且他们可能与客户以及客户真正重视的东西有最好的联系。他们将能够提供与客户的巨大联系,以便在整个团队中建立客户同理心。建立客户同理心和理解的更有效方法是让销售人员带领团队成员拜访客户。

营销

营销销售您的想法。在营销中找到一位优秀的设计师和合作伙伴至关重要。即使您不认为自己在营销某些东西,您也在营销。我们都在营销。每一天。我可能认为我可以很好地营销我的想法,但营销团队是每天都做这件事的团队——并且为此获得报酬。他们知道自己在做什么。我经常将演示文稿、架构图、文章、想法和活动带给他们,以便他们可以帮助我产生更大的影响。营销是力量倍增器。

安全

安全通常是许多公司中的一个独立实体。重要的是要注意,在 DevOps 文化中,安全也是开发人员和运维人员的首要关注点,而不是留给中央团队在所有内容部署完毕后进行修复。然而,安全部门的中央职能,即制定合理的策略、审计这些策略以及建立一些最佳实践和工具,是非常有价值的。尽早与安全部门沟通非常重要,这样他们可以帮助您成功,而不是被迫告诉您您的代码无法部署到生产环境。他们真的别无选择。

财务

财务部门可能会因为不批准关键采购而完全阻止您的整个计划,因为它可能会以您在现有背景下不理解的方式对业务产生负面影响。尽早让他们参与谈判至关重要。我发现他们通常拥有糟糕的工具,帮助他们进行一些自动化可以获得巨大的回报。

法律

当合同和许可证没有尽早提供给他们审查时,法律部门可能会将您的整个计划延误数月。我对法律有一种副业爱好,这使我阅读了数千页的法律和法院意见,因此我可能比大多数人更喜欢与法律部门交谈。

这是我启动任何新计划时首先联系的团队之一,因为他们需要了解您在做什么以及为什么要这样做。这将帮助他们确定公司存在哪些风险以及如何防范这些风险。例如,实施自带设备 (BYOD) 策略或使用 Slack 作为主要沟通工具需要理解比我可用的更多的背景信息。我还通过与他们合作创建一份始终批准的许可证和永不批准的许可证列表来帮助他们进行许可证审查。根据我的经验,这可以将他们的审查流程减少 50% 以上。

人力资源

人力资源部通常无法阻止特定的计划,但他们对招聘有巨大的影响,而招聘最终会影响公司文化。GitLab 拥有我见过的最好的文化之一。您可以在互联网上找到 GitLab 的 HR 文档,甚至可以 提交合并请求 以提出修改建议。那里的每个人都使用 GitLab,包括人力资源部,但这对于大多数组织来说可能是一个崇高的目标。朝着这个方向迈出的小步包括与内部招聘人员合作,确保他们知道您在文化契合方面寻找什么,帮助他们自动化耗时的任务,并通过让他们拥有部分文化的所有权来尽早让他们参与进来。

一个团队,一个目标:客户价值

公司的其他这些领域,与产品开发没有那么密切相关,通常会更加规避风险,因此耐心和教育是关键。他们和您有相同的目标——尽可能为客户创造最大的价值——所以不要与他们作对或树敌。给这些角色机会,他们会以他们的聪明才智和驱动力给您留下深刻印象。

标签
Dan Barker
网站:http://danbarker.codes 邮箱:dan@danbarker.codes

2 条评论

您忘记了这里最关键的部门,性能工程团队。我工作的公司没有采用这一点,现在他们正坐拥一个性能不佳的产品。

一个性能不佳的产品不会吸引客户 - 底线

本文重点关注工程部门以外的团队。我倾向于认为大多数组织不需要单独的性能工程团队,因为性能是进行产品开发的产品团队的责任。可能有一个团队专门研究性能以及性能的知识转移,但他们不应该对产品的性能负责。

回复 ,评论者:PerfEngi (未验证)

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 许可。
© . All rights reserved.