企业IT运维到底需要什么样的管理人员

除了规模最小的IT部门外，所有IT部门都往往划分各管理员所需的一套技能。毕竟，要聘请到高素质的网络管理员、服务器管理员和存储管理员本身够难的了，更不用说要物色到面对多项IT任务时都表现得游刃有余的候选者。

 

作为一条组织原则，划分“技能”确实可行：它不但明确了团队不同成员之间的职责，还确保了数据中心基础架构的每一个部分都得到应有的关注。

 

遗憾的是，技术却在往一个完全不同的方向发展。数据中心的技术变得日益融合、虚拟化。正如我在之前指出的那样，对存储方面一窍不通的网络管理员来说，日子越来越难过；对网络方面一窍不通的存储管理员来说，也是如此。

 

而且，这不是划分技能的方法存在的唯一缺点。划分技能的另一个副作用是，基础架构团队极少花心思去了解，从技术的角度来看，到底是什么让应用程序顺利运行。 

 

在大多数IT部门，每个关键任务应用程序都有各自专门的管理员。然而，这些成天围绕应用程序的管理员很少深入了解底层运行的基础架构，在设计、实施和支持方面需要依赖基础架构团队。反过来，基础架构团队也一般不大关注应用程序，需要依赖软件开发商才能弄清楚如何合理部署应用程序，以便该应用程序获得所需要的资源。

 

这条应用程序交付链从最终用户的工作站开始，经由网络，到达应用程序堆栈和服务器，再一路到达存储基础架构；这条交付链有多可靠多健壮，完全取决于最薄弱的那个环节。最薄弱的那个环节十有八九出现在应用程序团队与基础架构团队之间（要是没有一位技能娴熟的DBA，更是如此）。 

 

真实教训

 

要明白这个问题，不妨考虑本人多年来发现屡屡应验的一种情况：

 

现在是星期一下午2点15分。用户们开始反映某个关键任务应用程序遇到了严重的性能问题。除了性能不尽如人意外，应用程序管理员并没有发现这个应用程序有什么问题，于是这个问题转交给了基础架构团队。服务器管理员欣然加入进来，确定应用服务器在正常范围内运行，但数据库服务器出现了存储延迟严重的问题。

 

随后存储管理员证实：与该数据库服务器相连接的存储区域网（SAN）卷的确容量即将告罄，但它们本身其实没什么问题。到这时，问题已极其糟糕，好几个管理层都注意到了这个问题，于是一群高级管理人员突然来到存储管理员的办公室，想看看到底是怎么回事。当然，正所谓“锤子在手，满眼钉子”；于是那名存储管理员提议添加更多的磁盘；或者恐慌之余，提议将数据库卷升级到固态硬盘。

 

这种情况下，整条链上就是没有人真正关注该应用程序在做什么，或者它为什么突然加大了磁盘负载。真正的问题，也是我亲眼目睹的问题是，两个频繁存储到数据库的程序前后排得太密集了。只要其中一个程序的运行时间比应用程序开发商预计的长一点，两者就相互重叠，导致数据库卷面临频繁的输入/输出操作。这两个程序一起完成所需的时间更长，进而与其他程序相互重叠，结果引发了雪球效应，最终导致了这个明显的问题。

 

应用程序团队对应用程序面向用户的那部分非常熟悉，服务器管理员对操作系统和硬件很了解，但就是没有人实际负责两者之间脱节的那个极小部分。这种情况下，势必会导致性能突然大幅降低（如本文中的这个问题）。管理员条件反射般地配置过多的基础架构资源，试图“解决”问题。 

 

问题的反省

 

在当今“少花钱多办事”的IT环境下，这种结局司空见惯。你可能会问，“DBA到底在哪里？”问得好！以前，许多公司设有一名DBA；但如今由于预算吃紧，加上新的应用程序大批涌入，这个人的职责转变成了负责部署另一个新的应用程序。谁也没想到“少花钱多办事”的口号到头来成了“多花钱少办事”：那个新增存储设备的成本原本可以用来支付知道没有必要购买更多设备的某个人的薪水。 

 

要避免这种问题，唯一的办法就是确保应用程序支持链衔接无缝。在理想情况下，这意味着恢复DBA的职位；但在眼下这年头，另外增加一名专职员工很少被看作是解决问题的法子。

 

所以到头来，这个职责被转移到存储管理员、服务器管理员和网络管理员的身上。他们完全需要自力更生，不断充电，学习自己支持的应用程序的基本要点。毕竟，一旦哪里出了错，受责备的往往是管理员。性能图表上不会平白无故地出现性能骤降，它们往往与功能失常的硬件没有多大的关系。连高层管理人员没有注意的稍纵即逝的异常现象也值得仔细分析，以查明根源。这些异常可能是下星期一给你当头一棒的问题体现出来的征兆。