AAI Internal Wiki

Software DevOps — 我學到了什麼

閱讀時間約 18 分鐘

Software DevOps — 我學到了什麼

這裡記錄我在「Codex / Vercel / OpenClaw / Claude Code / GitHub / 工具鏈 / 部署」累積的學習。 每段話末尾的 [📎 source] 可反查到原始 obs / insight / memory / AAI wiki。

為什麼這個 topic 存在

(待累積足夠材料後人工撰寫；目前先 append 每日 delta)

每日累積

2026-05-02（2 段，10 個引用 source）

☕ 今天的共同線索很簡單：software-devops 看起來是在追求更快的 build、更聰明的 agent、更漂亮的自動化；但真正讓系統可靠的，常常是那些很樸素的東西：路由不要曖昧、狀態要記得住、工具壞掉時要有備胎。

一、部署速度不再等同於成熟度，真正的成熟是系統知道每個請求該走哪一扇門

今天最有趣的反差，是同一套部署故事裡同時出現「非常順」和「完全卡住」。一邊，Vercel pipeline 可以把 hero image 更新從 git push 推到 production，build 維持在 30-31 秒，整個 commit 到上線大約 5 分鐘；另一邊，AAI portal 想重新部署 whitelist 環境變數時，卻被 Next.js 的 routing conflict 擋下來，因為同一層同時有 [slug] 和 [[...path]]，就像診間櫃台同時開了「指定醫師門診」和「所有剩下都來這裡」兩個窗口，病人一進門，系統反而不知道該派到哪裡。這裡的主角不是 CI/CD（Continuous Integration/Continuous Deployment，就是從 commit、build 到 production 的自動交付鏈），而是 routing specificity（路由特異性，就是框架判斷哪條路徑比較精準的規則）。快，毫無疑問很重要；但如果入口規則本身模糊，30 秒 build 也只是在很快地失敗。

真正的轉折，是後來 auth-gated wiki viewer 沒有硬追最複雜的 proxy 架構，而是改採比較務實的 iframe wrapper，移除 abandoned route 後，35 秒內推到 production，讓 5 個 wiki 都可以透過 /internal/wiki/{slug} 進 Portal、再做 server-side OAuth 與 whitelist 檢查。這不再等同於「我們找到一個聰明 workaround」，而是更像急診分流：先把入口整理清楚，病人才有辦法被正確送到後面流程。Quartz 那邊也呼應同一件事：618 個 source files 生成 1769 個 static files，用 41 秒 emission 完成更新 index，之所以能快，是因為 pipeline 的每一步都有清楚邊界。這同 dynamics 也見於醫療流程設計：手術室 turnover 要快，前提不是每個人跑更快，而是病人、器械、麻醉、病理標本各自有清楚去向。

📎 sources: obs-64731 · obs-64825 · obs-64831 · obs-64810 📚 references:

  • Parnas, D. L. (1972) “On the Criteria To Be Used in Decomposing Systems into Modules”. Communications of the ACM 15(12):1053-1058.
  • Brooks, F. P. (1975) The Mythical Man-Month. Addison-Wesley.
  • Humble, J. and Farley, D. (2010) Continuous Delivery. Addison-Wesley.
  • Beyer, B., Jones, C., Petoff, J., and Murphy, N. R. (2016) Site Reliability Engineering. O’Reilly Media.

二、自動化不是把工作丟出去，而是讓系統在沒人盯著時仍然知道自己在做什麼

另一條線索比較像家裡裝自動咖啡機：按一下會出咖啡很帥，但真正有用的是它知道豆子快沒了、今天有沒有清過、出問題時會不會提醒你。RHT budget monitoring 一開始用 background agent 追 May 4 之後紐約州 budget、additional extender、RHT RFP 與官方說法，後來又升級成每天 9:07 AM 跑的 durable cron job，會查 budget 與 RFP、比較前後狀態、寄出繁體中文 email，重大事件還會在 subject 裡加 alert。這裡的概念不是 agent delegation（把一段可獨立完成的工作交給 agent），而是 durable automation（跨 session、跨重啟仍能持續跑的自動化）。只要監控對象是 $212M funding distribution 這種會被政治時程卡住的事情，人工偶爾查一次就不再夠；系統必須替人保留注意力。

