我们是一家拥有 80 名开发人员的公司的平台团队。我们使用 Github Actions 为 CI、EKS、RDS 运行一个普通的技术堆栈，没什么特别的。我们在这个系统上运行多个应用程序，所有微服务。管理层明确的方向是建立一个开发人员平台，可以帮助工程师端到端自助服务：
- 回滚
- 新数据库
- 新服务
- 调试
- 配置管理
- RBAC
- 启动新环境等。
然而开发人员说 "不"。没有明确的拒绝的道理，他们没有说什么是错的，也没有说为什么会拒绝，他们不能指出任何我们不涵盖的情况，但他们有一个简单而明确的方法可以规避这个系统。
如何解决问题？
关键是要满足所有利益相关者（包括提供基础设施的人，无论是 AWS 还是英特尔）。如果您在构建时没有不断地寻求和响应最大利益相关者的需求，那么您就不会构建他们需要的东西，他们会讨厌它。
如果是在“管理层指导”下完成的，这就变成了一个“熟悉的”故事。你不能以自上而下的方式进行开发。所以你基本上建立了一个管理系统，管理人员对为什么开发人员不使用它感到惊讶；然而，开发人员可能没有被问到他们真正的问题是什么以及他们真正需要什么。
注意：在某些组织中，开发人员可能是一个非常孤立的集团，可能需要数月或数年才能与他们“融入”（除非您是那些“软技能”专家之一）。
你必须找出痛点在哪里，并为这些痛点介绍解决方案。也许还有一个总体路线图和愿景。在旧的瀑布世界中，我们将这个过程称为“需求引出”。
不要试图解决你认为的问题。解决产生真正生产力收益的实际问题。
教训：不要在前期建立一个平台
成功的平台是新兴的。它们不是在前期建立并推到开发者面前的。它们是和开发者一起建立的。平台团队不断地寻找方法，使事情对开发者更有利。
一个平台不需要有所有的功能，但要有足够的能力使一个团队富有成效。在过去的几年里，我建立了一些平台（和团队），为超过200名开发人员提供服务，我的方法是：
与团队一起建设。从一个团队开始，确保平台适合他们的目的，然后再到下一个团队。随着更多团队的加入，他们会产生对平台的需求和要求。
团队需要在你建立平台的过程中学习。
你不能大张旗鼓地进行，这对他们来说是一个大跳跃。有很多东西需要学习。看起来你已经为他们创建了一个长长的清单，让他们知道如何使用这个平台。平台应该把这种一次性清单都拿走，一起成长学习。
听取团队的意见，平台的存在是为了服务他们。他们是你的客户。
你需要用产品的方法来处理平台。
教训：对运维不重视
根据我的经验（我是开发方面的 DevOps），大约 3/4 的团队对 Ops运维方面不感兴趣，甚至没有看到任何价值。它与组织的文化和结构紧密匹配——逆康威定律。如果公司的文化期望并鼓励其创建者定义的 DevOps，雇用具有相同期望的人，你会看到奇迹。