標題: 「為什麼有些工程師不相信 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 合作可能還會使得很多事情效率低落，溝通成本過大。

歡迎留言探討你的想法

「最近忙翻，完全沒有辦法兩天寫一篇文章...QQ」

這邊來宣傳一下今年的 COSCUP，所有議程都已經正式公開，其中 Kubernetes Community Day 也合併一起舉辦，本次的 COSCUP 屬於不用搶票的線下活動，活動時間是 07/30, 07/31

這次的 KCD 包含的議題有
- 如何在幾小時內快速部署一個私有雲 — 以 CNTUG Infra Labs 為例
- eBPF-based Container Networking
- How to start contributing to Kubernetes Projects
- 認識多個版本的 Kubernetes CRD 和 conversion webhook
- 在 k8s 上跑 time series database 甘苦談
- Level Up Application Management Using K8s Operator pattern
- Kubernetes zero-downtime label migration
- 什麼是雲原生？是一種技術還是 Buzzword? 暨雲原生 IT 大調查
- Building Kubernetes cluster the hard way
- Introduction to Multi-Version CRDs in Longhorn

此外 KCD 還有由我於主議程軌帶來的 keynote，「以 eBPF 構建一個更為堅韌的 Kubernetes 叢集」

主要會從各方面來跟大家聊聊 eBPF 這技術對 Kubenetes 可能帶來的影響與變化

這次的活動也是免報名的線下活動，對於年度大拜拜活動有興趣的千萬別錯過
議程連結: https://coscup.org/2022/zh-TW/session

標題: 「SRE 的工作介绍」
類別: others
連結: https://www.kawabangga.com/posts/4481

本篇是簡體中文的文章，所以就不針對文章進行導讀。

文內我覺得有趣的部分是從各個面向來探討 SRE 這個職位的可能內容，畢竟一直以來 DevOps, SRE 等相關概念的詢問就沒有停止過，而事實上每個公司的 DevOps 工程師, SRE 工程師的工作內容也都不盡相同。

也因為不盡相同，本來就很難一言概括到底 SRE 的可能內容，因此個人算是滿推崇本篇文章的分析與整理方式，從不同角度出發去列舉各種可能的工作內容，譬如文章中分成三大類
1. 架構
2. 服務平台
3. 業務導向

三種不同類型的 SRE 面對的對象不同，專注的事物也不同，我猜想很多人看完架構類型的論述可能第一個想法就跟以前的 SA/NA 網管有什麼不同？

也許從 SRE 的 R 出發，去探討你今天到底想要針對什麼樣的目標去提供高可用性，也許更能夠方便探討彼此對於 SRE 的需求與認知

標題: 「探討微服務架構下如何透過設計模式來打造一個可觀察性(Observability)的系統」
類別: others
連結: https://learncsdesign.medium.com/microservices-observability-design-patterns-bdfa5807f81e

大多數人過往探討到監控服務時，直覺性都會想到透過 Prometheus + Grafana 來達到 monitoring 的功能，然而現在更多人推崇使用 Observability 這個詞來概括所有跟維運監控有關的概念。
最常見的幾個小分類包含
1. Metrics
2. Tracing
3. Logs

而本文作者則用六個類別來概括可觀察性，分別是
1. Health check API
2. Log aggregaion
3. Distributed tracing
4. Exception tracking
5. Application metrics
6. Audit logging

作者針對這六個項目都依序下列流程介紹，包含
1. 簡單概念介紹
2. 架構與流程圖
3. 常見專案

作者除了這篇文章之外，還有關於微服務架構的系列文，其連結都在本文底下，內容包括如
1. Service Discovery
2. Security
3. Cross-Cutting
4. External API
5. Data
....

有興趣的歡迎閱讀全文瞭解更多

標題: 「Loft Vcluster 正式提供 ClusterAPI 來提供統一方式打造多租戶的 k8s 叢集」
類別: Kubernetes
連結: https://www.businesswire.com/news/home/20220512005260/en/Loft-Labs-Simplifies-Virtual-Kubernetes-Cluster-Management-with-New-Open-Source-Project

隨者 Kubernetes 的普及，愈來愈多的使用情境都嘗試轉移到 Kubernetes 上，然而對於一個分散式基礎架構來說，如何有效率的使用底層資源來滿足上層應用一直都是不可避免的問題。

然而對於 Kubernetes 來說，如何達到真正的多租戶應用一直以來都是個難題，內建的 namespace 概念是基於 k8s 物件的方式來達到輕量級隔離，某些內容如 PV 等甚至根本沒有 namespace 的概念。
相較於 namespace 這種輕量級方式，另外一個重量級的則是直接給每個租戶一套全新的 k8s 叢集，
概念簡單，直接用不同的 k8s 來隔離最輕鬆，然而講的容易實作麻煩，要管理這些 k8s 實務上要處理的事情多更多，特別是當租戶數量超過一百以上時，要同時管理維護與升級這些 k8s 叢集真的會想死

