標題: 「Linux 5.19 竟然是由 Apple M2 MBA 釋出的」
類別: others
連結: https://twitter.com/asahilinux/status/1553968394734813184?s=21&t=GMOBjwW_tzPQJ_j8mm7GZg

最近 Linux Kernel 5.19 的釋出如火如荼的進行，其中最有趣的是 Linus Torvalds 是使用 Apple M2 來運行 test build, boots 以及 release 相關操作

同時該推特帳號 Asahi Linux 本身就是一個能夠於 M1 上運行的 Linux 發行版本，不知道是不是暗示 Linus 本身是於 M2 晶片上運行 Asahi Linux 來發行 Linux 5.19 ?

標題: 「如何一直不停的於 SRE 之路上學習」
類別: others
連結: https://medium.com/async-software/how-i-learned-and-still-learn-site-reliability-engineering-dd6ad32c4285

作者認為身為一個應用程式的開發者，如果對於如何將應用程式給部署到正式環境的細節有一些粗略瞭解，對於 DevOps 的領域也能夠有所一些涉獵時，其實對於整個團隊來說會使得合作更加協同，譬如說應用程式開發者就會知道可能需要準備 Health Check 的 API，針對維運監控方面也會知道如何準備適當的 Metrics API。

所以作者就從幾個不同角度列出一些學習的相關資源，從 DevOps 的概念出發學習，接者是相關的技術探討

# 書籍
1. 第一本推薦的書籍是由 Google 所維護的 SRE 書籍， Site Reliability Engineering。
該書籍涵蓋了如何建置，部署，監控以及維護如此龐大的 Google 架構。
2. 作者推薦的另外一本書籍則是非常著名的鳳凰專案，跟者故事主角一同面對一個要轉型的企業，同時自己也可以順便思考到底本書想傳遞的 DevOps 概念是什麼

此外還有其他兩本包括 Continuous Delivery 以及 Continuous Architecture in Practice 這兩本探討 CD 以及 DevOps 與敏捷文化下的軟體架構設計

# 學習平台與網站
1. A Cloud Guru 是一個可以用來學習如 AWS, Azure, Terraform, K8s, Linux, Ansible 以及 GCP 的線上網站
2. 一個開源的 Git 專案， (MichaelCade/0DaysOfDevOps)，該專案紀錄如何從頭到尾用 90 天的時間去認識 DevOps 這個文化與技術，
3. The Delivery Hero Reliability Manifesto，該網站整理了很多關於 Delivery Hero 的技術文章，包含實務上的技術分享以及經驗累積的一些實戰經驗等。
4. DevOpsCube 則是收集了很多關於 Kubernetes, Jenkins, Container 等技術的相關實戰文章

對這些有興趣的人可以加入到書籤的待讀清單中

標題: 「善用 ephemeral container 來加強 K8s Pod 的除錯技巧」
類別: Kubernetes
連結: https://betterprogramming.pub/debugging-kubernetes-pods-deep-dive-d6b2814cd8ce

過往大家除錯 Kubernetes Pod 時很常會使用 kubectl exec 的方式進入到容器中去執行相關指令，但是這個方式很常遇到該容器沒有相關的工具而無法進行，當問題容器是第三方服務是更不太可能重新去建置這些容器來加入想要使用的工具。此外也有可能遇到部分操作需要權限，這情況通常都需要修改 YAML 重新產生一個 Pod

所以本篇文章會著重於另一個除錯的方式，也就是透過掛載一個 Ephemeral containers 的方式到現有的 Pod 上面，該 Contianer 可以安裝各式各樣的工具，同時動態共享如
1. Network namespace
2. Process namespace
3. Volume

有了上次的共享資源，我們就可以使用該容器來針對服務進行除錯同時又不需要去修改與動到任何既有服務的設定。

本文使用 KIND 架設一個示範用的 k8s 叢集並且使用 kubectl debug 的方式來示範如何掛載這類型的容器來達到除錯的效果。

如果對於除錯有苦手的一定要試試看這個方式

標題: 「不同公司針對 oncall 類別的津貼補償調查」
類別: others
連結: https://blog.pragmaticengineer.com/oncall-compensation/

