【51CTO.com原创稿件】还记得哥上次跟大家聊到的那个云平台项目吗?眼看快要大功告成了，去突然最近空降了一个思路活跃VP，新的需求顿时滋生了许多，而且喜欢动辄就吹“集结号”召集项目组成员开会。苦逼的廉哥只能将辣么多的“力比多”继续全情奉献并投入到了其中，真是累成了狗!可是哥是有独立思考和总结能力的，项目中的各种胜败得失时常被哥综合到理论上，并记录在了小本儿上。
好吧，花开两朵，各表一枝。我们还是继续咱们的漫谈主线，这次来聊聊项目与服务管理。对于运维人员来说IT服务的产生，发布和变更都是以项目的形式进行的。如何像日常运维流程那样管理好每个项目的整个生命周期是值得每个项目参与者去认真思考和不断试错的。
IT项目来源于需求，普通用户和运维人员所提出的IT需求一般较为直接也可能带有一定的局限性，多期望于某个IT服务的功能、界面和性能等方面。比如说，只是为了满足用户一时之需，或是配合客户某种互动，迁就使用了过于陈旧或是太过hi-tech的技术或服务，就如同打开了潘多拉魔盒一般，植入了一颗隐形炸弹，或是产生了连带风险。
举个例子吧。为了跟上潮流，企业业务部门提出迅速开同微信平台并且提供资料下载，这个看似fashion且便捷的需求却隐含着很多安全隐患。到时候真正出现了数据泄漏或系统被入侵、甚至牵扯到法律问题的时候，很少会有业务部门或者是项目组帮着IT运维部门寻根溯源甚至是引咎买单的。可以不夸张的说，这都是血的教训啊。
因此在立项时和在做分析的阶段，需要对各种需求加以引导和管理，淡定，切忌冒进。一般要把握好下述三个维度：
1. 原始问题描述：对要解决问题的叙述，它是需求分析的基础，因此需详尽阐明需求的起源。
2. 用户需求：使用用户容易理解的语言和图表描述需要提供的服务以及操作的规范。同时要做好各部分优先级的划分和定义。
3. 系统需求：开发出一个简单界面/功能原型来映射用户的需求。这除了可以给用户一个直观印象之外，还方便团队程序考虑其如何部署到当前的IT架构中，以及与现有系统的数据流向和兼容性等问题。
可见，对于需求，IT部门应成立项目组，积极的做好分析，确保所制作出的需求文档和原型能正确地反映用户的真实意图。其间可采用的方法包括：绘制模块关联图、创建用户接口原型、分析可行性、确定需求优先级、编写数据字典等。甚至项目组可以去主动引导用户，将需求限定在可实现、可控制的范围内。
有经济学基础的朋友都知道“机会成本”的道理，一旦我们立项的文档和原型定好的同时就等于放弃了其他的选择或是项目发展方向，因此项目团队除了至上而下的接受往后的 “发展道路”外，也不要轻易产生后面将会提到的需求变更，以免产生不可以预知的蝴蝶效应，导致项目的最终失败。
记得曾经见过这么一个段子：女神说要程序猿追求者帮其减肥。他满口答应并称自己是助人减肥的老司机。可是次日中午当又看到女神饭后坐在电脑前玩消消乐时，他苦口婆心的上前劝导了半天无效，突然脑洞大开，祭出狠招，去拉下了办公室的电闸。女神盛怒，说“原来你是这样的人!”，遂愤愤的摔门而出!望着其背景，他当时懵逼了，没有上去追，只是默默的念叨着：“不是说好了让我管住你的吗?怎么一语不合就这样?你走，我不送你;你来，无论多大的风雨，我要去给你买串儿。”
大家看到了吧，人都是有惰性和抵触情绪的，很多事情光有口头的约定是不行的，没有形成文字的东西是没有人会承认的，当然对有某些任性的女人来说，形成文字又如何?Anyway，我们下面来聊聊服务与运能级别管理。
1 白纸黑字
IT部门在企业内服务的对象是end users，他们对于咱们来说是“诗和远方以及甲方”。要实现企业的投资回报率，IT运维团队需要在服务质量需求、客户满意和服务成本之间实现平衡，也就必须在任何IT服务的立项阶段着手制定服务级别约定(SLA)，即：IT服务提供者(IT部门)与用户之间的约定。其内容包括：IT服务的描述，约定服务次数与时间，响应时间，故障恢复耗时(Recovery Time Objective)，故障恢复程度(Recovery Point Objective)，用户和提供者的各自责任，关键业务周期，异常处理与升级渠道，以及最终报告等。
多说一句：常在河边走，哪有不失鞋的。在出现IT事故时，运维人员应及时运用邮件/电话/短信等方式告知公司全员，让大家感受到IT的“关怀”和运作。让其在碰到问题的时候有了思想准备，不会因为“记几控几不住记几”而大发雷霆，同时也能树立了IT的积极、主动和尽力形象。
2 因人而异
应当注意的是：对于同一种IT服务，由于总部和分支办公室的地域差别以及不同部门用户的角色差异，服务级别约定有时候需要进行定制，以满足其要求的差异性。此外，IT部门除了有基于服务类型的“总体约定”，还应制定：“特殊区域/部门详细约定”，例如：对总部宽带线路的品质保证和特别为财务部数据安全的保证;以及“特殊用户群详细约定”，例如：对部门经理级别用户提供移动通信服务的支持力度。因此服务基本约定有利于用户对IT部门所提供的服务达成共识，避免过高的期望和误解的产生。IT部门也能籍此作为服务成本核算(下期将提到)的基础。
3 合纵连横
IT部门与企业其他部门之间可以就IT服务进行约定，从而产生那些运营级别约定(OLA - Operational Level Agreement)。这种约定旨在保证该业务部门的日常运作，例如：保证市场部在外开研讨会时所使用IT设备的齐备和可用。这种约定可以避免内部部门对部门“打群架”式的扯皮情况的发生。此外IT服务上线之前一定要有相应的基础合同(UC)的支撑，如上网线路保证、硬件备机、软件技术支持等。此类合同一般不为最终用户所感知到而且是由IT管理层与供应商签订。另外，不得不说的是签订的UC是对IT部门的一种合理的风险转嫁到方式。这种“上帝的归上帝，凯撒的归凯撒”式的明确责任的处理方式可以使得IT团队中事故发生时有条不紊的进行响应和恢复。当然这也会增加IT部门的日常成本支出，因此要周期性的重审并对条款进行改动，至于签到什么程度是要根据预算而定的。这一点，我们留到以后的成本核算章节再做讨论。
至此，三种约定之间的关系可由下图所体现：
重申一点：由于内外部环境的变化，以及技术的发展，服务等级管理应该是一个不断循环的过程，IT管理层应定期对各种服务/运营等级约定和基础合同进行评估、更新和修订。
屈指算来，这已是我们漫谈的第十四期了，回首十多期下来，这些分享既是对自己的思路和知识的一种梳理，又是和小伙伴们互动相长的过程，还结识了一些素未谋面的“朋友圈的朋友”。很有“ 有两岸猿声啼不住，轻舟已过万重山” 的即视感。聚沙成塔，汇溪成河，让我们在日常运维的技能与管控理论上不断提高自己的广度和深度，尽快成为企业里的“T型人才”吧。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
