基礎設施定義的問題，透過圖書和論文來找解法和答案更準確安心。 我們找到下列地圖、推薦、景點和餐廳等資訊懶人包

基礎設施即代碼：雲伺服器管理

為了解決基礎設施定義的問題，作者（美）基夫•莫里斯 這樣論述：

本書旨在解釋如何利用“雲時代”基礎設施即代碼的方法來管理IT基礎設施。主要內容包括：組織在採用新一代基礎設施技術時經常掉進的陷阱以及避免這些陷阱 的核心原則和基礎設施即代碼的關鍵實踐；動態基礎設施平臺的性能和服務模型；提供、確認核心基礎設施資源的工具；規定伺服器、構建伺服器範本和更新運行服務器的實踐和模型。 基夫·莫里斯（Kief Morris）是ThoughtWorks歐洲區持續交付和DevOps帶頭人，致力於説明客戶尋找建立和管理基礎設施運維工作的更有效方法；擁有近20年設計、構建和運行自動化IT伺服器基礎設施的經驗。 第 一部分　基礎 第　1章 挑

戰與原則　3 1.1　為什麼採用基礎設施即代碼　3 1.2　什麼是基礎設施即代碼　4 1.3　動態基礎設施的挑戰　5 1.3.1　伺服器蔓延　5 1.3.2　配置漂移　6 1.3.3　雪花伺服器　6 1.3.4　脆弱的基礎設施　7 1.3.5　自動化恐懼症　7 1.3.6　侵蝕　8 1.4　基礎設施即代碼的原則　8 1.4.1　系統能夠輕鬆複製　8 1.4.2　系統是用完可扔的　9 1.4.3　系統是一致的　10 1.4.4　過程是可重複的　10 1.4.5　設計經常變更　10 1.5　實踐　11 1.5.1　使用定義檔　11 1.5.2　自文檔化的系統和流程　11 1.5.3　一切版本化　1

2 1.5.4　持續測試系統和流程　13 1.5.5　小的變更，而不是批量變更　13 1.5.6　讓服務持續可用　13 1.6　反脆弱性：超越“穩健性”　14 1.7　結語　15 1.8　下一步　15 第　2章 動態基礎設施平臺　16 2.1　什麼是動態基礎設施平臺　16 2.2　對動態基礎設施平臺的要求　17 2.2.1　可程式設計　17 2.2.2　按需獲取　19 2.2.3　自服務　19 2.3　平臺提供的基礎設施資源　19 2.3.1　計算資源　20 2.3.2　存儲資源　20 2.3.3　網路資源　22 2.4　動態基礎設施平臺的類型　23 2.4.1　公有IaaS雲　23 2.4.

2　社區IaaS雲　23 2.4.3　私有IaaS雲　23 2.4.4　反模式：手搖雲　24 2.4.5　混合雲服務　24 2.4.6　裸機雲　24 2.5　如何選擇動態基礎設施平臺　25 2.5.1　公有還是私有　25 2.5.2　雲的可攜性　27 2.6　與雲和虛擬化的“機械通感”　29 2.7　結語　30 第3章　基礎設施定義工具　31 3.1　選擇基礎設施即代碼的工具　31 3.1.1　需求：指令碼介面　32 3.1.2　需求：無人值守的命令列工具　32 3.1.3　需求：支持無人值守的執行　33 3.1.4　需求：外部化配置　34 3.2　配置定義檔　36 3.3　使用基礎設施定義工

具　37 3.3.1　用過程化腳本置備基礎設施　38 3.3.2　聲明式定義基礎設施　40 3.3.3　使用基礎設施定義工具　41 3.3.4　配置伺服器　41 3.4　配置註冊表　42 3.4.1　羽量級配置註冊表　42 3.4.2　配置註冊表是CMDB嗎　43 3.4.3　CMDB的審計與修復反模式　44 3.4.4　CMDB的基礎設施即代碼方式　44 3.5　結語　44 第4章　伺服器配置工具　45 4.1　自動化伺服器管理的目標　45 4.2　具有不同的伺服器管理功能的工具　46 4.2.1　創建伺服器的工具　46 4.2.2　配置伺服器的工具　47 4.2.3　打包伺服器範本的工具　

