讀資料保護：工作負載的可恢復性03構建自己的框架

躺柒發表於2024-12-04
負載框架

1. 構建自己的框架

1.1. 資料保護工作會影響本組織的各個方面

  • 1.1.1. 聽取各種人員的意見並徵得他們的同意，其中有技術人員，也有非技術人員

  • 1.1.2. 建立各種評審委員會(review board)

1.2. 文件模板

  • 1.2.1. 目標闡述

  • 1.2.1.1. 儘可能簡潔地闡述這份文件的目標，篇幅控制在一段或兩段之內

  • 1.2.2. 執行綱要

  • 1.2.2.1. 要在此部分給擁有審批權的人提供足夠的資訊

  • 1.2.3. 修訂歷史

  • 1.2.3.1. 所有的文件都應該及時更新

>  1.2.3.1.1. 隨時應對變化

  • 1.2.3.2. 幫助你瞭解正在看的是哪個版本，並且讓你知道文件是經過了怎樣的修訂才變成現在這樣的

  • 1.2.4. 簽名頁

  • 1.2.4.1. 資料保護計劃對你的組織至關重要，因此在開發這樣一個專案時，必須明確責任

  • 1.2.4.2. 確保每一位關鍵的審批人與主題專家(Subject Matter Expert, SME)都願意遵循該計劃，並在文件的最終版（也就是確定版）上簽名

  • 1.2.5. 工作策略/工作範圍

  • 1.2.5.1. 有助於把該文件所要強調的某些主題給界定清楚

  • 1.2.6. 詞彙表（術語表）

  • 1.2.6.1. 對參與審批的非主題專家來說尤其有幫助

  • 1.2.7. 附錄

1.3. 評審委員會/諮詢委員會的工作流程

  • 1.3.1. 建立一套良好的評審體制，能夠幫助你聚合不同的觀點，讓你不會忽略掉某個與該系統的部件或需求有重要關係的意見

  • 1.3.2. 需求評審

  • 1.3.2.1. 安排各個部門的成員都來參與需求評審這一環節，而且還要有一名高管，以確保整個組織都能對這個專案感到滿意

  • 1.3.2.2. CIO（Chief Information Officer，資訊長）是很合適的人選

>  1.3.2.2.1. 既瞭解組織所使用的技術，又知道組織會以何種策略來使用這些技術

  • 1.3.3. 設計評審

  • 1.3.3.1. 從那些與特定技術有關的團隊裡選擇成員來組成設計評審委員會(Design Review Board, DRB)，這些人能夠提供自己的見解，讓你知道某項技術應該如何在本組織中實現

  • 1.3.3.2. 架構評審委員會(Architecture Review Board, ARB)

  • 1.3.3.3. 初步設計評審(Preliminary Design Review, PDR)

>  1.3.3.3.1. 先讓設計方案經歷這個小環節，以確保該方案已經遵守了相關的要求
  • 1.3.3.4. 生產準備狀態評審(Production Readiness Review, PRR)
>  1.3.3.4.1. 在設計方案已全部做好並經過最終測試之後執行的，它的目標是讓大家都能夠最後再看一遍，以確認沒有漏掉什麼東西

  • 1.3.4. 操作評審

  • 1.3.4.1. 在生產環境（也就是正式的工作環境）中執行該服務的運營團隊召集在一起，讓他們參與這一環節，以充分了解自己所要執行的是什麼樣的操作

  • 1.3.4.2. 完成操作評審（operation review，也叫運營評審）後，應該形成一份使用說明，以充當該系統的使用者手冊

  • 1.3.5. 變更評審

  • 1.3.5.1. 變更諮詢委員會(Change Advisory Board, CAB)，該委員會應該是技術組織裡的一部分，用來在實施最終方案之前，把方案裡有可能對本組織的日常運營造成影響的那些變化之處稽核一遍

  • 1.3.5.2. 檢查方案裡提到的變化對本組織是否合適，以防其破壞該組織的整體工作

  • 1.3.6. 專案管理

  • 1.3.6.1. 要使用穩健的專案管理手段來推進資料保護計劃，這可以幫助你協調工作，給相關人員提供資源並安排好各項任務的時間

  • 1.3.6.2. 讓你總是能夠按時拿出應該交付的東西，並確保這個計劃順利施行

2. 設計並構建資料保護系統

2.1. 在設計環節，你的目標跟收集需求時類似，也是讓大家對設計方案達成共識

2.2. 起草多種設計方案

  • 2.2.1. 每種方案的價格、實際恢復時間(Recovery Time Actual, RTA)、實際恢復點(Recovery Point Actual,RPA)都不同，而且執行該方案的人所需具備的操作水平也不一樣

  • 2.2.2. 第一種方案，總應該是那種“無論要什麼都儘量安排，別擔心花多少錢”的方案，該方案只考慮怎樣滿足需求文件裡定義的RPO與RTO

  • 2.2.2.1. 讓大家有一個很好的參照物，知道這個所謂的完美方案或理想方案需要花費多少資金

  • 2.2.3. 第二好的方案（second-best solution，次佳方案）

  • 2.2.3.1. 自身可能有一些問題需要稍後解決

  • 2.2.3.2. 方案減少了初期需要投入的資金，讓我們能等到以後真正需要執行某些操作時再投入

  • 2.2.4. 故障是沒有什麼規律的，因此，把恢復出來的這些檔案都整理到故障之前的正常狀態，並不像你想的那麼輕鬆，有時還不如干脆少備份一些檔案，等到恢復資料時再重製那些丟掉的檔案

  • 2.2.5. 為了滿足RTO，你必須儘快把資料恢復到正常狀態，為此，你可能會削減你所恢復並整理的資料量，但是又不能減得太過，那樣就無法滿足RPO了

  • 2.2.5.1. 必須把話說得很周到

