2014年2月14日存儲在線編譯：雷蒙布盧姆(Raymond Blum)領導著一支站點可靠性工程師團隊，主要負責谷歌數(shù)據(jù)的保密性和安全性。當然，谷歌永遠也不會透露那些數(shù)據(jù)的總量是多少，但是從其高管的言語中來看，那些數(shù)據(jù)總量沒達到YB級至少也達到了EB級。僅Gmail服務的相關(guān)數(shù)據(jù)就達到了EB級。

布盧姆在解釋谷歌如何互聯(lián)網(wǎng)時稱，常規(guī)的備份策略在谷歌是行不通的，原因是：在一般情況下，它們會隨著容量進行調(diào)整。

 

他談到了以下要點：

·         從未出現(xiàn)過數(shù)據(jù)丟失的事故。即使在GMail服務宕機時也沒有丟失過數(shù)據(jù)，但是這比磁帶備份要復雜得多。 整個系統(tǒng)的各個地方都需要檢索數(shù)據(jù)，這就要求它在包括人在內(nèi)的每一個層級上都提供引擎。

·         備份無用。它其實是你最關(guān)心的數(shù)據(jù)恢復功能。 它是一個恢復系統(tǒng)而不是備份系統(tǒng)。備份只是數(shù)據(jù)恢復戰(zhàn)略中的一部分內(nèi)容。 將任務轉(zhuǎn)至備份，讓它具備所需的各種功能，以便將數(shù)據(jù)恢復工作盡可能地簡化。

·         你無法按比例調(diào)整。 如果數(shù)據(jù)量增加一百倍，你不可能將人力資源或機器資源也增加一百倍。你應該去尋找倍增器。 自動化是提高利用率和效率的重要方法之一。

·         無處不在的備用冗余。谷歌有很多種服務，總是會有某一些服務出現(xiàn)故障。 這是不可避免的，就象人體內(nèi)的細胞也在不停地老化死去一樣。 谷歌從未想過能夠避開這種情況，而是未雨綢繆地制定對應的計劃。

·         無處不在的多樣性問題。如果你擔心某個站點不完全，那就請把數(shù)據(jù)放到多個站點上儲存。 如果你擔心的問題是用戶誤操作，那就請設置各種隔離政策，對用戶互動進行限制。如果你想免于受到軟件漏洞的危害，那就請使用不同的軟件。 將數(shù)據(jù)保存在不同廠商的設備上可以減少軟件漏洞的危害性。

·         將人中整個工作流程中解放出來。Gmail保存了多少份電子郵件的副本？ 人們不應該去關(guān)心這樣的問題。有些參數(shù)是由Gmail設置，然后由系統(tǒng)來管理的。 這是慣例。高級政策設置完成后，系統(tǒng)就會照此執(zhí)行。 只有出現(xiàn)超常規(guī)的事情后，才需要人工介入。

·         用實際應用去證明它。如果你根本就不去嘗試，那么它肯定是無法正常工作的。 備份和恢復一直處于被測試狀態(tài)中，目的是驗證它們是否能夠正常運作。

不管是大型企業(yè)還是小型企業(yè)，都能從中學到不少知識。 布盧姆談到的那些內(nèi)容既風趣，又有教益，非常值得一讀。他本人似乎也非常喜愛這項工作所具備的挑戰(zhàn)性。

以下是我個人獲得的一些心得：

·         數(shù)據(jù)有效性必須是100%。 永遠也不會出現(xiàn)數(shù)據(jù)丟失的情況。

o    從統(tǒng)計學的角度來說，如果你在一個2GB的文件中丟掉200K的數(shù)據(jù)，那可能并不是很多，但是那份文件可能就變得不能用了。

o    數(shù)據(jù)有效性比訪問通道有效性重要得多。如果一個系統(tǒng)宕機了，情況并不會變得十分糟糕。 但是如果數(shù)據(jù)丟失了，那就非常糟糕了。

