Architecture Journal
企業架構情境故事：好味餐飲從尖峰事故開始的數位轉型
案例說明
這是一個虛構案例。所有公司名稱、人物、數字與事故皆為虛構，不代表任何真實企業。
這篇文章只定義問題背景，不預設微服務、事件驅動或其他技術解法。後續 EA 架構系列會以本文的公司輪廓、目標、角色、現況與限制作為共同前提；若案例內容變更，應同步更新案例版本與基線日期。
| 項目 | 內容 |
|---|---|
| 案例版本 | 0.4 |
| 基線日期 | 2026-08-28 |
| 公司 | 好味餐飲集團，以下簡稱「好味」 |
故事從一個午餐尖峰開始
好味從一家街邊餐廳起家，十二年內發展成擁有三個品牌、42 家門市的餐飲集團。 早期那套只負責門市結帳與日結的系統，也一路跟著公司長大。工程團隊陸續把會員、 優惠券、線上點餐、庫存、廚房出單、外送串接與營運報表加進去。大家仍叫它 「POS 系統」，實際上它早已是整家公司最重要的交易核心。
2026 年 5 月 8 日星期五，好味推出會員日活動。上午 11:30，行銷部向 8 萬名會員推送「午餐第二件半價」優惠。四分鐘後，建立訂單、計算優惠、查詢狀態等訂單相關請求一度升到平日午餐尖峰的七倍。
當時有三項工作同時使用正式資料庫。優惠模組會在每次結帳時讀寫優惠券使用次數； 11:30 排程的庫存批次正在更新各門市的可售數量；營運人員則開啟活動報表，直接查詢 即時銷售資料。批次更新與報表查詢使資料庫回應變慢，OneFood 內等待查詢結果的交易 持續占用資料庫連線。幾分鐘後，OneFood 的連線池耗盡，線上點餐與門市 POS 開始逾時。
現行結帳流程會依序建立待付款訂單、呼叫付款服務商、寫回付款結果，再建立廚房單。 這些步驟會分別留下紀錄，付款服務商核准交易後，OneFood 仍須更新後續狀態。 這次事故中，有些請求在付款核准後、狀態寫回前逾時；有些則已建立廚房單，卻沒有 把結帳結果回傳給顧客。顧客再次送出結帳請求時，每次重送都會取得新的請求編號， 客服與門市無法立即判斷兩次請求是否來自同一次結帳。因此，有些門市收到兩張內容 相同的廚房單，也有顧客只看到信用卡扣款，卻在 App 或官網查不到已成立的訂單。
事故從效能下降發展成全面中斷：
| 時間 | 現象 |
|---|---|
| 11:30 | 會員推播送出，庫存批次與活動報表查詢開始執行 |
| 11:34 | 訂單相關請求一度達平日午餐尖峰的七倍 |
| 11:41 | 資料庫回應時間上升，OneFood 的資料庫連線開始排隊 |
| 11:46 | App、官網與部分門市 POS 大量逾時，客服開始接到查詢 |
| 12:03 | 維運人員重啟 OneFood，所有門市、App 與官網停止接單；外送平台仍可送出訂單，但 OneFood 無法正常接收 |
| 12:14 | OneFood 恢復服務，外送平台積壓的訂單陸續匯入，門市開始核對交易狀態 |
維運人員當時只能看到主機、JVM 與資料庫指標，無法判斷是哪個模組先出問題，也看不出一筆交易在訂單、付款、庫存與廚房之間走到哪一步。十一分鐘是系統完全停止服務的時間；在此之前已有十多分鐘大量逾時，恢復後也仍有訂單等待確認。
當天下午，共有 31 名財務、客服、資訊與門市人員參與處理，前後花了六個小時比對訂單、付款與廚房單。事故留下的初步數字如下：
| 影響 | 數字 |
|---|---|
| 超過三分鐘才確認結果的訂單 | 3,842 筆 |
| 疑似重複送出的訂單 | 217 筆 |
| 付款成功但訂單狀態不明 | 63 筆 |
| 出現負庫存的門市 | 18 家 |
| 直接退款、補償與估計流失營收 | 新臺幣 126 萬元 |
| 人工對帳與客服處理工時 | 186 小時 |
表中的訂單是從效能下降到恢復後清查期間受影響的交易，不只計算十一分鐘的全面中斷；各類別也可能重疊，例如付款狀態不明的訂單也可能超過三分鐘才確認結果。
公司正面臨什麼成長壓力
公司輪廓
| 項目 | 現況 |
|---|---|
| 門市 | 42 家直營門市，分布於北、中、南部 |
| 品牌 | 3 個品牌，共用會員、採購、部分菜單與中央廚房 |
| 員工 | 約 650 人，其中資訊團隊 24 人 |
| 會員 | 約 120 萬名註冊會員 |
| 訂單通路 | 門市 POS、App、官網、兩家外送平台 |
| 訂單占比 | 門市 60%、自有線上通路 22%、外送平台 18% |
| 尖峰負載 | 平日午餐尖峰每五分鐘約新增 300 筆訂單，產生約 1,800 次訂單相關系統請求；活動開始後，請求量一度達平日七倍 |
| 周邊系統 | 金流、電子發票、ERP、物流、簡訊與外送平台 |
董事會已核准兩年成長計畫：門市從 42 家增加到 80 家，推出一個只做外帶與外送的新品牌，並開放第一批加盟店。80 家包含首批 10 家加盟店，其餘新增門市仍由好味直營。
營運團隊預估，門市增加後，尖峰流量與支援案件會同步增加。行銷團隊準備為新品牌 設計獨立的菜單、價格與活動規則；負責加盟籌備的團隊則開始盤點加盟店可查看的資料、 可執行的作業，以及總部與加盟經營者各自負責的範圍。
管理團隊開始擔心，現有系統不只可能撐不住下一次活動，還可能成為公司成長速度的上限。
老闆希望公司變成什麼樣子
事故檢討會上，執行長林若晴說：
兩年內我們要開到 80 家店，也要能快速測試新品牌。系統不能再決定公司可以長多快。午餐尖峰出問題時，更不能所有通路和門市一起停下來。
管理團隊將期待整理成五項可以被觀察的業務結果：
| 業務目標 | 現況 | 兩年內希望達成的結果 |
|---|---|---|
| 支援展店與加盟 | 新門市設定與驗證平均需要 15 個工作天 | 5 個工作天內完成，不必等待專屬版本上線 |
| 加快新品牌與新通路上線 | 新品牌約需 6 個月，新通路約需 4 個月 | 新品牌 8 週、新通路 4 週內推出第一版 |
| 降低尖峰營運風險 | 局部異常可能拖垮全部通路 | 未受影響的門市與通路仍可接單；結果不明的交易在 30 分鐘內查明 |
| 縮短產品試驗週期 | 需求提出到上線通常需要 6 至 8 週 | 一般活動與規則變更在 10 個工作天內完成驗證並上線 |
| 提高交易資訊可信度與時效 | 每月約 320 筆交易需人工核對；營運報表隔日上午才完整 | 人工核對降至每月 50 筆以下；營運資料在 5 分鐘內可查 |
財務長補上一個限制：轉型期間不能讓公司停止接單。董事會每半年檢視一次投資，下一階段預算必須說明前一階段改善了哪些業務結果，以及還有哪些風險沒有降低。
董事會沒有指定改造手段，只要求任何方案都不能中斷日常營運，而且每一筆投資都必須說明解決了哪個業務痛點，以及公司要如何確認結果真的變好了。
不同角色看到的問題
事故檢討後，各角色提出了自己的目標、困擾與顧慮。
| 角色 | 主要目標 | 現在最痛的事 | 最擔心的轉型風險 |
|---|---|---|---|
| 執行長 | 展店、新品牌與營收成長 | 系統限制商業速度 | 花大錢後只換技術，業務結果沒有改善 |
| 營運長 | 門市穩定、出餐效率與標準化 | 各通路狀態不同，門市靠電話處理例外 | 新舊系統並存讓第一線更混亂 |
| 行銷長 | 快速設計活動與會員經營 | 每次優惠都要排進核心系統版本 | 投入改造後，活動上線速度仍沒有改善 |
| 財務長 | 對帳、退款與投資回報 | 訂單、付款、發票資料經常需要人工核對 | 改造期間影響結帳與稽核 |
| 門市店長 | 正確接單、備餐與交付 | 看不到訂單卡在哪裡，也無法自行復原 | 網路或中央服務異常時無法營業 |
| 廚房人員 | 按正確順序收到可製作的餐點 | 重複單、缺料單與臨時取消干擾出餐 | 新流程增加操作步驟 |
| 顧客 | 快速知道價格、付款與取餐狀態 | 逾時後不知道該等、重試還是聯絡客服 | 不同通路的價格、點數與狀態不一致 |
| 客服與財務 | 查到完整交易歷程並處理例外 | 需要跨五個畫面與試算表拼出真相 | 改造後仍無法取得一致的交易資訊 |
| 加盟經營者 | 在授權範圍內管理門市與掌握營運狀況 | 現有流程與權限都是依直營門市設計 | 看不到自己的必要資料，或看到不屬於自己的會員與他店資料 |
| 資訊團隊 | 安全地交付並快速定位事故 | 所有改動都碰同一套程式與資料庫 | 改造範圍超過團隊可以承擔的程度 |
現況：一套系統承擔整家公司
單體系統 OneFood
好味的核心系統叫做 OneFood。它原本是門市 POS 後端，現在也承接 App、官網與外送平台送入的訂單，並包含下列模組：
| 模組 | 主要責任 |
|---|---|
| Menu | 品牌、門市菜單、價格與上下架時段 |
| Promotion | 優惠券、組合價、會員日與使用限制 |
| Order | 購物車、訂單、取消與狀態 |
| Payment | 付款請求、回呼、退款與日結 |
| Inventory | 原料、餐點可售量與門市調撥 |
| Kitchen | 廚房單、製作佇列與出餐狀態 |
| Member | 會員、等級、點數與消費紀錄 |
| Delivery | 外送平台訂單與配送狀態 |
| Reporting | 營運、財務與活動報表 |
這些模組雖然在程式碼裡有不同套件，卻被一起建置、一起部署，也直接讀寫同一套關聯式資料庫。報表工具、批次程式與部分外部整合還會繞過應用程式，直接查詢或更新資料表。
目前的權限清單顯示，部分批次與報表帳號可以直接存取大量正式資料表。資料庫操作 紀錄保留了帳號與時間，卻沒有標示每次異動所屬的業務作業或負責單位。
flowchart LR
Channels["POS／App／官網／外送平台"] --> Monolith["OneFood 單體應用<br/>菜單、優惠、訂單、付款、庫存、廚房、會員、外送、報表"]
Monolith --> DB[("共用交易資料庫")]
Reports["報表與批次作業"] --> DB
Monolith --> Payment["金流服務商"]
Monolith --> Invoice["電子發票"]
Monolith --> ERP["ERP／物流"]
Monolith --> Messaging["簡訊／推播"]交付與營運方式
| 觀察面向 | 現況 |
|---|---|
| 團隊分工 | 團隊依前端、後端、資料庫與維運分工，沒有端到端負責單一業務能力的團隊。 |
| 發布方式 | 正式版平均每六週發布一次。部署需要兩小時維護時段，失敗時通常回復整個版本。 |
| 測試方式 | 自動化測試以單元測試為主，跨模組回歸仍由 QA 手動執行，完整回歸約需五個工作天。 |
| 變更範圍 | 過去一年的變更紀錄顯示，一項優惠規則平均會改動六個模組。 |
| 可觀測性 | 正式環境只有主機、JVM 與資料庫監控，沒有跨通路、模組與外部服務的交易追蹤；近半年事故的平均復原時間約為 110 分鐘。 |
| 知識集中 | 兩位資深工程師理解優惠、訂單、付款與庫存交錯的規則，大部分緊急變更都需要其中一人參與。 |
| 外部依賴 | ERP、電子發票、金流與外送平台仍是未來數年要保留的外部系統，不能假設它們會一起改造。 |
未來希望支援的業務情境
管理團隊沒有指定系統該怎麼實作，而是描述未來希望支援的業務情境：
| 業務情境 | 希望支援的能力 |
|---|---|
| 開設新門市 | 營運人員能在五個工作天內完成菜單、價格、權限與設備設定，不需要等待一次專屬的系統改版。 |
| 推出新品牌或新通路 | 團隊可以沿用既有的會員、訂單與營運能力，同時保留新品牌自己的菜單、價格與活動規則。 |
| 加盟店開始營運 | 加盟經營者只能查看自己門市的銷售與營運資料；總部仍能執行跨品牌管理，而非履約所需的會員個人資料不會提供給加盟店。 |
| 行銷推出大型活動 | 系統能承受短時間內快速增加的訂單；即使部分功能發生異常，仍不會讓所有門市與通路一起停止服務。 |
| 顧客完成下單 | 無論使用 POS、App、官網或外送平台，顧客都能清楚知道訂單、付款與取餐進度，不必因畫面逾時而猜測是否要重新操作。 |
| 門市遇到異常 | 店員能看見問題發生在哪一筆訂單、目前由誰處理，以及門市是否仍能繼續接單與出餐。 |
| 客服、營運與財務查詢交易 | 可以看到一致且可追查的訂單歷程，不必再從多個畫面與試算表拼湊答案。 |
| 一般活動或規則需要調整 | 改動不會牽連整套系統，團隊能在十個工作天內完成驗證並上線。 |
轉型期間的現實限制
| 限制類別 | 必須保留的條件 |
|---|---|
| 營運不中斷 | 42 家門市不能因轉型長時間停業，日常接單與出餐必須繼續。 |
| 既有設備 | 42 家既有門市的 POS 前台軟體與設備至少還會使用三年，轉型期間仍須正常接單與出餐。 |
| 外部系統 | ERP、電子發票、金流與外送平台不會配合好味同時改造。 |
| 團隊規模 | 資訊團隊只有 24 人，目前是兩個交付小組與一個平台／維運小組。 |
| 門市操作 | 門市對系統延遲與狀態不一致的容忍度很低，不能把所有例外都丟給第一線人工判斷。 |
| 財務流程 | 財務仍必須完成每日結帳，並說明訂單、付款、退款與發票之間的差異。 |
| 資料權限 | 加盟經營者只能存取自己門市的資料；會員個人資料、付款資料與跨店營運資料仍由總部負責管理與稽核。 |
董事會每半年檢視投資、再決定下一階段預算的節奏，和先規劃、審查再執行的 Stage-Gate 做法相近；這會是後續系列討論轉型治理時的固定約束。