標題: 「手把手教你系統設計」
類別: others
連結: https://www.hiredintech.com/system-design

今天介紹的這個網站是一個非常適合練習與學習系統設計的網站，該網站探討了系統設計於實務上的範疇，搭配些許影片進行一系列的介紹，此外除了基本的系統設計外，也探討了 Scalability 這個非常重要的概念，特別是若要設計一個有此特性的系統時有哪些點需要考慮
最後以搭建一個簡易版本的 Twitter 為範例開始逐步探討，包含
1 釐清問題與需求
2 High-Level 設計
3 Low-Level 的潛在問題
4 其他如 DB, Traffic 等延伸議題

對於想要練習系統設計相關題目的人非常值得花點時間跑完該網站

標題: 「Podman v4.4.0 將逐漸拋棄CNI作為其底層網路架構」
類別: tools
連結: https://github.com/containers/podman/releases/tag/v4.4.0

Podman 本週正式釋出其 v4.4.0 版本，其 release note 裡面有一個改動非常有趣
「CNI is being deprecated from Podman and support will be dropped at a future date. Netavark is now advised and is the default network backend for Podman.」

簡單來說，過去 Podman 使用的是 CNI 的架構來為其 container 提供網路功能，而從這個版本開始就正式標示為 deprecated 的版本並且於未來的版本將不再繼續支援
由於 Podman 本身就是一個本地開發測試用的軟體，同時本身也沒有透過 CRI 介面去支援 Kubernetes，因此這個改動對於 Kubernetes 本身沒有任何影響，單純是 Podman 自己生態系的改動。