o    谷歌保證你會遇到下列情況的各種組合：

§  場地隔離

§  因應用層出現(xiàn)問題導致的隔離

§  因存儲層出現(xiàn)問題導致的隔離

§  因媒體失效導致的隔離

o    你必須考慮到你能控制的范圍。將軟件標在縱軸上，地點標在橫軸上。 如果你想覆蓋所有的東西，你就需要在每個不同地點都保留一份軟件層的副本。你可以在不同地點使用虛擬機來實現(xiàn)這個目標。

·         備用冗余與可恢復性并不是一回事。

o    保留再多的數(shù)據(jù)副本也不能保證不發(fā)生數(shù)據(jù)丟失的事故。

o    對于某些類型的宕機事故來說，保留很多份數(shù)據(jù)副本確實是有用的。如果一顆流星撞擊了一個數(shù)據(jù)中心，而你在遠程站點保留了數(shù)據(jù)副本，那你當然不會受到影響。

o    如果你的存儲設備中有一個軟件漏洞，那么將數(shù)據(jù)復制到再多的設備上也無濟于事，因為所有的數(shù)據(jù)副本都存在那個漏洞。Gmail宕機就是最好的例子。

o    數(shù)據(jù)中心遭流星撞擊的概率絕不會比軟件漏洞、用戶誤操作或錯誤數(shù)據(jù)寫入等情況出現(xiàn)的概率高。

o    備用冗余非常適用于局部引用。當你希望所有的數(shù)據(jù)引用盡可能接近數(shù)據(jù)被使用的地點時，復制是個很好的方法。

·         整個系統(tǒng)的實用性達到了驚人的程度。

o    谷歌有很多種服務，總是會有某一些服務出現(xiàn)故障，這是不可避免的。 就象人體內(nèi)的細胞在不斷地死亡一樣。我們從未想過實現(xiàn)服務從不出現(xiàn)故障的目標。 我們?yōu)樗�制定預案計劃。各種設備總是會出現(xiàn)故障。

o    備用冗余就是解決問題的方法。事實證明，多臺設備的可靠性比一臺優(yōu)質(zhì)設備的可靠性更高。 一臺設備可能會因為某種災難而被毀掉。但是存放在50個不同地點的很多臺設備是很難在同一時間一起被毀掉的。

·         大規(guī)模并行系統(tǒng)出現(xiàn)數(shù)據(jù)丟失的概率更高。

o    如果沒有漏洞的話，MapReduce在3萬臺設備上運行還是不錯的。但是如果系統(tǒng)有漏洞的話，那后果立刻就會被放大無數(shù)倍。

·         如果整個站點出現(xiàn)宕機，那么即便有本地數(shù)據(jù)副本也無濟于事。

o    如果你的服務器機房進水了，那么即便你使用了RAID也沒用。

o    谷歌直到一年前才停止使用的Google File System（GFS）系統(tǒng)充分發(fā)揮了RAID的概念。利用編碼技術(shù)同時向不同城市的多個數(shù)據(jù)中心寫入數(shù)據(jù)，因此你只要一些碎片就能完成數(shù)據(jù)的重建工作。 因此，即便3個數(shù)據(jù)中心同時熄火，你仍然能夠使用自己的數(shù)據(jù)。

·         有效性和完整性都是整個機構(gòu)的特征。

o    谷歌工程師、BigTable、GFS、Colossus都知道保證數(shù)據(jù)耐用性和完整性是首要大事�，F(xiàn)在有很多系統(tǒng)就是用來檢查和糾正數(shù)據(jù)有效性和完整性方面的錯誤的。

·         你想要多樣化的配置。

o    如果你擔心站點問題，請把數(shù)據(jù)存放到多個站點。

o    如果你擔心用戶人為誤差問題，請禁止用戶人工操作。

