本文翻译自 Internal Developer Platforms Are for DevOps too 。
当一切都在一个地方进行跟踪时，强大的软件目录可以让生活变得更加轻松。
平台工程的兴起正在改变 DevOps。 DevOps 的任务是创建内部开发人员门户以帮助其他人（主要是开发人员）使用服务。但这还不是全部。
我们发现，DevOps 本身会受益于内部开发人员门户，尤其是需要强大软件目录的 DevOps 团队。即使是从开发人员自助服务（开发人员使用的服务）开始的 DevOps 团队也会发现用于 DevOps 目的的软件目录的优势。让我们进一步探讨这个问题。
DevOps 如何跟踪分布式应用程序及其运行系统的状态？他们如何理解微服务发生了什么？他们如何知道每天有许多部署的环境发生了什么变化，或者了解这一切的成本是多少？
如果所有这些信息都存在于一个巨大的手动 csv 中，如果它是一个包含软件和基础设施数据的 git 文件，或者如果它存在于某个超级工程师的脑海中，那么你就有麻烦了。如果花费的时间太长，你也会遇到麻烦回答简单的问题，例如哪些 Kubernetes 集群在哪里运行，或者当前在生产中运行哪个微服务版本。
这种缺乏控制是促使 DevOps 和平台团队采用内部开发人员门户的原因，最初的重点是软件目录。但是，内部开发人员门户不应该是关于开发人员的——开发人员体验、可重用和抽象的开发人员自助服务元素吗？他们是。但是平台工程人员忽略了一个重要的用例：DevOps 的内部开发人员门户。
DevOps 可以从内部开发人员平台中受益匪浅，因为他们也需要一个地方来访问有关软件和基础架构的数据，从环境、部署、区域和云资源到微服务。尽管拥有许多 DevOps 工具，但他们不一定有能力将来自 git 提供商、CI/CD、不同云供应商等的所有数据整合在一起。
DevOps 需要一个单一的地方来查看更改和依赖关系以及手头的所有元数据，并能够说明所有成本。我们在 DevOps 组织中展示 Port 的平台到平台团队时几乎偶然发现了这一点。他们没有寻求简化开发人员的生活，而是专注于自己的生活，首先让 DevOps 的生活更美好，然后才希望让开发人员的体验更好。
一位行业资深人士告诉我，他们开发内部开发人员门户的主要原因是为了确保无论何时为开发人员启用自助服务，都会设置正确的黄金路径，并带有护栏（或辅助轮，具体取决于开发人员和团队）。他们知道他们不能指望开发人员编写符合其 DevOps 标准的 Terraform 文件。这意味着无论开发人员做什么——从微服务脚手架到第 2 天的行动或提供临时环境——他们都需要护栏。这是通过内部开发人员门户提供的，具有类似产品的自助服务界面，不仅减少了开发人员的认知负担，而且让 DevOps 的生活更美好——更少的问题单和更少的混乱。
“开发人员的要求让我们发疯，”他告诉我。
有趣的是，如果设置护栏是开发人员门户的全部内容，那么记分卡（或 Spotify 的 Backstage 称之为“试音”）会事后反映这些要求是否得到满足。记分卡很重要，但涵盖所有自助服务操作并提前为每个操作设置护栏才是真正使平台工程工作取得成功的因素。
这听起来很奇怪，但是许多提供部分“目录”的工具——想想容器编排工具——显示跨一个元素的数据，比如一个集群，而不是很多集群，有时几个集群正是 DevOps 希望看到的，因为他们管理不止一个。
正如我们在此处定义的那样，DevOps 需要访问尽可能广泛的软件目录：“软件目录是基础架构和部署在其上的软件的可见层。理想的软件目录应该显示围绕 SDLC [软件开发生命周期] 的整个生态系统：CI/CD 流、开发环境、数据管道、部署和所有云。”
我们已经看到 DevOps 无法跨区域查看所有 AWS Lambda 的情况（AWS 不提供跨区域视图）。有时 DevOps 需要查看所有正在运行的服务的所有部署。无法从 GitHub 获取此信息并查看不同存储库中所有服务的所有部署。这个清单还在继续。
例如，如果所有正在运行的服务不具有相同的运行时，则没有一个地方可以查看所有相关数据（例如，我无法在同一位置看到在 K8s 和 Lambda 上运行的所有正在运行的服务）。这也会发生在 DevOps 无法看到整个组织的所有 Argo CD 应用程序的情况下。
同样，DevOps 还需要查看内部开发人员门户附带的活动日志，以便他们可以查看谁在何时何地做了什么，尤其是当他们让开发人员可以使用服务时，以防出现问题或出于审计目的。
最好的部分是什么？开发人员将使用相同的软件目录，具有一定程度的抽象和访问控制，因此他们不会被不必要的数据淹没。
简而言之，世界变得越复杂，DevOps 也就越需要开发人员门户。
在这种情况下，我们讨论的是将开发人员门户用作机器驱动工作流的一部分。这个想法真的是一样的。它假定内部开发人员门户是组织中软件和基础设施的唯一真实来源，是微服务及其运行的所有资源和基础设施的实时反映。
在这种情况下，DevOps 使用内部开发人员门户来通知锁定服务的工作流、在未达到最低质量水平的情况下构建失败或在特定 TTL 后终止临时环境。他们还可以使用高成本作为终止的输入。
微服务的复杂性是最近开发者门户兴起的驱动力之一。微服务是模块化的代码单元，旨在供其他软件元素重用。软件包并没有什么不同，相关的安全漏洞是一个令人头疼的问题。市场上有很多解决这个问题的安全解决方案，但内部开发人员门户似乎提供了一个更好的解决方案，因为它们提供了包可见性、迁移和依赖管理，类似于软件目录为漂移问题提供的功能。
使用内部开发人员门户还有其他与安全相关的好处。事实上，所有自助服务操作和 DevOps 操作都在一个中心位置进行跟踪，并且有一个活动日志，这使得通过 SOC2 合规性变得更加容易。此外，如果发生安全事件，解决起来会更容易。
当然，要做到这一切，您需要一个良好的内部开发人员门户，以及一个强大的软件目录。在此处试用 Port 的免费版本。