取而代之的則是由另外一個專門為了 Podman 生態而開發的底層網路架構, Netavark(https://github.com/containers/netavark)。

其官網敘述非常直白
「Netavark is a rust based network stack for containers. It is being designed to work with Podman but is also applicable for other OCI container management applications.」
基於 Rust 開發並且以 Podman 為主不過其他 OCI 相容的容器也可以使用。

至於為什麼 Podman 要切換過去，我認為主要有以下幾個原因
1 CNI 的發展目的更適合 Kubernetes 這種多節點的叢集架構，Podman 的目標則是單一節點上的容器管理系統
2 隨者使用者的使用環境愈來愈複雜，CNI 有時候很難輕易地達成環境架設，特別是想要讓容器運行到多層網路之中，譬如多網卡等情境，可以弄但是就麻煩
3 CNI 是純框架設計，功能全部仰賴各種 Plugin，如 Flannel,Calico,Cilium…etc，所以各種功能都還要仰賴第三方 Plugin 去實作，不然就需要自己完整實作一套 CNI Plugin

相對於 CNI 來說 Netavark 的特色有
1 不仰賴各種 Plugin，本身就將過往所有網路功能都直接實作掉，也意味者所有的網路功能都直接實作於 Netavark 中，沒有其他 Plugin 的需求
2 不同於 CNI 各種串接來串接去的 Plugin 方式， Netavark 單一工具的執行方式其實可以用更短的時間去設定完成整個容器網路，對於單一節點的應用上可以榨取更多時間


如果本身是一個 Podman 愛好者的話，可以花些時間去看一下 Netavark 以及其 DNS 夥伴 Aardvark 的相關文章以方便未來更加了解 Podman 的使用與除錯

標題: 「利用 ChatGPT 來提高團隊 Kubernetes 除錯效率」
類別: tools
連結: https://medium.com/dev-genius/k8s-chatgpt-bot-for-intelligent-troubleshooting-36e0a4a071c5


隨者 ChatGPT 最近的爆紅，愈來愈多行業與領域都嘗試透過 ChatGPT 來提升整體效率，雖然有使用過的人就知道很多時候 ChatGPT 沒有辦法就問題給予非常精準的答案甚至給予錯誤的答案，但是大部分時候都可以幫忙省去 Google 的時間

今天這篇文章作者想要分享一個透過 ChatGPT 來查詢 K8s issue 的小專案，該專案中 ChatGPT 會搭配 AlertManager 一同使用，將 Alertmanager 送來的錯誤訊息轉送到 ChatGPT 中讓其提供一些基本的概念以及除錯方式，最後將這個專案給整合到 Slack 中。

雖然該專案不一定可以輕易導入，但是可以看到愈來愈多人用不同的方式來使用 ChatGPT，花點時間玩看看這個工具，看看如何可以用其為自己的日常工作提供不同面向的變化吧

標題: 「讓 ChatGPT 考看看 AWS 證照?」
類別: others
連結: https://medium.com/@miguelsalva/chatgpt-goes-certified-aws-82747a2e4619

隨者 ChatGPT 的橫空出世，作者想要試試看這類型的服務是否有辦法通過各種 AWS 的相關證照，由於考試規則的限制與規範，並沒有辦法直接將 ChatGPT 套用到正式考試中，因此作者就透過 AWS 所公開的示範考試題目來逐一測試 ChatGPT

作者總共嘗試了 12 個不同的 AWS 證照，包含
1 CLF-C01: AWS Certified Cloud Practitioner
2 SAA-C03: AWS Certified Solutions Architect — Associate
3 DVA-C01: AWS Certified Developer — Associate
4 SOA-C02: AWS Certified SysOps Administrator — Associate
5 SAP-C02: AWS Certified Solutions Architect — Professional
6 DOP-001: AWS Certified DevOps Engineer — Professional
7 ANS-C01: AWS Certified Advanced Networking — Specialty
8 DAS-C01: AWS Certified Data Analytics — Specialty
9 DBS-C01: AWS Certified Database — Specialty
10 MLS-C01: AWS Certified Machine Learning — Specialty
11 SCS-C01: AWS Certified Security — Specialty
12 PAS-C01: AWS Certified: SAP on AWS — Specialty

每個證照都列出考試分數(滿分1000)以及通過的門檻分數。 最後 ChatGPT 順利的通過四個 Pass(No 1,3,4,11) ，其中有三個 Fail (2, 8, 12)的分數差一點就可以通過了。

根據證照的難易度來看的話， ChatGPT 通過了基礎等級的認證，兩張 Associate 的相關證照，一個 Specialty 等級的證照，而沒有通過半張 Professional 等級的證照

從這個角度來看，繼續追求證照作為條件的市場會不會受到影響?

標題: 「Tinder 為何以及如何打造屬於自己的 API GW」
類別: usecase
連結: https://medium.com/tinder/how-we-built-the-tinder-api-gateway-831c6ca5ceca

這篇Medium上的文章講述了Tinder是如何建立其API Gateway的，為了解決之前客戶端直接向Tinder的主應用伺服器發送請求的問題，Tinder創建了自己的API Gateway，API Gateway採用了微服務架構，這使得Tinder可以更輕鬆地管理其API Gateway，並支持更快的開發和部署。

Tinder的API Gateway是由Java撰寫，並使用Netflix的Zuul框架構建。Zuul是一個網關服務，允許開發人員建立反向代理和路由器，這些路由器可以將請求路由到網絡上的其他服務。Zuul還提供了一些內置的功能，如路由、過濾和反向代理，這些功能使Tinder可以更輕鬆地管理其API Gateway。

Tinder的API Gateway還具有一些特殊的功能，如基於用戶的路由、可靠的請求/回應記錄和指標追蹤等。基於用戶的路由允許Tinder根據用戶屬性（例如，使用語言、地理位置等）將請求路由到相應的伺服器。請求/回應記錄可以使開發人員更輕鬆地追蹤數據，並定位潛在的問題。指標追蹤允許Tinder監控API Gateway的性能和可用性。

總之，這篇文章介紹了Tinder是如何建立其API Gateway的過程和一些特殊功能，API Gateway的構建使Tinder可以更輕鬆地管理其API，實現更快、更安全和更有效的API管理和開發。閱讀這篇文章可以讓讀者對於如何構建API Gateway有更深入的了解，同時可以學習到一些關於微服務架構的知識。

標題: 「Tinder 如何打造一個專屬團隊使用的設計系統平台 Obsidian」
類別: usecase
連結: https://medium.com/tinder/building-obsidian-tinders-design-system-e127770d8e3f

這篇文章講述了Tinder是如何建立其設計系統 "Obsidian" 的，以及如何將其整合到Tinder應用程式中。 Obsidian旨在提供一組統一的設計樣式和元素，以使Tinder應用程式的開發更加一致和高效。

文章開始介紹了Tinder設計團隊如何決定建立設計系統。在Tinder快速發展的初期，Tinder的設計並不一致，這導致開發人員和設計師之間的困難以及更多的維護問題。為了解決這些問題，Tinder決定建立一個設計系統，這樣所有人都可以使用同一套設計樣式和元素進行開發。

接下來，文章介紹了Obsidian的幾個核心要素，包括顏色、圖標、字體、排版、按鈕等。這些要素都是Tinder開發人員在開發Tinder應用程式時需要考慮的重要因素。

此外，文章還介紹了如何使用Obsidian來開發Tinder應用程式。Tinder使用React Native來開發其應用程式，因此，Obsidian也需要與React Native進行整合。為此，Tinder設計團隊開發了一個名為 "Rally" 的React Native元件庫，這個元件庫包含了許多Obsidian中的設計元素，並且可以與React Native一起使用。

總之，這篇文章介紹了Tinder是如何建立其設計系統 "Obsidian" 的，以及如何將其整合到Tinder應用程式中。 Obsidian提供了一組統一的設計樣式和元素，使Tinder開發人員可以更加一致和高效地進行開發。通過使用Obsidian，Tinder能夠更好地管理其應用程式的設計和開發，並提供一致性的用戶體驗。

標題: 「Kubernetes 網路除錯之旅」
類別: network
連結: https://www.hwchiu.com/k8s-network-debug.html

許久沒寫原創文章，因此最近就將去年於 LINE & CNTUG #49 Meetup 的分享內容給文字化。

本篇文章嘗試用簡易的方式去介紹 Kubernetes 內的網路複雜性，強調簡單易用的網路功能背後是有多少複雜元件牽扯其中，因此要除錯網路問題沒有想像中的這麼簡單。

為了讓整體網路除錯更有效率與系統性，文章內闡述了一種網路思維來面對網路問題
1 分析網路流向，是東西向還是南北向
2 釐清問題發生點，到底問題是發生於哪個層級中

有了上述思路後，搭配畫圖的方式將整個架構圖勾勒出來，並且逐一檢查縮小問題發生點，最後找出真正造成網路不通的元兇。

標題: 「kubecolor，色彩化 kubectl 的輸出讓你更快辨識常見欄位」
類別: Tools
連結: https://blog.devgenius.io/k8s-kubecolor-introduction-3d650effc36f

今天分享的是一個小工具，本質上就是 kubectl 只是對於輸出結果進行色彩化的改造，讓原本預設全部都一樣顏色的指令輸出加上不同顏色
舉例來說透過 kubectl describe pod 觀看資訊時，不同的顏色使得觀看整個結果時會更加順眼與有效率，可以清楚的知道哪些字是“key"哪些是”value"，特別是要找尋特定 key 的時候我的經驗會比純黑白來得有效率一點，最簡單的用法其實可以直接透過 alias 取代 kubectl，因此實務使用上也不會有任何新指令的學習，有興趣的人都可以試試看

標題: 「完整介紹 Terragrunt，讓你理解其角色與用途 」
類別: Tools
連結: https://blog.devops.dev/a-complete-overview-of-terragrunt-fbebb53fbd42

隨者 IaC 概念的普及，愈來愈多團隊使用 Terraform 來管理自身架構，除了基本撰寫 TF 檔案外，使用官方 Module 或是自行撰寫 Module 都可以大幅簡化重複的程式碼來達到 DRY 的概念。
然而某些情況下，想要將一整套應用服務部署到不同環境時，甚至是不同 cloud providers 的時候就會開始思考整個資料夾的結構要怎麼設計， Terraform Module 要怎麼設計與使用才可以盡可能地減少重複程式碼。

舉例來說，很多時候會透過
1. Module 描述很多底層元件與部署
2. Main.tf 去呼叫各個 module 來組合出一個完整應用

如果想要將 main.tf 給部署到不同環境，不同地區等的時候，最直接的方法就是將 main.tf 給複製多份搭配不同變數即可
然而這種情況下對於要維護 main.tf(甚至有多個*.tf) 檔案的話就會變得稍微麻煩。
有些人會透過 soft-link 的方式確保多個資料夾共享一份檔案來簡化維護而有些則是會用其他工具來幫助管理 Terraform，而本篇的 Terragrunt 則是後者工具中非常知名的一個解決方案。

Terragrunt 算是一個 Terrafrom Wrapper，因此能夠以更上層的角度去幫忙管理與呼叫你的 TF Code，文章開頭就直接闡明使用 Terragrunt 的幾個理由，包括

1. Keep your backend configuration DRY
2. Keep your Terraform CLI arguments DRY
3. Execute Terraform commands on multiple modules at once
4. Execute custom code before or after running Terraform.
5. Wo rk with multiple cloud accounts

(1) 的情境是當你環境愈來愈多時，每個 TF 應用你都會撰寫 backend 來確保 TF code 可以被多人共享與協同合作，而 backend 要避免路徑重複以免互相蓋來蓋去造成問題。基本上這個問題只要仔細與小心，每次創建新資料夾時都有準確去修改就可以解決這個問題，只是通常隨者架構愈來愈龐大，參與的人愈來愈多，有時候就會發生人為錯誤，創建資料夾直接複製其他的檔案忘了改，或是路徑沒有按照規則去撰寫。
Terragrunt 提供了一些方式去簡化操作，規劃一次後續使用就無需擔心一切都會自動被處理好

其餘的好處文章內都有詳細介紹用法與情境，對這套工具不熟悉的可以看看這篇文章，非常詳細的講述整個概念

標題: 「Reddit 於 3/14 升級 Kubernetes 失敗的報告總結」
類別: Usecase
連結: https://www.reddit.com/r/RedditEng/comments/11xx5o0/you_broke_reddit_the_piday_outage/?rdt=39706

整篇文章滿長的，以敘述為主然後帶出一些關鍵點，這邊幫忙節錄幾個重點，有興趣的可以閱讀全文


1. Reddit 從 2009 就開始導入雲端架構，並且非常早期就使用 Kubernetes
2. 歷史包袱導致架構中的 Kubernetes 都採用不同的方式建置與維護，譬如有一批就是使用 Kubeadm
3. 團隊有進行 Kubernetes 的升級演練，即使遇到問題也有順利解決並且紀錄
4. 升級時間定於 03/14/2023 19:00 UTC (Kubernetes 1.23 -> 1.24)
5. 升級後兩分鐘發現系統問題，網站無法使用，第一件觀察到的事情就是 Monitoring 上面完全收不到任何 Metrics，沒有 Metrics 就如同瞎子摸象很難馬上知道發生什麼事情
6. 有發現一些 DNS 的問題，但是這問題是首次遇見，先前各種測試升級都沒有遇到
7. 部署失敗想嘗試執行 Plan A，就是馬上退版，但是 Kubernetes 並沒有提供 Downgrade 的方式，畢竟每次升級都會有些許的 Scheme 與 API 版本修正，唯一的降板方式就是需要透過整個狀態的備份與還原
8. 團隊有開發專屬的備份與還原應用程式，不過該程式只有餘測試環境中反覆測試，並沒有真的對 Production 環境測試，因此對於要不要運行這個備份程式其實團隊是有信心疑慮的，也不確定跑下去要花少時間，這段時間整個網站停機要多久。因此決定先行繼續研究問題嘗試修復
9. 花了將近兩個多小時觀察到各種現象然後沒有辦法解決，於是決定備份還原
10. 事後檢查原因是因為 Calico 沒有辦法正確部署相關的 Routing 規則，原因是因為 Calico 用來尋找節點的 nodeSelector 於 K8s 1.24 被改變了
11. 前面提到，該 K8s 是由 Kubeadm 建造的，請閱讀下列連結中關於 "node-role.kubernetes.io/master" 的段落 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#no-really-you-must-read-this-before-you-upgrade


如果要更精簡的說法就是
Kubeadm 從 1.23 -> 1.24 的升級有改變其 control plan 的預設 label，這會使得所有相依這個 label 的服務出現問題

標題: 「少少幾行設定就解決了 Kubernetes 那 gRPC 服務的 scaling 問題」
類別: network
連結: https://medium.com/jamf-engineering/how-three-lines-of-configuration-solved-our-grpc-scaling-issues-in-kubernetes-ca1ff13f7f06

本篇文章主要是探討 gRPC 於 Kubernetes 內因為負載平衡所導致的流量分配問題。
作者團隊中於 Kubernetes 中部署 gRPC 服務，由於 Kubernetes 內建的 Load-Balancing 是基於 L4 去處理，而 gPRC 則是基於 HTTP/2。
其中最大的問題是 HTTP/2 的一個精神就是基於一條 TCP 連線來傳送各種訊息，這種狀況遇到 Kubernetes L4 Load-Balancer 就會發生負載平衡根本發生不了。

試想一下今天 Kubernetes 中有兩個 gRPC Client 以及兩個 gRPC Server，今天所有的 Client 與 Server 都已經順利建立好 TCP 連線來處理後續 gRPC 訊息。

今天 gRPC Client 因為效能問題於是動態調整 Pod 的大小，從兩個變成四個，因此這種狀況下就會變成 4個 gRPC client 面對 2個 gRPC server。
一切運作正常直到 gRPC server 負荷不了，因此也自動調整 Pod 大小變成 四個 gRPC server。
這時候問題就來了，由於 TCP 連線已經建立完畢，所以先前的四個 gRPC client 還是會繼續把流量送給前面兩個 gRPC server，後面兩個新增的 gRPC server 則是不會接送到任何流量。

為了讓流量可以順利平均分攤，只好透過一些組合來重新調整 Pod 的數量最終達到流量分攤。

作者最後發現 gRPC 的 Server 有提供連線相關的設定，其中最重要的兩個設定分別是
MAX_CONNECTION_AGE
以及
MAX_CONNECTION_AGE_GRACE

其中官方關於 MAX_CONNECTION_AGE 的一個節錄也提到該選項的用法
This option can force the client to periodically reconnect to a L4 LB which allows spreading load more quickly.

對於 gRPC 效能與流量用法有興趣的人務必好好研究這個用法

標題: 「移轉 Legacy Application 到 Kubernetes 需要理解的四種 Pattern」
類別: Kubernetes
連結: https://itnext.io/4-container-design-patterns-for-kubernetes-a8593028b4cd

本篇文章作者描述將過往應用程式轉移到 Kubernetes 內很常遇到的問題，譬如
1. 輸出一律寫到檔案而非 Stdout
2. 不支援 Prometheus 因此沒辦法整合到 Monitoring 系統
3. 只能支援 HTTP 連線
... 等

大部分這些情況都可以透過修改程式碼的方式來完成，然而既然被稱為 Legacy 應用程式就有很大的機會這些應用程式現在屬於一種難以撼動的狀況，可能現有的人已經不熟當初的架構與程式語言，更別說要對其進行修改測試與發佈。

對於新專案來說這種情況不會發生，但是對於要將舊有服務導入到 Kubernetes 的情境中則並不是不可能發生，因此這時候如果可以擅用 Container 與 Pod 的特性來補足這些功能同時又不需要修改程式碼則是一個值得探討的方向

作者用非常淺顯易懂的方式來描述四種 Kubernetes 內很常見的設計模式，包含
1. Init Container
2. Sidecar
3. Ambassador
4. Adapter

如何利用這四種不同的模式來解決各種 Legacy 應用程式可能會遇到的問題，有興趣的可以稍微複習一下這些名詞與概念

標題: 「以 vcluster+ArgoCD 打造一個多租戶的 Kubernetes 叢集」
類別: kubernetes
連結: https://blog.devops.dev/multi-tenancy-with-vcluster-794de061fff1

作者團隊想要透過一個 Kubernetes 叢集的 namespace 來提供多租戶的使用方式，簡單來說就是 “Namespace as a Service”。
這個問題之所以麻煩是因為既有的 Kubernetes Namespace 並不是一個真正的隔離機制，有很多內建如 clusterrole, PV, storageclass 等物件都是沒有 namespace 概念的而是整個叢集共享的。

作者先前嘗試使用 vcluster 這個技術於 Kubernetes 叢集中創建一個全新的 Kubernetes 叢集，並且讓租戶使用這個新創立的 vCluster 來使用就不用擔心跟既有 Kubernetes 會有資源物件上的衝突。

然而提供全新一套給 Kubernetes 叢集給租戶聽起來很彈性自由，但是實務上對開發者來說不一定很方便，畢竟開發者更專注的是應用程式的開發而並非 Kubernetes 的操作與管理，因此如何
1 基於 vCluster 的機制提供一套獨立的 Kubernetes 叢集
2 整合 GitOps 的方式讓開發者可以用熟悉的方式去管理與部署自己的應用程式

因此本篇文章後半部分就是探討如何整合 vCluster +ArgoCD 提供一個完全友善的開發環境，讓開發者可以更簡易的去測試自己的東西同時也不擔心會影響彼此

標題: 「75 個 Kubernetes 的相關面試問題與答案」
類別: kubernetes
連結: https://medium.com/@bubu.tripathy/top-75-kubernetes-questions-and-answers-d677a0b87d79

Kubernetes 幾乎已經成為 Container Orchestration 領域上的共識標準，因此很多團為都會嘗試使用 Kubernetes 來管理服務
然而導入 Kubernetes 其影響的並不單純只是維運人員，對於小團隊來說，開發者勢必也要理解 Kubernetes 的概念才有辦法整合整個開發流程並且提高效率

本篇文章列出了基本的 75 的 Kubernetes 的基本概念，大抵上都是基本問題，不會涉入到非常進階的使用情境分析，但是對於分辨是否對 Kubernetes 有基本理解來說是滿有用的
也許對於 Junior 的職缺可以考慮用這類型的問題來快速判斷是否對 Kubernetes 有些許經驗與理解

標題: 「EKS v1.25 到 v1.26 的升級經驗談」
類別: kubernetes
連結: https://marcincuber.medium.com/amazon-eks-upgrade-journey-from-1-25-to-1-26-electrifying-79b287084eef

本篇文章是個系列文，作者每次升級都會撰寫一篇文章探討升級要注意的事項已經升級過程，從 v1.20 一路到 v1.26 每次版本的升級都有詳細記錄

其中這次 v1.26 的升級有幾個事項要注意
1 Container Registry 的位置改變，從 v1.26 以後所有過往使用 k8s.gcr.io 的位置都會改到 registry.k8s.io
2 Kuberlet 使用的 CRI 版本將會從 v1alpha2 變成 v1 版本，這個部分需要考慮的就是底層使用的 CRI Runtime 是否支援 v1 版本，以 containerd 來說至少要升級到 1.6.0 的版本
3 過往如果對於 Pod 要 Mount Volume 有權限控管的時候都會透過 fsGroup 的選項來調整掛載後的權限，未來可以把這個功能轉交到 CSI Driver 去處理，這意味所有用到該 Volume 的 Pod 可以直接仰賴 CSI Driver 去處理而不用每個 Pod 裡面都去設定
4 API Server 提供內建的 Metrics 讓管理人員知道所有 feature tag 的始動與否
此外從 API 的角度來看
1 autoscaling/v2beta2 正式退役，之後請改用 v2 版本
2 flowcontrol.apiserver.k8s.io/v1beta1 正式退役，請改用 flowcontrol.apiserver.k8s.io/v1beat2.

至於對 EKS 的使用者來說，升級前起先升級 AWS CNI 的版本到 1.12 否則你升級 EKS 後就會看到各種 CNI Plugin 的問題

標題: 「給資深開發者有關微服務的十個面試問題」
類別: Others
連結: https://medium.com/javarevisited/top-10-microservices-problem-solving-questions-for-5-to-10-years-experienced-developers-3391e4f6b591

這篇文章作者列出了十個關於微服務相關的問題，目標受眾為5-10年左右的開發者，每個問題都有給予的答案方向，問題都滿有趣且實際的，譬如

1 假設你開發套需要處理訂單的微服務系統，因為某些架構因素導致服務掛點，你要如何確保當服務恢復後沒有任何一個訂單被丟失且都能夠被妥善的處理
2 假設你要開發一套處理使用者帳號認證的微服務系統架構，你要如何確保你可以處理大量的請求且同時保持高可用性
3 假設你要開發的微服務架構要處理付款相關議題，要如何確保該服務足夠安全且所有使用者資訊也都受到保護
4 假設你的服務都會與 message queue 互動並且有多個服務會從其拿訊息處理，假設當有一個服務掛點沒有辦法順利取出資訊處理，你會採取何種策略來找到 root cause 並且除錯？
文章內還有其他六個題目，推薦有興趣的人花點時間看完

標題: 「90天 Senior DevOps 工程師報到攻略」
類別: Others
連結: https://medium.com/@alexrozdolskiy/a-step-by-step-guide-for-your-first-90-days-as-a-senior-devops-engineer-90b043cd764b

作者認為當今天被基於 Senior DevOps/SRE 此職位招聘時，公司對該職位的一個期待就是「自行解決問題」
很多時候可能會發現團隊中並沒有給予你一個非常明確的工作方向與進度，而這時候就是要仰賴你自行的能力去規劃整個工作進度與方向
針對那些沒有計畫的團隊，作者這邊給出一了一個三階段，總共 90 天的完整計畫，希望透過這個計畫能夠讓你不辜負此職位並且有效的帶領團隊成長

前30天
這個階段的手動目標是了解當前所有環境與架構並且為了未來所有改進與改善打好基底，包含
1 釐清整個組織的分佈與情況，包含
1 是否有整個工程團隊的組織架構
2 瞭解所有工程團隊用到的技術架構，包含 Backend/Frontend/Mobile …etc
3 瞭解所有資料團隊用到的技術架構，包含 (ML/Analytics/ …etc)
4 …等
2 釐清當前團隊中 DevOps 職位所扮演的角色，包含
1 Goals/KPIs/ 是什麼及如何制定
2 資安與權限控管目前如何設定
3 瞭解 SDLC (軟體開發生命週期) 的一切，包含部署方式，部署環境，監控...等
3 透過手動的方式來融入整個環境
1 透過 PR 的方式修復一些小 bug
2 參考文件並且修復任何不足之處

當有了上述的基本認知後，接下來就要開始思考自己的招聘能夠為團隊帶來什麼？
1 這個職位的目的與方向
2 新職位？還是取代舊有人員？
3 有無 OKRs/KPIs 等規劃?
4 有無相關 Agile/Kanban 規劃使用?

文章後半部分還針對 30-60 天，60-90 天兩個階段去探討，我覺得文章內容除了就職者之外，團隊主管也可以參考一下新招聘的 DevOps 初期應該要做什麼？ 要如何幫助他們快速 onboard 來釐清一切並且對團隊帶來正面的改善

標題: 「為何我拒絕成為 Amazon 內的 Senior Software Engineer」
類別: Others
連結: https://medium.com/@jamesryebread/why-i-will-never-be-a-senior-software-engineer-at-amazon-6613c66c2a6e

本篇文章作者的標題聳動其實整體核心內容很簡單，就是 WLB(Work Life Balance) 的取捨。

入職時，人人都懷有胸有大志，想要努力成長升遷，成為傳說中的十倍工程師，想要一路往上爬最終成為所謂的 Principal Enginner 並且過著千萬年薪的生活
然而隨者時間推移與工作型態發展，作者開始理解到自己其實並不如自己想像的聰明，平凡如自己要如何與一堆天才與高手共同競爭？ 如果真的有此機會升遷到更高階的職位那整個競爭與評比的壓力只會更大而且完全沒有信心能夠於這種競爭下存活

此外容易被人忽略的一點就是職位愈高，責任愈大，除了如過往的開發工作外還會有更多的會議需要參與討論，整體工時可能就會達到每週 60 小時。
此外升遷除了個人能力表現外，當前從事專案的熱門與影響力也會是一個評比表現，所以很多時候不是你能力不夠，而是當下這個時間點你就是無緣升遷，除非換組織換專案或是哪天時來運轉專案變得很重要，否則就會跟多數的同袍一樣，卡在 L5 數年。

結論來說，作者理解到自己想要追求的生活是成為一個出色的工程師，正常上下班，可以享受自己的夜晚從事自己喜歡的事情，而不是為了更多薪資(可能沒多到可以向五斗米般折腰?) 而夜以繼日的瘋狂工作，生活平衡才是自己追求的工作型態。

看完這篇文章可以完全理解那種感覺，隨者個人責任的變化以及升遷還要考慮到影響力與專業度的，因此愈來愈多的會議需要參加甚至帶領會議，而且從自己的團隊到跨足多個團得的會議都要處理，甚至當公司夠大有跨時區的團隊的時後就會出現早上六點第一個會議，晚上九點最後一個會議這種忙碌人生

至於這樣的生活與薪資水平是不是值得追求也沒有一定的答案，不過每個人都適合去思考一下自己追求的生活是什麼型態

標題: 「網際網路之父 Vint Cerf 坦承當年設計 TCP/IP 的三大錯誤」
類別: Others
連結: https://spectrum.ieee.org/vint-cerf-mistakes

簡單來說，從現今往回過去看個三個設計不足的點分別是
1 覺得 32 Bit 應該就足夠整個網際網路使用
1 沒有花費更多心思去探討資安的部分
2 沒有足夠理解 WWW 對於全球帶來的影響

從現今 IPv4 (32Bit) 的設計來回顧當年 1973 的設定其實也有點說不過去，畢竟 Cerf 也提到當年如果你說你要用一個 3.4 * 10^38 的大小來設計一個不確定會不會成功的實驗實在是有些瘋狂。
然而隨者網際網路的蓬勃發展， IP 數量開始出現耗盡的問題進而促使 IPv6 的發展，而 IPv6 初版則是 1998 年，距離現今也大概 25 年左右了，然而 IPv6 的落地與應用與 IPv4 是截然不同方向，對於使用者與開發者來說你有多少日常生活會使用 IPv6 地址的? 但是對於基礎建設商來說可能就不是如此，譬如 Nokia 提到的這篇簡報[註一]就提到如何透過 IPv6 的方式來改善整個 5G 網路核心的功能並改善效能與延遲性。

文章內有提到 WWW 帶來的全球資訊量爆炸，資訊多到人們再也沒有辦法慢慢瀏覽找到需要的資訊，此困境最終促使搜尋引擎的出現，讓人們可以用更簡易的方式去搜尋到各式各樣的 WWW 網站來獲得所需要的資訊。

搜尋引擎與 WWW 的相互發展，搭配各種文章農場以及投放廣告，使用者愈來愈難透過搜尋引擎快速且精準地找到問題答案，特別是還有些網站會偽造文章更新日期來欺騙使用者點擊，常常以為是最近的文章結果點進去都是十年前的文章，這類型的干擾都使得搜尋引擎與找到答案之間的關係愈來愈薄落

從 1973 到 1992, 第一個搜尋引擎出現也過了將近 20 個年頭，而 30 年後 AI 也正在改變整個搜尋引擎的用法。

譬如去年推出轟動世界的 ChatGPT，其透過一個對話的方式讓你可以透過用詢問的方式來尋求答案，使用者只要專注於各種 prompt engineering (詠唱魔法) 想辦法問出正確的答案，而非像過往搜尋引擎一樣需要點擊各種結果並從中努力找到答案。
此外微軟推出的 Bing Chat 這個內建 GPT 模型的搜尋引擎，也提供了 AI 使用的一種想像方式，將搜尋引擎與 AI 整合讓使用者同時享有兩種功能並且根據需求決定要用何種方式來找尋答案

需求促使改變，而改變的同時也需要天時地利人和，每個元件都環環相扣，少了一個也許都沒有辦法促使這些科技更新與改善。
也許就如同我們開發設計專案架構一樣，好的架構與設計都是要根據需求逐步迭代而進步，想要一開始就設計一個萬無一失的協定與架構似乎都過於天馬行空，畢竟你永遠都無法料到什麼時候又會有一個殺手鐧的出現逼迫你改變。

標題: 「DevOps Certification Roadmap」
類別: Others
連結: https://medium.com/@AnnAfame/%EF%B8%8F-devops-certification-roadmap-%EF%B8%8F-75e38e9b8da1

本篇文章列舉了作者認為推薦或認為值得擁有的 DevOps 相關證照並且對於該證照給予一些介紹以及考取學習上的建議，包含了

選擇性
1 Red Hat Certified Engineer
2 Docker Certified Associate
3 Puppet Certified Professional
4 Certified Jenkins Engineer
5 Certified Prometheus Administrator
6 The Certified DevOps Professional
7 DevOps Institute Certified Agile Service Manager
推薦擁有
1 AWS Certified DevOps Engineer – Professional
2 Microsoft Certified DevOps Engineer Expert
3 Google Professional Cloud DevOps Engineer
4 Certified Kubernetes Administrator
5 HashiCorp Certified: Terraform Associate
6 Certified Kubernetes Security Specialist

證照到底值不值得花錢去考是個一直以來都存在的討論議題，到底履歷上這些證照是否可以加分眾說紛紜，我認為就跟 DevOps 的定義一樣， YMMV 沒有標準答案，有的面試官吃證照，認為有證照就有基本實力，相反的也會有面試官會認為證照都是背題目，實戰經驗才是重點。

我個人的角度來看，與其一直去思考證照能不能幫我找工作提高薪水，不如去轉個念去思考，證照就是我學玩某個技術後順便去考的，主軸還是學習與理解，加強自己技能樹的深度與廣度。
如果剛好有餘裕資金與時間，就可以順便考個證照看一下這些證照到底玩什麼把戲，順便確認一下是否還有什麼自己不熟悉的東西。

至於企業角度又是不同，特別是教育訓練下很多時候上面追求 KPI，學習一個技術很難寫報告，但是學玩技術又可以獲得證照則這個報告相對好寫，我想這也是這個證照領域歷久不衰的原因之一?

標題: 「fsync 的重要性，為什麼任何非拜占庭協定的應用程式沒有 fsync 都會有資料遺失的可能性」
類別: Others
連結: https://redpanda.com/blog/why-fsync-is-needed-for-data-safety-in-kafka-or-non-byzantine-protocols

本文是由 Redpanda 該廠商的所撰寫的技術文章，主要是探討 fsync 與分散式系統下的問題。

fsync 的概念就是確保應用程式寫入的資料必須要寫道硬碟才可返回，該方式提高資料保證性但是卻降低了效能。

然而隨者資料複製 (replication) 架構的崛起，愈多愈來的架構採取資料複製的方式，其將資料給存放到不同節點上並且同步資料，即使有任何節點斷電或是出問題也不影響整個資料的正確定。

也因為資料複製提供的資料一致性，使得很多實作方式就不考慮執行 fsync，只要每個節點都有辦法順利同步資料，那任何不使用 fsync 的節點若中途斷電或是損毀也都不影響全域的資料正確性。

然而作者指出這是一個誤解，事實上只要你不跑 fysnc，任何斷電損毀節點上的未同步資料都會導致全域的資料遺失
更重要的是大部分的複製協定只支援 fail-stop 這類型的錯誤，該錯誤的假設是你節點會損毀沒關係，但是節點重啟後必須要跟損毀前資料一致，而因為沒有執行 fsync 的操作，這類型的節點損毀一定會掉資料。

為了解決這問題，作者指出這問題對於 拜占庭協定來說其實不是問題，因為拜占庭協定最初的假設就是更糟糕的故障可能性，支援各式各樣的節點行為。
文章後半部分用一個方式來證明 “單一節點的未同步資料是如何導致全域資料遺失”

結論來說：
在資料複製的架構中，使用 fsync 是確保資料一致性和持久性的關鍵方式。本文章強調了一個常見的誤解，即僅通過複製就可以消除對 fsync 的需求，並且示範了在一個非拜占庭式協議的系統中，單節點上未同步的數據丟失仍然可能導致全域資料遺失。