業務連續性計畫最常失敗的環節並非危機發生之時，而是危機發生前的評估階段。企業完成了業務影響分析，制定了恢復時間目標，構建了全面的恢復手冊，卻在最糟糕的時刻發現，看似無關緊要的舊版身份驗證服務竟是整個電子商務平台的單點故障；原本優先級很低的 COBOL 批處理程序竟然為實時支付驗證服務提供數據；或者兩個被分配到同一恢復級別的應用程序存在未順序記錄的依賴關係，導致未恢復順序記錄的依賴關係。評估已經完成，但依賴關係卻被忽略了。
應用程式關鍵性評分是指為組織組合中的每個應用程式分配一個量化或分級的重要性指標，該指標決定了應用程式的復原優先順序、冗餘投資水準、變更控制要求以及在災難復原順序中的位置。如果僅基於業務影響調查和應用程式所有者訪談進行評分，則評分反映的是人們對應用程式功能的認知。而如果基於對應用程式實際功能的結構分析，例如誰調用誰、哪些資料流經哪些程式、哪些共享元件位於多個高優先級系統的關鍵路徑上等，則評分能夠反映實際運作情況。
信念與現實之間的差距正是業務連續性計畫失敗的原因。
應用程式關鍵性評分實際衡量的是什麼
關鍵性並非單一維度。為了確定企業應用程式的關鍵性評分，可以考慮使用者回饋來評估企業應用程式的關鍵性或重要性，包括對策略業務需求的最大影響、對業務合作夥伴的影響、對客戶互動的影響以及對其他企業應用程式的影響。這些維度分別體現了「關鍵性」的不同面向：
業務影響是指組織每小時停機造成的損失。收入損失是最顯而易見的：一個每小時處理 10 萬美元的支付處理系統，每停機一分鐘都會造成可量化的成本。但業務影響不僅限於收入，還包括監管風險（停機會觸發哪些合規義務？）、聲譽損害（客戶是否直接受到影響？）以及合約違約（服務等級協議 (SLA) 是否會觸發違約條款？）。
運行依賴性是指有多少其他系統或流程依賴於此應用程式。一個對業務影響較小的應用程式可能具有很高的關鍵性，因為它位於對業務影響較大的應用程式的依賴路徑中。例如，為所有其他面向客戶的應用程式提供支援的身份驗證服務，其關鍵性遠超其自身功能所暗示的。
恢復複雜性是指應用程式復原的難度和耗時。一個對業務影響中等、恢復時間為 48 小時的應用程序，可能需要比一個對業務影響更大、恢復時間為 2 小時的應用程序投入更多的冗餘資源，因為前者的總停機風險更大。
監管義務是指哪些應用程式需要遵守監管連續性要求。受《資料保護條例》(DORA) 約束的金融機構必須證明其關鍵或重要功能能夠承受特定中斷情境。受《健康保險流通與責任法案》(HIPAA) 約束的醫療機構必須保障包含受保護健康資訊的系統的可用性。對於特定應用程序，監管因素可能會凌駕於業務影響評分之上。
關鍵性評分是所有四個維度的綜合評分，權重取決於組織的特定風險承受能力、監管環境和商業模式。
標準關鍵等級
大多數企業應用組合都採用四級關鍵性模型。應用關鍵性矩陣中的關鍵性類別包括：任務關鍵型、業務關鍵型、業務營運型和管理型。以下定義反映了符合 ISO 22301（業務連續性管理系統）和業務連續性協會良好實踐指南的當前行業實踐：
一級關鍵任務應用，其故障會立即導致核心業務營運中斷或造成不可接受的監管或安全風險。恢復時間目標 (RTO)：通常為 0-4 小時。恢復點目標 (RPO)：通常為 0-1 小時。例如：核心銀行交易處理系統、即時交易系統、緊急調度系統、工業控制介面、支付授權系統。這些應用需要最高的硬體基礎設施投資：雙活冗餘、零 RPO 複製、自動故障轉移以及最嚴格的變更控制。
二級關鍵業務應用，其故障會嚴重影響業務運營，但不會立即停止營運。恢復時間目標 (RTO) 通常為 4-24 小時。恢復點目標 (RPO) 通常為 1-4 小時。例如：客戶關係管理系統 (CRM)、企業資源規劃 (ERP) 模組、訂單管理系統、薪資發放期間的人力資源系統、監管申報窗口期的報告系統。這些應用需要高可用性基礎設施、定期測試的故障轉移機制以及優先順序恢復順序。
第三級：業務運營應用，這類應用支援業務運營，但其臨時不可用可透過手動變通方案進行管理。恢復時間目標 (RTO)：通常為 24-72 小時。恢復點目標 (RPO)：通常為 4-24 小時。例如：內部協作工具、非客戶報告、管理入口網站、培訓平台。標準的備份和復原流程適用。
第四層級：管理類應用程序，用於支援管理功能，對營運無直接影響。恢復時間目標 (RTO)：通常為 72 小時以上。復原點目標 (RPO)：24 小時以上或上次備份時間。例如：內部文件維基、非必要開發工具、歷史報告。根據實際情況從備份恢復。
層級劃分並非永久性的。一個應用程式在一年中的大部分時間裡屬於三級，但在月末財務結算、監管報告期或交易高峰期，其層級可能會降至二級。動態關鍵性（即根據營運日曆調整層級）是成熟業務連續性計畫 (BCP) 的組織在建立基準層級結構後實施的一種改進措施。
評分方法：將維度轉換為數字
結構化的評分方法將四個關鍵維度轉化為一個數值分數，從而客觀地而非受組織政治因素影響地進行層級劃分。以下方法使用加權標準產生一個 0-100 的綜合分數：
維度 1：業務影響（權重：35%）
| 停機時間每小時造成的收入影響 | 總分 |
|---|---|
| 每小時超過 1 萬美元 | 35 |
| 每小時 1 萬至 100 萬美元 | 28 |
| 每小時 10 美元至 100 美元 | 21 |
| 每小時 1 美元至 10 美元 | 14 |
| 每小時收入低於 1 美元 | 7 |
| 對收入無直接影響 | 0 |
監管影響（因停電而觸發的 DORA、HIPAA、PCI-DSS、SOX 合規義務）在此維度上增加了 10 分。
維度 2：營運依賴（權重：30%）
| 扇入：依賴此應用程式的應用程式 | 總分 |
|---|---|
| 超過 20 個依賴應用程式 | 30 |
| 10-20 個依賴應用程式 | 24 |
| 5-9 個依賴應用程式 | 18 |
| 2-4 個依賴應用程式 | 12 |
| 1 個依賴應用程式 | 6 |
| 無受扶養人（獨立） | 0 |
這裡的扇入計數指的是結構依賴計數，即調用此應用程式、讀取其輸出或依賴其資料的應用程式數量，而不是使用者數量或感知重要性。由於應用程式所有者並不了解其所有下游用戶，因此該維度在調查中最常被錯誤計算。
維度 3：恢復複雜度（權重：20%）
| 未預置災難復原的預計復原時間 | 總分 |
|---|---|
| > 72小時 | 20 |
| 24 72小時 | 16 |
| 8 24小時 | 12 |
| 2 8小時 | 8 |
| <2小時 | 4 |
| 自動故障轉移 < 15 分鐘 | 0 |
維度 4：資料敏感度和監管義務（權重：15%）
| 資料分類和監管要求 | 總分 |
|---|---|
| 受監管的個人識別資訊/個人健康資訊/健康數據，並有明確的恢復時間義務 | 15 |
| 受監管數據，無特定恢復時間義務 | 12 |
| 敏感內部資料（商業機密、財務記錄） | 9 |
| 內部營運數據 | 6 |
| 非敏感內部數據 | 3 |
| 沒有儲存數據 | 0 |
綜合評分與等級對應關係：
| 綜合得分 | 層級分配 |
|---|---|
| 75-100 | 一級，關鍵任務 |
| 50-74 | 二級，業務關鍵型 |
| 25-49 | 三級，業務運營 |
| 0-24 | 第四層級，行政人員 |
依賴性問題：為什麼基於調查的評分會出錯
營運依賴性維度最容易被誤判，一旦出錯後果也最為嚴重。看似無關緊要的傳統身分驗證服務可能成為整個電子商務平台的單點故障，其故障可能導致所有創收交易中斷。這個過程超越了抽象的威脅，將影響轉化為對服務等級協議的具體、可衡量的影響。
應用程式擁有者了解其直接上游依賴項，即它們所呼叫的系統。但他們很少了解其完整的下游依賴項，即調用它們的系統。一個內部使用者身分驗證服務可能被其所有者視為低關鍵性服務（它不產生收入、結構簡單、很少發生故障），但卻被十二個面向客戶且均為一級（Tier 1）的應用程式所依賴。此身分驗證服務的實際關鍵性為一級，並非因為其自身功能，而是因為其在更高層級系統的依賴關係圖中的位置。
基於調查的關鍵性評分會系統性地產生這種誤差。應用程式所有者調查問卷會問：「這個應用程式的關鍵性如何？」身份驗證服務所有者會根據服務本身的功能回答「低到中等」。然而，十二個依賴應用程式的所有者並沒有回答關於身份驗證服務的調查問卷，而是回答關於他們各自應用程式的調查問卷。這樣一來，依賴關係就無法被捕捉。
其後果體現在恢復順序：業務連續性計劃 (BCP) 根據調查得出的關鍵性評分定義了恢復順序，並將身份驗證服務安排在三級恢復階段。在實際事件發生時，本應先恢復的一級應用程式卻無法恢復，因為它們所依賴的身份驗證服務尚未恢復。恢復順序在其最關鍵的依賴項處失敗。
調查總是忽略三種依賴類型：
隱藏的共用組件。一個內部 COBOL 程序負責處理三個獨立業務流程的貨幣轉換，而調查顯示這三個流程之間並無共享組件，因此該程序構成了一個隱藏的依賴關係，會影響所有三個流程的恢復。如果該貨幣轉換程序屬於第 3 層級，而這三個業務流程中的任何一個屬於第 1 層級，則該貨幣轉換程序的實際關鍵性為第 1 層級。
數據管道依賴關係。使用其他應用程式批次處理資料的應用程式之間存在一種時間依賴關係，而非即時依賴關係。風險並非同時發生故障，而是順序故障：下游應用程式恢復，但其資料來源尚未恢復到相同的恢復點，導致表面上看似正常運行，但實際上使用的是過時資料。除非追蹤資料流本身，否則此類依賴關係不會出現在網路拓撲圖或呼叫圖分析中。
共享配置和模式依賴關係。即使應用程式之間從未直接調用，共享資料庫模式、配置服務或身分提供者的應用程式也存在隱式依賴關係。共享資料庫中的模式變更可能會影響多個應用程式。如果在模式損壞後僅恢復一個應用程序，而不會恢復所有共享該模式的應用程序，則會導致整個應用程式組合的狀態不一致。
業務連續性計畫整合：關鍵性評分如何驅動復原決策
關鍵性評分是六項特定業務連續性計畫 (BCP) 設計決策的意見：
1. 恢復順序定義。應用程式依嚴重性順序恢復，即第一層級先於第二層級，第二層級後於第三層級；但在同一層級內，恢復順序由依賴關係圖決定。沒有入站依賴（即沒有其他應用程式依賴它們）的應用程式可以按其所在層級的任意順序恢復。扇入度高的應用程式必須在其依賴項之前恢復，無論它們在同一層級內的相對得分如何。因此，恢復順序是：層級順序應用於每個層級內受依賴關係約束的子序列。
2. 設定復原時間目標 (RTO) 和復原點目標 (RPO)。關鍵性評分用於校準 RTO 和 RPO 目標。每個生產應用程式的最大可容忍停機時間 (MTD) 和復原點目標 (RPO) 構成了整個業務連續性策略的技術基石。 MTD 是企業可以容忍應用程式不可用的最長時間。 RTO 必須小於 MTD。 RTO 和 MTD 之間的裕量即為安全緩衝。對於每小時停機時間都會對業務造成重大影響的一級應用程序，其 MTD/RTO 裕量較窄，需要設計用於快速自動恢復的基礎設施。
3. 基礎設施投資校準。關鍵性評分直接影響災難復原基礎設施的投資決策。一級應用需要採用多區域雙活冗餘架構。二級應用需要採用經過測試的故障轉移雙活架構。三級應用程式需要定期備份並制定完善的復原流程。四級應用程式可以依賴標準備份策略。如果沒有關鍵性評分，基礎設施投資決策要麼會陷入過度投資（成本高昂），要麼會陷入投資不足（風險巨大）。
4. 變更控制要求。關鍵性評分較高的應用程式需要更嚴格的變更控制：更長的變更凍結期、更多強制審批人、更廣泛的變更前測試以及更保守的回滾程序。將一級變更控制應用於四級應用程式會浪費工程時間。將四級變更控制應用於一級應用程式會造成不可接受的風險。
5. 測試和驗證頻率。業務連續性計畫 (BCP) 要求定期測試復原流程、進行桌面演練、組件級故障轉移測試以及完整的災難復原模擬。關鍵性評分決定了測試頻率：一級應用程式需要每季進行一次災難復原測試；四級應用程式需要每年進行一次測試。對所有應用程式都採用相同的測試頻率既不實際也沒有必要。
6. 供應商服務等級協定 (SLA) 要求。對於依賴第三方服務的應用，關鍵性評分決定了供應商合約中必須包含的 SLA 要求。一級應用（恢復時間目標 (RTO) 為 4 小時）需要第三方 SLA 來保證與該 RTO 一致的可用性。四級應用則無需此類要求。
遺留系統複雜性
遺留系統使得關鍵性評分變得複雜，而現代應用程式組合管理框架無法充分解決這些問題。標準的關鍵性評估假設應用程式擁有者了解其應用程式的功能以及依賴項。但對於遺留系統，例如由多代開發人員維護的 COBOL 程序、依賴關係最後一次記錄於 2008 年的 JCL 作業流，以及生成輸出文件供當前組織內無人編寫的進程使用的 RPG 程序，這一假設並不成立。
遺留系統的實際依賴結構只能在程式碼本身看到。一個 COBOL 程式寫入一個資料集，而該資料集又被十二個下游程式讀取，那麼該程式就有十二個下游依賴項，但 COBOL 程式的擁有者可能不知道這一點，因為他/她看到的只是程式的功能（處理日常事務），而看不到程式的結構性作用（產生支援其他十二個流程的資料集）。
對於遺留系統，關鍵性評分的依賴性維度需要進行程式碼分析，而非依賴關係調查。 COBOL 程式的扇入計數只能透過檢查環境中所有其他程序，並確定哪些程序引用了程式的輸出資料集、呼叫約定或共用副本來得出。結構化程式碼分析平台提供的正是這種分析，如果沒有這種分析，分配給遺留程序的任何關鍵性評分的依賴性維度充其量只能是一種基於經驗的猜測。
誤判遺留應用程式的關鍵性會造成極其嚴重的後果，因為遺留系統往往既高度關鍵（它們通常包含數十年積累的核心業務邏輯），又評分偏低（其所有者無法明確說明哪些環節依賴於它們，因此會給出保守的評分）。結果是，一些實際上位於一級業務流程關鍵路徑上的遺留程序被評為三級，而這正是實際事件中恢復序列失敗時出現的典型故障模式。
SMART TS XL 提供關鍵性評分的依賴性證據
SMART TS XL 直接解決應用程式關鍵性評分的依賴性問題，適用於基於調查的方法最不可靠的應用程式類別。
應用程式依賴關係映射功能建構了環境中所有語言的完整依賴關係圖：包括每個相互調用的 COBOL 程式、每個生成下游程式所需資料的 JCL 作業步驟、每個在互不直接調用的程式之間創建隱式依賴關係的共享副本，以及在生產者和消費者程式之間流動的每個資料集。此圖是關鍵性評分的依賴關係維度、扇入計數、共享組件標識以及調查無法可靠捕獲的隱藏資料管道依賴關係的結構性證據基礎。
影響分析功能使得依賴關係圖可用於業務連續性計劃 (BCP) 規劃：對於組合中的任何應用程序，枚舉所有直接或間接依賴於它的其他應用程序，這些應用程序因此繼承了它的可用性要求。一個 COBOL 程式有三個直接依賴項和二十個間接依賴項（依賴這些直接依賴項的程式），其有效關鍵性反映的是它所處的二十三個程式的關鍵路徑，而不僅僅是它自身的功能。
靜態程式碼分析功能揭示了影響復原複雜度維度的結構複雜度指標：圈複雜度、耦合度指標、死程式碼百分比和技術債務指標，這些指標可以預測每個應用程式的復原時間和風險。與功能相同但架構清晰的應用程式相比，具有高複雜度和高耦合度的應用程式恢復成本更高，其第三維度恢復複雜度得分也更高。
企業級搜尋功能使得在業務連續性計劃 (BCP) 的整個生命週期內，都可以查詢完整的依賴關係清單：查找訪問特定資料集的每個程序（識別所有依賴於該資料集可用性的程序）、共享特定副本的每個程序（識別所有受副本可用性影響的程序）、在特定批次視窗中運行的每個 JCL 作業程序（識別所有受副本可用性影響的程序）、在特定批次視窗中運行的每個 JCL 作業程序（識別所有受副本可用性影響的程序）、在特定批次視窗中執行的每個 JCL 作業程序（識別所有受副本可用性影響的程序）、在特定批次視窗中執行的每個 JCL 作業程序（識別所有受副本可用性影響的程序）。此搜尋功能支援年度關鍵性評分審查，確保評分隨著應用程式組合的演變而保持最新。
對於進行以下活動的組織 遺產現代化 與業務連續性計劃 (BCP) 開發相關的項目， SMART TS XL的分析同時服務於這兩個目的：用於確定關鍵性評分的依賴關係圖也決定了遷移順序，而用於確定恢復複雜性評分的複雜性指標也決定了現代化工作量的估算。
保持評分最新：年度審查週期
業務連續性成熟度評估應幫助您完成三件事：了解現狀、識別最重要的差距，並制定切實可行的改進方案。這才是使成熟度評分成為更完善的方案的關鍵。
隨著組織的變化，應用程式關鍵性評分會偏離實際情況。新的應用程式不斷湧現，舊的應用程式雖然被淘汰但並未完全停用，以前互不依賴的應用程式之間也建立了整合。業務流程不斷變化，其所依賴的應用程式也隨之改變。監管要求不斷演變，並帶來了新的恢復義務。
年度關鍵性評分審查週期應包括：
結構重新分析。重新運行依賴關係映射，以識別自上次審查以來引入的新依賴項。原本獨立的應用程式現在可能存在依賴項，提高了其關鍵性。而先前高度依賴的應用程序，其用戶可能已遷移到更新的系統，從而降低了其關鍵性。
業務影響重新評估。隨著業務成長和應用組合的演變，收入和營運影響數據也會改變。三年前每小時業務價值為 1 美元的應用，隨著業務增長，現在可能要處理十倍的業務價值。
恢復測試結果的整合。災難復原測試揭示了假定的復原複雜度與實際復原複雜度之間的差距。在初始評估中恢復複雜度得分較低的應用程序，可能在桌面演練中表現不佳，這表明需要向上修正評分。
監理變更審查。新法規或現有法規的變更可能會對特定應用施加新的恢復時間義務。例如，DORA 法規對歐盟金融機構的營運彈性要求，對「關鍵或重要功能」施加了特定的恢復時間義務，而這些義務可能並未反映在 DORA 法規生效前的關鍵性評分中。
擁有成熟的業務連續性計劃 (BCP) 的組織不會將關鍵性評分視為一次性工作，而是一個持續的過程：當應用程式依賴關係、業務影響或監管義務發生重大變化時，評分就會更新，並透過結構化審查每年進行驗證。
得分的好壞取決於其依賴性證據的品質。
應用關鍵性評分的價值在於，其依賴性維度應基於結構性證據而非問卷。業務影響和監管義務維度可以透過訪談和業務流程分析進行可靠評估。而營運依賴性維度則無法透過這種方式評估，因為它需要了解每個應用所依賴的元件，而應用程式所有者往往會系統性地低估其下游用戶。
故障模式是可以預測的：基於調查得出的關鍵性評分所建構的復原序列會在隱藏的依賴項處失效。遺留身份驗證服務恢復延遲。當依賴 COBOL 貨幣轉換程式的應用程式嘗試恢復時，該程式處於離線狀態。共享資料庫模式的復原點與從中讀取資料的應用程式的復原點不同。結構分析提供的依賴關係證據可以預防所有這些故障，而且在實際事故中發生這些故障比在桌面演練中發生這些故障代價更高。
評分方法已建立，框架也已存在。大多數組織面臨的差距不在於評分框架本身，而是其最關鍵維度的證據基礎。在下一次事件需要業務連續性計劃 (BCP) 發揮作用之前，必須透過結構分析來彌補這一差距。
