浅淡我对运维服务的一些看法.pdfVIP

浅谈我对运维服务体系的一些看法 　随着 XX 公司十一五期间信息化 XX 工程全面建成并持续深化 应用，与公司业务紧密融合的全球规模最大的集团企业级信息系统投 入运行，如何最大限度保障其安全准确高效运行——这一课题摆在了 我们面前。XX 和“XX”体系的建 ，对信息系统运行工作提出了更高 要求。下面我从运维工作实际出发，详细分析运维工作内容、管理组 织结构和职责划分以及运维体系建 情况，就运维工作中存在的一些 问题，对信息系统运维体系的建 提出了一些看法。 一、运维服务目标 明确服务目标，在我看来，为客户提供稳定、可靠的运维服务是 我的工作目标，也是我们整个运维团队整体的工作目标。我们所安排 的一切工作项，比如巡检、值班；制定的一切流程、规范都应该是为满 足客户服务而付出的努力。 二、运维服务的内容 与运维服务目标相比，运维服务的具体内容往往十分含混，不具 备具体操作、指导性质。即服务合同内容不清晰。 例如：  哪些是我们应该提供的工作内容？  哪些是我们不应该提供的服务内容？  人员的管理权、考核权怎么划分？  运维费用、预算如何支配，谁有权利支配？ 这些内容一定需要界定清楚，以便于运维工作能够更好的开展。 因此，签订明确的运维服务合同是至关重要的。即便是当场服务合同 未考虑周全，也应该在必要的时候签订补充协议。 三、构建运维部门 运维管理部门负责的是运维的项目，应该是负责为各项目提供运 维服务的一个团队，我们统一称为“运维管理部”。可以想象这个部门 里绝大多数人员是具体的一线员工，这些同事直接面对客户。不同的 运维团队有不同的具体情况，一线员工由于工作性质的原因，可能薪 资不高，而且技能也不高，一些疑难问题需要更高级别的工程师处理。 这里就有两种构建部门的模式。第一种是运维管理部只有一线员工， 公司其他部门比如技术支持部作为二线支持部门，研发中心和厂商作 为三线支持单位；第二种模式是运维管理部包括一、二线员工，能够处 理决大多数问题，疑难问题提交给研发中心和厂商处理。 作为提供高效运维服务的关键是，无论哪种方式，都需要服务链 条上的技术员工对运维管理部来说是可控制的。即在发生故障时，相 关部门能够按照预计的方案自动、自发的开展工作，相关人员在提供 服务这件事情上是绝对可控的，不能出现没人管、人不在的情况。因 此，运维服务方面的岗位职责，部门及部门之间的关系一定要明确。 四、运维服务员工甄选 运维服务很少是一个人能完成的，具备规模的项目都需要多人配 合，大家互有分工，运维团队的员工是这个团队的资本，因此，运维人 员的对自己工作的本质要有清醒的认识。不符合从事运维工作的人员 没有工作动力、没有进取心，这样的人搅乱了整个团队工作的气氛。其 他员工看到这些“大爷”们的“工作”作风也就没有了动力。因此，做好运 维工作选人很重要，我们要对这些“大爷”们敬而远之。 五、运维与项目一定要分开 运维与项目搅和在一起也算一件头痛事儿，是严重的制约运维工 作开展的绊脚石。通常的理解是项目竣工后把项目相关资料移交给运 维部门（即建设转运维），对运维部门进行培训，使之能够开展服务工 作。这时，项目建 已经结算，移交工作作为项目结束的里程碑。这样 工作分工泾渭分明，大家的权利和义务十分明确。就算是项目周期很 长，项目不可能在完全结束后再移交运维部门，那也应该是哪些系统 开发完毕了，可以移交了就做部分移交，没有开发完成的就不移交，这 样工作有一个明确的分工，项目组与运维部门的工作要十分明确，这 样工作结合也算顺当。但是，就怕项目与运维工作搅在一起。例如，也 没有移交，反正开发战线长，产品代码修改频繁，应用系统匆匆上线 后就扔给运维做编辑、维护栏目等，这时，运维在使用过程中往往还需 要承担系列常见的工作：  需求分析交给运维。运维负责与客户碰需求，最 后交给项目经理或其他人；  测试交给运维。由于系统“庞大”，研发的同事们