【博文推荐】那些年，做过的项目

进入IT这个坑转眼快10年了，从开发到运维到DBA，一直做着***层的工作，干些琐碎的事情，今天来巴拉巴拉那些年做过的项目，告慰一下失去的青春岁月！小项目就不提了，讲几个拿得出手的。

[[136782]]

***个拿的出手的项目是广东移动的多媒体痤席项习，时间大概是2007年十月、十一月左右吧，多媒体坐席是个什么东西呢，它不是东西，它其实是广东移动网 页版的10086系统（类似于QQ），是广东移动布局互联网服务的一个入口，也是为了在不方便打电话的情况下，还可以通过网络来解决服务问题，不至于出现 服务肓区。项目的系统架构：终端  + 集群应用服务器 + 集群中间件 + RAC 9I数据库，开发语言：Java + PL/SQL。

项目初期各种资源投入很到位，项日进展也很顺利，但到了后期情况就有所变化了，主要是2008年广东移动开始进入3G网络时代，现有的一套系统是2003 年建立的，面向2G网络的，己不能满足3G业务的发展需要了，一套全新的系统已经开始规划，不久就要开始实施。而这套多媒体坐席系统还是2G网络的一部 分，显然已经不能适应3G业务的发展需要了，因此这个项目处于一种尴尬的局面。既不能上也不能下的状态，上呢迟早要淘汰，下上呢做了一大半，以前的努力就 白费了。因此项目后期资源投入跟不上，一些问题拖着无法解决。

主要问题有消息丢失、消息分配不及时、消息重复分发等，而这些问题都比较棘手，因此天天要进行跟踪，分析日志、修改代码。但是这些问题也不是天天都有的， 基本都是在业务高峰时可能会出现，所以就给跟踪分析带来很大困难，你跟时不一定会出现，而且跟踪时会影响系统性能，如果等问题出现了再跟己经来不及了，这 就是问题的棘手之处。但是客户他不管你这些，他出了钱就要一个能正常使用的系统，你说日志跟不到无法定位，这不是理由啊！因此搞的我们见了客户就像老鼠见 了猫一样，都躲着走。后来实在没法再拖了，才从总部了来了两个研发到现场解决，再加上市场的忽悠，问题总算是解决了，客户才在验收报告上才签了字，项目总 算是搞完了。 

   这个项目客户虽然拖着不签字，但不代表客户不支持我们的工作，相反在项目中客户还是给了我们很大的支持，比如我们怀疑移动的内网可能有拦截敏感消息的可 能，建议***能去外网测试，客户马上就安排十几个人去网吧测试，没想到还真与网络有关。说实在话如果客户不帮你，要自己找一批人测试也不是一件容易的事， 这也是我这么多年做项目唯一的一次难忘的测试经历。所以和客户多交流多沟通，充分利用客户的资源，对于顺便的完成项目是有很大帮助的。包括后来做的几个项 目，客户都给予了很大的帮助包括吃饭住宿等，在此也要对客户表示感谢。

   对这个多媒体座席项目的评价是‘累、散、慢’。

#p#

2008年广东移动主要的项目是BOSS 的项目，我们客服主要是协助BOSS方面做技术支持工作，做为双方的接口人，定位出测试中发现的问题到底是那方的，由谁来解决。先后参与了广东移动八地市动感地带回割项目、中山移动OCE回割智能网项目，地点都是在中山市。这种项目都比较大，参与人数较多，厂商也不是单一的一家。项目的组织架构也较复杂，都是项目总指挥负责制。由移动方出任项日总指挥，各厂商出任付总指挥，下设若干职能小组，每组一个组长，组员是混合组成的。

动感地带回割项目，就是把动感地带的计费由以前的其它系统全部割到由BOSS系统进行计费，项目是封闭式开发，比较辛苦，但是这个项目的待遇比较好，项目经理天天晚上领着一帮人去喝酒，到***一听到喝酒两字都想吐。每周还有一次自助餐吃外加一次外出活动，如去中山市外爬山郊游，项目场地还有娱乐健身器材，总之项目活动是很丰富的。不像有的项目从早到晚都是一件事，埋头苦干写代码。这个项目是我做过的最爽一个项目，主要是项目主体不在我们这边，所以不用操太多的心，完成自己的本职工作就可以了，以致于***都不想离开了。项目***割接的时候，中山市电视台还进行了现场报道。对这个项目的评价就是一个字‘爽’，这个项目同时也验证了一个道理，就是有钱好办事，钱能把所有人团结起来，不管你们互相认不认识，只要你们都认识钱就行了，看来钱这玩意真是个神奇的东西！

