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
- QCOS-2949 statcollect 使用 root 運行 關聯QCOS-2707
排查：嘗試： 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
與運維配合問題：
紅牛那邊說 lac的機器可能比較麻煩。白天再重啓可以嗎？
宕機頻發，
無volume 手動完成遷移，有volume 重啓
改進：容器自動遷移， 或者迅速重啓
statcollect.log-1025174940
statcollect.log-1025174951
k8s隨機宕機測試 測試服務高可用
開源框架比如netflix的chaosmonkey
nq73-nq80 已升級內核
operating system driver/deamon osd