carpnet
作者carpnet·2014-02-27 19:52
系统工程师·江苏省电信

回顾我的2013-云化如荼&去IOE小试

字数 2730阅读 17893评论 2赞 1

每逢岁末年初,总结计划总是难免的。过去的2013年并没有值得大书特书的地方,作为一个一线的技术工程人员,我一如既往当好螺丝钉,做好分内事,从事着系统运维的很多方面,虽不成体统(体系),但也属情理之中。我所说的,并非一己之力就能承担,只是从我的口中说出大环境下我所看所想所做的。

人云亦云,虚实两相宜

2012年我们公司就开始掀起了云化的序幕,核心系统上云才有说服力,于是试点上线、规模推广马不停蹄。云平台虚拟机模版复制、交付期短,使得我们维护的主机从两位数跃升到三位数。2013年进入了真正意义上的云化年份,新上线项目工程应用服务器主机一律使用虚机,老系统要加大云化进程力度,于是负责云平台资源交付的同事忙的不亦乐乎,虚机真如白菜价。我们维护的BSSBusiness Support System,业务支撑系统)作为核心系统之一,早在2012年就申请了几十个虚机搭建了几套集群生产环境;2013年已经从一窝蜂的“机”潮“机”海中抽身而出,想到了异地灾备,于是只能潜心静待另一个机房的云平台的诞生。因仅有一个机房部署的仅有的一个云平台,资源吃紧,捉襟见肘;云平台大锅饭,资源相互争抢,一时疲态尽显,危机四伏。同城异地机房云平台在2013年下半年才犹抱琵琶半遮面,千呼百唤始出来。我们果断出手,申请资源,在新云平台上搭建了2套集群生产环境。

我们所谓的云平台充其量就是企业私有云IaaS,基于VMware虚拟化,操作系统、安全基线、中间件提供预装,但应用部署还得靠自力更生。靠着厚脸皮吃老本的精神,我把以前积累的脚本重用,关键是WAS安装目录复制后遍历修改集群包含的所有节点的主机名,这样我就可以把既存的WAS集群生产环境从这个机房云克隆到另外另一机房云。自动化复制对等配置的环境,无论对于生产、测试而言,都是有莫大好处,这就不铺开了。

 IOE  ,从小试做起

在创新方面,大型国企不遗余力,模式往往是省公司(集团公司)搭台地市分公司(省分公司)唱戏。恰逢有机会在2012年见证亲历了一个创新运维小平台的应运而生。其作为一个集中化运维的平台,开发短平快,但是完全拥抱开源:基于web开发框架RailsRuby on Rails),采用NoSQL文档数据库mongodb,前端web服务器为nginx,通过封装ruby提供简化定制的脚本语言,封装数据访问层,IT人员可以稍加培训就可以编写脚本,显性化定时任务,进而共享和沉淀维护脚本和经验。一别于我们重量级的IHSIBM HTTPServerIBM定制化的Apache+WAS NDIBM J2EE应用服务器集群部署版,WebSphere Application Server Network Deployment+Oracle(关系型数据库老大)。该平台是某地市分公司的技术大拿的创意,并担纲了该平台的架构设计和开发。

2013年随着好评和上量,该平台也开始陆续出现了一些性能的问题。我作为维护者,不得不开始捧起mongodb的入门,翻看官方的参考文档,如小学生一般从零开始畏首畏脚操弄转储备份、性能优化。Mongodb本身提供的索引分析手段(先设定超时门限如3秒:db.setProfilingLevel(1,3000);后查询大于3秒的超时语句:db.system.profile.find({millis:{$gt:3000}});),就可以得到查询结果,直接作为呈堂证供发给开发人员进行分析优化。此外数据转储后的瘦身,最好停机后使用db.repairDatabase()能够回收占用的存储空间。

