標題: 「SRE 的工作介绍」 類別: others 連結: https://www.kawabangga.com/posts/4481
本篇是簡體中文的文章，所以就不針對文章進行導讀。
文內我覺得有趣的部分是從各個面向來探討 SRE 這個職位的可能內容，畢竟一直以來 DevOps, SRE 等相關概念的詢問就沒有停止過，而事實上每個公司的 DevOps 工程師, SRE 工程師的工作內容也都不盡相同。
也因為不盡相同，本來就很難一言概括到底 SRE 的可能內容，因此個人算是滿推崇本篇文章的分析與整理方式，從不同角度出發去列舉各種可能的工作內容，譬如文章中分成三大類
三種不同類型的 SRE 面對的對象不同，專注的事物也不同，我猜想很多人看完架構類型的論述可能第一個想法就跟以前的 SA/NA 網管有什麼不同？
也許從 SRE 的 R 出發，去探討你今天到底想要針對什麼樣的目標去提供高可用性，也許更能夠方便探討彼此對於 SRE 的需求與認知
標題: 「DevOps is a failure」 類別: others 連結: https://leebriggs.co.uk/blog/2022/06/21/devops-is-a-failure
本篇文章作者從不同的角度來聊聊 DevOps 這個詞所代表的含義與實作意義
第一段作者先閒聊一下自己與 DevOps 詞的歷史，接者直接拋出一個作者長期好奇的觀點 「每個人都一定聽過 DevOps 是一個需要 Dev + Ops 共同參與的文化，但是作者自己參與的 DevOps 相關會議與討論，與會者大部分都是 Ops 人員，而不是那些真正參與開發的 Dev 人」
接者作者聊聊自身多年前的經驗，當時的開發團隊宣稱該團隊是「true devops」，同時不跟作者的維運團隊討論各種維運需求，這過程讓作者非常困惑，為什麼對方會說自己是 true devops 而又不找自己探討維運需求
作者後來與該開發團隊深聊後終於理解對方的意思，原來該開發團隊身兼開發與維運，該團隊使用 boto3 加上一些腳本來管理應用程式的生命週期，同時該團隊招募的 「full stack engineer」除了基本的後端技術外，也要對 AWS 有不少的熟悉與經驗。
對方的舉動更加困惑了作者，畢竟公司當時採取類似 Netflix 的方式來打造一個平台來讓所有開發者可以更輕鬆的去管理這些東西，而該開發團隊的舉動完全是反其道而行，到底為什麼要這麼做？？
當作者加入 Pulumi 時期時，作者開始使用一些知名工具如 GitLab, Terraform, Kubernetes 等工具來打造一個適合開發者的好用平台，然而每次想要將該平台給推廣給開發者時總是屢屢碰壁，總是會聽到如「你們的東西我不熟悉，我們還是習慣自己打造的工具」等類似說詞給打發掉。
作者接下來不斷嘗試說服開發團隊來使用自己打造的超級平台，鼓勵他們參加 DevOps 相關活動等各種方式，最終得到的還是類似「我們會按照我們自己的方式去嘗試～謝囉」之類的回覆
回顧過往，作者發現錯的是自己，一直以來相信的 DevOps 願景「讓 Ops 停止說 No, 讓 Dev 停止說"yo~ 今天部署吧"」 其實並不真實，作者認為 2022 的今天， DevOps 真正的含義是 「維運端的人努力說服開發人員按照維運人員的想法去做事情」
綜觀所有號稱跟 DevOps 有關的工具，你會發現幾乎都跟維運有關，每個跟 DevOps 有關的職缺列舉的技能也是滿滿的跟維運有關，對作者來說， DevOps 工程師跟過往的 System Admin 根本沒有太大分別，差異只有把「實體機房建置，上架機器」 v.s 「雲端機器建置，創立VM」而已。
文章內後半部分還有一些作者的想法，有興趣的可以閱讀完畢
本篇文章的想法滿有趣的，譬如作者提到想要幫開發團隊建立一個維運平台卻屢屢碰壁。
Ops 可能會覺得 Dev 一直不停重複打造工具沒有效率，不如使用自己打造的好平台 Dev 可能會覺得 Ops 不懂自己的需求，不如自己根據需求打造
同樣的敘述放到不同的規模，譬如
dev -> 5 人的專職開發團隊 dev -> 50 人的專職產品團隊
後者的角度也許會覺得團隊人數夠多，可以自己處理自己的需求，不需要仰賴公司提供一個萬能平台來處理一切，同時跨 team 合作可能還會使得很多事情效率低落，溝通成本過大。
歡迎留言探討你的想法
標題: 「面試人生 - 設計一個簡易的分散式 Job Scheduler」 類別: others 連結: https://medium.com/@raxshah/system-design-design-a-distributed-job-scheduler-kiss-interview-series-753107c0104c
本篇文章是一個面試技術文，探討開發一個類似 Job Scheduler 的專案時應該要如何去設計整體系統來完成需求，整體的架構基於 KISS 的原則，就是簡單為主。
整個流程原則基本上是
功能面常見類型如
非直接功能面如
有了功能面的需求，接下來就是數量大小的需求，譬如該架構要可以達到每秒 1000 個 Job(1000QPS), 從這些需求下去估算大概需要多少 CPU 以及多少 Memory，同時這些數量還可以滿足功能面的需求，譬如每個 Job 可以運行最多五分鐘。
所以也許會得到需要 10,000 台的 (16C) 機器，以及 100 台(16GB) 的機器來提供服務 基本的運算可以快速的理解該需求到底需不需要分散式的架構來處理，本文的範例資料量就很明顯是 scale up 沒有辦法完成的。
接下來就基於分散式的架構去設計相關架構，包含如
逐步的規劃這些架構，並且探討彼此元件之間的溝通方式，這些方式是如何互相組合來滿足功能面/非功能面的需求
詳細需求可以參考全文
標題: 「Cloudflare 06/21 災後報告」 類別: networks 連結: https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/
Cloudflare 官方文章詳細解釋 06/21/2022 當天到底發生什麼事情導致用戶受到影響，
這次的問題影響範圍概括了 Cloudflare 底下的 19 個資料中心，而很不幸的這 19 個資料中心剛好都是負責處理繁忙的全球流量，所以受到影響的用戶數量才會如此的多。 問題主因是網路設定的調整(有問題先猜BGP，不行再猜DNS...)，整體的發生時間沒有非常長
過去 18 個月以來， Cloudflare 致力於將其底下繁忙的資料中心進行架構改造來達成更為堅韌與彈性的網路架構，內部稱該架構為 Multi-Colo POP(MCP)，影響的 19 個資料中心包含 Tokyo, Singapore ... 等
新架構最重要的部分就是其網路的部分是基於 Clos network 的架構設計，透過多層次的設計達成類似 mesh network 般的網路連結，該架構使得未來要維護與調整時能夠更輕鬆針對部分網路設備去處理而不會影響到整體網路(文章有架構圖片)。
這次的問題主要跟 BGP 有關，Cloudflare 更新 BGP 的過程中有部分的 subnet 沒有順利的被傳遞出去，最終使得部分 subnet 的流量無法被順利轉發，進而導致整個網路問題。
文章內部有針對 BGP 問題更詳細的介紹，熟悉 BGP 的朋友可以花點時間看一下
這次的問題影響範圍很廣，Cloudflare 針對下列三面向反思了一下問題的發生原因
雖然嶄新的 MCP 架構其目的就是要提供更好更強的可用性，但是將舊架構給升級到新架構的過程中還是不夠完善。整體的更新流程直到最後一步驟才算是真正的接觸到全新 MCP 架構，這使得如果中間更新流程有錯必須要到最後才會觀察到 MCP 資料中心的網路炸了。 改善的方式則是未來的這些流程與自動化必須要加入更多關於 MCP 架構的測試來確保整體部署不會遇到預期外的結果。
路由器的錯誤設定使得正確的路由規則沒有辦法順利的被傳達下去，最終使得網路封包無法如預期般地到達這些資料中心。 所以修復過程中就是要找出這些錯誤的設定並且修正，最終使得這些 BGP 能夠將正確的路由政策給轉發下去。
當前的自動化流程中有非常多的部分可以改進，這些改進有機會完全或是部分的去減緩問題發生時的影響程度。 有兩個目標是想要透過改善自動化機制達成的
CDN 不通先上社群看同業有沒有哀嚎，大概就可以知道是不是自己的問題了?
標題: 「啟動 container 直接 kernel panic 的 bug」 類別: others 連結: https://bugs.launchpad.net/ubuntu/+source/linux-aws-5.13/+bug/1977919
本篇文章探討的是一個關於 Ubuntu kernel(5.13+) bug 產生的各種悲劇，已知受害的雲端業者包含
linux-oracle linux-azure linux-gcp linux-aws
等常見大廠。
簡單來說，預設設定下只要簡單跑一個 container 譬如
docker run -it ubuntu bash 就可以直接觸發 kernel panic，直接讓你系統死亡強迫重啟
整個 bug 結論來說就是，一連串的操作最後有機會導致使用到一個 null pointer，然後 kernel 就炸拉...
相關的修復可以參閱這個連結，裡面有大概提到問題發生點以及修復方式。 https://kernel.ubuntu.com/git/ubuntu/ubuntu-impish.git/commit/?id=6a6dd081d512c812a937503d5949e4479340accb
標題: 「分散式系統上的常見網路謬誤」 類別: others 連結: https://architecturenotes.co/fallacies-of-distributed-systems/
本篇文章是探討分散式系統上很常被開發者所忽略的網路情況，這些情境都容易被忽略與考慮，但是每個點實際上都會影響整個系統的效能與功能
這些常常被忽略的網路情況包含
開發分散式系統的時候，一定要去考慮網路壞掉的情況，切記網路中的任何傳輸都不是 100% 穩定的。千萬不要假設所有封包與傳輸都沒有問題，必要時還要考慮重新連線，重新傳輸的情況。
網路時間還有一個要注意的就是延遲時間，通常 Client/Server 如果都是同一個系統內的服務時，這類型的時間可能非常短，如 ms 等級。 但是當 client 可能是來自真實使用者的手機裝置時，就要將 latency 這些因素給考慮進去，不能假設所有的 API 與網路請求都是秒回的情況。
更常見的還有導入 CDN 等方式透過地理性的位置來減少 client/server 之間要傳輸的距離。
文章內針對剩下的類別都有簡單的圖文並茂來解釋，淺顯易懂，有興趣的可以參閱全文
標題: 「為什麼有些工程師不相信 Best Practices 」 類別: others 連結: https://blog.devgenius.io/why-some-developers-dont-believe-in-best-practices-8c03ea4f7e88
工程師想必對於 DRY, KISS(Keep It Simple, Stupid), YAGNI(You Ain’t Gonna Need It) 這些廣為流傳的開發原則並不陌生，這些原則都是過去許許多多優秀工程師透過自己的經驗而濃縮的開發準則。
但是作者觀察到有滿多工程師對於這些 開發原則/命名標準/最佳實驗經驗 等採取一個不信任態度，甚至覺得導入這些東西都是浪費時間。 因此本文章是作者探討什麼樣的工程師可能會不太願意去學習與導入這些廣為流傳的開發原則與經驗
作者開宗明義地說，小專案的成功經驗基本上是沒有辦法導入到大專案的開發的，小專案的特型譬如 1) 合作人員很少 2)專案時間少 這類型的特性只得技術債或是欠缺設計的程式架構不太會影響整個專案，畢竟專案太小，時間太短，後續的人不一定有機會真的觀察到這些潛在的問題。
而小專案還有一個很大的特性就是後續維護的人很有可能跟當初的開發者不同，所以對於開發者來說非常難去感受後續維護的痛苦與需求。
上述特性有可能會使得開發者覺得自己的開發經驗非常足夠且堪用，因此就會基於這樣的經驗來抵抗其他更多被推廣且推崇的開發原則與最佳實戰經驗。
因此對於一些只開發過小專案且沒有後續維護的工程師來說，其有可能就不會想要學習這些原則與經驗，畢竟自己的工作流程根本沒有機會感受到好處。
簡單來說就是「劣幣逐良幣」的概念，從工程師開發的角度來看，寫一個「可能比較好維護，未來比較不會有問題，高品質的程式碼」如果實務上不會帶來任何好處，甚至可能「績效表現比較不好」的情況下，那為什麼工程師要努力寫出高品質的程式碼？
軟體團隊除了開發者之外，還會有相關的專案管理人員，產品管理人員以及最終使用者。 對於非技術人員來說，其在意的點更有可能專注於「程式開發速度，產品上線速度」，至於專案的後續維護性，開發靈活性等長時間才會看到的問題都不是他們所在意的點。
這種情況下，如何評價一個工程師的能力很有可能就變成「能夠多快的滿足專案需求，而不是寫出的程式碼品質」，所以對於工程師來說，快速寫出功能不考慮後續其他維護等長期問題反而更可能受到團隊重視，因為「功能出的快」。
所以如果團隊沒有辦法好好的去重視「高品質程式碼等考慮長期問題的開發原則」就有可能會導致工程師不會想要好好的去撰寫好的程式碼，長期下來這些工程師就可能會開始拒絕學習各種開發原則與最佳實踐的經驗，畢竟導入這些東西沒有任何實質上的幫助，反而初期可能會降低功能的上線速度。
「知彼知己，百戰百勝」，沒有花時間去學習這些開發原則的前後脈絡與適用情景就沒有辦法很順利的導入到開發專案中，所以實際上這些導入都要工程師花時間去學習與理解，然後嘗試導入與使用。
然而並不是每個工程師都願意花時間去學習，畢竟平常工作就是寫寫程式碼，寫寫文件，結果來說能動就好。花這些時間去學習這些東西
作者認為很多工程師「其實都不知道自己不知道什麼」，這導致他們很難去學習新技術與新概念，畢竟未知領域帶來的好處與優勢不是他們工作經驗中有機會去體驗到的，就如同前面所述，對一個擅長開發短期專案就拋棄給別人維護的人來說，其很難體會到各種長期維護與技術債的問題。 practices.
另外一個非常常見的問題就是「導入開發原則與好的開發經驗」與否對於初期開發來說很有可能沒有很任何明顯的差異。 從短期目標來看，兩者開發角度產生的結果不會差異太大，但是對於只有幾個月的小專案來說，後者甚至能夠更快的完成需求然後拍拍屁股結束閃人。
架構複雜性，技術債以及其他的爛程式碼可能產生的後續問題都需要時間發酵，所以團隊事主如果沒有辦法以長期觀念來看到程式開發的話，上述的問題就沒有辦法被重視，就如同前面所述，開發者就會「速度為主，品質為輔」的概念來開發，至於後續維護痛苦與否就是後續接手人的事情。
剩下其他論點就可以到原文去觀賞
標題: 「使用 StressChaos 的經驗來學習 Pod Memory 使用情況」 類別: others 連結: https://chaos-mesh.org/blog/how-to-efficiently-stress-test-pod-memory/
本篇文章是來自於 Chaos Mesh 內的官方文章，主要是想要探討為什麼使用 Chaso Mesh 來測試記憶體狀況時結果實際狀況與設定的狀況不一致 文章一步一步的探討所有問題最後同時也整理了一些關於 Kubernetes 內的 Memory 相關機制
文章開頭，作者先部署了一個簡單的 Pod(只有一個 container)，該 Pod 針對 Memory 的部分設定 request: 200Mi, limits: 500Mi 結果作者到該 Container 中透過 free 與 top 的指令，都觀察到顯示的記憶體使用量高達 4G，這部分明顯與設定的 limits 500Mi 有所衝突 因此這邊產生了第一個點要特別注意
Kubernetes 是透過 cgroup 來計算與控管 Pod 的 Memory 用量，然而 free/top 等指令並沒有跟 cgroup 整合，因此就算跑到 container 中執行這兩個 指令看到的輸出其實都是 host 相關的，如果想要知道真正 container 相關的數量，還是要使用 cgroup 相關的指令來取得，譬如 cat /sys/fs/cgroup/memory/memory.usage_in_bytes
文章還有特別提到 Kubernetes 會針對 Request/Limit 的設定方式來將你的 Pod 分為三個等級，分別是 BestEffort, Burstable 以及 Guaranteed 其中當系統因為 OOM 不足要開始找受害者下手時，被設定為 Guaranteed 的應用程式則會是最低優先度，只有真的找不到其他受害者時才會來處理 Guaranteed 類型的 Pod。
最後則是更細部的去探討 Kubernetes 關於 Memory 的使用與管理 對於 Kubernetes 來說， 當系統上 Memory 數量不足時，可能會觸發 Evict 的行為，開始將部分運行的 Pod 給踢出該節點，而如同前面所述， Kubernetes 是依賴 Cgroup 來處理的，因此 /sys/fs/cgroup/memory/memory.usage_in_bytes 自然而然就成為其決策的重要參數
其中要注意的是 /sys/fs/cgroup/memory/memory.usage_in_bytes 代表的並不是 "剛剛好系統上正在被使用的 Memory 數量"，其數值則是由 "resident set", "cache", "total_inactive_file" 等三個面向組合而成，因此 Kubernetes 實際上會先從 /sys/fs/cgroup/memory/memory.usage_in_bytes 與 /sys/fs/cgroup/memory/memory.stat 取得相關參數，其中後者可以得到如 total_inactive_file 的數量 最後透過下列算式 working_set = usage_in_bytes - total_inactive_file 來得到一個名為 working_set 變數，該變數實際上也可以由 kubectl top 獲取，這也是 kubernetes 用來判斷是否執行 evict 的主要指標。
一個節點還有多少可用的 Memory 則是透過 memory.available = nodes.status.capacity[memory] - working_set 所以每個節點的總共量扣掉 workign_set 就是當前可用量，一旦當前可用量低於門檻時，也就是 k8s 執行 evict 之時 官網文件中其實有滿仔細的去描述這些操作行為 有興趣的可以花點時間全部看完 https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/
標題: 「/proc/meminfo 與 free 指令的內容比較」 類別: others 連結: https://access.redhat.com/solutions/406773
本篇文章要探討的是到底 /proc/meminfo 與 free 這個指令所列出來的 memory 相關資訊到底該怎麼匹配
雖然文章有特別強調主要是針對 RedHat Enterprise Linux 5,6,7,8,9，但是我認為大部分的 Linux 發行版的差異不會太大，畢竟整體都是來自於 Kernel 內的實作，我認為還是值得閱讀與理解。
對於大部分的系統管理員來說，勢必都有聽過 free 這個指令，該指令可以列出系統上當前的 memory 使用狀況，舉例來說通常會有 Total, Used, Free, Shared, Buffers, Cached 之類的欄位(不同版本可能會有些許差異)。 不熟悉的人可能會認為系統上的記憶體就只有“全部“,"使用中","閒置" 等三種類型，而實際上的記憶體處理遠比這些複雜，這也是為什麼 free 的輸出欄位會比較多的原因
除了 Free 指令外， Kernel 本身還有提供一個特殊的檔案位置讓使用者可以讀取當前的 memory 狀況，該位置為 /proc/memifno，其會提供如 MemTotal, MemFree, Buffers, Cached 等相關欄位
本文並不會針對每個欄位去探討實際上的意義，取而代之的是簡單的比對，透過幾個列表讓你清楚的知道 free 指令輸出的每個欄位要如何與 /proc/meminfo 去比較，要如何轉換等 特別要注意的是文章內有仔細地針對不同 RedHat Enterprise Linux 版本去分別探討，所以如果是 RedHat 系列的使用者更要好得閱讀並確保能夠理解自己當前使用版本的狀況
標題: 「goss, 一個簡易且迅速的 server 驗證工具」 類別: others 連結: https://github.com/aelsabbahy/goss
今天要介紹的是一個驗證工具 goss，該工具的目的非常簡單，讓系統管理員可以透過 YAML 的方式幫機器上的服務撰寫 Unit Testing 什麼情況會需要使用這類型工具？
舉例來說，當你今天部署了一個全新機器(手動/自動後)，你安裝了下列軟體
同時你也根據需求事先創建了一些使用者，接者你想要驗證這些軟體與相關設定是否設定完成 最直覺的方式就是手動檢查，一個一個服務與設定人工檢查
而 goss 這套軟體的目的就是讓你用 YAML 的方式去撰寫你想要驗證的所有服務，可以用來驗證包含
Goss 除了基本用法外，也有人基於其概念往上疊加 dgoss，用來驗證 Docker 的運行狀態，還有類似的 dcgoss，針對 docker-compose 來使用。 當然目前也很多人會透過 Ansible 的方式來自動化部屬，而 Ansible 本身其實也有相關的測試框架可以用來測試部署結果，所以到底要用哪類型的工具 來驗證 Server 等級的狀態就根據團隊需求與現有流程而定，比較沒有一個獨大的工具用法。