雲端機房建置前中後期 導入維運經驗談

大約在 2010 年 前 後 Gartner Group揭櫫互聯網時代進入所謂的雲端世代，各國政府及企業逐步開始對相關領域進行探討、評估與投資，不論是平台商(IaaS、PasS)、應用系統服務商 (SasS)等等在接下來的十年內如雨後春筍般蓬勃發展，可惜台灣受到高速網路頻寬建置、企業規模、語言隔閡、人才培養及觀念法規等等主客觀因素的限制，整體雲端服務的發展始終偏重在硬體設備生產，企業級軟體發展及相關底層平台服務進步的速度相對落後於國際。

所幸這幾年相關的問題逐一獲得改善，公部門及本土企業逐步開始踏入” 雲海” 中遨遊，挨踢大叔有幸在近幾年參與幾種不同型態的雲端機房建置導入工作，所以將相關跌撞教訓與感想建議進行分享，希望有緣人除了少走冤枉路外，更能使用最適當的配置達到企業系統上雲的終極目標。

讓我們看一下 Gartner 2010 年預測，這一個趨勢真的很有意思，除了懷古還可以驗證前人預言正確性 ( 其實很準確 )

經驗談 1：上雲的目的及其中挑戰

這句話寫在這篇文章的開頭好像有點奇怪，但是這問題絕對是後續所有故事的核心。這些年挨踢大叔支援過的各類雲端化專案固然各有千秋，但多數專案承辦人的答案其實驚人的統一……這是老闆說的 !!這種為了上雲而上雲的情境並不罕見，但做任何事情都應該要先有明確的目的性，有了共同的標的與合宜的策略才能降低失敗機率，更別提白白浪費得來不易的資訊預算了。為了協助組織搞清楚雲端化的階段性目標，挨踢大叔粗略整理幾個常見的上雲策略與可能的疑慮如下：

純主機代管 (Co-Location) 策略

這是大多數單位最常執行的雲端化方式，嘗試大幅利用虛擬化技術將現有及新開發的應用系統建置於外部雲端機房內，減少單位內部空調、電源、消防及實體進出管制的大麻煩。採用這種策略時資訊服務與資料同時都在雲端機房執行，所有的營運管理機制和備份作業也都集中在遠端執行，單位內部維運重點將放在有效維持聯外網路的通訊品質即可，最大的好處是能滿足底層基礎建設與維護壓力，同時可高度滿足人員設備進出管制等等的稽核要求，也是相對最快速且簡易的上雲策略之一。

但 Co-Location 策略若是使用私有雲方式架設相關服務，資訊管理人員固然保有服務與資料存取的實際掌控與調適能力，但整體設備投資成本反而只增不減，這可能與部分企業主的預期不同。反之如果是租用公有雲相關服務，單位只能在建置初期選擇” 可能合乎需求” 的 IaaS 及 PaaS供應商，後續則必須在完全信任供應商提出的各項保證及 SLA 下租用相關服務持續運作，坦白說在這講究零信任的時代趨勢下，完全信任供應商提供的資訊或許不是個最合宜的方式，因此在此架構下如何從管理面、制度面、技術面多管齊下強化資訊系統自我防護強度，反而成為單位資訊人員的另一個大挑戰。

雲端備份

管理過資料備份的人員應該都知道備份的321 原則 (3 代、2 種媒體、1 個異地 )，使用雲端空間進行資料備份無疑完美解決了後兩項的要求，問題要達成這個策略目標也不如想像中的容易，特別是網路頻寬是物理性限制瓶頸，也成為諸多單位雲端備份專案失敗的主因。

要徹底解決這個看似無解的難題，挨踢大叔建議資訊人員還是要先回歸與用戶協商定義合理可行的 RTO 與 RPO 才是正途，再依據優先次序選擇性進行 D2D2C 平台建置及網路擴充規劃，否則再大的網路頻寬都不可能滿足實務需求﹔後續如遠端備份資料的防護性、備份資料空間需求等等議題，也有賴單位資訊人員不斷的協商與爭取預算，否則看似非常堪用的雲端服務反而可能變成一發不可收拾的錢坑。

純雲端服務

所謂的純雲端服務是類似像 Microsoft365、Google Workspace 這類純雲端的應用，單位導入這類的服務除了不可避免的帳號認證同步作業外，的確可以節省許多的平台營運管理 (Even After Service)負擔。由於雲端服務 Service Provider 已經承擔了絕大部分的日常維護工作，資訊人員這時候要考量的重點反而是合規性與資料所有權的問題。合規要求在各行各業都有不同的規範與限制，所以本文不進行討論，對資訊人員來說在資料和服務相依性高度整合狀態下，如何確保資料的自主權和未來的可移植性反而成為最大的挑戰，特別是資料全進了雲服務廠商手上後，如何保有一份地端 ( 或可自我控制 )完整的備份資料，這些議題反而成為整體服務規劃常被忽略但不得不面對的風險。

