【大话IT】运维是个坑，年底盘点背锅侠的点点滴滴~（获奖名单已公布）

Fl_wolf

在本次图书出版活动中，获得社区纪念版运动帽衫的网友有：
@撒加
@799029078
@zzfzqq
@qingduo04

请以上获奖者在2017年2月20日前将姓名，公司，职务，行业，电话，邮箱，QQ，地址，站内短信发送给王楠w_n以便及时给您快递奖品。

发不了站短的，请在原帖下方跟帖留言。

至于QQ现因两个编辑轮番值班登陆，可能会有遗漏的情况，有任何问题请尽量在原帖下方跟帖留言或在站务版块反馈，谢谢！

注：因特殊原因，每次活动的获奖者我都会通知各位，如果大家在截止日期之前还未联系到管理员，那么本次活动的得奖资格将被取消，所以请大家及时的与管理员取得联系，谢谢合作！

============================================================



话题再走一波~~~~~~

话题背景：
运维是个遇坑、填坑、再遇坑、再填坑，有些时候还被同事挖坑，duang的一下掉下去了，还要自己慢慢爬坑；有些却是自己了解不够深入，或不够细心所留下来的坑。
楼主表示，在实际操作中遇到了多多少少的坑，只有运维人们共享所遇到的坑，才能更快的定位与解决这些烦人的坑。


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



活动时间：1月4日—2月4日


活动奖励：

凡参与此次活动的，均可获得“金鸡报喜”徽章一枚。




活动结束后，将选取4位讨论精彩的同学，送加棉加厚社区纪念版运动帽衫各一件。






DTCC 2017 来啦！

随着云计算和大数据时代的来临，数据正在以前所未有的速度成为各个领域价值创造的核心驱动力。

在此背景下，国内最受关注的数据库技术盛会——2017第八届中国数据库技术大会（DTCC2017）将于2017年5月11-13日如约而至。本届大会以“数据驱动•价值发现”为主题，汇集来自互联网、电子商务、金融、电信、政府、行业协会等20多个领域的120多位技术专家，共同探讨Oracle、MySQL、NoSQL、云端数据库、智能数据平台、区块链、数据可视化、深度学习等领域的前瞻性热点话题与技术。大会共设定2大主场和20个技术专场，将吸引5000多名IT人士参会，为数据库人群、大数据从业人员、广大互联网人士及行业相关人士提供最具价值的交流平台。



官网链接：http://dtcc.it168.com/
购票链接：http://dtcc.it168.com/goupiao.html

欢迎扫码关注DTCC官方微信，获取最新信息！

o枫叶o飘零

这个话题好，沙发是我的

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

都是因为自己的问题导致的，我举几个栗子

1.iptables配置，当时非常自信,直接在机器上配了，当时脑壳抽风，先配了一条默认拒绝所有，然后.....你懂的........   幸亏是云服务器，进控制台删除那条iptables就行了。

2.crontab，这一点也是个坑，当脚本写好，手动测试没有问题时，再放进crontab里面,发现各种问题。    最后的解决方法是把crontab的执行环境变量和当前的环境变量不一样等等...    如果脚本要放进crontab   尽量写绝对路径。。。。。。

3.写sudo文件，当时手一抖，多写了一个字母就保存了，然后无法sudo了.......     

4.java项目内存不释放，导致内存爆了。当时换了无数个tomcat版本,换了无数台服务器都是一样的问题。最后还是让开发改他们自己的代码才解决的。。。。。
5.rm -rf /* .log  然后你懂的   , 当时还纳闷删除几个log怎么这么慢,等执行完毕时，发现连ls都木有了....

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


变量   路径     shell中的单双引号....   元字符和正则的区别    linux命令的执行优先级等等
只有自己踩过坑，才会长记性，如果自己在同一个坑跌倒第三次，那就是自己没脑子

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


大部分是因为自己不细心，或者不了解他们的原理、方法。

规避他们的最好方法就是先通读手册，然后再在虚拟机上测试，测试没有问题后再上线。

如果虚拟机上没有问题，上线之后出现问题，那再来解决。

撒加

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

2.有哪些细枝末节的坑你是想提醒一下身边的运维伙伴的？
其实做运维，尤其是基础架构的运维，接触的都是开源组件啊、流程啊等等，这些都有可能是踩坑的地方。一一列举真的太多了。

3.谈谈出现坑的主要原因与如何规避它们。
从带团队开始，也总结了下出现坑的一些原因，大体上有这些
a:研发代码问题，比如代码逻辑、代码中出现字母打错的情况、少个标点符号什么的、为了修一个bug结果导致新bug的出现等
b:测试部门对于上线的代码测试不够充分，存在侥幸心理，一上线，吼吼，业务出现问题
c:运维部自身，运维流程不规范、不标准；运维人员对开源组件的认识不足且文档一般都不仔细看（90%都是度娘上去看别人怎么配置的，自己不会去深究）；运维人员做事不经思考，不是先想怎么做，而是先做了再说出现问题再去考虑，严重浪费人力成本；
以上的问题，对于研发和测试部门，作为运维真的不好去建议什么，只能向上反应，希望他们怎么做。
对于运维部门，我认为，首先要制定的就是运维规范和流程，而且能让机器去做的就不要让人去做（人的风险更大），让人参与的内容越少越好；再次，需要培养运维人员看官方文档的习惯、做事的习惯；第三，要赏罚分明，没有赏罚，大家做事自然不会考虑太多（我罚过部门的人，一次后，做事效率提升了，踩坑的次数骤减）

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

cjfeii

rm -rf /
多么痛的领悟~~~

apen

说起运维，那就是个泪奔的过程！
1.你遇到过哪些的坑让你印象深刻？你是如何解决的。
关联系统太多，出了问题，只要不摆在面前，谁都是视而不见！这就要分清工作职责，做好工作协调，同时要有可以说服别人的可信依据：我负责的部分没有问题！
2.有哪些细枝末节的坑你是想提醒一下身边的运维伙伴的？
文档要完备、工作过程要注意积累、养成做好运维工作日志的习惯，更重要的是：一定要有完善系统监控。
3.谈谈出现坑的主要原因与如何规避它们。
系统不一定靠得住，但比起人，系统更靠得住，因此自动化手段不能少，特别是大系统的运维。
应用软件的优化调整不能停，一个良好的应用软件，所需要花费的运维成本是很低的。

heyong45

回复 4# cjfeii

遇到过一次这个问题，而且还是单机。。。

seesea2517

小细节太多都不记得这些坑啦，关键还是要做事细心，记录细致。

Rayree1993

lollol

anzi5091104

运维有风险，入行需谨慎

aloki

没有十足把握的话不要在生产服务器上以root用户执行命令。不要轻易执行删除命令，最好以mv取代，待确认没有任何问题后再执行rm命令。