磨人認為，系統上線後仍需要持續維運。只要系統還有人使用，使用方式、執行環境與資安要求就會繼續改變。不跟著調整，系統會逐漸變得難以使用，也難以修改。磨人把上線後的工作分成每月固定的例行工作與配合各種要求的例外工作，兩類都留下紀錄，專案團隊與主管單位隨時能核對。本篇是長期維運與政府合作系列的主文，後面各節會連到系列中的專文。
軟體演化與維運工作的分類
Lehman，1980的論文提出持續變更定律：被使用並且要反映現實的程式，若不持續調整，會逐漸變得較不實用，直到被重建取代。論文同時指出，變更時若不投入維護工作，程式結構會劣化，複雜度會增加。
Lientz 等，1978的問卷寄給 120 個組織，回覆 69 份。回覆顯示，維護與增強佔去系統與程式開發群組的大部分資源，管理階層也認為維護和增強至少略比新開發重要。維護的問題偏向管理面，使用者對增強與擴充的要求，則是最重要的管理問題。
磨人把維運當成管理工作處理：每項工作都列在清單上，依固定的週期執行並留下記錄。
傳統上，交付後的工作都稱為維護，並常分為完善、調適、修正與預防四類。Rajlich 與 Bennett，2000主張，交付後其實是一連串不同的階段，各階段有不同的活動、工具與商業後果，業界與工程都能從理解這些階段與轉換獲益。
Swanson，1976把軟體維護比喻為冰山，水面下有許多不易衡量的內容。這些工作需要記錄，專案團隊才查核得到。
磨人在同一份清單裡把每月例行與例外分開。例行工作有固定的節奏，例外事件則寫入當月的維護事項。
| 類型 | 內容 | 留下的紀錄 |
|---|---|---|
| 例行 | 每月固定抓取維護報告所需的數據；依年度排程進行帳號清查、還原備份演練與個人電腦資安健檢 | 專案團隊可接受格式的維護報告；演練與清查的紀錄與佐證 |
| 例外 | 配合資安來文修改、配合弱點掃描修改、配合資安稽核 | 寫入當月維護事項，附逐項處理說明 |
- 當月的維運工作
- 判斷工作的來源
- 每月固定的數據與報告例行依固定週期執行並留下紀錄
- 配合資安來文、弱點掃描或資安稽核例外寫入當月維護事項，附處理說明
- 系統發生問題依異常處理流程通報、修復、通知與事後報告
依每月維護報告的做法整理。系統發生問題時另走異常處理流程。
除了表中的工作，系統也可能發生問題。系統發生問題時，磨人會安排人力即刻處理。處理流程見系統異常的通報、分級與修復流程，分級與目標怎麼約定見SLA 的分級與目標怎麼寫。
例行資安工作依年度排程執行
例行資安工作需要可預期的排程。磨人為每一季的例行資安工作開設討論串，涵蓋還原演練、帳號清查與個人電腦健檢，動手前先和專案團隊確認時程與範圍，再依年度排程執行並留下紀錄。
年度專案的例會、回報清單與上線檢查怎麼安排，見跨單位年度專案的溝通節奏。回報處理與週期檢查的日常做法，見上線後的例行維運。
執行環境更新與掃描結果的處理
磨人配合教育部專案，從設計標承接到工程標，在戶外教育資源平臺上線後，配合主管機關要求的掃描、修補中高風險、誤判申覆。以下是更新與掃描處理中可通用的做法。
執行環境與套件的官方安全修正，需要儘快跟上。Node.js 執行環境釋出安全修正版後，磨人主動提醒專案團隊並安排升級；需要主機端配合的部分，由專案團隊轉交主機的維運窗口，全部就緒後完成升級並逐項驗證。
每月例行的主機掃描，依主管單位規定的期限處理。專案團隊收到掃描報告後，通知工程負責人並轉送報告。工程師依規定的期限修正，處理完回覆已處理。專案團隊再把處理說明填入改善進度表，回報主管單位。
依主管單位規定的期限整理。
只調整伺服器設定而程式碼沒有變動時，可先不填系統異動單，仍須提供調整內容的簡述，供專案團隊填表。掃描報告拿到之後怎麼排修補優先序、怎麼申覆誤判，見弱點掃描報告拿到之後的處理。
主管單位也可能依外部資安比對結果，列出需要更新修補或移除軟體的系統名單，並限期回覆。工程師逐項處理並寫明做法，專案團隊彙整後回覆主管單位，主管單位據以核銷。
法規與資安要求逐年調整
公部門的資安要求會逐年調整，系統即使功能沒有改動，也需要跟著檢視。年度滲透測試與弱點掃描由主管單位安排，磨人配合修補與複測。
年度滲透測試分階段進行：先辦工作說明會，再依梯次檢測，之後有初測報告說明會，修正後再辦複測報告說明會。專案團隊在每個階段於固定的溝通管道轉貼時程與資料，未出席者可看會後錄影與簡報。兩種檢測的差別與法規頻率，見弱點掃描與滲透測試的差別。
要求也會落到具體設定。工程負責人觀察到政府部門的資安檢核表多已把密碼最短長度由 8 碼改為 12 碼，通知全體開發者，把密碼規則改為至少 12 碼並含大小寫英文與數字。前端的提示文字隨後與後端規則同步，由工程負責人提供統一文案，再補上說明浮窗。
因應當年度資安規範的架構要求，磨人調整主機架構並通知專案團隊。改善措施需要可查核的佐證，磨人工程師隨即擷取佐證畫面。
主管單位彙整的資安精進措施與自檢表，涵蓋輸入輸出處理、安全標頭設定、檔案上傳驗證與密碼儲存方式等類。專案團隊轉貼後，工程團隊依自檢表逐項檢視並自行驗證。逐項可核對的清單，讓例行要求有依據可查。
公部門的人工智慧應用日後也會被盤點與查核。磨人在相關檢核要求出現的數個月前，已把公部門人工智慧應用參考手冊放進團隊共用的資料供閱讀。檢核表送到後，磨人盤點專案中實際用到 AI 的範圍，隔日提出填寫版並提醒專案團隊審閱，專案團隊當日完成提交。
技術債的累積與償還
技術債是 Cunningham，1992用的比喻：先交付尚未整理好的程式，像是舉債，短期可以加速，及時改寫還清則無妨。不償還時，花在不夠好的程式上的時間都是利息，整個工程組織可能被未整理的實作拖到動彈不得。
Sculley 等，2015針對機器學習系統指出，快速進展看似不花成本，實際會累積可觀的長期維護成本，資料相依性是風險來源之一。含 AI 功能的系統，維護範圍因此多了資料這一層。AI 問答上線後的拒答門檻與濫用防守，見AI 問答上線之後怎麼維持可信度。
磨人在系統上線前數個月，就由工程負責人列出資安基本做法，請開發者配合：
- 金鑰類設定一律放進環境變數
- 請求加上固定的識別標頭
- 所有寫入類請求附上防偽權杖
- 登入憑證的存取包成獨立模組
- 先訂出閒置後自動登出的規則
其中把登入憑證的存取包成獨立模組，是因為日後要換成別種驗證方式時，比較好調整。
設計與工程分屬不同標案時，系統知識怎麼延續，另有專文說明：從設計標到工程標怎麼延續系統知識。
維運報告怎麼寫
維運報告讓專案團隊與主管單位核對當月做了什麼。磨人每月固定抓取維護報告所需的數據，並產出專案團隊可接受格式的報告。報告內容依下列順序整理：
- 每月固定的數據：維護報告所需的數據，以專案團隊可接受的格式提供。
- 當月的例外事項：配合資安來文修改、弱點掃描修改或資安稽核時，寫入當月維護事項。
- 逐項處理說明：逐項寫明做了什麼；只調整伺服器設定而程式碼沒有變動時，也提供調整內容的簡述。
- 佐證：演練紀錄與截圖，在清理演練環境之前留好。
需求、決策與上線通知留在共用的溝通管道，做法見用共用的溝通管道留下需求與決策。
超出約定範圍的改善，磨人寫成主動提案，並以 POC 先驗證，再決定是否納入約定。做法見約定範圍之外的 POC。
不適合套用本文做法的情況
本文的例行排程與逐項紀錄，適用於長期使用、受主管機關資安要求約束的系統。短期活動頁在活動結束後即下架，維運重點在活動期間的處理與活動結束後的資料保存，不需要年度排程。沒有外部查核要求的內部小工具，例行工作的週期可由使用方自行訂定，不必套用演練與清查的頻率。
開始前要準備什麼
磨人在遷移到託管環境之前，把要向主機的維運窗口確認的問題分成三類整理成清單，避免做到一半才發現缺項：
- 伺服器：測試環境與正式環境的主機配置、能否遠端連線、是否需要申請單
- 資安：弱點掃描與滲透測試由誰安排、在哪個環境執行、費用由誰負擔
- 部署：既有網站移轉前要完成哪些檢查、正式環境由誰部署
合約與驗收也在這個階段對齊。長期委外要同時管理合約條款與雙方關係，見長期委外的合約條款與關係治理。驗收指標如何對應客戶目標，見從需求到成效指標的驗收寫法。
磨人把客戶的目標當成自己的目標，上線後的維運也從責任、環境與紀錄方式的對齊開始。服務內容見長期維運與平台建置。要評估系統現況與維運範圍，可準備主管單位的資安要求與既有的掃描報告，再聯絡磨人。
