Skip to content

父之罪

  • Quote

他的五官鑴刻得有稜有角——上鷹嘴鼻,豐潤的嘴,下巴的線條宛如危巖峭壁——但他臉孔引人側目,主要是因為它活似一塊空白石板,只等別人刻下誡令。

我從來不知道該怎麼訂價。我的時間只有對我才有意義,它對別人值多少我怎麼知道?如今我已經刻意調整我的生活方式,希望盡可能不要介入別人的生活。那我又該跟強迫我介入的人收多少才算合理?

他沒問下去。奇怪的是,這比他問了還叫我難堪。

「咖啡跟酒,奇怪的組合。」
「是嗎?」
「酒叫你醉,咖啡叫你清醒。」
我搖搖頭。「咖啡從來沒法叫人清醒,它只能撐著你不睡。拿壺咖啡奉送酒鬼,兩個加到一塊只是個睜眼酒鬼。」

天主教堂從我身上拿到的錢比別人要多。不是我偏心,只是因為他們開門的時間較長。不是週末的話,基督教堂大部分都關了門不做生意。

我知道下一步一定逃不掉。我一直躲躲閃閃。但它老不鬆手,我沒辦法永遠躲著不理。現在不做,更待何時?

我從布魯克林回來時頭痛欲裂、口乾舌燥。我止渴的功夫做得比止痛徹底許多。

有件事我早就學到:不需要知道對方在怕什麼,知道他在怕就夠了。

搜書架時,如果可以任意翻閱,然後往地毯隨手一丟,工作效率自然可以大大提高。如果你得把每本書整整齊齊的擺回原位,二十分鐘的工作準可以拖上兩個鐘頭。

「唔,他們年輕貌美的時候,你不會在意他們花錢太少,他們是我這兒的最佳室內擺飾,你知道。他們可以招徠顧客。」

我暗自納悶,不知道她臀部一扭一扭是為了給我養眼,還是她天性如此。

你得適可而止。你永遠不可能查出所有真相;不過你永遠可以查到比已知的多。

這樣做八成是浪費時間,不過我做的事其實全是浪費時間,看你從什麼角度看。顯然我裡頭有個什麼,命令我非得浪費時間不可。

保重。我覺得大家好像是近幾年來,才在道別時說這兩個字。人人開始有了危機意識,整個國家陡然意識到,我們在一個隨時需要保持警覺的世界。

我深深看進溫蒂的眼睛,我們過去這幾天變得非常親密,她跟我。我現在對她的了解恐怕已經超過她能接受的程度。

我們還滿合的。有那麼一會兒,所有難解的問題都不見了,躲在陰暗角落。

用 Terraform, Google Cloud VPN 架設 Hybird Cloud

  • Ops
tags: gcp, cloud-vpn, shared-vpc, terraform

為了更了解地端、雲端網路如何連接,用了 GCP 來做一整套簡單的實驗。

架構說明

img

雲端

為了模擬比較複雜的組織架構,雲端使用了 Shared VPC 的架構,有以下幾個優點:

  • 減少 VPC 數量,較容易管理
  • 多個子專案(service project)可以共享同一個主專案(host project)定義的網路
  • 子專案可以各自分開 billing
  • 劃分網路權限,子專案只能使用主專案定義的網路

要使用 Shared VPC 架構有幾個前提:

  • 須要有 GCP Organization
  • 主專案須設定為 shared VPC host
  • 子專案須 attach 到主專案

雲端的 VPC Gateway 的實作方式採用 GCP 的 Classic VPN,也稱為 route-based VPN,採用事先定義好的靜態路由規則(static routes) 來做 routing。

GCP 還有另一套 VPN 叫 HA VPN,背後是使用 BGP 來做動態路由設定,由於架構較複雜,沒在此實驗採用。

要使用 GCP 的 Classic VPN 有以下前提:

  • 兩端只能走 IPsec 協議
  • 兩端都必須有 public IPv4 位址

在兩端 peering 上也要避免 IP 位址重疊。另外,若要做到高可用,可以建立多個 VPN gateway 來達成。

地端

為了模擬地端環境,另開一個 GCP 專案,也會設定一個獨立的 VPC。

地端採用一台 VM 實例來扮演 VPC Gateway,使用的工具是 strongSwan

Read More »用 Terraform, Google Cloud VPN 架設 Hybird Cloud

淺談 Moby’s BuildKit

  • Dev, Ops

前陣子因為工作需要,研究了一下所謂 Docker build 的 3.0 版本 —— docker buildx build,希望能找出其與 docker build 背後的差異

docker buildx 指令是使用 Moby’s BuildKit 這套工具來代理 building,所以以下會用 BuildKit 來指稱新的建構模式

