將寫進變更單落實到流程中

從 Day 19 到 Day 25 的建置過程中，每一篇都少不了一句「寫進變更單」：

• Day 22 改動 FortiGate 60F 的 Syslog 目的地與記錄政策。
• Day 23 在 PVE 節點建立帳號並啟動 Corosync 封包擷取。
• Day 24 將網頁過濾 Profile 掛上 Policy 1。
• Day 25 接受了二十項授權過期的風險評估。
• 連 pve-firewall.md 都明確寫著：「這三個指令都寫進 Day 26 變更單的回退欄」。

變更單被不斷引用，但這套機制此前卻一直只存在於口頭與註解中。

今天正式把它實作出來。一個合格的生產環境變更管理，必須回答內部控制與 ITGC（IT 一般控制）的四個核心問題：誰提的？誰核准的？什麼時候執行的？怎麼驗證做對了？

本篇的目標不談抽象的 ITIL 流程圖，而是落實到真實的系統與可觀測性管線：

1. 變更即代碼（Change as Code）：一張變更單就是一個 Markdown 檔案，以 Git PR 取代傳統工單表單，利用不可竄改的 Git Commit 歷史記錄建立稽核軌跡。
2. 管線全自動聯動：單子變更時，自動在 Day 21 的 VictoriaLogs 留下結構化標記、在 Day 20 的 Grafana 儀表板 標出變更時間窗區間，並在 Alertmanager 自動開啟與關閉告警靜音（Silence）。
3. 場域實兵驗證：第一張變更單（CR-2026-0001）直接拿生產環境開刀——針對 Day 25 告警中的雙節點叢集關鍵第三票（QDevice VM），進行 Debian 12 到 13 的就地平滑升級。

相關程式碼已開源於 onprem-changes v0.1.0，告警規則與儀表板正本則位於 onprem-metrics v0.3.1。

一、一張單是一個檔：結構化 Markdown 與 Front Matter

在我的架構中，一張變更單就是一個獨立檔案：changes/CR-2026-0001-qdevice-debian-13.md。檔頭以 YAML Front Matter 供自動化腳本解析，內文則以六個固定 Markdown 章節供工程師閱讀與稽核。

1. 內文六大段落（缺少任何一段驗證即中斷）

每一段對應一個關鍵工程問題，任何一段留空，CI 中的 check.py 就會報錯退件：

1. 目的：為什麼要動？
2. 影響：動的時候誰會受損？停機容忍度是多少？
3. 步驟：具體執行哪些指令？
4. 驗證：做完後，如何以客觀指標或日誌證明成功？
5. 回退：失敗時怎麼復原？沒有回退方案必須明載原因，且變更風險（risk）強制升級為 high。
6. 紀錄：實際執行的開始時間、結束時間與執行結果（供結案填寫）。

2. 關鍵 Front Matter 欄位設計思維

• assets：指向 Day 25 的 eol/assets.tsv，格式為 資產/元件。check.py --assets 會嚴格校驗該資產是否存在。變更完成後，資產清單的 commit 訊息會帶上變更單號（例如 eol/assets.tsv: qdevice is on Debian 13.7 (CR-2026-0001)）。無論從資產查變更，還是從變更查資產，都能雙向追溯。
• silence：本次變更預期會被觸發的告警規則。QDevice 重新開機期間，Day 20 設定的 PveQdeviceAbsent 可能觸發。單子事先聲明此規則，執行時腳本會自動向 Alertmanager 註冊有效期限至 window_end 的 Silence。未寫在單子上的異常告警照常響起，這才是監控的真諦。
• approval_exception（一人維運的真實誠實原則）：ITGC 要求「提出、核准、執行」職責分離（SoD）。但在單人維運場域中，偽造另一個核准帳號是自欺欺人。我的規則是：若核准者與執行者相同，必須顯式填寫此欄位說明補償控制（例如：PR 自審且強制 24 小時冷卻期）。

  實測插曲：本次 CR-2026-0001 於 18:14 開 PR、22:15 合併（冷卻約 4 小時），因為當晚需連同腳本進行場域端實測。我如實將「冷卻未滿 24 小時」寫入 approval_exception。誠實記錄例外，遠比假裝一切合規更有工程價值。

• GitHub 分支保護策略：開啟「Require review before merging」後，GitHub 原生機制不允許作者核准自己的 PR，單人專案將無法合併。我的解法是：關閉 enforce_admins，由專案擁有者以管理員身分略過限制合併。在 Push 到 main 分支時，GitHub 會在 Audit Log 印出顯著的 Bypassed rule violations for refs/heads/main 標記。若未來團隊擴充至多人，只要清空 approval_exception 並啟用 enforce_admins，即無縫轉換為嚴格的雙人同儕審查機制。

