|
---|
国内政府行业维护省级大集中系统的经验并不多。北京地税是国内率先实现税务信息系统大集中的省级单位。做好北京地税大集中系统的维护工作,不仅对北京地税,甚至对整个税务行业来说,都是一项开创性的工作。 近期,我刊邀请北京地税局运营维护中心副主任闫军生,介绍了北京地税的大集中运维实践经验,并邀请中国人民大学外包领域研究专家杨波老师、IBM全球服务部业务及技术管理部高级IT架构师毕巍一起进行了讨论。 熟知国内外IT运维情况的毕巍,这样评价北京地税的运行维护工作:尽管他们不是按照IT运维的最佳实践ITIL来运作的,但的确取得了成效,就像电视剧《亮剑》中的那个团长,没有上过一天军事理论课,但打仗就是行。 北京地税局是国内率先实现税务系统大集中的省级单位。2001年,北京地税核心征管大集中系统初步上线运行。原来分散于各区县局的应用平台、数据、网络等全部都集中到了市局,各区县局的运行维护压力和风险减小了,整个压力和风险都集中到了市局。大集中系统的任何一个小差错,就可能造成全市地税系统的瘫痪。 大集中之后,北京地税局便立刻认识到运行维护工作的重要性,开始了不懈探索,并决心要走出一条建设性的路子。 以外包策略为主 北京市政府关于“合理利用行政资金购买社会服务,履行政府职能”的IT建设策略,启发了北京地税,并使其做出了一个大胆决定:采用外包方式来维护大集中系统,通过合同与外包服务商建立起法律关系,以保证系统的稳定运行。 目前北京地税局大集中系统的运行维护策略以外包为主。整个IT系统主要由三家外包公司负责:核心征管系统业务由四一安信公司承包并维护;个人所得税明细申报系统和tax861网站是由博士山公司负责;整个发票系统管理由恒信恒安公司承包;OA系统由神州数码公司承包,其它一些小系统由小公司负责。 出于安全考虑,核心数据的安全策略、系统的一些机密性内容,仍留给自己自行管理,比如系统的密码、口令,策略一致性鉴定,运行安全质量的监督检查等。 运维专业化 经过多年探索,北京地税又认识到运行维护是一项不同于开发建设的工作,必须由一帮人进行专门研究;同时要利用信息化机构机制和不同的职责安排,使其相互之间形成一种制约,以保证信息化安全。 基于此,2005年上半年,北京市地税局成立了北京市地方税务局运营维护中心(简称“运营维护中心”),把信息中心原来的维护、开发工作进行了专业化分工。 运营维护中心就像是北京地税IT系统的“管家婆”,专门负责处理各种生产设备的运行维护问题,包括各种核心业务系统、网络设备、机房等。对外,它要为纳税人服务,保证纳税服务平台的稳定运行;对内,要为税务干部提供一个安全的管理平台,保证实时管理。目前,运营维护中心90%以上的工作是外包管理,也就是管理几家外包服务商的问题。 北京市地税局运营维护中心是一个经北京市人事局编制办公室批准成立、自收自支的事业单位,到现在为止只有7个人,7个人分成两个组:综合组和运维组。运维组负责处理一切业务工作;业务之外的行政、后勤等工作由综合组负责。 运营维护中心副主任闫军生至今记忆犹新,2001年北京地税大集中系统初步上线时,曾经出现过比较大的事故。当时整个北京的纳税人炸开了锅,几百个税务所、成千成万人在议论。如今,经过多年探索,北京地税大半年内再也没有发生过类似事件。 北京地税在大集中系统方面的运行维护经验,不仅对整个税务行业,甚至对电子政务建设,都具有开创性和借鉴意义。 一个充满矛盾冲突的过程 “说句难听的话,我们就是不停地与别人打架。半年来,没少得罪人。” 闫军生略带苦笑而又释怀地说:“当事情不能两全时,我们往往以系统安全为重。”闫军生所谓的“打架”并不是一种消极状态,而是大集中运维过程中一种正常的矛盾冲突。 大集中系统的运维过程充满了各种矛盾冲突。在执行过程中,运营维护中心不仅要学着用合同管理与服务商打交道,用条款化、量化标准进行外包管理,也要配合行政管理;他们还要与开发部门进行交涉;遇到突发事件,他们更要冲锋陷阵,化解纳税人的各种抱怨。 与开发部“打架” 运营维护中心没少与开发部打架。事实上,闫军生和开发部主管的私人关系非常好,但工作目标不同,决定了这个“架”不得不打。 开发部的目标是把开发的系统迅速成功上线。“没有200%的把握,我就不愿意让开发部上线。我们的职责是要把维护的风险化解到日常每一个流程、每一个环节中,把风险降到最低。如果他要求上线,我就要求他们必须达到什么条件才能上。这样下来,安全系数就高了。最后,大家一起把工作做好。打架不是目的,目的是为了系统安全。” 闫军生介绍道。 由于闫军生的坚持,开发部还改变了“从来不写维护文档”的习惯,开发部的项目文档量也增加了40%。 一般国内做开发的人从来不写维护文档,可能一些小公司甚至都不懂什么是维护文档,不仅因为做起来很麻烦,而且工作量很大,要求维护文档必须跟实际情况一致。 IBM服务部毕巍表示:“非常佩服闫军生,他已经在实践中将国外很多年的经验教训都总结出来了。维护文档是属于开发阶段非功能性需求里面的维护部分的需求。在项目开发阶段就应该对它进行规划,现在国内开发都偏重于功能性需求,不重视非功能性需求,非功能性需求包括性能、可靠性、安全性、扩展性以及运维,比如维护要求、职责、操作手册、操作规范等。它属于开发团队的职责。” 当运维管理遭遇行政管理 运营维护中心也会遭遇行政管理与运维管理的冲突。曾经有一次,系统开销满了,眼看即将发生重大安全事故,谁都不敢动。按照行政管理规定,运营维护中心必须一层一层给上级领导打报告、请示,等待批示。 紧急关头,闫军生二话不说,马上决定把系统关了,再重新启动,来回重新启动了好几次,仍然不行。最后,干脆关掉全部输出之后再慢慢开,一直开到输出为40%的业务量时,不许再开了,因为当时系统开销已经达到临界点了。一个小时之后,系统就可以运转了;再过一小时,问题解决了。随后,闫军生发动运营维护中心的人员对内部进行解释。 “当时,我都晕了。按照内部行政规定,我们搞社会服务的,应该保证上级对我们的管理介入,但是,遇到这种突发事件或应急事务,当系统管理和行政管理发生冲突的时候,身处一线,我们必须要有所取舍—以系统安全为主,这个时候,行政管理必须有所屈从。最终,行政领导也理解了我们,非常尊重我们。” 闫军生表示。 回想半年来的工作,闫军生自嘲地表示:“坏事都是我干的。回头一看,都是我在违章。因为按照行政管理的条文一衡量,我是一个天天违章的人。怎么办?必须要有所取舍。既然领导把这个任务交给我了,我就豁出去了,不管怎样,首先要保证系统安全吧。” 学做合同管理 真正让闫军生感到艰巨的任务是如何与服务商打交道。 在外包策略下,运营维护中心对服务商采用了一种完全基于合同的管理。按照合同条款,外包公司或相关服务商每月会定期向运营维护中心汇报运行维护工作情况;运营维护中心按照合同条款对他们一个月的工作进行质量评估,再按照合同条款决定是否付款、是否处罚,以及是否追加一些款项。 看似简单的合同管理,操作起来却非常不易。这半年来,运营维护中心没少吃苦头。由于刚刚开始尝试外包时,许多事情都不懂,因此,合同制定得比较粗糙。当遇到问题,一打电话给服务商,服务商就说这事不在合同之内,合同里面的确也没有。碰到这种事,运营维护中心只能“有苦说不出”。 闫军生总结道:“合同管理是一门学问,包括合同的制订、合同的种类,到如何管理合同,我们应该管什么、应该注意什么,怎么拿起法律武器等,都很有讲究。2006年,我们准备花一、两个月好好研究一下合同。” 沟通,让别人理解 尽管存在种种矛盾冲突,闫军生乐呵呵地表示:“我们与各方面的关系都好着呢。” 在化解各种矛盾冲突之中,身为运营维护中心“一把手”的刁维列主任,扮演了一个重要的角色——沟通者。 在闫军生看来,刁维列主任把运维方面的事情办完之后,大部分时间就是与高层领导、部门领导们沟通,让他们理解运维工作,为什么花钱,为什么要这么干,为什么要学习合同管理等。 “不理解,是因为不了解。只有沟通,才能让领导理解,才能重视起来。领导重视了,我们就方便开展工作。”闫军生表示。 闫军生 北京地税运营维护中心副主任 当事情不能两全时,我们往往以系统安全为重。 毕巍 IBM全球服务部业务及技术管理部高级IT架构师 甲方清楚怎么外包,乙方也知道怎么接手,这是国外企业愿意做整体外包的一个原因,否则风险太大。 杨波 中国人民大学外包领域研究专家 运维外包涉及了大量的不确定因素,所以需要双方建立长期的信任关系来保证外包关系的顺利进行。 尊重规律 在闫军生的眼中,运维工作就像一个具有自身运作规律、等待揭开谜底的魔方。 一个看似简单的“停机”,在闫军生看来,也有自己的处理规则:“别人老认为这两个字很简单,实际上,这么庞大的一个集中生产系统停机了,任何时候都可能起不来。因为这个系统是一个大集群,当硬盘以7200转/分钟或者1万多转/分钟的速度高速旋转时,可能某块磁粉不知道什么时候就掉了,如果掉的一块正好是操作系统部分,那么整个系统就完了。” 为此,闫军生制订了一套完备的“停机”流程:停机之前,先检查所有环节一切正常,并对系统进行备份,随后才停机;在启动机器之前,要先购买各种服务和支持,一旦某个设备不能正常启动,保证马上能得到服务支持。据介绍,每次停机,运营维护中心购买的服务费用就有5~6万元。 如果不尊重规律、不按规律办事,系统配置参数的一个小小的修改,可能也会捅出大娄子。比如,改变生产系统的某个配置参数之后,没有标明版本和版本号,又没有对系统重新启动一遍,可能某个时候,这个系统就运转不了了。 “运行维护工作必须适应生产系统的自身规律,制定出相应的工业化维护过程。尊重运行维护的基本规则来开展维护工作,是一个非常重要的理念,来不得虚伪。” 闫军生表示。 冥思苦想提出两个方针 为了开展运维工作,身为运营维护中心“一把手”的刁维列主任在大伙眼中消失了几天,冥思苦想提出了两个方针:早发现、早报告、早建议,预测、预报、预案。 早发现、早报告、早建议,就是在日常运维工作中早点发现系统存在的隐患,早点报告上级领导,并早点提出建议。预测、预报、预案,就是根据以往的运行维护经验,及时进行预测哪些地方可能发生问题,提出警告,同时准备相应的预案,以便问题真正发生时,做好应对措施。 为了尽早查出存在的安全隐患,运营维护中心曾经对整个系统环境进行了摸底、排查。原来的系统环境不是很规范,到了夏天,其温度有时会高达28.9C,环境温度较高会损害设备。发现问题之后,他们立刻给上级领导打了个报告:如果按原来的状态继续运行下去,机器寿命会缩短多长时间,对系统稳定性有什么影响,整个系统数据存在什么风险等,并提出了具体的应对方案。这份报告呈上去之后,领导非常重视,立刻给予落实。 尝试流程化 事实上,闫军生理想中的维护工作状态是:只有任何一个事务处理都具有流程化、可控化,才能维护好一个生产系统。在这种状态下,启动任何一个流程,每个人都知道如何处理和运转这个流程,而且落实在每一个环节的责任都非常明确。 半年来,运营维护中心尝试进行了流程化、规范化建设。机构变化处理流程就是其中一个。2005年上半年,北京地税22个区县的所有机构开始调整,有些机构撤销了,有些合并了,而原来的系统没有提供针对这些变化的应对措施。遇到这个问题,怎么办? 再难,也要想办法解决。运营维护中心派出一个工作组进驻区县局,对每一个机构每一种情况的处理流程进行调研,前后花了两个月,总结出一大堆文件,详细整理出不同情况的处理办法,包括处理到什么程度,系统怎么处理,人员怎么处理等。如果再遇到机构调整问题,只要遵循已有流程处理,就可以了。 运营维护中心还引入了首问责任制。第一个接到热线电话的人,自始至终负责解决这个问题,不允许出现相互推诿的情况。一旦遇到问题,为了及时把事实告知客户,安抚客户的情绪,运营维护中心还建立了短信平台。现在,遇到问题时,不再是运营维护中心几个人,而是局长、科长等上百人一起进行解释,缓解了客户的紧张情绪。 这种立足于“尽早发现问题、尽早预防、保证不出问题”的运维方针,以及规范化运作的思路,受到毕巍的高度认可。 熟知国内外IT运维情况的毕巍,这样评价运营维护中心:尽管他们不是按照IT运维的最佳实践ITIL来运作的,但的确取得了成效,就像电视剧《亮剑》中的那个团长,没有上过一天军事理论课,但打仗就是行。运营维护中心的这些套路,都是他们自己在实践中摸索出来的。回过头来看,我们会发现,他们的一些套路在ITIL理论上都可以找到对应点。事实上,他们已经在向ITIL理论靠了。 五点运维经验 记者:作为IT服务方面的资深顾问,您觉得北京地税有哪些值得借鉴的运维经验? 毕巍:考核决定结果,成立运营维护中心是一个英明决策,这可以促使一些人专门从运维角度考虑并处理一些问题。 “一把手”和“二把手”的配合做得不错,也就是说,大家职责分工很明确。比如北京地税运营维护中心“一把手”的工作主要是和上级领导、左右部门领导进行沟通,“二把手”主要处理日常事务。 尊重运维的基本规律,用运维规则来处理运维的事情,这是大半年来被印证成功的地方。 把握住了两个基本的理念:一个是服务理念,确实以服务理念,来促进对外关系和有效组织内部人员。另一个是人脉,他确实把握住了这份工作确实是一个人脉问题。很多方面,他都是在促进人脉问题,包括开放热线电话,使客户在不满意时有一个宣泄的渠道。 采用了首问责任制。首问责任制是对团队的一种组织方式,也就是说,第一个人接到了某个问题,从头到尾,你要负责到底,而不是说,你接到了一个问题,再转给别人去解决。这可以确实把服务理念在组织里贯彻到位,解决了以往比较分散的、责任不明确的状况。 记者:在北京地税的外包合同管理方面,请杨波老师给点建议。 杨波:外包形态有两种,一种形态是项目型外包,一种是流程型外包。系统运维是一种流程型工作,没有明显的起点和终点,这种合同涉及到了很多不确定性以及大量的资产专用性投资,这种合同通常要签5~7年。它通常需要一个转换过程,这个过程实际是把外包服务商的管理体系和甲方的要求、管理体系融合的过程,通常需要一年到一年半,然后才能走向正规。 运维外包因为其中涉及了大量的不确定因素,即使是签订1000页的外包合同,也不可能把所有的不确定因素都涵盖进去,所以需要双方建立长期的信任关系来保证外包关系的顺利进行。合同也是非常重要的,它在双方产生争议时,起到了一个基准的作用。 另外一种是项目型外包,这种外包不确定性因素很小,双方可以签订比较完备的合同,外包工作有明确的起点和终点。 闫军生:依您的经验来看,什么情况下,北京地税可以做整体外包?时间和条件成熟吗? 毕巍:在国外比如美国,甲方和乙方共同成长,当甲方走过十几年路程,自己理清楚一个盘子以后,自己已经玩透了,才有能力把整个系统交出去。甲方清楚怎么外包,乙方也知道怎么接手,这是国外企业愿意做整体外包的一个原因。否则风险太大。 我不敢说,北京地税能够整体外包的具体时间是哪一天,但需要几个前提,第一,商业化操作模式要从上到下都能被接受,包括北京地税最高行政领导能够接受外包模式和理念。第二,外包要求这个运维体系一定要有自主化运转能力,不管少了谁,这个体系还能正常运转下去,如果达到这种程度,就可以了。
|