本篇文章不是一個技術文，但是卻可能跟各位息息相關。
假設身處一個需要輪班的職位，你覺得公司是否應該要針對輪班這件事情有額外津貼喔？ 有的話要如何處理？
是問題發生才算加班還是半夜不睡覺進入stand by 模式也要算加班？
面試被告知需要輪班的話，你會針對整體薪水的部分提出什麼樣的補償？

文章幫你收集了各公司對於 oncall 的額外津貼與相關補償，有興趣的不妨參考看看，瞭解一下目前大部分的公司都怎麼處理這一塊以及當自己遇到的時候會希望怎麼樣處理/被處理

標題: 「以 KEDA 與 K6 來示範如何基於 Ingress 與 Prometheus 流量來自動擴張 Pod 數量」
類別: kubernetes
連結: https://blog.cloudacode.com/how-to-autoscale-kubernetes-pods-based-on-ingress-request-prometheus-keda-and-k6-84ae4250a9f3

KEDA 全名是 Kubernetes Event-Driver Autoscaler, 由於原生的 HPA 只能夠基於 CPU 等指標來進行自動擴展，而 KEDA 希望能夠更加強化這個機制讓整體叢集更加好用，因此其底層銜接 Kubernetes Deployment 等各種 workloads，而上層則是透過銜接各式各樣的 event。 這意味者你就有機會基於不同的事件來跳整 deployment 的數量。
而本篇文章是基於 KEDA 為基準，想要使用基於 nginx-ingress 的效能指標來動態調整 Deployment 的數量，而為了讓 KEDA 可以接受這些 Event, nginx-ingres 則是會透過 promethues 的方式將其資料給分享出去。

整個 demo 流程中最後使用 k6 來產生 HTTP 的流量，透過這些打到 nginx-ingress 的流量才使得 prometheus 得到最新的效能指標，最後觸發 KEDA 來動態調整 Pod 的數量

標題: 「八個你可能不知道的 git 小技巧」
類別: others
連結: https://betterprogramming.pub/8-advanced-git-commands-university-wont-teach-you-fe63b483d34b

本篇文章介紹了八個可以提升生產力的 Git 小技巧，譬如說
1. 身處 A branch 但是可以直接觀察該檔案於不同 branch 的內容
2. 清除本地那些已經被合併的 branch
3. 從歷史所有 commit 中搜尋特定字串的位置
4. 開啟自動拼字錯誤，不小心手殘打錯的指令也可以幫你校正回來
...等

文章並不長但是每個用法都有介紹一下概念以及如何使用與設定，有興趣的可以參考參考

標題: 「十個 Terraform 相關的小工具」
類別: Terraform
連結: https://shahneil.medium.com/10-best-terraform-tools-that-you-need-in-2022-e6b6d55bc071

這篇文章收集了作者認為有趣且有用的 Terraform 小工具，譬如
1. Inframap -> 根據你的 HCL code 或是 tfstate 來產生關聯圖，將所有資源彼此之間的依賴性以視覺化的方式呈現，對於需要接手專案的入門者來說也許是一個快速理解當前專案大方向的好工具
2. Terraformer -> 逆向的 Terraform，從現有的基礎架構反向產生對應的 TF/JSON 以及 tfstate。對於現存不方便改動的架構，似乎採用這個方式也能夠快速的將其套上 Terraform 的皮?
3. Terrakube -> 一套類似於 Terraform Enterprise 的開源專案，設計初期就是針對 Kubernetes 的運行環境去設定，簡單來說就是可以讓你於 Kubernetes 內部署一套類似 Terraform Enterprise 的架構供團隊使用
4. TFsec -> 一套針對安全性的靜態檢查工具，幫忙檢查相關語法同時針對創立的架構給予一些安全性上的建議

文章中還有其他六個工具，長期使用 Terraform 的使用者可以參考看看

標題: 「事故反思與 Postmortem 的實踐方式」
類別: Others
連結: https://blog.pragmaticengineer.com/postmortem-best-practices/

讀過 Google SRE 相關書籍的都會對 Postmortem 這個事後檢討的機制並不陌生，Google 強調 Postmortem 一個很大的精神是不究責，不去探討是誰造成該問題，相反的是去找出問題所在並且建立更完善的流程來確保該問題不會二次出現。

