01

终于要吞这只大青蛙了！

按照某种时间管理理论，每做一件很重要但却很不想去做的事情，都相当于吃掉一只“活青蛙”。

“如果你必须吃掉两只青蛙，那就先吃掉那只长得大长得丑的。”而撰写“应用系统建设篇”无疑是这群青蛙中我最不愿吞咽的。

但我知道，只有先把这只最大个儿、倒胃口的青蛙吞掉后，我才能继续顺利往下进餐。

02

随着信息化的发展，中石化总部和分公司陆续建设了很多满足各种功能的信息系统。

一般说来，每个信息系统都可以解决一类事情，都要占用一台服务器，一块存储空间，都需要一部分人去跟进、学习、运维。

03

没有推行源头采集数据库以前，每个应用系统跟数据库基本上是一一对应的。服务器、数据库、应用系统三者可以用“一机一库一系统”来简称之。即一台服务器上安装一个独立数据库，基于该数据库建设一个应用系统。因此这里就把数据库与应用系统合并起来一起写。

数据库的备份与恢复是数据库运维和管理人员最常做也是最重要的一件事情。数据库管理员经常，甚至每天都要做的一件事情就是给数据库备份。不同时期，不同大小的备份文件，占据了服务器很大一部分硬盘空间。

尽管用心转移和保存的备份成果，可能从来都不会动用，但我们仍然会义无反顾地去做。就像人买保险一样，明知道绝大数时间用不上，但还是会去买一个，权当心理的安慰吧。

做数据库管理员时间久了，会形成一种强迫症：所有的东西都要预备至少两份，并且还要存在不同的地方，这样心理才踏实，才有安全感。 甚至连工资也都想要双份的，但是没人给。

04

记得有一次，由于操作不当，导致生产数据库发生致命故障，无法启动还原。幸亏那一年正在测试使用DSG公司的一款数据库同步复制软件，可以把源库通过日志分析的技术完完全全地复制过去。不过在此以前一直没有在正式库中测试过这种方法是否可用。但在那个危机时刻，只能死马当活马医，我们把DSG的工程师火速搬过来救场。

那天下午下班后，我们一行三人把自己反锁在办公室，表情严肃，严阵以待。我们拔掉电话线，以防有人骚扰。

然后就进行了数据库的恢复工作。我们首先要检查目标库中数据的可用性，对一些小问题进行调整处理。然后把目标库当成源库，把原来的源库当目标库，通过realsync技术把数十万条数据复制到新的目标库。

随着天色由明变暗，由暗变黑，从傍晚到晚上，到深夜，到凌晨，天色又从黑变暗，从暗变朦胧，从朦胧慢慢地变亮了。

我们弄啊弄，整啊整，一直到凌晨三点才完全调试好。一会儿，天亮了，拉开窗帘，天好蓝，云好白。

又过了一会儿，上班时间到。野外施工日报照常上报，生产信息数据照常显示，使用人员照常查询调用数据。没有人知道昨晚发生了什么，只有我们红肿的眼皮和接二连三的哈欠——是的，我们就是幕后英雄，地下工作者，公司数据的守护者，就是人们常说的做好事不留姓名但留下很多照片的雷锋。妈的，那晚上真是累疯了！

05

岩芯扫描系统

岩心扫描系统是是一个独立的系统，它短小精悍，功能实用。尽管只有四张表，岩心筒次表，岩心图像表，岩性描述表，岩心剖面图，但组合起来却可以形成多种实用的图例。柱状图，对比图，甚至外表面滚动图，可以给你一个岩心图像全方位的展示。

从此以后，研究院及其他相关部门人员再需要查看岩芯属性的时候，可以不用再去岩心库了，一键点击，境界全出。

它就像《射雕英雄传》里傻姑的武功，尽管只有简单的三招掌法、三招叉法，呆呆板板，但由于有了高手黄药师的提炼与精简，使用起来也是威力无比，对付一般的应用场合已经绰绰有余了。

06

生产信息系统

生产信息系统是我所知的分公司第一个综合通用类系统。它的上线让分公司很多部门的话题有了一个共同的载体。当大家聚在一起谈起生产信息系统上的这个井深，那个进尺的时候，听的人就会心领神会，知其所指。

它是基于胜利油田05年的数据库建设部署的，有一定的先进性。之后中石化推广实施的源头数据采集数据库也是基于此，并进行扩展扩充而成。

生产信息系统包含钻、录、试油、井下作业、油气水井日报、原油天然气销售、联合站气站运行记录等多个模块。模块众多，功能强大。

从此很多部门从原始、低层次的EXCEL电子表格汇总、统计、甄别中脱离出来，跃入了PPT制作的高大上阶段，眼前多了可供选择的丰富的色彩。

07

​勘探综合信息系统

一看到“综合”两字，我就有点眼晕，因为综合两个字总让人想到大包大揽，无所不能。

的确是这样的，但凡公司里的部门或机构，一旦与综合挂上钩，不免让人想到：所有的繁琐，零碎儿都会划拨给综合。看起来高大上，干起来苦逼累。