这么貌似微不起眼的小小平台,小范围使用、影响有限,但作为一个弄潮另类,我觉得它意义深远。它发出的声音并不高也不大,但它是发端,说不定后面就有很多平台系统、项目工程也会逐渐考虑去IOE、接纳开源,前赴后继,假以时日,将成大流。

交付监控,须到处化缘

本来没有我什么事情,只因为交付监控项目负责人忙不过来,几个月没有进展,于是项目改嫁转而落到我们头上了。业务交付过程监控,涉及的流程长、环节多,考核指标更不用说,首要任务便是要到各大环节系统的源数据,因为数据到位方能有米之炊。作为一个老龄酱油男,我只能厚着脸皮,开会协调、电话消息三催四请,好不容易要到主要系统的数据。

接着又是开足马力,在既定的方案框架上进入开发实施阶段。合作厂商项目组负责人比较有号召力和凝聚力,成员们也大多走南闯北项目经历丰富,理解配合支持,数据加工、前台开发,有条不紊地推进。

然后就是项目推介,试点上线,全省推广。使用铺开后问题bug的反馈及个性需求的接收,相应的版本补丁发布更新。

对于这种前拖后赶的工程项目,也算是一个奇葩。好在我们合力同心,拼力追赶,把前面拖延的进度给追回了一大截,但遗憾的是,我只能说,这个项目虽然是一个好项目,但是没有在合适的时间出现,项目延期导致给项目的推介上线推广带来了不可弥补的硬伤。

稳定安全,绝对很重要

一个系统的运维,先且不论需求设计开发上游环节,如果没有充分可靠的测试(我们是把测试纳入在运维之内),谨慎的变更管理,故障的快速感知分析处置,问题的锲而不舍跟踪处理,并周而复始,持之以恒,那系统的稳定性谈何容易。

2013年我们就是这么度过的。我的班头运维主管经理韧性十足,揪着问题不放,系统的变更大至版本补丁,小至网络配置修改,风险评估、检查评审,基本不少。特别是代码发生大变动的版本/关键补丁对系统性能的影响,时刻不掉以轻心,一旦发生问题,迅速反馈上游进行紧急修复。

安全在国企是常抓不懈,公司内部、监管部门及第三方定期或不定期安排或明或暗的漏扫,我们也是疲于应付,因为是漏扫是自动的,我们是人肉的,有些安全漏洞官方并没有提供修复的补丁或方法。Struts2框架远程命令执行漏洞也不可避免波及我们,因为我们工程包众多,有少数是采用Struts2类库。于是公司上下,公网、内网应用纷纷进行整改。

 

就是在云化大工地、去IOE小试样的尝新变奏和业务监控化缘、系统求稳保安的永恒主题的碌碌中,走过了2013年。充实,但是也并非是工作狂。晚上和周末尽量能不加班就不加班。每个月老夫老妻在工作地点折中的电影院去看一场电影;周末天好一家三口有时也出去转转挤着电动车到三公里外的购物广场,儿子喜欢坐地铁就不时带他去坐坐地铁;下了班回家,妻子忙不过来,我也绘声绘色给儿子翻来覆去讲小火车托马斯和朋友们的故事……日复一日,平平谈谈,这就是我的2013。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

1

添加新评论2 条评论

wudanwudan其它IBM
2014-03-05 14:16
赫赫,写得挺好,很赞同“一个系统的运维,先且不论需求设计开发上游环节,如果没有充分可靠的测试(我们是把测试纳入在运维之内),谨慎的变更管理,故障的快速感知分析处置,问题的锲而不舍跟踪处理,并周而复始,持之以恒,那系统的稳定性谈何容易。” 去IOE这一块,作为一个新的动向,在对原有架构瘦身的同时,对技术、对技术人员、对经验的要求也更高,比如大规模环境下的性能、管理、稳定性。
请叫我航哥请叫我航哥软件开发工程师IBM(苏州)
2014-02-28 16:13
  不错,支持一下!
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广