兩者中間的一個折衷方案則是透過 Kubernetes 管理 Kubernetes，目前知名的專案就屬本文的 vcluster，而該專案最近又釋出了一個全新專案，該專案實作了 Kubernetes ClusterAPI，讓使用者可以透過 ClusterAPI 這個標準直接管理由 Loft 創建的 vcluster。

對於開發者來說就可以透過同一個管理方式來創建各種支援 clusterAPI 的叢集，不論是不同公有雲的叢集，或是某些地端廠商發行版，甚至是本文提到的 vcluster

有使用過 vcluster 的使用者可以研究看看此專案，看看使用 clusterAPI 是否可以讓本來的管理工作流程更為簡單順利

標題: 「Airbnb 是如何因應業務型態來動態調整 Kubernetes 叢集大小的?」
類別: Kubernetes
連結: https://medium.com/airbnb-engineering/dynamic-kubernetes-cluster-scaling-at-airbnb-d79ae3afa132

本篇文章是 Airbnb 的技術分享文，主要是探討過去四年來， Airbnb 是如何將內部服務逐漸轉移到 Kubernetes 上，並著重於如何動態的去調整 Kuberentes 叢集的大小。

對於 Airbnb 來說，如何有效地根據當前流量來動態的調整運算資源大小一直都是內部非常重視的一點，導入 Kubernetes 前， Airbnb 主要的資源都是透過 EC2 VM 來運行，而如何將這些服務逐漸地轉移到 Kubernetes 上同時又要能夠動態調整大小則是一個長期抗戰的目標。

Airbnb 將這個過程分成三個階段，以下分別節錄一些重點


Stage 1: Homogenous Clusters, Manual Scaling

過去使用 EC2 來部署服務時，團隊主要是透過手動的方式調整叢集數量來確保能夠應付當前業務流量，比較大的問題是這些當流量退去後這些資源常常沒有被回收，導致資源與金錢浪費。

所以第一階段就是先搭建簡單的 Kubernetes 叢集，根據不同的使用情境配置出不同的 Kubernetes 叢集，同時第一階段只運行 stateless 相關服務，同時基於 Kubernetes 的設計，讓每個節點運行適當的 Pod 數量以減少資源浪費。

此階段下，有任何叢集的擴充都還是基於手動操作，根據需求來進行叢集的調整。

Stage 2: Multiple Cluster Types, Independently Autoscaled

第二階段中，開始導入各式各樣不同的業務情境與相關服務，這使得底層需要的 Kubernetes 都會有些許不同的設定與資源，因此團隊從中開始打造一個抽象層，透過抽象層去描述需要的 Kubernetes 叢集設定與資源，包含實體機器的類型與相關軟體設定。

隨者使用情境的類型增加，團隊內的 Kubernetes 叢集也更多了，而第一階段採取的「手動」調整大小明顯無法處理這些需求，因此團隊開始導入 Kubernetes Cluster Autoscaler 來嘗試自動化 Kubernetes 的叢集調整。

相較於人工手動觀察與調整，透過自動化的 Cluster Autoscaler 幫助 Airbnb 省下大概 5% 的雲端成本，同時也減少很多維運上的操作需求

Stage 3: Heterogeneous Clusters, Autoscaled

當 Airbnb 幾乎將所有業務都轉移到 Kubernetes 後，此時的叢集類型已經超過 30 多種，部署的叢集數量更是破百，整體規模的成長使得 Kubernetes 的管理愈來愈麻煩
舉例來說，當 Kubernetes 要升級的時候，每個要求的類型(30+) 都要獨立測試過，確認每個類型都不會被影響才可以順利往上升級。

所以第三階段的目的就是希望保有過往的彈性下，同時降低複雜性，其中採取的方式希望能夠創造一個服務各種不同業務需求的 Kuternetes 叢集。

而團隊發現到現有的 Cluster Autoscaler 使用上有些限制使得沒有辦法很順利地達到團隊需求

因此文章後半部分主要詳細介紹團隊是如何開發 Cluster Autoscaler 並且積極的與社群互動來確保自己開發的新功能是能夠讓其他使用者一起受益，而非只有 Airbnb 自己有辦法使用。

有興趣的可以點進去閱讀全文

標題: 「一個名為 comcast 的網路模擬小工具」
類別: Networks
連結: https://github.com/tylertreat/comcast

今天介紹的是一個很有趣的網路工具，該工具是用來模擬不同環境下可能的網路條件，譬如封包掉落率，Latency 以及整體頻寬。

這樣一個看起來不太複雜且多年沒有維護(上次 release 是 2015)的工具竟然會有將近 8.4k 的星星數，我想最大的理由應該就是這工具的名稱實在太貼切了...

Comcast 是美國這邊知名的網路供應商，就我個人經驗來看，很常遇到封包被丟，網路維修等各種問題...

標題: 「探討 Linux 系統下 Cache 與 Buffer 的差異」
類別: Linux
連結: https://medium.com/geekculture/linux-memory-buffer-vs-cache-44d8a187f310