然而就跟 DevOps/SRE 這個詞一樣，每個團隊每個公司的解讀方式都不同，最後的實作方式都不同，不過這也是完全可預期的結果，畢竟每個團隊的組成與運作方式都不同，但是最重要的都是要打造一個不咎責，對事不對人的咎責文化。

本篇文章有點長，主要分成五個面向去探討，包含

Common incident handling practices across the industry.
Incident review best practices
Incident review practices of tomorrow.
What tech can learn from incident handling in other industries.
Incident review/postmortem examples and templates
想要打造一個良好的維運團隊，postmortem 是個不可或缺的流程，有興趣的歡迎花點時間閱讀本文

標題: 「事故反思與 Postmortem 的實踐方式」
類別: Others
連結: https://blog.pragmaticengineer.com/postmortem-best-practices/

讀過 Google SRE 相關書籍的都會對 Postmortem 這個事後檢討的機制並不陌生，Google 強調 Postmortem 一個很大的精神是不究責，不去探討是誰造成該問題，相反的是去找出問題所在並且建立更完善的流程來確保該問題不會二次出現。

然而就跟 DevOps/SRE 這個詞一樣，每個團隊每個公司的解讀方式都不同，最後的實作方式都不同，不過這也是完全可預期的結果，畢竟每個團隊的組成與運作方式都不同，但是最重要的都是要打造一個不咎責，對事不對人的咎責文化。

本篇文章有點長，主要分成五個面向去探討，包含
1. Common incident handling practices across the industry.
2. Incident review best practices
3. Incident review practices of tomorrow.
4. What tech can learn from incident handling in other industries.
5. Incident review/postmortem examples and templates

想要打造一個良好的維運團隊，postmortem 是個不可或缺的流程，有興趣的歡迎花點時間閱讀本文

標題: 「Uber 如何使用 gRPC 打造內部的推播平台」
類別: Usecase
連結: https://www.uber.com/en-GB/blog/ubers-next-gen-push-platform-on-grpc/

本篇文章是 Uber 官方的技術部落格，主要探討的是 Uber 如何將既有輪詢為主的操作模式轉移到推送為主的操作模式，這類型的改動目的是提升使用者(消費者/司機)的應用程式體驗。

以技術層面來說，就是將基於 HTTP1.1 的 Server Sent Events(SSE) 系統給轉移到基於 gRPC 的系統，本篇文章分成
1. 緣由，現有困境
2. 轉移方式
3. 學習以及未來展望

前半部分 Uber 先介紹當前的 SSE 架構，該架構的全名為 Reat-Time Asynchoronouse MEsssaging Network, 大概就是即時非同步訊息網路，簡稱拉麵(RAMEN). 文章簡單敘述 RAMEN 的架構，包含如何使用 Redis, Cassandra, Zookeepr 以及從 Client(網頁，手機) 與 Server 不同角度是怎麼看帶 RAMEN 系統。

然而 RAMEN 有一些極限是團隊想要改善的，包含
1. RAMEN 底層是基於 text-based 的傳輸，所以對於要傳送影片，聲音等非純文字檔案就不夠有效率，需要進行一些轉換。
2. SSE 的架構是個單方向的連線傳輸，該架構下某些狀態訊息的傳輸要等到最多 30 秒才可以確認，這對於很即時的應用來說是極為不便的
3. ACK 的傳輸目前也是不夠有效率，一種改善方式就是採用雙向連接，但是這意味整體 Connection 數量就會變成兩倍，底層架構要維護的連線數量會直接翻倍

當前 RAMEN 實務上可以運行，但是上述的一些問題使得團隊想要嘗試改善，最後就決定整體轉換到基於 QUIC/HTTP3 的 gRPC 協定。
對於團隊來說最大的吸引點是 天生連線就是雙向溝通，這意味 Client/Server 可以更即時的交換彼此的訊息。