二、變更單的生命週期：每一步都是一個不可竄改的 Commit

變更的推進完全對應至 Git Commit 歷程：

執行 git log --follow changes/CR-2026-0001-*.md，便能得到這張變更單分秒不差、無法後製竄改的時間線。

實現操作的驗證：本次實測依序歷經 draft（18:11）$\rightarrow$ approved（18:14 於分支，22:15 合併）$\rightarrow$ scheduled（22:37）$\rightarrow$ done（22:55）。
中間漏掉了一步：在 begin 之後忘記 Commit in_progress 狀態。這個疏忽導致後續第五節的 Prometheus 指標 ChangeInProgress 一次都沒觸發。這證明了自動化管線的忠實性——Textfile 收集器只認 Git Repo 的狀態，人若偷懶沒 Commit，監控系統便不會平白編造。

三、開始與結束寫進同一條管線：change-mark.sh

變更執行當下，維運人員最常犯的錯誤是：事後憑記憶補填變更時間。我透過收集端的 change-mark.sh，在鍵入 begin 與 end 的當下，將狀態同步廣播至三處：

sudo -u metrics /opt/onprem-changes/scripts/change-mark.sh begin CR-2026-0001
# ... 執行維護步驟 ...
sudo -u metrics /opt/onprem-changes/scripts/change-mark.sh end CR-2026-0001

腳本執行時會將 Grafana 產生的 Annotation ID 與 Alertmanager 的 Silence ID 保存在 /var/lib/onprem-changes/CR-2026-0001.state，以便 end 時精準關閉。

grafana: annotation 2
alertmanager: silence 751e35fd-322b-4914-a1bf-d80121872d46 until 2026-10-10T23:45:00+08:00
change-mark: CR-2026-0001 begin recorded in the journal (tag change)

場域踩坑筆記

1. Grafana OSS 權限陷阱：原本希望建立僅有「Annotations 寫入權限」的專用 Service Account。但 Grafana OSS 只有 Viewer、Editor、Admin 三種角色，Viewer 寫入註記會回傳 Access denied to save the annotation。在沒有 Enterprise RBAC 的環境下，只能給予 Editor 角色，並嚴格控管 Token 僅限變更腳本使用。
2. Alertmanager amtool 移至主機：收集端主機原本未安裝 amtool（Day 25 是透過 docker exec 呼叫），但 metrics 系統帳號無 Docker 權限。我直接從容器提取同版本（0.28.1）的二進位檔置於 /usr/local/bin。
3. 測試污染生產日誌：原版的 Smoke 測試腳本在開發機上呼叫真實的 logger，意外在 Journal 灌入 8 筆測試用開始紀錄，並被 Promtail 送進 VictoriaLogs 生產日誌庫！隨後在 v0.1.0 重構時，全面導入假 Logger 環境變數（LOGGER），防止測試日誌玷污稽核軌跡。

在 VictoriaLogs 裡看見維護事件的全貌

在 VictoriaLogs 中查詢 CR-2026-0001：

• 若加上 SYSLOG_IDENTIFIER:change，精確顯示 4 行：PVE 節點與收集端各自記錄的 begin（22:45:04 / 22:45:06）與 end（22:55:07）。
• 若不加過濾條件，會查出 9 行紀錄——多出的 5 行蘊含極高價值：
  • 3 行是收集端上的 sudo 稽核日誌，記錄了誰在何時提權執行 change-mark.sh。
  • 2 行是 QNAP NAS Virtualization Station 的事件日誌，精準記錄 22:46:30 開始、22:46:44 完成快照 CR-2026-0001-before 的建立。

這印證了一項最佳實踐：所有快照、備份任務與暫時性資源，一律帶上變更單號命名。維護事件與系統動作自然在日誌庫中聚合為一條連貫的故事線。

四、第一張變更單實測：QDevice VM 就地升級 Debian 13

這台在 Day 25 觸發 AssetEolPassed 告警長達 90 天的 QDevice VM，僅運行 corosync-qnetd，作為雙節點 PVE 叢集的第三票仲裁。

完整單據見 CR-2026-0001，以下記錄關鍵決策與實測數據：

1. 核心決策

