今天玩 Azure Function 玩太晚了，11:50 才想起來還沒寫推薦= = 果斷來轉貼一則小技巧
如何讓 Git 可以用一個 git push 同時推送到多個遠端儲存庫 - The Will Will Web

其中我個人最常用的就是這段推送到多個 Remote Repo 的部份：

有時候我們會需要一次推送變更到多個不同的 Git 遠端儲存庫，你其實可以設定一個 git push 命令就能同時推送到兩個不同的遠端儲存庫！

簡單來說就是先看一下 Repo 現在都抓了哪些遠端：

# git remote -v
origin  https://github.com/User/demo01.git (fetch)
origin  https://github.com/User/demo01.git (push)

然後用 git remote set-url 來把 push 時要推的遠端多設一組就好了～

git remote set-url --add --push origin https://github.com/User/demo01.git
git remote set-url --add --push origin https://github.com/User/demo02.git

ps. 記得原本的 origin 也要先設一次，養成良好習慣 :)

我體感上這個實用小技巧還蠻常(?)用到的啦，分享給大家

團隊這幾天有發生需要回顧的問題，馬上收到這篇。剛好拿出來推給各位朋朋：
Postmortem Culture: Learning from Failure - sre.google

The cost of failure is education.

什麼是事後檢討（Postmortem）？什麼時候要寫？

事後檢討就是在翻車之後，把「我們翻車了，翻了三圈半、我們都幹了些什麼來把車翻回來、到底為什麼會翻車、後續要怎麼避免翻車」等資訊記錄下來的東東。

The primary goals of writing a postmortem are to ensure that the incident is documented, that all contributing root cause(s) are well understood, and, especially, that effective preventive actions are put in place to reduce the likelihood and/or impact of recurrence.

寫一份事後檢討的主要目標是確保事件被記錄下來，所有貢獻的根本原因都被充分理解，尤其是要採取有效的預防措施來減少再次發生的可能性和/或影響。

那什麼時候會需要寫檢討？這篇文章列了幾個狀況：

• 一定比例的使用者不能使用
• 掉資料
• 工程師被叫去 on-call 退版
• 花了有夠解還沒處理完問題
• 監控整個失敗，拖到被人發現

無責任文化

既然都要寫檢討了，大多時候就是有事情搞砸了。為了不要讓寶貴的學習機會淪為情緒發洩和攻擊別人的場合，這篇文前半段就開始提了「無責任（Blameless）」

用我們比較熟悉的話來說，就是「對事不對人」，把目光放在「我們的服務哪些方面還可以改進」，藉此得到變得更強大的機會

從另一方面來說，如果放任大家互咬、培養出互相指責的扭曲文化，那很多問題就會被蓋牌，這樣其實更危險🤔

For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior.

為了使事後檢討是真正無責任（Blameless）的，它必須專注於確定事件的發生原因，而不指責任何個人或團隊的不良或不適當行為。

A blamelessly written postmortem assumes that everyone involved in an incident had good intentions and did the right thing with the information they had. If a culture of finger pointing and shaming individuals or teams for doing the “wrong” thing prevails, people will not bring issues to light for fear of punishment.

一份無責任的事後檢討假設參與事件的每個人都有良好的意圖，並根據他們所擁有的信息做出正確的決策。如果存在一種指責和羞辱個人或團隊做出“錯誤”決策的文化，人們將因為害怕受罰而不敢揭示問題。

補充：如果想要看一些反例，可以讀前陣子的這篇〈迷失在阿里雲的年輕人〉裡
「濫用的 Code Review 和故障復盤」這一小節。

事後檢討的審查標準

寫完檢討書 v1 之後，會先在團隊內請資深工程師幫看一下 O 不 OK。要看的點有：

• 相關的資料有沒有被收集起來給後人參考？
• 影響評估有沒有完整？
• 根本原因的分析有沒有足夠深入了？
• 後續的行動計劃和修復工作都列好了嗎？有排好優先順序了嗎？
• 我們有沒有跟利害關係人（stakeholders）說過結果了？

都搞定之後就可以開始散佈出去了，希望其他人能從我們翻車的姿態中學會教訓。