o    如果你想讓數(shù)據(jù)不受軟件錯誤的影響，就請把它放到不同的軟件中。將數(shù)據(jù)保存到不同廠商的設備上可以降低大廠商故障的影響。

·         利用磁帶將數(shù)據(jù)備份起來真的非常好。

o    磁帶其實很好用，因為它跟磁盤不一樣。如果可以的話，他們可能還會使用打孔卡片來儲存數(shù)據(jù)。

o    試想一下，如果你的SATA硬盤的設備驅(qū)動程序中出現(xiàn)了一個漏洞，會出現(xiàn)什么樣的后果呢？如果使用磁帶的話，就不會有這樣的問題了。 它增加了你的多樣性，因為不同的媒體需要使用不同的軟件。

o    磁帶容量符合摩爾法則的規(guī)定，因此將磁帶當作備份媒介來使用是很不錯的，即便它們能夠在其他設備上使用，它們也不會泄密。

o    磁帶是加密的，這就意味著壞人很難從中得到有用的東西。

·         備份是無用的。你關(guān)心的其實是數(shù)據(jù)修復問題。

o    如果系統(tǒng)存在問題的話，你就必須在用戶使用數(shù)據(jù)前找出它們。當你需要修復數(shù)據(jù)時，你就需要用到它了。

o    持續(xù)不斷地進行數(shù)據(jù)修復。隨機選擇5%的數(shù)據(jù)進行備份，然后修復數(shù)據(jù)并進行對比。 為什么呢？ 在數(shù)據(jù)丟失前，搞清楚備份系統(tǒng)是否工作正常。這樣可以找出并解決很多的問題。

o    進行自動對比。不能跟原始數(shù)據(jù)進行對比，因為原始數(shù)據(jù)已經(jīng)發(fā)生了變化。 因此，給所有的數(shù)據(jù)分配檢驗數(shù)字，然后對比那些檢驗數(shù)字。將數(shù)據(jù)放回源媒體、磁盤、閃存或是其他任何存儲媒介。 確定數(shù)據(jù)能夠環(huán)行一周再回來。這個過程一直在進行之中。

·         如果故障率出現(xiàn)變化，就發(fā)出警報。

o    如果有些東西發(fā)生了變化，你可能想知道到底是怎么回事。如果一切運行正常，那就別來煩我。

o    系統(tǒng)肯定會不時出現(xiàn)一些故障，但是如果只是某個文件在首次修復時出現(xiàn)問題，那就不用發(fā)警報了。

o    假設第一次出現(xiàn)故障的概率為N，第二次出現(xiàn)故障的概率為Y。 如果故障率出現(xiàn)了變化，那么肯定是哪里出錯了。

·         一切都停止下來。

o    磁盤經(jīng)常因為故障而停止工作，但是這種事情一發(fā)生你就會知道，因為你一直監(jiān)控著磁盤。

o    如果使用磁帶的話，那出現(xiàn)故障時你是不知道的，只有當你想去使用它時才會知道它出現(xiàn)了故障。磁帶可以存放很長的時間，但是在你需要用到它之前，你需要先進行測試。

·         磁帶上的RAID4。

o    不要將數(shù)據(jù)只寫到一盤磁帶上。它們都是盒式磁帶。 機械臂也許會失手掉落磁帶，磁帶上的磁粉也許會掉。不要冒險。

o    當把數(shù)據(jù)寫到磁帶上的時候，告訴寫入軟件將數(shù)據(jù)保存好，知道我們發(fā)出它可以改變的命令。如果你這樣做的話，你已經(jīng)違約了。

o    寫滿4盒磁帶后，通過XORing即可生成第五盤代碼磁帶。這5盒磁帶中丟掉任何一盤磁帶，你都依然可以恢復數(shù)據(jù)。

o    現(xiàn)在告訴寫入程序它們可以改變源數(shù)據(jù)了，因為數(shù)據(jù)已經(jīng)被存放到最終的位置上，現(xiàn)在那些源數(shù)據(jù)變成備份冗余副本了。