以最簡單的郵件服務為例，把單位 EmailService 放上雲端的確可以大幅降低提供24X7 郵件存取服務的維運壓力，但除非企業真的可以把往來郵件的管理及備份整個交給用戶自行處理 ( 還是大家其實都這麼玩 ?)，否則上了雲的外部郵件服務根本已經不受到內部管控，這樣的服務方式能符合法規要求或部稽核這一關嗎 ? 萬一發生郵件資訊外洩狀況時是要如何舉證呢 ? 將來政策調整更換供應商或想回到地端時既有歷史郵件要怎麼移轉或保留 ?這些都是經常被人們忽略但遲早會面臨的大問題啊。

由此可知使用純雲端外部服務固然是個好方法，但挨踢大叔建議導入相關服務時最好一併完成配套的資料備份工作，而且備份方式最好與前端服務整個抽離開來，甚至最好能直接下到地端，因為這樣不但能保有必要的異地備份，哪天想換掉相關服務供應商時也不易發生資料無法移轉的窘境，對企業來說才是最聰明和有保障的雲端服務導入方式。

雲端第二 ( 備援 ) 機房

在混合雲架構之下雲端機房除了要能獨立運作之外，還經常要扮演主機房的緊急備援角色，這類的組織目標基本上已經屬於大魔王等級的難度了，相關網路環境與機房建置建議尋求專業的系統整合公司進行設計建議，這類策略推動除了整體硬軟體建置工作外，實務上問題常常出現在不切實際的客戶預期、資料同步時間差和切換程序 SOP 執行能力等非技術性的問題，因此使用這類策略時砸錢事小 ( 有錢當然可以小小任性 )，建立業務與資訊單位的人員共識才是最困難的挑戰。

因此挨踢大叔良心建議資訊單位應該透過建置小應用系統方式摸清楚雙機房實務上的限制，估算出整個基礎建設能提供的系統服務 (Computing Power、Data SyncPerformance and Reliability…) 容量上限及系統切換所需合理服務中斷時間，漸進式調整雙機房運作所需的內外部服務架構 ( 如網路及防護設備、外部 DNS、資料同步機制……)，待一切基礎環境就緒後再和業務端商談合理可執行的服務水準(Service Level) 後逐步進行移轉，並透過不斷的演練讓相關支援人員熟悉雙機房系統切換程序及驗證方式，否則這類的上雲策略除了會是個大錢坑外，更會成為資訊人員的揮之不去的夢靨。

經驗談 2：雲端機房連線適用情境

除了單純使用純雲端服務的選擇外，雲地機房間的網路連線品質直接決定了所有資訊服務的成敗，雙機房間的網路通訊除了單純的頻寬選擇之外，網通線路的穩定性及延遲決定了後端服務與資料同步的可執行性，造成的影響直接反應到前端終端用戶對資訊服務的有效性與滿意度，因此對外網通連線的設計也成為企業上雲的重要議題。眾所周知台灣網路連線成本及可選擇性始終是大家心中的痛，因此建置經濟且合乎實務需求的對外網路，始終是資訊人員必須面對的選擇挨踢大叔整理了幾種常見的連線方式的適用情境如下 :

挨踢大叔實戰談 終端服務和後端資料處理切割成兩個獨立區域

由於頻寬租用是不可避免的花費，建議資訊人員可以把終端服務和後端資料處理切割成兩個獨立區域分別處理，大部分可控的使用者終端服務可優先採用便宜且可擴充的一般性網路提供服務，輔以多重線路分離不同負載的方式降低網路塞的機率，提高終端用戶的服務滿意度，後端資料處理則強烈建議採用資安及可靠度高的專用線路建置資訊通道，降低因頻寬問題產生的服務不確定性風險，達成資訊系統上雲強化資訊服務韌性的核心目標。

經驗談 3：機房網域設計與資安管理

經過多年的網際網路攻防歷練，相信具有規模的機關與企業都已經把內外服務進行合理的規劃，透過防火牆不同網段的隔離將內外服務進行隔離，並透過受限制的資料分享方式同時滿足外部服務與內部運作運用。資安防護需求更高的單位甚至會將內外資料做實體性隔離，除了在同服務區域內將前端應用 ( 如 Web) 與後端資料( 如 Database) 再做隔離外，內外服務也謹守只能 Inside Out 不能 Outside In 的資料分享原則進行系統設計配置，外部系統所需要的資料會由內部系統經過篩選 ( 遮罩 ) 後再由內而外傳送出去，外部資料向內傳遞的需求則透過內部專屬的資料閘道服務將所需資料取回，透過層層管控與節制降低整體系統營運風險，並在最大程度上降低資安事件發生時的資料外洩風險與損失。

