写写最近的工作

上周过的很糟心,旧槽点没吐完呢新槽点接二连三的来了,心力交瘁裸辞的心都有了。但是想到还得交房租还得吃饭,读书还太少,不能太任性,还是先吐吐槽吧。

周一,安全部门扫到一批有严重安全漏洞的服务器,由于没有完善的监控系统,对服务器的掌控能力很弱,非常原始的依赖手工修改服务器设置。博主对手工做重复的事一直非常抵触,面对这些有着乱七八糟问题批量功能不好用的服务器,无头苍蝇一样乱忙,搞得头昏脑胀情绪低落。然而这还不算完。

一夜回到解放前

平时工作的机器也不幸中招了。但是具体怎么中的没有任何说明,直接就给拔网线了。这机器开了rsync服务,平时工作都从这里rsync脚本。一下子没了挺不方便的。好在cloudstack平台有个vm搭了git server,存储了大部分工作脚本。可是屋漏偏逢连夜雨,周二早上一来,cloudstack平台也出问题了,console proxy vm无法启动,user vm也都无法启动。这机器没放机房,几乎每天都很暴力的直接拔电源,开机时时常会遇到一些问题。由于一直只是当虚拟机管理软件用没有深究过,之前遇到类似问题重启下就ok了,这次怎么重启都不行,一冲动,就直接重置了cloudstack环境。就这样,git server一时半会也恢复无望了。焦虑中居然忘记了自己电脑上的那份代码。用另一台rsync服务器上的很老的代码做了几个提案,感觉好容易才实现的半自动化瞬间要回到刀耕火种的原始社会了,难道又要开始ctrl-c,ctrl-v的运维生涯了么。。

重装cloudstack

每次安装cloudstack都挺抓狂。周二忙了一下午也没重装成功。Secondary Storage VM始终无法成功创建。日志中大量类似下面的内容:

身上提案也没心情做了。周三继续,居然在自己的wiki中找到了之前记录的解决方法。。。

 恢复VM数据

周四几乎都在折腾恢复cloudstack的VM的事了。都忘记了周三许诺同事周四要完成的一个提案。等下班的时候才给我打电话==,只好等周五做了。恢复VM的事也没能完成,对kvm不太了解,一开始想简单的将primary下的qcow2镜像导入cloudstack模板或者存储,结果都失败了,注册模板倒是可以成功,但就是不能启动,添加存储也可以成功,但是无法挂载。

周五。周二的情况又出现了,Console Proxy VM死活无法启动。够了!再重装非疯了不可,一定要找出解决方法。这次运气比较好,通过日志搜到了cloudstack邮件列表里的类似问题。

I have the following issue:
After emergency reboot of hypervisor node (i.e. reset via ipmi), system vms
got stuck in "starting state":
http://thesuki.org/temp/ss/SS-20130416154808.png

When I look onto console through vnc I see either prompt for fsck or errors
related to r/o mounted root fs:
http://thesuki.org/temp/ss/SS-20130416155009.png

There is no way to destroy vm either from web interface or api
(cloudmonkey):

 cloudmonkey> destroy systemvm id=eb3adb37-96d1-4785-884d-5958526b75fc
Async query failed for jobid 3c2fd0d7-a0a0-427a-ae3e-dda96b7cf9e0
Error 530 We cannot stop VM[ConsoleProxy|v-1058-VM] when it is in state
Starting
 cloudmonkey>

I have to manually update state in mysql before I am able to destroy this
vm:

mysql> update vm_instance set state='Stopped' where name='v-1058-VM';
\Query OK, 1 row affected (0.08 sec)
Rows matched: 1 Changed: 1 Warnings: 0

 cloudmonkey> destroy systemvm id=eb3adb37-96d1-4785-884d-5958526b75fc

OK,终于找到了可以不用重装就解决问题的方法。可是VM数据还是没有恢复。眼看就要放假了,提案不能在托了。抓紧时间将工作机的数据恢复到了线上机器上,重建了rsync服务器。之后完成了一个改IP的提案,四台机器,脚本批量改,抓包确定交换机端口,脚本修改通道IP数据,终于不那么抓狂了。之后又完成了一个管理卡不通的提案,有十多台,好在都是因为模式问题,ipmitool raw 0x30 0x24 2,批量一个命令搞定。在快下班的时候,十多个提案居然全做完了,一身轻松的感觉,真好。