而应用系统也是如此，一加上“综合”不免让人想到各种功能模块大荟萃，乱锅炖，一锅出。总之，一句话，需求部门总想把所有的功能全部加上去，恨不得连一个普通的小系统都能发邮件，购物，玩游戏。

所以要让一个综合类的系统做出彩，给人眼前一亮的感觉，也不是一件很容易的事情。

而勘探综合信息系统则较好地扬长避短，充分展示了自己优势和特色。

该系统集成了勘探综合数据库管理平台、地震成果数据库系统、测井数据库系统、勘探图形文档库系统等综合数据管理架构，实现了勘探结构化数据、地震叠后数据、常规测井数据、图形文档成功的综合管理。

两期项目共完成了N口井探井数据（探井基础数据、井斜数据、录井数据、测井解释成果数据、地层分层数据等）、N条Nkm二维地震数据、N个区块Nkm2三维地震数据、N口井测井数据及N张勘探成果图与勘探部署图数据的整理入库。

由于系统参与系统开发的人员是有着丰富物探专业的资深人士，系统完全是按照用户的体验进行的。所以系统建成后，很多用户都说不错，唯一一点就是项目完成后，很少再有新资料注入，上文中的N失去了变成N+1的机会，只能扼腕叹息。

08

勘探数据资源集成系统

勘探数据资源集成系统则仿佛在综合前面又加上了一个“大”字，就像是一个综合科变身升级为综合处一样。

该系统原想把分公司所有的与勘探相关的资源，从文档到成果，到数据体，到成果图等全部整合到一起，用一口型更大的锅，实现更高层次的大锅炖。

但是存在一些问题：由于楼上勘探综合信息系统和该系统具有很多相似相近的地方，本系统的建设没有把上一个系统的内容数据全部纳入吸收，在一定程度上造成了重复建设，出现了大锅烧火，小锅不停的局面。

09

OA综合办公系统

真没辙儿，又一个“综合”类系统来了。

开始的OA系统只是实现了总部公文的流转，分公司通知公告和内部邮件的收发，是一个天真可爱的小伙儿。后来随着他能力越来越强，背负的责任越来越大，more power，more responsibility，很多的功能逐渐附加到他的身上，会议室预订、领导日程、制度管理，考勤管理等等。

同时由于人缘不错，他还担当起替别人收快递的角色来——把别的系统的待办统一集中到自己的屋檐下，合同管理、费用报销、招投标审核、安全管理系统等等。

慢慢地OA系统不仅仅是分公司公文上下传达的通道，更是各种业务审批流转的枢纽。Leader们在上面大笔一挥，各种工作流便会奔向负责各项业务的相关部门，执行落实反馈。

随着身上背负的东西的越来越多，我不禁担心起他的小体格子来，生怕有一天会突然垮掉，留给大家一个永远的背影。因此我们平常必须对他百般呵护关爱，定期查体，甚至还准备给他升级随身装备，提高其战斗力。

1​0

僵尸榜

就像人买衣服一样，可能在挑选的时候，受到售货员或者陪同者的忽悠，虚荣心一下子爆棚，冲动之下购买了某件衣服。等回到家穿的时候，就会发现有一些之前没有发现的问题，于是穿了几次之后就束之高阁，淹没于衣柜中，从此被冷落。

应用系统建设也是同样的情况。宣传的时候，应用系统软件方会把系统描述的几近完美，功能齐全，用户体验好，问题绝迹。当我们头脑一热，选择建设上线的时候，会发现真正的应用效果并不像宣传的那样好，很多方面根本满足不了实际的工作或流程的需要。如果用过几次之后，业务部门的用户体验不好，就会选择利用老系统或者老手段，而毅然决然地放弃新系统，不再顾及你新来贵客的身份。

于是，在机房的某个角落里，出现了一台台近乎僵尸的应用系统。这些应用系统既不能删除，因为怕将来某一天某个人突然间想用，但又不能大规模地推广开来。所以就形成了一种鸡肋式的状况，食之无味，弃之可惜。

开发决策系统，地质图形管理系统、钻井设计系统（排名不分先后），这一长串的名字让我禁不住唏嘘长叹。

你们一个个都曾风华正茂，意气风发，壮志在胸，想利用自己的手艺绝活儿为某些部门冲锋陷阵，解决他们的后顾之忧。但是随着时间的流失，你们会慢慢发现自己并没有那么得宠，人们对你们的与依恋没有那么强烈。没有你们，照样玩得转。

如果在某次能力的展示过程中不慎出现纰漏，相关人员就会渐渐地抛弃你。很多时候他们并不是不喜欢你们，而是离了你们照样过得很好。你们没有真正戳到他们的痛点，挠到他们的痒处。

所以，如果你一直长期在一个无人光顾的角落里的话，忍忍吧。没有办法，这就是现实，人们就是这样的势利。

11

等等

注：这里的等等不是wait a while的意思，而是and so on的意思。

12

闭环与开放问题

