从 CMDB 到服务目录

为什么传统的 CMDB 不够用？

对于传统的企业内部的 ITIL 组织，或者传统的运维人员而言，CMDB 是用来提升 IT 资产管理效率的数据库，帮助跟踪 IT 资产和管理配置。这也决定了传统 CMDB 设计的视角是比较单纯的运维视角，从产品本身设计的目标是帮助运维人员的辅助性工具，而非生产力工具。

早期的这类工具只能承担数据的手工录入，查询和一些简单监控的功能，可以满足小规模的日常管理，但在组织 IT 资产快速增长时，往往出现数据和实际环境不一致的问题，也难以跟踪资产的变更历史。

随着虚拟化和上云，现代企业的基础设施变得更复杂，相继又出现了 Ansible/Saltstack 这样的工具，IT 资源的管理方式变成了代码。管理资产的方式不再是手工配置，手工录入，能够达成配置管理数据同步，也就是我们所说的基础设施即代码。

随着敏捷开发和 DevOps 运动的兴起，开发团队从单纯的成本中心转变成为核心的生产力团队，对外提供服务。企业的 IT 资产管理不仅包括基础设施，也包含了对服务的管理。基础设施即代码虽然解决了开发人员对于基础设施自主性管理的需求，但在服务能力和资源管理之间还缺乏一座沟通的桥梁。

作为完全自主的敏捷团队，需要从服务到资源进行端到端的管理，支撑这类管理活动的资产管理平台，也将成为敏捷组织运营的基础性生产力工具。

Spotify 在服务目录的实践

ITIL v3 中引入了服务目录，开始用业务角度描述服务，但使用人员仍然面向的是运维人员和管理者。虽然体系中也引入了所谓的服务生命周期管理，但由于开发角色的缺失，无法落地为真正的全生命周期管理的框架。

随着云原生的蓬勃发展，互联网企业作为践行敏捷的先锋，在服务全生命周期管理方面率先采取了变化。Spotify 的大规模敏捷模式在行业内已经为人所熟知，他们又是怎样管理服务目录的呢？最近 Spotify 开源了自己的服务目录管理平台 Backstage，可以深入了解他们是如何进行管理的。

服务目录的管理对象

领域

领域在企业架构中映射到独立的能力条线，企业的组织设计包含对应领域包含的人员和业务边界。领域在组织中是长期活跃的对象，当我们采用领域驱动设计时，限界上下文的确定可以帮助我们很好的定义系统的分工边界。

系统

系统将一系列的服务能力进行封装，对领域提供服务。它也包含了开发阶段的人力资源和计算资源，系统中的组件和资源通常由同一团队拥有，在系统的立项，开发，维护期间形成单独的核算单元，有着明确的投入和产出目标。

服务（API）

服务是系统对外能力开发的具体集合，系统暴露能力的方式必须使用 API，映射到云原生中的应用设计原则

组件

服务组件可以单独形成系统中的一类功能。系统开发时根据专业分工形成对应组件设计，组件的形态包括微服务，类库，文档，流水线等等

资源和过程

资源是运行服务组件的环境，包括完整的开发，测试，生产环境，也包含对应的监控和日志数据。开发过程中的各类活动可以从服务目录中进行管理。

服务目录的实现

看板和搜索

看板和搜索提供的能力包括: 服务和组件清单，基于领域的效能指标，技术方案升级指标

Backstage 内嵌了文档的规范，帮助开发者在组件代码库内完成技术文档的编制，不使用外部的知识库

监控和预测

基于系统和组件级别进行的服务质量指标和成本指标监控

整合 kubernetes 的能力，基于系统和组件级别进行的运行资源监控

自动化

Backstage 提供了组件模版，帮助开发者快速生成相关的脚手架，自动完成代码库和流水线和监控相关的初始化工作

资源的初始化配置可以通过同 Kubernetes 的集成，通过自定义插件进行自动化

插件机制

Backstage 良好的插件机制提供了丰富的插件生态，平台管理员可以从 Backstage 官网上获取自己适用的插件