上線後的工作有固定的順序與週期，每一項都留下紀錄，專案團隊在每一步都知道下一步是什麼。為什麼要持續維運，見上線後為什麼要持續維運，本文只談做法。
一則回報從登錄到結案的處理順序
使用者或場域人員來電來信時，專案團隊先把這則回報登錄在共用回報清單，再到討論串留言，標記負責的工程師並附上清單項目。磨人先回覆已收到、排查中，找出原因後修正並上線，最後在同一則回報的回覆中寫明已處理。以下是歸納自多筆回報的步驟。
- 登錄：專案團隊在共用回報清單登錄，附上頁面、發生時間與截圖，並說明為什麼需要優先處理。
- 指派：在討論串貼出清單項目，指名負責的工程師。
- 回覆已收到：磨人先回覆已收到、排查中。
- 重現：工程師先在自己的環境重現問題。
- 補資訊：請回報者提供操作時間點或填寫內容的截圖。
- 暫行做法：給出暫行做法與預計的完成時程。
- 修正：修正先上測試站，確認後再上正式站。
- 結案回覆：在同一則回報的回覆中寫明已處理或已更新。
依專案團隊與磨人配合的做法整理，範圍是使用者與場域人員回報的一般問題。
需要人工補資料的回報，由專案團隊向使用者收齊佐證，磨人在後台處理後回覆。需要還原時，由專案團隊向使用者確認原本的狀態，以便還原。系統發生問題時，磨人會安排人力即刻處理。
測試發現的問題與檢測結果用同一套紀錄處理
測試時發現問題，磨人在討論串貼出情境與截圖，指名負責的前端與後端開發者，請兩邊先對齊判斷依據，修好再測試。開發者回報根因與處理狀態、推出新版本後，磨人重測，並把結果記在品質檢查清單裡。改好的部分也可交給專案團隊測試。問題與重測結果都留在清單上，之後有紀錄可查。
主管單位安排的檢測或弱點掃描有結果進來時，工程負責人貼出報告截圖並標明處理期限，先判讀成因，再提出一到兩個處理選項，例如調整預設值，或把錯誤頁改成簡化版、只顯示純文字，請開發者確認不會連帶出錯。開發者調整後先推出修正版，再回覆已處理，由工程負責人複查。修補優先序、誤判申覆與複測的細節，見弱點掃描報告拿到之後的處理。
外部寄來的通知先依性質分級再決定是否處理
搜尋引擎管理工具寄來的通知，由專案團隊轉貼到討論串詢問，磨人依性質分級後回覆。頁面重新導向類的通知，先不處理。找不到頁面類的通知，多半來自使用者留存的歷史舊連結：網站改版之後，舊連結仍會被訪問，開錯網址本來就會回應找不到。專案團隊接受這個判斷，暫不動作。
分級的理由之一是打斷有成本。Mark 等，2008的實驗發現，被打斷的工作反而在較短時間完成，品質沒有差異，但人們靠加快速度補償，代價是更多壓力、挫折與時間壓力。該研究用的是實驗室任務，這裡取的是打斷有成本這一點。磨人先分級，不需處理的通知就不會切斷正在進行的修正。
週期檢查各自留下的紀錄
維運委外時，機關對受託者有選任與監督的責任。資通安全管理法施行細則第七條規定，機關委外建置、維運資通系統或提供資通服務時，選任與監督受託者應考量人員配置、複委託、客製系統的安全測試、事件通報與契約終止時的資料處理等事項，並須定期稽核受託者，或於得知事件時查核。條文對稽核只寫「定期」，沒有給具體天數。
數位發展部資通安全署的常見問題說明，委外前就要注意受託者的選任，委外後要監督，建議透過契約規範與專案管理落實。同一份說明提到，核心系統或委託金額達新臺幣一千萬元以上者，檢測須由機關自行或另委託第三方辦理。
磨人配合教育部專案，從設計標承接到工程標，長期維運戶外教育資源平臺，依主管機關要求配合掃描、修補中高風險與誤判申覆。年度滲透測試與弱點掃描由主管單位安排，磨人配合修補與複測。下表是週期項目與各自留下的紀錄。
| 項目 | 週期 | 安排者 | 留下的紀錄 |
|---|---|---|---|
| 維護報告 | 每月 | 磨人 | 當月取得的數據，以及專案團隊可接受格式的報告 |
| 主機弱點掃描與修補 | 每月 | 主管單位安排，磨人配合修補 | 掃描報告、工程師的處理回覆、專案團隊填寫的改善進度表 |
| 滲透測試與複測 | 每年 | 主管單位安排，磨人配合修補與複測 | 各階段的時程與資料，以及會後錄影與簡報 |
- 維護報告每月
- 主機弱點掃描（主管單位安排）每月
- 滲透測試與複測（主管單位安排）每年
依專案團隊與磨人配合的做法整理。圖上的位置只表示頻率，不是排程。
主機弱點掃描每月進行。專案團隊收到掃描報告後，通知工程負責人並傳送報告，工程師依主管單位規定的期限修正，處理完回覆已處理，專案團隊再把處理說明填入改善進度表回報主管單位。僅調整伺服器設定而程式碼沒變動時，可先不填系統異動單，但仍須提供調整內容簡述供填表。每次掃描都有人認領、有回覆、有紀錄。
年度滲透測試分階段進行：先辦工作說明會，再依梯次檢測，之後有初測報告說明會，修正後再辦複測報告說明會。每一階段的時程與資料都由專案團隊轉知，未出席者可看會後錄影與簡報。
備份還原演練前，專案團隊先列出要求：啟用備援機後須由團隊驗證資料正確，並寫明驗證步驟、比對方式（筆數、內容、檔案大小）與佐證截圖。演練後，工程師把紀錄與佐證放進共用雲端，並提供可連線的測試網址供補截圖。專案團隊確認佐證足夠後，才清理演練用的主機與相關設定。順序是先留好佐證，再清理演練環境。
程式碼靜態分析不按日曆，主分支每有更新就自動執行一次。
維運報告所需的數據要在接手時就準備好
維運報告需要可追溯的數據，接手既有系統時更要先弄清楚現況。磨人把準備工作分成兩種視角列出。
- 從頭建置：先處理自動備份設定、紀錄機制的完整性，以及能否寫程式快速取得報告數據。
- 接手既有系統：先確認伺服器內安裝的軟體與部署方式、備份範圍與存放路徑、紀錄設定與存放路徑，以及是否已有取數程式。
月報在次月初交給專案團隊，轉送主管單位。主管單位閱讀後點出月報中需要留意的統計趨勢，專案團隊轉告，磨人回覆收到並進一步分析原因。
接手既有系統的程式碼檢查見接手既有系統的全碼健檢流程，交付與維運證據的整理方式見公部門專案的交付與維運證據。
例行事項與例外事項分開記錄
每月固定做的事，是抓取維護報告所需的數據，並產出專案團隊可接受格式的報告。例外事項則寫入當月的維護事項，包括以下來源：
- 配合資安來文修改
- 配合弱點掃描修改
- 配合資安稽核
例行與例外分開，報告才讀得出當月固定做了什麼、額外配合了什麼。突發事件另有處理流程，見系統異常時的處理流程。系統含有 AI 問答時，維持拒答門檻與可信度的做法見AI 問答上線之後的維持方式。
交付後的工作常被統稱為維護，並分為完善、調適、修正與預防四類。Rajlich 與 Bennett，2000主張交付後其實是一連串不同階段，各階段有不同的活動、工具與商業後果，業界與工程都能從理解這些階段與轉換獲益。磨人把例行與例外分開記錄，維運報告才能分別呈現兩類工作。
Lientz 等，1978的問卷研究發現，維護與增強佔去系統與程式開發群組的大部分資源，維護的問題偏管理面。這是 1978 年的研究，這裡引用的是維護問題偏管理面這一點。回報登錄、週期檢查與維運報告，處理的正是這類管理面的事。磨人在長期維運與平台建置中，用同一份清單分開記錄例行與例外，每月交出專案團隊可接受格式的報告。
不適合的情況
這套順序與週期，對下列情境幫助有限，需要先處理前提。
- 系統上線後沒有後續更新與維護的計畫：回報與週期檢查沒有施行對象，月報也無從產出。
- 沒有固定的專案團隊或窗口：回報無處登錄，也無人指派，需要先確定誰接來電來信、誰填清單。
- 紀錄與備份沒有留存：維運報告缺少數據來源，須先補齊紀錄設定與備份範圍，再談月報。
開始前要準備什麼
上線後的維運要順利進行，開始前先備齊下列項目：
- 共用回報清單與窗口：誰登錄、誰指派、誰回覆結案。
- 主管單位對掃描、修補期限與改善進度表的要求。
- 備份範圍與存放路徑，紀錄設定與存放路徑。
- 維運報告的格式，以及取得報告數據的方式。
- 備份還原演練的驗證步驟、比對方式與佐證截圖的要求。
上線後的順序與週期，可以在需求階段就寫進文件。要討論範圍與做法，請與磨人洽談長期維運。
