一个IT运维管理平台的基本能力框架

前段时间，我分享了关于IT运维和业务连续性管理的一些思考和想法，并引申出IT运维也应该保持持续创新来创造并体现自身的价值，而不仅仅是做幕后的无名英雄。

从上一篇文章中，我们已经有了一个共识：IT运维管理的本质是业务连续性管理。这意味着IT运维管理这个产品是为业务连续性服务的，并不是为了运维而运维、为了监控而监控。为此，我们需要精准管理那些会影响业务连续性的因素。

我们先分析，IT运维管理平台要管理的对象有哪些。如下图所示：

从上图我们可以看到，要支撑最上层的各个业务不间断的连续运行，那么就需要保持SaaS层的各个业务应用系统不间断的运行，而业务应用系统的不间断运行依赖于PaaS层的平台软件的不间断运行，平台软件的不间断运行又依赖于IaaS层基础架构的不间断运行。这里的每一项对业务连续性的影响程度都不一样，有些会立马让业务中断，有些需要经过一段时间后才会让业务中断，有些会对整个IT架构、IT资产带来灾难性的覆灭，也有一些只是起到辅助管理、效率提升的作用。因此，我们需要从中识别出哪些因素会对业务连续性造成什么程度的影响，然后对其进行分类，根据分类制定相应的管理策略，并采取相应的监控措施。

上图显示了一个IT运维管理平台应该要管理的对象。那么，如果要对这些对象进行管理，这个步骤、流程是怎么样的？看下图：

这是一个大致的工作流程，第1、2步动作是一次性的；第3、4步动作在首次批量扫描资产后，一般情况下也不需要重复做，除非有新设备上架；需要重复执行的是第5-8步，这4个步骤会产生很多的任务，这些任务是否按照标准在执行、是否按照SLA要求完成，需要进行适当的管理，也就是IT服务管理（ITSM）；各类软硬件资产在持续的运行中会产生很多的日志，这些日志可以帮助工程师定位故障解决问题，也可以帮助工程师提前识别潜在的风险，还可以帮助工程师进行资源配置的优化调整等等，这些日志还是智能运维很重要的输入语料。

由此，我们可以推导出这个产品最起码应该具备以下能力：CMDB、日志管理、监控告警、运维管理、ITSM五大能力。

对这5个能力按照IT系统的逻辑架构进行梳理和重组，就能推导出这个产品框架性的功能架构。考虑到运维管理和ITSM的相关性很强，所以就合并到了一个大的模块下。增加了可视化大屏和信息推送两个用户触点，在做产品能力展示的时候，可视化大屏会更加的直观，而在实际的运维管理工作中，信息推送会更加的实用，因为谁也不会一天到晚盯着屏幕看，企业也不可能安排一个工程师专门去盯屏幕。

如果我们坚持“IT运维的本质是业务连续性管理”这个观点，那么，IT运维的焦点就是管理好风险和异常情况，其它正常的情况反而变成了运维的噪音。而一个健壮的IT架构，异常必然是少数的情况。这就要求IT运维产品在【纳管对象选择—>监控项目设置—>告警规则设置—>告警推送—>告警降噪】这整条链路要设计的非常精准，既不能把很多无用的告警信息推送给运维工程师，也不能让同一个告警信息（或相同根因的告警）频繁的推送给工程师，更不能让那些有用的告警信息甚至高等级的告警信息漏推送给运维工程师，否则都将会导致工程师无法及时发现和处理真正的风险和故障，最终导致业务停摆。

随着AI能力的发展，未来基于知识库和日志的智能运维能力将有望得到飞速的发展，很多问题都由系统自动化处理掉了，加上高可用、灾备方案的有效实施落地，在一个很理想的状态下，整个架构可能永远不会出现因为某个节点停机而导致业务停摆的情况，那个时候传统的IT运维将不再需要，IT运维人员也就能够彻底摆脱【无过便是功】的尴尬角色。