2026 年 3 月，INSIDE 報導了臺安醫院的 AWS 上雲案例 —— 標題是「零衝擊完成遷移」「醫療上雲典範」
聽起來很順利對吧
我是這個專案的技術顧問，這篇不講架構圖，講我記得的那些時刻
第一次碰醫院
我做雲端開發好幾年了，GCP 跟 AWS 都用過，FastAPI + Cloud Run 是日常，技術棧不是問題
但醫院是完全不同的世界，醫療資料有法規限制、資安合規要求比一般企業高一個量級、IT 部門的運作邏輯跟新創完全不同，掛號系統不能停、病歷系統不能停、醫囑系統不能停 —— 你在上面動任何東西，風險都是真的
顧問公司找上我做這個案子的技術執行，我能搞定雲端架構，但醫療場域的規矩，我是第一次碰
傳統 SI 不會這樣做
先講一件事，不然後面的故事沒有脈絡
傳統的系統整合商（SI）做這種案子，標準做法是：派一個 AWS 認證工程師、排 3-6 個月、帶一組人進場，專精一個平台，案子做完換下一個同類型的
我完全相反，一個人，什麼雲都碰，GCP 最熟但 AWS 也要能上，同時手上還有十幾個其他專案在跑
怎麼做到？
我用 AWS Console、CloudFormation、VPC Flow Logs 這些原生工具去建架構、排查問題、驗證連線，該自己動手的地方自己做
但關鍵時刻我會用 AI 加速
比如 VPN 排查到一半，需要快速確認 Fortinet 跟 AWS 的 Phase 2 參數對不對 —— 與其翻三份文件交叉比對，我把設定丟進 Claude，十秒內就有答案
每次踩坑之後，我讓 AI 幫我把排查過程整理成結構化的 SOP，下次碰到直接照著走，這些 SOP 最後也交給了醫院的 IT 團隊
差別在哪？傳統 SI 的知識在人的腦袋裡，離職就沒了，我把每次踩坑的經驗留在系統裡，可以交接、可以複用
四個組織，三種語言
這個專案的複雜度不在技術，在人
- 醫院 IT 團隊：每天要維持掛號、病歷、醫囑系統不能停，他們同意撥時間配合，但日常工作不會等你
- AWS 原廠：提供架構建議和技術支援，這個案子對台北區域的團隊也是重要里程碑
- 遷移工具原廠 RiverMeadow：橫跨歐美亞的跨國團隊，跟我們開會的工程師在美國，講英文，會議排在台灣的晚上
- 我們（顧問團隊）：負責把這三方串起來，讓事情發生
一場會議裡，有人講中文，有人講英文，有人在醫院機房用手機開視訊，有人在美國的家裡，時差、語言、每個人對「做完」的定義都不同
光是讓四方把時間對齊，就能花掉一整週
那條打不通的隧道
專案需要建一條 VPN 隧道，從醫院連到 AWS
聽起來簡單 —— 設定防火牆、打通 IPSec、驗證連線，教科書上一頁就講完的事
但現實是：醫院原本的防火牆設備需要做底層設定的調整，而那台設備同時承載著整間醫院的日常營運流量，原廠的審查流程很嚴謹，來回確認需要時間 —— 畢竟動到這台設備的風險不小
但專案等不了，技術上什麼都準備好了，就是那條隧道打不通
最後團隊決定改用另一家防火牆設備來建 VPN，繞過原本的瓶頸，換了之後幾天就通了
這件事讓我印象很深 —— 有時候技術問題的解法不在技術裡，在於你願不願意換一條路走
深夜兩小時的 debug
有一次，我們排了一場跨國會議，正式開始跑遷移，美國的工程師、醫院的 IT、我們全部上線
遷移工具啟動之後，連線一直不穩，封包會掉，速度忽快忽慢
我們開始排查，看防火牆 log —— 沒東西，看 AWS 的連線分析 —— 流量有到但回不來，看路由表 —— 設定看起來沒問題
我一邊跟會議裡的人討論，一邊自己用 AWS VPC Flow Logs 跟 Reachability Analyzer 交叉比對
排查到中間，我把目前的線索丟進 Claude 問「還有沒有漏掉的方向」—— 它提了一個我沒想到的：設備層的存取控制，這個方向後來是對的
花了快兩個小時，我們差一點就要開 AWS 原廠的 support ticket 了
最後發現原因不在我們一直盯著看的那些設備上，是另一個我們不知道存在的東西，默默把流量擋掉了，不報錯，不留 log，就是丟掉
改了一個設定，ping 馬上通了，兩小時的問題，修好只要 30 秒
排查能力是基本功，但在高壓的跨國會議裡，有個東西幫你快速展開盲區，確實省了不少時間
「怎麼跟老闆證明我做完了？」
有一次會議結束後，大家都離線了，醫院的 IT 窗口留下來，問了美國工程師一個問題：
「我們怎麼證明遷移成功了？我要怎麼跟主管報告說，事情做完了？」
這個問題不在任何技術文件裡，沒有哪個 SOP 會教你怎麼向不懂技術的主管展示雲端遷移的成果
但這才是他真正在意的事 —— 他不只要把機器搬上去，他要能拿著一份東西，走進主管辦公室交代
美國工程師很有經驗，馬上拉出遷移工具的報表畫面 —— 完成百分比、時間軸、可以匯出 PDF
那個瞬間我學到一件事：技術做完不等於交付完成，客戶需要的不只是「東西搬好了」，是一份他能拿去交代的證據
從那之後，每個專案結案我都會先問自己：「客戶要怎麼跟他老闆說這件事做完了？」
幾個月 vs 幾天
回頭看整個專案，真正在做技術設定的時間大概只有幾週，但從啟動到完成，走了好幾個月
中間的時間花在哪裡？都是等待，但每一個等待都有它的理由
醫院的 IT 不是只服務我們這個案子，他們同時要顧掛號系統、病歷系統、每天幾百個使用者的問題，能撥出半天配合測試已經是排擠了其他工作，你不能催，因為他們的日常優先級比你的 POC 高
防火牆的變更要走原廠審查，那台設備扛著全院的網路流量，任何改動都可能影響門診運作，審查流程慢，但那是保護病人的機制，不是官僚
跨國會議要對時區，美國工程師的早上是我們的深夜，醫院 IT 只有白天能開會，三方都有空的時段，一週可能就那一兩個小時
每一個「等」都不是誰在偷懶，是每個組織都有自己的節奏和限制，加在一起就是用月來計算的時間
這是我做這個案子之前不懂的事，以前做軟體，timeline 掌握在自己手上，但在醫療場域，你動的每一步都牽動著真實的營運風險，快不了，也不應該快
AI 在這裡也幫了忙 —— 每場會議結束後，錄音丟進去幾分鐘就有結構化的紀錄：誰說了什麼、決定了什麼、什麼還沒做
跨語言的會議（中英混雜）尤其有用，人工整理一場要一小時，AI 幾分鐘搞定，結案的時候報告也是從這些紀錄裡彙整出來的，省了大概兩天的文書工作
但 AI 沒辦法幫你催人、幫你排會議、幫你讓四個組織的優先級對齊，那個部分還是得靠人
最後的結果
遷移完成後，我們把結案報告整理好交給醫院 —— 遷移前後的對照、驗證結果、系統運行狀態，讓 IT 窗口能直接拿去跟主管報告
IT 主任在結案時說了一句話（INSIDE 報導有引用）：「對第一線醫護與行政人員來說，最好的回饋就是不受影響」
前線醫護從頭到尾沒有感覺到任何異常，掛號、病歷、門診，全部照常運作
結案那天回家，我想的不是架構圖，是之前那個 IT 窗口問「我怎麼跟老闆交代」的畫面
技術我搞定了，但怎麼站在客戶的位置替他想、幫他把成果變成一份他能交出去的東西 —— 這是我從這個案子帶走最重要的收穫