Wheel of Misfortune!

這句有點咒語的 Feel，不知道怎麼翻，「衰鬼之輪」嗎？

後半段一些文化相關的東西，像是讀書會、每月檢討等等的都很平常，但這個輪子還蠻有趣的

基本上就是大家（抓著新來的菜鳥 SRE）一起，把過去的某次事故報告給調出來，現場就開始當劇本來跑團：

New SREs are often treated to the Wheel of Misfortune exercise (see Disaster Role Playing), in which a previous postmortem is reenacted with a cast of engineers playing roles as laid out in the postmortem. The original incident commander attends to help make the experience as “real” as possible.

新進的 SRE（網站可靠性工程師）通常會參與「厄運之輪」的練習（參見災難角色扮演），在這個練習中，以前的事故回顧會被重新演繹，工程師們扮演著事故回顧中所規定的角色。原始的指揮官也會參與其中，以盡可能使體驗更加「真實」。

事故還可以放個幾年之後拿出來當桌遊(?)，有種挺歡樂的感覺。這樣我很願意好好寫檢討書耶 xD

今天嘗試用新的格式來推薦，本來想說看能不能縮短每次整理心得的時間

不過反正每次要打利害關係人，都會打成厲害關西人，選字的時間就比縮短的時間久了，根本沒差= =

今天朋友丟了卡米哥大大的另一篇文章給我，立馬選擇轉貼上來：
軟體開發者的價值 - 卡米哥

身為一個軟體開發者，我一直以來都想知道我的價值到底在那裡。在我長期的觀察和思考，終於有了一個初步的答案，若站在老闆的角度來看，我的價值其實就是我寫下來的程式碼總共幫老闆賺了多少錢。

因為老闆僱用你，就是希望你可以幫他打造一台自動賺錢機器，然後靠機器運轉來達成自動賺錢。若要深入探討的話，我想先談談什麼是價值，以及什麼是程式語言，從思考一行程式的價值開始，到思考軟體開發者的價值。

從這個出發點開始，作者大大一路思考：什麼是價值？什麼是程式語言？程式的價值呢？開發者的價值呢？

其中一個思路我覺得不錯，那就是「程式的價值 = 執行次數 * 執行一次生成的平均價值」，
也就是說：程式執行是會賺錢的（當然有些程式的價值可能是負的 xD）

而我們軟體開發者，就需要運用技術力來讓程式能夠繼續跑下去、繼續賺更多錢。
所以，開發者提升開發速度、提升程式碼品質等等，都是在提高讓程式能繼續跳表(?)的戰力

這個觀點也能夠解釋為什麼我們應該追求上一篇文章提到的那些價值觀（程式碼品質、維護成本、修改成本等等），因為這些都影響了我們產出的價值

此外，還有幾個我特別標記的點。其中一項就是關於技術債的部份：

在我之前的工作經歷當中，大部分時間是在做新創公司的案子，而新創公司的客戶數通常趨近於零，我曾經開發並且上線一個新的網站，卻始終沒有用戶真的去使用，經營了一兩年，結果測試環境上的資料還比正式環境上的還多，在這種情況下，即便程式的效能再好，沒人來使用的網站所產生的價值其實是趨近於零。

= 沒有人在用的程式，產值是零

當時是案主付錢委託我們開發網站，所以我們有收到錢，只是網站並沒有替案主賺到錢。我們採用的技術很好，自動測試也寫的很完整，卻做出了一個垃圾，而在此同時，我接了另一個案子的長期維護，這個專案裡程式的架構很亂，欠了一堆技術債，而且都沒寫測試，但是客戶人數足夠而且一直有下訂單，所以反而這個案子就有在賺錢。

= 即便是充滿技術債的程式也能產生價值

我發現像我這樣的菜鳥常常會有一種迷思：這專案的技術債有夠多！真沒價值！

但不是這樣的，並不是臭不臭就可以斷定程式的價值。只要這個專案還是收入來源，它其實就還在產生價值。你養蟲，蟲也養你

就像泳池的收入並不是取決於裡面的尿多不多，而是進來游的人多不多嘛

