標題: 「八個你可能不知道的 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 似乎就不是個問題，也許能夠減少更多手動設定的部分，有興趣的歡迎研究看看

標題: 「Terraform: Up & Running 書籍第三版簡單概述 」
類別: Other
連結: https://blog.gruntwork.io/terraform-up-running-3rd-edition-is-now-published-4b99804d922a

本文作者就是本文要探討書籍的作者，Terraform: Up & Running 該書籍收錄與整理了實務上 Terraform 會遇到的各種問題以及對應的解決方式，此外本篇文章也發布於 Gruntwork 上，而 Gruntwork 最著名的專案莫過於 Terragrunt 以及 Terratest，因此該團隊對於 Terrafrom 的開發與應用上並定累積了很多實務上的想法，這類型的想法也當然了變成上述兩套開源軟體開發的動力與目標。

本文簡單地從第三版的書籍中裡面挑選幾個常見的問題來介紹，包含
1. Validation: 如何透過 validation, precondition, postcondition 等功能來來進行部署前後的檢查
2. Refactoring: 如果需要針對 resrouce 重新命名與改變，新版要如何透過 move 來搬移這些資源
3. Static Analysis: 除了真正執行你的 TF code 來達到測試外，不執行的靜態測試有哪些工具可以執行，這類型的工具又有哪些的差異及特色
4. Policy Enforecement: 近幾年流行的 Policy as a code 要如何整合到 TF 環境中，如果團隊中針對 TF 部署的資源都有相關的 policy 要遵守，這類型的 policy 要如何整合到 TF 的開發與部署週期


文章中針對這幾個區塊有更詳細的介紹，包含每個問題以及相關解法，Terraform 重度使用者推薦看一下這系列文，甚至可以考慮購買一下原文書來閱讀

標題: 「ArgoCD v2.5 release preview 」
類別: CICD
連結: https://blog.argoproj.io/argo-cd-v2-5-release-candidate-e2121f2002ba


距離 2.4 正式釋出才短短四個多月，現在 ArgoCD 近日就推出了 2.5 的 preview 版本，這次的 2.5 版本除了基本的文件與臭蟲外，新增了高達 58 項的新功能與改正，這些功能包含
1. Beta Support for Server-Side Apply
1.22 所正式 GA 的 Server-Side Apply(SSA) 將被引入到 ArgoCD 的更新策略中，SSA 天生的特性使得其更適合去透過 dry-ryn 來預知錯誤同時更新檔案內的過程中還有機會可以減少步驟
2. API and CLI Support for ApplicationSets, and Advanced Templating
使用 API/CLI 的開發者目前都可以透過這些介面來操控 appset 這類型的資源，譬如指令 "argocd appset"，此外 appset 本身也強化其 template 的部分
4. New Project-Level Restrictions
部署資源到 Project 的時候現在加入 ! 這個反向指示的用法，可以針對如 cluster/namespace 的資源來達到更靈活的控管，譬如資源只能部署到特定 namespace 以外或是 cluster 以外

5. Better Network Security
目前預設情況下 ArgoCD Server 與內建的 Dex 之間的流量都預設加密，此外如果 CNI 有支援 NetworkPolicy 的話，其 ingress/egress 的規則也被重新改寫，新改寫的規則更加精準也嚴格，期盼能夠提升整體網路安全性。



有使用 ArgoCD 的讀者可以稍微看一下 release doc，有多餘機器的也可以嘗試使用看看 v2.5，看看是否有解決什麼目前 2.4 遇到的困境，有任何問題也都可以回饋給官方讓官方一起改進

標題: 「基於 Rust 開發的各種CLI替代工具」
類別: tools
連結: https://danielgafni.medium.com/the-modern-linux-cli-stack-46253688b53d

本文作者想要分享各種基於 Rust 開發的各種跨平台工具，這些工具與過往常用的工具比較起來到底哪些對於日常生產力有更好的提升與幫助

舉例來說，作者目前常用的組合技如下
shell: zsh
plugin manager: oh-my-zsh / antigen
prompt: powerlevel10k
terminal multiplexer: tmux

上述工具替換到 Rust 為主的新工具則有下列選擇

shell: nushell
prompt: starship
terminal multiplexer: zellij


文章後半段則針對 nushell, starship, zellij 等工具進行簡單介紹，此外還有一些強化工具，譬如 bat(cat強化版) 等


這類型的新工具目前看起來最大的改變就是視覺化的方式呈現，這部分則就很看人的使用情境，如果平常的使用很仰賴 | .... 等各種工具串接的話，也許這類型的視覺化就沒有太大誘因，此外另外一個特別的點是設定，文章有提到這類型的工具設定起來都愈來愈簡單，甚至可以透過 Yaml/Toml 等格式來設定

有興趣的就可以針對這類型工具去玩看看


https://medium.com/swlh/break-down-kubernetes-server-side-apply-5d59f6a14e26

https://danielgafni.medium.com/the-modern-linux-cli-stack-46253688b53d

標題: 「別人用 AWS 不代表你要用 AWS」
類別: usecases
連結: https://www.karlsutt.com/articles/you-should-not-be-using-aws/


本篇文章不是一個深度技術文，不過更像是一個文化潮流的省思文，文章中以 AWS 為範例去闡述現在的潮流就是「成功的人用，我也要用」的思維
文中提到「Just because Netflix, which accounts for about 15% of the global internet traffic, has built a complex architecture of custom software and microservices on top of a popular public cloud provider does not mean you absolutely, positively have to replicate their setup.」

