在我的整个工作中，我定期观察在公司中实施监视未带来预期结果的情况。 监视效果不佳或根本不起作用。 通过分析这种情况，我意识到它们的原因几乎总是相同的。 尽管它们都是表面上的，但我一直都在与他们会面，因此决定将它们放在一起，以便对您进行警告和武装。
1. 不要实施监视工具
如果IT部门仅接收监视工具，则其自身将不会产生有效且相关的监视。 与其引入监视系统，不如尝试将监视IT基础结构创建为
流程组织。
监视过程是什么意思？
监视过程是人力资源，技术手段和组织措施的结合，旨在解决公司在IT基础架构运行过程中要监视的任务。 我尤其要指出，此定义中的人员和规则并非同等重要，而不仅仅是技术手段。
这是我曾经参与的监视项目名称的一些典型示例。 在大多数情况下，项目的名称准确反映了客户希望获得的结果：
- 实施企业电信网络管理和操作系统
- 创建一个IT基础架构监视系统
- 控制系统的开发和Internet电路的运行
- OJSC交换设备监控系统的实现
- 建立信息技术管理系统
- 创建用于IT基础架构的管理和监视系统的软硬件复合体
公司专注于技术，通常会牺牲其他两个组成部分-人力资源和组织措施。 结果，该工具出现了，但是对
谁以及
如何使用此工具却没有一个清晰的了解。
自然地，在任何程度的监控系统实施项目中，都存在榜样和随附的文档。 但是通常，该文档是正式的，不能帮助IT部门回答在使用系统时出现的问题。
2.集成商不会为您完成所有工作
通常，对于与监视相关的项目，大中型公司会吸引集成商公司的专家。 在检查基础结构的过程中，集成商依靠
他们的知识和解决问题
的经验。 但这远不是公司真正需要的。 没有人比公司的专家更了解与IT基础架构的运营相关的复杂问题。
因此，我建议在
确定第三方承包商之前，通过监视独立
确定公司要解决
的问题 。 例如：
- 虚拟基础架构上的负载分配不均；
- IT基础架构中的大量事故；
- 通过执行简单的任务来高度吸引高素质的专家；
- 公司服务的可用性低；
- 第一行有大量呼叫；
- 从事故发生到发现的时间很长；
- 需要优化系统管理员的工作；
- IT基础架构的生产力低下；
- 缺乏有关IT基础架构资源的可靠数据；
- 缺乏事故预防工具。
即使在监视的早期阶段，
修复将量化问题的
指标并收集有关这些指标的统计信息也将非常有用。 因此，在组织监视过程之前，我们将收到有关IT基础架构功能状态的信息。 在实施监控之后，我们可以控制组织如何影响这些指标的变化。 此类指标的示例是：
- 报告期内记录的平均事件数；
- 关键服务的平均停机时间；
- IT基础架构的平均可用性百分比；
- 基础设施利用率的平均百分比；
- 报告期内第一行的呼叫次数；
- 从事件发生到发现的平均时间；
将制定出更好的指标来表征运营IT基础架构的主要问题，在监控过程中将获得更大的改进。 这些指标的不断计算应该是该过程的组成部分。 必须以一定的频率修改公式以进行计算。 因此，您可以及时响应IT基础架构的发展变化，其定性和定量组成。 在评估IT基础架构支持部门的绩效时，建议将这些指标用作KPI。
3. 不要混淆IT基础架构的监视和管理
熟练的专业人员是有效监控过程的三个关键组成部分之一。 有时，为了节省资金，尤其是在实施过程中，公司会尝试
将监视系统的支持和开发委托给参与IT基础架构操作的
系统管理员 。 但是，如果您选择一个单独的结构（专家）来支持监视，则将大大提高服务质量。 监视将是针对这些员工的
主要而非次要活动，因此他们将对其活动的成功和相关性更加感兴趣。
监视单位（专家）的职责应包括以下职能：
- 管理复杂的监控系统；
- 创建新的监控指标；
- 调整监测阈值；
- 开发新的监测工具；
- 执行用户请求；
- 报告；
- 整个IT监控流程的开发。
即使几个IT部门将共同参与配置监视，您仍然
需要拥有一个单独的结构-一个与监视相关的专业知识中心 。 这将有助于防止重复劳动成本，并迅速解决在共同管理时迟早会出现的任何冲突情况。
4. 不要期望自己的下属使用监视。
碰巧，负责人开始在公司中实施监控，给出必要的指示，分配资金，与集成商达成协议，从而完成了监控工作。 而且，徒劳无益的是，为了使监视有效，它必须在公司层次结构的所有级别都以一种或另一种形式出现。 一旦经理开始使用监视服务，它将自动成为其所有下属的必备条件。
5. 不要强迫员工使用监控系统
早晚要完成监视系统的实施，并开始运行。 有时会伴随着命令：所有IT部门开始使用系统。 通常，直接胁迫不会带来积极的结果。 可以实现的最大数量是最小必要数量的正式执行。
如果能帮助每个部门解决问题，将得到积极的监督。 如果IT运营部门未开始使用监视，则可能表明监视实施目标设置不正确。 或者说实施的目标与IT部门的目标不一致。
鼓励公司部门使用监视结果，但不强迫他们这样做。 这种动机的一个不错的选择是基于度量来为每个单位创建关键指标，这些指标以定量的方式描述运营IT基础架构的问题。 我在上面给出了他们的例子。
6. 不要在测试过程中专注于测试监视系统的功能。
开发监视系统后，先对其进行测试，然后进行试运行。 在这里，我们的下一个“非”意义重大。 从某种程度上讲，我在每个项目中都遇到了这个问题。
如果监视工具的实施是由第三方组织执行的，则重要的是，公司的专家应在验收测试和试运行阶段积极参与系统测试方法的形成。 在测试过程中，有必要精确地专注于
该工具是否确实有助于实现监控目标 。
以下是在最终测试中使用指标的一些示例：
- 优化IT基础架构的利用率。 根据监视系统的报告，可以就IT基础架构的最佳处置和更合理的分配做出明确而积极的决定。
- 减少IT基础架构中的事故数量。 监视IT基础结构应提供尽可能多的正确信号和尽可能少的错误信号。 您可以通过收集有关来自监视系统的信号百分比的统计信息来验证这一点，这些信号确实报告了IT基础架构组件的紧急状态，并已做出反应以消除事故原因。
- 通过执行简单的任务来减轻高素质专家的负担。 检查系统中内置的角色模型的完整性和详细性，以及有关公司结构部门的信息填充的完整性，并在系统提供警报的情况下分析上报警报的规则。 确定到达目标接收者的信号百分比并将此值与目标指标进行比较也将很有用。
- 改善公司服务的可用性 。 监视系统定义的公司服务可访问性指标与报告期的实际可访问性指标的比较，这些指标由替代方法确定。 这还包括检查用于确定公司服务的可用性的指标列表的完整性和详细信息，这些指标的阈值以及为目标公司服务支持组设置警报。
- 验证外部承包商提供的IT服务的质量 。 验证所提供服务的监视指标是否最大程度地覆盖了与外部承包商签署的SLA中的参数。 根据他们的数据，我们可以清楚地说承包商正在满足SLA条件。
- IT基础结构清单。 检查监测系统收集的清单信息的完整性及其是否符合清单的要求和目标； 检查监控系统发布的库存报告的质量和易用性。
- 主动的事故警告。 在开始使用监测系统之前和投入试用后，报告期间的事故数量统计数据的比较； 将这些值与目标进行比较。
一方面，要对此进行验证非常困难-您需要首先确定计算这些指标的方法，然后再累积有关它们的统计信息。 但是，另一方面，这些度量标准不仅可以用于监视测试过程，而且还可以在将来涉及运营的IT部门的激励系统中确定下来。
仅检查基本功能（例如，在交换机发生电源故障时监视系统中的警报的出现）并不能使系统完全能够应付其任务。 这样的检查只会显示系统基本正常。
7.直到您开始使用它并使之适应您的需求，监视才开始变得有益。
这个“不是”是指在完成实施之后系统的操作阶段。 非常重要的一点是要了解，如果没有适当构建的监视过程及其更新，系统中的数据将在实现完成后立即变得过时。
在调试时，应尽可能解决所有与系统维护和监视功能，使用规则以及职责和支持分工有关的组织问题。 还应定义解决操作过程中出现的问题的规则和程序。 缺少这些规则是监视工作停止并在工作的活动阶段完成后积分器开始下降的主要原因。
最后，在监视系统开始商业运营之前，应制定法规，以制定监视过程中的基本工作规则：
- 谁以及如何使用该系统；
- 谁负责使系统保持最新状态；
- 谁有权调整阈值度量值；
- 如何创建新指标；
- 在这种情况下，应创建新的指标；
- 创建新指标需要多长时间；
- 如果监控系统记录到事故应该怎么办；
- 谁以及如何应对这一事故；
- 谁负责监视系统的功能；
- 如何解决与错误或缺乏正确信号的出现有关的冲突。
结论
我真的希望阅读完我的文章后，您不会发现与公司所发生的情况类似的情况。 如果您的公司刚刚开始进行监控，我认为，这七个主要方面的信息会导致实施监控过程中的错误，从而有助于您创建有效的流程，从而为IT基础架构的工作带来稳定性。