而我們的目標就是用我們的技術力和解決問題的能力，替它排除更多的障礙、讓它繼續產生價值，然後把錢帶回來給我們(?)

那如果我們做不到呢？例如上頭就是想要你寫一些沒人用的東西？

雖然你在一家公司內可能不能決定要寫什麼程式，但你可以選擇要去哪一家公司寫程式，去能被執行最多次，且單次執行所生成價值最高的專案寫程式，則可以最大化自己的價值。

沒錯！是時候歡迎我們 2/27 推薦過的這篇「上游思維」的結論：

1. Change your company, or
2. Change your company.

那麼，今天的轉貼就到這邊，明天見～

收假前來看點故事吧，今天要推薦的是這篇：
軟體開發者的培養 - 卡米哥

這篇的主軸圍繞在作者 20 年來的學習歷程，以及過程中培養的各項價值觀

從剛入門大家都有過的「寫了能跑、越短越好」開始，隨著問題越來越難、越複雜，也開始有了效能、可讀性、可維護性等等的考量

作者很貼心的把培養出來的這些價值觀分項列點地說明。推薦大家直接過去看原文，段落明確，說明清晰，值得收藏

但因為我畫的重點太多了（老毛病），多到沒辦法直接整車拉過來，因此今天也按照慣例，簡單粗暴地列一下內容收進我的筆記庫就好

程式碼執行成本（效能）

要處理的資料量變大了，程式寫爛了要跑半天了，得開始重視效能
➡️ 學習資料結構和演算法，辨別程式執行時間和實作方案的優劣

程式碼修改成本（可維護性）

專案開始被改來改去了，每次修改都要花成本
➡️ 如果能讓修改更方便快速，那當然就可以增加產能
➡️ 需要版本控制，以及改用能夠抽換實作的寫法

程式碼理解成本（可讀性）

改東西的時候會因為程式碼太亂，光是讀懂就花了大量時間
➡️ 專案規模越來越大，要讀的東西也越來越多，花的時間也越來越長
➡️ 只能動手整理程式碼，開始乖乖拆模組、好好取名等等

（作者推薦看怦然心動的人生整理魔法，我也有點怦然心動）

程式碼彈性

開始觀察需求的生長方向來留擴充點，使用物件導向原則和設計模式來保留彈性

（我個人感覺有點像是可維護性的延伸議題，而且我還菜，有時會分不出來彈性和過度設計 QQ）

程式碼測試成本

重構（作者很誠實，他寫「重寫」）的時候很容易改壞之前寫好的部分
➡️ 專案規模越大也就代表測試成本越高
➡️ 需要開始碰自動化測試了

保留修改權、保留反悔權

如果面臨兩個解決方案，想一想：

• 選擇某個方案之後，要再進一步修改的成本有多高？
• 選擇某個方案之後，想反悔了改成另一個方案的成本有多高？

例如修改變數名稱的成本遠低於修改 DB 的欄位；或是存圖片的時候先保存完整圖片，把真的效能炸裂的時候換成保存壓縮後圖片的選項保留起來等等

總之就是：避免做出悔不當初的選擇

學習前人經驗

有一句我覺得作者講得挺好，切中我心，直接轉上來

一開始會以為只會用套件做東西的人很弱，能自己實作才強，但現在完全不會這樣想。 只會靠自己累積經驗的學習方式最慢，能吸收他人經驗來加速學習，才能站在巨人的肩膀上。

前面列了蠻多價值觀的，那如果這些價值觀衝突了呢？

這時候就要根據情況對價值觀進行優先度的排序：

在不同的情況下，價值觀的優先序也會跟著不同，例如開發完成就不會再增加需求的小專案就不需要考慮修改成本。

價值觀的篇幅結束了之後，作者還談了一些通靈能力、協作能力的部分。例如多人開發的時候，就像同居時每個室友對乾淨的看法不同，勢必要先喬好，最好能留下規約，把髒亂的環境打掃成乾淨的環境

但因為我信奉的是游泳池原則（軟體專案就像游泳池，每個人都會在裡面尿尿），所以就不特別截了。

只是最後有一段讓我有被打到的港覺：

