昀哥@老兵筆記
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-
感謝閱讀老兵筆記，祝百病不侵鼠你健康！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/41198.html
標籤：其他