本指南探讨了平台工程、DevOps 和 SRE，探讨了平台工程的角色和职责，并教授了实施步骤。
平台工程是为开发人员构建和维护自助服务平台的学科。该平台提供了一套云原生工具和服务，可帮助开发人员快速高效地交付应用程序。平台工程的目标是通过标准化和自动化软件交付生命周期 （SDLC） 中的大多数任务来改善开发人员体验 （DX）。开发人员无需进行上下文切换（如预配基础结构、管理安全性和学习曲线），而是可以专注于使用自动化平台编码和交付业务逻辑。
平台工程具有内向的视角，因为它专注于优化组织中的开发人员以提高生产力。组织从以最佳级别工作的开发人员中受益匪浅，因为它可以缩短发布周期。该平台通过提供开发人员将代码投入生产所需的一切来实现这一目标，这样他们就不必等待其他 IT 团队提供基础架构和工具。使开发人员的日常活动更加轻松和自主的自助服务平台称为内部开发人员平台（IDP）。
什么是内部开发人员平台 （IDP）？
IDP 是一个平台，其中包含自助式云原生工具和技术，开发人员可以使用这些工具和技术来构建、测试、部署、监控或执行有关应用程序开发和交付的几乎所有操作，而开销尽可能少。平台工程师或平台团队在咨询开发人员并了解他们独特的挑战和工作流程后构建它。
在为许多大型高科技企业讨论和实施 Kubernetes CI/CD 管道和 GitOps 解决方案后，我们意识到典型的 IDP 将包含以下 5 个支柱：
- 用于自动化部署的 CI/CD 平台（ Jenkins、 Docker Hub、 Argo CD、 Devtron、 Spinnaker）)
- 用于管理容器的容器编排平台（ Kubernetes， Nomad， Docker Swarm)
- 用于身份验证、授权和密钥管理的安全管理工具（ HashiCorp Vault、 AWS Secrets Manager、 Okta Identity Cloud)
- 用于自动化基础设施预置的基础设施即代码 （IaC） 工具（ Terraform、 Ansible、 Chef、 AWS CloudFormation)
- 跨所有集群（ Devtron Kubernetes dashboard、 Prometheus、 Grafana、 ELK 堆栈）的工作负载和应用程序可视化的可观测性堆栈)
平台团队以易于开发人员使用的方式设计 IDP，学习曲线最小。IDP 可以通过自动执行重复性任务、减少维护开销和消除对无休止的脚本编写的需求来帮助减少开发人员的认知负担并改善 DX。IDP 通过提供自助服务平台，使开发团队能够独立管理资源、基础设施需求、部署和回滚。这增加了开发人员的自主权和责任感，减少了依赖性，并简化了开发周期。
为什么平台工程很重要？
平台工程可以帮助组织获得多个内部（开发人员）和外部（最终用户）优势：
Kubernetes Dashboard是在Kubernetes架构之上开发的外部服务。在后台，仪表板使用 API 读取所有群集范围的信息，以便在单个窗格中查看。它还使用 API 将资源和应用程序部署到群集中。CLI 和 Kubernetes 仪表板都依赖于 kube-API 服务器来处理请求。要开始使用 CLI，Ops 团队必须在同一集群中部署 Kubernetes 仪表板（类似于 Kubectl 部署）。
- 改进的开发人员体验 （DX）： 过多的云原生工具增加了开发人员的认知负荷，因为决定将哪一个用于他们的特定用例并掌握它需要花费大量时间。平台工程解决了这个问题，并通过提供一套简化、标准化的工具和服务来适应开发人员的独特工作流程，从而改进了 DX。
- 提高生产率： IDP 提供了开发人员以自助服务方式测试和部署代码所需的一切。这减少了 SDLC 不同阶段的延迟，例如等待某人配置要部署的基础架构。平台工程通过帮助开发人员主要专注于核心开发工作来确保他们的工作效率。
- 标准化设计：IT 团队在典型的软件组织中使用各种工具，因团队而异。在这种情况下，维护和跟踪事物变得复杂。平台工程通过标准化工具和服务来解决这个问题，并且他们更容易解决任何瓶颈，因为平台对每个开发人员都是相同的。
- 更快的版本： 平台团队通过提供易于使用、可重用和可配置的工具链，确保开发人员致力于交付业务逻辑。因此，开发人员的工作效率非常高，并且能够可靠、安全地加快功能和创新的上市时间。
在组织中实施成功的平台团队并利用上述优势需要遵循一些共同原则。将平台视为产品就是其中之一。
平台即产品
平台工程的核心原则之一是将平台产品化。平台团队需要采用产品管理思维来设计和维护一个不仅用户友好，而且满足客户（应用程序开发人员）期望和需求的平台。它首先收集开发人员遇到的问题的数据点，并确定要促进的领域。这可以提高部署频率，降低变更失败率，提高可靠性和安全性，改善DX等。
需要注意的是，构建平台就是构建一个核心产品，以解决大多数团队面临的共同挑战。 它不是解决单个团队的问题，而是跨多个团队提供产品来解决同一组问题。例如，如果多个团队需要相同的基础架构，则平台团队处理该共享部分并分发它是有意义的。这种重用平台和可重复性的想法至关重要，因为它允许应用程序交付的标准化、一致性和可扩展性。
与产品管理一样，平台团队拥有产品，选择某些指标，并继续获取客户反馈以改善用户体验。该平台的产品路线图随着反馈而发展，并适应客户不断变化的需求和愿望。
平台工程师的角色和职责
平台工程师的主要角色是设计和维护自助服务平台 （IDP），并为开发人员提供平台服务。首先要与开发人员互动并了解他们的痛点：
倾听客户心声
采访开发人员和不同的 IT 团队，了解他们的工程环境和挑战，并了解他们正在优化的内容。他们可能正在尝试构建有效的 CI/CD 管道或实现更好的访问控制，以及围绕软件交付的许多其他挑战。
优先
确定大多数团队共有的共同挑战，并优先解决这些问题，而不是单个团队面临的问题。例如，如果大多数团队发现难以安全地存储和检索机密，则理想的做法是优先考虑并为每个人解决机密。
平台设计
使用为用户解决这些问题所需的工具设计 IDP，以及使开发人员能够自助服务资源和基础结构的文档。在上述情况下，采用机密管理工具将解决有关安全管理机密的挑战。平台设计的一部分还包括编写脚本来自动执行日常开发任务，例如启动新环境和配置基础架构以减少开发流程中的错误和摩擦点。
指标
围绕目标选择特定指标来衡量平台的有效性。例如，如果目标是改进DX，则指标包括参与度分数，团队反馈等。同样，如果目标是降低更改失败率或提高部署频率，则指标将更改。
收集反馈并维护平台
继续倾听客户的意见并观察指标。收集用户反馈以向平台添加新工具并进行优化以获得更好的用户体验。这还包括及时了解DevOps和云基础架构领域的新兴工具和技术，并在必要时采用它们。
DevOps 工程师或 SRE 的角色很容易与平台工程师的角色混淆，因为他们都管理底层基础架构并支持软件开发团队。尽管所有这些角色之间存在某些重叠的职责，但每个角色都因其独特的重点而与其他角色不同。
平台工程与开发运营
DevOps 是一种理念，它为 SDLC 带来了文化转变，以提高软件交付速度和质量。DevOps 促进了开发和运营团队之间的协作和沟通，并加速了自动化以简化部署。平台工程 - 一种实践而不是一种哲学 - 可以被认为是DevOps的下一次迭代，因为它共享DevOps的一些核心原则：协作（与Ops），持续改进和自动化。
平台团队和DevOps的日常任务在某些方面是不同的。DevOps 使用某些工具和自动化来简化将代码投入生产、管理以及使用日志记录和监视工具观察代码的过程。他们主要致力于 构建有效的 CI/CD 管道。平台工程师采用DevOps使用的所有工具，并将它们集成到一个共享平台中，不同的IT团队可以在企业级使用该平台。这样，团队就无需自行配置和管理基础架构和工具，并节省了大量时间、精力和资源。平台工程师还可以创建文档并优化平台，以便开发人员可以在其工作流程中自助服务工具和基础架构。
只有在拥有许多不同 IT 团队使用复杂工具和基础架构的成熟公司中，才需要平台团队。当然，在这样的工程环境中，需要一个专门的平台团队来管理复杂性。平台团队构建和管理基础架构，帮助 DevOps 加快持续交付。但是，DevOps 团队在初创公司中执行平台工程任务（例如配置 Terraform）是很常见的。
平台工程与 SRE
站点可靠性工程师 （SRE） 专注于确保应用程序可靠、安全且始终可用。他们与开发人员和运营团队合作，创建支持交付高度可靠应用程序的系统或基础架构。SRE 还执行容量规划和基础架构扩展，并管理和响应事件，以便平台满足所需的服务级别目标 （SLO）。另一方面，平台工程管理复杂的基础设施，并为开发人员构建一个高效的平台来优化SDLC。虽然两者都在平台上工作，他们的角色听起来很相似，但他们的目标不同。
平台工程和 SRE 之间的主要区别在于他们面对谁并迎合他们的服务。SRE 面向最终用户，确保应用程序可靠且可供他们使用。平台工程师面对内部开发人员，并专注于改善其开发人员体验。两个团队的日常任务在这些目标方面有所不同。平台工程为快速应用程序交付提供了底层基础架构，而 SRE 也提供了同样的事情来交付高度可靠和可用的应用程序。SRE 更多地致力于故障排除和事件响应，平台工程师专注于复杂的基础架构和支持开发人员自助服务。
为了实现各自的目标，SRE 和平台团队在其工作流程中使用不同的工具。SRE 主要使用普罗米修斯或格拉法纳等监控和日志记录工具来实时检测异常并设置自动警报。平台团队使用跨越软件交付过程各个阶段的不同工具集，例如容器业务流程工具、CI/CD 管道工具和 IaC 工具。总而言之，SRE 和平台团队致力于构建可靠且可扩展的基础架构，其目标不同，但他们使用的工具之间存在一些重叠。
如何在组织中实施 Platform 工程
在拥有少数工程师的初创公司中，平台团队不会是直接的需求。一旦组织发展到多个 IT 团队并开始处理复杂的工具和基础架构，理想的做法是让平台工程师来管理复杂性。
创建角色（工程主管/副总裁）
当开发人员花费更多时间配置工具和基础架构而不是交付业务逻辑时，像副总裁或工程主管这样的顶级工程师通常会创建平台工程师的角色。他们会发现大多数IT团队都在解决同样的问题，比如启动一个新环境，这滞后于交付过程。因此，工程主管将定义平台工程的范围，确定责任领域，并创建平台工程师/团队的角色。
创建内部开发人员平台（平台工程师/团队）
平台工程师首先构建组织中已使用的基础结构和工具的日志。然后，他们将采访开发人员并了解他们的挑战，并使用解决企业级问题的工具和服务构建内部开发人员平台。他们将以灵活的方式构建平台，并促进不同的架构和部署风格。平台工程师还创建文档并进行培训课程，以帮助开发人员自助服务平台。对于平台工程师来说，拥有开发人员背景是理想的选择，这样他们就知道成为开发人员的感觉并更好地了解挑战。
载入用户（应用程序开发人员）
平台准备就绪后，平台工程师将加入应用程序开发人员。这将需要内部营销，并让团队知道该平台及其可以解决的问题。吸引用户的最佳方式是将他们拉到平台上，而不是将平台扔给他们。这可以通过从一个小团队开始并帮助他们克服挑战来完成。例如，帮助小型团队优化 CI/CD 管道，并在此过程中提供最佳体验。早期采用者的口碑将在整个组织中产生积极的连锁反应，这将有助于将更多用户加入该平台。
平台工程并不止于用户入职。这是一个持续的过程，平台适应新兴工具和技术以及用户不断变化的需求和要求。
结论：使用开源工具进行平台工程
选择一个开源平台，为平台工程师提供标准化的工具链，帮助开发人员加速软件交付，这一点很重要。Devtron 就是这样一个平台，它通过自动化端到端 SDLC 的 CI/CD 平台、安全性和可观察性来帮助开发人员。