後半部分都在描述一些轉移的過程以及新的架構方式
最後則是列出幾個轉移過程中的學習重點，如
1. Concurrency Issues
2. Message Flow Control
3. Graceful Shutdown Handling
4. Handling Missing Callbacks
5. Payload Compression -> 這個議題我覺得很有趣，因為 Uber 使用遍布全球，不是每個使用者都有良好的手機網路，內部發現對於使用 3G 網路的使用者來說，抓一個超過 1MB 的檔案就要花費快一分鐘，整個使用者體驗非常差，透過 Gzip 的壓縮能夠把時間減少到剩下五秒左右，使用者體驗大幅度上升


對於該架構轉換有興趣的可以看看本文

標題: 「Azure 服務炸給你看...」
類別: Usecase
連結: https://status.azure.com/en-gb/status

昨天開始 Azure 的服務就各種不穩，追根究底原因是底層 Ubuntu 上新版套件 systemd-resolved(https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119) 出現問題，該套件負責的則是系統上的 DNS 解析功能，所以受影響的機器其 DNS 解析就一起出包。
當 OS 出包，各種往上疊加的應用就一起出包，如 AKS...等

雖然容器化跟 YAML 好棒棒，但是平時還是要跟 OS 當好朋友，遇到問題時才看得懂到底發生什麼事情，以及自己如果要先行處理的話可以怎麼處理，畢竟不是所有系統的東西都可以用 YAML 搞定的。

標題: 「十本推薦閱讀的 DevOps 相關書籍」
類別: Usecase
連結: https://medium.com/@bestarion/10-books-make-you-become-a-perfect-devops-engineer-fcb1b83a079

作者列舉了九本(雖然標題寫10本..)其認為對於 DevOps 職涯發展有幫助的相關書籍，每本書籍都有列出其大綱，作者，相關重點以及購買連結，其中最知名的鳳凰專案也當然不會被錯過。
1. The DevOps Handbook
2. The Phoenix Project
3. DevOps for Developers
4. The Unicorn Project
5. Effective DevOps
6. Continuous Delivery
7. The DevOps Adoption Playbook
8. Accelerate
9. Infrastructure as Code: Managing Servers in the Cloud

標題: 「Kubernetes 1.25 改動差異」
類別: Kubernetes
連結: https://www.cncf.io/blog/2022/09/02/kubernetes-version-1-25-everything-you-should-know/

今年八月份是 kubernetes 1.25 的正式發行，除了帥氣的小 logo 外也帶來非常多的改動，這些改動大部分都是既有功能的狀態轉移，譬如從 alpha/beta 等版本轉移到 stable，一下就幫大家節錄一下這次的改版有哪些值得注意的新功能，節錄中就不特別針對新功能還是狀態轉移進行區別。


# Apps
1. StatefulSet 新增一個參數，minReadySeconds，該參數用來提供一個額外的緩衝區間讓 Container 可以有更好的方式去處理需要過長的啟動時間
2. Cronjob 未來設定時可以特別使用 TimeZone 的選項來描述該時間對應的時區，而不用全部依賴叢集內 Controller 的時區

# Auth
1. PodSecurityPolicy 自從 1.21 被標示為即將捨棄，1.25 則是正式捨棄
2. 支援自動處理 KMS(Key Management Service ) 上的 Key rotate

# Network
1. NetworkPolicy 中可以透過 endPort 這個欄位來描述一個範圍的 Pod，不論是 Ingress 或是 Egress 現在就可以透過 endPort 一次描述一個區間，而不需要像過往一樣每個 Port 分開寫
2. 過往創建 Cluster 的時候可以指定 Service IP 的範圍，而所有自動創建的 Service 都會使用這個區間的 IP，如果有特別需求時使用者是可以手動指定想要用的 IP，現在透過 ServiceIPStaticSubrange 這個新的欄位可以讓使用者更順利地去手動設定想要的 ServiceIP 同時也可以確保自動設定的 Service IP 不會與手動的重疊已產生IP重複問題

# Node
1. 前幾篇文章介紹的除錯方式， Ephemeral Containers 如今也正式進入到 stable 階段，這個方式我認為未來是除錯路上必備的技能之一
2. cgroups v2 的整合也到了尾聲， 1.25 正式宣告為 stable 版本，不過我對於 cgroup, cgroup v2 的看法大概是其實真的花時間去理解這些的使用者根本沒多少，其改動到底有影響什麼大部分應該都沒有感覺
3. liveness 中的新欄位 terminationGracePeriodSeconds 也正式到 stable 階段了。