48 4.2.4　在伺服器上運行命令的工具　49 4.2.5　從中央註冊中心獲取配置　50 4.3　伺服器變更管理模型　51 4.3.1　臨時變更管理　51 4.3.2　配置同步　51 4.3.3　不可變的基礎設施　51 4.3.4　容器化服務　52 4.4　容器　52 4.4.1　以容器方式和非容器方式管理Ruby應用程式　53 4.4.2　容器是虛擬機器嗎　54 4.4.3　使用容器而不是虛擬機器　55 4.4.4　運行容器　56 4.4.5　安全和容器　56 4.5　結語　58 第5　基礎服務概述　59 5.1　基礎設施服務和工具的考慮　59 5.1.1　支援外部配置的工具優先　60 5

.1.2　假定基礎設施是動態的工具優先　61 5.1.3　具有雲相容許可的產品優先　61 5.1.4　支援松耦合的產品優先　62 5.2　團隊之間共用服務　62 5.3　監控：告警、指標和日誌　63 5.3.1　告警：出現問題時告訴我　64 5.3.2　指標：收集和分析資料　65 5.3.3　日誌聚合和分析　65 5.4　發現服務　66 5.4.1　伺服器端的服務發現模式　67 5.4.2　用戶端的服務發現模式　67 5.5　分散式進程管理　67 5.5.1　使用伺服器角色編排進程　67 5.5.2　使用容器編排進程　67 5.5.3　調度短期任務　68 5.5.4　容器編排工具　68 5.6

　軟體部署　68 5.6.1　部署流水線軟體　68 5.6.2　打包軟體　69 5.7　結語　70 第二部分　模式 第6章　置備伺服器的模式　73 6.1　伺服器置備　74 6.1.1　伺服器的生命週期　74 6.1.2　伺服器都承載了什麼　77 6.1.3　伺服器上東西的類型　77 6.1.4　伺服器角色　79 6.2　創建伺服器的模式　80 6.2.1　反模式：手動製作伺服器　80 6.2.2　實踐：將伺服器創建參數放在腳本中　81 6.2.3　反模式：熱克隆伺服器　82 6.2.4　模式：伺服器範本　82 6.2.5　反模式：雪花工廠　82 6.3　引導新伺服器的模式　83 6.3.1　

推送引導　83 6.3.2　拉取引導　84 6.3.3　實踐：對每個新伺服器實例進行冒煙測試　84 6.4　結語　85 第7章　管理伺服器範本的模式　86 7.1　供應範本：不能讓別人來做嗎　86 7.2　使用範本置備伺服器　87 7.2.1　創建時置備伺服器　87 7.2.2　在範本中置備　88 7.2.3　平衡範本和創建之間的置備工作　88 7.3　構建伺服器範本的流程　89 7.4　原始鏡像　90 7.4.1　反模式：熱複製伺服器範本　90 7.4.2　基於作業系統安裝鏡像烘焙範本　91 7.4.3　基於供應鏡像烘焙範本　91 7.4.4　基於Unikernel構建範本　92 7.4.5

　在不啟動伺服器的情況下自訂伺服器範本　92 7.5　更新伺服器範本　92 7.5.1　重新烘烤範本　93 7.5.2　烘焙新範本　93 7.5.3　版本控制伺服器範本　93 7.6　構建基於角色的範本　95 7.6.1　模式：分層範本　95 7.6.2　共用範本的基礎腳本　96 7.7　自動化伺服器範本管理　96 7.7.1　在烘焙前自訂伺服器　96 7.7.2　實踐：自動測試伺服器範本　97 7.8　結語　97 第8章　伺服器更新與變更模式　98 8.1　伺服器變更管理模型　99 8.1.1　臨時性變更管理　99 8.1.2　持續配置同步　99 8.1.3　不可變伺服器　99 8.1.4　

容器化伺服器　100 8.2　通用模式和實踐　100 8.2.1　實踐：最小化伺服器範本　101 8.2.2　實踐：當伺服器範本變更時更換伺服器　101 8.2.3　模式：鳳凰伺服器　101 8.3　持續部署的模式與實踐　102 8.3.1　模式：無主要伺服器的配置管理　102 8.3.2　實踐：應用Cron　103 8.3.3　持續同步流　104 8.3.4　未配置領域　104 8.4　不可變伺服器的模式與實踐　106 8.4.1　伺服器鏡像作為製品　106 8.4.2　使用不可變伺服器簡化確認管理工具　106 8.4.3　不可變伺服器流程　107 8.4.4　使用不可變伺服器引導配置　10