想想你的應用規模跟架構，再想想 Netflix 跟你的差異，你真的覺得你需要一開始就打造跟 Netflix 一樣的底層架構嗎？

此外作者還提出一個迷思概念，很多使用最新技術的案例其實成功的原因不是「使用最新最潮的技術」，這些「最新最潮的技術」只是剛剛好被用到而已。
最後文末有三個概念提出分別是
1. Optimise for operational simplicity
2. Optimise for internal simplicity
3. Focus on delivering value to your users

有興趣的可以閱讀全文

標題: 「從 SRE 的觀點來看，如何打造一個對開發也對維運都有好處的軟體服務」
類別: usecases
連結: https://www.willett.io/posts/precepts/


作者汲取這多年來參與不同規模團隊合作下的經驗，思考如何打造出一個更適合維運的應用服務，這些經驗的目的並不是打造一個 100% 完美絕對穩到炸不會出包的服務，相反的
更注重於「如何透過 20% 的努力來獲得 80% 的可靠性，同時開發人員也不會覺得窒礙難行」

文章主要分成四大項，分別是
Coding
Merging
Deploying
Operating

每大項內又有幾個小項目分別舉例，這邊稍微汲取幾個範例與想法，作者的每一個想法不一定適合每個團隊，不過可以聽取看看不同人的想法來想想這些提到的優缺點目前團隊工作流程是否有出現？ 有的話應該要怎麼解決？或是現有的解決方式是否有改進的空間？

# Coding
No in-code fallbacks for configs -> 如果你的應用程式運行初期讀取不到任何應該要讀到的設定時，就應該儘早死去來達成 fail fast, fail early 的概念， config 往往會決定應用程式的行為，不會動或是缺少設定的話就及早自殺，讓整個問題可以更快被發現，最害怕的就是明明少了一個重要的 config 結果該 config 相關的程式碼要到重要時刻才會被執行到，然後整個爆炸時間點就被延後，最後還要花費更多的時間與精力去找問題發生點

Avoid state like the plagu -> 有狀態的程式其管理複雜度不是無狀態程式可以比擬的，就算有了各種容器管理機制整體複雜度還是非常高，能的話將這些狀態都送往 DB/Cache 去處理，盡可能打造一個好維護的無狀態程式

Never give up on local testing -> 相較於 CI 等自動化測試等流程來說，本地測試所需的時間其實更少，從消耗時間來看是能夠提升開發者生產速度的，然而本地測試相對麻煩的就是環境的建置，因此有機會的，可以嘗試透過容器化的方式來系統化建置測試環境，讓開發者都可以一邊開發一邊本地測試。


# Merging
For infra changes, make plans extremely obvious -> 想辦法讓任何 infra 的改變是顯而易見可預料的，譬如使用 Terraform 進行管理的團隊最好將 terraform plan 的結果整合到 CI 與 Review 的過程中，這樣大家都可以一目瞭然到底這次的修改會產生什麼樣的變化，同樣的對於 Helm 應用來說，可以透過第三方plugin, Helm diff 來幫你檢視一下當前版本與即將升級版本的差異，到底有哪些資源會被創立哪些資源會被移除。


# Operating

Use Helm -> 使用 Helm 或是其他如 kustomize, jsonnet...etc 等工具來管理 Kubernetes 檔案，非特殊情況不要一直透過 kubectl apply/edit/delete 等來管理應用程式的部署狀況，所有的部署情況都應該可以被追蹤與管理

Avoid operators and CRDs -> Kubernetes 好棒棒，但是對於開發者來說，從 Container 到 Kubernters 的鴻溝太大，這中間的學習過程一旦扯入了 CRD 就會有更多未知的事情發生，所以作者認為能的話盡量讓事情保持簡單，減少用 operators 等機制這些增加複雜性的東西

標題: 「由 Google 開發的 Kubernetes Queue 開源方案: Kueue」
類別: Kubernetes
連結: https://kubernetes.io/blog/2022/10/04/introducing-kueue/

本篇來自官方部落格的文章要介紹的是由 kubernetes-sig 底下所開發的專案, Kueue 是一套專門針對 Kubernetes Job 的 Queue 管理開源解決方案

Job queueing 是一個不論是地端或是雲端都可以用到的功能，將 Kubernetes Job 給進行佇列排程確保當前有限的系統資源可以依序的被這些 Job 存取
而 Kueue 則是基於 Job 這個運算單元上提供了 Job queueing 的功能，可以決定哪些 Job 要馬上執行，哪些要等待以及哪些資源要被這些 Job 給存取。

文章提到幾個 Job queueing 希望達到的功能有
1. 多租戶環境下希望每個租戶的能夠使用的資源是公平分配的，譬如不活躍租戶底下的資源可以暫時借給其他活躍的租戶去運行
2. Job 可以彈性的根據不同環境來配置不同的資源用量，譬如 spot/on-demand，或是有不同型號的 CPU/GPU 等
3. 能夠根據資源的配置而自動擴展

原生的 Kubernetes 的 Job/Cronjob 功能非常單純，所以需求都要仰賴其他解決方案，而 Kueue 認為這些解決方案的問題都是他們都必須要替換掉現存穩定的 kube-scheudler/job-controller，這些可能會造成
維運上的問題甚至是造成 job APIs 的複雜化，所以如果可以從原生內部直接支援，對於所有使用者來說則是會更好的使用方式


有興趣的可以閱讀全文來研究看看這個開發中的專案