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

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

標題: 「十個 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 搞定的。