4）监控对象的梳理

依据监控的目的和目标，明确需要监控的IT组件将变得非常清晰。此时，梳理监控对象成为必要步骤。通常，"基于应用监控对象梳理"是常用的方法。基于应用系统的监控对象梳理的优势体现在：

·以用户体验为核心：在任何IT服务中，用户体验都是关键的考量因素。从应用系统的视角出发，可以更直接地理解用户的需求和体验，从而将监控的焦点集中在对用户体验影响最大的IT组件上。

·确定监控指标和阈值：通过理解应用系统的工作机制和依赖关系，可以确定各个IT组件的监控指标和阈值。这可以确保监控活动的有效性，并可以在可能影响应用系统性能的问题发生之前发出预警。

·避免遗漏关键IT组件：应用系统通常需要多个IT组件协同工作才能正常运行。通过对应用系统的全面梳理，可以确保所有关键IT组件都被纳入监控范围，从而避免因遗漏某个组件而导致的监控盲区。

·理解IT组件的价值：通过理解应用系统对各个IT组件的依赖关系，可以更深入地理解每个IT组件对整个系统的价值。这有助于确定各个组件的优先级，并在资源有限的情况下优化资源的分配。

表：基于应用系统的监控对象梳理

系统名称	域名	IP地址	使用用户	关键业务功能 （用户视角）	可用性要求	延迟要求	吞吐量要求	系统优先级排序 （降序）

5）监控对象优先级定义

监控对象的数量可能非常多，需要通过优先级的方式来定义优先执行监控的对象。对于监控对象优先级的定义通常采用多维度量化评分法。具体量表如下：

表：监控对象优先级评估表

纬度	评分标准
业务价值	高（3）	中（2）	低（1）
服务依赖复杂度	复杂（3）	中等（2）	简单（1）
可 用性目标	99.99%（3）	99.9%（2）	99%（1）
历史异常	严重（3）	普通（2）	轻微（1）

·得分与优先级说明：

总分>=8，优先级最高；总分4-7，优先级中；

总分<=3，优先级最低。·评估纬度说明：

·业务价值评估。明确服务对业务的重要性，需从其对业务收入的贡献度、用户规模、业务连续性等维度进行综合评估。服务价值越高，其优先级亦相应提升。

·服务依赖性分析。需深入分析服务的上游与下游依赖关系，上游与下游服务的稳定性及可用性将直接影响服务的性能。依赖关系的复杂性越高，服务的优先级亦应越高。

·服务可用性目标考量。不同服务的可用性目标存在差异，对可用性要求更高的服务应赋予更高的优先级。此优先级的确定需依据业务连续性及容灾需求。

·历史异常与中断情况回顾。审视服务在过往一段时间内的异常事件及服务中断记录，异常与中断频次越高，对服务优先级的影响越大。

6）服务健康模型定义

·服务健康模型：该模型反映服务中关键事件及其相互关系。单一服务可能对应多个健康模型。服务健康模型可借助报告或仪表板形式展现，以呈现服务的健康状况和性能指标，供服务所有者、参与团队及其他利益相关者按需查阅。

·服务健康模型功能：服务健康模型使监控团队能够评估服务的用户体验。例如，可构建一个模型来测量从移动应用发起请求，经过所有数据库系统，直至在移动应用中确认交易完成的整个过程所需时间。此方式确保服务相关信息能被利益相关者主动获取。

·服务健康模型构建方法：服务健康模型基于参与服务设计团队的输入构建。例如，可依据客户交易流程构建模型，以反映从移动应用发起请求，经过所有数据库系统，直至在移动应用中确认交易完成的整个过程。

服务健康模型通常由以下主要部分构成：

1.服务事态：涵盖所有可能影响服务运行的事态，如硬件故障、软件错误、网络问题等。

2.服务连接：反映服务中各事件间的相互关系及依赖性。例如，应用程序请求可能需通过多个数据库系统才能完成。

3.服务性能指标：包括各种反映服务运行效率和效能的数据，如响应时间、失败率、服务利用率等。

