企业内部平台扩散 | AI生成和翻译
问题：在大型公司和银行中，团队构建内部平台和工具是否常见？这些工具实质上封装了现有的开源解决方案，如 Ansible playbooks、用于构建包的 Jenkins 以及自定义部署平台。然而，其中大部分工作可以直接在 Jenkins 中完成。这种做法主要是为了创建内部项目以促进职业发展，导致工具质量较低，用户群小（1万到5万用户），维护团队规模小，长期成本高，并最终被淘汰。
答案：
是的，这种情况在大型公司，尤其是在银行和金融等高度受监管的行业中，非常普遍——不幸的是，它也很常见。
有几个因素促成了这种行为：
-
职业激励和政治：在大型组织中，晋升和曝光度通常取决于通过新项目、“交付影响力”、领导团队或拥有平台。构建内部工具或平台可以展示领导力并创建一个“王国”，从而证明人员和预算的合理性。仅仅改进现有的开源工具或管道很少能获得同样的认可。
-
法规和合规要求：银行面临严格的审计、安全和合规规则（例如 SOX、PCI-DSS、GDPR 或当地金融法规）。Jenkins 或 Ansible 等现成工具可能无法开箱即用地满足所有要求（例如，细粒度访问控制、审计跟踪、审批工作流）。因此，团队会构建封装或平台来添加企业级功能，即使这会部分重复功能。
-
与遗留系统集成：大型银行通常拥有数十年历史的主机、自定义中间件和专有系统。通用工具难以无缝集成，因此内部平台应运而生以弥合这些差距。
-
避免供应商锁定和定制：公司倾向于不过度依赖某个开源项目，以防其改变方向或停止维护。他们还希望拥有品牌、统一的 UI/UX 和支持合同——因此会选择内部解决方案。
-
“非我发明”（NIH）综合症：工程师和架构师有时认为他们可以构建出更适合自身需求的东西，低估了与 Jenkins、GitHub Actions 或 Docker 等成熟工具的质量和生态系统相匹配所需的努力。
您提到的缺点是真实且众所周知的：
- 与经过实战考验的开源项目相比，初始和长期质量较低。
- 10 年以上的高维护成本，团队规模较小（通常为 5-20 人）。
- 技术债务累积，导致难以现代化的过时技术栈。
- 碎片化：不同部门之间存在多个重叠的内部工具。
许多组织最终会认识到这一点，并转向“内部开源”（将内部工具视为开源项目）、采用云原生平台（GitHub Actions、GitLab CI、ArgoCD、Harness 等）或整合到更少标准化工具上。但由于沉没成本、政治和风险规避，转型缓慢。
总而言之，是的——这种情况很普遍，而且通常效率低下，但它深深植根于大型企业特有的组织激励和约束。进步的公司试图通过奖励对共享平台的贡献而不是新发明来对抗它，但这仍然是一场持续的战斗。