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

开发 项目管理
进入IT这个坑转眼快10年了,从开发到运维到DBA,一直做着最底层的工作,干些琐碎的事情,今天来巴拉巴拉那些年做过的项目,告慰一下失去的青春岁月!小项目就不提了,讲几个拿得出手的。
 本博文出自51CTO博客srsunbing博主,有任何问题请进入博主页面互动讨论!
博文地址:http://srsunbing.blog.51cto.com/3221858/1657672

进入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缓存),对这些项目的感受是,无论从规模上、技术上、项目管理水平、项目参与人员的素质等方面,与广东移动的项目都有很大差距。别的不说,没钱没权,什么也干不了,干了也干不好,我曾经遇到个只有几十万的小项目,拖拖拉拉一年多,***项目不了了之,买方拿到的东西不是他所想要的,卖方说那点钱只能做出这个啊!***买卖双方都是一无所得。看着都累,更别说做了。经常有人问,项目成功靠什么,什么时间、成本、质量、范围,狗屁!我看靠的就是权和钱,没钱没权拿什么做项目、拿什么笼络人心、拿什么吃吃喝喝、拿什么进行黑幕交易,在这个非常现实的社会里,必须先解决这些非常现实的问题,然后才能开始做项目,当然了时间、成本、质量、范围、沟通也是很重要的。

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

 
责任编辑:王雪燕 来源: 51CTO
相关推荐

2015-05-15 10:04:28

localhost

2021-07-14 11:13:46

线程性能优化阿里云

2015-07-01 10:25:07

Docker开源项目容器

2015-06-17 09:34:09

软件定义存储 云存储

2015-09-29 10:26:51

pythonlogging模块

2015-12-10 10:13:22

2014-12-12 10:46:55

Azure地缘组affinitygro

2015-04-07 09:32:57

phpSocket通信php出现错误

2022-04-18 11:05:36

开源github代码库

2015-07-29 13:46:27

OpenStackIcehouse私有云实战部署

2014-12-24 11:13:06

可用性集availabilitset

2012-05-29 16:33:59

灾备

2014-10-23 09:31:07

post-commitSVN

2014-12-22 11:04:30

Windows AzuiPhone虚拟机

2014-12-01 10:33:51

Python

2015-04-21 09:28:58

ockerdocker监控平台监控

2015-05-13 11:37:58

openstack测试网络连通

2015-03-09 14:53:04

OracleOracle DGDataGuard F

2014-11-25 11:33:35

2014-12-11 10:31:22

网络优化KVM
点赞
收藏

51CTO技术栈公众号