o    谷歌備份的每一點數(shù)據(jù)都要經(jīng)過這種處理。

o    每月丟失的磁帶可能達到數(shù)百盒，但是由于這個處理程序的關(guān)系，每個月的數(shù)據(jù)丟失事故并不會達到數(shù)百次。

o    如果一盒磁帶丟失了，可以利用持續(xù)不斷的數(shù)據(jù)修復檢測出來，然后你就可以利用相關(guān)的磁帶重新制作一盒與丟失的磁帶一模一樣的磁帶，所有的數(shù)據(jù)就都恢復了。如果碰巧遇到兩盒磁帶都損壞的情況，那只有當那兩盒磁帶的損壞點也是一樣的時候，你才會丟失數(shù)據(jù)，你可以利用磁帶重新恢復數(shù)據(jù)。

o    不要因為這些技術(shù)而令數(shù)據(jù)丟失。數(shù)據(jù)丟失的代價太大了，但這就是商業(yè)成本。

·         備份是你為避免發(fā)生數(shù)據(jù)修復成本而采取的預防措施。

o    它是一個數(shù)據(jù)修復系統(tǒng)而不是備份系統(tǒng)。數(shù)據(jù)修復是不可避免的中斷。 它們非常有用。利用備份來恢復數(shù)據(jù)。

o    按照要求對數(shù)據(jù)進行備份并根據(jù)需要將它們保留足夠長的時間。盡可能快和盡可能自動去進行數(shù)據(jù)修復。

o    數(shù)據(jù)修復操作應該是簡單、迅速和快捷的。你應該能夠通過一項簡單的操作來啟動數(shù)據(jù)修復。

o    數(shù)據(jù)修復工作可以在你休息或睡覺的時候進行。因此，最好不要在數(shù)據(jù)修復操作中添加任何人工操作的要素。 你承受著壓力。因此，當你在備份數(shù)據(jù)時請把數(shù)據(jù)修復的準備工作也做充足。

o    很大一部分系統(tǒng)都是這樣工作的。

o    數(shù)據(jù)源也許必須將數(shù)據(jù)保存一段時間，這段時間也許是幾天，然后才能將那些數(shù)據(jù)備份。但是一旦數(shù)據(jù)被備份好，它應該能夠迅速被恢復。

o    為了讓數(shù)據(jù)修復的速度盡可能快一點，請不要頻繁使用備份媒體�；▋蓚�小時的時間去讀一盒磁帶的做法是不可取的。 只將一盒磁帶寫一半，然后同時讀取兩盒磁帶，這樣你就可以將數(shù)據(jù)恢復的時間縮短一半。

·         調(diào)整是一個問題。

o    當你有EB級的數(shù)據(jù)需要備份時，現(xiàn)實中還有其他一些限制條件。如果你必須拷貝10份EB級的數(shù)據(jù)，那你可能需要10個星期的時間去備份每天的數(shù)據(jù)。

o    由于數(shù)據(jù)中心遍布全球各地，因此你還有一些選擇的余地。你是否會給每一個站點分配近乎無限的備份容量？ 你是否會按地區(qū)將所有的備份數(shù)據(jù)集合在一起？ 傳輸數(shù)據(jù)的帶寬如何？ 你難道不需要為業(yè)務流量預留帶寬嗎？

o    相關(guān)成本。這里有很多折中方案。 并不是每一個站點都有備份設施。必須保證網(wǎng)絡上的可用容量處于均衡狀態(tài)。 備份必須在X站點進行，因為它有所需的帶寬。

·         你不可能成比例地調(diào)整規(guī)模。

o    不能說你想要多少網(wǎng)絡帶寬和磁帶都行。磁盤會出現(xiàn)故障，因此如果你有1萬塊磁盤的話，你可能需要1萬多名操作員去更換它們。 你有1萬個裝載支架來放磁帶嗎？這都不是成比例增加的。