可是同一天也提醒我們，自動化最怕的是「看起來會跑，其實少了一個螺絲」。system monitor 因為 CODEX_HOME 沒設，找不到 $CODEX_HOME/automations/automation/memory.md，所以可以做 disk check，卻不能和歷史 baseline 比較；opencli 一度不可用，後來又變成可用但噴出大量 YAML deprecation warnings，最後仍要靠 WebSearch 和 Firecrawl fallback；sub-agent 查 database 更戲劇化，76 次 sqlite3 CLI round-trip 花了 589 秒，而真正 query 每次不到 100ms，瓶頸根本不是 database，是每次都要模型推理和 permission check。這毫無疑問把 observability（可觀測性，就是系統把自己的狀態講清楚）和 batching（批次化，把很多小動作合成一次做）推到主角位置：沒有 memory，監控就失明；沒有 fallback，工具偏好只是願望；沒有 batching，快的 database 也會被慢的對話迴圈拖垮。同 dynamics 也見於臨床追蹤：病人回診不是只有抽血那一刻，真正可靠的是 baseline、異常通知、備援聯絡方式和一次看懂趨勢的摘要。

📎 sources: obs-64781 · obs-64799 · obs-64840 · obs-64861 · obs-64867 · obs-64884 📚 references:

  • Goodhart, C. A. E. (1975) “Problems of Monetary Management: The U.K. Experience”. Papers in Monetary Economics 1.
  • Campbell, D. T. (1979) “Assessing the Impact of Planned Social Change”. Evaluation and Program Planning 2(1):67-90.
  • Kahneman, D. (2011) Thinking, Fast and Slow. Farrar, Straus and Giroux.
  • Beyer, B., Jones, C., Petoff, J., and Murphy, N. R. (2016) Site Reliability Engineering. O’Reilly Media.

2026-05-03（2 段，9 個引用 source）

☕ 今天的共同線索是：DevOps 看起來像是在寫腳本、接部署、換模型，但真正決定系統能不能自己活下去的，常常是三件很日常的事：鑰匙放哪裡、門禁怎麼管、帳單誰付。

一、自動化不是會自己跑就好，它還要記得昨天發生過什麼

今天最像 coffee 聊到一半突然拍桌的發現，是 disk monitoring automation 一開始不是壞在 scan，也不是壞在資料量，而是壞在一個空掉的 CODEX_HOME。系統想讀 $CODEX_HOME/automations/automation/memory.md，拿昨天和前天的 baseline 來比今天的目錄變化；結果環境變數是空字串，mkdir 直接跑去 root filesystem 想建 /automations，被 read-only permissions 擋下來。這裡的主角不是 automation（自動化，就是讓工作不用每次靠人工手動跑），而是 state（狀態，就是系統記得自己以前看過什麼）。沒有 state 的自動化，就像每天量體重但從不記錄昨天幾公斤：數字看起來很精準，判讀其實很盲。

有趣的是，修法也不是什麼豪華架構，而是回到很樸素的找鑰匙邏輯：既然 CODEX_HOME 沒有講，就去 ~/.codex 找，最後找回 /Users/lunhsiangyuan/.codex/automations/automation/memory.md，裡面有 8 次 monitoring sessions，從 2026-05-01 21:51 到 2026-05-02 11:03 CST，包含 MacBook Pro 從 259 GiB 降到 212 GiB、CloudDocs/session 清掉 44.7 GiB、mac-mini 的 Homebrew cache 從 2.8G 到 53M。這毫無疑問說明 observability（可觀測性，就是系統把自己的狀態講清楚）不再等同於「今天印出一份報告」；它更像門診追蹤，重點是看趨勢、看新長出的東西、看風險是不是在爬坡。同 dynamics 也見於腫瘤追蹤：單次影像有價值，但真正讓醫師安心或警覺的，是前後片放在一起看。

📎 sources: obs-64915 · obs-64916 📚 references:

  • Beyer, B., Jones, C., Petoff, J., and Murphy, N. R. (2016) Site Reliability Engineering. O’Reilly Media.
  • Kleppmann, M. (2017) Designing Data-Intensive Applications. O’Reilly Media.
  • Tversky, A. and Kahneman, D. (1974) “Judgment under Uncertainty: Heuristics and Biases”. Science 185(4157):1124-1131.

二、把流程做成一條路之後，真正難的是知道哪段該省、哪段不能省