4.用户体验指标：包括反映服务对用户体验影响的数据，如满意度评分、用户错误报告数量、用户交易完成时间等。

5.报告与仪表板：通常提供服务健康和性能的可视化展示，使服务所有者及其他相关团队能迅速掌握服务的当前状态和历史性能。

需注意，服务健康模型的具体构成要素可能因服务的特定需求和特性而异。总体而言，服务健康模型应提供充足信息以助于理解服务运行状态，并在问题发生时能迅速定位及解决。

通常可以使用下表梳理“服务监控模型”

表：服务健康模型梳理表

系统名称：
说明：关键业务功能和系统服务映射（针对某个系统）
关键业务功能	服务名称	服务描述	指标类型	监控指标	指标说明
			可用性
			请求时延
			吞吐量
			错误率

10）流程衡量指标

表：监控和事态管理流程衡量指标

序号	CSF（关键成功要素）	KPI（关键绩效指标）	指标计算	指标说明
1	建立和维护用于描述各种事态及其检测所需监控能力的方法/模型	利益相关者对监控和事件管理方法的满意度	满意度评分平均值（例如，通过调查问卷收 集）	这个指标评估了利益相关者对监控和事件管理方法的满意程度。高满意度表明利益相关者认为这种方法有效并满足他们的需求。满意度评分可以通过定期进行满意度调查获得。这个指标的价值在于它提供了对方法效果的直接反馈，可以用来改进和优化方法。
2		组织对方法的坚持程度	（遵循方法的事件数/总事件数）*100%	这个指标评估了组织在实际操作中对监控和事件管理方法的坚持程度。高比例意味着组织在大多数情况下都遵循了方法。这个指标的价值在于它显示了方法在实际操作中的应用程度，并可以揭示任何偏离方法的趋势。
3		不遵循或被认为不切实际的方法建议/要求的百分比	不遵循或被认为不切实际的建议/要求数/总建议/要求数）*100%	这个指标度量了方法的建议/要求被忽视或被认为不实际的频率。高百分比可能表明方法有不适用或不切实际的部分。这个指标的价值在于它可以帮助识别方法中可能需要修改或改进的部分。
4	确保及时、相关且充足的监控数据对相关利益相关者可用	利益相关者对监控数据及其展示的满意度	（对监控数据及其展示满意的利益相关者数量/总利益相关者数量）x100%	这个指标用于衡量利益相关者对监控数据和其展示方式的满意度。高满意度通常意味着监控数据符合利益相关者的需求并以易于理解的方式呈现，这对于确保信息的有效传递和决策的准确性至关重要
5		监控数据的质量（按照约定的数据质量标准）	（达到数据质量标准的监控数据数量/总监控数据数量）x100%	这个指标用于衡量监控数据的质量。高质量的监控数据可以确保数据的准确性和可靠性，从而提供有效的决策支持和操作洞察。在评估数据质量时，可能会考虑准确性、完整性、一致性和时效性等因素。
6	确保事态能够被尽快检测到、准确解释，并在必要时迅速采取行动。	事态错误的影响	错误事态数/总事态信息数*100%	这个指标用于衡量监控事态管理错误告警，对整个系统产生的影响。当这个比例越高时，说明监控和事态管理的错误越多，没有能够及时发现潜在影响，而带来系统的不稳定甚至故障。
7		事态信息 “噪声”的数量和影响	噪声事态数/总事件数*100%	这个指标用于衡量无效或不重要的事态新（即“噪声”）对系统的影响。如果“噪声”事态的比例过高，那么这可能会分散IT团队的注意力，使他们无法集中精力处理真正重要的问题，从而降低整个系统的运行效率。
8		由于无效的监控和事态管理而无法预防或解决的事件和问题的影响	（未预防的问题数+未解决的问题数）/总问题数*100%	这个指标用于衡量由于无效的监控和事态管理导致的无法预防或解决的问题对系统的影响。如果这个比例过高，那么说明事态管理的效果很差，可能会导致大量的问题无法得到有效的处理，从而对系统的稳定性和可靠性产生严重的影响。

参考数字化IT运维管理体系建设指南等书籍资料

