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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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