如何在公司内部的Dev 和 Ops 团队之间实现更好的沟通？如今，大多数公司的开发人员和运营人员都很难进行协作。本文将让您了解每个目标，并了解如何协调他们以符合 DevOps 文化。
简而言之-DevOps文化
DevOps 文化基于以下原则：通过建立真正的职能团队打破 Dev 和 Ops 之间的孤岛，尽可能缩短发布周期。
什么是真正的职能团队？
在技术项目中，团队通常包括以下角色：产品负责人、开发人员和用户体验设计师。“Ops”（运营）是应用程序稳定性和可用性的保障者，然后拥有自己独立的团队。在 DevOps 文化中，Ops 包含在产品团队中。这被称为功能团队，因为它是自主生产其功能的。从设计到生产。
什么是好的发布周期？
一个成功的敏捷团队可以每天完成为期一周的冲刺并部署暂存功能。另一方面，即使是最高效的团队也倾向于等待两周甚至一个月才能将他们的开发成果投入生产。这样的发布周期减慢了获得客户反馈的速度，从而减慢了产品的改进。由于 DevOps 文化，Devs 和 Ops 之间的流畅协作促进了更定期的发布，从而缩短了迭代周期。一个好的 DevOps 组织还可以在事件发生时做出更有效的反应。
开发和运营：相互矛盾的目标？
从历史上看，开发人员一直关注他们提供的功能数量。另一方面，Ops的使命是确保站点 100% 的时间正常运行。发布是造成停机和服务反复不稳定的主要原因，我们可以理解 Ops 不愿意每天部署功能。 这些相互冲突的目标以及Dev和Ops之间缺乏协作通常会在这两个专业之间造成紧张关系，从而损害产品及其最终用户的利益。 存在的问题点：
- 对投入生产的必要性存在分歧。
- 在发生错误时甩甩甩锅“它不是我们的问题，问题在应用程序方面，由他们来管理”
- 交流之间的沟通延迟。当沟通不顺畅时，一个简单的问题可能会浪费宝贵的时间。
一个小例子来说明最后一点： 某客户，由于沟通不畅，原本应该10min的环境变量变化，却花了24h多（没有好的沟通过程，而不是直接互相交谈）让 2 个团队在合适的条件下进行有效的协作将节省他们的时间, 提高产品的质量和团队的氛围。
我为更好的开发/运营协作而制定的行动计划
沟通._ _ 这（永远）是战争的精髓。
第 1 步：创建职能团队
开发人员和运营人员聚集在一起，整个团队承担责任。Ops 和 Dev 互相帮助，共同确保正确的功能部署和生产稳定性。
第 2 步：将 Ops 时间用于支持开发团队
这可以采取多种形式，具体取决于您的方法，但目标始终相同：为和平合作创造条件。 来自开发人员的意外请求（例如打开新环境）不应被 Ops 团队视为不便。 开发人员必须了解 Ops 具有优先任务，每个 Ops 都有一个所谓的“缓冲区”半天，这是它根据每个请求提取的储备。这个缓冲区是嵌入在我们的 Ops sprint 中的每周的主题。这给了 Ops 干预所需的时间，但迫使开发人员优先考虑他们的请求，因为这个时间不是无限的。
第 3 步：结束“非正式”请求
任何请求，即使是最小的请求，都需要时间。了解需求、打断正在进行的工单、完成任务、在完成时提供可见性，所有这些最终都会在周末变得昂贵。 为了让开发团队了解请求了多少 Ops 以及它可能产生的影响，我们禁止了“非正式”请求。通过 Whatsapp，在咖啡机上，在会议结束时等。它们都在一个共同的渠道上为所有技术团队（通常是 Slack）制定。这有两个效果：开发人员对向 Ops 发出的所有请求有远见，并避免它们过载，并且发出的请求更加精确。
第 4 步：让 Ops 参与开发活动
敏捷方法也是促进沟通的好方法，因此也是良好的团队协作。提醒开发团队注意其功能的影响，并提醒他们注意可能遇到的任何复杂性。 Ops 参与：
- 到日常；
- 在 Scrum 仪式的“评审”部分；
- 在研讨会上；
- 来解决问题。
第 5 步：定义共同目标
在 Google，为了协调 Dev 和 Ops，团队制定了一个共同目标：错误预算。每个月，每个职能团队都被授权实现 0.01% 的停机时间。这使得在常规生产版本和基础设施稳定性之间设定平衡标准成为可能。 一起庆祝成功也很重要。无论 Dev 和 Ops 目标在职能团队中是不同的还是共同的（参见 Google），当其中一个目标实现时，作为一个团队庆祝它是很重要的。这样可以更好地参与团队。
总结
DevOps通过更频繁地交付更高质量的版本来节省时间。要实现这一点，必须让 Ops 和 Devs 作为一个团队工作。以下是实现此目标的步骤摘要： 1）组建职能团队 2) 投入运营时间来支持开发团队 3) 取消“非正式”请求 4) 让运维参与开发活动 5) 定义共同目标 一旦建立了这些基础，就总有可能走得更远。调试或值班等主题可以成为更密切合作的主题。
