IT运维的变迁：从综合网管到IT运营

IT运维的变迁：从综合网管到IT运营

二十多年前，综合网管代表着IT运维监控的最高水准。大型企业的IT部门都在为建设好全面的综合网管，构建起完备的监控体系而投入大量的资金。现在树立在各个企业大型运行监控中心的巨大的监控大屏就是那个时代留下的遗产。现在越来越多的企业都建立起了类似的大屏，大屏上也显示着丰富的数据，不过坐在大厅里的人都不会盯着这块大屏，而是看着自己桌上的一个小屏幕。如果你去参观这些监控中心的时候留意一下那些似乎十分认真的盯着自己眼前的那个小屏幕的监控人员的时候，你可能会发现，他们实际上并没有在使用这些监控数据，而只是装模作样的盯着而已。因为这些数据对他们来说是没有啥用处的。也许几分钟前看上去数据还十分正常，几分钟后，系统就宕机了。

实际上，综合网管时代要解决的问题是，当IT系统出问题了，我们能够知道问题大致出在什么地方。是网络还是应用还是中间件数据库。只要能够在系统出现问题后，短时间内能够找出这个问题点，综合网管就算完成其使命了。所以平时盯着屏幕看监控数据是没有太大的意义的。

而实际上，综合网管的作用绝对不仅限于此，IT部门对于综合网管的需求也不仅限于此。监控的目的也不仅仅是当系统出问题的时候能够快速做大致的定位，而是希望能够提前感知故障的存在，并且在故障未发生之前消除于无形。似乎综合网管也能够完成这个使命，介绍防患于未然的时候，我们总能举出一个空间使用率的例子来说明这套机制是如何运作的。不过似乎我们也只能举出一个空间使用率的例子了，其他例子都不太好举。如果举CPU使用率的例子，那似乎太复杂了，CPU使用率突然变高有可能是正常现象，也有可能是异常。即使是异常，也有无数种可能性，其中可能99%的可能性都是无害的，不需要去做跟踪分析。因此基于综合网管架构的闭环管理实际上在现今的IT运维场景中，似乎有些不太适用了。

随着信息技术的发展，我们能够感知与发现异常的能力大大提高了，但是这种感知异常的能力并不能直接给我们的运维能力提升，风险防范能力的提升带来任何的好处。2006年，我和HP的一个ITIL咨询团队给平安保险科技部做业务连续性与容量管理的IT咨询的时候，他们谈到了对问题的闭环管理。他们要求对于核心业务系统数据库的任何一个异常都需要在一周内实现闭环分析。这个工作让他们避免了80%以上的隐患成为故障。当时这是一个十分先进的IT运维理念，不过放到现在来看，如果面对现今爆炸式发展后的信息系统规模来说，这种运维管理方式就太奢侈了。为了在当时的核心系统上实现闭环管理，平安保险付出了大量的二线和三线人力资源。面对现在扩到数十倍数量的核心业务，再采用这种闭环管理的模式，连财大气粗的平安科技恐怕也投不起了。

事实上，这种基于简单的指标采集后，通过各种基线告警构建告警体系的综合网管系统，在现在的新的IT运维需求下，已经显得力不从心了。每天成千上万的告警如果都去做闭环管理，则IT部门无法承担其成本。如果对这些告警置之不理，那么一旦出现故障，IT部门没有及时发现，则又要承担巨大的责任。IT部门该如何适应新形势下的运维需求呢？有人说，重点看护好几个核心系统，让他们不出问题就行了。这句话似乎有道理，不过哪些算是核心系统呢？随着信息系统对业务的支撑作用的不断提升，你又能说哪个业务系统是核心系统呢？几年前有一次我在西部旅行时被一个电话中断旅行，回到北京去分析一次IT故障。到了北京后才发现要分析的是电子邮件系统的一次30多分钟的中断事故。当时我就觉得特别奇怪，邮件系统以前不是经常出现类似的故障，大不了就换个邮箱，为啥非得这么严肃的做问题诊断呢？后来得知，是因为公司老大要给部委领导发一个十分重要的电子邮件，正好赶上邮件系统故障，最后为了不让领导的领导等太久，就只好用外部邮箱发了。没想到一个小小的邮件系统，也会成为最为关键的系统，以后企业邮箱成为了企业核心系统中的一员。记得那次分析会上，有个专家说了一句意味深长的话：“以前总以为只有对外服务的系统才是核心系统，现在看来，只要领导用得上的系统都得列入核心系统范围”。实际上，对于任何一个业务部门使用得系统，对于这个部门来说，都是核心业务系统，一旦出现故障，会影响这个部门的业务。在现在的IT运维来说，“核心系统”的概念已经被泛化了。

