讀資料保護：工作負載的可恢復性02收集需求

1. 要點

1.1. 資料保護並不是IT裡面最出彩的部分

• 1.1.1. 讓這個組織知道自己可能遭受哪些風險

• 1.1.2. 與該組織內具有核心競爭力的IT產品通常沒有什麼聯絡

1.2. 做資料保護所需的資源通常很昂貴，而且這些資源並不會體現在該組織賣給客戶的最終產品裡

• 1.2.1. 沒人會情願為這種保單付費

1.3. 在開始花費大量預算做資料保護之前，必須先確保自己所要構建的這套資料保護方案，確實將企業在這方面的需求涵蓋了進來

2. 組織的工作內容

2.1. 作為資料保護者，你必須盡力構建出能夠保護所有資料與所有人的最佳方案

• 2.1.1. 全面瞭解這個組織的情況，有助於你更好地擬定資料保護方案

2.2. 從組織本身，以及該組織提供的服務或產品入手，來理解這個組織裡面的資料，以確定其中哪些資料最重要

2.3. 在開始處理你收集到的這些資訊之前，必須先構建一套框架給自己使用，以便透過該框架來處理資訊，另外還要構建一套文件系統，用以記錄資訊

3. 收集需求

3.1. 把與資料保護計劃有關的重要人物找出來，搞清楚這些人的要求，只有這樣，你做的計劃才能有效施行

3.2. 確定RPO與RTO

• 3.2.1. 恢復點目標（Recovery Point Objective, RPO；也叫目標恢復點）​

• 3.2.1.1. 出現災難時最多能夠容忍多少資料丟失

• 3.2.2. 恢復時間目標（Recovery Time Objective, RTO；也叫目標恢復時間）​

• 3.2.2.1. 遇到災難之後必須在多長時間內恢復資料

3.3. 尋找SME

• 3.3.1. 對於資料保護工作來說，組織裡的每個人都是你的客戶

• 3.3.2. SME（主題專家）

• 3.3.2.1. 資料是不是必須始終保持上線（而不允許暫時下線）​

>  3.3.2.1.1. 可能無法將資料恢復到發生故障的那一刻，但我們可以將其恢復到發生故障前一個小時的樣子

• 3.3.2.2. 資料創造者

>  3.3.2.2.1. 知道資料是從哪裡來的，也知道它是從哪個部門來的

>  3.3.2.2.2. 只有先搞清楚資料產生自哪個部門，我們才能知道資料丟失時從頭開始重建資料是不是特別複雜

>  3.3.2.2.3. 可能來自生產與運營團隊

>  3.3.2.2.4. 可能來自負責收集產品管理、組織及業務等方面資訊的團隊

>  3.3.2.2.5. 可能來自資料服務團隊

>  3.3.2.2.6. 從合規團隊與網路安全團隊裡面選一位成員參與，因為這兩種團隊的人，會對你提出一些與資料的儲存方式和使用方式有關的重要需求

>  3.3.2.2.7. 有很多渠道都能接觸本組織的資料

>  3.3.2.2.8. 資料的變化頻率不同，具體如何變化，要看該組織的內部工作流程

  >   3.3.2.2.8.1. 一定要問清楚他們每小時或每天處理多少個事件或多少項事務，這樣你才能知道資料在這個系統中的週轉速度

  >   3.3.2.2.8.2. 資料庫與資料服務團隊交流時，要記得收集相關資訊，搞清楚資料儲存在什麼地方，以及這些資料實際佔用多少空間

• 3.3.2.3. 管理者

>  3.3.2.3.1. 跟管理層的成員交流，因為他們更瞭解本組織的實際運作情況

>  3.3.2.3.2. 知道本組織的產品需要在多長時間內交付給客戶

>  3.3.2.3.3. 認真地跟他們討論本組織在資料保護上能投入多少資金，這樣的討論必須談到錢的問題

  >   3.3.2.3.3.1. 做好這方面的準備，你就應該能把RTO給確定下來了

• 3.3.2.4. 法務專家

>  3.3.2.4.1. 在資料保護上採取的做法，一定要符合該組織所應遵守的法律法規

>  3.3.2.4.2. 隱私是一個越來越受重視的問題，很多zf都提出了與該問題有關的法律要求

3.4. 釐清需求

• 3.4.1. 技術人員與非技術人員都不能漏掉，如果某些內容對於跟你談話的人來說顯得太過艱深，那你還要找個翻譯，把這些內容通俗地轉述給對方

• 3.4.2. 要珍惜他們的時間，所以你應該把談話的節奏安排好

• 3.4.2.1. 分3次或4次談，每次談20min，要比一次談一整個小時好

• 3.4.2.2. 他們每天都有緊迫的任務需要完成，他們要確保本組織能夠把目前的事情做好

• 3.4.3. 應該與每位SME單獨談，而不要同時找多位SME談

• 3.4.3.1. 可能會讓其中某些專家受到其他專家影響，而無法純粹地表達出他們本來的觀點

