ylchang@iii.org.tw

1. 前言

距離公元2000年已不到180天，全世界正歡天喜地在迎接一個新世紀的來臨之際，同時Y2K危機，卻正困擾著世界各國、社會各階層、各行業，一場跨世紀的除蟲大戰，亦正如火如荼地在全世界各地開展。有人說『Y2K危機是人類跨世紀最大的災難。』，您相信嗎？其實，Y2K危機問題的嚴重性，早已受到世界有識人士的重視與關注，紛紛提出詳盡而廣泛的研究分析報告，大聲疾呼各重要政府機構及民間企業，要迅速採取因應對策，使Y2K危機禍害降至最低限度。

不論您是企業的經營者、高階主管、基層幹部或一般員工，您是否已經充分認知Y2K危機，了解其嚴重性，並且已經採取了因應措施呢? 坊間探討Y2K危機問題因應措施之文章與書籍，已相當豐富，且目前已進入公元2000年倒數階段，本文將協助大家思考，當電腦年序揮別1999年進入2000年時，萬一現行修改計畫無法如期完成，或有疏漏，而導致企業業務無法正常營運時，如何規劃一套緊急應變計畫，以確保公元2000年來臨時，公司或機關的業務不會因為Y2K問題發生而中斷或錯亂，造成鉅大損失，應是當務之急。

2. Y2K危機問題影響之認知

甚麼是千禧虫？在電腦發展初期，硬體設備非常昂貴，任何程式均要儘量節省記憶體的儲存空間，在處理時間資料時，習慣將年份以二位數表示，造成資訊系統無法分辨2000年與1900年，此外千禧虫還有個分身叫閏年，容易為大家所忽略。這些蟲子可能在所有資訊系統先後發作，造成整個作業系統癱瘓！主機系統僅是冰山的一角，個人電腦及使用嵌入式晶片之系統更是可怕！你有沒有想過核能電廠可能會出事？你有沒有想過沒有水電的日子？銀行領不到錢，卻收到天文數字的帳單！

為了整個公元2000年資訊危機計畫能順利推動並使企業能安然過渡到公元2000年，必須獲得企業內高層決策主管認可與支持，並成立高階指導小組，宣導此一危機對企業之影響，確認企業所有員工了解此一危機，願意同心協助計畫之執行，減少企業內部門間的衝突與誤解。

另外在推動Y2K危機計畫時，經常會遇到如下幾個誤解:

1. 大企業才有Y2K的問題

Y2K是資訊技術問題，與企業的大小無關。固然大企業自動化程度高，所承受的風險比較大，但由於早有危機意識，起步較早，加上財務與人力資源較豐富，反而問題較少。相形之下，許多中、小型企業至今對Y2K危機仍然一知半解，才是問題所在。

2. 新換系統沒有Y2K問題

除非確實經過完整之測試，不要假定新換系統沒有Y2K問題，主要是因為許多設備或系統供應商本身對Y2K問題都缺乏了解，特別是在Non-IT領域尤其嚴重，因此如何能確保所有新換的系統沒有Y2K問題。

3. 解決Y2K是MIS部門的事

嵌入式晶片的應用層面，早已經到達『無所不在』的程度。一般辦公室常見的傳真機、影印機、印表機、電力系統等設備，都有可能發生Y2K問題。至於工廠之自動化設備，更不用說。因此，Y2K絕對不僅是資訊系統問題，而是企業內所有部門人員均需關注的問題。

4. Y2K危機僅是單一企業內部的問題

企業置身於產業環境下，必然有許多往來的廠商，在這生產供應鏈當中，只要有一環節受到Y2K問題的衝擊，企業本身也將可能受到影響波及。往來廠商可略分為:基礎產業、上游供應商、下游產品客戶、協力廠商、金融體系、關係企業……等。

3. 何謂緊急應變計畫

緊急應變計畫是針對現行一般作業模式，在經過周詳考慮後所提出之替代方案。它亦是：

一、處理未知風險之持續經營策略。

二、風險評估過程之產出物。

三、組織處理下列事項之細節：

1.緊急事故時的最初反應﹔

2.風險管理﹔

3.將損害降至最低程度﹔以及

4.如何回復正常作業程序。

四、確認組織之關鍵性業務流程／設備，並且在災害發生時能迅速恢復正常。

五、提供事先預定之行動綱領，而能：

1.減少決策所需時間﹔

2.快速恢復關鍵性之服務﹔

3.最短時間內恢復可接受之最低程度服務﹔並且

4.藉由多數資源回復正常而降低災害之衝擊程度。

