案例：醫療軟體的搬遷與運維#

某醫療機構要把舊軟體（電子健康紀錄、藥局與醫師端）搬到新平台。原系統規模不夠，現代化是必然。

規劃階段#

• 業務與技術合作收齊需求、定預算、評估可行性
• 拍板技術棧、收集客戶基底資料以評估擴充性
• SME 共同設計架構、資料流、業務流、工具清單
• 啟動人才招聘以補足新技能

實作階段#

• 專案／產品按敏捷規範流程
• DevOps 建環境與 CI/CD 管線
• 開發者依照需求寫程式、單元測試、合併程式
• SRE 同步配置監控儀表板、告警模板

測試階段#

• QA 執行多種測試
• SRE 補上混沌與效能測試
• 缺陷回到開發者修補

部署階段#

• 測試通過後打包部署
• SRE 做健全性測試
• 業務使用者驗證後正式上線

維運階段：兩個重複出現的痛點#

上線 4 個月後 SRE 與運維陸續陷入手動繞過模式。

問題 1：歷史資料缺失#

• 病患歷史資料在新版未顯示，運維不得不手動把資料載入新資料庫
• 兩個月內反覆繞過約 10 次

問題 2：自動 failover 不完整#

• 部分服務透過屬性中的旗標決定執行於哪個區域，不在負載平衡器掌控之中
• 任何規劃內外的中斷或發布都需要工程師手動切流量
• 易錯且耗時

重複手動繞過會直接拉長 MTTR，最終影響可靠性。

SRE 的解法#

資料缺失的自動化#

• 根因：舊 → 新資料庫遷移時部分資料未複製
• DBA 需要時間規劃增量資料複製
• 在這之前，SRE 寫了一支自動化：偵測到「找不到資料」即回到舊 DB 把資料複製過來、重啟服務
• 數月後正式增量資料完成，SRE 工具仍救過一次「人為誤把資料寫進舊 DB」的事故

自動 failover#

• 根因：部分服務的執行區域由應用層旗標控制，負載平衡器無法管
• SRE 用 Python 寫了一支工具：在負載平衡器搬遷流量時自動觸發、把這些服務也跟著遷移
• 整合進管線，自動執行、無人為錯誤

自動化 toil 的成果不只是省時間，而是 MTTR 下降、SRE 可靠性可量測地上升、客戶體驗無感故障。

教訓#

• 自動化的最佳起點，是團隊正在「重複手動處理」的場景
• 即便是「臨時補救」的自動化，也常能轉化為長期防呆
• 自動化讓 SRE 能把焦點轉向結構性改善，而非每天重複救火