直接下結論

  • BuildKit 須要透過一個前端服務去轉換 Dockerfile (或其他語言定義的建構流程),再交給 LLB 處理
  • 即使是同一個 Dockerfile,docker build/buildx 兩者建構出的 layer 完全不同,無法共享
  • 如果你建構很複雜,已經有在使用 multi-stage build(例如須要先編譯成二進制檔案),那會比較有幫助,如果是要 build 類似 python 這種直譯式的應用程式,因為流程較為單純所以幫助不大

Read More »淺談 Moby’s BuildKit

SRE: How Google Runs Production Systems 讀書筆記(四)

  • Ops

on-call

關鍵是「數量」跟「品質」的平衡:

  • 數量:不超過 25% 時間 on-call
  • 品質:須要有充足的時間處理(含分析、debug、事後檢討,一個事件約須花 6 小時完成)

幾分鐘內要回應?

回應時間與服務水準、可靠性有關,例如面向使用者的服務須在 5 分鐘內回應,非敏感業務通常是 30 分鐘

維運負擔過大怎麼辦?

事件 / 警報比例應接近 1:1,避免重複警報導致維運壓力、調派有經驗的 SRE 協助、與研發團隊一起分擔維運

系統太穩定怎麼辦?

維運壓力不夠會導致自信過度或自信不足,每個工程師每季應至少參與一次 on-call,公司可定期舉辦災害演練

故障排除技巧

故障排除是一連串的「假設」+「排除」,這個技能是可以教學相長的,如果能做好事後檢討、紀錄負面結果(negative result),故障排除會是學習一套系統很有效的方法

小心避免以下陷阱:不理解現象(方向錯誤)、假設是對的,但測試假設的方法錯誤、過早下結論、被巧合/偽相關誤導

「緊急情況下,飛行員的首要任務是保持飛機飛行及安全登陸,故障定位和排除只是次要目標。」

Google 用什麼追蹤工具?

每個系統用的工具可能不同,文中提到的 Dapper 是 Google 內部很廣泛應用的工具,特別看了一下文獻整理幾個重點

在分散式系統,跨服務請求很常見,例如發出一個 requestX,在下游會發出額外數個請求 —— 攤開看就是一個 Tree(巢狀的 RPCs)

這個請求/響應歷程的樹狀結構稱為一個 Trace,當中的節點就是單一請求/響應,稱為 Span,裡面會紀錄時間戳、traceID、parentID、host 等詳細資訊。Span 是以本地文檔的方式建立和寫入的,再透過 Dapper daemon 去拉取並儲存到後端 —— BigTable, Trace 存成 row,Span 存到其對應的 sparse column

可以把 Span 視為是一種 Log,除了運行在伺服器上的 Dapper daemon,應用程式也可以透過函式庫發送 Span、加標籤或自訂的額外訊息等,這個重要功能稱為 annotation

Dapper 設計上很重視的理念是「低成本」,包含本地檔案的讀寫、後端儲存、網路頻寬(只佔小部份),因此採用取樣 (sampling) ,經驗上顯示取樣不只可以大幅降低延遲,也能讓資料得以保存更久,Dapper 的預設取樣率是 1/1024——對數據密集型系統而言,不會造成分析上的盲點

Dapper 原本只是一個追蹤工具(黑箱的),但後來演化成一個大型的監控平台,有強大的界面可以幫助分析,甚至到後來,發現可以應用的層面更廣:系統的依賴關係(dependency)分析、網路狀態分析、在共享儲存的基礎上區分服務、長尾延遲的分析、錯誤報告分析等

Read More »SRE: How Google Runs Production Systems 讀書筆記(四)

SRE: How Google Runs Production Systems 讀書筆記(三)

  • Ops

發行工程(release engineering)

這章開頭介紹了有關「發行」這個新的學科,在 Google 雖由 SRE 以外的特定角色負責,但 SRE 一樣須要與之密切合作與關注;後半部份介紹發行流程、以及 Google 使用的發行系統 Rapid 與建構工具 Blaze (開源版本為 Bazel)

發行工程師在幹麻?

發行工程是一項獨立出來的工作,核心是 build 跟 deliver,由發行工程師負責

發行工程師的工作不是「負責發行」,而是開發工具、制定 best practice,好讓產品研發團隊能自主發行,也就是 self-serving

發行模式有哪些?

發行的步驟由發行工程師、SWE、SRE 三者一起定義,舉幾個例子:

  • 每小時建構一次,再根據變更項目和測試結果挑出要發行的版本
  • Push On Green,測試通過就發行

因規模和軟體性質而異,有的發行時間會需要延長到好幾天(如基礎設施)

怎麼建構?

無論使用什麼建構工具(Google 用 Blaze),建構應該要是一致且可重複的,也就是在兩台不同機器上建構同一個版本,應該得到相同結果

