澳大利亞網絡安全評估初創(chuàng)公司UpGuard梳理了過去幾年的信息安全事故，列出了7個自動化IT系統(tǒng)缺陷導致重大的安全事故的實例實例，昌暉儀表網轉載此文，意在警醒自動化同行們：自動化技術帶來的安全事故，其危害同樣觸目驚心，工作中必須認真再認真，仔細再仔細！ 

1、亞馬遜/DynamoDB：DynamoDB數(shù)據庫攪亂亞馬遜基礎設施 
正如物流之類物理服務需要道路交通這樣的物理基礎設施，公司企業(yè)的數(shù)字服務也依賴于底層數(shù)字基礎設施。2015年9月，亞馬遜自動化基礎設施過程中斷，造成AWS平臺宕機。從簡單網絡中斷級聯(lián)反應成大面積服務掉線，亞馬遜經歷了傳統(tǒng)內部數(shù)據中心才會經歷的那種斷網——盡管它有非常先進和集成的云平臺。

亞馬遜的網絡中斷影響到其一部分DynamoDB云數(shù)據庫的存儲服務器。此事發(fā)生時，一些存儲服務器還在請求其成員資格數(shù)據。于是，斷線造成了檢索和傳輸超時，這些服務器無法獲得自己的成員資格數(shù)據，自動退出了服務。

當那些無法獲得請求的服務器開始重新嘗試請求的時候，DynamoDB超時問題便引發(fā)了更大面積的斷網。如此，惡性循環(huán)產生，亞馬遜客戶有5個小時無法使用AWS。 

2、網站Healthcare.gov：一個疏忽葬送美國政府的醫(yī)療健康網站
2013年10月，美國政府推行《平價醫(yī)療法案》的網上登記工具時，Healthcare.gov被寄予厚望；而數(shù)百萬公民健康保障的交付壓力，讓風險越來越高。于是，當該網站上線僅2小時就因重大軟件故障而崩潰時，政府遭到了相當大的抵制。由于缺乏集成、可見性和測試，該項目從一開始就埋下了重大隱患——Healthcare.gov的賬戶創(chuàng)建功能“ Account Lite ”中存在超過100個缺陷。

由于其功能，Account Lite 是 Healthcare.gov 網站的重要組成部分，供人們創(chuàng)建賬戶并訪問自己的醫(yī)療健康選項。該模塊問題太多，注定要引發(fā)災難。盡管如此，自動化系統(tǒng)還是照原樣推進了。 

軟件發(fā)布失敗了，讓數(shù)百萬公民無法獲得醫(yī)療保障。更遭的是，網站崩潰還引發(fā)了政治衍生影響，讓《平價醫(yī)療法案》的反對者開始援引該事件作為政府無法發(fā)展成功醫(yī)療保障項目的鐵證。網站最終穩(wěn)定了下來，但并應在發(fā)布前就集成的工作，卻是在崩潰發(fā)生后才做完。
 
3、Dropbox：讓Dropbox掉線的小缺陷 
沒有哪個IT團隊會喜歡掉線經歷，尤其是掉線造成團隊必須快馬加鞭實現(xiàn)應急規(guī)程的時候。2014年1月，Dropbox就對一次計劃產品升級造成的3小時掉線抓狂不已。

Dropbox腳本中的一個“小缺陷”，自動將其更新應用到了幾臺活動主機上，于是，上千臺產品服務器受到影響，引發(fā)該公司在線服務崩潰。幸運的是，Dropbox的應急規(guī)程設計良好且有效。IT團隊在備份和恢復策略的幫助下，在3小時內成功恢復了大部分服務。然而，某些大型數(shù)據庫的恢復就慢得多了——全部核心服務完全恢復花去了Dropbox數(shù)天的時間。



