一个疑难故障，坑了我半年青春

可能是基于原来安装方式的千奇百怪导致问题丛出,所以Docker官方提供了一个脚本用于适配不同系统、不同发行版本Docker安装的问题,这也是一个比较奇怪的地方,所以Docker生态还是蛮乱的.

验证

16:44:15 up 28 days,23:41,? 2 users,?load average: 0.10,0.13,0.15

docker????30320???? 1? 0 Jan11 ???????? 00:49:56 /usr/bin/docker daemon -p/var/run/docker.pid

Docker内核升级到1.19,Linux内核升级到3.19后,保持运行至今已经2个月多了,都是ok的.

总结

这个故障的处理时间跨度很大,都快半年了,想起今年除夕夜收到服务器死机报警的情景,心里像打破五味瓶一样五味杂陈.期间问过不少研究Docker和操作系统内核的同事,往操作系统内核版本等各个方向进行了测试,但总与正确答案背道而驰或差那么一点点.最后发现原来是处理得不够彻底,比如升级不彻底,环境被污染；比如升级的版本不够新,填的坑不够厚.回顾了整个故障处理过程,总结下来大概如下：

回归运维的本质

运维要具有预见性、长期规划,而不能仅仅满足于眼前：

1. 应急预案：针对可能系统上线后可能发生的故障类型进行总结,并提供应急预案.
2. 抢通业务：优先抢通业务,再处理故障.
3. 应用版本选择等技术选型问题：在环境部署和应用选型时需要特别注意各种版本,最好采用社区通用或者公司其他同学已经测试或验证可行的版本.
4. 操作系统内核：要合理升级内核,只有定位到确定版本存在的问题,才能有针对性的升级内核版本,不然一切徒劳.
5. 在我们原来的设计中,不同用户调度器针对同一个容器同时操作没有加锁机制,也没有按照对源判断原则,也曾出现过迁移失败的情况.迁移时判断迁往的目的地址是否就是本地地址,如果是本地地址应该拒绝操作的.这个问题不知你是否觉得眼熟.我倒是发现,很多人程序开发过程中,就经常不对输入源或者操作的源状态进行判断,结果出现了各种bug.

Google的能力

（编辑：网站开发网_盐城站长网 ）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!