去年，我们与 1850 多个工程组织进行了交谈。大多数人正在计划或已经在构建内部开发人员平台。以下是我们看到这些团队陷入的最艰难的教训和谬误。
平台工程、内部开发者平台和开发者自助服务总体上是一个快速增长的趋势。
根据Puppet 的 2020 年和 2021 年 DevOps 状态报告以及我们自己的DevOps 基准研究，采用这些趋势是让表现最好的工程组织与表现不佳的团队区分开来的原因。内部开发人员平台和开发人员自助服务通常被视为跨越组织 DevOps 转型鸿沟的最佳方式。
我亲眼目睹了 2021 年的 249 个平台，这让我对团队如何优先考虑这些努力、常见的陷阱和关键错误有了独特的看法。在这篇文章中，我将阐述我的主要观察结果，我计划最终将其汇总成一个更大的指南（甚至是一本书），围绕企业平台化。
平台工程入门
Luca Galante 将平台工程定义为
“设计和构建工具链和工作流的学科，为云原生时代的软件工程组织提供自助服务功能。平台工程师提供的集成产品通常被称为“内部开发人员平台”，涵盖了应用程序整个生命周期的运营需求。”
因此，我们最终致力于将开发运维粘合在一起，形成一个易于消化的内部开发人员平台，以平衡软件工程师的认知负荷，以便他们能够更好地处理设置的复杂性。
开发人员自助服务不应该意味着您需要 1,000 名 Kubernetes 专家来围绕 Kubernetes 运行 1,000 种不同的服务。
收集了团队在开始平台工程时最常犯的 10 个错误：
#1 优先级谬误
除非您碰巧为 Google 工作，否则您的预算可能有限，对此您无能为力。对优先级进行长时间的思考是非常重要的。我所说的 8/10 团队犯了这个错误，这些错误代价高昂。最常见的例子是团队在应用程序和开发生命周期中首先想到的事情并将其作为最高优先级，而不是从整体上看待整个生命周期。
大多数平台团队从优化入职体验以及如何创建新的应用程序或服务开始。
但这种情况多久发生一次？仅仅运行一个脚本可能还不够吗？
那么，您如何以正确的方式考虑优先级呢？我有一个非常简单的经验法则。进行 100 次部署。现在询问您的基础架构、运营和应用程序开发团队：
- 部署只是对镜像进行简单更新的频率如何？
- 他们多久启动一次新环境？
- 他们多久加入新同事？
- 他们多久添加一次新的微服务？
- 他们多久更改或添加资源（数据库、文件存储、DNS）？
- 他们多久添加或更改一次环境变量？
记下所有内容后，询问他们每次必须执行这些活动时各自花费了多少时间。例如“运维需要多长时间来配置一个新数据库”？由于必须等待，对开发团队有何影响？根据所有这些信息构建一个表格并相乘。您将获得一份很好的优先事项清单。
作为提示：我们已经分析了全球 1850 多个设置，您的团队更有可能处理配置更改而不是添加新服务。这就是你的答案。
#2 可视化谬误
我最喜欢的例子来自世界最大的在线零售商之一。他们投资了惊人的 104 名 FTE 来构建他们的平台。在那里，开发人员可以通过打开的 PR 和他们的应用程序开始他们的早晨浏览。每个服务都显示在目录中。高管们喜欢这样的仪表板体验。它还让他们感觉对谁是哪个服务的所有者具有透明度。但它仍然没有解决任何问题。
万一发生灾难，高管们会说“我没有人可以打电话，因为我们现在完全透明了”。听起来不错，但开发人员可以在他们的日常工作流程中查看 Github 和其他工具。当灾难发生时，他们通常知道该给谁打电话。
这样的解决方案不会告诉您究竟出了什么问题以及原因。问题应该是如何降低变更失败率。
因此，如果您查看他们的开发者门户的实际使用数据，您会发现人们只在开始新服务时登录以搜索其他服务。
正需要做的事情：清理应用程序配置和非结构化脚本中的混乱，这些脚本会因维护和错误而消耗时间。
第二件事是基础架构编排和配置，因为这通常涉及多个不同的团队，因此会产生等待时间。
#3 “你无法打赢的战争”谬误
你的任务是清理混乱，因为你的团队使用了“太多的工具”。
一个团队使用 Jenkins，一个 Gitlab，一个 Azure DevOps，您构建了在完美世界中您的团队将只使用一个 CI 系统。
解决办法很简单，把CI工具限制在构建镜像上，把它们连接到平台API上，把这部分集中起来，并与基础设施和集群连接起来。这对CI设置有净化作用，你得到了你真正关心的东西的集中和精简。无论你在哪个团队工作，开发者的体验都是完全一样的。
#4 "所有东西和所有人都在一起 "的谬论
如果你想自上而下地、一次性地、高度标准化地进行文化转型是很难的。雇佣顾问大军对开发人员进行云原生的培训，等于白做：你正在做的是你在逼迫人们。人们讨厌被逼迫。
你把一些东西放在一起，然后告诉人们去使用它，也是这样。
解决办法：找到一个灯塔团队，花大量的时间与他们在一起，使其正确。从内部培养大使和传教士，给他们时间和自由来影响团队的其他人。
一步一步地开始，将同样多的时间放在优先级和规划上。让你的管理层明白，他们需要降低路线图的期望值。
与你的开发人员交谈。迪斯尼在这方面做得很好。他们定期举办工具链黑客活动，在此期间，团队优化他们的设置，并对平台的路线图产生影响。识别你押注的未来技术，并将其正确化。
#5 "新设置并不更好 "的谬论
这个问题与之前的 "一次性完成 "谬论紧密相连。团队倾向于一次做太多事情（或者被逼着以超过他们能力的速度交付），建立一个充其量是平庸的平台。新的平台有一个问题，就是它们是新的（哈哈）。意味着人们必须习惯于它们，而且根据定义，它们的边缘是粗糙的。
就平台而言，同样困难的是：你如何找到MVP？正如退伍军人联合会的平台产品负责人Alan Barr在之前的聚会中提到的。
"平台往往是厚重的，它们必须做很多事情，你要找的是复制你已经有的工作。"
在日常使用中，小事情就是算数，而且需要时间。许多转型失败是因为新的平台是新的，但它并不比以前的解决方案更好。在这种情况下，没有新的功能可以真正让开发者的生活更轻松。但是，没有人能够真正阐明为什么个人的牺牲会对整个组织的理智带来好处。你的新平台必须要比以前的设置好几倍，否则就会失败。
缓解这种谬论：
从小处着手，用真正的产品思维，这一点我怎么强调都不过分。以一个灯塔式的应用程序为例，它无论如何都是领先的，是完全容器化的，在你的最佳基础设施堆栈上运行。现在过度投资于这一设置，就像没有明天一样。构建一个好得多的东西，让用户成为布道者，而其他团队也非常想拥有这个东西。不要试图建立一个统治一切的平台（见上一个谬论）。在大型机和Kubernetes之间不存在良好的体验。这是一个值得停止梦想的梦想。
#6 抽象的谬误
工程师讨厌为了抽象而失去对底层技术的使用。我们中的许多人都见过这样的日子：不被理解的标准化尝试让我们无法做事，并拖累了我们。有没有在一个超级严格的OpenShift实例中工作过，你一直在等待中央运营团队搞清楚你要求的选项是否应该成为标准？不要落入这个陷阱。抽象不应该意味着限制。你的同事会立刻讨厌你，这可不是一个好地方。
缓解这种谬论 ：
建立黄金通道而不是笼子。我的意思是，并不是说抽象本身是错误的，但你必须想使用它们。如果它们不起作用，团队应该能够在任何时间点上规避它们。让我给你一个具体的例子：你的基础设施协调方法是，如果一个开发人员请求一个数据库，就启动一个默认的Terraform模块。这已经通过了安全审查，在大多数情况下是可行的。你的开发人员有一个合格的边缘案例。与其关闭规避默认的选项，不如让他们自己来扩展模型。通过给予一定的保证，使他们不必为预先审查的设置负责或随叫随到，从而促使他们保持在这条道路上。
#7 "最响亮的声音 "的谬误
这一点很重要。我见过的几乎所有的团队都被这个谬论骗了。随便找一个由7人组成的工程团队，其中有一个人物我称之为 "内核黑客"。对这个人来说，如果某样东西不在资源库里，它就不存在。她每天都在用Aduino对她的烤面包机进行重新编程，并通过bash脚本向她的伙伴求婚。
这个人非常善于围绕整个运营和交付计划的结构进行阐述。这就构成了一个很高的风险，即你要根据这个人的规格来优化平台和整个设置。只是因为这个人的自信心让其他人都闭口不谈。问题是，其他人都必须操作这个设置，否则你就会陷入低于自由的谬论。
缓解这种谬论：
好的设置是为链条中最弱的环节而不是最强的环节设计的。当你起草你的战略时，当你确定工作的优先次序时，当你把你的平台设计成一个产品时，确保你向开发者征求意见。不要在具有高度多样性的大型会议上询问他们。而是要单独询问不同的人群。如果你把铁杆SRE放在JS开发者旁边，你会得到错误的输入。谨防抽象谬误。内核黑客不应该被限制。让他们成为扩展平台的一部分，让他们进入工作小组，并清楚地说明为什么某些事情要这样做，以服务于更广泛的社区而不是少数人。
#8 自由谬论
在一个歇斯底里的尝试中，为了赢得他们工程团队的心，工程经理们剥离了最后一点标准，把AWS的访问权交给了每个人。中央运营团队已经成为过去，权力被转移到个人贡献者身上。耶，所有规模化工作的缺点，没有任何好处。我没有看到这一次是成功的，但它却被一次又一次地尝试。你可以从字面上观察到事情是如何走偏的。首先，每个人都心不在焉，因为他们现在正在熟悉Helm、Terraform和ArgoCD的魅力。这也意味着他们没有完成他们的工作。大多数开发者最终意识到了这一点，将他们的注意力转移到手头的工作上（编写NodeJS应用程序，这已经很困难了）。不是因为他们没有能力，而是因为让7/7个团队成员达到必要的专家水平并不划算。但总得有人来做这个工作，所以通常会有一个资深的同事来照顾一切。我把这些人称为影子行动。长话短说：你记住我的话，在接下来的12个月里，你的总生产力将下降15-25%。享受吧!
缓解这种谬论：
通过实现开发者自助服务来消除对关键人物的依赖，不应该与把额外的认知负荷扔给开发者有关，因为他们没有能力处理。正如在Salesforce建立内部开发者平台的Aaron Erickson所说："要在Kubernetes上运行1000个不同的服务，你不应该需要1000个Kubernetes专家来做。" 始终针对团队能够处理的认知负荷程度进行优化。
#9 "谷歌/Facebook/Netflix "的谬论
挑衅的想法，但你不是谷歌、Facebook、Netflix，也不是Spotify。这在很多方面都是正确的：你没有资金，你没有影响力，你没有足够的规模。这也意味着你不能也不应该复制他们的做法。他们能给你带来灵感吗？也许吧。
但说实话，你很可能并不详细了解他们的内部用例。例如，当人们谈论Netflix时，很少有人知道他们主要只建立了一个大的主要服务，正如Nigel Kersten（Puppet）最近提到的。另外，如果你的企业在一个高度管制的行业或关键的基础设施中运营，"快速移动，打破东西 "并不是好的建议。我们在花哨的会议上听到的谈话越多，我们就越有可能将自己与我们不应该比较的设置进行比较。让我再给你举个例子。最近，每个人都建立了开发者门户网站，为你需要一个新的微服务的情况进行优化。其中一个品牌有一个突出的产品，使之超级方便和简单--为他们自己的需求而建，不一定是你的。但是，等等，你实际上多久会创建一个新的微服务？如果你是全球流媒体的领导者，那就非常、非常频繁。如果你是 "德意志银行"，就不是很经常了。这些产品也提出了大规模的模式，甚至更大的平台和中央云运营团队。它们在非常特殊的情况下起作用，但在你的情况下不太可能起作用。
缓解这种谬论 ：
如果你的团队中的任何人或任何顾问将这些品牌进行比较，你一定要有超强的判断力。这样做的几率很低。加入社区并与同行交谈，确保这些设置实际上是可以比较的。
#10 "与AWS竞争 "的谬论
你能让AWS做的事情，就让他们做吧。不要重新发明轮子。你永远无法打败他们的团队。他们拥有世界上最好的工程师，他们的资源可能是你的1000倍。
缓解这种谬论：
在建立平台时，要专注于你的设置所特有的东西，但要尽可能地使用专业工具。如果你想建立专业的工具，你应该在Terraform、AWS或Humanitec申请，在任何其他情况下，你应该专注于那些能推动发展的东西。很抱歉这么直白，但其他的都是废话。