六、可應用於一般工作、業務流程或甚至是整體組織階層。

4. 緊急應變計畫之基本原則

一個完善的緊急應變計畫應該是：

一、內容清晰且易於了解。

二、保持適度彈性且在任何時間均能確實執行。

三、明確定義其適用之組織、場所或使用時機。

四、以組織結構及日常工作之規劃為基礎。

五、讓員工熟悉以確保其有效性。

六、整合組織內不同的行動方案及計畫。

七、具有彈性，因此能處理不同等級之風險及範圍工作。

八、有經過週期性的測試。

5. 與其他計畫之關連性

在處理各式操作上的問題及事故時，已有一系列之應用計畫。它們包括持續性經營管理、業務持續計畫、災害復原計畫、系統回復計畫及緊急應變計畫等。在某些事件中這些計畫有時可交換應用，有時則代表完全不同之處理流程。

在組織內描述某一流程所使用之計畫名稱，並不是重點所在。只要負責之組織成員知道並了解其內容即可。

緊急應變計畫可說是一般持續性經營管理之一部份。雖然可與災害復原計畫合併，然而彼此卻擁有不同的面貌。以傳統之觀點而言，災害復原計畫主要是針對實體之損害，例如火災或水災所造成之損失，並且企圖依賴備用之設備及備份之資料來恢復正常作業。緊急應變計畫則主要是針對公元2000年年序危機之處理，然而組織必須了解外部資源或許無法適時支援，甚至本身亦可能受同樣問題所影響。

6. 計畫時機

一般而言，緊急應變計畫應該是任何業務運作中不可或缺的一部份，並且是永續進行的計畫。

一、在危機中規劃和執行具成本效益之替代措施時，如果預期會發生困難則應立刻開始計畫。

二、在遭受關鍵性日期所產成之危機衝擊下，必需立刻擁有並執行緊急應變計畫時。

三、組織或許不願意太早開始，然而有限之資源也許將完全轉移至已完成準備之一方。

四、所有準備事項必需就定位，以避免最糟情況發生時。然而時間緊迫。

五、組織已有部分業務運作必需處理公元2000年日期。

六、組織至少應該為所有關鍵性資訊系統及資源，包括非IT部分發展緊急應變計畫時。

七、部分系統雖非屬關鍵性業務流程，然而一旦失敗時將對持續性運作造成負面之衝擊。此

時仍應針對此系統發展緊急應變計畫。

八、決定何者適合發展緊急應變計畫並非永遠是直接了當的，因為系統通常具有高度之整合

性，因此一個關鍵性系統或許依賴於另一個非關鍵性系統。

7. 執行實際查核

當發展緊急應變計畫時，應在最後完成時實施實際查核工作。應該被提出之問題如下：

一、計畫之可行性如何？

二、是否可真正達到目的？

三、計畫是否處於適當之服務階層？

四、是否成本太高？

在某些情形下緊急應變計畫可能無法順利執行。如電力供應長時間中斷，例如:當發電機失效或發電機之燃油用盡時，則業務運作將被迫停止。如此一來緊急應變計畫就應該包括此種停止之處理程序。

8. 風險評估與管理

風險管理是組織針對危機鑑定、量化、評估及行動之重複性執行過程。緊急應變計畫則是風險評估過程之產品。組織之風險管理計畫及業務優先順序將決定緊急應變計畫之需求。風險管理計畫可說是：

一、確認組織所面臨之危機並且保證危機可被充分了解並予以最小化。

二、範圍廣闊而且包含所有資源種類，例如組織成員、設備、系統等等危機簡化策略。

緊急應變計畫可以說是組織風險管理策略一部份，因此必須與整體風險管理計畫原理及目標一致。

一般而言，各公司機構必須：

一、檢閱所有業務運作及確認風險之形式。

1.何者可能發生？

2.如何發生？

3.將於何處發生？

4.探求可信度高之風險來源。

二、風險之量化與評估。

1.檢閱現有管理模式。

2.確認可能發生之失敗。

3.確定失敗後所產生之影響。

4.建立風險之等級(例如：失敗之可能性 X 影響程度)。

5.將所有風險分級。

三、處理及降低風險行動。

1.確認所有方案。

2.選擇最佳可行方案。

3.發展降低風險計畫。

4.執行計畫。

9. 公元2000年特有風險

公元2000年特有風險必須予以考慮，主要範圍包括：

一、針對關鍵性應用系統Y2K修改工作無法及時完成。

二、新系統更換無法及時完成。

三、Y2K修改工作失敗，並且導致關鍵性系統失效或產生錯誤結果。

