這可能是你需要的： https://bethune.enmotech.com/ 近日，關於騰訊雲的一則事故在朋友圈刷屏。 事件回放 騰訊雲披露的整個事件的基本情況如下： 8月6日 消息：近日，騰訊雲用戶“前沿數控”平臺一塊操作系統雲盤，因受所在物理硬碟固件版本Bug導致的靜默錯誤，文件系統元數據損壞 ...
這可能是你需要的：
近日，關於騰訊雲的一則事故在朋友圈刷屏。
事件回放
騰訊雲披露的整個事件的基本情況如下：
8月6日 消息：近日，騰訊雲用戶“前沿數控”平臺一塊操作系統雲盤，因受所在物理硬碟固件版本Bug導致的靜默錯誤，文件系統元數據損壞。
騰雲在聲明中稱，監控到異常後，第一時間向用戶告知故障狀態，並立即組織文件系統專家並聯合廠商技術專家嘗試修數據，最終終仍有部分數據完整性校驗失敗。此外，隨即對固件版本有bug的硬碟全部進行下線處理，確保相關隱患全部排除。
第一時間制定如下“賠償+補償”方案，包括包括全額返還 3569 元費用以及提供 132900 元現金或雲資源的額外補償。不過，"前沿數控"基於自身評估就此次故障對騰訊雲提出了高達 11，016，000 元的索賠要求，雙方未達成一致。
而在用戶端，『前沿數控』的聲明則是：
...災難就發生在2018年7月20日，近千萬元級的平臺數據全部丟失，包括經過長期推廣導流積累起來的精準註冊用戶以及內容數據，這瞬間將一家創業公司摧毀….
...花了兩年多心血打造的平臺！當所有內容數據全部丟失，在這種情況下需要花多大代價才能恢復運營？還能運營得起來嗎？拿這13萬能用來乾什麼？那是我們公司的命脈！
...丟失的數據包括PC網頁、H5、小程式共用的核心數據。平臺註冊的精準用戶數據全部丟失、數十萬條用戶帖子全部丟失、行業品牌庫數據及所有錄入的資訊全都丟失。因為是高度垂直的行業，獲得流量是極其困難的事情...
而更有網友找出騰訊雲硬碟 99.9999999% 的可靠性承諾：
可是畢竟廣告好不好，還要看療效，9個9的可靠性，你也永遠無法論證你不是那 0.00000001%。
什麼是靜默錯誤
既然騰訊以9個9的代價換來的這次慘痛事故，公告中的“靜默錯誤”就非常值得關註了。那麼什麼是“靜默錯誤”呢？
靜默錯誤在英文中被稱為：Silent Data Corruption，我們知道硬碟最核心的使命是正確的存入數據、正確的讀出數據，在出錯時及時拋出異常告警。磁碟出現異常的情形可能包括硬體錯誤、固件 BUG 或者軟體 BUG、供電問題、介質損壞等，常規的這些問題都能夠正常被捕獲拋出異常，而最可怕的事情是，數據處理都是正常的，直到你使用的時候才發現數據是錯誤的、損壞的。這就是靜默錯誤。
網上的一篇論文：Silent data corruption in SATA arrays: A solution - Josh Eddy August 2008 對靜默錯誤進行瞭解釋，我引用了一段文字進行說明，全文下載請關註公眾號“數據和雲”回覆：122arch 獲得（我偷懶扔到之前的目錄中了）。
這篇文章提到：
有些類型的存儲錯誤在一些存儲系統中完全未報告和未檢測到。 它們會導致嚮應用程式提供損壞的數據，而不會發出警告，記錄，錯誤消息或任何類型的通知。 雖然問題經常被識別為靜默讀取失敗，但根本原因可能是寫入失敗，因此我們將此類錯誤稱為“靜默數據損壞”。這些錯誤很難檢測和診斷，更糟糕的是 它們實際上在沒有擴展數據完整性檢測功能的系統中相當普遍。
在某些情況下，當寫入硬碟時，應該寫入一個位置的數據實際上最終寫入另一個位置。 因為某些故障，磁碟不會將此識別為錯誤，並將返回成功代碼。 結果，RAID系統未檢測到“錯誤寫入”，因為它僅在硬碟發出錯誤信號時才採取措施。
因此，不僅發生了未檢測到的錯誤，而且還存在數據丟失。 在圖2中，數據塊C應該覆蓋數據塊A，而是覆蓋數據塊B.因此數據塊B丟失，數據塊A仍然包含錯誤的數據！
結果，數據被寫入錯誤的位置; 一個區域有舊的，錯誤的數據; 另一個區域丟失了數據，RAID系統和HDD都未檢測到此錯誤。 檢索B或C的訪問將導致返回不正確的數據而不發出任何警告。
撕裂寫入
在其他情況下，只有一些應該一起寫入的扇區最終會出現在磁碟上。 這稱為“撕裂寫入”，其導致包含部分原始數據和部分新數據的數據塊。 一些新數據已丟失，一些讀取將返回舊數據。 同樣，硬碟不知道此錯誤並返回成功代碼，因此RAID無法檢測到它。訪問檢索B將返回部分不正確的數據，這是完全不可接受的。
上文提到的“撕裂寫入”，如果在 Oracle 資料庫中發生，那麼就是分裂塊，當然 Oracle 資料庫會自動檢測這種情況。
那麼“靜默損壞”發生的概率有多少呢？該文提供了一組數據：
...一項針對NetApp資料庫中150萬個硬碟驅動器的學術研究在32個月內發現，8.5％的SATA磁碟會產生靜默損壞。 某些磁碟陣列運行後臺進程，以驗證數據和RAID奇偶校驗是否匹配，並且可以捕獲這些類型的錯誤。 然而，該研究還發現，後臺驗證過程中錯過了13％的錯誤。
那些未被髮現的錯誤，就會成為企業的災難。雖然我們不知道騰訊雲所稱的“靜默錯誤”是否與此相關，但是靜默錯誤的確值得大家去瞭解。
即便沒有任何錯誤，數據也需要定期進行讀取，以確保數據無誤，在幾年前，我遇到過一起案例，Oracle 資料庫莫名的發生了一定批量的數據損壞，存儲上沒有任何錯誤，但是資料庫端大量的分裂塊，存儲沒有檢測到錯誤，並且複製到災備站點，最後導致了數據丟失。
你可能需要：
對錯與利弊
我們姑且不要討論誰對誰錯，我們要知道：只要是硬體就有損壞的一天，只要是運維就有誤操作的可能。而且，有一句名言說的好『小孩子才分對錯,成年人只看利弊』。雲給了我們便利之處，也就一定會有風險相隨。
也許很多人已經忘記了廣西移動在 2017年9月8號發生的大事故。僅僅因為一個代碼 0 和 1 的輸入，就引發了影響 80萬 移動用戶的大故障：
當晚凌晨，該工程師將代碼輸錯（1輸成0），導致格式化，進而讓80萬移動用戶的數據遭到清空。事發後，中國移動10086收到了將近2萬多條電話投訴，移動和華為立即啟動緊急排查處理，整個事故在第二天早上10點才得以控制。
而近年，在雲服務商處發生的重大事故可以說是『層出不窮』，國內國外盡皆如此，列舉幾個 2017 年的事故：
2017年1月20日，大約一定是受到川普上任的影響，突如其來的伺服器故障影響了一大批爐石玩家，恢復時間長，由於意外斷電，導致資料庫損壞，不得不通過游戲回檔恢複數據庫的使用。（關於爐石傳說的Oracle資料庫故障不要以為你也可以幸免）
2月1日，除夕剛剛過完，荷蘭的一個DBA在資料庫複製過程中意外地刪除了一個錯誤的伺服器上的目錄，刪除了一個包含300GB的實時生產數據的文件夾。300G的資料庫被刪成4.5G，由於沒有有效的備份，嘗試了所有5個恢復工具都沒有完成恢復。在丟失數據並恢復失敗後，伺服器徹底崩潰。（五重備份無一有效，還有哪些 rm -rf 和GitLab類似的憂傷？）
2月11日，網路剪報服務商 - Instapaper 遭受了超過31小時的服務中斷，聲明需要一個星期的資料庫恢復時間，然而經過10天的恢復，也僅僅恢復了6個星期的數據。（雲服務真的靠譜嗎？ AWS 用戶中斷31小時僅恢復6周數據）
2017-04-05，位於紐約的雲服務商 Digital Ocean 遭遇了一次長達4小時56分鐘的停機事故，事故的原因是主資料庫被刪除了（primary database had been deleted），由於配置錯誤，本應指向測試環境的任務被指向了生產環境，測試任務包含的環境初始化過程刪除了主生產資料庫。（不以規矩不成方圓：Digital Ocean也刪除了他們的資料庫）
2017年6月 位於荷蘭海牙的一家雲主機商 verelox.com， 一名前任管理員刪光了該公司所有客戶的數據，並且擦除了大多數伺服器上面的內容，客戶數據恢復希望渺茫。（參考：2017，那些我們一起刪庫跑路的日子）
而近在今年4月，香港一家雲服務上也聲明，因為管理員的 rm -rf /* 操作，導致所有的數據丟失：
正所謂，硬體一壞，誰也沒招，線路再穩，藍翔報銷，功夫再高，也怕菜刀。
數據備份守則
對於運維來說，最重要的是提高自身的免疫力，獲得高抗風險能力，從而在災難中幸存下來。事關企業數據安危的情況，無論如何都不能疏忽大意。
所以，無論走的多遠，也不要忘了最基本也正是最重要的備份，有效的備份才能讓企業高枕無憂。怎樣保證備份的有效性？那就要做到不僅僅備份，而且還要定期檢測備份。
還記得Google曾經轟動一時的流水線刪庫事件，這可是團隊作案喲，這麼團結真的好嗎？（時移世易：遵從既往經驗致 1.5PB 數據刪除，Google SRE是如何應對的？）
一個 Google Music 用戶彙報某些之前播放正常的歌曲現在無法播放了。Google Music 的用戶支持團隊通知了工程師團隊，這個問題被歸類為流媒體播放問題進行調查。3 月 7 日，負責調查此事的工程師發現無法播放的歌曲的元數據中缺少了一個針對具體音頻數據文件的指針，於是他就修複了這個歌曲的問題。
但是，Google 工程師經常喜歡深究問題，也引以為豪，於是他就繼續在系統中查找可能存在的問題，當發現數據完整性損壞的真正原因時，他卻差點嚇出心臟病:這段數據是被某個保護隱私目的的數據刪除流水線所刪掉的。Google Music 的這個子系統的設計目標之一就是在儘可能短的時間內刪除海量音頻數據。
該流水線任務大概誤刪除了 60 萬條音頻文件，大概影響了 2.1 萬用戶.
沒有什麼是絕對可靠的，所以要選擇相信自己。
我在多年以前總結的 DBA 四大守則，第一條就是『備份重於一切』。
針對Oracle資料庫，一套 ADG 環境是最簡單的數據保障，備庫加上備份，就能夠防範硬體故障這個層面的災難性數據損失，MySQL 通過主備同樣可以實現類似的架構。當然您的數據有多重要，應該採取的技術措施就應該有多完善，任何疏忽肯定都是在冒險。
然而對於企業來說，您必須要牢記的是：如果您不能承擔數據全部丟失的損失，就要做好自主的可靠數據備份。依賴自己最可靠，依賴他人有風險。
針對種種安全風險，我曾經總結了提升資料庫安全的"16條軍規"供大家參考，很多朋友也向我們詢問，如何做才能夠徹底防範這類風險，我想你可以從以下16條建議中找到答案：
備份重於一切
我曾經在總結的DBA四大守則的第一條就指出，『備份重於一切』，有了有效的備份，即使遭遇災難，也可以從容應對，對於重要的生產環境，適當建立備庫進行數據保護，查詢分擔，也會減少生產庫的風險；
唯一會讓DBA們從夢中驚醒的就是:沒有備份! 所以對於資料庫運維來說，第一重要的是做好備份!有備方能無患!
嚴格管控許可權
過度授權即是為資料庫埋下安全隱患，在進行用戶授權時一定要遵循最小許可權授予原則，避免因為過度授權而帶來的安全風險。本次安全風險，如果用戶只具備最低許可權，如不具備DDL許可權，那麼也不會遭到風險；
明確用戶職責
應當明確不同的資料庫用戶能夠用於的工作範圍，應當使用普通用戶身份的，就絕對不應該使用DBA的用戶身份，只有職權相稱，才能夠避免錯誤，降低風險。 即便是擁有管理員職責的用戶，也應當遵循以不同身份執行不同任務的習慣，比如SYS和SYSTEM用戶的使用就應當進行區分和界定；
密碼策略強化
毫無疑問，資料庫用戶應當使用強化的密碼規則，確保弱口令帶來的安全風險，很多數據泄露問題來自弱口令攻擊和提權；
限制登錄工具
明確限制不同工具的使用場景，明確規定工具的準確來源，或者通過堡壘機等來限制資料庫訪問。對於工具也可以做出明確規則和限制，如限制僅能通過SQL Developer訪問生產，PL/SQL Developer工具僅能訪問測試環境，以減少安全風險甚至誤操作風險；
禁止遠程DDL
可以限制DDL操作僅能在資料庫伺服器本地進行，禁止遠程連接執行DDL操作，這一手段在很多公司被嚴格執行，如果具備這一規則，此次的事故可以被直接屏蔽掉；
使用綁定變數
在開發過程中，嚴格使用綁定變數，綁定變數可以防範SQL註入攻擊，減少資料庫安全風險；這次安全事故，很多用戶開始猜測是SQL註入，走了很多分析上的彎路；
監控監聽日誌
監聽日誌記錄了資料庫訪問的來源、程式等信息，包括惡意掃描，密碼嘗試等，一定要重視監聽日誌的作用，並對其進行分析和監控，以清楚的匯制資料庫訪問圖譜；雲和恩墨一直幫助用戶通過監聽日誌分析來揭示風險，白求恩平臺（ https://bethune.enmotech.com ）為用戶免費提供這一分析緯度的預警；
數據網路隔離
資料庫的網路環境應該一直隱藏在最後端，避免將資料庫置於直接的訪問連接之下，由此可以減少資料庫的訪問風險；
測試和生產隔離
互通就意味著同時可以訪問，也就可能帶來很多意想不到的安全風險，企業應當將測試環境和生產環境部署於不可互通，或者不可同時訪問的網路環境中，避免因為錯誤連接而發生的資料庫災難。 分離部署一方面可以降低誤操作的可能性，也可以屏蔽一些無關的訪問可能，從而從網路鏈路上保證數據安全；
密碼差異設置
有些測試環境或者非產品環境是利用產品環境恢復得到的，DBA在建立了測試環境後，就沒有修改資料庫用戶的登錄密碼;經常性的，DBA也習慣在所有環境中設置通用的密碼;這些習慣為系統帶來了很多風險和不確定性。 我們建議用戶在不同環境中採用不同的密碼設置，這是因為一方面產品環境和測試環境面對的訪問用戶不同，密碼設置相同則意味著產品環境的安全性完全得不到保障;另一方面，DBA登錄到不同的資料庫需要使用不同的密碼，這進一步減低了DBA在錯誤的環境下執行命令的可能性。
重要數據加密
很多重要的數據，需要加密存儲，最典型的就是用戶和密碼信息，大量的泄密事件本質上是因為缺乏最基本的加密防範，對重要數據實施一定的安全防護加密，是應當予以適時考慮的安全方面之一；
適時的軟體升級
這裡的軟體指資料庫軟體，尤其是當Oracle已經發佈了安全補丁，已知的安全漏洞被黑客利用，則更可能對資料庫產生致命的傷害；
防範內部風險
不可否認，絕大部分安全問題都來自於企業內部，來自最緊密、最輕易的接觸和訪問，企業的人員變動，崗位變更，都可能導致數據安全問題的出現，單存依靠對管理員的信任不足以保障數據安全，必須通過規章、制度與規 範的約束才能夠規避安全風險。
很多企業為了便利而捨棄規範、規章或者安全限制是得不償失的做法。安全防範應當從內部做起，從限制約束自我做起，當最緊密相關的訪問都遵從守則，那麼系統的安全性就能夠獲得大幅度的提升。
樹立安全意識
安全問題最大的敵人是僥幸，很多企業認為安全問題概率極低，不會落到自己的環境中，所以對於安全不做必要的投入，造成了安全疏忽。所以安全問題最大的敵人是我們自己，安全需要一點一滴的加強，逐步完善，雲和恩墨一直幫助核心客戶進行全面的安全評估，制定安全方案，守護數據安全。
開始安全審計
以Oracle資料庫為例，資料庫已經提供了很多安全防範的手段和方法，我們建議用戶適當展開安全防範措施，開啟部分任務審計，定期分析資料庫風險，由此逐步完善資料庫安全。
關註安全，更重要的是意識，陽光之下，並無新事，努力請從今日始！
這可能是你需要的：