上述的機房 DMZ 切割方式是大家相對熟悉的架設習慣，用 DMZ Zoom to Zoom方式設定防火牆也可以降低管理及設備的負載，這看似一切美好的管理方式能直接移植到雲端環境上嗎 ? 如果是 CoLocation 策略的話當然沒問題，但若採用公有雲服務的話情況可能就不一樣了。

要知道在一般的公有雲服務區域內，租用的防火牆可能只會區隔出一個相對大範圍的 VLAN 網段，所有租用的 VM 其實都躺平成一片，甚至初始狀態從 Internet都可能自由進出 ( 總要先連進去才能開始設定合法通道 )，加上公有雲實體 ServerLocation 可能依據維運要求隨時更換，所以租用的雲端服務載台若發生對外連線設定疏漏，所有的 VM 極可能會完全暴險於外部網路攻擊之下，因此機房管理人員務必要戒慎恐懼小心行事。

一般地端網段 DMZ 切割示意

公有 ( 混合 ) 雲初始網段示意圖

由於公有雲環境下單純用防火牆 Rule 隔出防禦縱深的美好日子已經不再，利用實體隔離設計強化資安防護的選項也幾乎無法達成，資訊人員在地端機房許多緩解風險的手段勢必被迫進行調整，既然 IT 雲端平台就像 OT 資安要求一樣無法完成實際的實體隔離，但建議資訊人員在建置雲端系統時要用盡所有可行的管理和軟體手段做到最大程度虛擬隔離，這才能降低雲端機房的營運風險。相關可能的作業事項其實多如牛毛，挨踢大叔約略整理幾個常見的重要事項如下：

降低雲端機房的營運風險要項

1. 盤點所有資訊服務所需的軟體版本 ( 含相依性軟體 ) 及連線通訊需求，確認內外服務是否存在 overlap 重疊狀態。如果可能的話常見的後端資料提供者 ( 如 DBMS)務必先嘗試進行改變 Access Port and/orIP 存取限制的相關設定，增加突入雲端環境防護有心人士的存取複雜度，除增加預警偵測機率外也能爭取緊急應變反應時間。
2. 所有基礎系統平台及服務啟動帳號嚴格執行最小化安裝與授權原則，並第一時間完成單位內規範之平台平台資安強化程序 (Security Harden Procedure, 如GCB…)，所有跨 Server 連線通道均以作業系統防火牆採從無到有策略逐一設定並妥善管制，避免發生管理性疏漏導致意外狀況。
3. 強化底層平台帳號管制措施，所有高權限帳號強烈建議導入 MFA 多因子認證機制，完成現階段相對最安全可行的帳號密碼防護環境。
4.  所有遠端管理連線均須納入單位授權 IP限制管理，避免直接開放使用 Internet 進行管理性連線 ( 建議改用單位 VPN 再繞至雲端機房 )。
5. 所有應用系統軟體均採最小化安裝原則進行，不需要的元件絕對禁止安裝。這是件知易行難的大工程，特別是應用系統開發團隊常習慣性使用大鍋炒方式安裝輔助程式庫 (Software Library)，但是為了強化應用系統資安強度還是不得不為。
6. 嚴格要求系統維運紀律，嚴禁維運團隊於平台儲存未經加密的連線檔案資訊( 如 web.config)，或於雲端平台違反規範進行外部資料存取 ( 常見如用 Webmail 方式收發郵件 )，杜絕人為失誤導致的資安事件。挨踢大叔老生常談 特別注意標準程序執行的次序性問題

挨踢大叔老生常談 特別注意標準程序執行的次序性問題

上述的注意事項似乎都是老生常談，但挨踢大叔多年觀察下來能確實執行的單位著實不多，技術面能解決的問題其實都相對容易 ( 了不起花錢就好 )，資訊人員對應用系統的孰悉程度及作業紀律才是難以掌控的盲點，換言之企業如果打算將既有系統上雲，良心建議資訊單位務必先確實檢討地端作業是否能真實符合 ISMS 制度的各項基本規範，而且特別注意標準程序執行的次序性問題 ( 例如先給最小權限安裝還是先用 root 安裝再縮小權限 )，先在相對可控的地端調適出最適合應用系統屬性的各項作業組合及維運 SOP 之後，再考慮應用系統是否適合上雲或該選擇哪類的上雲策略，否則未經仔細評估的匆促決策小則事倍功半浪費預算，大則造成資料洩漏的資安事件，大家務必要謹慎行事。