对于很多部门来说，一个课题或者项目完成，基本上就可以束之高阁了。如果没有后续的检查或者查询之类，可能很长时间都不用再碰。我把这样的问题称之为闭环问题，闭环问题可能包括一个设计、一个标书、一份合同、一个总结的完成等等。

闭环问题，可以在实施的过程中，努力做好每一个环节、细节，完成后就可以高枕无忧。

而对于信息类项目，尤其是信息系统建设项目来说却完全不一样。项目本身的验收通过，只是标志这个系统作为一个项目承载体使命完成了，但对于信息系统的运维才刚刚开始。

作为信息系统运维人员，我们对于信息系统的推广与普及的态度是矛盾的。一方面希望大家能够普及推广使用，毕竟这才是我们建设应用系统的目的；但另一方面使用的人多了，势必会暴露发现各种各样的问题，让我们应接不暇，某些时候甚至疲于应付。

就算是共性的大问题都解决了，各种各样的个性小问题仍然层出不穷，需要运维人员耗费极大地的精力去应付。每新建一个应用系统，就多了一摊子事儿，并且这件事会一直伴随左右，只要应用系统不退出江湖。

13

闭环与开放问题

这些年经历让我对闭环问题和开放问题的学习有了不太一样的理解。

对于闭环问题可以在进行的过程中憋足一口气，在特定的时间段集中优势兵力把它拿下，一旦完成，马上扔掉，比如一场考试，一个课题，一份报告等等。

而对于开放性的问题的学习，则需要做好打持久战的准备，需要对进展过程中的每一环节都要关注，因为保不准某一环节的短板会影响整个项目大木桶的顺利完成。并且要用可持续发展的眼光和态度对待，因为开放性问题一般不是一个孤立的点，孤立的个体。它像搭积木一样，开始很小，很简单，随着各种部件的插入、连接、集成，系统体积变得越来越大，系统复杂度越来越高。

根据系统论的说法：子系统和功能点的增加与实施及运维工作量的增加不是简单的线性增长关系，每增加一个层级，其复杂度会因为各子系统间兼容、调用等问题，而如指数函数曲线图趋势一样骤升。

14

比如我们公司，把很多系统的待办功能比如合同管理、费用报销、安全系统、招投标系统以及督办系统都单点集成到OA这个统一平台上来了。从表面看来很整齐划一、保持队形，但实际上底层暗流涌动，风险隐藏。

不同的系统性情各异，相处起来难免磕磕碰碰，比不上自家兄弟亲近，经常会由于兼容性问题而打架，保不准某一天以一种什么怪异的方式展现出来，让你措手不及。

15

应用系统的运维也是一件很难整齐划一的事情。不论测试的时候如何信誓旦旦，上线时总会出现各种意想不到的问题：系统环境，IE兼容性，权限问题等等。除去系统本身的要求条件外，对操作系统的依附也是很强的。

随着系统越来越多，功能越来越零散，学习与维护的人越来越多，大家也感觉随之带来了各种各样的问题。

所以对应用系统的运维，不仅仅在于你对该系统各模块功能烂熟于胸，更重要的是对相关操作系统的熟练掌握程度。很多时候，一个钩，一个挑，一个选项的忽视都会让你懊恼半天。

16

“六统一”

“六统一”即：“统一规划，统一标准，统一设计，统一投资，统一建设，统一管理”，是中石化信息化建设的原则。

在“六统一”中的好几个“统一”实际上都是与顶层设计有关，而“统一标准”则是让我们在实际实施过程中有了一个切实的依据与抓手。

它要求我们在以后进行应用系统建设的时候，不能匆忙开工，要首先制定统一标准，遵循标准。把相关的技术标准梳理研究透后再动手，这样有时反而比匆忙下手来得更快，麻烦更少。磨刀不误砍柴工，慢即是快。

统一的标准可以让我们在独立开发单个应用系统的时候，不用纠结于用什么路数。路数已经规定好，你只需要用心打好自己的拳就好。

“六统一”诞生的过程，必定是艰难的，是很多次失败系统建设总结出来的血与泪的教训。它并不像这二十四字表面那么轻松淡然，而是一种返璞归真后的简约，烈火淬打后的重生。

各种标准不统一的应用系统就像是各种不同管径的输水管，尽管可以通过各种复杂的焊接、转换，接入，让水在管径不一的水管中流动，但是接口太多，弯路太多势必会严重影响输水效率。

多年来，有很多公司都想把我们这么多的系统整合起来，一统天下。他们都曾壮志在胸，志存高远，但却少了攻城拔寨，披荆斩棘的执行力。在脑海中想象一个宏伟蓝图容易，真正把蓝图上每一个细节都描绘生动却不是一件容易的事情。当他们接下这幅蓝图的时候，才发现，原来竟然缺了那么多的颜料，宣纸，勾勒。于是虎头蛇尾，中看不中用。

做的好的，也只是把各个系统独立王国，整合成一个松散，低耦合的联邦国家，而不是一个上下集权的帝国。

​如何彻底解决系统整合问题，我想还是应该回归与借鉴“六统一”思想吧。