ITSM的系统与建设.docVIP

ITSM系统的建设 ITSM系统的建设这是我一直想写的内容，苦于没有时间与精力，本来是希望把这个项目从立项到规划，到设计开发，到最后的实施应用的全部过程写成一个笔记，但工程浩大，有些力不从心，正好国庆节有一些时间，就先写一部份吧。以下的内容会一些杂，我把我们规划这款ITSM系统的一些想法写出来，里面会夹杂着我对这种类型系统的一些规划考虑点，这种考虑一是基本对ITIL的理解，二是对软件实现的理解，三是运维管理的考量。内容不会十分具体，因为每一个部份基本都是一个模块，如果写得深入，基本是一个详细的设计说明书了，这就没有必要了。这是第一次真正的去思考规划与设计一个系统，这里说的设计可能与软件工程的设计定义有一些区别。以前都是做软件实施，现在终于有机会把在做软件实施时的一些想法前移到设计阶段，因为这个项目的规划与实施都会是我负责，所以是把首尾相连了，这也相对可以保证规划的思想可以比较彻底的贯彻下去。可能存在的问题是，后续的一些设计过程，我没有非常深入进去了，这样会导致一些缺失，另一方面，许多在规划的想法是会对公司的体制与管理制度造成一定冲击的，可能到时没有足够的时间与决策支持去扭转当前的作业现状，最后就是对开发团队的实现能力有一些担心，一个好的想法开发人员没有足够的技术能力去实现，这也是比较麻烦的。总的来说，这项目要想取得我预计中的效果，非常具有挑战性。不废话了，下面将逐步展开说明。一、 系统目标系统目标是为了说明我们想开发一个怎样的系统，想利用这个系统做什么，达到怎样的目的，最简单的是，我们想打造一个运维平台，把我们在各个地区分布的运维服务团队，无论属于哪一个客户群的，无论是属于哪一种业务领域的（桌面、网络、系统、软件）都统一纳入到一个相同的平台上作用，他们要基于相同的制度，基于相同的流程，基于相同的理念，用统一术语与方式去服务客户，我们的一个优势是规模与平台资源，但如果我们的人员与业务无法整合到一起，这种优势就不复存在的，反而可能成为一个负面原因，因为你没有了大船的承载能力，却也没有小船的灵活转身能力。运维服务业务有其特点，因为很难标准化，同时太容易受客户的影响而改变流程或制度了，一旦你的团队分散，客户多，而且地理分散后，说光依靠发布出ISO20000的体系文件，对人员做多么扎实的培训，这样就能把大家的各种作业规范统一起来，不是说不可能，极难，要花费巨大的管理资源，同时这样做的一个问题是你的运维服务数据是极难进行分析与采集的，这时一个显而易见的方式就是利用软件。我们在打造自已的平台时，概括来说对这个平台有这么一些几个方面要求：? 设计要求要基于我们的运维服务业务特点，同时把这几年我们做管理探索与改善的经验置入其中，另一个方面要把ISO20000在实施过程的所得纳入实现，这里就是我们的服务体系了，但只是取部份流程的，主要是针对服务支持等部份的流程，还有一个方面就是要参考REMEDY优缺点。这三个方面是我们规划设计这系统的主要基础，加上我们对远景的期望，基本上这三个方面我们都做了一些调研与整理工作。? 范围要求我们所有的运维服务业务，我们所有的运维服务人员，以及运维服务中的所有活动都需要可以被管理，也可以分这么两个层面来说，我们这个平台要可以管理所有的运维对象（各种类型的项目），同时要管理我们的运维资源（人），这里的运维对象与运维资源并不是抽象的概念，是非常具体的，运维对象可以具体到具体每一个CI及其备件，运维资源具体到每一个人的工时利用。其它的象服务目录与SLA等就不用多介绍了，是必要纳入管理。主线是从运维对象与运维资源这儿走出来的。? 扩展要求运维平台可以满足公司当前的运模式的发展需求，以及我们现在的产品的发展，这里涉及具体的一些公司现状，就不多作说明了? 质量要求在应用质量上我们要超过REMEDY，注意是应用质量，不是指功能，功能上我们无意与REMEDY去一争长短，因为这没有什么可能性与意义，但我们有信心只要一年实施时间，我们就完全可以超过REMEDY在公司的应用质量，这一点我的把握相当大。二、 系统架构我们使用的是B/S的系统架构，这是为了方便地理分散的员工使用，同时也是为了考虑到日后全国的用户可能会登录系统进行一部份的作业，比如参与调查，或者开放论坛等，采用B/S的架构，负面的影响一是速度方面，二是界面表现力，但日后的升级维护比较方便，用户登录也很方便。具体是否成功，可能还要等日后大规模应用时才能进一步验证。开发平台是.NET2005 C#，数据库采用ORACLE 10G。另外我们在流程中（比如事件升级、派单）做了一些邮件通知与短信通知的功能，其它的在技术方面，倒好象没有太多值得说明的地方，也可能可以说技术并没有太多的亮点。三、 流程控制在系统流程控制方面，当时也有过一些争议，后面由于