o    雖然磁帶庫的數(shù)量已經(jīng)上升了一個數(shù)量級，但是對人員數(shù)量的要求并沒有同步提高10倍。需要的人數(shù)肯定會增加一些，但肯定不會象按比例增加那么多。

o    有一個例子可以說明這一點，早期人們曾預測電話數(shù)量會增加30%，那么話務員的數(shù)量也應該增加30%，但是事實上并非如此，因為后來使用了程控技術(shù)自動接線。

·         自動化技術(shù)

o    日程安排已經(jīng)實現(xiàn)了自動化。如果你有一項服務并且需要儲存數(shù)據(jù)，你可能每隔一段時間就需要對數(shù)據(jù)進行備份一次，然后需要每隔一段時間對數(shù)據(jù)進行修復。 這些數(shù)據(jù)備份和數(shù)據(jù)恢復工作都可以由內(nèi)部系統(tǒng)自動完成。備份是計劃好的，系統(tǒng)可以自動進行數(shù)據(jù)恢復的測試工作和完整性測試。 當系統(tǒng)檢測出某一盒磁帶出現(xiàn)故障時，它會自動進行處理。

o    作為人，你不需要了解這些東西。也許在未來的某個時候，你才會想起來去查看一下有多少磁帶出現(xiàn)過問題。 如果磁帶故障率發(fā)生變化，從每天100盒增加到每天300盒，系統(tǒng)才會發(fā)出警報。 但是在系統(tǒng)發(fā)出警報之前，系統(tǒng)是不會提示你每天有100盒磁帶出現(xiàn)問題是在正常范圍以內(nèi)的。

·         人工不應介入穩(wěn)態(tài)運行的系統(tǒng)。

o    包裝和運輸硬盤仍然需要人工來完成。 自動準備運輸標簽，獲得RMA編碼，核對發(fā)出的包裹，接收回執(zhí)，這都是自動進行的。只有當這個流程中斷時，才需要人為干預。

o    庫軟件維護也是如此。如果有一個固件需要升級，并不需要派一名員工去給每個系統(tǒng)升級。 下載固件升級，然后將它送到總控制庫即可。 對固件升級進行測試，盡可能準確地驗證測試結(jié)果。 然后將它發(fā)出去。這套正常操作不需要人工干預。

·         自動處理設備宕機事故。

o    很多設備每分鐘會宕機兩次。如果在使用3萬臺設備執(zhí)行MapReduce作業(yè)時有一臺設備宕機，那就別告訴我了，只要自動處理好它然后繼續(xù)執(zhí)行作業(yè)就行了。 再找一臺設備，將工作負載移動過去，然后重啟設備。

o    如果設備之間存在關(guān)聯(lián)性，那就請在計劃中加一個等待指令。如果系統(tǒng)等待的時間太長，則可以向管理員發(fā)出警報。 你處理你自己的計劃工作。這是算法應該做的事，而不是人應該做的事。

·         在數(shù)據(jù)增長的同時，保持效率不斷提高。

o    提高利用率和效率。數(shù)據(jù)量增長100倍的時候，決不能出現(xiàn)對人員或設備的需求量也增長100倍的情況。

o    2011年的GMail宕機事故和修復情況。從中可以看出谷歌是如何丟掉數(shù)據(jù)然后又找回那些數(shù)據(jù)的。他在周日上午10:31收到一條警報信息，上面寫著：“Holly Crap呼叫xxx-xxxx”。如需了解更多關(guān)于那次宕機事故的信息，請點擊這里。

o    Gmail服務的數(shù)據(jù)量已經(jīng)達到EB級了。那需要使用很多很多的磁帶。

o    100%恢復。數(shù)據(jù)可用性并不是100%。 丟失的數(shù)據(jù)在事故發(fā)生后的第一天或第二天并沒有全部恢復。 但是最終，所有的數(shù)據(jù)都被恢復了。