进入2009年主要是在东莞做项目，先说下东莞的地名：横坑、小坑、长坑、井上等等，听听这名字，不是坑就是井，不坑也不行啊！移动客服的地点也比较偏僻，东西北三面一公里内是荒芜人烟的。2009年的***个项日就是广东移动一级客服项目，这是个内部的报表系统，就是省公司把各地市公司的运营数据抽到省公司的数据库，然后再进行各种处理展示，以便省公司进行分析决策。系统架构与上面的几个项目一样，广东移动的主要系统架构基本都是一样的，这里就不重复了。当然了这个报表系统就是多了两层的数据抽取转换，***层是从六大中心的数据库进行数据抽取，加入省公司的数据库，还有一层是在省公司的数据库中进行数据的再次处理，别的都一样。

项目过程也没有什么多讲的，资源到位项目进展很顺利，唯一不好的就是要常去机房，但是那块的交通不方便基本上无车可座。因此只能搞个旧自行车骑着去机房，吃饭也不方便，属于拿着钱也找不到花的地方，只能靠泡面解决了。为什么这个项目和上面的项目有天壤之别呢？除了地理因素外，还有一个核心的问题，就是没钱。准确的说是没有多余的项目活动经费，没钱只能是吃泡面了，拿什么吃肉喝酒啊！这是我做过的待遇最差的一个项目，还好项目本身没什么问题，早早完工了，自己也早点解脱。

   对这个项目的评价是‘苦、累、差’，太差了，差的不得了！

#p#

  2010年12月底项目实施过程中， NGCC系统发生了一次重大的故障，当时的处理过程和上月底支付宝故障的处理过程有点相似，在这里来说说吧。故障的原因是一台数据库主机的交换分区耗完了（是P595主机的配32个CPU 96G内存），但是主机并没有宕掉，导致服务不能自动切换到另一台主机上，当时的影响是广东移动半个省的10086电话受到影响，而时间大概11点多，已经进入了业务的高峰期。这是个非常严重的故障立刻上报省公司。分析故障***给出的解决方案是关掉监听，让应用自动切换另一台主机。把方案上报后，等待省公司领导批准。但事情并没有想象的那么简单。为什么呢？就是因为有一套应急系统在那放着。***省公司的领导让切到应急系统上，先让主流程开始服务，其它的问题后续再解决。

好吧，领导让用应急那就用应急吧，结果应急系统上面还是旧系统的流程文件，马上从新系统上拷贝一份完整的流程文件替换到应急上面，修改配置，启动相关服务，大概20分钟左右完成，至此10086电话可以打通了，当然只能提供主要的流程服务。时间已经过了1个多小时了，主流程可以使用了，下面马上解决主机交换的问题，修改交换分区重启主机，几十分钟又过去了，主机终于搞好了，数据库能正常使用了，再次上报省公司领导是否马上切换回来，因为应急系统无法提供完整的服务，等待.................，终于领导下令了切换回来，切换很快完成，故障解决了，但是时间已经过去了两个多小时。

支付宝的故障是怎么处理的，我不清楚，但估计不是那么简单的进行二选一（即让高层领导在启用应急和重启服务之间做出选择），少不了要层层汇报，同时还要给领导讲出充分的理由，为什么要这么做，利弊是什么。然后领导们再进行决策，估计是集体的决策。领导也要考虑责任问题的，集体的责任总比个人的责任强吧！所以事情没有我们看的那么简单的，绝对也不会简单的。 我们可以把问题看简单，但领导不能把问题看简单，这恐怕就是为什么我们当不了领导的原因吧！

2011年离开通信行业进入互联网行业，也做过一些项目，如某公司的CRM系统，某电商公司的分布式服务平台项目（系统架构：LVS + 集群应用服务器 + 11G RAC，前端使用DNS加速，后端使用memcache缓存），对这些项目的感受是，无论从规模上、技术上、项目管理水平、项目参与人员的素质等方面，与广东移动的项目都有很大差距。别的不说，没钱没权，什么也干不了，干了也干不好，我曾经遇到个只有几十万的小项目，拖拖拉拉一年多，***项目不了了之，买方拿到的东西不是他所想要的，卖方说那点钱只能做出这个啊！***买卖双方都是一无所得。看着都累，更别说做了。经常有人问，项目成功靠什么，什么时间、成本、质量、范围，狗屁！我看靠的就是权和钱，没钱没权拿什么做项目、拿什么笼络人心、拿什么吃吃喝喝、拿什么进行黑幕交易，在这个非常现实的社会里，必须先解决这些非常现实的问题，然后才能开始做项目，当然了时间、成本、质量、范围、沟通也是很重要的。

以上就是本人那些年做过的项目，就先唠叨到这吧！