Weekly Issue 第 15 期：Go 語言從 1.25 支援 Flight Recorder

最近安排旅遊計畫，會到 Brisbane 居住三個月，突然跟熟悉的環境分開，用陌生眼光看待周圍一切，真是個特別的體驗。

世界依然在轉動，只是用了不同速度，反映在每週週報上，是項目變少了，可是內容變長了。

🗞️ 熱門新聞

Flight Recorder in Go 1.25

Go 1.25 開始支援 Flight Recorder。

以前要抓 trace，都是要等到事發後才能抓，有沒有可能事發前抓呢？有，原理很簡單，配置一塊記憶體存放臨時的 trace，如果符合條件，輸出持久化，否則丟棄，這就是 Flight Recorder。

官方給的範例很讚，像 slow request 這類例子，常常是處理 request 時遇到問題，在沒有 Flight Recorder 的情況下，要處理只能把該端點的 request 都抓起來，或者給定一段時間持續記錄。現在可以精準打擊了。

✨ 科技觀點

The rise of async programming

由 LLM 來寫程式，人類來審查，好像慢慢成為一種模式，但「唯有在無需手動測試每個邊緣案例的情況下驗證結果，非同步程式設計才能發揮作用。」

文中講的「自動化驗證」對我來說特別有意義，如果沒有測試保護，沒有基準驗證，沒有自動格式化，組織就還沒有進到 AI Ready 的狀態。

這跟 DevOps 同樣，為什麼 DevOps 常常從 CI/CD 談起？不是只有 CI/CD 才是 DevOps，而是連 CI/CD 都沒有的情況下，真的很難建立開發與維運協作的文化。

The Beauty of Programming

Linus Torvalds 談他眼中的 Programming。

「至今仍難以解釋，為何連續三天絞盡腦汁卻仍找不到更優雅、更漂亮的解決方法，這件事本身竟能如此令人著迷。但一旦你找到了那個方法，那將會是世界上最棒的感覺。」

這段讓我想起 Nabokov 談小說藝術：「這種舒暢一旦被感覺到，就會令人意識到，儘管生活中有各種各樣的跌跌撞撞和愚笨可笑的錯誤，生活內在的本質大概也同樣是靈感與精緻。」

有次跟朋友聊到，Programming 在生活中主要還是扮演創造收入的角色，但是，真正驅動我投入其中的，是偶爾在其中會看到的發光時刻。

Why we trust strangers’ open source more than our colleagues’

看到個有趣的問題：為什麼我們信任陌生人的開源專案勝過同事？

第一直覺是想「有嗎？」後來轉念想，如果不是以認識與否來判斷，我的標準是什麼？

通常會看專案是否持續更新、有沒有積極處理 issues、還有 contributor 的數量、以及這個專案是否夠成熟。如果這些點沒有滿足，用起來還是會怕，畢竟不知道是否哪天會 OOM 或洩漏我的資料。

Seeing like a software company

有段時間一直在糾結個問題：「如何衡量不同職能的貢獻呢？」

最簡單是看營收，例如業務成交量，你賺多少錢就是多少貢獻，但依照這觀點，客服或研發部門應該當成本單位嗎？如果真這樣想，通常公司也差不多了。

另個講法是用「目標導向」來衡量，只是實施中仍然容易有各種問題，最關鍵的是，當要衡量，就需要量化，需要具有 legibility。而 legibility 是資源管理的基礎，它跟對客戶的承諾結合在一起。

很喜歡這篇文章的觀點，與其說是管理，不如說是歷史。「可辨識的機制確實重要，它能讓組織完成原本不可能的事……但不可辨識的面向同樣關鍵，它能實現高效工作、為不合時宜的流程提供調節閥，並滿足人類天生對閒話交流與柔性共識的渴望。 」

📌 工程實務

Retrospective of September 25th go.opentelemetry.io incident

Otel 發表了一篇事故報告，跟 CAA Record 有關。

事故原因是 OpenTelemetry 根網域沒有 CAA Record，資安人員通知他們應該加上，但是呢，如果你加上了 CAA Record，沒在紀錄中的 CA 就不能簽發憑證（這就是加上的目的），所以憑證過期後，原本憑證無法更新，事故就發生了。

這篇很接近我理想中的報告，特別是 Lessons learned，點明「我們對於應用程式運行的平台知識有所不足，導致這次事件持續時間超出應有範圍 」，修改的人不知道影響範圍，也沒確認 AppEngine 的 CA，屬於 Domain Knowledge 問題。這是應該讓整個團隊都要學習的點。

Otel 處理方式也很俐落，他們將 AppEngine 遷移到 Netlify，統一使用的平台。前篇說到我不贊成完全讓團隊自行選型，原因就有維護問題，如果一開始全用 Netlify，應該能避免這個事故，即使發生了，處理起來也會更簡單。

Grafana, Loki, and Tempo will be relicensed to AGPLv3

看了看 Grafana 從 Apache 2.0 改為 AGPL v3 的說明，相對單純的營利組織，Grafana 的立場更傾向貢獻這端－－你只要願意貢獻源碼，Grafana 不禁止用途。

在另一篇文中，立場表達更明確「當你使用的授權許可並未被 OSI 接受時，很難聲稱自己是一家開源公司。」Mongodb 在這點上就閃爍得多。