另外對於有成熟機房營運管理制度及實務經驗 ( 空有制度沒用 ) 的單位或企業來說，在經過多年調教之下各項注意事項都已經培養成組織慣例所以問題不大，那上雲的過程是不是就直接仿造地端的現有架構一對一對應上去就好呢 ?

前端服務的應用系統直接在雲端平台重新直接佈署一次，後端的資料源直接 Backup /Restore上去，甚至乾脆直接 Clone 一套完整的 VM 上雲後改改 IP 和連線設定就好 ( 很多雲端服務供應商都建議這種快速移植方式 )，這樣的解決方案簡直完美不是嗎 ? 挨踢大叔綜合各家的經驗得到的答案還真不是呢。

要知道這些年來受到各項資安稽核要求，眾多單位會使用 LDAP 服務進行設備管理及服務權限設定等等工作，而且這個 LDAP 服務還極可能是不分端用戶及機房管理用途單的單一服務 ( 挨踢大叔堅決反對這種設計方式 )，一對一直接 Clone 出來的各項服務平台 VM 要能運作，等同變相要求同時移植同一套 LDAP 上雲才行，這結果直接把資訊系統最核心的資安管控服務直接放到 Internet 讓有心人士練功，Try and error 過程甚至可能造成大範圍的密碼錯誤過多鎖定帳號事件，當然這類攻擊嘗試可以在累積一定經驗後進行阻隔，但資訊人員花費大量精神去處理這類工作實在太沒效益了。

另一方面地端的平台往往經過長時期的運作，定期更新的過程多少會留下許多不必要的軟體元件或設定在平台環境之內，無差別的複製貼上等於是把歷史遺留的風險直接放上 Internet 讓人瞻仰，因此在能力許可的狀況下，良心建議大家應該優先使用從零開始的安裝策略建置雲端服務平台，雲地兩端最好使用完全不同的權控帳號與服務，避免前人不慎遺留下的小失誤引發未來的大麻煩啊。

資訊系統上雲是一個非常值得討論的策略性議題，當資料離開自己實體控制時除了一般性的資安防護之外，其他平時可能被忽略的管理性的問題反而需要特別重視，要知道資安攻擊手法固然眾多，但只要適當地導入各項存取防護及完善資料保護機制，已知且常見的各項外部攻擊手法都可以得到一定程度的舒緩。但挨踢大叔必須提醒大家資訊系統最可怕的風險並不在外部。

反而是來自於內部的人為錯誤操作，例如 2021 年底行政院資安處 ( 現數位部資安署 ) 指出政府機關近年三級事件通報中以人為疏失為事件發生的主因，足見任何管理制度或資訊技術都擋不住這個必然會產生的風險，所以如何增加衝擊緩衝區域和降低人為操作發生錯誤的機率，反而在企業上雲的過程中應被更加重視與探討。

雲地間增加獨立的 Landing Zone，強化營運韌性

為了達成增加防禦縱深和強化防呆設計管理系目標，國外許多單位提出了一套在雲地間增加獨立的 Landing Zone 的實體規劃方式，整體設計思維重點在於：
1. 雲地兩端增加一個作業的中介 Buffer Area，避免雙機房直接透通相互干擾影響的風險。

2. Landing Zone in/out 任何一個機房的日常資訊作業最好都使用自動化機制完成，降低人為失誤機率。

3. Landing Zone 的 Buffer Area 相關作業服務帳號可雲地兩端完全隔離，徹底阻斷帳號密碼一條鞭的資安風險。

4. 資料層級的作業緩衝區增加了資料封裝確認、內容過濾轉置、權限管控、存取稽核等等不同程度的工作彈性，適當的設計可以強化核心資料的防護能量。

5. 應用系統層級的 Landing Zone 設計可以增加應用系統資源使用及作業佈署的擴展性，將新創及正式服務進行一定程度的隔離，強化整體服務的可靠度。

