不过劳动劫!技术人完美渡劫的七个姿势

助你渡劫的DBAplus社群 2018-04-28 20:00:37

五一劳动节近在眼前,连上6天班盼来的3天小长假格外可贵,但小编发现,不少兄台在假期里还要加班加点、忙碌不堪……也是,做IT的,谁不是一不小心踩个坑,两三倍的工作时间就耗进去了,瞬间劳动节变劳动劫!

 

咱们先来分享一波踩坑遭遇,让同病相怜的童鞋有个机会彼此拥抱,至于如何终结这些饱含血泪的踩坑历程……(悄悄告诉你们,后文有惊喜!

 

那些年的辛酸史
 

 

 

踩坑1号

起初我只是看热闹,结果……后来我成了热闹……

 

有一段时间公司缺Hadoop运维人员,作为Hadoop运维的我,周末开始尝试在服务器上搭建集群。

 

当时搭的感觉没啥,到了转天上班,一到公司就发现我们部门领导周围围了一圈人。我放下包坐下来一打听,才知道xxx集群不可用了,线上应用全部报错,我当时还跟同事开玩笑说,这么重要的集群怎么会出问题,这弄坏的人会不会给处分被开除啊。

 

然后我就坐下来听他们一直在讨论,他们说前一天下午4点开始报错的,领导还在那儿上服务器检查东西,发现Namenode被格式化了。

 

领导就问我们昨天谁操作了,我说我在其他服务器上搭建集群来着,顿时我有点莫名的恐慌。然后领导去那台服务器上查,突然说:我嚓,你配置文件是不是从那个集群拷的(出事的集群)?我说是啊,说完我就意识到,完蛋了……配置文件没改完,在搭建集群的时候有一步给格……式……化……了……

 

我当时直接蒙圈了,现在想想都觉得好丢人。可能你们会问后来怎样了,但我什么都不想说,只能告诉你我有个好领导,把这个事儿摆平了,论好领导的重要性……

 

踩坑2号

脑子断片,有一种英雄气短、死于非命的悲惨感

 

公司DB2数据库,生产跨库Load游标数据忘记加Nonrecoverable,导致表空间挂起,还是挺大的一个表空间。还好备份表空间时间不长,影响作业不多。有时脑子断片,操作时关注点集中在自以为高大上的知识点上,忽略基本准则。有一种英雄气短、死于非命的悲惨感。

 

 

踩坑3号

当时腿都软了,差点就要跑路

 

公司自用的流媒体服务器遇到故障,网站无法访问,后面确认是文件挂载问题。我测试时建了个软链接测试,测试完确认问题后rm -rf软链接,结果就在两秒后我意识到问题,马上按了Ctrl+C,我擦,视频被我删了差不多200g……这个网站不是我负责维护的,是我们女同事在维护,如果是我,我会做定时备份,而她视频没有备份。当时腿都软了,差点要跑路。后面找到办法,就是重新在Web上传,重新转码,搞了我一个周末,谢天谢地。

 

 

踩坑4号

要不是我活好,当时我就哭了

 

记忆犹新的之前在用Icinga(类似于Nagios)做监控的时候,有一次删除配置文件时,一不小心将整个配置目录删掉了!我擦……当时都快哭了,幸亏活好,主机信息文档又全面,不到3个小时就恢复了。之前考虑过用开源的恢复软件,考虑到要Unmout磁盘,但是风险都太高,最后放弃了。

 

前事不忘后事之师啊,现在的风格绝对妥妥的。尼采说过:What does not kill you makes you stronger,所以说,坑还是有价值滴!

 

 

踩坑5号

全公司开发组看着我撞坑,我内心是绝望的

 

那个时候是被老大抓去帮忙同组里开发的另一条产品线上的组织树,数据虽然在缓存里,但是特定时候对于业务有冗余,虽然只要展示有用的组织结构,但还是要保持完整的树状,不能断开。

 

自己想好了算法去过滤有用的组织,再把断开的组织树分支接起来。本地测试,测试同学都没测试出问题,结果上线之后发现一台机器CPU跑满了!我们公司监控是直接展示在开发大厅门口的,全公司开发组都能看见。你知道当时我有多绝望吗?被老大骂得狗血淋头,拿下来Dump日志分析,最后折腾出来后才发现原来是赃数据导致,也就是A的上机是B,B的上机是A……结果就是找的死循环了……

 

踩坑6号

从此再也不相信第三方了

 

我的坑是队友造的锅!最坑的那次是版本1.0.2的时候,一个机器的硬件识别功能突然走不下去,1.0.1还好好的。接着组长拉着我周六加班到十一点,周日上午继续调试!

 

到最后,我们才发现是硬件供应商的底层接口悄悄改了变量名!问题是之前问底层有无修改是再三保证没问题,当undefined提示出来后就无话可说了。从此再也不信第三方的鬼话了,必亲调!

 

踩坑7号

4K+的数据对象灰飞烟灭……

 

去年一个项目是与某企业活动目录AD有关的(AD是个类似于数据库的概念),要开发一个AD的Web控制台,其中包含了删除AD对象的功能。有天下午,还未完全清醒的时候登录了服务器,然后部署新版本,结果手贱点了删除功能,对跳出的确认框连看都没看就点了Y。突然不知怎么就觉得有什么地方不对了,10秒后,4K+的数据对象灰飞烟灭,瞬间睡意全无!十多分钟后,又注意到这是测试服务器,没有连接到正式环境,万幸……然后重新导入数据吧。

 

  劳 动 节 ?
  劳 动 劫 ?

 

不知这些血泪史中可有你的身影?总的来说,踩坑的原因千奇百怪,避坑的本质九九归一,要想从根本上解决这些苦逼遭遇,就要抓住要点,从思路上减少踩坑的可能性。

 

为此,我们特别请到DBAplus社群联合发起人、《Oracle DBA工作笔记》作者杨建荣老师,就运维工作中的经验和教训总结出了一些思考,从思路上给出了技术人都通用的宝贵建议:

 

对自己的思考
 

 

在运维工作中,我也经历和变换了一些角色,对我来说,行业里大家都彼此熟悉,我也会偶尔成为“意见领袖”。但是我发现工作中的事情需要落到实处,基本有几点需要明确:

  • 有想法

  • 沟通

  • 做事情的效率和产出

  • 团队协作能力

 

当然这个从空降或者一蹴而就来入手,显然是阻力比较大的,除非给你的角色具有压倒性的力量。

 

所以对于工作的事情,我也做了一些思考和总结,总是在想:我的目标是什么?我现在的状态是什么?我现在和目标的差距有多大?问题到底出在哪里?

 

经验和建议
 

 

我做了一些提炼,有一些经验和建议:

 

1无论你是否是专家,都要接触业务

 

运维的意义是业务驱动,一旦脱离了业务,你会发现做很多事情会比较被动。比如你要做业务优化,但是不知道该怎么去对接业务方;你要做出一些建设性意见,脱离了业务方的反馈,会发现计划和反馈会有很大的出入;越脱离业务,会纠结于很多不是问题的问题;还有一点,我觉得更加重要的是,脱离了业务,其实也是增加了代沟,你的成果他无法感知,他的痛点你也无法体会。

 

所以无论你是否是专家,都要接触业务、深入业务、优化业务,纵然接触业务会花掉不少的时间,我觉得能够阶段性地投入、有针对性地投入,还是值得的。

 

2你的工作量

 

其实我以前比较排斥工作周报,汇报工作也是阶段性来做。

 

但是显然,从我的角度来说,很多工作虽然做了,工作量却很难体现,比如公司会给我安排一个里程碑的任务,同时对于运维工作,我觉得部署安装是基础功能,备份恢复要提前搞定,从技术发展来看,要跟进新技术预研;从业务的支持来说,业务方的需求还要尽力满足,势必会有一个比例的投入和优先级。

 

所以,如果只是按照一个核心里程碑事件,其实我可以工作的相对很轻松,但是事情自己不深入来做,已有的问题还在那里,后期要更正会更加纠结。与其这样,不如提前发挥自己的余热,把这些事情先搞定。

 

所以我决定做一些改变,就是多承担一些任务、多做一些事情。虽然工作确实忙了不少,但是你会发现,你解决了很多潜在问题,对自己推进工作和给同事减压都是很好的辅助。

 

3工作的形式和输出

 

我以前的认知中,对于形式其实不是很看重,觉得事情做好就行。换个角度来理解,我觉得这就跟大家去考取一个证书一样,哪怕这个证书现在已经不重要了、市场上的认可价值没那么高了,但是你通过自学完成了系统的知识结构,同时也能够结合工作做一些补充,那么这就是一个实质性的工作。至于考取证书,就是一个锦上添花的状态。

 

我们对于工作的形式和输出就是这个锦上添花的补充。

 

有了当然更好,如果没有其实也可以,但是如果有这么一套考核的标准,是你的干嘛不去争取?如果用数据库来打比方,就跟系统权限和角色一样,系统权限是一些很零散的权限形式,基于对象级,太多了也没人去关心,自己都不记得了;但是如果打包成角色,其实就有一种一目了然的感觉。

 

4你需要主动发起一些事情

 

磨合了很多事情,如果这个事情的结果导向不是很明确,或者大家觉得这个事情可做可不做的时候,能不能继续做下去,就需要看一些核心的推动力了。

 

比如,在碰到一件事情的时候,你最好是自己主动来针对性地发起和跟进,否则这件事情很可能就是不了了之,你觉得大家应该重视,大家觉得应该由你来发起,结果出现了GAP,难免会上火和焦虑。我们的生活和工作中有太多的不了了之的事情。就好比我现在发起的自动化运维分享群,或者是要推动的一些方向性的事情。

 

5无脚本不欢,以手工操作为耻

 

我在和不同行业、角色的人聊天的过程中,发现大家对于运维的很多理解都是基础运维。

 

其实,这就跟大家走一个高空栈道一样,运维好比是两边的护栏,没问题的时候看起来意义不大,但是自己走的时候发现确实很需要。说明确一些,就是工作中,尽可能脚本化、工具化、流程化来处理问题,尽可能不要手工敲命令来实现,要以手工操作为耻。

 

我觉得我们自身对运维的理解要上一个台阶,如果你的工作内容都是基础运维(服务器部署安装、环境配置、权限开通),那么你的角色就很危险了。这种工作今天可以手工,明天可能就不需要了。

 

6小环境里的大智慧

 

有很多同学都会说自己的公司的环境规模太小、很多方面不够规范等问题,但是这些问题只有抱怨是解决不了的。就算你一任性,一走了之,那么问题在其他的公司也会或多或少有类似的体现。

 

我要强调一点,任何级别的公司都会有大大小小的问题,绝对有很多是让你觉得明显不合理的细节。我建议大家不要总是抱怨,就算是抱怨,也要同时提出有建设性的意见。

 

有些公司,文化层面上,价值观没法改变,但是运维细节的改进还是很有实践意义的。比如我举一个具体的例子,MySQL中的Online DDL,如果你要维护管理很多版本的环境,一个500万级别的表需要添加一个字段,那么这个操作该怎么做?如果你手工添加,基本也是秒级就可以完成,但是你如果再用心一些,针对不同版本,使用工具来完成,虽然看起来有些啰嗦,但就是这些细节能够带给你诸多经验。一旦数据量到了千万级别,你也有了一些基础的经验,你会觉得运维这个活儿是个手艺活。

 

7运维的几个进阶角色

 

对于运维的路该怎么走的问题,方向有很多,边界也有很多,从我的理解来说,我觉得可以有很多的进阶方向。比如:

  • 开发架构

  • 运维应用平台开发

  • 应用内核开发

 

没有什么事情是那么简单就能完成的,这些方向可以根据自己的能力和定位来针对性地投入。现在知识更新很快,我们的理念其实也要不断跟进、不断更新。

 

 

看完杨建荣老师的思考和建议,大家有没有一些豁然开朗的感觉呢?要想在工作中尽可能避免踩坑,除了这些必不可少的工作方式要落地之外,细心与耐心也是必不可少的,不然……看看本文开头那些血与泪的遭遇,大伙儿心里还没点A与C之间的那个数么?

 

活动预告