o    復制層發(fā)生了一系列故障和事故。是的，我們有三個相同的文件，但是它們都空了。 即使進行過設備測試、系統(tǒng)測試和裝配測試，故障也無法避免。

o    從磁帶恢復數(shù)據(jù)。這是一項繁重的工作。 數(shù)據(jù)恢復的時間與數(shù)據(jù)規(guī)模是成正比的�；謴�1GB的數(shù)據(jù)也許只要1毫秒到幾秒的時間就行了。 但是要恢復20萬個收件箱（每個收件箱中都有幾GB的數(shù)據(jù)），那就要一些時間了。

o    叫醒了歐洲的兩名員工來處理此事，因為當時他們那里是白天。將人員分配在不同的地方，就是有這樣的好處。

o    數(shù)據(jù)被從每一盒磁帶上恢復過來，并經(jīng)過了驗證。這項工作沒有花太多的時間，只用了幾天就完成了。 員工們對此感到滿意。遇到類似事故的其他公司花了一個月的時間才意識到他們無法將數(shù)據(jù)恢復回來。 谷歌采取了一些措施來保證下次遇到類似事故時會更快地完成相關(guān)的處理工作。

o    讀一盒磁帶要花2個小時的時間。磁帶散布在很多地點。 沒有哪一個站點有足夠的計算能力去讀取所有與數(shù)據(jù)恢復有關(guān)的磁帶。

o    利用壓縮技術(shù)和檢驗數(shù)字技術(shù)，其實并不需要把20萬盒磁帶都讀一遍。

o    從那以后，數(shù)據(jù)恢復工作就一直在不斷改進。

·         為各種數(shù)據(jù)的恢復工作設定優(yōu)先等級。

o    你應該對各種數(shù)據(jù)的恢復工作設定優(yōu)先等級，比如先恢復你正在使用的收件箱的數(shù)據(jù)和已發(fā)送的電子郵件數(shù)據(jù)，然后再恢復歸檔數(shù)據(jù)。

o    一個月都沒有被碰過的帳戶可以放在后面恢復，優(yōu)先恢復相對比較活躍的用戶的帳戶的數(shù)據(jù)。

·         備份系統(tǒng)被視為一個巨大的全局有機組織。

o    例如，不要只在紐約備份GMail服務的數(shù)據(jù)，因為如果數(shù)據(jù)中心的規(guī)模擴大或縮小，備份數(shù)據(jù)的規(guī)模就應該相應地進行調(diào)整。

o    將備份當作一個巨大的全球性系統(tǒng)來對待。當備份發(fā)生的時候，它也許是在其他任何地點進行的。

o    利用磁帶來恢復數(shù)據(jù)必須在磁帶所在的地點進行。但是數(shù)據(jù)可以在紐約而備份卻在俄勒岡進行，因為俄勒岡的數(shù)據(jù)中心有足夠的容量。 地點隔離是自動處理的，谷歌沒有將數(shù)據(jù)的備份地點告知客戶。

o    容量是可以移動的。由于有一個全局容量并得到網(wǎng)絡的支持，因此磁帶在哪里并不重要。

·         你擁有的數(shù)據(jù)越多，數(shù)據(jù)備份工作就越重要。

o    東西越大就越重要，這是一條常規(guī)定律。谷歌以前只做搜索業(yè)務。 現(xiàn)在它有了GMail服務，因此它變得更大和更重要了。

·         建立一套優(yōu)秀的基礎設施

o    隨身攜帶一把瑞士軍刀真的很好。當MapReduce被開發(fā)出來的時候，他們可能從未想到過它會被用于備份。 但是如果不是已經(jīng)開發(fā)出MapReduce的話，那么人們也不會想到把它用于備份。

·         調(diào)整規(guī)模真的很重要，你不能只擁有它的一部分，比如軟件、基礎設施、硬件、流程等等。