身為資深軟體開發者，應該要有能力培養技術等級低的開發者，而不是排擠或邊緣化他們。一個有能力培養新進開發者的資深開發者是更有價值的。在遊戲裡，30% 團隊戰鬥力加成的靈氣，通常是很強的技能。

要是我們整隊都有 30% 靈氣還能疊加該有多強啊！這也許正是現在的我所缺少的。特別筆記下來。

真的很喜歡看這些前輩們的觀念文或經驗談，感覺像是窺見前輩們思考裡的其中一角，正在挖的大泥球都變香了呢

那麼，今天的轉貼就到這邊，我們明天見～

前兩天跟朋友聊到 User Story，馬上翻出之前收藏的這篇：
打翻咖啡不能解決問題，談 User Story - 嫁給 RD 的 UI Designer

我們先簡單地認識一下 User Story：
「我是 囗囗囗，我需要一個方法來幫助我 囗囗囗，這樣我就能 囗囗囗」

例如說「我是工程師，我需要一個方法來減少參與沒卵用的會議，這樣我就能專心開發」(?)

有了這個 User Story 香香東西，我們大家就可以先對焦好需求，再來討論解決方案

備註：對 User Story 想進一步了解的朋友，可以參考這篇：產品管理流程中，使用者故事（User Story）常見的三種使用情境 - Anne Hsiao

而今天要推薦的這篇，就是用非常精準的方式告訴你
「當 User Story 寫歪的時候」會有什麼結果：

A. 我想要抽菸。
B. 我是疲倦想睡覺的上班族，想要提神。
C. 我是疲倦想睡覺的工程師，想要提神，好讓我能專心認真寫程式。

句型分析：
Ａ句是業界最常見寫法，不知道使用者是誰、也不知道為啥要做這件事，只講了「功能」，然後就要開工。
Ｂ句稍微好一些，勉強能猜測是誰要做這件事，功能開發出來要給誰用，猜歪的機率不低。
Ｃ句完整地說明是誰、想要做什麼、做這事的動機，腦海裡浮現的會是創意而不是創傷。

上面的例子中，A 的場景粗暴，什麼資訊都沒有，只能通靈
（之前遇過更扯的，投影片丟出來啥也沒解釋，馬上就開始問功能什麼時候會做好）

如果你習慣用 A 句和專案成員討論功能，恭喜你，改來改去的日子永無止境，絕對是一條邁向通靈王的偉大航道。而且這條道路註定是孤獨的，同事都會討厭你。

而 B 雖然抓到場景了，但是非常容易翻車。
畢竟，如果你只是想提神，那打翻咖啡的確比喝咖啡更加提神，對吧？

如果你習慣用 B 句和專案成員討論功能，那你會得到一杯咖啡然後被當面打翻它。沒錯啊～打翻咖啡超級提神！絕對比只給你一杯咖啡更有效，絕對能超越競品，使用者肯定超喜歡的！

所以，從這杯咖啡中我們可以學到：即使不是撰寫 User Story，
討論需求時仍然要注意「使用者、情境、需求、動機」這些必要資訊，才更有機會有效溝通。

否則，我們就只能邊通靈邊倒咖啡了 xD

今天想轉貼有香香動畫(?)的科普文： Load Balancing - Sam Rose

這篇文章用了簡單的動畫，讓讀者能直觀地了解當下 Request 的傳送狀況（看著球被丟給伺服器，意外地蠻療癒的）

從最簡單的 1 個來源發送給 1 台伺服器（=只要一直把球丟過去給伺服器就好）開始

接著，伺服器開始吃不下了。我們想要增加伺服器數量，但就需要把 Request 分配給他們兩台伺服器，這時候最簡單粗暴的做法就是輪詢（=輪流發球給他們）

然後再加入一些會在實務上遇到的狀況：每顆球（Request）要處理的工可能不一樣大，伺服器也不一定都一樣強。

這樣一來，單純平均發球的輪詢作戰很快就會遇到胃口比較小的伺服器開始吃不下的尷尬狀況

為了減輕這個狀況，我們可以在每個伺服器前面加個小小的排隊區（Request Queues），雖然要排隊勢必會拉長時間，但至少掉球的狀況就減少了

