深度 | 运维4大痛点逐个击破之首：被动响应的尴尬

“门户怎么又访问不了？”

“打开一个页面10秒钟，要不要干活了？”

......

据不完全统计，普通高校信息化管理部门每季度要被动处理的宕机故障约为10起；在网络优化升级阶段或应用推广用户剧增阶段导致的事故多达30起。

如何减少故障，防患于未然？本文将探寻高校运维服务中最急迫的“被动式响应”问题，并寻求破解之道。

以上案例根据金智公司运维服务的真实事件改编。该案例中所述问题，基本没有哪所高校能幸免。我们可以发现：保证应用系统稳定与安全是运维工作的核心。

在新的应用环境下，要保障系统的可用与流畅尤为困难：

1、IT支撑学校核心业务，用户依赖加强

随着信息化应用的深化，IT系统往往支撑了教学过程、校务管理、师生日常服务等核心业务。服务对象也从几十上百人的职能部门，扩展到了上万师生用户，出现问题的影响面加大。

网络与终端的拓展，使得师生更倾向于选择手机、PAD等方式获取服务，而不再受到时间、空间的局限。因此，许多故障往往是在信息化工作者下班后出现或被发现的。

2、对比互联网级应用，师生愈加挑剔

移动互联网APP已成为师生日常工作生活的重要工具。每天浸淫在这些应用中，难免以“互联网级应用”的要求来审视校内服务，对访问速度、软件界面愈加挑剔。

3、学生吐槽不受控，信息办压力暴增

信息办常接到上级领导的电话，责问宕机后管理者不知情，却被学生发现。的确，师生是使用者，易发现问题；而信息化部门是建设者，并不会天天守着系统。

随着网络媒体的发展，师生用户的意见反馈渠道如未经有效的设立，意见未得以有效、快速解决，往往会诉诸于其他的方式，如到BBS、空间、微博、微信上去吐槽，或直接反馈给校领导，导致扩散面、影响力加强，信息化人员感觉压力倍增。应用越广泛、越深入，越是如此。

（学生微博吐槽）

业界也有些运行监控系统，可实现对学校的各类底层环境的检测和预警，但其检测对象基本锁定在主机、存储等底层硬件环境，难以定位到具体的业务系统。

通过此类监控系统，信息办人员只能发现底层硬件或网络报警了，却不知道是哪一个应用系统出现了问题，更不知道出现问题之后将影响到多少用户、哪些用户的使用，同时也无法预知故障的恢复耗时。

（典型检测系统界面图）

究其根本原因：应用系统架构越来越复杂，硬件厂商不了解上层的应用的部署情况，管理信息系统又是由多家提供、分期上线，谁也搞不清楚应用与底层环境之间的关联关系。

而信息办管理人员角度出发，他们最关注的无非是：已投入运行的系统有哪些？每个系的可用性与流畅度如何？

在没有良好工具的情况下，绝大多数老师采用“纯手工”的方式，即学校信息化管理人员每天对所有核心业务系统的URL逐一访问。这种方式费时费力，还不能实时检测所有时段的问题，尤其是下班以后。

给力的工具，长啥样？何处寻？根据金智运维服务部的总结，高校信息化管理部门所需要的运行监控系统应立足校方信息办的诉求：

首先，系统应通过简单清晰的界面，对所有已上线应用系统进行集中呈现，直观的提供给管理人员。

其次，对两类系统进行报警：一是不可用或不流畅的系统进行提示；二是可能发生问题的系统或存在潜在风险的系统。

预警的前提是针对每个系统建立阈值报警体系。阈值是指每个系统可用性、流畅度、安全性的基础评估指标。凡低于或超过阈值，说明系统无法达到最低要求，则对该系统进行报警提示。

第三，对于上述系统，可下钻以查看到系统所关联的主机、存储、数据库，并对问题或风险发生的具体服务进行展开和提示。

综上所述，运行监控系统应建立应用系统与IT资源之间的关联性，不应将目标集中在单个的主机、存储上，而是从应用入口，判断每个业务系统存在的风险和问题，在进行逐层深入的定位到具体的硬件设备，有针对性的为技术人员进行检查和故障修复提供信息。