四、嵌入式晶片或韌體(例如火災警報器、安全系統、PABX、電梯、空調、流程控制系統等

等)可能故障或無法正常運作。

五、業務上合作夥伴可能無法及時完成系統轉換，導致彼此系統間介面無法正常運作。

六、公共設施，例如電力、水力、通訊及交通系統可能受損，導致一段時間無法正常使用。

七、供應鏈上游或下游部分，可能遭受Y2K問題衝擊，並進而影響組織本身。

八、傳統回存設施，例如備用電腦設備，在公共設施無法正常服務或軟體遭遇Y2K年序問

題時，將無法使用。

10. 降低風險之策略

降低已知風險是風險管理上重要之一環。在接近公元2000年之際，組織降低風險部分，主要是在執行Y2K相關計畫時針對系統修改、測試或轉換等工作。

組織在面臨Y2K問題時應該考慮進一步行動，即是準備與關鍵性日期相關計畫。此型式計畫包括日期接近時、日期轉換時及日期通過時。而緊急應變計畫則可在上述計畫失敗時，提供替代之行動方案，並且也是在Y2K問題上降低業務危機之最後，也是最佳之步驟。

至於在準備與關鍵性日期相關計畫時，考量重點應該是根據個別組織需求。不過一般而言可包括以下各點：

一、盡可能提前作業(例如薪水發放作業、救濟金發放作業及執照更新等等)。

二、延後工作時程(例如開發票作業、維護作業)。

三、在2000年即將來臨前完成所有系統之備份。

四、在2000年即將來臨前備份各主要及參考檔案，及其他重要關鍵性文件(例如紙張或電子

檔)。

五、在2000年即將來臨前將所有設備關閉，並且在2000年來臨後逐一開啟相關設備，直到

全部設備運作正常為止。

六、針對內部關鍵性業務流程部分，儲存重要輸入資料。

七、針對客戶端所提供之服務部分，儲存重要輸出資料。

八、在公元1999年與2000年交接之際，為降低人員受建築物內系統或設備影響，可安排部

分人員暫時離開。

九、排定人員輪值表以確保在關鍵日期屆臨時，重要人員不致缺席。

十、儘可能減少商業活動，以將可用之資源投入緊急應變之處理。

十一、測試備用發電機並確保油源供應正常。

十二、安排緊急用水供應，例如供水車或儲存瓶裝水。

十三、安排系統及設備最終測試。

十四、在2000年來臨前，安排與重要資源供應商簽訂服務合約。

11. 緊急應變計畫執行步驟

針對組織整體所發展公元2000年緊急應變計畫，應該是包括對業務流程、系統及設備等內容所發展出之緊急應變計畫。而此計畫所以重要實因其影響範圍涵蓋組織全體。

緊急應變計畫應該是流程(process)而不是計畫(plan)。一旦計畫發展完成就必須定期更新，並且確保相關工作均已準備就緒。

緊急應變計畫發展流程與Y2K計畫本身相同。亦即是，從清查、評估、計畫、修改、測試及上線等依序發展。以下為發展流程：

1. 清查

1.組織內部現有之相關計畫(例如business recovery, emergency response等等)為何？

2.是否已具有緊急應變計畫管理架構？

2. 評估

1.現有計畫是否更新且已文件化？

2.現有計畫是否已足以應付公元2000年之問題？

3.相關人員是否已接受足夠訓練？

4.計畫是否已測試過？

5.是否已包括所有關鍵性系統及設備？

6.若有緊急應變計畫之管理架構，它們是否合宜？

7.管理階層是否接受開發新計畫或修改現有計畫之必要性？

8.管理階層之支持程度是否足夠？

3. 計畫

1.確認緊急應變計畫所需之流程、系統及設備。

(1)哪幾項操作程序、產品及服務可能遭受衝擊，衝擊時間多久？(此項分析至少應包括所有關鍵性系統及設備)

(2)重新界定關鍵性系統優先順序。

(3)在技術上，緊急應變計畫應該包括：自行開發之應用程式、硬體、套裝軟體、操作介面、韌體、業務上之合作夥伴、以及含嵌入式晶片之系統或設備。

2.確認關連系統及設備所需之應變計畫。

(1)如果應用軟體需要計畫，則配合之硬體也需要計畫。

3.根據優先順序發展計畫。

(1)不可能為所有項目規劃緊急應變計畫。

(2)從最高優先之計畫開始。

(3)根據風險狀況，平衡Y2K問題修改及發展緊急應變計畫之工作。

4.預估失敗後損失之費用。