另一條線索，是 Alfred Brain 和 AAI Wiki 的部署故事看起來一路順，但順到最後反而把 trade-off 端上桌。先檢查基礎設施時，AAI Wiki 已經是 Quartz static site generator 接 Vercel，content/ 可以放 markdown，quartz.config.ts 和 quartz.layout.ts 管知識庫外觀與生成；可是 repo 裡沒有 middleware 或 auth config，代表 alfred-brain 的保護要自己補。接著又發現專案沒有 Git remote，自動部署不是 GitHub push 觸發，而是靠 vercel CLI 手動送；最近幾次 content deployment 大約 2 分鐘完成。最關鍵的是 Hobby plan 沒有 Vercel Password Protection 和 SSO Protection，這毫無疑問讓 deployment pipeline（部署管線，就是內容從本地、驗證、複製到 production 的路徑）不再等同於「能上線」；它還要回答「上線後誰看得到」。

後面 pipeline 變得很完整：Alfred Brain hub 真的上到 https://aai-internal-wiki.vercel.app/alfred-brain/，root、hub、medical-oncology 三個 URL 都回 HTTP 200；Stage 4 又多了 04-synthesize-codex.sh，用 codex gpt-5.5 做長文 synthesis，Stage 5 的 05-validate-store.ts 負責 citation validation、provenance tracking、多目標部署和 archive。可是最反直覺的地方在成本：software-devops synthesis 用 codex gpt-5.5 消耗 52,618 tokens，Haiku 類似輸出只用 713 tokens，三個 topic 平行跑總共 140,954 tokens。這不是「哪個模型比較厲害」的比賽，而是 cost-aware architecture（有成本感的架構，就是把錢、token、人工注意力都當成系統資源）開始說話：外部處理比較穩、比較省 Claude session tokens，但它不是免費午餐。同 dynamics 也見於醫院流程：檢查排得出去只是第一步，接下來還要問健保、感染管制、病人隱私和人力成本能不能撐住。

📎 sources: obs-65022 · obs-65026 · obs-65031 · obs-65042 · obs-65051 · obs-65060 · obs-65061 📚 references:

  • Humble, J. and Farley, D. (2010) Continuous Delivery. Addison-Wesley.
  • Parnas, D. L. (1972) “On the Criteria To Be Used in Decomposing Systems into Modules”. Communications of the ACM 15(12):1053-1058.
  • Saltzer, J. H. and Schroeder, M. D. (1975) “The Protection of Information in Computer Systems”. Proceedings of the IEEE 63(9):1278-1308.
  • Goodhart, C. A. E. (1975) “Problems of Monetary Management: The U.K. Experience”. Papers in Monetary Economics 1.

🔗 延伸：Software DevOps

2026-05-04（2 段，10 個引用 source）

今天的共同線索是：DevOps 的成熟不只是把更多工作交給 agent，而是讓每個自動化流程都知道「我該去哪裡找記憶、我該把輸入輸出交給誰、我壞掉時會留下什麼線索」。

一、自動化沒有記憶，就只是每天很勤勞地重新失明一次

今天最值得記下來的，不是 disk monitor 有沒有成功掃完，而是它一開始連自己的日記放在哪裡都不知道。系統原本去找 $CODEX_HOME/automations/automation/memory.md，但 CODEX_HOME 在這台機器上是空的；後來用 $HOME/.codex/automations/automation/memory.md 才找到真正的檔案，裡面保留了 2026-05-01 到 2026-05-03 的 disk monitoring 歷史、baseline、cleanup 與 trend analysis。這裡的主角是 state（系統狀態，就是機器記得昨天發生過什麼），不是 scan 本身。沒有 state 的自動化，就像每天量血壓卻每次都把前一天的紀錄撕掉：今天的數字看起來精準，但你完全不知道它是在改善、惡化，還是只是測量角度變了。

這毫無疑問把 observability（可觀測性，就是系統把自己的狀態講清楚） 推到比「會跑」更前面的位置。自動化常常讓人有一種錯覺：只要 cron job、agent 或 script 被啟動，工作就算交代出去了；但真正可靠的流程，會先回答「我從哪裡讀 baseline」「我怎麼比對新舊結果」「環境變數缺席時我有沒有合理 fallback」。Goodhart 1975 講 KPI 會被拿來鑽空子，Campbell 1979 也提醒測量一旦變成管理目標就會變形；放到這裡，就是你若只看「今天有沒有跑」，自動化會越來越擅長回報一個空洞的成功。這同 dynamics 也見於臨床追蹤：單次 PSA 或 creatinine 有價值，但真正讓醫師能判斷風險的，是前後趨勢、採檢條件與異常時的回報路徑。