Landing Zone 的設計觀念在各大雲端服務供應商均有詳細的說明，歡迎有興趣的人自行進行查閱相關說明，但挨踢大叔深知此一觀念在國內也許並不普遍，甚至有人會覺得太過麻煩甚至浪費金錢，實務上任何企業都不能無視資安事件層出不窮的事實，人性的弱點又是根本無法克服的問題，所以挨踢大叔仍然真心推薦大家可參考相關設計精神，重新檢視單位現有的雲地雙向甚至純地端的資訊作業準則與程序，或多或少在日常作業中導入自動化機制 ( 如自動化建構與佈署 ) 降低人為錯誤機率，並在檢視企業資料流及跨域傳遞的過程發現是否有強化安全防護及服務韌性的契機，透過不斷漸進式的調整提升企業整體資訊系統維運的成熟度，這樣子有目標性與階段性的精進作業遠比被法規追著執行來的有意義，大家真的可以參考一下。

另外一定有些長官們會覺得既然要花錢上雲，系統硬軟體當然要用導入最熱門的 Docker 化甚至Microservices 化才有績效，在此挨踢大叔提醒大家技術本身沒有優劣之分，真正的焦點在於雲端機房的管理運作方式和傳統地端存在著一定程度的差異 ( 即使純 Co-Location)，在整體管理制度和人員水準還沒提升到一個相對成熟的境界時為了上雲而上雲，這種冒進的行為挨踢真的只是剛剛好而已，所以務必要慎之戒之。

經驗談 4：平台容量規劃

早在 .Com 泡沫化後的數年間，ServerConsolidation 成為資訊業界的重要事項，大家努力地進行服務整併與調適工作，一方面精準的進行新設備採購，另一方面降低不必要的既有設備維運投資，平台容量的預估容量規劃 (CapacityPlanning) 成為資訊系統開發的重要工作之一，但隨著 X86 平台與虛擬化技術的大幅躍進，硬體運算能量跳躍式成長及虛擬化動態調整作業彈性成為所有資訊人員的救命仙丹，傳統的容量規劃慢慢地淪為一種純喊價過程 ( 特別是針對儲存空間 )，年輕的系統開發人員習慣性認為系統平台存在取之不盡的可用資源，相對沒經驗的系統管理人員也認為反正出問題再動態調整就好。

如此的氛圍之下資訊平台的資源運用方式往往產生觀念性偏差，但這個狀況在面臨大數據和雲端平台時明顯就需要進行修正，畢竟外部彈性資源服務都是用金錢疊出來服務，指數型成長的數據資料也需要使用合宜資源與聰明的方式拆分處理，所以即使雲端平台已具備動態資源調整的強項，在有限經費的前提下適度的系統平台容量規劃和租用策略又再一次成為資訊人員必須面對的課題。

挨踢大叔在從實體主機轉化為 x86 虛擬化的過程中一直有種” 見山不是山”的感覺，在隔了一層霧的虛擬化平台運行系統經常會發生一些” 靈異事件” ，除了系統實際資源可能被系管人員無預警”動態限制” 外，許多單位的虛擬化平台資源都存在 resource over commit 的狀況，或是某些資源配置過度集中 ( 特別是 Disk I/O)導致不同 VM 相互干擾，平時系統負載不高時大家相安無事，但到了月底月初結算作業尖峰期大家效能一起崩潰的窘境，這類問題的根源其實還是源自不當的系統容量規劃和資源配置，未被優化的不合宜資源配置也許是受限於實體限制的不得已選擇，那把系統移上號稱有無限資源的公有雲端是不是一種可能的救贖呢 ?

善用公有雲服務動態調整
週期性檢視配置調整

上述問題的答案其實很明確……有錢就好辦事。採用 Co-Location 策略的單位仍然存在設備容量上限的狀況，所以問題依然無解；改用公有雲平台策略的單位會發現採購選項上有各式各樣的排列組合，從最基本的資源專屬或共用模式開始，下含各項資源的實際需求配置、磁碟的種類等等，其複雜程度更讓人眼花撩亂，那在這眾多的選項中資訊人員該怎麼抉擇呢 ? 當然各單位上雲的目的性與可用經費並不一樣，不管是由儉入奢還是由奢返儉都是可行的執行方式，在此挨踢大叔建議大家不妨用以下方式思考:

1. 除非是新建的全新資訊系統，請先在地端建立起現有系統長期資源使用狀況監控與紀錄機制，蒐集一段時期 ( 最好包含作業尖峰期 ) 的全系統前後台系統資源負載資訊。若發現部分平台資源仍有餘裕，建議在地端下修可用運算資源至合宜水準，待系統運作趨於平穩後相關設定可做為未來移植上雲的初始基準值(baseline)。
2.  分析地端不同角色伺服器資源使用的屬性，確認其為 CPU bound 或 是 I/O Bound 型的服務，I/O Bound 部分還要再細分為 Read only (File Sharing) 或Read/Write 交易型 (DBMS) 的作業，若為資料庫伺服器就要再進一步與應用系統為維運團隊了解是否存在大量寫入交易作業情境 ( 負載尖峰 )，作為後續資源採購的細部 IOPS 規劃基本需求。
3.  確認不同伺服器屬於應用系統專用 (WebAP) 還是可能跨系統共用 (File /DBMS)，並確認未來跨系統資源整併共享的策略。
4. 公有雲端資源採購時建議可分為前後台兩種策略：