4）监控对象的梳理

依据监控的目的和目标，明确需要监控的IT组件将变得非常清晰。此时，梳理监控对象成为必要步骤。通常，"基于应用监控对象梳理"是常用的方法。基于应用系统的监控对象梳理的优势体现在：

·以用户体验为核心：在任何IT服务中，用户体验都是关键的考量因素。从应用系统的视角出发，可以更直接地理解用户的需求和体验，从而将监控的焦点集中在对用户体验影响最大的IT组件上。

·确定监控指标和阈值：通过理解应用系统的工作机制和依赖关系，可以确定各个IT组件的监控指标和阈值。这可以确保监控活动的有效性，并可以在可能影响应用系统性能的问题发生之前发出预警。

·避免遗漏关键IT组件：应用系统通常需要多个IT组件协同工作才能正常运行。通过对应用系统的全面梳理，可以确保所有关键IT组件都被纳入监控范围，从而避免因遗漏某个组件而导致的监控盲区。

·理解IT组件的价值：通过理解应用系统对各个IT组件的依赖关系，可以更深入地理解每个IT组件对整个系统的价值。这有助于确定各个组件的优先级，并在资源有限的情况下优化资源的分配。

表：基于应用系统的监控对象梳理

系统名称	域名	IP地址	使用用户	关键业务功能 （用户视角）	可用性要求	延迟要求	吞吐量要求	系统优先级排序 （降序）

5）监控对象优先级定义

监控对象的数量可能非常多，需要通过优先级的方式来定义优先执行监控的对象。对于监控对象优先级的定义通常采用多维度量化评分法。具体量表如下：

表：监控对象优先级评估表

纬度	评分标准
业务价值	高（3）	中（2）	低（1）
服务依赖复杂度	复杂（3）	中等（2）	简单（1）
可 用性目标	99.99%（3）	99.9%（2）	99%（1）
历史异常	严重（3）	普通（2）	轻微（1）

·得分与优先级说明：

总分>=8，优先级最高；总分4-7，优先级中；

总分<=3，优先级最低。·评估纬度说明：

·业务价值评估。明确服务对业务的重要性，需从其对业务收入的贡献度、用户规模、业务连续性等维度进行综合评估。服务价值越高，其优先级亦相应提升。

·服务依赖性分析。需深入分析服务的上游与下游依赖关系，上游与下游服务的稳定性及可用性将直接影响服务的性能。依赖关系的复杂性越高，服务的优先级亦应越高。

·服务可用性目标考量。不同服务的可用性目标存在差异，对可用性要求更高的服务应赋予更高的优先级。此优先级的确定需依据业务连续性及容灾需求。

·历史异常与中断情况回顾。审视服务在过往一段时间内的异常事件及服务中断记录，异常与中断频次越高，对服务优先级的影响越大。

6）服务健康模型定义

·服务健康模型：该模型反映服务中关键事件及其相互关系。单一服务可能对应多个健康模型。服务健康模型可借助报告或仪表板形式展现，以呈现服务的健康状况和性能指标，供服务所有者、参与团队及其他利益相关者按需查阅。

·服务健康模型功能：服务健康模型使监控团队能够评估服务的用户体验。例如，可构建一个模型来测量从移动应用发起请求，经过所有数据库系统，直至在移动应用中确认交易完成的整个过程所需时间。此方式确保服务相关信息能被利益相关者主动获取。

·服务健康模型构建方法：服务健康模型基于参与服务设计团队的输入构建。例如，可依据客户交易流程构建模型，以反映从移动应用发起请求，经过所有数据库系统，直至在移动应用中确认交易完成的整个过程。

服务健康模型通常由以下主要部分构成：

1.服务事态：涵盖所有可能影响服务运行的事态，如硬件故障、软件错误、网络问题等。

2.服务连接：反映服务中各事件间的相互关系及依赖性。例如，应用程序请求可能需通过多个数据库系统才能完成。

3.服务性能指标：包括各种反映服务运行效率和效能的数据，如响应时间、失败率、服务利用率等。