• 維護窗設定：排定於離峰時段 22:45 至 23:45。影響評估明確指出：QDevice 離線期間若再有一台 PVE 節點故障，叢集將失去 Quorum 並自我隔離。
• 回退手段：雖然這台 VM 重建只需 10 分鐘，但重建會導致 qnetd 憑證變更，需至 PVE 重新執行 pvecm qdevice setup。因此升級前直接在 NAS 建立快照 CR-2026-0001-before，出錯時可在 1 分鐘內就地還原且憑證不變。
• 驗證指標：check.sh 回傳 0、pvecm status 仲裁票數維持 1 票、VictoriaLogs 存在完整標記，最後更新 Day 25 的 assets.tsv 清除 EOL 告警。

2. 升級歷程與 30 秒的驚喜

升級遵循 Debian 13 官方發行指南，將 APT 來源由 bookworm 置換為 trixie，並使用 systemd-run 執行更新，確保即使 SSH 連線中斷，升級行程也不會中途腰斬。

實測數據分析：

• APT 升級耗時：兩階段升級（apt upgrade --without-new-pkgs 與 apt full-upgrade）歷時約 6 分半鐘。
• 動態連結過渡期：升級期間 systemctl 一度回報 libcrypto.so.3: cannot open shared object file，此為 Debian 13 進行 64-bit time_t 遷移（libssl3 替換為 libssl3t64）的短暫幾秒現象，隨後平穩完成。
• 重啟中斷時間：VM 重啟時，PVE1 端的 check.sh 於 22:54:07 探測到離線（回傳 1），22:54:36 即恢復正常（回傳 0）——實際服務中斷僅約 30 秒！
• deb822 轉換：執行 apt modernize-sources，成功將傳統 sources.list 無痛遷移為標準 deb822 格式（sources.list.d/debian.sources）。

由於重開機僅離線 30 秒，並未達到 Prometheus 規則 PveQdeviceAbsent 所設定的持續 2 分鐘門檻（for: 2m）。因此，Alertmanager 雖然依變更單掛載了 Silence，但最終顯示 No affected alerts。

Silence 沒被觸發算是白做工嗎？
絕非如此。事前設定 Silence 是為維護期間超出預期的延遲買保險，避免假警報干擾值班人員。

3. 當晚最昂貴的教訓：窗外的緊急變更（CR-2026-0006）

在準備進入維護窗前，我發現了一個嚴重疏漏：這台最小化安裝的 VM 既沒有安裝 sudo，歷史紀錄中也遺失了 root 密碼，而 SSH 早在 Day 11 就被加固為只允許公鑰登入且禁止 root 登入。

為了推進升級，維運人員於 22:31 從 NAS 主控台透過 GRUB init=/bin/bash 暴力重設 root 密碼，導致 VM 在排程維護窗開始前重開了兩次。

看這張 Grafana 儀表板：

• 灰色陰影區域（22:45～22:55）：是合規核准的 CR-2026-0001 維護窗。由於 30 秒中斷落在 1 分鐘 Prometheus 取樣間隔之間，圖表上的仲裁票數完全沒有出現缺口。
• 灰色區域左側（22:32～22:36）：出現了一道刺眼的票數驟降缺口，PveQdeviceAbsent 於 22:34:50 至 22:36:35 處於真實 Firing 狀態！

這張圖完美展現了變更治理的威力：任何未經申報、沒有 Silence 防護、不在維護窗內的改動，在可觀測性系統下一覽無遺。依照規定，我於 24 小時內補開了一張緊急變更單（type: emergency）：CR-2026-0006。

五、從單子到指標：Prometheus 變更監控與 Docker Inode 陷阱

為了讓 Prometheus 也能感知變更狀態，我撰寫了 changes-textfile.py，由排程每 15 分鐘拉取 Git Repo 並產生 changes.prom：

change_record{id="CR-2026-0001", status="done", type="standard", risk="medium", implementer="ivan", approver="ivan"} 1
change_window_start_timestamp{id="CR-2026-0001"} 1791643500
change_window_end_timestamp{id="CR-2026-0001"} 1791647100

搭配四條精確的 Prometheus 警報規則（正本位於 prometheus/rules/changes.yml）：

排錯實錄：Docker Bind-Mount 的 Inode 詛咒

在部署本組規則時，我順手揪出了一個從 Day 25 潛伏至今的隱蔽 Bug：

Alertmanager 的 alertmanager.yml 是透過 Docker 單檔 Bind Mount 掛載進入容器。Day 25 我直接覆寫修改了該設定檔（產生了新的 Inode），但 Docker 單檔掛載認的是建立容器時的 Inode！

