事業單位

而是「出事的時候誰負責、以及要從哪一層開始查」。

網路不通、電話打不進來、機房斷電、代管主機停擺、容器叢集異常、系統服務中斷 —— 這六件事在客戶眼中都是「壞掉了」,但排查路徑完全不同。事業單位的存在,是為了讓每一種故障都有明確的第一責任人與明確的處置文件,而不是讓客戶自己去猜該找誰。

同時,六個事業單位並非彼此獨立運作。跨領域故障是維運中最耗時的一類 —— 網路看起來正常、主機看起來正常、服務卻連不上,問題常常出在兩個領域的交界處。以共用的架構文件、設備清冊與變更紀錄,讓跨領域排查能在同一組事實之上進行。

負責骨幹網路、區域網路與管理網路三個體系,涵蓋對外線路接入、BGP 路由、區間互連、VLAN 規劃、防火牆政策、VPN、網段配置管理、網域與 DNS,以及憑證的簽發與輪替。設備面涵蓋 MikroTik 路由器、Dell EMC 與 D-Link 交換器、Extreme 交換器與 OPNsense 防火牆。

網路維運最難的部分不是把設定打上去,而是知道現在到底是什麼設定、以及當初為什麼要這樣設。網段、VLAN、路由與白名單全部納入單一來源管理,設備組態由自動化工具依該來源產生,人不逐台手打。

管理網路與骨幹、區域網路完全隔離 —— 即使骨幹遭受攻擊,仍可經管理網路對受影響設備進行處置。

負責對外線路接取、專線服務、跨據點互連與企業通訊服務,涵蓋網際網路接取、企業專線、站對站連線、雲端總機、語音與視訊通訊,以及通訊品質的量測與保障。

電信服務的價值在平常幾乎感覺不到,只有在中斷的那幾分鐘才會被注意到。維運重心因此放在兩件事：備援設計(線路、路由與設備各層皆有明確的失效接管方式)與量測(持續量測延遲、丟包與可用率,在客戶察覺之前先處理)。

負責機櫃、電力、冷卻、實體設備、虛擬化平台與儲存設施。虛擬化平台同時採用 VMware vSphere 與 Proxmox VE,依負載特性分工；儲存依用途分級,分別採用 Ceph 分散式儲存、TrueNAS、QNAP 與 Synology,並在儲存網路上依設備類型與消費平台分段隔離。

機房維運最容易被低估的是「資產到底有哪些」。以實體設備編碼為主鍵維護現役資產清冊,並與虛擬化平台上的主機命名一一對應,由代號即可推得機櫃、據點與承載角色。

負責客戶端的主機代管、雲主機、資料庫代管、應用代管與儲存代管。客戶依規模與需求分區承載；客戶的資料庫與儲存集中於代管區域,不在各自環境中自建。

代管服務最核心的承諾是隔離。凡是宣稱「客戶之間看不到彼此」的,都必須實際測過才能寫進服務條款 —— 實測項目包含持授權憑證是否列得出他人的資源名稱、是否讀得到他人的資料；測不過就退回更粗的隔離粒度,而不是把設計上的期望當成事實對客戶承諾。

負責容器叢集、映像倉庫、持續整合與部署管線、可觀測性設施與訊息管線。容器編排採 Kubernetes,映像統一以版本識別碼標記並釘選摘要值,第三方官方映像一律釘選上游版本號與摘要,不使用浮動標籤。

另一項職責是讓「服務有在跑」與「服務真的有在用」這兩件事分得開。快取、佇列、監控這類元件的共同特徵是壞了也不會讓服務停下來,只會安靜地退化。因此驗收標準不是「應用還活著」,而是要看那一端的連線數與流量 —— 沒有產出就是故障,即使沒有錯誤訊息。

負責作業系統基線、主機初始化、備份與還原、資安基線與定期巡檢。作業系統以 Debian 為標準,例外類別在文件中逐項列明並附理由。

例外清單本身就是一種管理手段。規則是：例外必須寫出理由與範圍,而且範圍要寫窄。一旦例外的理由被寫成「這樣比較方便」,清單就會不斷變長,而清單一長,標準本身就失去意義。