昀哥@老兵筆記
2020農曆新年開局不容易，新冠肺炎仍在攻艱克難階段。回首過去的9102年，總有一些事主要是事故值得去記錄。下面我們來盤點一下9102年的“外部事故”。
一，我們遭遇的IT基礎設施服務事故
2019年是IT基礎設施服務相對黑暗的一年。各種災難性事件高發，我們所依賴的多家公司的關鍵服務不可用時間突破SLA四個九（即一年52分鐘）。下面我們回顧一下：
-
阿里雲：2019年3月3日，凌晨0點開始，阿里雲華北二機房可用區C部分ECS服務器等實例出現IO HANG，導致託管業務的所有服務器資源使用率100%且均無法登錄，業務中斷長達3小時。
-
中國移動：2019年3月15日，由於中國移動的物聯網集中化系統（CMIOT）凌晨部署架構優化（第二批）割接上線，從7點11分開始影響全國大面積物聯網卡使用，於7點30分開始逐步恢復服務，但由於數千萬張物聯網卡排隊接入，直至上午11點才緩解。
-
銀聯、網聯和微信支付：2019年3月23日，14點42分左右，銀聯和網聯（兩個清算機構）與微信支付上海機房的物理連接被挖斷了，雖然他們快速切換了備用線路，但下游業務均受到了影響，所有交易（支付寶、微信支付、雲閃付）都在抖。
-
114DNS：2019年4月4日，10：30～12：30，114 DNS和谷歌DNS 8.8.8.8 相繼掛了。
-
上海移動：2019年5月29日，11：10～11：20，上海移動網絡出現異常，網絡和通話均受到影響，上海地區一度無法線下收單。
-
支付寶：2019年12月5日，16：23～16：45，支付寶出現全網故障，系統報錯“010002：系統異常”陡增，歷時22分鐘。全網均有感知，新聞報道“支付寶崩了”。
- 阿里雲：2019年12月6日，部分用戶反饋阿里雲華北、華東地域部分網絡出現異常，影響部分雲資源訪問。
二，IT大廠事故
每年IT大廠都會飛出各種妖蛾子，下面我們盤點一下2019年到2020年春節前的IT大事故：
-
MongoDB：2019年1月，網絡安全人員Bob Diachenko在推特上爆料，深網視界的MongoDB數據庫在公網上“裸奔”，允許完全訪問，全球新聞界隨後大舉跟進了這起大規模數據泄露事件，該數據庫包含256萬條以上的個人信息記錄，涉及身份證號碼、簽發和到期的時間、性別、國家、地址、生日、護照照片、僱主以及基於攝像頭所記錄的過去24小時內經過的地點信息，約668萬條記錄。
-
拼多多：2019年1月20日，拼多多一個100元無門檻優惠券（對應於一個已過期的運營活動）由於操作失誤，導致凌晨又重新上線，從凌晨1點到10點，整整9個小時，羊毛黨徒們狂歡，據信拼多多損失高達數千萬元。
-
Facebook：2019年3月22日，據匿名內部員工透露，從2012年至今，有將近2～6億Facebook用戶的賬戶密碼可能是以純文本形式存儲的（即明文存儲），並且可被2萬多名Facebook員工搜索。
-
AWS：2019年3月22日，前AWS網絡工程師Thompson利用AWS的“配置漏洞”或“防火牆設置錯誤”，入侵了AWS客戶美國第一資本銀行（Capital One Financial）的S3 Bucket（存儲桶）並下載了其中的內容，她還嘗試利用 IPredator 的 VPN 和 Tor 來隱藏入侵痕跡。她將數據發佈在其Github賬號內，並在推特上吹噓她持有這些客戶隱私數據。
-
AWS：2019年10月22日，亞馬遜的AWS DNS 服務器遭遇猛烈而持久的 DDoS 攻擊，攻擊持續了15個小時！
-
ES：2019年12月，還是Bob Diachenko宣佈發現了一個巨大的、可公開無密碼訪問的ElasticSearch數據庫，包含超過27億個電郵地址，其中有10億個的密碼都是簡單的明文存儲，這種情況很像是原本買下了該數據庫的某人本試圖啓動其搜索功能，卻被錯誤配置成了公開可用。
-
京東：2020年1月8日，估計是誤操作把京東自營小家電品類上到了200元無門檻券的適用區域裏，時間長達五十分鐘，據信涉及24萬筆低價訂單，預估商品金額7000萬。
三，我們遭遇的各種外部軟件缺陷事故
常在河邊走，難免會溼鞋，用第三方軟件用的久了，也會多多少少遇到它們的致命缺陷：
-
Docker資源感知問題：2019年1月，我們發現在阿里雲上搭建的容器集羣上，各種Java應用的Docker容器實例會間歇性地被 SIGKILL（signal=9）。原因是Docker容器利用CGroup對進程使用的資源進行限制，而在容器中的JVM依然會利用宿主機環境的內存大小和CPU核數進行缺省設置，這導致了JVM Heap的錯誤計算。我們做了兩個措施來規避Docker OOM Killer：1）開啓CGroup資源感知，目的是將heap堆內存和容器限制的內存設置成相同大小，2）將容器內存限制由2.5G調整爲3G（注：2G（heap空間）+1G（額外） =3G），同時建議使用SpringBoot，它比較輕量，佔用資源比較少，目前我司部分工程使用SpringCloud 設置爲1G（heap空間）+1G（額外）=2G。
-
阿里雲鏡像問題：2019年4月15日以及25日，我司在阿里雲華北和華東機房的幾臺宿主機都曾突然出現IP地址缺失，導致上面跑的服務全部失聯。此乃阿里雲鏡像的bug，對應於它的《KB:94181：檢查與修復CentOS 7實例和Windows實例IP地址缺失問題》。我司隨後檢查所有機房並都通過腳本修復了。
-
Consul缺陷：2019年6月18日，有關鍵業務突然告警說它在nginx的註冊地址1.1.1.1註冊失敗。原因是在內部容器註冊的流程中，consul-template程序將consul中的數據讀取出來，再寫入nginx的upstream模塊的配置中，但如果consul-template讀取不到數據，則它會將默認地址1.1.1.1寫入到upstream模塊的配置中，從而爲事故埋下了隱患。Consul官方已經在0.9.0以上新版本中修復此問題，我司隨後逐一升級了所有機房的consul服務。
-
OKHTTP缺陷：2019年7月，據現場端反饋，即使在網絡正常的情況下，也會有個別設備會在某個時段內出現支付緩慢，多筆交易連續失敗的情況。原因是如果OKHTTP第一次出現SocketTimeoutException，後續即使網絡已經恢復正常，請求也始終返回SocketTimeoutException，必須等到多活域名切換、重新連接WiFi，或重新啓動應用程序才能恢復正常。此問題尤其是在4G網絡下比較常見，官方未解決。我司只能在全局ResponseError監聽器裏，如果發現出現SocketTimeOut就清空連接池，並持續關注此issues修復狀態，及時更新。
-
MySQL缺陷：2019年8月12日，數據中心的主從數據庫宕機。原因是innodb做table truncate時候，要把屬於這個table的表空間文件的所有的頁刷盤並從buffer pool中去掉。代碼中的判斷應該存在問題，觸發了實例crash。後續已將MySQL版本升級至較新版本5.7.27，同時將數據中心的數據庫報表庫和其他關鍵業務庫拆分到不同實例，減小影響面。
-END-
感謝閱讀老兵筆記，祝百病不侵鼠你健康！