# Storage
1. In-Tree Storage diver 到 CSI 的轉移繼續往前推進，其中包含已經移除，即將移除以及相關正式轉移的相關儲存方案，如下
Depreciation: GlusterFS, Portworx
Removal: The Flocker, Quobyte, and StorageOS
Migration to CSI plugin: AWS EBS, GCE PD, vSphere
2. 未來將可以動態的去修改預設的 storageclass 名稱，而非只能使用 cluster 創建時的預設名稱而已

文章中還有其他的小改動，有興趣的可以去觀看

標題: 「Istio 迎來 sidecar less 的架構，全新 ambient mesh 的宣布」
類別: Network
連結: https://istio.io/latest/blog/2022/introducing-ambient-mesh


Istio 於上週宣布其新架構的推出，Ambient Mesh 是基於 sidecarless 全新架構，有玩過 istio 的朋友一定都知道為了達成 istio 內各種如流量管理，mTLS等功能，實際上每個應用程式旁邊都會部署一個基於 envoy 的 sidecar 容器，該容器會無縫的截取相關網路流量並且進行後續處理來實作各式各樣功能。

還記得在數個月前當 cillium 宣布要以 eBPF 打造一個無 sidecar 的全新 service mesh 時就有很多討論，其中最大的就是 sidecar 是必要的，沒有辦法變成 node 層級的 agent 來處理各種 service mesh 需求。

而如今連 istio 自己都跳下來要嘗試進行 sidecarless 的修正，該架構主要會將整個架構分成兩個層級，分別處理 l4 與 l7 不同的流量，其架構也有些許不同。
lecel 4 會基於節點為單位的 agent 搭建一套 zero trut tunnel , 而 l7 的設計考量到 enovy 本身沒有多租戶的設計，擔心流量會互相吃掉影響，因此對應的 webproxy point 架構因應而生。

目前整體還是測試階段，團隊希望透過這個方式未來可以讓使用者有更平緩的導入過程同時也可以避免 sidecar 佔用過多系統資源

標題: 「用 YAML 控制 Netlink... YAML 工程師大躍進嗎」
類別: Network
連結: https://lpc.events/event/16/contributions/1347/attachments/1022/1982/YAML%20Neltink.pdf


本週於 Dublin 舉辦的 Linux Plumbers Conference 看到一個有趣的專案發想，該專案 YNL 的全名是 YAML Netlink，其目的是想要透過 YAML 的方式來控制 Netlink

Netlink 是目前 Linux Kernel 非常重要的系統，讓 User 與 Kernel 間可以透過其來交換各種網路相關訊息，從讀取到控制都應有盡有
而這個專案採取的方式是讓使用轉撰寫基於 YAML 格式的敘述，接者將其轉換成底層 Netlink 真正所用的協定格式並與 Kernel 互動

除了連結的投影片外，底下也有該場次的錄影分享
https://www.youtube.com/watch?v=9QkXIQXkaQk&t=2640s

標題: 「基於 ebpf 的輕量級微服務監控服務 」
類別: Network
連結: https://github.com/coroot/coroot

隨者 ebpf 的蓬勃發展，愈來愈多應用嘗試透過 ebpf 的概念來實作不需要動到應用程式的監控解決方式，老實說這方面的類型非常多，基本上都會包含譬如
1. 微服務之間的呼叫關係，這部分通常都會基於網路拓墣的概念去展現彼此之間的呼叫關係，能夠幫助管理員釐清整個網路流量走向
2. 微服務之間的流量分析，從基本的 L4 到 L7 等，能夠直接列出更詳細的封包內容
3. 內建 Tracing 概念來揭露單一流量橫跨不同微服務所花費的時間，能夠幫忙找尋可能的效能瓶頸
4. ...等

除了 ebpf 官網所列舉的各種服務外，本篇文章分享的是一個相對的輕量級解決方案，除了上述的基本功能外，其有針對 PostgreSQL 進行特別整合，能夠列出到底是哪些 Query 產生大量的資源消耗，同時針對 lock 等也可以列出更多幫助除錯的資訊

