|
能力管理的活动（Activities）完整地说明了如何实施能力管理
在多次教授ITIL课程的过程中，我经常会遇到学生对于服务提供（Service Delivery）感到力不从心的情形，学生们总觉得似乎不容易实践。对此，我的观点是不要拘泥于流程之中。虽然众所周知ITIL是一种流程的设计，但是理论的ITIL只是告诉人们流程应该设计成什么样，具体的流程必须在理解了理论之后才能实践。
能力管理，英文的原文是：Capacity Management。Capacity这个单词，在 IT产业其实常常被解释成容量。但是，为什么在ITIL里面解释成为能力呢？其实，举两个很简单的例子就可以说明：
·公司建立了一套电脑系统，这套系统拥有了200GB的磁盘阵列的“容量”。
·小吴通过了Oracle OCP的考试认证，小吴因此有了数据库管理的“能力”。
上面的这两句话的“容量”及“能力”如果互换，相信人们一定不会认同这样的表达方式。但是，如果这样表达：这套电脑系统，不仅仅可以运算，还拥有了强大的存储“能力”。也许就可以理解：为什么中文将Capacity Management翻译成为能力管理，而不是容量管理了。因为，“能力管理”这个名词的使用范围会高于“容量管理”。
能力和容量的区别
设想一下“能力”与“容量”这两个名词，分别适用在哪里？这些地方，身为一个ＩＴ的工作人员，你该有什么样的态度？
能力管理，通常我们会首先联想到人的行为。比如：因为人的行为、能力，IT 部门才得以有能力提供服务给客户。容量管理，通常会让我们联想到物的状况，可能是 IT 部门的某些资源，比如CPU、内存、I/O、存储设备等等。这虽然不是二者绝对的差别，但是就理论的学习方面，可以考虑一刀切下的二分法，即利用这样一个二分法，来学习以下的理论。
根据ITIL的理论，能力管理（Capacity Management）有三个子流程（Sub Process），分别是业务能力管理（Business Capacity）、服务能力管理（Service Capacity）及资源能力管理（Resource Capacity）。我希望利用上述一刀切下的理论，来连接这三种很重要的子流程。或者是说：利用上述一刀切下的“能力”及“容量”，来对应三种重要的能力管理的理论。
何谓业务能力管理？其实重点就是IT部门有足够的能力，以应付从现在到未来的业务需求（Business Requirement）。ITIL强调的是未来的需求，但我们不可能精确预估未来。我们能够预估的，只有由过去到现在的行为，来判断未来的趋势该如何去顺应。
何谓服务能力管理？其实就是IT部门对于客户所需要的服务所具有的能力。当然，如果IT部门有服务水平管理（Service Level Management），就会理解客户所需要的服务具体是什么情况，具体的资料就会出现于服务水平协议（Service Level Agreement）。
何谓资源能力管理 ？就是目前IT人员最擅长的 IT 基础设施（Infrastructure ）的资源管理。比如说常常谈到的CPU的快慢、内存的大小、网络的吞吐量、存储的大小等等。
所以，对于业务能力管理、服务能力管理及资源能力管理等上述三个子流程的要求，我们不妨将其简化理解为“人”的能力及“物”的容量。举例来说，如果你要负责一套电子邮件的服务，或许会想到有多少使用者要使用这一个服务？这一服务在公司里有什么服务需求？三年之后会成长多少？需要哪种配置的服务器？哪种软件？需要多大的存储，才能供应这些员工的邮箱？三年之后呢？需要多宽的带宽？管理者需要哪些技能？需要规划哪些职责等等。不仅如此，你可能还需要规划从今天开始到三年之后，这套电子邮件服务的可能成长。
参与能力管理子流程的活动
能力管理的三个子流程分别有四件活动来参与，分别是：效能监控、需求管理、模型建立及应用选型。
如何利用日积月累的资料来进行分析，以求理解现在的情形？观察及记录就是一个好方法。以同一个例子来讲，通过不断地观察及记录、日积月累就可以了解电子邮件服务何时很忙？何时又很闲？每个月使用者的增量是多少？每个月的邮件量又是多少？增加量又是如何？存储使用了多少？原本可能只需要懂smtp/pop3的人员负责，现在可能还需要Exchange的Web mail的管理能力来参与？明年可能需要7×24的服务，该如何规划人力呢？
ITIL的理论有一张图，解释了能力管理的活动（Activities）。这张图完整地说明了如何实施能力管理。图中三个子流程分别有四件活动来参与，分别是：效能监控（Interactive Activity），又称 （Performance Monitoring），需求管理（Demand Management），模型建立（Modeling）及应用选型（Application Sizing）。
其中效能监控就是要求我们做前文所提到的观察及记录。确实，这项工作一旦启动，将会是无穷无尽的，不断观察及记录。既然有了观察及记录，就一定会有数据库来供记录，这个数据库称为能力管理数据库（Capacity Database）。
需求管理的内容包括淡季、旺季、工作时间、非工作时间等等。IT部门希望能够了解到业务部门的工作量，比如公司每年的4月是淡季，所以IT可以从事一些定期维修的工作，IT人员的培训、新的服务测试也通常放在4月。那么，如何了解4月是淡季这一信息？这就需要长期的观察及记录。又如，IT人员不会在上班时间对生产系统进行备份（Backup），因为上班时间的电脑服务器很忙碌，此时进行备份会使得有限的资源雪上加霜。
利用长期的效能监控，必然可以理解业务部门的需求。虽然业务部门的需求可以写在服务水平协议内（Service Level Agreement），但是长期观察及监控的资料，一定是第一手、而且是IT人容易理解的、最直接的信息。否则，要利用模型建立或是应用选型来做预估，难度就会大大增加。
模型建立或是应用选型实施起来是比较困难的。模型建立，必须要针对某个已经设计或是正在设计，但是尚未生产的IT服务，给予不同的工作量，然后预估其后的行为（Behavior）为何。应用的选型，针对将要上线的应用（Application），预估所需要的资源为何。实务上，可能可以应用某些软件来进行模拟。否则，IT人员确实很难利用一些烦杂的数学工具来进行推估及演算。
能力管理实践
能力管理就是利用ＩＴ部门的人与物，透过长期的观察及记录，来贡献给业务能力管理、服务能力管理及资源能力管理。
前文的要点概括而言就是：针对“人”的能力及“物”的容量，利用长期的观察及记录，来进行能力管理的实践。但是不要忘记由现在到未来的预估：业务能力管理、服务能力管理及资源能力管理。
“物”的容量，所有的IT部门都已经实践了。许多IT部门都有各种监控软件在监控CPU的使用、内存的使用、IO的吞吐量、存储的使用量、网络的带宽的使用量等等。不仅如此，IT人员还会利用观察的经验，制定其门槛值（Threshold），当门槛值达到时系统会报警（Alarm）。这是一套有效的管制：由主动的管理，变成被动的管理。
“物”的容量当然不仅限于资源能力管理。针对物的容量管理，也需要时时刻刻关心业务能力管理及服务能力管理。比如什么样的IT架构，可以提供怎样的IT服务，以对应及满足客户相关的业务需求。比如200GB的硬盘可能只能满足1000个用户邮箱，随着业务量和用户量的成长，200GB也必须增加。
“人”的能力是整个能力管理中的重要一环。与“物”的容量不同，“人”的能力管理是目前IT实施的一项弱点。目前的IT部门该如何管理好“人”的能力？
“人”的能力可以分两个方面：一是工作的能量（Capacity，可理解为另外一种“容量”），一是技能（Skill）。有人精于数据库，也有人专于网络，这就是技能的不同。从这两方面可以得到一个交叉的分析结果：职务及责任（Roles && Responsibility）。透过职务及责任，来进行“人”的能力的管理，进而贡献给业务能力管理、服务能力管理及资源能力管理，这是一个好的方向。
那么具体应该如何进行？首先还是要完成相关的职务及责任（Roles && Responsibility）。这项工作，必须要与服务水平管理及配置管理为主要方向。服务水平管理会理解客户的全面需要，之前也会撰写服务说明书（Service Catalogue），也因此，所有的职务及责任也在此确定。
概括而言，能力管理就是利用IT部门的人与物，透过长期的观察及记录，来贡献给业务能力管理、服务能力管理及资源能力管理。特别需要再次提醒的是：长期的记录可以预估未来的需要。这就是ITIL的能力管理。
|