策略 1：

前台應用的 AP 伺服器建議可先用共用模式採購，為應付新環境水土不服的狀況，虛擬主機的 CPU、 Memory 資源在上線初期可以配置比地端稍高一些，待系統整體運作穩定後逐步調整。

策略 2：

後台的 Data Tier 伺服器強烈建議使用專屬模式採購，交易型虛擬主機資源建議採一次到位方式建置，確保後台資料處理的作業效能。另外應用系統移入雲端初期必然存在後端服務資源過剩現象，單純的檔案分享可以採漸進式持續增購空間方式擴充，但資料庫服務的設定與調適通常需要專業人員參與，不當的資源調整可能造成平台與軟體設定匹配性問題，因此建議此類角色服務的資源不宜任意調整，應以維持資訊服務穩定性為最高考量。

5. 公有雲虛擬化主機硬碟型態的採購選擇往往是最令人困惑的環節，從 SSD 等級到 Nearline SAS(SATA) 等級的選項應有盡有，賣家立場當然建議直上 SSD 保平安，但挨踢大叔近 30 年應用系統導入經驗顯示除了特定的用途 ( 如大量 OLTP 交易 )外，靠 SSD 等級 Storage 才能運作的系統在本質上多少存在設計上的缺陷，而且系統實際負載往往也達不到最初的假設 ( 從Baseline 資訊可知 )，當然如果老闆錢花不完就不用糾結，否則建議可從應用系統效能問題著手調適，或者嘗試用較大的 Memory Space 去換 Disk I/O 效果可能更佳，一般性原則建議後臺共用 OLTP交易系統當然優先選擇較高等級的存取服務，前端應用系統或單純的檔案分享先採用較低速的磁碟型態即可，後再監控應用系統的實際反應效能後進行調整。
6. 公有雲下所有的資源都是用金錢換來的，日積月累聚沙成塔後相關花費可能令人意外，此時請務必善用公有雲服務動態調整資源的優勢，週期性檢視資源使用量後進行配置調整，才能將有限經費做到有效運用。另外公有雲服務商提供的資源增減建議只能約略參考，因為相關建議是依據前一個計算週期負載推測出來的平均值，除了瞬間尖峰量可能被總時長淡化掉，資源服務商也不可能知道未來何時會發生應用系統的負載尖峰期，因此資源調整務必要考量實體業務面的作業需求，否則可能發生業務尖峰期資源不足或淡季資源閒置，資訊單位的服務水準穩定性和經費運用有效性都會遭受長官質疑啊。

經驗談 5：雲端機房監控大哉問

任何一個具規模的地端機房應該都自行或委外建置了NOC (Network Operation Center) 和 SOC (Security Operation Center) 服務，機房管理單位會服務供應商會透過各類硬軟體及網路和防護設備，對機房所有的資源運作、網路傳輸、系統日誌與作業紀錄、服務中斷異常等等事件進行資料儲存、監測、分析、示警甚至與第一時間阻斷應用，在地端機房都已經行之有年的成熟技術，移上雲端哪裡會有什麼問題對吧 ? 錯了！問題大著呢。

上雲後監控面向的心得

其實任何一個公有雲供應商都會提供基本的監控服務選項供客戶選用，相關服務項目就算不如地端豐富，該有的東西大致上也都八九不離十，但挨踢大叔在參與系統上雲的過程中至少發現以下的狀況 :

1. 理論上雲端服務可能遭受的攻擊風險比地端來的更高，而且由於底層平台並非是個可控的環境，單位現有的NOC/SOC工具或委外服務供應商是否能提供同質性服務，將會平台導入時面臨的大問題。
2. 公有雲雲端平台資安風險需要透過底層平台服務商與單位 SOC( 工具 ) 廠商協同進行監控，受限於不同廠商服務的差異性和變異性，相關系統整合的複雜度與時效性遠高一般認知，相關作業時間差也可能產生另一種風險有待克服。
3. 雲端服務供應商提供的監控資料細膩程度各有特色，唯一不變的是資料的完整度與保存時間多寡都請先付費，要知道各單位在不同規範下必須保有一定時間區間的佐證紀錄備查，為了 N 年用不了幾次的紀錄花錢買儲存空間是個合理的選擇嗎 ?
4. 雲端服務供應商存放的系統紀錄內容與地端不同，為了有效解讀龐大的資料必須另外動用額外資源開發一套整理與判讀的作業程序，相關產出也可能與大家熟悉地端樣貌無法一致，這可能會造成內部管理面上的額外負擔。
5. 資料與資訊的差異在於是否能經過整理與解釋，如果散落滿地無法整合的資料除了應付稽核其實沒有人何實質意義，如果雲地兩端 NOC/SOC 的資料無法彙整，在使用混合雲架構下的資料 ( 訊 ) 斷點是否可能造成後續的問題頗值得深思。