作者開頭就列出關於 Linux 底下 Buffer 與 Cache 的常見說法

Buffer: 「是一個為了底層硬碟的暫時儲存設備，會將要寫入到硬碟的資料給快取起來，Kernel 接著可以根據需求來最佳化寫入到硬碟的時機，譬如將多個小寫入給合併成一個大寫入」

Cache: 「是一個為了從硬碟讀取檔案的快取，譬如對一個檔案多次讀取，後續的讀取就可以以更快速的速度從 Cache 中讀取資料，不需要每次都跑到硬碟去讀」

作者根據這的定義問出了一個問題，為什麼 Buffer 不能夠快取從資料讀取的資料？ 反過來看為什麼 Cache 不能夠去處理要寫入的資料？

從 "free" 這個指令的輸出訊息中，可以看到 buffer/cache 這兩個概念被放一起，兩者是以總和為單位去看待的。
根據 free man 的說明

buffers: 被 Kernel buffers 所使用的記憶體 (Buffers in /proc/meninfo)
cache: 被 Page Cache /Slabs 所使用的記憶體 (Cached, SReclaimable in /proc/meminfo)

可以看到實際上這些數值都是從 /proc 這個特殊的檔案入口讀取出來的，這時候如果去翻 proc 的介紹，來仔細看這些定義

Buffers:
Relatively temporary storage for raw disk blocks that shouldn't get tremendously large (20MB or so).

Cache:
In-memory cache for files read from the disk (the page cache). Doesn't include SwapCached.

從這邊來看，其實 Buffers 似乎強調的是 Raw Disk，而 Cache 則是從硬碟中去讀取資料。
因此作者接下來就執行兩個實驗，透過 dd, vmstat 等指令去驗證

1. 使用 dd 去寫入檔案
2. 使用 dd 從 disk 讀取區塊

從上述的實驗中可以觀察到
1. 使用 dd 去寫入檔案時， Cache 的使用記憶體數量逐漸上升，這意味其實寫入檔案其實也有快取的概念，而系統上的 Cache 實際上介入
2. 使用 dd 從硬碟讀取區塊時， Buffer 與 Cache 的記憶體使用量都有上升，但是 Buffer 的成長量非常明顯，與 Cache 不是同個數量級的。這也意味者從硬碟直接讀取區塊時， Buffer 會參與並且作為快取的角色來加速整個讀取。

根據這兩個實驗，作者給出的觀察是
Buffer: 當寫入硬碟或是從硬碟讀取時， Buffer 會作為快取來幫忙
Cache: 當寫入檔案或是從檔案讀取時， Cache 會作為快取(Page Cache)來幫忙

標題: 「就是一份唸書的書單」
類別: others
連結: https://github.com/charlax/professional-programming

今天分享的是一個類似 awesome-xxxx 系列的 git 專案，該專案收集了不同領域值得閱讀的書籍與文章
範圍非常廣，從程式語言到容器技術到系統架構概念全都包

閒來無事也許可以當一個唸書清單?

標題: 「如何測量與提升開發者的生產力」
類別: others
連結: https://medium.com/@bijit211987/how-to-measure-and-improve-developer-productivity-694607f501bc

本篇文章想探討的是一個數十年以來一直被研究探討的問題，如何有效地去評測一個開發者的生產力？
對於管理人員來說，有時候都會希望能夠有一個完美的指標可以用來評估當前團隊以及個人的生產力，特別是近年因為遠端工作興起，團隊可能散落世界各地，橫跨不同時區，這種情況下要如何保有過往的開發生產力與效率則是每個團隊都會面對的問題。

作者認為這生產力指標是一個重要但是極度困難的工作，畢竟開發團隊工作牽涉到如
1. 撰寫新功能
2. 修 bug
3. 重構，提升維護性
4. 撰寫測試
5. ...等
這些不同面向都很難有一個單一指標去衡量一個開發者的生產力，舉例來說
用想都覺得很不合理的 LOC(程式碼行數) 對應到上面五個類別就完全不同，新功能會有最多的程式碼行數，修 bug 可能很困難，結果只有改一行，重構更可能減少程式碼行數？
這種情況下用單一指標來評斷生產力與否完全沒有道理。
除了這類型的指標外，作者提到還有很多類似的指標
1. 工作多少小時. (很有可能出現很多人發呆衝時數)
2. 發現多少 Bug (是真的有聽過規定要每週驗多少 bug 的指標...)
3. 解決多少 Ticket
4. ... 等

文章中作者從幾個不同面向去提供思考，譬如
1. Git-Based 的指標，包含程式碼改動頻率，多少程式碼有經過 code review
2. SPACE 框架，基於多個指標如 (S)atisfaction, (P)erformance, (A)ctivity, (C)ommunication/Collaboration 以及 (E)fficiency
3. OKR 系統

對於如何測量生產力有興趣的可以參閱看看作者的一些觀點

標題: 「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. 開啟自動拼字錯誤，不小心手殘打錯的指令也可以幫你校正回來
...等

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