运维是个坑，盘点背锅侠的点点滴滴~

运维是个遇坑、填坑、再遇坑、再填坑，有些时候还被同事挖坑，duang的一下掉下去了，还要自己慢慢爬坑；有些却是自己了解不够深入，或不够细心所留下来的坑。

小编认为，在实际操作中遇到了多多少少的坑，只有运维人们共享所遇到的坑，才能更快的定位与解决这些烦人的坑，所以小编针对运维这个坑准备了几个问题，下面我们就来看看网友们都有哪些精彩回答吧！

讨论话题

• 1.你遇到过哪些的坑让你印象深刻？你是如何解决的。
• 2.有哪些细枝末节的坑你是想提醒一下身边的运维伙伴的？
• 3.谈谈出现坑的主要原因与如何规避它们。

1.你遇到过哪些的坑让你印象深刻？你是如何解决的。

2.有哪些细枝末节的坑你是想提醒一下身边的运维伙伴的？

3.谈谈出现坑的主要原因与如何规避它们。

精彩回复

【撒加】

1.你遇到过哪些的坑让你印象深刻？你是如何解决的。

我影响最深的应该是一次配置Haproxy的时候，对于各种时间，当时都是少了单位（默认都是毫秒），结果导致我们在测试应用的时候，一会好一会不好，这个失误一般来说还真不好查，怎么看配置怎么没有问题，后来是抓包后发现连接超时时间特别短，回过头在看配置文件时，才把10改成10s。

2.有哪些细枝末节的坑你是想提醒一下身边的运维伙伴的？

其实做运维，尤其是基础架构的运维，接触的都是开源组件啊、流程啊等等，这些都有可能是踩坑的地方。一一列举真的太多了。

3.谈谈出现坑的主要原因与如何规避它们。

从带团队开始，也总结了下出现坑的一些原因，大体上有这些

• a:研发代码问题，比如代码逻辑、代码中出现字母打错的情况、少个标点符号什么的、为了修一个bug结果导致新bug的出现等

a:研发代码问题，比如代码逻辑、代码中出现字母打错的情况、少个标点符号什么的、为了修一个bug结果导致新bug的出现等

• b:测试部门对于上线的代码测试不够充分，存在侥幸心理，一上线，吼吼，业务出现问题

b:测试部门对于上线的代码测试不够充分，存在侥幸心理，一上线，吼吼，业务出现问题

• c:运维部自身，运维流程不规范、不标准；运维人员对开源组件的认识不足且文档一般都不仔细看（90%都是度娘上去看别人怎么配置的，自己不会去深究）；运维人员做事不经思考，不是先想怎么做，而是先做了再说出现问题再去考虑，严重浪费人力成本；

c:运维部自身，运维流程不规范、不标准；运维人员对开源组件的认识不足且文档一般都不仔细看（90%都是度娘上去看别人怎么配置的，自己不会去深究）；运维人员做事不经思考，不是先想怎么做，而是先做了再说出现问题再去考虑，严重浪费人力成本；

以上的问题，对于研发和测试部门，作为运维真的不好去建议什么，只能向上反应，希望他们怎么做。

对于运维部门，我认为，首先要制定的就是运维规范和流程，而且能让机器去做的就不要让人去做（人的风险更大），让人参与的内容越少越好；再次，需要培养运维人员看官方文档的习惯、做事的习惯；第三，要赏罚分明，没有赏罚，大家做事自然不会考虑太多（我罚过部门的人，一次后，做事效率提升了，踩坑的次数骤减）

以上是对这个活动的一点看法，哈哈

【General_715】

1.你遇到过哪些的坑让你印象深刻？你是如何解决的。

有一次在rhel5上配置yum,因为rhel是需要认证的，配置起来完全和centos不一样，配置上去之后没有起到作用，就联系了红帽的技术支持，也没找出原因就叫我用sosreport命令(记不太清了，应该是这个)收集信息，命令执行时间较长，在执行的过程中，我自己把问题解决了，于是联系技术支持，他叫我ctrl+C退出即可，结果我执行了之后，服务器down了。。。。。。后来打电话过去，他们说是这个命令的bug，已经在rhel6版本修复，5版本不予修复。

还有，最开始接触脚本的时候，脚本了用了rm命令，后面接的是变量，在后面是tmp目录，目的是想再某一个目录(通过变量取得)下建一个tmp目录，然后用完之后删除这个tmp目录，结果这个变量有一次没取到，然后就把根目录下的tmp目录删除了。。。还有，某一个内部系统使用起来非常慢，项目经理很不满意，后来我上系统上用top命令查看，发现数据库进程占用cpu达到了100%，登上数据库一看，正在执行的一个sql语句对某一个表进行查询操作，我一查，这个表几百万行。后来经过调查和询问，系统搭建的时候，有一个脚本要定期执行去删除这个表的数据，结果脚本，之前搭建的同事忘了放到crontab里去执行，从来就没运行过。

2.有哪些细枝末节的坑你是想提醒一下身边的运维伙伴的？

首先，最重要的就是要在测试环境进行一些未知的操作，在完全确认没问题之后，在上生产环境进行操作。整个操作过程记录成文档，留下日志，在生产环境操作的时候，严格按照之前准备好的文档执行。而且要在非业务时间。

再有，就是不要再脚本里出现rm命令，更不可以在rm命令后面接变量。

3.谈谈出现坑的主要原因与如何规避它们。

• 第一，自己操作不仔细，出现操作失误。
• 第二，开发程序有bug，这个就需要在测试环境先运行，没问题了再上生产环境运行。
• 第三，新手进行操作因为没经验容易引起问题，最好有有经验的人在旁边看着，不要让新手独立进行操作

第一，自己操作不仔细，出现操作失误。

第二，开发程序有bug，这个就需要在测试环境先运行，没问题了再上生产环境运行。

第三，新手进行操作因为没经验容易引起问题，最好有有经验的人在旁边看着，不要让新手独立进行操作

【799029078】

谈谈这短短两个月遇到的几个坑吧 。

1 普通用户执行 sudo ls /root/ntp* 找不到文件 ROOT ls /root/ntp*

解决办法：sudo bash -c "ls /root/ntp* "

2 用户test有附加组test1

当用usermod 删除附加组时 id命令不显示test2

groups命令还会继续显示附加组为test1

解决办法：重新登入 groups命令就会正

3 背景：一个计划任务 每分钟会去检测一个服务进程，如果进程不存在则启动

场景：卸载该服务

步骤：

1 删除计划任务

2 检测进程

3 如果进程存在则删除进程

4 删除安装目录

缺陷：计划任务会出现间隔定期去读取/etc/crontab的配置文件，步骤1虽然删除了，但是计划任务已经读取进去了。

在执行完步骤3后，计划任务又把进程拉起来了，造成服务卸载了，但是进程还在。

下次再安装时该服务会出现异常。该问题出现的几率应该在0.5%以下

解决办法：

增加步骤5 检测进程是否存在，再kill进程。就算计划任务在步骤4以后执行，它也拉不起进程了，因为服务的安装目录都被删除了。哈哈

4 ansible异步任务的两个坑

坑1

shell：xxxx

async:

poll:

args:

chdir:

后面的这个chdir压根没作用！有木有

坑2

还是

async:

poll:

如果用该异步任务实现shell去产生另一个异步任务，另一个异步任务有几率不会真正执行！概率高达10%左右

5 端口的一个坑

这是几个月前遇到的问题了

web服务器别绑定87号端口！！！！

浏览器默认不让访问