8 8.4.5　事務性伺服器更新　109 8.5　管理配置定義的實踐　109 8.5.1　實踐：保持配置定義最小化　109 8.5.2　組織定義　110 8.5.3　實踐：使用測試驅動開發來驅動良好的設計　110 8.6　結語　110 第9章　定義基礎設施的模式　111 9.1　環境　112 9.1.1　反模式：手動製作的基礎設施　112 9.1.2　定義基礎設施棧即代碼　112 9.1.3　反模式：每個環境單獨的定義檔　114 9.1.4　模式：可重用的定義檔　114 9.1.5　實踐：測試並推進棧定義　115 9.1.6　自服務的環境　116 9.2　組織基礎設施　116 9.2.1　反模

式：單體棧　116 9.2.2　遷移基礎設施時避免“直接遷移”　118 9.2.3　將應用程式環境分到不同的棧中　118 9.2.4　管理棧之間的配置參數　119 9.2.5　共用基礎設施元素　120 9.2.6　實踐：應用程式碼和基礎設施代碼一起管理　122 9.2.7　共用定義的方法　123 9.2.8　實踐：基礎設施設計要與變更範圍匹配　124 9.2.9　示例：微服務的基礎設施設計　125 9.3　運行定義工具　128 9.4　結語　128 第三部分　實踐 第　10章 基礎設施的軟體工程實踐　131 10.1　系統品質　132 10.1.1　低品質的系統很難變更　132 10.1.2　

高品質的系統能更容易、更安全地變更　132 10.1.3　基於代碼的基礎設施品質　133 10.1.4　快速回饋　133 10.2　基礎設施管理的版本控制系統　133 10.3　持續集成　134 10.3.1　持續測試分支不是持續集成　134 10.3.2　誰破壞了構建　136 10.3.3　忽略失敗的測試　137 10.3.4　針對基礎設施的持續集成　137 10.4　持續交付　137 10.4.1　集成階段的問題　137 10.4.2　部署流水線和變更流水線　138 10.4.3　持續交付不是持續部署　139 10.5　代碼品質　140 10.5.1　整潔代碼　140 10.5.2　實踐：

管理技術債務　140 10.6　管理重大的基礎設施變更　141 10.7　結語　142 第　11章 測試基礎設施變更　143 11.1　敏捷測試方法　144 11.1.1　自動化測試提供快速回饋　144 11.1.2　有機地構建一個測試套件　145 11.2　構建測試套件：測試金字塔　145 11.2.1　避免失衡的測試套件　146 11.2.2　實踐：盡可能在最低層級進行測試　147 11.2.3　實踐：僅實現需要的層級　148 11.2.4　實踐：經常刪減測試套件　148 11.2.5　實踐：持續評審測試的有效性　148 11.3　實現均衡的測試套件　149 11.3.1　低層級測試　15

0 11.3.2　中間層級測試　151 11.3.3　高層級測試　154 11.3.4　測試運維品質　155 11.4　管理測試代碼　156 11.4.1　實踐：將測試代碼與所測代碼放在一起　156 11.4.2　反模式：反射測試　156 11.4.3　隔離元件進行測試的技巧　157 11.4.4　重構組件以便隔離　158 11.4.5　管理外部依賴　158 11.4.6　測試設置　159 11.5　測試的角色和工作流　161 11.5.1　原則：人們應該為所構建的東西編寫測試　161 11.5.2　編寫測試的習慣　162 11.5.3　原則：每個人都應該能夠使用測試工具　162 11.5.4

　品質分析師的價值　162 11.5.5　測試驅動開發　163 11.6　結語　164 第　12章 基礎設施的變更管理流水線　165 12.1　變更管理流水線的好處　166 12.2　設計流水線的準則　166 12.2.1　確保每個階段的一致性　167 12.2.2　對於每個變更都立即得到回饋　167 12.2.3　在手動階段之前運行自動階段　168 12.2.4　儘早獲得類生產環境　168 12.3　基本流水線設計　169 12.3.1　本地開發階段　169 12.3.2　構建階段　169 12.3.3　發佈配置製品　170 12.3.4　自動化測試階段　171 12.3.5　手動驗證階段　

