在快速发展的软件开发领域，具有前瞻性思维的企业组织正在拥抱平台工程文化的变革力量。这种创新方法强调创建共享平台、工具和实践，使开发人员能够更快、更高效地交付高质量的软件。在本文中，我们将深入探讨平台工程文化的核心原则和深远的好处，探索它如何在技术团队中促进协作、创新和可扩展性的独特融合。

01 平台工程文化的本质

平台工程文化的核心理念是建立一套可重复使用、可扩展的工具、服务和框架，为整个组织的开发人员赋能。这种文化提倡创建可被不同团队和项目利用的集中式平台，而不是将基础设施和通用服务视为孤立的项目。这种方法的协作性和前瞻性消除了重复劳动，简化了开发流程，并确保了不同产品和服务之间协调一致的产出。

02 平台工程的基本原则

• 抽象和标准化：平台工程师熟练地抽象底层基础设施和服务的复杂性，为开发人员提供简单和标准化的 API。这样，他们就能让开发人员专注于构建特性和功能，而不是处理低层次的实施细节。

• 自动化：平台工程文化的核心是对自动化的高度重视。自动化调配、部署、测试和监控流程使团队能够以更高的速度、可靠性和一致性交付软件。

• 自助服务：平台工程师努力赋予开发人员自助服务功能，使他们能够毫不费力地访问和管理资源。这些自助服务平台有助于加快迭代速度，减少日常任务对集中团队的依赖。

• 持续改进：平台工程文化深深植根于持续改进的原则。平台工程师会积极征求开发人员的反馈意见，找出痛点，迭代演进平台，以满足不断变化的开发需求

03 拥抱平台工程文化的优势

• 加速开发：通过提供预构建的组件和服务，平台工程文化加速了开发过程。开发人员可以集中精力构建应用逻辑，从而减少冗余，加快新功能和新产品的上市时间。

• 增强协作：平台工程文化培养跨团队协作精神。平台团队与应用程序开发团队携手合作，促进合作意识和共同责任，以交付高质量软件。

• 可扩展性和效率：共享平台本质上可以减少冗余工作并提高软件开发效率。随着组织的发展，该平台可以无缝扩展以适应不断增长的需求，而无需大幅增加资源。

• 一致性和可靠性：标准化平台可确保各产品的一致性，从而带来更可靠、更可预测的用户体验。此外，自动化流程可减少人为错误，提高系统可靠性。

• 鼓励创新：通过将常见的基础架构问题委托给平台团队，应用程序开发人员可以专注于创新和构建独特的功能，为其产品或服务增加实质性价值。

• 降低风险：标准化平台降低了系统故障和中断的风险，提高了整体可靠性和性能。

向平台工程文化过渡可能会带来一些挑战。循序渐进的采用过程，加上持续的反馈循环，可以确保无缝过渡，并确保每个人对平台工程文化的接受。

04 案例研究：Licious 的卓越平台工程之旅

以 Licious 为例，我们将分析向平台工程过渡的实际好处与优势。在 Licious 内部已经意识到需要一种更加精简、可扩展和高效的软件开发和部署方法。

在这一过程中，和许多其他企业一样，都遇到了与软件开发规模相关的挑战。随着应用程序数量的不断增加、版本的频繁发布以及复杂的技术堆栈，Licious 发现在 DevOps 实践中保持一致性、可靠性和效率变得越来越困难。

认识到现有 DevOps 方法的局限性，去年年初，我们决定过渡到平台工程，以全面应对这些挑战。随后我们分阶段实施了战略路线图。

第 1 阶段：通过自动化和左移增强 DevOps 能力

在第一阶段，我们确定了以下工作领域：

• 战略和可衡量指标：我们对当前的实践进行了全面评估，找出了痛点，并制定了一个具有衡量标准的强大 DevOps 工程方法愿景。我们制定了明确的战略，使平台工程目标与公司的长期业务目标保持一致。

• 团队重组和技能发展：对技术熟练的 DevOps 工程师团队进行了重组和技能提升，使其专门从事平台工程。还提供了额外的培训，以确保他们掌握 IaC、容器化和通过云原生方法实现自动化部署管道等领域的必要知识。帮助他们将编程作为核心，而不仅仅是脚本。

• 采用基础设施即代码：我们投资于 IaC 实践，使用 Terraform 自动配置和管理基础设施。这使得基础架构部署和补丁的一致性、可重复性和版本控制成为可能。

• 容器化和编排：使用 Docker 进行容器化，并通过 Kubernetes 进行协调，以简化跨不同环境的应用部署、扩展和管理。采用云原生堆栈。创建基于 Kubernetes 的操作员，以自动化方式处理手动操作。

• 在 45 天内将 100+ 项服务从 EC2 迁移到 Kubernetes。

• GitOps 和左移：我们投入了大量时间开发自助服务流程，并充分利用 GitOps 原则，使开发团队能够自主调配资源、管理部署和监控服务。这消除了资源瓶颈，减少了人工干预的需要。

• 持续改进：我们不断收集开发团队的反馈意见，并根据实际使用情况和挑战迭代改进平台工程实践。

第一阶段成果

第一阶段的结果非常积极。在团队内部，我们能够：

1. 减少 DevOps 每天执行的冗余任务。

2. 减少对 DevOps 的依赖和阻碍。

3. 提高系统的可靠性和可扩展性。

4. 减少由于高峰时段和活动而导致的意外中断。

5. 服务所有者更有能力自信地管理其应用程序。

6. 最重要的是，改善DevOps工程师的工作与生活平衡，减少夜间意外急救时间。

第 2 阶段：内部开发人员平台

Licious 平台工程之旅的下一阶段是内部开发人员平台。

为什么？

在向 Kubernetes 平台迁移的过程中，我们面临的大部分挑战都是如何找到已废弃服务的所有权以及部署在 Git 上的活动分支。因此，我们萌生了建立内部服务目录的想法。

要解决什么问题？ 

减少新服务的载入时间；改善开发人员体验并实施服务成熟度指数；简化我们从开发到生产的发布过程，实现对 DevOps/平台工程师的零依赖。

进展如何？

目前，我们的 IDP 之旅还处于初期阶段。但是，当我们越多地了解其他公司对内部开发人员平台（如 Spotify 的 Backstage）的调整时，我们就越坚信自己走在正确的道路上。

第二阶段成果

Licious 从 DevOps 到平台工程的转变，展示了采用整体方法进行软件开发和部署的变革性影响。通过创建一个标准化、可扩展和自助式的平台，将效率、可靠性和协作提升到新的水平。