再進一步的話，我們可以針對伺服器的消化能力來替他們加個權重，不過手動標權重很容易翻車，所以要想辦法讓他自動調整權重，也就是要能「動態加權輪詢」

例如根據最近三次的執行時間來計算伺服器的胃口(?)，再決定要發幾顆球給伺服器，比較餓吃比較快的就多發一點(??)

除了吃不下把球吐掉以外，如果吃太久吃到 Timeout 也是不行的。而針對延遲問題，這篇最後介紹了「峰值指數加權移動平均（PEWMA）」

做法其實也很直覺：抓一下最近這些伺服器的延遲如何、都處理了多久，然後再經過一些數學魔法(?) 來算出下一個 Request 給哪台伺服器比較好、看能不能讓延遲更少

ps. 附上數學魔法的段落給那些看得懂的朋友：

For each server, the algorithm keeps track of the latency from the last N requests. Instead of using this to calculate an average, it sums the values but with an exponentially decreasing scale factor. This results in a value where the older a latency is, the less it contributes to the sum. Recent requests influence the calculation more than old ones.
對於每個伺服器，該演算法會追蹤從最後 N 個請求開始的延遲時間。不同於使用此來計算平均值，它將這些值相加，但使用指數遞減的比例因子。這導致一個值，其中較舊的延遲對總和的貢獻較小。最近的請求比舊的請求更影響計算。

That value is then taken and multiplied by the number of open connections to the server and the result is the value we use to choose which server to send the next request to. Lower is better.
然後，將該值乘以與伺服器的開放連接數，結果就是我們用來選擇下一個請求要發送到哪個伺服器的值。數值越低越好。

但是相較前面著重在不要把球吐掉的「動態加權輪詢」，這套注重延遲問題的「峰值指數加權移動平均」就比較有可能發生更嚴重的吃不下問題

作者有進行一些測試並繪製圖表，有興趣的朋友可以參考看看。感覺還是要根據狀況、評估對延遲或掉包的容忍程度，再決定採用怎樣的負載平衡策略會比較好

那麼，今天的轉貼就到這邊，我們明天（大概）見～

這兩天在幫部落格加上新玩具，來轉貼一篇寫得挺完善的介紹文：
用 Microsoft Clarity 網站分析工具，觀察使用者行為 - Let’s Write

Clarity 是微軟把拔推出的免費網站分析工具，其中有些特別的地方，例如憤怒點擊：

這個也很有趣，光看名稱就覺得有趣了 XD~

一般我們自己在看別人家的頁面，比方看到個「點我下載懶人包」之類的按鈕，如果點了發現沒反應後，我們會怎麼做？我們會一直點、繼續點、猛點 10 次、怒點 100 次！

這個就是 Rage clicks

另一個讓我覺得小驚豔的功能是側錄（Recordings）

這個功能可以直接看使用者在你的畫面上是怎麼操作的，有種看使用者開著直播看自己文章的感覺，相當新奇。所以也能很明顯地看到使用者複製了文章裡的程式碼然後跳窗走人……

另外，側錄紀錄上也只有一些模糊的識別內容，所以可以不用擔心錄得太超過(?)的問題

左邊是清單，可以照想要的方式來排列順序，右側就是點擊清單後會看得到的側錄影片。

這邊可以看到，清單上會顯示的是：裝置、作業系統、國家，這三個跟使用者比較相關，是一個比較模糊的分類。

畢竟如果可以看到「這個人就是王小明，就是他，這就是錄他在幹什麼」的情況，那個資及隱私的問題就大了。

所以只提供一個模糊的分類是可以理解及接受的。

其他功能可能要等子彈飛一會兒再來探探。
有興趣的朋友也可以先戳戳看官方給的 Demo 頁面

那麼，今天的轉貼就到這邊。我們明天見～

看見前輩貼了「可觀測性」的鐵人賽筆記，翻了一輪發現挺香的，馬上轉貼上來：
marcustung/Observability-in-DevOps: Observability 101 (github.com)

這些文章（我感覺）能切成幾個部份：

