系統出問題時，處理流程要在事前訂好：誰接手、何時算事件、怎麼回報、修好之後怎麼通知，都寫成文件。磨人把回報、重現、暫行辦法、修正與通知固定成同一條路，專案團隊在任何時間點都知道下一步是什麼。事後的檢討不究責，焦點放在促成因素與改善項目。受託維運公部門系統時，流程還要接得上主管單位的通報作業，所以說明稿與異動紀錄也是流程的一部分。
哪些情況要宣告為事件
一般回報與事件的處理強度不同。宣告條件事前寫明，處理的人不必在壓力下臨場判斷。Stribblehill，2017在 Google 的 Site Reliability Engineering 一書第十四章說明，宣告事件的條件寫得越明確越好，並舉出三個例子，任一成立就視為事件：需要第二個團隊參與、使用者或客戶看得到影響、集中分析一小時仍未解決。該章描述的是 Google 的規模，小型專案可依團隊大小調整門檻。
條件用使用者看得到的現象來寫，例如頁面打不開、表單送不出、資料顯示不一致。條件確定後，與SLA 的分級與目標一併寫進維運約定，專案團隊與開發團隊判斷的依據就會一致。
- 回報登錄在共用回報清單
- 工程負責人對照宣告條件需要第二個團隊參與、使用者看得到影響、集中分析一小時仍未解決
- 三項任一成立宣告事件指定指揮、作業、溝通、規劃四種角色
- 三項都不成立依一般回報步驟處理仍有登錄、負責人與結案回覆
條件取自 Google 手冊的舉例，各專案的門檻依團隊大小在維運約定中另訂。
回報到結案固定走同一條路
未達事件條件的回報，同樣要有登錄、有負責人、有結案回覆。磨人把回報、重現、補資訊、暫行辦法、修正與通知固定成同一個流程，下圖標出每一步由誰負責。
依回報到結案的固定順序畫出；清單與欄位依各專案調整。
- 專案團隊接到場域人員或使用者的來電來信後，先登錄在共用回報清單，貼出頁面、發生時間與截圖，並寫明為何要優先處理。
- 在共用討論串留言，指名工程負責人並附上清單項目，開發團隊先回覆已收到、排查中。
- 工程師先在自己的環境重現。重現不了時，請回報者補上操作時間點與填寫內容的截圖，或附上測試案例影片請對方補充情境。
- 給出暫行辦法與預計完成時間，例如調整瀏覽器對該網站的權限，讓現場先能繼續操作。
- 修正先上測試站，確認後再上正式站。
- 在原討論串回覆已更新，回報與結果留在同一處。
需要人工補資料的回報，由專案團隊向使用者收齊佐證，開發團隊在後台處理後回覆；必要時請專案團隊向使用者確認原狀，以便還原。這個模式在長期維運期間持續使用。
暫行辦法只處理當下。同類問題，磨人也會回饋到頁面，補上更清楚的判斷與提示。
測試階段的問題改用編號清單管理。工程師逐號標註處理狀態：能重現的處理，重現不了的附上測試案例影片請對方補充情境，屬提示類的先加說明浮窗。處理完後，工程負責人把原因歸納並對照問題編號，說明對齊的方式，最後以一句更版完成通知，請產品端確認。
涉及前後端的問題，磨人在討論串貼出情境與截圖，指名兩端負責的開發者先對齊判斷依據，再修正。新版本推出後，磨人重測，並把結果記進品質檢查清單。例行維運中的回報處理、週期檢查與維運報告，另見上線後的例行維運。
角色與溝通在事前分好
系統發生問題時，磨人會安排人力即刻處理。接手的人是誰、誰對外說明、誰向使用者確認，事前就寫在流程文件裡。
Stribblehill，2017描述了事件處理常見的危害：只盯著技術問題、溝通不良、各自改動系統。該章建議的做法，是分出指揮、作業、溝通與規劃四種角色，設固定的指揮所，維護即時更新的事件文件，並在事前備妥與演練流程。
Google 的規模遠大於一般專案，小團隊裡一人可能身兼兩種角色，只要寫明誰在指揮、誰負責對外說明。磨人的對應做法是固定一條討論串，判讀、決定與進度都寫在同一處，專案團隊與開發團隊各自負責的部分，在流程文件上分開列。
主機端的事項由專案團隊轉交主機的維運窗口，作業時段事先確認。
對主管單位的說明稿與異動紀錄
受託維運公部門系統時，主管單位轉來的資安通報，處理順序事前固定如下。
- 專案團隊轉寄通報信，並在討論串指名工程負責人。
- 磨人先回覆處理中。
- 工程師判斷來源，擬好給主管單位窗口的說明稿，內容含初步原因、補強方向與複測方式。
- 專案團隊審閱後送出。
- 專案團隊詢問修復時程，磨人給出預計完成日。
- 修復並更新正式站後回報。
- 涉及程式變動的部分，依資安管理要求補填異動紀錄，供後續稽核檢視。
修復動作之前，先保留日誌與畫面，作為調查的依據。數位發展部資通安全署，2026的業務專區說明，機關發生資通安全事件時，應依辦法即時通報及應變，迅速完成損害控制或復原作業，並確保跡證保存；資安署也訂有各機關資通安全事件通報及應變處理作業程序，供機關參辦。開發團隊的欄位與留存紀錄，以主管單位的作業程序為準。
受託端也在法規的範圍內。資通安全管理法施行細則第七條規定，機關委外建置、維運資通系統或提供資通服務時，選任與監督受託者應考量人員配置、複委託、客製系統的安全測試、事件通報與契約終止時的資料處理等事項，並須定期稽核受託者，或於得知事件時查核。稽核受託者時，異動紀錄是可以直接提供的資料，所以修復上線時一併補齊。
外部檢測或弱點掃描的結果進來時，工程負責人在討論串貼出報告截圖並標明處理期限，先判讀成因，再提出一到兩個處理選項，例如調整預設值、改成簡化版錯誤頁或只顯示純文字，請開發者確認不會連帶出錯。開發者調整後先推出修正版，再回覆已處理，由工程負責人複查。修補優先序、誤判申覆與複測的細節，見弱點掃描報告拿到之後。公部門專案要留哪些證據，見公部門專案的交付與維運證據。
備份還原演練先問清楚由誰訂計畫
還原演練驗證備份在需要時確實可以還原，同時留下主管單位要求的佐證。演練牽涉主機端，所以第一步是問清楚由誰訂計畫。
- 磨人先問專案團隊：由開發團隊提出演練計畫，還是主管單位已有規劃版本再調整。主管單位提供注意事項與流程時，磨人依其準備。
- 專案團隊先列要求：啟用備援後須由團隊驗證資料正確，並寫明驗證步驟、比對方式（筆數、內容、檔案大小）與佐證截圖。
- 磨人排定演練時段，邀請專案團隊參加。
- 演練時還原前一晚的備份，確認服務正常，比對資料筆數與上傳檔案數量。
- 專案團隊填寫還原紀錄測試表並附上還原後的截圖，表單的寫法依專案的實際架構調整。
- 演練紀錄與佐證放進共用雲端，並提供可連線的測試網址，供補截圖。
- 專案團隊確認資料量足夠後，才請主機的維運窗口刪除演練用主機與相關設定。
演練環境最後才清理，佐證必須在清理前完成。Nelson 等，2025是美國 NIST 發布的事故應變建議，把事故應變放進組織的資安風險管理，從準備到復原整段都有涵蓋，可供機關規劃事故應變作業。備份還原演練是事前準備的一環。
事後報告不究責，寫促成因素
Lunney 與 Lueder，2017主張無究責的事後檢討，焦點放在事件的促成因素，不歸咎個人或團隊。該章認為人們若怕受罰就會隱匿問題，因此應改善制度與流程，事後報告本身不作為懲罰的依據。
Allspaw，2012從工程師的角度補充：無究責的檢討讓涉事工程師能毫無懼怕地詳述當時的行動、觀察、預期與假設；怕受罰就不願提供細節，事故的機制無法被理解，同樣的事故必然重演。文中也提出「第二個故事」，把人為錯誤視為組織系統弱點造成的結果，不視為失敗的原因。這兩份文獻都來自網路服務業的工程實務。
磨人的做法是恢復之後依日誌整理調查報告，完整版附改善計畫。報告寫事件經過、影響範圍與促成因素，原因分屬應用端與主機端時拆開列出，各自追蹤。宣告為事件的，建議都補一份事後報告。
不適合套用完整流程的情況
- 活動期間限定的一次性頁面，活動結束後下架，沒有後續維運。登錄與結案回覆就夠，不必設事後報告。
- 尚無真實使用者的試作版本或內部測試環境。回報走測試清單即可，不需要宣告條件與指揮角色。
- 維運窗口與負責人尚未確定的系統。先決定誰接手回報，再談事件宣告；沒有接手的人，條件寫得再細也無人執行。
開始前要準備什麼
- 共用回報清單與固定討論串的位置，以及誰有權登錄。
- 宣告條件，用使用者看得到的現象來寫。
- 角色名單：指揮、作業、溝通、規劃，加上主機維運窗口與主管單位窗口的聯絡人。
- 對主管單位的說明稿欄位，以及異動紀錄的格式。
- 備份還原演練的負責方、驗證步驟與佐證項目。
- 事後報告的範本，以及不究責的約定。
磨人配合教育部專案，從設計標承接到工程標，長期維運戶外教育資源平臺。磨人會把這份清單整理進長期維運與平台建置的維運約定，並依主管單位的作業程序調整欄位。現有系統想對照這些項目時，可以聯絡磨人，提供目前的流程文件，由開發團隊逐項對照。