標題: 「一張幫助 SRE 快速理解所有大廠最新消息的整理網站」
類別: Other
連結: https://www.sreboard.com/


該網站簡單直白，自動幫你追蹤相關網站/社群/知名部落格等最新文章，譬如
1. Ansible
2. CNCF
3. AWS
4. Docker
5. GCP
6. ...等

我覺得如果可以培養成習慣，也許可以每天上班前快速的瀏覽一下有什麼最新消息直得注意也是一個不錯的方式

標題: 「幫助重構 Terraform 減少大量 move 語法的開源專案 tfautomv」
類別: Other
連結: https://github.com/padok-team/tfautomv


Terraform 自從 1.1 後有支援一個名為 move 的特殊語法，該語法的用途是當你今天需要因為團隊規模或是其他因素想要針對 Terraform 進行重構而提供的一種特別語法。
舉例來說，假設之前透過 Terraform 內創造一個 aws_instance.a 的物件，但是重構後需要將該名稱給換成 b，之前的命名不夠精準。
預設情況下直接改名稱， Terraform 會認為這兩個是不同的物件，因此會幫你把 aws_instance.a 給刪除，並且重新創建一個 aws_instance.b。
但是會想要進行重構的團隊鐵定不想要運行的架構整個被砍掉，所以透過這個新的 move 語法就能夠告知 Terraform 這兩個物件需要轉移，請把所有跟 aws_instance.a 有關的物件都視為 aws_instance.b
而本文介紹的專案 tfautomv，顧名思義， TerraForm Auto Move，就是要幫助開發者可以更輕鬆地去使用 move 語法來重構與調整整個 TF 資料夾與程式碼。
如果有重構需求的也許可以看看這個專案會不會有幫助

標題: 「從 GPU 使用者的角度來看，為什麼 AWS 與 GCP 大不同」
類別: Other
連結: https://freeman.vc/notes/aws-vs-gcp-reliability-is-wildly-different

這篇文章是作者要探討從 AWS/GCP 不同平台去要求 GPU 的心得，作者於兩週的時機陸陸續續地去要求 T4 GPU 卡，最終數量達到三千張。
文中唯一的圖片就是要求 GPU 的效能分析，主要是要探討要花費多少時間才可以獲得一張可用的 GPU 卡
圖中去觀察可以看得到
1. AWS 所需時間非常快且非常穩定，基本上就是一條直線
2. GCP 所需時間久且不穩定，時間跳來跳去

AWS 平均不到 15 秒，而 GCP 卻要 42 秒左右，此外從發生錯誤的角度來看，整個過程 AWS 只有發生一次錯誤，而 GCP 卻發生了 84 次的錯誤。
所以從整體結果來看，作者認為如果你今天有任何因為需求而即時加開 GPU 的可能性的話，實在想不到用 GCP 而不是 AWS 的理由
詳細介紹可以參閱全文

標題: 「以 Terrafrom 來控管 Grafana Alert」
類別: Other
連結: https://grafana.com/blog/2022/09/20/grafana-alerts-as-code-get-started-with-terraform-and-grafana-alerting/

通常使用 Grafana + Prometheus 組合包的人都會面臨一個問題，就是告警的部分到底要使用 Prometheus Alertmanager 還是 Grafana Alert，兩者各有各的好處以及優缺點
特別是當你 Grafana 整合 loki 同時處理 log 時就能夠透過 Grafana Alert 針對 log 訊息來觸發 alert，整體會更加靈活。

不過過往使用 Grafana Alert 的時候如何去維護這些設定檔案則是一個困難事情，雖然透過 YAML 可以很順利的將 Grafana 給搭建起來，但是對於其內部的設定還是仰賴手動設定來處理
而官方介紹的 Terraform provider 則是介紹如何透過 TF 來設定你的 Grafana Alert，如果可以順利整合到 TF 中，那透過 Git 管理搭配 CI/CD 來自動化管理 Grafana Alert 似乎就不是個問題，也許能夠減少更多手動設定的部分，有興趣的歡迎研究看看