4、Opsmatic：后患無窮
托管在傳統(tǒng)服務器管理之下時，自動化往往也面臨同樣的古早IT問題。其中一個經典假定是：“沒壞就別修復”——假定所有系統(tǒng)都按預設方式運行。所以，Opsmatic的常規(guī)服務器維護搞攤了其整個運營時，根源就出在事情并沒有像他們原以為的那樣進行。

該案例中，名為“清除默認用戶”的方案在該公司AWS實驗早期階段被創(chuàng)建。如今，測試過去很久之后，該流程仍在生產服務器上悄悄運行，維護人員根本不得而知。就像很多重大故障一樣，該事件也是長期的無心之失造成的，這些小過失逐漸積累，終釀大禍。

5、Knight Capital：拼寫錯誤致10億美元損失
不僅僅是管理性IT過程，其算法交易也被 Knight Capital 自動化了。然而，不幸的是，在真金白銀處理事務中，這些改變和計劃外的錯誤是有可能很快發(fā)生的。2012年，因為一個微小的錯誤，Knight Capital 在45分鐘里以 $172,222/秒的速度大量損失資金。

大規(guī)模數(shù)據中心運營中，服務器集群通常都會執(zhí)行單個功能。這樣可以將負載分配到更多的運算資源上，為高流量應用提供更好的性能表現(xiàn)。該模式要求集群中所有服務器都采用相同的配置，無論功能用到的是集群中哪個具體的服務器，這樣所有的應用就會有相同的表現(xiàn)。然而，配置這種東西，即便籌備的時候是相同的，也總是會逐漸出現(xiàn)偏差的。

盡管做了自動化升級，Knight Capital在服務器陣列上的代碼部署卻還是手動的，而一個不可避免的人為錯誤，導致了其8臺服務器的配置與其他服務器不同。Knight Capital的技術人員在部署新服務器代碼時出了這個小錯誤，但卻沒人發(fā)現(xiàn)。IT員工便一直在這些服務器都是相同配置的錯誤認知下操作。 

同時，一段已經退役的代碼在錯誤配置的服務器上仍然可用。因此，該服務器開始向特定交易中心發(fā)送指令，圍繞股票交易的多米諾骨牌效應產生，4.65億美元交易損失不可避免。 

6、達美航空：自動化致航班停飛
大型物流運營依靠自動化系統(tǒng)達成規(guī)模化所需的速度要求。有些航空公司在維持這些系統(tǒng)運行上舉步維艱。就像傳統(tǒng)的人工系統(tǒng)管理方式，自動化系統(tǒng)也受到錯誤配置的傷害。最近幾年的最糟情形，便是這些自動化系統(tǒng)宕機造成航空公司上億美元的損失，及其客戶信譽的喪失。

錯誤配置發(fā)生時，通過自動化機制，錯誤會被很快推送，造成整個系統(tǒng)宕機。對航空公司而言，這意味著航班運營中斷，飛機延誤，資金析出。2017年1月就發(fā)生過類似事件，達美航空自動化系統(tǒng)中的一個小故障引發(fā)斷電，給航空公司造成1.5億美元經濟損失。

7、谷歌Gmail：您有新郵件？Gmail崩潰事件
當技術巨頭經歷偶發(fā)自動化相關中斷，一個小時的宕機所引發(fā)的后果會比表面上的損失更為深遠。這些行業(yè)巨頭想做任意改變，都必須覆蓋成千上萬臺服務器。身處技術前沿的谷歌自動化其配置管理毫不意外。雖然是為了讓操作更簡單而設，當錯誤修改在自動化系統(tǒng)里發(fā)生，便意味著該錯誤會在數(shù)秒內廣泛傳播。 

2014年，谷歌內部自動化配置系統(tǒng)里的一個小故障，讓Gmail崩潰了大約半小時。該錯誤配置被發(fā)送到了在線服務上，導致用戶日期請求被無視，相關服務接連出錯。

經驗教訓在于，配置自動化并不等同于配置管理。自動化僅確保所做修改會被推送到所有系統(tǒng)上。