建構過程應是密閉的 (hermetic),不應受機器上安裝的其他函式庫或軟體影響

正式站有 bug 怎麼辦?

Google 通常不在 master 分支直接發行,而是從 master 切新的分支用來發行(避免建構後無關的變更影響到 master)

針對 bug 的修復會先上到 master,在發行分支再把該變更 cherry pick 過來,即可重新建構跟發行

怎麼持續建構/部署?

因為這章提到的工具跟元件比較多,從 Florian Rathgeber 的簡報上找到的一張關聯圖來看可能會比較好理解

image

  • Midas Package Manager(MPM):是 Google 使用的套件管理系統,資料元存在 BigTable 上。我粗淺的理解方式是把它「對應」到容器的映像檔,它們都是利用「名稱 + 標籤」作為唯一識別,但比起容器映像檔,MPM 有更進階的功能,例如 ACL 跟簽章;另外一個從根本上不同的是映像檔是有序的 layers,而 MPM 則是無序的 filegroups
  • Blaze:建構工具,用來建構 MPM、二進制檔案、對應的測試
  • Rapid:分散式發行系統,可執行由建構藍圖 (blueprint) 定義的工作流、利用 Blaze 來跑建構及測試;Worker 是跑在 Borg 上,可以並行處理發行工作
  • Sisphus(希臘神話的薛西佛斯):自動化部署的框架,提供更彈性的部署功能、流程儀表板

一句話概括基本流程:Rapid 負責跑測試、建構 MPM(打上特定標籤),Sisphus 負責部署此 MPM 版本

Read More »SRE: How Google Runs Production Systems 讀書筆記(三)

SRE: How Google Runs Production Systems 讀書筆記(二)

  • Ops

第三章在講風險,開頭再度強調了「不該追求極端的可靠性」,我們必須考慮機會成本——可靠性的成本並非線性成長,多追求一個級別的提昇(例如 99% 提昇至 99.9%)說不定成本要提高百倍才做得到,甚至,好不容易達成後對使用者來說根本沒差

怎麼看風險?

可靠性(或者說對故障的容忍程度)是靠風險管理得出的結果。風險是一個非線性的連續體(continuum)的概念,我們要問的問題是:服務合理的風險是多少?

合理的風險更像是一個可選的區間,透過衡量「成本」、「業務風險」與「維運風險」對應後我們可以再選出一個目標值

怎麼量化風險?

故障導致的業務風險很難量化(例如媒體大肆報導導致退訂),最直接的作法是參考指標(延遲、停機時間、請求成功率等)

拿停機時間來看——可用性水準訂為 99.99%,一年當中可以接受的停機時間就是 52.56 分鐘

但對分散式服務來說,停機可能是很久才會發生一次的(較難追蹤校正),可以改用請求成功率——可用性水準訂為 99.99%,如果一天要接受 2.5 M 個請求,錯誤數量少於 250 個即可(要注意不同請求的重要性不同,直接面向使用者的請求會更重要)

可用性目標應該多久更新一次?訂定的依據是什麼?

通常以一季為單位來訂,每週或每天追蹤其變化

成本考量很重要,舉了一個很好的比較:Gmail 跟 Youtube——Gmail 定的可用性目標很高,因為如果服務中斷,會導致大量成本及嚴重後果(例如包含許多企業在內的使用者流失);反之,為 Youtube 設定的可用性目標較低,因為快速發展更重要

可以思考下列這些問題:

  • 使用者是誰?他們期望怎樣的服務水準?
  • 服務是否直接關係到收入?(公司的收入或客戶的收入都算)/ 是付費還是免費?
  • 競爭對手的服務水準如何?
  • 多一個「9」,收益增加多少,成本增加多少?
  • 服務是否為基礎設施?服務水準是否可以適用各個業務端?

如果難以訂定,可以參考「ISP 的服務錯誤率」(大約 0.01%-1%),只要可用性優於此基礎,故障就會被網際網路的噪音(noise)掩蓋掉

持續發生的零星故障 / 全網中斷哪個更糟糕?

看情況。不同故障類型不能以同樣方式來量化,要考慮不同故障會對業務端造成多大影響

同一個服務怎麼滿足不同類型的使用者?

有時服務的特性是雙面刃,書上舉了 BigTable 為例:要低延遲,利用率愈低愈好(可以更快處理),但要低成本,利用率愈高愈好(避免閒置)

我自己在使用 BigTable 也遇過這種競爭約束(competing constraints)的情況:同一個應用要服務 streaming 跟 batch 這兩種不同場景

書上提供一個解決方式:用戶隔離——低延遲使用者跟離線分析使用者分別使用不同叢集

Read More »SRE: How Google Runs Production Systems 讀書筆記(二)

Bitnami