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

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

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

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

• 有想法

• 沟通

• 做事情的效率和产出

• 团队协作能力

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

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

我做了一些提炼，有一些经验和建议：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 开发架构

• 运维应用平台开发

• 应用内核开发

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