关于CMDB数据运营的想法，区别于行业主要关注配置数据治理，我对CMDB数据运营的想法如下：CMDB的数据运营应站位在IT资产效能的数据运营，配置项是对IT资产的数字化描述，重点思考如何利用IT资产数据分析，赋能IT风险防范、软件交付、成本管理、IT治理。其中，对IT资产对象的容量评估是一项能够赋能IT风险防范与成本管理的切入点。

从工作机制看

容量评估是一项主动性的技术运营工 作，是为了评估、预测 系统、应用、平台软件、主机等IT资产对象最大的负载处理能力，或从资源成本消耗角度分析，以更好地 应对实际业务发展，配置IT资源。

在组织、流程、平台、场景的体系中，流程机制需要先行。企业里配套多种与容量管理相关的工作机制，比如： 常态化的系统、资源容量评估工作、新系统或重要变更涉及的技术评审、IT资产效能管理、立项环节的资源评估等工作机制。 容量评估的工作机制，可以是一项以容量管理为主要目的的流程机制，也可以将容量评估赋能现有某一项工作机制。在 常态化系统或业务容量评估中，可能涉及按系统重要性级别、类型制定评估频率，设置系统或系统承载业务的黄金指标、黄金指标的设计容量、容量评估涉及的数据加工与分析、分析问题的感知、制定相关优化工作决策、跟进优化工作的落实等工作流程。CMDB应该在系统上线与变更环节，登记系统、应用、功能的设计容量，运行过程中记录历史容量峰值等信息供指标策略消费，并将资产关系提供给容量评估决策。

从工作思路看

可以考虑分几点:一是明确目标，明确容量管理是为了性能管理、客户体验提升、业务连续性计划、成本优化、某项业务活动、预期的市场变化等。 二是明确容量是可度量的、容量是有依赖关系的、容量是有上限的、容量是可规划的。 三是数字化容量管理，围绕数字化感知、决策、执行的闭环推动容量管理。

在第二点中的几点中，所谓的容量可度量是指应将容量管理的落地转化为反映容量的指标与评价容量水平的基线上。容量的依赖关系是指容量通常由业务行为上的量的指标出发，影响了软件层面并发、空间、时延等方面的技术指标，再到资源层面的指标。容量的上限指容量的多少是应该在架构与研发环节设计、部署环节配置资源、变更准入环节的压力测试评估。容量的规划是指容量管理应该采用主动性的分析，并提前建立容量缩扩容、程序优化、链路优化等优化方案。

从评估类型看

不同资产的容量评估方法、目标不同。可以考虑分为 软件系统相关的、软件平台相关的、硬件及基础设施相关的评估类型。 软件系统指某个信息系统全局性的、部分重要业务的、运营活动的，或多个系统关联的容量管理。 软件平台相关的指数据库、中间件、应用平台等层面的容量管理。 硬件及基础设施相关的指计算资源、存储资源、网络等层面的容量管理。

从评估基线看

容量指标好不好，需要有参考值，即评估基线，包括： 设计容量、历史峰值、压力测试极限值、平均值、静态经验阀值、历史同比与环比值、历史动态基线等。

从指标的选择看

假设分为技术通用指标、技术运营、业务运营指标。

技术通用指标包括：与主机相关的CPU、内存、磁盘IO、存储空间、网卡流量，网络相关的带宽、网络吞吐量，以及数据库、中间件相关的技术指标。

技术运营指标主要与性能管理相关，比如关键功能/服务的时延、请求响应时长、最大请求时长、服务/接口调用次数、XXX率。

业务运营指标与交易系统相关的业务订单/交易量、请求数、在线用户数、请求时长，以及具体到业务系统的黄金指标。

通常来说，业务运营指标、技术运营指标、技术通用指标，会层层传递。比如业务订单量多了，服务流量会增加，引发并发量增加，需要更多的节点或占用更多的资源。

从评估对象看

可围绕CMDB的IT资产对象建立容量评估，比如：基础设施、关键设备、计算资源、存储资源、集群主机、平台软件、系统、业务、应用、模块、组件、接口等。

从场景工程设计看

打算针对上面的分解设计研发容量评估工具，初步看应该包括以下功能（有兴趣的朋友欢迎留言一起讨论下）：

1.指标管理功能。
由运维数据平台的指标中心负责容量与性能指标的生产。指标中心的指标数据来源于源端工具，其中技术通用性指标应基于企业统一监控系统负责供数，技术运营指标与业务运营指标则由偏业务层的APM、NPM、业务监控等工具。指标数据的采集、存储、计算、管理归运维数据平台负责，容量评估工具负责指标数据的消费。

容量管理工具能够获取指标中心的元数据，并根据容量评估内容（系统、平台软件、基础设施）设计指标分类管理。系统的容量评估的用户视角通常是以系统为单位，DBA的用户视角通常是数据库类型或数据库集群为单位。针对不同的视角获取指标后，应能在线获取指标数据，并进行在线的分析，以便评估是否将指标纳入容量管理主题的分析场景工具中。

2.策略管理功能。
在线化容量评估应能将专家经验式的容量管理线上化，策略管理是将容量评估方法数字化。策略是评估某个指标或某几个指标是否存在问题的评估方法。策略管理是针对容量评估指标设置容量不足、低效等视角的评估参考值。可以考虑支持用户配置上面提到的容量基线（比如 设计容量、历史峰值、压力测试极限值、平均值、静态经验阀值、历史同比与环比值、历史动态基线等）作为策略的数据评估算子。策略除了容量基线的评估算子外，还需要提供当触发策略后的动作，比如是在可视化层面的提示，还是触发消息推送信息、告警事件、风险事件、问题单、自动化缩扩容等流程。

3.评估管理功能。
从数据运营的“感知、决策、执行”的闭环看，指标与策略承担感知的作用，决策则由自动化策略与人工专家评估承担。所以，一次评估工作是否完成不是输出一份无状态的容量管理的报表或看板，而应该设计初始化/未评估、已评估的状态，即每一份容量评估报告需要触达到具体的容量管理用户，由用户根据容量报告的数据，作用自己的决策。当然，用户也可以将决策自动化，直接将容量问题转化为风险事件。**

另外，容量管理的评估应能够提供业务运营指标、技术运营指标、技术通用指标关联影响的辅助功能，能够在线的查看不同指标的影响关系，帮助用户更全面的分析容量问题，以及作用决策。

4.报告及看板管理功能。
报告或看板面向的是一个主题的容量管理。报告与看板的区别是，一份报告是一份评估模板，会在不同的时间切面产生某个时刻的快照数据，即一份报告有很多实例；看板的数据是在线数据，查看的是最新的容量信息。

一个主题的报告或看板需要整合多个容量指标数据，在工程角度，我觉得报告编排的对象应是策略，指标为策略结论提供原材料，根据策略结论可以提供单指标、多指标、关联指标的辅助支持。这样的话，就可以设计多个指标的容量评估，或建立多个指标之间的影响关系。