挨踢大叔實戰談 SOC 處理準則

上述的狀況挨踢大叔也在雲裡霧裡摸索著較佳解，但在考量風險與資訊整合的目標下，建議可以嘗試把高急迫性的 SOC 和一般性的 NOC 作業分別處理，概念性的作業準則為 :

1. 與即時資安防護相關的 SOC 偵測與阻絕功能優先考慮使用雲端平台廠商提供的服務，可行的話甚至可以整合多家雲端服務 ( 如 DNS、WAF、IPS/IDS…) 擴大防禦縱深，此時跨供應商整合服務的工作可能有些複雜，資訊單位務必在前期投入足夠的能量進行可行性評估與進行完整測試，建立起一套聯盟式的雲端機房資安防護網。
2. 所有 SOC 相關的 Log 務必要傳回單位既有 SOC 平台進行記錄與分析，並嘗試從大量雲地記錄中識別資訊事件 co-relationship 相關的 Rule 與 Pattern，作為發現異常語調教雲地資安防護手段的基礎。
3. 在技術可行的狀況下 NOC 相關服務建議優先納入地端平台集中管控，提供一致性資訊便於總覽資訊系統全面性概況。
4. 法規稽核所需的系統 Log 一律傳回地端平台存放，並產出合規之各式管理性報表，同時滿足上級機關檢視需求、減輕日常維運負擔及降低設備租用成本之效。
5. 部分專用細部效能監控分析工具建議優先在地端實施效能調教，待整體作業效能達一定水準後再移入雲端平台運行，若有必要時可在條件許可下將偵測工具佈署於雲端環境內，儘量避在跨域情境下進行應用系統層級的效能調適作業。
6. 嘗試評估導入可適用於跨域環境的系統偵錯服務，降低系統操作人員工作負擔。

經驗談 6：資料同步作業設計

採用混合雲或雲端備份策略必然存在跨機房資料傳輸甚至近即時同步的作業需求，但在可用頻寬及工作時間似乎永遠無法滿足資料成長速率狀況下，看似單純的事情遠比想像中來的艱難許多，針對這種狀況系統整合廠商提供了各式各樣的多級緩存、去冗壓縮甚至 Storage Block Level同步等等眾多方式來協助企業完成這項艱鉅的任務，挨踢大叔彙整眾家成功與失敗經驗分享建議如下 :

1. 想要在有限頻寬及作業時間完成資料傳遞，最核心的問題還在於業主要務實的確認資料成長量並定義出合理的工作要求，將資料依據重要性分出優先次序與合理作業週期，甚至在面臨作業異常狀況下定義某些重置處理的條件，否則需求持續累積總有卡關的一天。
2. 資料同步同時涵蓋平台工具面與應用系統技術性考量，跨域傳輸必然產生的時間延遲通常需透過應用系統團隊進行
   一定幅度調整，再搭配機房網通環境調整及硬軟體技術方可達成目標，故相關作業需求與實際執行設計需要軟體開發與機房維運人員共同協作方可成功，缺一不可。實務上由應用系統開發團隊主導的資料同步作業成功機率，往往遠大於單純系統管理人員獨自靠現有技術或想像實施的最終成果，因此硬軟雙方的相互協調與配合，絕對是資料同步成果與否的關鍵因素。