4.用户体验指标：包括反映服务对用户体验影响的数据，如满意度评分、用户错误报告数量、用户交易完成时间等。

5.报告与仪表板：通常提供服务健康和性能的可视化展示，使服务所有者及其他相关团队能迅速掌握服务的当前状态和历史性能。

需注意，服务健康模型的具体构成要素可能因服务的特定需求和特性而异。总体而言，服务健康模型应提供充足信息以助于理解服务运行状态，并在问题发生时能迅速定位及解决。

通常可以使用下表梳理“服务监控模型”

表：服务健康模型梳理表

系统名称：
说明：关键业务功能和系统服务映射（针对某个系统）
关键业务功能	服务名称	服务描述	指标类型	监控指标	指标说明
			可用性
			请求时延
			吞吐量
			错误率

10）流程衡量指标

表：监控和事态管理流程衡量指标

序号	CSF（关键成功要素）	KPI（关键绩效指标）	指标计算	指标说明
1	建立和维护用于描述各种事态及其检测所需监控能力的方法/模型	利益相关者对监控和事件管理方法的满意度	满意度评分平均值（例如，通过调查问卷收 集）	这个指标评估了利益相关者对监控和事件管理方法的满意程度。高满意度表明利益相关者认为这种方法有效并满足他们的需求。满意度评分可以通过定期进行满意度调查获得。这个指标的价值在于它提供了对方法效果的直接反馈，可以用来改进和优化方法。
2		组织对方法的坚持程度	（遵循方法的事件数/总事件数）*100%	这个指标评估了组织在实际操作中对监控和事件管理方法的坚持程度。高比例意味着组织在大多数情况下都遵循了方法。这个指标的价值在于它显示了方法在实际操作中的应用程度，并可以揭示任何偏离方法的趋势。
3		不遵循或被认为不切实际的方法建议/要求的百分比	不遵循或被认为不切实际的建议/要求数/总建议/要求数）*100%	这个指标度量了方法的建议/要求被忽视或被认为不实际的频率。高百分比可能表明方法有不适用或不切实际的部分。这个指标的价值在于它可以帮助识别方法中可能需要修改或改进的部分。
4	确保及时、相关且充足的监控数据对相关利益相关者可用	利益相关者对监控数据及其展示的满意度	（对监控数据及其展示满意的利益相关者数量/总利益相关者数量）x100%	这个指标用于衡量利益相关者对监控数据和其展示方式的满意度。高满意度通常意味着监控数据符合利益相关者的需求并以易于理解的方式呈现，这对于确保信息的有效传递和决策的准确性至关重要
5		监控数据的质量（按照约定的数据质量标准）	（达到数据质量标准的监控数据数量/总监控数据数量）x100%	这个指标用于衡量监控数据的质量。高质量的监控数据可以确保数据的准确性和可靠性，从而提供有效的决策支持和操作洞察。在评估数据质量时，可能会考虑准确性、完整性、一致性和时效性等因素。
6	确保事态能够被尽快检测到、准确解释，并在必要时迅速采取行动。	事态错误的影响	错误事态数/总事态信息数*100%	这个指标用于衡量监控事态管理错误告警，对整个系统产生的影响。当这个比例越高时，说明监控和事态管理的错误越多，没有能够及时发现潜在影响，而带来系统的不稳定甚至故障。
7		事态信息 “噪声”的数量和影响	噪声事态数/总事件数*100%	这个指标用于衡量无效或不重要的事态新（即“噪声”）对系统的影响。如果“噪声”事态的比例过高，那么这可能会分散IT团队的注意力，使他们无法集中精力处理真正重要的问题，从而降低整个系统的运行效率。
8		由于无效的监控和事态管理而无法预防或解决的事件和问题的影响	（未预防的问题数+未解决的问题数）/总问题数*100%	这个指标用于衡量由于无效的监控和事态管理导致的无法预防或解决的问题对系统的影响。如果这个比例过高，那么说明事态管理的效果很差，可能会导致大量的问题无法得到有效的处理，从而对系统的稳定性和可靠性产生严重的影响。

参考数字化IT运维管理体系建设指南等书籍资料