o    你不能說，我有足夠多的員工，因此我打算使用更多的磁帶。如果你打算將員工人數(shù)增加一倍，先想想你公司外面的停車場是否能增加一倍的停車位吧。 公司的自助餐廳和休息室呢？ 每一樣都要增加一倍，最后你肯定會遇到一個過不去的瓶頸，然后不得不停下來。

·         在實際應用中證明它。

o    凡事都不要想當然。希望并不是一種策略。

o    如果你不去測試它，它就無法正常工作。要想驗證備份，就必須進行數(shù)據(jù)恢復工作。 除非你到最終都沒有證明任何東西。事實證明，這樣的做法會導致大量的事故出現(xiàn)。

·         災難恢復測試。

o    每過N個月都會出現(xiàn)一種災難。你應當在企業(yè)組織的每個層級模擬災難發(fā)生時的反應。

o    如果災難什么都不帶走，公司將如何生存呢？ 必須學會適應。

o    在基礎設施和物理安全設備中找出巨大的漏洞。

o    設想一下，如果有一個數(shù)據(jù)中心只有一條路通向外界，那么那條路上必然塞滿了運輸發(fā)動機燃料的卡車。如果那條路不在了，會怎么樣？ 最好再增加一條通道和另一條輸送柴油機燃料的供應管道。

o    制定供應鏈備用策略。

·         在不同的時間點和不同的地理位置及時對不同軟件的數(shù)據(jù)進行備份。

o    不要只是讓數(shù)據(jù)在不同的系統(tǒng)層級之間移動，而是應該將數(shù)據(jù)保存在系統(tǒng)的不同層級中。 這樣當你丟失某些數(shù)據(jù)時，你還可以從其他地方恢復它們。時間、地點和軟件，這都很重要。

o    以GMail宕機事故為例。如果復制軟件存在漏洞，怎么可能不出現(xiàn)數(shù)據(jù)丟失事故呢？ 這是某位聽眾提出的問題，他并不想要知道處理的細節(jié)。數(shù)據(jù)不斷被備份。 假設從晚上9點之后的數(shù)據(jù)我們都有，而數(shù)據(jù)錯誤是在晚上8點發(fā)生的，但是錯誤的數(shù)據(jù)還沒有被備份到磁帶上。 錯誤被停止了。軟件被恢復到之前某個正常運行的狀態(tài)。 在某一時刻，所有的數(shù)據(jù)都是完好的。那些數(shù)據(jù)都在磁帶上。 有些數(shù)據(jù)被復制了。 有些數(shù)據(jù)在前端，有些數(shù)據(jù)在日志里，這些數(shù)據(jù)源的某些數(shù)據(jù)是重復的，你是有可能重新所有的數(shù)據(jù)的。 在這些情況下，不要將數(shù)據(jù)從設備中提取出來，直到它被存入另一臺設備后過了N小時才能那么做。

·         刪除問題。

o    我想刪除這些數(shù)據(jù)。不要通過重寫磁帶的方式去刪除磁帶上的數(shù)據(jù)。 由于磁帶的規(guī)模太大，那樣做的成本就太高了。

o    有一種更加可行的做法是，利用密鑰來達到目的。它不會告訴我們谷歌在做什么。 也許鑰匙丟掉就等于把數(shù)據(jù)刪除了。

·         只有當員工們彼此信任且共同承擔責任時，一個規(guī)模龐大的組織才能高效運轉(zhuǎn)。

o    彼此信任。

o    確定組織界面和軟件界面都得到了明確的定義。在各個層級之間進行驗證測試。

·         制定白名單和黑名單。

o    確保數(shù)據(jù)被存放在一個受到保護的地方并且保證那些數(shù)據(jù)不會被存放到某個特定的地點。這有助于保證地點多樣性和地點獨立性。

o    這并不是設備固有的功能。必須添加到支持管理條件中。

o    將責任下方到盡可能低的層級。填寫正確的檔案，它就象魔術(shù)一樣發(fā)生了。