3.  LAN 和 WAN 先天就存在不同的可靠度和穩定度，就算跨域機房採用的是最高品質的專有固網也是一樣，資料同步工作絕對不要認為可以將應用系統前後端配置於不同機房方便兩邊直接進行交易存取，否則就算連線通道一切暢通無阻，不可避免的遠端傳輸延遲勢必拖慢資料庫交易執行速率，最終可能拖垮整個系統的穩定性。
4. 依據資料 At Most Once 或 At Least Once 的屬性定義傳輸需求的重要程度，並選用不同的網路連接方式進行後續作業，At Most Once 的交易型資料請務必使用高穩定度的專用連線傳輸，檔案類型或可具備 At Least Once 容錯特性的資料，可以使用較便宜但大頻寬的專線進行傳輸，有效的分流處理才可能保障作業的可執行性。
5. 使用的資料同步作業工具建議選用可視化及可中斷重啟的方式實施作業，簡易但不知作業進度或無法留下完整紀錄的工具建議不要選用，避免意外中斷時無法獲知實際情況。
6. 資料庫類型同步方式常有底層平台系統層級 ( 如 Replication) 和應用系統控制兩種方式可實施，考慮到雲地兩端必然的頻寬限制與傳輸延遲穩定性問題，強烈建議優先選用應用系統以佇列 (Queue) 方式實施，最大程度確保兩端機房資料的一致性與同步的穩定性。
7. 大量小檔案傳遞受限於磁碟系統物理性限制無法加速，建議宜從應用系統面用時間軸或其他角度進行分割減少單位時間內所需傳遞的資料量，若受應用系統限制無法有效進行分離設計，建議優先採用 Storage Block Level 硬體式方式克服不斷增加的資料傳輸需求。
8. 若雲地雙機房應用系統相關資料需來回傳遞，資料結構、存放設計與使用同步技術務必避免發生迴圈狀態。
9. 雲地雙機房縱使同時存在相同服務，考量跨域整合的眾多不穩定因素，建議考量實際作業需求優先採用 Active–Standby 模式提供對外服務，降低整體服務維運複雜度。

經驗談 7：哪些選配可以考慮

公有雲服務商都會提供一些非常有用的網通服務，建議大家可以先了解相關特性後再考慮是否納入混合雲甚至 Co-Location架構中提供優質服務，強化整體資訊系統的安全性及穩定性 :

外網分散式阻斷服務 DDoS 防護

DDoS 攻擊本身對系統資料也許無害，但惡作劇型態的癱瘓服務真的非常令人無奈，而且最怕的狀況是 DDoS 的發生只是為了掩飾另一個同時進行的攻擊事件，所以殲敵於境外才是最高明的防護手段。向雲端服務廠商租用 DDoS 防護可以在 ISP端直接阻隔大部分的惡意攻擊事件，如果有對外服務的企業絕對值得進行投資。

Server Load Balance (SLB)

天底下不存在永遠不會出錯的硬軟體設備或應用系統程式，前端多機負載平衡加後端叢集容錯，再配合上底層雙設備互為備援的架構已經是全球的共識了。很多單位都已經導入了提供前端 ServerLoad Balance 能力的 Layer 4~7 Content Switch 提供在地應用系統服務，相關負載分流及錯誤檢查機制等等也都有一定程度的優化，所以在雲端導入類似服務應該不是一件難事才對。實務上這個服務上了公有雲可能沒有想像中那麼單純，要知道服務供應商上為了提供跨設備、跨機房甚至跨國的平台容錯切換能力，許多的設定不如地端設備存在這麼多的彈性，而且地端常用的使用IP Address 做綁定和分流的設定方式上了雲端很可能不適用，甚至 Web 應用系統經常性需要的 Application Session 綁定 工 作 (Session Persistence / SessionSticky) 也不一定能滿足。因此在選擇相關服務前務必要先了解供應商的系統服務內容，並檢視相關差異是否能透過修改應用系統來撫平問題，這才可能在雲端平台提供相關容錯能量。

Content Delivery Network (CDN)

內容傳遞網路 (CDN) 服務非常適合用於大量靜態網頁及檔案資料下載的應用場景，特別是企業官網這類異動頻率不高的對外服務非常適合嘗試使用此類的服務。導入 CDN 通常不需要應用系統進行過多修改，但企業在租用服務後務必要定期檢視 Hit Rate 數據是否達到預期，並確認服務不如預期時的後續改善策略，若真的無法調整可考慮放棄租用相關服務，將經費透入其他維運工作。

Opportunities are reserved for those who are ready

資訊系統上雲與否在業界紛紛擾擾了十年，每個單位都有自己的主客觀限制和因應策略，部分單位和企業還要遵守政府相關法規來定義後續發展腳步，基本上不存在統一適用的標準答案。不論這些年眾多單位導入相關服務的成效，挨踢大叔真心建議所有資訊單位應該把握這個契機，從制度面、作業面、需求面、服務面重新盤點所有資訊應用，並檢討現行作業制度與國際通用標準間的差異，逐步把資訊服務的開發維運推向高度資安化、自動化及 Cloud Ready 的境界。這個強身健體的過程也許對大家是個挑戰，但絕對是強化單位資訊系統服務彈性和韌性的良性演進，至於到底要不要上雲其實根本不是問題，重點是大家都已經準備好啦。