在这种新的形势下，IT运营成为解决这个问题的必然。某个告警是不是要闭环管理，哪些系统的告警要做闭环管理，如何更为低成本的实现闭环管理，其逻辑的基础是运营，是成本的有效性与合理性。在数据中心规模数十倍上百倍扩大的今天，IT系统和设备已经不是三十年前信息化刚刚开始时的那个珍稀动物大熊猫了，为一台计算机建一个数据中心大楼的事情也不会再发生了。IT运维也应该从成本效益考虑，才能够在有限的经费下实现更高的运营质量。随着云平台、为应用、人工智能的发展，实际上我们也应该对IT运维换换脑筋了。信息系统可用性保障与运营成本应该从两方面去考虑，一方面通过新的技术来尽可能提升信息系统的主动可用性保障，另外一方面是通过新技术降低可用性保障的成本。有些系统完全可以使用云平台的高可用保障机制来保障SLA，没必要采用以前那种既昂贵又无法确保SLA的传统架构。比如一个业务部门的系统日常运行负载并不高，数据库的数据量也不是很大。业务部门也能够承受偶尔出现的30分钟内的系统不可用，但是要确保7*24小时这个系统都是随时可用的。针对这个需求，以前大多数比较有钱的企业都是用两台2路服务器搭一个RAC来部署这个数据库系统。这个系统的一次性建设投入大概是两台服务器大约10万元，一套RAC系统大概200万元。这个系统投入还是相当大的，不过如果数据库本身出了问题，那么这套系统就只能通过备份恢复的方式来恢复数据，大约需要10小时左右的恢复时间，或者从异地灾备系统将数据取回来，大约需要一天以上的时间。因为这套系统不是最为关键的核心业务系统，因此是没有建设应用级灾备的，只有数据级灾备，异地灾备只能恢复数据，无法恢复业务。如果把这套数据库上云，只需要开两个云主机来运行这套系统，RAC是没必要的，两个云主机之间搭一个DATAGUARD就行了（不需要只读DG，因此不需要ADG，只需要最简单的不收费的DG），这样的话，Oracle许可证费用可用减少到48万，云主机的成本也不需要10万元了。而且当云主机出现故障的时候，通过云主机的自动恢复可以恢复数据库运行，如果云平台无法恢复这个数据库的运行，在10分钟内启用DG接管也是十分容易的事情。钱花的少了，可用性实际上并未下降，甚至还提升了。在IT运营的思维方式下，花小钱办大事是可以实现的。

IT要想运营的好，不仅仅是上面的一些花小钱办大事的小技巧，更多的是需要通过对信息系统运行状态与运行风险的分析，更为精准的投入运维资源到最需要的地方，更为精准的进行资源调度与资源扩容。让每一分IT投入都能有最大的收益。在几年前，我和一个IT主管交流的时候，他向我提出一个问题，让我帮助他考虑考虑。他说：“老白，你是DBA，你有没有考虑以前我们可以让一个运维人员盯着核心系统看，每5分钟对关键指标做一次检查，从而避免大故障的发生。现在我管着400多套数据库系统，加上DG，有超过1000个实例，我只有2个专职DBA，加上外包驻场的人也不过4个人，我怎么才能管好这些数据库呢？哪怕让这4个人都24小时不睡觉，也没法按照运维规范完成每天的监控与巡检工作啊。”

确实是这样的，盯着传统的网管数据看是不现实的，如果不盯着看屏幕，对各种告警做闭环管理也不现实，因为每天的日志告警与基线告警短信在万条以上，每个短信都仔细看一看的时间都没有。因此为了更好的支撑ITOM，必须充分利用运维大数据平台、人工智能平台的数据与分析能力，构建强大的深度分析能力，用智能化、自动化的手段进一步降低人力依赖，降低运维成本。

用运营的态度来对待信息系统的运行，将有限的资金用于最需要的地方，通过新技术来改造优化IT系统的部署架构，在保障SLA的基础上大幅降低IT系统运行的成本已经成为企业数字化转型工作中的十分重要的工作。如果不把这步棋走好，企业数字化转型的成本会成倍的增加，效率也会大大降低。

今天似乎又开启了一个无比庞大的话题，写到这里已经快9点了，今天只能先聊到这里，感觉这个问题还是没有聊透，以后再就这里提到的一些话题，做单独的分析吧。