這導致容器內部讀取的永遠是舊 Inode 的過期檔案，即使對 Alertmanager 發送 SIGHUP 重載信號，它也只是重新讀取舊檔案。這意味著 Day 25 設定的 EolTextfileStale Inhibit 規則在此之前從未真正生效！

解法：重啟 Alertmanager 容器重新綁定 Inode。後續版本將全數改為「掛載目錄」而非掛載單一檔案，以徹底規避此機制陷阱。

六、技術債清償：歷史變更回頭補單

引進健全體系的第一天，必須先面對過去欠下的技術債。將前幾天文章中執行的重要改動，全面補發變更單並鎖定為 done 狀態：

在補寫 CR-2026-0004 時，剛好也深刻反省 XD，因為 Day 24 的改動若遺漏了 error-allow 選項，整個內網的連外網頁將全數中斷。這種錯一個參數就全滅的變更，當時理應被標註為 risk: high 並具備嚴謹的維護窗與回退策略。補單不是形式主義，而是強迫我重新用風險思維審視過去的每一個決定或按下的enter。

七、變更管理的黃金法則

在本次實踐後，為地端環境立下幾條變更治理鐵則：

1. 拒絕流水帳：六大段落各自獨立。填不出來的段落，代表變更風險尚未被想透。
2. 禁止本地偷改：收集端僅唯讀拉取（git pull --ff-only），所有單據修改必須經由 Git PR。
3. 無例外條款濫用：團隊若有兩人以上，approval_exception 必須強制留空。
4. 禁止無限期 Silence：Silence 必須嚴格跟隨維護窗結束，長期風險接受（如 EOL）也必須設定定期覆核日。
5. 去識別化防護：變更單存放於公開 Repo，嚴禁夾帶密碼、金鑰、憑證與完整內網 IP。
6. 執行準備亦屬變更：執行變更所需的工具、權限與套件（例如本案的 sudo），必須提前包含在前置驗證或獨立變更中，避免窗外的臨時搶修。

實作操作指南：怎麼跑？

1. 建立並提交變更單

git clone https://github.com/ivanusto/onprem-changes && cd onprem-changes
cp changes/TEMPLATE.md changes/CR-2026-0007-<slug>.md
$EDITOR changes/CR-2026-0007-<slug>.md

# 本地驗證（校驗語法、格式與資產清單引用）
python3 scripts/check.py --assets ../onprem-metrics/eol/assets.tsv
python3 scripts/render.py

# 發起 PR
git checkout -b CR-2026-0007
git add -A && git commit -m "CR-2026-0007: <title> (draft)"
git push -u origin HEAD

2. 收集端初始化（單次配置）

sudo install -d -o metrics -g metrics /opt/onprem-changes /var/lib/onprem-changes
sudo -u metrics git clone https://github.com/ivanusto/onprem-changes /opt/onprem-changes

# 配置具備 Editor 角色的 Grafana Token
sudo install -d -m 0755 /etc/onprem-changes
sudo install -m 0600 -o metrics grafana.token /etc/onprem-changes/grafana.token

# 安裝 Cron 排程與確認 amtool 存在於本機
sudo install -m 0644 /opt/onprem-changes/collector.cron /etc/cron.d/onprem-changes
command -v amtool || echo "amtool 必須安裝於宿主機 /usr/local/bin"

3. 變更執行當日

# 1. 宣告變更開始（自動寫入日誌、打 Grafana 註記、開啟 Silence）
sudo -u metrics /opt/onprem-changes/scripts/change-mark.sh begin CR-2026-0007
# (至 Repo 將狀態改為 in_progress 並 commit)

# 2. 依變更步驟執行生產作業...

# 3. 宣告變更結束（自動結束註記、關閉 Silence）
sudo -u metrics /opt/onprem-changes/scripts/change-mark.sh end CR-2026-0007
# (至 Repo 填寫「紀錄」章節、狀態改為 done 並 commit)

結語與明天預告

今天把「變更管理」從企業管理口號，實體化為工程師熟悉的 GitOps 工作流、日誌標記與可觀測性閉環。每一次進入機房或敲下 sudo，不再是隨性而為的探險，而是一次受到監控防護網保護、進退有據的標準作業。

然而，今天的單子記錄的是「人自稱做了什麼」。
在零信任與合規稽核的世界裡，稽核員更相信「機器記錄你做了什麼」。