📎 sources: obs-65252 📚 references:

  • Beyer, B., Jones, C., Petoff, J., and Murphy, N. R. (2016) Site Reliability Engineering. O’Reilly Media.
  • Kleppmann, M. (2017) Designing Data-Intensive Applications. O’Reilly Media.
  • Goodhart, C. A. E. (1975) “Problems of Monetary Management: The U.K. Experience”. Papers in Monetary Economics 1.
  • Campbell, D. T. (1979) “Assessing the Impact of Planned Social Change”. Evaluation and Program Planning 2(1):67-90.

🔗 延伸：Software DevOps

二、生成管線不再等同於呼叫模型，成熟度藏在邊界、模板和 I/O 裡

另一條線索看起來比較分散：簡報生成、imagegen prompt file、learning anchors、v4 case report、codex synthesis job hang 住。但把它們放在一起看，今天真正出現的是一個更清楚的 generation pipeline（生成管線，就是從材料、模板、模型到輸出驗證的一條路）。Presentations plugin cache 裡已經有可程式化生成投影片的基礎設施，slideCover、slideSpine、metricRail 把版面組合和 text、rect、rule 這些 primitive 分開；image generation 也不是直接亂打 API，而是由 openai_generate_image.py 先寫出 .imagegen.txt prompt file，讓 JSON metadata、目標 output path、尺寸、品質和背景設定都留在 Codex agent 邊界內。這像廚房備料：厲害的主廚很重要，但如果砧板、食材標籤、出餐順序都混在一起，最後不是創意料理，而是每次靠運氣。

最戲劇化的證據，是同一套知識庫重建流程從 v3 learning anchors 推到 v4 case report，再到 validated/stored/deployed production，中間不是敗在「模型不會寫」，而是敗在背景 codex exec 卡在 stdin。4 個 topic 的 synthesis job 原本應該平行完成，卻累積到 10 個 codex process，log 一直停在 “Reading additional input from stdin…”；即使用 < /dev/null 重定向，後來還是出現所有 4 個 topic 又回到 stdin wait state 的矛盾。這毫無疑問說明 I/O contract（輸入輸出契約，就是程式彼此約定資料從哪裡進、從哪裡出、何時結束） 不再等同於小細節。當流程跨過 prep、delegation、validation、SQLite provenance、Vercel deployment，每一段都必須知道自己何時可以收工；否則模型已經寫出 5525、5179、5219 bytes 的 narrative，系統卻仍像電話掛在線上，沒有人敢說任務完成。

結論不是「不要用 agent」，而是 agentic workflow 要像手術團隊一樣分工：模板決定病例格式，script 決定誰拿器械，provenance database 決定標本怎麼追蹤，deployment 才是最後把病人推出恢復室。v3 的 4 topics、43 citations、production HTTP 200，v4 的 12 chunks、37 verified citations、AAI Wiki sync 和 .applied/ archive，都在證明同一件事：可教學的知識庫不是一次漂亮輸出，而是一條可以重跑、可追溯、會驗證的路。這同 dynamics 也見於研究資料管理：統計模型再好，如果 CRF、資料字典、audit trail 與輸出版本沒有接好，paper 寫得越快，越可能把錯誤帶進正式結論。

📎 sources: obs-65384 · obs-65416 · obs-65176 · obs-65191 · obs-65200 · obs-65208 · obs-65195 · obs-65210 · obs-65216 📚 references:

  • Parnas, D. L. (1972) “On the Criteria To Be Used in Decomposing Systems into Modules”. Communications of the ACM 15(12):1053-1058.
  • Humble, J. and Farley, D. (2010) Continuous Delivery. Addison-Wesley.
  • Brooks, F. P. (1975) The Mythical Man-Month. Addison-Wesley.
  • Saltzer, J. H. and Schroeder, M. D. (1975) “The Protection of Information in Computer Systems”. Proceedings of the IEEE 63(9):1278-1308.
  • Beyer, B., Jones, C., Petoff, J., and Murphy, N. R. (2016) Site Reliability Engineering. O’Reilly Media.

🔗 延伸：Software DevOps

[← 回 Alfred Brain Hub]

關係圖譜

反向連結