不久前，我在荷兰的一个技术活动上向主要由系统管理员组成的听众发表了讲话。我的主题之一是系统管理员如何提高他们为组织提供的价值。我认为，提供价值的最重要因素之一是每个人都要了解组织的整体优先事项和目标，以及组织开发团队的优先事项和目标。
这一切听起来很明显，但在许多组织中，信息孤岛几乎完全阻止了团队间沟通，而这种沟通对于理解彼此的优先事项是必要的。即使在大型组织中，这些组织拍拍自己的后背，声称已经完全采用了 DevOps（或渴望完全采用 DevOps），但对其他团队的优先事项和目标的了解并非无处不在。当我问我的听众中那几百人是否了解他们的开发团队以及驱动这些团队的因素时，很少有人举手。
你可以辩称，如果你声称已经完全采用了 DevOps，但你的人员不了解他们直接合作的团队的目标和优先事项，那么你就是做错了。你说的可能没错。但先放在一边。即使在传统的组织中——一个只是刚刚开始其 DevOps 之旅、已经实施了 DevOps 理念的某些部分，或者只在组织的某些部分实施了 DevOps（我见过所有这些情况）——我也会强烈建议你了解你的同事。我 *特别* 建议你了解那些在你的团队之外，与你构建和维护的平台合作（或在其上工作）的人。
花一个小时左右的时间，与在你的平台上开发应用程序的人，或者与维护其上的商业现成软件的人坐下来谈谈。让他们向你解释你的平台和你的服务如何使他们的生活更轻松，以及如何使他们的生活更困难。你和你的团队可以做些什么来改善这种情况？
互相交谈，互相学习，辩论问题*和*解决方案——特别是与那些最初目标可能与你不同的的人——有助于每个人一起前进，并构建造福整个社区的东西。
我们一直在世界各地的开源社区中看到这种情况。由来自不同公司和不同人员组成的广泛社区，他们有着（可能）不同甚至相互冲突的目标，都能正常工作。成功的开源社区通常是多元化的，成员之间进行沟通以满足广泛的目标，寻找妥协方案，并照顾到每个人。
在广泛的开源社区与在你的组织中与“相邻团队”合作，以使你的平台更好地适应他们的利益和目标之间，存在明显的相似之处。这只是采取第一步并开始与他们对话的问题。
此时，你可能会问：“但这不就是我的架构师或服务所有者应该做的事情吗，对吧？” 嗯，是的，当然，他们在这方面发挥了作用。许多其他人也是如此。你也是！
例如，假设你的组织为你的团队设定了一个目标，即在收到初始请求后一周内交付一项服务。如果服务在一周内交付，则满足服务级别协议 (SLA)，一切都很好，对吧？实际上，这有时才是正确的。
假设你的目标是在一天内自动（根据自助服务请求）交付一台新的虚拟机 (VM)，并且成功率至少为 95%。现在假设一个开发团队每天为 CI/CD 目的请求数十台临时 VM，并且 95% 的 VM 都被正确交付。你的目标已经实现，你的 SLA 已经达成——但没有人对这种情况感到满意，因为 CI/CD 管道由于配置错误的 VM 而多次中断。
[更多阅读：改善对话的 10 种方法]
在本例中，需要尽快重新评估目标和 SLA。但是，即使在一个孤岛化的组织中，与你的开发团队或应用程序维护人员进行定期的对话，也可以使这种情况不太常见（如果发生的话也更容易解决）。小烦恼和小问题将在早期被发现；小改进将被提出，小改进将在大规模部署影子 IT *之前* 被完成。
归根结底，没有什么比人与人之间的沟通更好。没有什么能像知道哪个名字对应哪张脸那样打破障碍。没有什么比知道他们希望支持你取得成功更容易与人交谈！所以，去和你的相邻团队谈谈吧。和他们一起喝咖啡。在你的组织中建立一个广泛的社区！
附：您的开发团队很可能会与您谈论云和持续集成与交付。这些是本文潜在的后续行动的议题。敬请关注！
2 条评论