明天 Day 27，將探討稽核軌跡（Audit Trail）：
整合 FortiGate 的設定變更事件（type="event"）、PVE 虛擬化平台與 QNAP NAS 的管理動作日誌，以及 Linux 主機的 sudo 提權審計，全數接入 VictoriaLogs 日誌管線，並與今天的變更單自動比對——任何沒單子的敲擊，都將無所遁形。

參考資料

• Debian 13 Release Notes, Chapter 4 Upgrades from Debian 12 兩階段升級的順序、sources 的改法、apt modernize-sources
• Proxmox VE 文件 Cluster Manager, Corosync External Vote Support pvecm qdevice setup 與 remove
• pve-qdevice-on-qnap Day 15 的 VM 設定與四個演練
• Grafana HTTP API, Annotations POST /api/annotations、PATCH /api/annotations/:id、service account token
• Grafana 文件 Roles and permissions OSS 的 Viewer、Editor、Admin 基本角色
• Alertmanager, amtool silence silence add --end、silence expire
• GitHub Docs, About protected branches 要求 review、不能自審、禁止 force push、管理員略過
• Prometheus 文件 Unit testing rules
• ISO/IEC 27001:2022 Annex A 8.32 Change management 控制措施的要求

Day 1｜系列規劃與場域總覽：從跑得起來到可長期維運，先談為什麼要封裝
Day 2｜Container Station 薄殼架構：QPKG 骨架、生命週期腳本與狀態頁
Day 3｜版本鎖定與供應鏈：image digest、SHA256SUMS 與授權檔
Day 4｜GitHub Actions 自動打包與 release：從 git tag 到可驗證的套件
Day 5｜案例 Jellyfin 與 Roon：硬體轉碼的裝置直通與主機網路
Day 6｜案例 changedetection.io 與 Homepage：資安與資訊公告監看 + 整合入口
Day 7｜在地自建 ComfyUI 的生存指南：自建 Image 鎖定、GPU 直通與三層目錄架構
Day 8｜案例實戰：Open WebUI + Ollama 重構記，把專案回到通用框架會省下什麼呢？
Day 9｜容量規劃：用模型與硬體搭配矩陣決定地端節點與儲存規格
Day 10｜上游引擎一改版，地端 AI 環境用的配方壞了怎麼辦 ? patch 移植實戰紀錄
Day 11｜DGX Spark 節點基線：DGX OS 初始設定、帳號與 SSH 加固
Day 12｜熱與統一記憶體守護：取樣器、自動降載與長時間負載實測
Day 13｜別讓節點踩爆模型！NFS 集中模型庫的單寫多讀、權限凍結與完整性治理
Day 14｜儲存規劃與路徑實測：RAID 60 與 RAIDZ2 試算，SSD、NFS、iSCSI 載入時間解析
Day 15｜Proxmox VE 雙節點 HA：Virtualization Station 上的 QDevice
Day 16｜Proxmox VE 備份與還原：HDP for Business Beta 的排程、保留與還原演練
Day 17｜儲存設備備份策略與還原演練：快照、HBS 3 與 3-2-1 備份策略
Day 18｜3-2-1 的最後一步：異地物件儲存、保留政策與冷熱資料成本精算
Day 19｜指標收集：把前十八天的取樣器接進同一個時間序列
Day 20｜儀表板與告警，打造一個簡潔的單一面板
Day 21｜日誌集中與保存：節點不裝新代理，封存要能比對
Day 22｜被擋下的封包才是便宜情報：從防火牆靜默盲點到日誌降噪與自動化告警
Day 23｜日誌找不到原因？從 tcpdump 最小權限封包擷取到 WORM 封存的網路排錯實戰
Day 24｜稽核問「某台工作站上個月連到哪裡了」？FortiGate AUP 雙軌日誌實踐：線上 LogsQL 檢索與離線對帳修煉
Day 25｜資產生命週期與授權 EOL 監看：到期日只是一個數字，通通收進 Prometheus 時間序列！
Day 26｜變更管理實戰：串起 Git 變更單、監控與日誌，讓每次改動都有跡可循
Day 27｜自動化稽核比對：當機器留下的日誌，對上工程師寫的變更單（VictoriaLogs × FortiGate × PVE）
Day 28｜Rollback 實戰演練：沒真正執行過的復原步驟，永遠只是一場美麗的假設
Day 29｜打造地端維運的 AI 圍欄：Agent 授權閘道實作，無工單即無工具，無核准即無不可逆變更
Day 30｜完賽總結｜算清一年的電費、硬體折舊與雲端代價：地端 AI 維運 30 天留下的真實資產