内部开发者门户：三个实际案例
内容提要
本文讨论了平台工程和内部开发者门户在组织中的应用，分享了三家组织领导者的经验和见解。强调了平台工程和内部开发者门户对于提高开发效率和开发者体验的重要性。介绍了选择内部开发者门户的原因和实施方法，以及使用后的成果和收益。
延伸解读
平台工程动因各异，但目标一致
三家企业引入平台工程的背景各不相同：AMCS因团队从200人扩张到1200人，原有DevOps模式成为瓶颈；PGS因疫情缩减人员，需用更少人力维护大量系统；GAIG则直接以提升开发效率和体验为目标。尽管起点不同，但都指向同一方向：通过平台工程和内部开发者门户，让开发者更自主、更高效地完成工作。
自建还是采购？需权衡资源与复杂度
AMCS最初考虑Backstage，但评估后发现其复杂度高，团队资源不足以自行维护，最终转向SaaS方案。PGS也认为自建UI抽象层并非其核心任务，选择消费现有产品。GAIG则采用产品化方式自建门户。可见，选择取决于团队规模、资源和对控制权的需求，没有统一答案。
黄金路径与自助服务：降低认知负荷
PGS发现，尽管有文档，开发者仍难以遵循统一最佳实践，导致兼容性和一致性问题。通过定义黄金路径，并将自助服务与治理结合，PGS和AMCS让开发者能快速完成原本耗时且需多团队协作的任务。例如，AMCS将85分钟的任务缩短至5分钟，同时确保符合规范。
产品化方法与持续反馈是关键
GAIG和AMCS都将门户视为产品，设立产品负责人、Scrum团队，并通过冲刺迭代。GAIG在软启动阶段收集约50名开发者的反馈，调整后再推广至300人。AMCS则收到来自开发、支持、专业服务等多方积极反馈，并持续收集新需求。这种产品化方法有助于提升采纳度和信任。
Q&A
内部开发者门户的主要目的是什么？
内部开发者门户的主要目的是提高软件开发过程的效率和开发者体验。
AMCS Group为何决定实施平台工程？
AMCS Group在经历DevOps实践后，意识到需要平台工程来应对快速增长带来的挑战，解决请求积压问题。
GAIG在开发内部开发者门户时采取了什么方法？
GAIG采取了产品化的门户开发方法，重视开发者的需求和反馈，进行多次会谈以确保满足开发者的需求。
PGS在实施Kubernetes后遇到了什么问题？
PGS在实施Kubernetes后，发现其复杂性导致开发者的认知负担过重，难以有效使用。
引入内部开发者门户后，PGS和AMCS的效率如何变化？
引入内部开发者门户后，PGS和AMCS的效率显著提高，开发者能够更自主地完成任务。
如何确保内部开发者门户满足开发者的需求？
通过收集反馈、进行需求调研和迭代开发，确保门户能够满足开发者的需求。