• 一些系統穩定性的東東。例如災害復原、高可用性和高可靠性之類的
• 可觀測性 Observability
• 好像很猛的新標準 OpenTelemetry
• 香香的 Grafana Cloud

每篇文章的開場都會先說明重點、結束的時候也有知識點小結，非常貼心

因為系列文本身蠻長的，能延伸的知識點也蠻多的。這邊就按照慣例，列一些我印象比較深刻的點

我在看到主題的時候，第一個疑問其實是：所以我的團隊有了可觀測性可以幹啥吃？

而在 Day 10 的可觀測性介紹裡，這一段回答了我的問題：

白話點背後是希望可以回答以下問題：

• 請求經過哪些服務 ? 系統中哪個部分 loading 最大
• 當服務發生緩慢時，哪裡慢(Bottlenecks)以及可能原因是什麼
• 當服務無法使用時，錯誤及可能異常的原因是什麼
• 當使用者反映操作 timeout，但在 Dashboard 上顯示平均請求都很快，要如何找到其可能緩慢原因

目的是希望工程團隊可以理解並解釋系統的現況（增加系統透明度，而不是靠通靈），當系統出現問題時，可以第一時間了解爆炸範圍，進行緊急問題的處理已加速恢復的時間。

身為通靈師的一員，看到這段開始覺得「哦，好像不錯哦，竟然不是靠直覺嗎🤔」

而在 Day 28 的時候又看到了更強烈的對比：

如果你是開發或是運維團隊人員，當線上系統或負責應用程式遇到問題時，會做哪些事情來協助定位問題

警報 (Alert) :
當系統監控偵測到異常或是特定指標 (Metrics) 超過預定的閥值或水位時，系統會產生告警警報，對於 RD 及團隊來說，這是首先被告知問題的方式。

儀錶板 (Dashboard) :
收到警報後，RD 可能會先查看 Dashboard 了解異常背後的數據。Dashboard 提供即時的數據視覺化，幫助 RD 快速定位問題範圍和影響程度。

查詢 (Adhoc Query) :
若 Dashboard 所提供的資訊不足，或是為了要更精準確定問題原因，RD 會使用 adhoc Query 進一步的來查找特定時間的數據資料來確認問題。

日誌 (Log Aggregation) :
確認問題範圍後，RD 會查找相關的系統或是應用程式 Log，Log 中可能包含更明確的應用程式執行資訊，或是問題的詳細描述與錯誤訊息，幫助 RD 更有機會找到問題的具體原因

分散式追蹤 (Distributed Tracing) :
如果應用程式架構是分散式系統，RD 會使用分散式工具來找特定請求式如何在多個服務間流動過程，有助於找到性能瓶頸或可能失敗的原因。

修復 (Fix) :
一旦問題被定位，就有機會定位問題並進行緊急修復的動作。可能解決方式式調整配置設定檔、修正錯誤的程式或是重新啟動服務(重開治百病)

感覺是專業工程師的抓蟲流程。但像我們專業靈媒團隊，平時出事的反應更接近 Day 29 的：

口而相傳，緣分到了就會修好
各自通靈
(文件)定義流程 + 系統

通著通著就哭了。

另一組記憶點是來自於我原先的誤會：「可觀測性不就是插一狗票 Log 嗎？」

在 Day 11 的「從哨塔到全景地圖」有稍微讓我認識了一點：

舉個玩世紀帝國的例子，監控就像是在已經打開的地圖前提下，在覺得危險的位子設立哨塔及哨兵，當有人來攻擊時就會有叮叮叮聲響來提醒玩家派兵防守

可觀測性就是一打開地圖就已經全開，當別的玩家派兵攻打自己的範就可以看到派人的兵種是甚麼及人數，可以做更有效的化解對方玩家的攻擊

好像有點懂了：插監控就像是深入敵方野區插眼，可觀測性是想直接開圖

而我們團隊都是銅牌瞎子，所以小地圖根本是黑的

同樣讓我長知識的還有「三本柱 Metrics、Logging 與 Tracing」

這邊直接節錄文章中的介紹：

Metrics : 指標

• 用來衡量和監控系統性能的關鍵數據指標，通常是數字化的方式呈現(可聚合數字)。
  