172 12.3.6　上線　173 12.3.7　流水線的節奏　173 12.4　使用流水線的實踐　174 12.4.1　實踐：證明每個變更都對生產準備就緒　174 12.4.2　實踐：每個變更都始於流水線起點　175 12.4.3　實踐：出現錯誤時停止流水線　175 12.5　擴展流水線到更複雜的系統　175 12.5.1　模式：扇入型流水線　176 12.5.2　實踐：保持較短的流水線　179 12.5.3　實踐：解耦流水線　179 12.5.4　集成模型　180 12.6　處理元件之間依賴的技巧　181 12.6.1　模式：庫依賴　181 12.6.2　模式：自置備的服務實例　183 1

2.6.3　提供預發佈的庫構建　183 12.6.4　為消費者提供服務的測試實例　184 12.6.5　將服務的測試實例用作消費者185 12.7　管理元件間介面的實踐　186 12.7.1　實踐：保證介面的向後相容性　186 12.7.2　實踐：從發佈解耦部署　186 12.7.3　實踐：使用版本相容　187 12.7.4　實踐：提供測試替身　187 12.7.5　實踐：用契約測試來測試提供者　188 12.7.6　實踐：用參考消費者來測試　188 12.7.7　實踐：提供者介面的冒煙測試　188 12.7.8　實踐：運行消費者驅動契約測試　188 12.8　結語　189 第　13章 基礎設

施團隊的工作流　190 13.1　任何可以自動化的都要自動化　190 13.1.1　手動變更　191 13.1.2　臨時的自動化　191 13.1.3　自主的自動化　192 13.1.4　自主的自動化工作流　193 13.2　使用本地沙箱　194 13.2.1　使用本地虛擬化做沙箱　194 13.2.2　具有本地測試的工作流示例　196 13.2.3　使用虛擬化平臺做沙箱　197 13.3　代碼庫組織模式　197 13.3.1　反模式：基於分支的代碼庫　198 13.3.2　模式：每個元件一個主幹　199 13.3.3　模式：單一主幹　199 13.4　工作流的效率　199 13.4.1　加快

變更　199 13.4.2　代碼評審　200 13.4.3　將治理融入工作流　200 13.5　結語　202 第　14章 動態基礎設施的連續性　203 14.1　服務連續性　204 14.1.1　真實可用性　204 14.1.2　用動態伺服器池做恢復　205 14.1.3　為動態基礎設施設計軟體　206 14.1.4　為連續性劃分系統　208 14.2　零停機變更　208 14.2.1　模式：藍綠替換　209 14.2.2　模式：鳳凰替換　209 14.2.3　實踐：縮小替換的範圍　210 14.2.4　模式：金絲雀替換　211 14.2.5　為零停機替換路由流量　212 14.2.6　有數據

的零停機變更　213 14.3　數據連續性　214 14.3.1　冗餘地複製資料　214 14.3.2　重新生成資料　215 14.3.3　委託資料持久化　215 14.3.4　備份到持久存儲　215 14.4　災難恢復　216 14.4.1　持續的災難恢復　217 14.4.2　災備計畫：為災難做計畫　218 14.4.3　實踐：優先重建而不是冷備份　218 14.4.4　通過流水線持續監控　219 14.5　安全　220 14.5.1　自動掩蓋危害　220 14.5.2　以可靠的更新作為防護　221 14.5.3　包的來源　221 14.5.4　自動加固　222 14.5.5　流水線中安全

驗證的自動化　223 14.5.6　變更流水線的漏洞　223 14.5.7　管理雲帳號的安全風險　224 14.6　結語　225 第　15章 基礎設施即代碼的組織要求　226 15.1　演進式架構　226 15.1.1　在實戰中學習　228 15.1.2　從先驅者流水線開始　228 15.2　度量有效性　229 15.2.1　首先對期望的結果達成一致　229 15.2.2　選擇有助於團隊的度量指標　230 15.2.3　跟蹤和改善週期時間　230 15.2.4　使用看板視覺化工作　232 15.2.5　回顧會議及事後分析　233 15.3　組織授權使用者　233 15.3.1　劃分功能模型的陷

阱　233 15.3.2　採取自服務模型　235 15.3.3　承擔全部責任：誰構建，誰運行　235 15.3.4　組織跨職能團隊　236 15.4　持續變更管理的治理　237 15.4.1　提供穩固的構建單元　237 15.4.2　在流水線中證明運維就緒　238 15.4.3　共用運維品質的所有權　238 15.4.4　審查和審計自動化流程　238 15.4.5　優化發現和修復問題的時間　239 15.5　結語：永無止境　239 關於作者　240 關於封面　240

