不过劳动劫！技术人完美渡劫的七个姿势 - 职场生涯

咱们先来分享一波踩坑遭遇，让同病相怜的童鞋有个机会彼此拥抱，至于如何终结这些饱含血泪的踩坑历程……（悄悄告诉你们，后文有惊喜！）那些年的辛酸史    踩坑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运维的几个进阶角色对于运维的路该怎么走的问题，方向有很多，边界也有很多，从我的理解来说，我觉得可以有很多的进阶方向。比如：
开发架构
运维应用平台开发
应用内核开发