• 這些數據通常用於即時監控系統，以確保它們在正常運行範圍內。
  
• 例如 : CPU使用率、記憶體使用率、請求速率、錯誤率等都可以通過指標來衡量

Structured Log : 結構化日誌

• 日誌包含有關離散事件的結構化或可讀的詳細資訊。用於提供請求的細節與上下文。
  
• 日誌通常被用來瞭解系統中特定事件的發生情況，以及在事件發生時提供上下文。
  
• 例如，錯誤日誌、訪問日誌、應用程式日誌等都是常見的日誌類型。

Distributed Tracing : 分散式追蹤

• 用於追蹤複雜分佈式系統中請求的過程，以便了解請求從一個元件到另一個元件的傳遞情況。
  
• 它有助於識別性能問題和瓶頸，並提供有關請求流程的詳細信息。
  
• 通常，追蹤由一個唯一的標識符（例如 traceID）來關聯相關事件。

我的理解是這樣，供參考：

• 如果服務 CPU 狂噴猛噴，直接噴到 100% 120% 500%，這個是 Metrics
• 如果在程式碼裡面偷寫紙條印出來，例如 “Oops, ERROR!"，這個是 Logging
• 如果跨了三四個服務只好摸一串粽子找過去，這個是 Tracing

在這之前我基本上都一律叫成 Log，同事問問題也是兩手一攤：你去查 Log 啊= =

想起一臉疑惑的朋友們，原來混在一起搞撒尿牛丸的是我🥲

補充：今天和朋友(?)詢問了一些 Metrics、Logging 與 Tracing 的例子，這個對比貼上來給各位參考：

總覺得其中一種做法特別熟悉🤐

後面還有蠻多記憶點的，但寫到這邊發現篇幅有點爆，Discord 竟然發不出去了= = 加速一下

中間段（Day 17~）的主角都是不明覺厲(?)的可觀測性全新標準 OpenTelemetry

例如介紹 OpenTelemetry 的規範和實作，例如協定和 API 規格，接著逛了一圈 Demo

能夠理解有個大一統規範能對可觀測性有多大的幫助，但因為我個人沒玩過，看這段的時候基本上就是「哦哦這新標準好像猛猛的」

可能之後找時間碰才會有更深的心得，已經摸過的朋友也歡迎幫忙補充資訊上來

最後的 Day 20+ 開始介紹 Grafana Cloud，離我就更遠了，這邊就略過 xD

除了上面的兩大塊深水區以外，我還有兩個小小點特別有印象：

Day04 的 SLA -> SLO -> SLI 這條：

我們在 3/19 轉貼德魯大大的 Re-Order Message 文章時，裡面有提到「對整個系統的 SLO 期待」這一段。在這裡串了起來：

我們跟客戶簽了 SLA 說我們 99.99% 穩。然後我們為了達標（=不要賠錢），就訂了更具體的 SLO，而為了衡量這些指標，就搞了 SLI

啊如果 SLI 量下去，抱歉沒達到 SLO，就準備按照 SLA 簽的東西跪地開賠。大概是這樣(?)

另一個小小點是 Day 30 的可觀測性驅動開發（Observability Driven Development ,ODD）：

就像 TDD 測試驅動開發強調在寫程式碼前要先寫測試案例，以提高程式碼的保護與品質。ODD 在建立可觀測性系統方面也是如此，可觀察性驅動開發意味著開發人員在編寫程式碼之前考慮可觀察性信號或是監控方法，適用於元件級別或是整個系統。

也許，我是說也許，我們開發之前的確就該想好後續該怎麼監測跟維護，而不是把鍋端給後面的苦主來通靈。對吧？對吧前輩們？

三十天太長了，很難在這篇推薦文裡介紹完。我已經列了許多我有筆記的部份，但像是 OpenTelemetry 這些硬東西，我個人力有未逮(?)

還是推薦有興趣的朋友直接閱讀，畢竟文章結構簡單直接，有大綱有小結，拆成每一天的話也不算長，有名詞或觀念也能再自己延伸，感覺不虧

不說了我要去拆文章內容到我的筆記庫了= =”