• 3.4.3.2. 單獨與這些SME談過之後，可能會聽到一些相互衝突的觀點，這可以等到稍後評審需求的時候再去解決

3.5. 評審需求

• 3.5.1. 將每個部門的需求全都收集下來並整理清楚了

• 3.5.2. 掌握了足夠的資訊，知道本組織的資料都存放在哪些地方，以及每個地方存放了多少資料

• 3.5.3. 關於資料的產生速度與變化速度，現在也應該清楚了

• 3.5.4. 知道本組織的服務或產品需要花多長時間來創造或交付，進而會知道在某些資料（乃至全部資料都）無法訪問時，各個部門能夠撐多久

• 3.5.5. 把收集到的眾多需求做成簡報，並邀請與資料保護有重要關係的人來審查這些需求

• 3.5.5.1. 能夠勸說本組織以及其中的資料創造者支援你的計劃，另外還應該有負責執行基礎設施的那些技術團隊裡面的一些關鍵人物

• 3.5.5.2. 要解決的問題界定清楚，然後將你從各個部門收集到的需求放到這份簡報（也就是幻燈片）裡面，讓這份資料能夠反映出各團隊的期望

• 3.5.5.3. 這個階段是在核實每個部門所提出的需求，看看這些需求怎樣才能更好地融為一體

• 3.5.5.4. 不一定要把預算與報價詳細列出來，但你可以大致算算這個計劃需要花費多少資金，這樣就可以更好地給大家解釋，讓大家知道他們所提出的需求得花多少錢才能實現

• 3.5.6. 服務水平協議

• 3.5.6.1. Service-Level Agreement, SLA

• 3.5.6.2. 透過這個協議來體現大家所認同的RPO與RTO

• 3.5.6.3. 資料保護必須使用大量的網路資源及儲存裝置（包括固態的儲存裝置與其他型別的儲存裝置）​，還有可能用到磁帶

>  3.5.6.3.1. 導致你的資料保護服務必須耗費一些時間與資金才能生效

>  3.5.6.3.2. 資料保護服務所使用的網路頻寬，通常比本組織的其他服務要多

• 3.5.6.4. 資料保護服務所使用的網路頻寬，通常比本組織的其他服務要多

• 3.5.6.5. 提前做好測算，搞清楚自己的資料恢復計劃必須做到什麼樣的效果，才能達到你對（內部）客戶承諾的相應服務水平，這樣他們到時就不會因為你的計劃沒有達到預期水平，或他們期望的水平超出了此計劃的實際水平而責怪你了

• 3.5.7. charge-back計費模式

• 3.5.7.1. charge-back計費模式（model，或稱計費模型）​，意味著每個部門都要為它所使用的服務量而承擔資金責任

• 3.5.7.2. 部門需要為這些資料所佔用的空間付費，這能夠促使他們仔細思考，是否真的要把所有的資料都納入保護範圍

• 3.5.7.3. 保護資料所用的這些基礎設施並不是免費的（較為重要的資料應該優先得到保護）​

• 3.5.8. 資料分級

• 3.5.8.1. 花些時間給需要保護的資料做分級

• 3.5.8.2. 並不是所有的資料都同等重要，其中相當大一部分資料，其實都可以在必要時丟棄，而不會影響本組織的正常運作

• 3.5.8.3. 資料分級的概念會直接影響你的RPO與RTO

• 3.5.8.4. 保護資料要花錢，但絕對不能為了省錢而把必須保護的資料漏掉

• 3.5.8.5. 資料保護計劃的要義，就是在本組織遇到問題時能夠儘快恢復必要的資料，資料只有先得到保護，才談得上如何恢復

3.6. 結束需求評審

• 3.6.1. 評審時每個人都有各自的觀點，他們都會站在自身的立場上探討本組織的事務

• 3.6.2. 給每一個參與討論的人分配至少10min時間，並讓大家都明白，這樣的會面是為了確定本組織在資料保護方面的需求（而不是純粹為了吵架）​

• 3.6.3. 要做好記錄

• 3.6.3.1. 如果你發現大家所達成的共識還有需要修改的地方，那就據此更新簡報，讓大家再重新審查一遍

• 3.6.4. 結束需求評審之後，把結論填充到文件模板裡，並將這份文件輪流傳給參與評審的每一個人，讓他們親筆簽名

• 3.6.4.1. 面對這樣一份需要簽字併為此負責的檔案時，肯定會多花一些時間，先確認自己真的明白檔案裡說的是什麼意思，然後才會在書寫簽名的那個地方留下名字

• 3.6.5. 讓其中一些人進入DRB（設計評審委員會）​，以便參與後續的設計評審環節

• 3.6.5.1. 讓評審需求的人來審查你根據這些需求所做的設計，總是有好處的

• 3.6.6. 在整個需求評審過程中，你的角色始終是給大家提出問題，並徵集大家的意見