基礎設施定義進入發燒排行的影片

關鍵基礎設施之工業控制系統失誤樹分析

為了解決基礎設施定義的問題，作者許士龍 這樣論述：

關鍵基礎設施為重要社會基礎功能所需之基礎建設，一個國家為了維持民生、經濟與政府等相關公私部門之合作運作而提供之基本設施與服務，而電力供應攸關民生、產業及經濟發展至鉅，近年來國內因核能議題、環保議題及燃煤發電機組退役等影響，在目前電力需求仍維持成長之趨勢下，電力供應仍年年吃緊，政府部門及電力公司均全力執行各相關措施，確保電力穩定供應。電力供應穩定，不僅是民生必需，更攸關國家經濟發展與國家安全。電力系統對於我國重要半導體產業而言，是生產製造的中樞神經。一旦電力系統供電品質異常或發生故障，將會造成生產線的機台跳機，使生產流程中斷，且隨著復電時間的延長，時間與金錢的損失上也就愈來愈大。因此，半導體產

業對於電力系統品質的好壞相當注重。在我國能源產業轉型之際及配合世界環保潮流，台灣電力公司及民營電廠(IPP)對天然氣供應的質與量需求日殷，天然氣發電占比日益提高，而穩定而安全的天然氣供應更是至關重要的議題。本研究以製程安全管理之概念，就天然氣控制系統導入失誤樹(FT)分析，藉由多層次之保護機制，於工業控制系統(ICS)之設備建立防呆機制，讓系統有容錯能力，以因應人為疏忽，強化控制系統安全防護，避免斷氣導致全國大停電事件不再重複發生，確保電力穩定供應，並大幅增進國家經濟發展。

國際戰略與安全形勢評估 2010/2011

為了解決基礎設施定義的問題，作者中國現代國際關系研究院 這樣論述：

書摘︰ 在世界經濟安全風險居高不下，貿易戰和貨幣戰氛圍濃厚的背景下，主要大國紛紛加快調整內外戰略和重組關系，軍事戰略更加重視提升應對多樣化威脅的綜合能力，加上世界政治生態惡化和多種非傳統安全挑戰相互強化上升，所有這些因素使得國際安全形勢更趨復雜嚴峻。主要表現在四個方面︰ 首先，國際核裁軍、核軍控、防擴散形勢復雜。在奧巴馬（台譯︰歐巴馬）政府高舉“無核世界”旗幟的努力推動下，美、俄簽署削減和限制進攻性戰略武器新條約，承諾各減少1／3核彈頭並將總數限制在1550枚以內，美可每年檢查俄核設施18次。隨後，核安全峰會和防擴散條約審議大會相繼召開，決定將分別在法國和韓國繼續舉行核安全峰

會，並開始討論建立中東無核區。美、英、法、俄等國還公布了各自的核武器數量。但隨著美等大國加大對核威懾力的倚重和投入，力推核武現代化，國際核裁軍、核軍控和防擴散進程可能面臨動力衰減的難題。特別是美國舉行了亞臨界核試驗以增強核武器有效性、安全性，未來十年還將耗資1800億美元換代核武庫、完善投送系統、提升小型核武器打擊力�。俄羅斯新增2個裝備“白楊一M”系統的導彈軍團，使全國攜帶該武器戰斗值班單位增至9個。�英、法簽訂聯合核試驗協議，規避經費不足，保持並增強兩國核打擊力。隨著朝核問題形勢的持續緊張和伊朗核問題形勢繼續糾結，核擴散形勢依然嚴峻。日本擬向印度出口核能發電技術和設備，兩國核能合作面臨突破

。美、越民用核能合作談判迅速推進，越被允許保留自行鈾濃縮權利。巴基斯坦局勢動蕩，極端主義勢力擴大，基層秩序缺失，核武器、核燃料安全風險升高，成為新核擴散源的可能性上升。 其次，網絡和太空戰略競逐明顯升溫。盡管全球軍費持續上揚態勢受金融危機影響開始下挫，除美、印外，日、歐、俄實際國防開支都在縮水。但是，各國卻普遍加強提升網絡戰能力和太空技術競爭力，即使壓縮國防開支的國家也在增加這兩個領域的投入。由此，國際網絡實戰化水平明顯提高。美國已經組建網絡司令部，由四星上將、國家安全局局長統領，已開始實際運作，出台了首份網絡作戰能力建設規劃，探討可能在全球範圍內發動先發制人的網絡攻擊，演練“網絡風