2.3. 評審設計方案

  • 2.3.1. 設計評審委員會(DRB)

  • 2.3.2. 根據最終的需求文件做個小結，然後從這個小結出發，深入探索其中某些細節問題的具體處理方式,並把這些做法記錄下來

  • 2.3.2.1. 一定要把你對RPO的要求寫下來，而且要寫出你為了滿足RTO還必須做哪些工作

  • 2.3.3. 等到確定最終的設計方案之後，你就可以將其完整地寫成文件，並讓大家輪流簽字了

2.4. 挑選部件並以此構建資料保護系統

  • 2.4.1. 準確測定恢復資料所花的時長，以確認該系統滿足了需求文件裡面寫的SLA

  • 2.4.2. 制訂操作計劃並編寫操作文件了

3. 編寫操作文件

3.1. 必須把該準備的文件全都準備好，你的工作才算完成

  • 3.1.1. 必須把該系統的用法寫成文件，讓沒有參與設計的那些人也能明白如何使用該系統，而不需要你在旁邊指導

3.2. 界定每個人的操作角色

  • 3.2.1. 每個人都必須知道自己在這個新資料保護系統裡面的地位

  • 3.2.2. RACI圖

  • 3.2.2.1. R(Responsible)是執行人

>  3.2.2.1.1. 實際執行任務的人
  • 3.2.2.2. A(Accountable)是負責人
>  3.2.2.2.1. 為任務順利完成或產品順利交付而負責的人
  • 3.2.2.3. C(Collaborator)是協作人
>  3.2.2.3.1. 幫助實際執行人完成某項任務的人
  • 3.2.2.4. I(Informed)是知情人
>  3.2.2.4.1. 需要了解任務執行進度的人
  • 3.2.3. 一定要讓ORB（Operation Review Board，執行評審委員會）審查你的RACI圖，並向他們提出問題，以此搞清楚你的這個新系統會不會對本組織造成什麼影響

3.3. 編寫操作文件

  • 3.3.1. 要確保所有的文件都已及時更新，並確保這套文件已經把這個資料保護系統所涉及的人全都覆蓋到了

  • 3.3.2. 操作手冊、執行說明或標準操作流程（Standard Operating Procedure, SOP；也稱為標準作業程式）

  • 3.3.3. 從在日常工作中接觸這個資料保護系統的人的角度寫出來的東西是很有價值的

3.4. 勸說大家編寫文件

  • 3.4.1. 大家都知道但卻都不願意去碰的事情，也就是撰寫文件

  • 3.4.2. 文件是必不可少的，而這樣的說明書、手冊或者SOP，最好能由拿這個系統執行實際任務的人來寫，而不應該由從未做過這些事的人來寫

3.5. 文件模板

  • 3.5.1. 操作說明（也就是SOP或者操作手冊）應該像早前的設計文件與需求文件一樣，遵循相應的模板

  • 3.5.2. 文件裡要有服務的概述、文件的修訂記錄，以及一張簽名頁，讓每個與執行該服務有關的部門都簽字同意

  • 3.5.3. 每一份清單都對應於日常工作中的某一項常規任務

  • 3.5.3.1. 如果操作人員的時間比較緊迫，那麼可以把手冊影印一份，每做完其中一項，就在此項前面的框裡做個記號

  • 3.5.4. FAQ（Frequently Asked Question，常見問題解答）區

  • 3.5.4.1. 用來詳細解釋我們在操作過程中可能會遇到的一些複雜問題

  • 3.5.5. 聯絡資訊

  • 3.5.5.1. 一定要寫上聯絡資訊，其中包括各大供應商的聯絡方式，讓我們能夠在某元件發生故障時，聯絡到提供該元件的那家供應商裡負責提供支援的人員

  • 3.5.5.2. 讓操作人員能夠聯絡到受這項服務影響的各個部門的負責人，以及應該得到通知的各位高管

  • 3.5.5.3. 聯絡資訊裡面要包含手機號，而且要註明遇到緊急情況時，應該優先以什麼樣的方式來聯絡這些人

  • 3.5.6. 給操作人員列出有可能出現的各種狀況，並針對每種狀況撰寫一段小結，同時給出解決辦法

  • 3.5.6.1. tracking support ticket

  • 3.5.7. 至少保留一份紙質的手冊，把它放在活頁夾裡，讓操作人員能夠方便地查閱

  • 3.5.7.1. 有了這份紙質手冊，以後停電時你就不用在機房裡使勁回想伺服器的啟動順序了，而是可以直接翻開手冊來執行操作

3.6. 納入工作環境

  • 3.6.1. 凡是要對資料保護服務做出修改（例如要升級軟體或做資料恢復測試）​，都應該先告知CAB

  • 3.6.2. 還沒有CAB，那就設立一個這樣的委員會

  • 3.6.2.1. 再指定一位變更經理（change manager；也稱變更管理者）​，這位經理專門負責CAB以及CAB所要監管的事務

  • 3.6.3. 輪到CAB（變更諮詢委員會）發表意見了

  • 3.6.3.1. 你要修改的是什麼？

  • 3.6.3.2. 這個新的東西有沒有經過全面測試？

  • 3.6.3.3. 這次變更可能影響或者將要影響哪些服務？

  • 3.6.3.4. 如果變更後的效果不理想，我們怎樣退回到變更前的狀態？

  • 3.6.3.5. 這次變更安排在什麼時候做？需要多長時間才能做完？

相關文章