(1)如果訂定緊急應變計畫所需之費用大於問題發生後之損失，則考慮不發展。

(2)計畫所保護之系統，應有相當之複雜度。

(3)例如緊急應變計畫對傳真機而言，可能僅是單純的購買新機。

5.確認所有可能緊急應變策略，其應用範圍包括：

(1)以手動模式替代自動化系統與設備(有時稱之為work-arounds)﹔

(2)僱用額外人力來支援設備無法控制時之工作

(3)將商業活動降為較低之層級﹔

(4)關閉部分系統以避免問題擴大﹔

(5)訂定取代現有工作方式替代方案﹔

(6)購買或租用足夠油源發電機，以作為備用電力來源﹔

(7)在可能情況下，重新設定流程控制系統之日期或將日期往回調整﹔

(8)為降低人員受建築物內系統或設備之影響，可安排部分人員暫時離開，滿足最少人力需求，且同時關鍵人員不致缺席﹔

(9)安排與重要資源供應商簽訂服務合約以備不時之需。

6.發展緊急應變時期之通信策略：

(1)誰是通信人員？

(2)誰決定通信內容？

(3)決定聯絡管道為何？組織成員、客戶、供應商、新聞媒體、管理者、政府行政首長等等。

(4)在緊急狀況下，與組織成員維持聯繫機制為何？

(5)如何統一對外陳述所作估計，以免估計被誤解為保證？

7.在計畫過程中，針對所有範圍(例如組織成員、承包商及供應商等等)發展相關策略。

4. 計畫及程序

1.修訂現有計畫或發展新計畫。

2.修訂或執行適當管理規劃。

3.檢視組織現有任務狀態、策略計畫及風險管理計畫以獲得相關訊息，例如服務等級、反應

時間等，如此有助於引導緊急應變計畫之規劃。

4.評估每一流程、系統及設施，以確認可能之失敗點。

(1)例如應用軟體之失敗點可能包括：存在於應用軟體內部之程式模組、執行應用軟體之硬 體、硬體本身之操作系統、及應用軟體可由他處獲得日期資料之通信介面。

5.確認每一問題點之風險及衝擊。

(1)針對問題之可能性與影響性予以評估。

6.針對每一問題點發展緊急應變計畫。

(1)建立計畫以應付可能之問題。

(2)一個單獨的緊急應變計畫可能適用於許多不同之問題點，只要問題點彼此具有相類似特 性。

7.為配合緊急應變措施之執行，應事先協商、定義及文件化可接受之服務層級。可能之層級包括：

(1)正常服務層級─此層級提供之服務相當於平常時期之服務。例如用一部完全相同的設備

取代出狀況的設備。

(2)降低服務層級─此層級提供之服務水準低於平常時期之服務。。

(3)簡化服務層級─此層級提供相較於平常時期不同之服務。

(4)終止服務─部分組織內少數系統及設施可選擇此層級。

5. 測試

1.測試是確保緊急應變計畫能如預期有效執行之關鍵。

2.組織成員執行計畫前必須接受適度訓練。

3.完整的緊急應變計畫測試可能是昂貴且不切實際的。因此應依據組織之關鍵性業務決定合理的測試等級及形式。

4.部分設備必須完成測試。

5.測試應用方法可包括：

(1)模擬(Simulation)﹔

(2)模型(Modeling)﹔

(3)排程(Walk-throughs)﹔

(4)桌上稽核(Desktop audits)﹔

(5)練習(Exercises)。

6.實際經驗已證明，測試過之計畫比未測試過者擁有較高之成功率。

6. 上線

1.獲得管理者對計畫之核可。

(1)這是建立計畫時最後且關鍵之一步。

(2)管理者必須了解並且支持每一計畫。

(3)上述觀點所以重要乃因許多計畫均將無可避免是高成本的。

(4)管理者必須了解替代方案之深度與廣度，以便正確運用資源。

2.定期更新緊急應變計畫。

3.在需要時執行緊急應變計畫。

12. 緊急應變計畫文件化

通常業務上之緊急處理及持續運作計畫，被認為應該擁有較長之生命週期，且必須具備正式文件及予以適當的維護。然而針對公元2000年問題之緊急應變計畫將明顯擁有較短之生命週期，因此正式文件不一定需要印刷精美。然而在危機發生時期，公元2000年緊急應變計畫在處理危機時必須具備功能性及實用性。因此擁有正式文件顯然是有幫助的。

在文件化緊急應變計畫時可參考下列要素。

1. 確認

1.標題及計畫所涵蓋系統或設施描述。

2.組織名稱。