暴Ⅲ”攻防戰。總統奧巴馬將數據基礎設施定義為“國家戰略資產”，任命首任“國家網絡安全主管”。�歐盟演練網絡戰以檢驗有關機制的效果。英在未來4年國防經費削減8％的情況下大幅增加對軍情部門網絡戰、電子戰投入。日本成立約5000人的網絡戰部隊專職網絡系統攻防。韓啟動信息保障司令部組建工作，擬于2012年投入實戰。此外，俄、朝和以色列等國也相繼斥巨資籌組網絡軍隊。“維基揭秘事件”則從另外的側面反映了網絡安全挑戰的嚴峻性。太空競爭持續加劇，增加了太空合作和構建太空秩序的緊迫性。美空天飛機X一37B首飛成功，首次發射由12枚超精密GPS衛星組成的衛星星座。俄撥款lo億美元打造“全球導航衛星系統”，並與印度

協議研發小型四輪探月機器人。日耗資20億美元的月球探索計劃穩步推進，2020年前將在月球建立無人太空站。�意大利在預算全面削減的情形下撥款100億美元啟動為期十年的新航天計劃。 …… 全球篇 第一章 金融危機推進世界大變革大調整 一、主要力量加緊戰略調整 二、大國關系分化重組加快 三、國際安全形勢更趨復雜嚴峻 四、亞太格局重組紛亂炙熱 五、中國與世界互動進入更復雜敏感階段 第二章 後危機時期世界經濟在顛簸中艱難復蘇 一、復蘇勢頭強弱不均，發展趨勢參差不齊 二、經濟亂象紛呈，前途荊棘叢生 三、經濟格局變化明顯，多極化進程

上新台階 第三章 國際金融亂象治理任重道遠 一、國際金融形勢︰越來越亂 二、國際金融治理︰更加艱難 三、中國金融態勢︰愈發危險 第四章 國際恐怖勢力調整戰術歐、美反恐面臨新形勢 一、國際恐怖組織拓展新的策源地 二、歐、美本土面臨的恐怖威脅再度增加 三、美國全面收縮反恐戰線，強化本土反恐 第五章 國際核軍控進程高開低走成果虛多實少 一、美國新核戰略高調出台，後繼乏力 二、美、俄新條約虛多實少 三、多邊核軍控取得進展，但後勁不足 第六章 網絡空間國際合作步入關鍵期 地區篇 大國篇

影響關鍵基礎設施持續營運因子之研究-以緊急救援之災害應變中心為例

為了解決基礎設施定義的問題，作者華哲偉 這樣論述：

「關鍵基礎設施(Critical Infrastructure, 簡稱CI)」指的是一個國家為了維持其社會、經濟、衛生及軍事等持續運作所需的基本設施功能、服務或設置，這些功能或服務一旦喪失，將對國家整體造成嚴重影響。而臺灣於2018年修訂的「國家關鍵基礎設施安全防護指導綱要」，在「國家關鍵基礎設施領域分類」 中，把「緊急救援與醫院」列為八大部門中其中一項，其中次領域「緊急應變體系」 中重要設施之一，已明定「災害應變中心」為關鍵基礎設施防護的一環。而美國在關鍵基礎設施的防護策略上，清楚定義以「風險管理」為主要的做法，以釐清所需防護的對象及決定投入資源的優先順序，近來更以「功能持續運作」為目標，

導入企業「持續營運管理」架構以降低營運中斷所造成的衝擊。臺灣位處歐亞大陸板塊與菲律賓海板塊碰撞帶，地震頻繁；同時也飽受颱洪的侵襲，對於關鍵基礎設施的運作造成很大的威脅，其中在緊急應變體系方面，若重要設施受到人為或自然災害而毀損，將使應變緩慢而使災害更為擴大。本研究從關鍵基礎設施定義、範圍及防護架構角度探討「災害應變中心」之功能持續運作的重要性，然後以文獻收集及專家訪談建構持續營運因子，在進行層級分析法（AHP）後，得知權重最高者為「應有的人力」（41.6%），後依序為「關鍵基礎設施的支援」（18.5%）、「必要的設備」（14.8%）、「場所的規劃」（12.7%）、而「依循的程序」（12.3%）

之權重最低，問卷結果可作為日後災害應變中心持續運作做為投入資源參考。