事故分析

16:45 完成发布 00:42发生宕机 container－node lac56
7:45 完成nq发布 20:00发生宕机 nq55/nq56/nq39/nq42/nq13
17:21 hotfix statcollect@付业成
19:15 临时重启下 indexd，因为需要新增管理帐号的 del 权限。@付业成

回顾下这个过程
0700 发布bq nq gq
1700 发布lac
1745左右 hotfix statcollect
1903 nq55 down
2000 nq56 down
2252 nq39 down
2257 nq42 down
0000 nq80 down
0038 lac56 down
0057 nq13down
全部发生在statcollecthotfix之后

回滚：发布的和宿主机有关的只有 logd statcollect osd，回滚nq/bq/gq/lac osd &statcollect
回滚之后，服务恢复

初步汇总判断：跟发布有关，review 发布osd statcollect 相关issue
1. QCOS-2949 statcollect 使用 root 运行 关联QCOS-2707
2.
排查：尝试： hotfix操作@付业成，cs环境复现 @付业成
查找资料，发现kernel panic问题，heavy namespace use频繁执行 @马思超
@苏海 写脚本频繁调用docker exec 对线上容器执行，nq4宕机

问题发生在hotfix之后，
从关联issue 看，还有关联 pod创建后没有网卡的问题 @付业成 @蔺育申
这个 statcollec 加了监控会调用 docker exec
直接原因：开启statcollect root权限导致宕机
开发人员，想当然的认为 只改了一个权限；
关键是该权限关联了 pod建立后没有网卡的问题排查action－增加监控；
docker exec 的执行，需要root权限开启，才生效。
监控生效，导致频繁docker exec 导致宕机。
根本问题：
https://lkml.org/lkml/2014/2/15/217
https://lkml.org/lkml/2014/10/24/456

https://github.com/docker/docker/issues/13940

事故出现后，表现好的地方：lac有告警，非值班人员马凯雄发现 ，通知群里，大家都引起警戒，付总回滚代码，海哥迅速迁移容器，减少损失；
需要改进的地方：
hotfix流程没有先在cs环境操作；
事故先在nq 发现了 ，没有得到及时处理；
运维，竟然说宕机能不能明天处理，重视度不够，主要是我司宕机事件频发，大家有些麻木；

可能原因：
1、 新内核升级，
2、 statcollect hotfix
3、 上线发布
4、 spark-master干了什么奇怪的事情能把宿主机搞挂？
4台是同一个内核问题？我看了日志，出问题的第一条都是这个
2016-10-25 19:57:00.074204166 [13222673.348663] BUG: unable to handle kernel 2016-10-25 19:57:00.074254797 NULL pointer dereference2016-10-25 19:57:00.079086508 at 0000000000000150

内核 NULL Pointer dereference

与运维配合问题：
易弢 01:02:37
红牛那边说 lac的机器可能比较麻烦。白天再重启可以吗？

宕机频发，
无volume 手动完成迁移，有volume 重启
改进：容器自动迁移， 或者迅速重启

statcollect.log-1025174940
statcollect.log-1025174951

k8s随机宕机测试 测试服务高可用
开源框架比如netflix的chaosmonkey

nq73-nq80 已升级内核
operating system driver/deamon osd