3.生效日期。

4.計畫建立者。

5.關聯計畫。

2. 授權

1.負責人之姓名、頭銜及簽名。

2.核可日期。

3. 計畫目的

1.目的是計畫本身非常重要之元素。

2.所有的緊急應變計畫不一定要有相同的目的。

3.緊急應變計畫具有下列目的之一。

(1)維持正常運作。

(2)在降低服務水準下，持續運作。

(3)在儘可能快速及安全情形下，停止運作。

4.組織在業務上的優先順序及應變策略上替代方案複雜程度和所需費用，將決定計畫本身之目的。

4. 啟動緊急應變計畫之標準

1.在啟動緊急應變計畫時，應該要有清楚、明確定義且自動的標準(有時可稱之為自動調整之標準)。

2.在眾多標準中如能限制主觀因素所認定之數量，將有利於在面臨失敗時快速反應。

3.舉例而言：

(1)喪失修改步驟中應有之里程碑(milestone)。

(2)事先決定關鍵性人員數量。

(3)事先定義系統失敗數量。

(4)事先決定停機時間長度。

5. 預測計畫之生命週期

1.計畫本身應該定義系統或設施在緊急應變模式中及持續運作之時間長度。

2.如果有許多層級存在同一計畫中，則應該對每一層級定義計畫之生命週期。

6. 角色、責任與權力

1.角色、責任與權力須有清楚的定義。

2.相較於平常執行模式，它們在緊急應變模式時可能是不同的。

3.聯絡名單應該包括內部及外部之人員，例如：

(1)組織成員﹔

(2)簽約對象﹔

(3)供應商﹔

(4)廠商﹔

(5)媒體﹔

(6)緊急事件處理部門。

7. 啟動緊急應變模式程序

1.啟動緊急應變模式之步驟必須清楚列出。

8. 實行緊急應變模式步驟

1.執行緊急應變模式步驟必須清楚列出。

9. 實行緊急應變模式時資源規劃

1.相較於平常執行模式，資源使用在緊急應變模式時通常是不同的。

2.舉例而言：不同的資源運用方式包括：

(1)組織成員，計畫表﹔

(2)工具，日常用品，辦公室設備﹔

(3)硬體，軟體，通信設備﹔

(4)資金，採購單﹔

(5)安全設施﹔

(6)備份資料﹔

(7)圖表等等。

10. 回復至平常執行標準

1.在結束緊急應變模式時，應有清楚、明確定義的標準。

2.在眾多標準中如能限制主觀因素所認定數量，將有利於順利回復平常執行模式。

3.回復平常執行標準包括：

(1)完成轉換之測試，並且獲得使用者及管理者認可。

(2)電力供應恢復正常。

11. 回復至平常執行程序

1.結束緊急應變模式步驟必須清楚列出。

12. 恢復資料遺失或損壞處理程序

1.通常引起失敗之情況會導致資料遺失或損毀。

2.在緊急應變時期，資料可能並未完整輸入系統。

3.必須建立重新輸入所有遺失或損毀資料程序，以確保系統資料完整性。

13. 預估計畫之所需費用

1.緊急應變計畫應該預估所需費用，如此在計畫啟動過程組織方能對所需資金有明確之概念。當然，無法預測情形仍可能產生計畫以外的費用。

14. 緊急應變計畫後期

1.準備緊急應變計畫執行後之正式檢討。

2.問題與改進應該在計畫中註明及修正。

3.任何主要之改變均應經過管理階層之核可

[1] Contingency Planning Guide, Minnesota State Government USA,

http://www.admin.state.mn.us/ipo/2000/contbest.html

[2] Guidelines for Contingency Planning, Department of Information Resources, Texas State

Government, Austin, Texas, USA, http://www.dir.state.tx.us/oops/ctgyplan

[3] Contingency Planning, Warren S. Reid, Year/2000 Journal ,

http://www.y2kjournal.com/hot/reid3.htm

[4] The Millennium Problem in Embedded Systems, The Institution of Electrical Engineers,

http://www.iee.org.uk/2000risk/Welcome.html

[5] Contingency Planning Reduce Risks & Avoid Surprises, An over view of a presentation to

SPG’s Year 2000 Conference, Philadelphia Pennsylvania November 17 1998, Lyon, Popanz &

Forester, http://www.lpf.com/year2000/contingency/contingency.html

下列表格針對嵌入式系統提供一系列之功能、服務、關鍵要素、備援方法及緊急應變計畫等範例。資料來源為美國德州州政府出版之Guidebook 2000,About Time : Managing the Y2k Problem in Local Government。