今天還在持續厭世，來轉貼前天看延壽指南的時候撿到的工程師減肥指南(?)

• 寫給工程師看的減肥指南 — Part 1 不運動減掉 16kg - Sean Cheng
• 寫給工程師看的減肥指南 — Part 2 生酮理論 + 胰島素理論 - Sean Cheng
• 寫給工程師看的減肥指南 — Part 3 腸道菌理論 - Sean Cheng

我喜歡這系列的點在於，第一篇作者就直接列出影響他最大的幾個減肥理論，然後還分享了從 2020 到 2022 的歷程：

在前面半年我就擬定了大方向，後面則是陸續補齊完整概念、建立專屬於自己個人的理論。
總結起來，影響我最大的三個減肥理論是：

生酮理論 + 胰島素理論：
人可以使用油脂當作身體能量，因此幾乎不吃澱粉也能活的好好的。

腸道菌理論：
每個人的腸道菌相不同，因此即使吃入相同的東西，吸收的熱量、營養成分卻不會一樣。

細胞層級的代謝理論：
人使用油脂當身體能量的能力，和呼吸習慣、細胞油脂組成、粒線體數量有關。

針對這些理論，在後續也逐項進行說明。並且引用了一些影片（或是說，很多影片），可以馬上就連出去科普科普：

How Bacteria Rule Over Your Body – The Microbiome - youtube

在第一篇也有把要做的事、別做的事情清楚地列出來，而第二篇、第三篇也有很好懂的說明。例如：

勞力工作者主要使用醣類當作日常能量，在活動時使用肌肉、肝臟中的儲存的肝醣，並在吃飯時透過進食澱粉、水果、肉類(可轉換成醣)補充回來，每天的生活循環可能如下：

吃午飯(醣類補充到 80%) → 勞力工作(醣類降低到 30%) → 吃晚餐 (醣類補充到 80%) → 睡覺8小時(醣類降低到 60%) → 吃早餐(醣類補充到80%)…

但在國家發展到以知識型產業為工作主體的情況下，大多數人的生活型態已經完全不適合每天吃大量澱粉，因為其醣類循環狀況會變成下面這樣：

吃午飯(醣類補充到 110%) → 坐著工作(醣類降低到 100%) → 吃晚餐 (醣類補充到 120%) → 睡覺8小時(醣類降低到 95%) → 吃早餐(醣類補充到110%)…

我個人還有下午茶、點心跟宵夜，都不知道補充到幾 % 去了。

前陣子體檢一卡車紅字，最近也一直覺得身體怪怪的。在前天翻延壽指南的時候，順著找到了這篇，感覺多少認識了一些新知識（當然，有沒有身體力行又是另一回事 xD），也轉貼上來給各位朋朋們參考。

今天頭還是很暈，簡單分享一下今天看到的有趣文章：
無限 alert 迴圈事件 - Kalan’s Blog

這件事發生在日本：

在 2019 年三月，兵庫縣警以在電子留言板上放上有惡意程式碼的連結有不正指令電磁的記録供用未遂之疑，到女國中生家搜索，並搜查兩名男性後送檢。3/25，日本黑客協會開始募集兩名男性的律師費用及官司費用，總共募到了 553 人共 700 萬日圓的金額。 在同年 5/29 兩位男性以緩起訴處分，此案件沒有任何受害者。

根據其中一位男性的說法，檢察官認為「對某些手機型號來說，一旦點擊連結後有可能沒辦法關閉畫面，或是需要拿去維修甚至是拜託專家，違反了電腦病毒罪當中的要件『反意圖性』。」，對於「不正指令電磁的記録供用罪」的主張沒有改變。

竟然違反了「不正指令電磁的記録供用罪」，究竟是怎樣的程式呢：

window.alert 能夠接收指定的字串，並顯示一個具有 OK 按鈕的對話框。按下 OK 按鈕之後就能夠把對話框關閉。

這個程式是無限迴圈，因此關閉對話框之後，又會再出現對話框，這個行為會持續到使用者關閉瀏覽器分頁。

就是這樣。還敢寫出無限彈跳窗啊 xD