然后专心恢复VM数据,也找到了思路。用qemu-img info看VM镜像时,可以看到backing file.

直接将其转换为其他格式,会提示backing file不存在。由于重置过cloudstack环境,backing file都没在新环境的/primary下了。但是备份中还是有的,将备份中的移动到新环境,在转换,果然就OK了。

对backing file还不理解,但是转换的vmdk可以在vmware下挂载了,数据也都还在,下班的时间也到了,终于可以开心的过一个假期了。关于backing file,这篇文章挺好,存着备用。

在cloudstack上折腾上载卷时,遇到过挂载失败然后一直卡在Copying状态无法删除的情况,受上文提到的邮件列表的启发,直接操作数据库改状态,然后就可以销毁错误的卷。

 一点思考

我之所以觉得工作很糟心,是因为做事的方法流程有很多很无聊的过程,大量的复制粘贴工作,大量的没有意义的通话,像个客服,像个搬运工,就是不像工程师。我的典型的工作状态:

  1. 事件追踪系统中业务方提故障提案,一般只给出个IP或者资产号
  2. 登陆服务器,如果可以直接解决还好,如果需要登陆管理卡,就需要查询管理卡IP,需要外包解决的就要查位置信息
  3. 把IP或者资产号复制下来,到CMDB中粘贴查找,获取服务器详细信息
  4. 登陆管理卡,或者把业务方提案中的内容和CMDB中查到的服务器位置信息复制下来写成工单给外包,外包工单系统还有很多体验很差的表单要选
  5. 值班,接听电话,虽然那个电话号称是紧急故障响应电话,但是有大量不需要即时反馈的事情,大量NC的事情诸如某个软件怎么使用,某人的分机号是多少之类,把人当客服了。总是被强行打断,处理很多只需要写个FAQ就能解决的事情

我希望的工作状态:

  • 运维的核心应该是监控。应该围绕监控做事,主动发现故障并及时排除故障,事件追踪系统只应该作为一个辅助:监控发现的问题在事件追踪系统做一个问题解决过程追踪记录即可。但是我司目前的情况很被动,针对基础运维(管理卡,账号,硬件等)没有完善的监控,需要业务方遇到故障后在事件追踪系统写提案,然后由我们处理。其实我的很多工作量都完全可以在未发生影响的时候就自动解决。比如管理卡模式错误问题,监控做好了,随时可以修正,还有账号,随时修正,目前每天需要处理很多账号无法登陆的问题。
  • 运维系统之间的协同非常重要,内部系统也需要用户体验。我司目前各种运维系统各自为政,用户体验非常差,效率也不高。还是要说事件追踪系统,这个系统的表单太过灵活,虽然能抓到数据,但是由于可以随便填,几乎无法自动化处理。举例来说,有个域名处理的系统,暂时不吐槽这系统使用体验有多差,只说做事流程,某些域名的添加需要在事件追踪系统手动写提案,表单数据乌七八糟,没有统一格式,这样也就无法适配其他各种运维系统,导出他们需要的格式,这样,我的工作就成了搬运工,ctrl-c,ctrl-v,无聊至极。还有很多其他系统需要做搬运工,说多了都是泪,就不说了。所以,事件追踪系统至少在基础运维这方面,应该由其他系统自动推送工单数据到事件追踪系统,而不是以事件追踪系统为核心来做事。主要的流程应该在各自的系统中完成,事件追踪系统仅作追踪之用。
  • 监控的基础是CMDB,CMDB的数据应该是其他系统自动插入,而非人工修改。而且CMDB应该是模块化的,最核心最简单的只需要一个资产库即可,采购的机器资产号硬件配置直接导入资产库,之后IP,交换机端口,操作系统等配置信息应该是其他运维系统自动向CMDB更新数据。
  • 理想的工作方式:CMDB和监控非常完善,基础运维对机器有很强的控制能力,时刻把握每台机器的状态,用监控主动修复大部分问题,人工只解决有意义的问题,而不是无头苍蝇一样的乱忙。业务方可以看到自己管理的机器的状态与警报,选择警报机器,自动生成包含详细机器信息及故障信息的工单到事件追踪系统,基础运维无法远程解决的问题可以一键生成外包工单。外包的反馈可以自动回推到事件追踪系统。
  • 内部论坛。写个FAQ,有效减少NC问题。

参考资料

5 thoughts on “写写最近的工作

回复 annhe 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注