工程哲學：Werner Vogels

核心要點

• 他的核心原則是:一切都會一直出故障,因此你要為故障而設計,而不是為防止故障而設計。 自2005年起擔任 Amazon CTO 的 Werner Vogels,把一個直白的觀察——在足夠大的規模下,元件故障是持續的、統計上必然的——變成了一條設計教條:假定每一塊磁碟、每一台伺服器、每一條網路鏈路、每一項相依都會出故障,並建構出能在故障之中依然保持可用的系統,而不是假裝故障可以被防止。¹⁶
• 他是 Dynamo 論文的共同作者,這篇論文開創了現代 NoSQL 背後的種種思想。 《Dynamo: Amazon’s Highly Available Key-value Store》(SOSP 2007)把一致性雜湊、向量時鐘、寬鬆法定人數、以流言為基礎的成員管理以及最終一致性,統統裝進了一個始終可寫的儲存系統裡,並直接影響了 Cassandra、Riak、Voldemort,以及 Amazon 自家的 DynamoDB。²³
• 他是最終一致性最重要的佈道者。 他的文章《Eventually Consistent》把可用性與一致性之間的取捨講得明明白白:當網路發生分區時——而在大規模下它一定會——你必須做出選擇,而 Dynamo 選擇了保持可用、隨後很快收斂,而不是阻塞到所有副本達成一致為止。⁴⁷
• 他為工程文化留下了「you build it, you run it」(誰建構,誰維運)這句話。 在2006年的一次對話中,他描述了 Amazon 讓開發者在正式環境中擁有自己服務的模式——界定範圍、建構,並且維運——並主張讓建構者背上呼叫器、站在客戶面前,正是驅動品質的關鍵。⁵

這條原則

「Everything fails, all the time.」(一切都會一直出故障)—— Werner Vogels,Amazon CTO,談如何設計可靠的分散式系統⁶

大多數工程都是為一切正常運轉的情形而最佳化的。你寫好正常路徑,處理掉幾個能想到的錯誤,然後發布。這種本能一直管用,直到你在大規模下執行系統——那時它就會背叛你。當你執行著幾十萬台機器時,「罕見」不再罕見。每塊硬碟三年才出一次的磁碟故障,在你的機群某處每隔幾分鐘就會發生一次。每一百萬個封包丟一個的網路鏈路,一天會丟掉數百萬個封包。Vogels 最著名的那句話把這一切壓縮成四個詞:一切都會一直出故障。⁶ 故障不是需要繞開去設計的例外;在大規模下,它是你必須針對它去設計的穩態條件。

由此推出的原則,是對常規原則的顛倒。如果你無法防止故障——而在大規模下你可被證明無法做到——那麼防止它就是錯誤的目標。正確的目標是在事物正在出故障的同時保持可用。所以你假定每個元件都會死去,並這樣設計:任何單一的死亡都能挺過去。把資料跨機器複製,讓其中一份的遺失不可見;把服務解耦到 API 之後,讓出故障的相依只降級某個功能而不是掀翻整個系統;並且把任何單一故障的爆炸半徑降到最小,使其無法拖垮整體。系統不是為了避開故障情形而建,而是為了讓故障情形乏味無奇而建。¹⁶

這條原則還有後半部分,正是它讓前半部分成真:一旦網路可能發生分區,你就無法同時擁有完美的一致性和完美的可用性,因此你必須選擇——而 Vogels 選了可用性。 當網路分裂把你的副本彼此隔開時,系統要麼拒絕作答、直到所有人達成一致(一致,但不可用),要麼用手頭已有的內容繼續作答、稍後再調和(可用,但短暫地不一致)。對 Amazon 的購物車而言,拒絕作答是不可接受的——在分區期間拒絕「加入購物車」的購物車,就是丟失一筆銷售的購物車。⁴ 所以 Dynamo 始終接受寫入,讓副本隨後再收斂。代價是有一個短暫的時間窗,不同副本可能回傳不同的答案;回報則是一個永遠不對客戶說「不」的系統。這種取捨——保持可用、隨後很快收斂,而不是阻塞到所有人達成一致為止——就是最終一致性,Vogels 用一生主張它在大規模下是正確的取捨。⁴⁷

背景

Werner Vogels 於1958年10月3日出生於荷蘭埃爾默洛。¹ 他通往運算的道路,並不是穿過頂尖大學的那條常規直線。他在海牙應用科學大學攻讀電腦科學,於1989年完成學業,直到很久以後才取得阿姆斯特丹自由大學的電腦科學博士學位——他2003年的論文《Scalable Cluster Technologies for Mission Critical Enterprise Computing》由 Henri Bal 和 Andrew Tanenbaum 指導,後者是分散式系統與作業系統領域的奠基人物之一。¹ 值得記住的細節是,這個博士學位是跟在多年真實系統工作之後,而非在它之前;是理論追上了實踐。

最具塑造性的篇章發生在康乃爾大學,1994年至2004年間他在那裡擔任研究科學家,從事可擴展、可靠的企業系統研究。¹ 在康乃爾,他身處 Ken Birman 的分散式系統研究組——Isis 與可靠群組通訊的那條譜系,這一系工作探問的是:一組機器如何在成員不斷故障與復原的過程中達成一致、保持一致並持續執行。他與 Birman、Robbert van Renesse 共同創辦了一家公司 Reliable Network Solutions,並出任其副總裁兼 CTO。¹ 這就是 Vogels 生長其中的思想土壤:不是「我們如何防止機器出故障」,而是「一群機器如何在其成員故障的同時保持正確與可用」。當他後來說一切都會一直出故障時,他並非即興發揮——他是在陳述自己浸淫其中十年的可靠分散式系統傳統的奠基前提。

他於2004年9月加入 Amazon,任系統研究總監,於2005年1月被任命為 CTO,並在2005年3月加上了副總裁頭銜——此後他一直擔任這一角色,推動公司整體的技術方向。¹ 他的到來恰逢 Amazon 發明現代雲端的那些年:Dynamo 儲存系統在這一時期被建構並寫成論文,Amazon Web Services 推出了它的基礎服務,而 Vogels 成了這一切底層架構原則的公開代言人——為故障而設計、透過服務解耦、擁抱最終一致性,並讓建構服務的人來負責維運它。²⁴⁵

這些工作

「一切都會一直出故障」:為故障而設計與最終一致性

從這裡開始,因為這是被鑄成工程的那條原則。這條教條有兩步動作。第一步是為故障而設計:把每個元件都當成必將出故障的東西,讓系統挺過它的遺失。這意味著冗餘(複製,使任何一份副本都可以消失)、解耦(服務透過 API 對話,使生病的相依優雅降級而非級聯崩潰),以及爆炸半徑圍堵(對系統分區,使故障被困在一個小單元裡而非四處蔓延)。¹⁶ 一個設計的考驗,不是「在一切健康時它能否運轉」,而是「當這塊部件在最糟糕的時刻死去時會發生什麼」——而答案必須是「系統繼續提供服務」。

第二步動作,正是讓高可用在大規模下成為可能的那一步:最終一致性。Eric Brewer 的 CAP 觀察指出,當網路發生分區時,分散式系統無法既完美一致又完全可用——它必須放棄其一。⁷ Vogels 的《Eventually Consistent》把這個選擇講明了,並精確定義了那條替代路徑:在最終一致性下,「儲存系統保證,如果不再對該物件做新的更新,最終所有存取都將回傳最後更新的那個值。」⁴ 最終這個詞就是這整樁取捨。一個強調可用性的系統「可能始終接受寫入,但在某些條件下,一次讀取不會反映出一次剛剛完成的寫入的結果。」⁴ 在一個短暫、有界的時間窗裡,兩個副本可以彼此不一致——但誰都絕不拒絕作答。收斂在背景進行,使用者從不被阻塞。

為何它作為工程很重要:大多數開發者對資料庫的心智模型是單機的那種,一次寫入會立即對其後每一次讀取可見,因為只有一份副本。那個模型在大規模下活不下來,因為一份副本是單點故障,而一台機器是吞吐量的天花板。一旦你開始複製——而為了可用你必須複製——你就繼承了這個問題:當副本們還在追趕時,一個讀者看到的是什麼。Vogels 的貢獻在於堅持:這不是一個要藏起來的缺陷,而是一個要刻意去選擇的設計維度;並且給了工程師一套詞彙——讀己之寫、單調讀、會話一致性——讓他們恰好挑出某個工作負載實際需要多少一致性,而不必在所有地方都為最強的保證付費。⁴

Dynamo 論文與 NoSQL 運動

這條原則有一件正典式的產物:《Dynamo: Amazon’s Highly Available Key-value Store》,由 Vogels 共同撰寫,發表於該領域頂級的作業系統會議 SOSP 2007。² Dynamo 是 Amazon 對一個具體而殘酷的需求給出的答案——購物車必須始終接受寫入,哪怕在資料中心分區和磁碟故障期間也是如此,因為一個不可用的購物車會直接損失營收。²³ 為強一致性而調校的傳統關聯式資料庫,在分區下無法做出這種承諾。於是 Amazon 建構了一個用一致性換可用性的儲存系統,並把具體做法精確地寫了下來。

Dynamo 是一份分散式系統技術的目錄,被組裝進一個始終可寫、去中心化的系統裡,而這篇論文的影響力,來自它把這些技術鋪陳得多麼乾淨俐落。²³ 一致性雜湊把資料分區到各節點上,使環可以增長或收縮而無需把一切重新洗牌——「漸進的、可能是線性的可擴展性」。³ 向量時鐘追蹤每個值的因果歷史,使並行寫入能夠被偵測到,而不是被悄無聲息地遺失。寬鬆法定人數與提示移交讓系統在部分副本不可達時仍可寫入,把寫入暫存在一個臨時替身上,直到正主節點歸來。以默克爾樹為基礎的反熵讓副本能高效地找出並修復彼此的差異。以流言為基礎的成員管理讓節點無需中央協調者就能彼此知曉並偵測故障——這一設計刻意保持對稱與去中心化,所以「Dynamo 中的每個節點都應當與其同伴擁有同一套職責」,這意味著不存在哪個特殊節點,其死亡是災難性的。³ 這每一個選擇都服侍著同一個主人:在事物出故障時保持可用。

Amazon 從未發布 Dynamo 的程式碼,但那篇論文完成了使命——它成了那十年間最具影響力的系統論文之一,是 NoSQL 運動的思想種子。³ Apache Cassandra、Riak 和 Project Voldemort 那種無主、最終一致的設計,都可直接追溯到它。³ 而這個名字也以 Amazon DynamoDB 的形式在商業上延續了下來,它建立在 Dynamo 的原則之上,儘管在底層做出了不同的工程選擇(單主複製,而非 Dynamo 那種純粹的無主模型)。³ Dynamo 影響力本身的教訓也值得一記:Amazon 的競爭護城河不是程式碼,而是清晰。透過精確解釋他們放棄了哪些保證、為什麼放棄,他們教會了一代工程師如何對這種取捨進行推理。

AWS、物件導向服務,以及「you build it, you run it」

Dynamo 是個儲存系統;Vogels 更深層的貢獻則是架構性的和文化性的。Amazon 的平台被建構成一張由只透過 API 對話的獨立服務組成的網——沒有誰伸手到幕後去碰共享資料庫,沒有隱藏的耦合。⁵ 這種紀律對故障至關重要:當服務被解耦到硬性介面之後,出故障的那一個只會降級它所支撐的那個具體功能,而不會損壞資料、或拖住所有觸碰過它的東西的執行緒。物件導向服務,就是用架構表達出來的爆炸半徑圍堵。它也正是讓 AWS 成為可能的東西——一旦你的內部系統是乾淨的、可經 API 定址的服務,把它們作為產品對外開放,就是順理成章的下一步。

文化的那一半,是 Vogels 被引用得與「一切都會一直出故障」一樣頻繁的那句話:「you build it, you run it」(誰建構,誰維運)。 在2006年與 Jim Gray 的一次對話中,他描述了 Amazon 的模式,即每個服務由建構它的團隊從頭到尾擁有:「每個服務都有一個與之關聯的團隊,而那個團隊對該服務負完全責任——從界定功能範圍,到對它做架構設計,再到建構它、維運它。」⁵ 而其理由明確地關乎以擁有換取品質:「誰建構,誰維運。這讓開發者接觸到自己軟體的日常維運。它也讓他們與客戶產生日常接觸。」⁵ 沒有一堵可以把程式碼扔過去的牆;寫下這個服務的工程師為它背上呼叫器。其效果是一個緊密的回饋迴路——最有能力修復某個脆弱點的人,正是在凌晨三點感受到那份痛苦的人;而設計了這個功能的人,直接聽到客戶的抱怨。在這裡,「擁有」不是一句人力資源標語;它是一種可靠性機制。一個維運自己所建構之物的團隊會為故障而設計,因為故障會把他們自己叫醒。

為雲端佈道:爆炸半徑、單元,以及良好架構的系統

Vogels 的第四類工作,與其說是單件產物,不如說是一個持續了二十年的角色:他是那位架構師兼佈道者,系統化地講清了如何在雲端之上建構,而不只是如何建構雲端本身。¹⁶ 反覆出現的主題,是把這條原則應用到越來越大的範圍。把爆炸半徑降到最小:把系統切分成獨立的單元,使一個故障、一次糟糕的部署、或一個有毒的請求被圍堵在一小片客戶裡,而不是全體客戶。積極地解耦:相比那種一個慢相依就會拖住整條呼叫鏈的緊密同步鏈條,更應偏向帶有明確契約的非同步、鬆耦合服務。把復原自動化,而不是把它寫進文件:一份需要人來執行的維運手冊,在那個人睡著時不會被執行。把故障當作一種測試輸入來擁抱:刻意注入故障以證明系統能挺過它們,而不是寄望它能。這每一條都是被轉化為維運實踐的「一切都會一直出故障」——這是一以貫之的訊息,在演講、寫作以及多年後第二次 ACM 對話中反覆出現:韌性是一種你從第一行程式碼起就設計進去的屬性,而不是在示範跑通之後再加上去的一層。⁶

這套方法

橫跨 Dynamo、最終一致性、物件導向服務,以及「you build it, you run it」去讀,會發現同樣的承諾在反覆出現。Vogels 的方法與其說是一句口號,不如說是一組始終在場的習慣。

先為故障情形設計。 在大規模下,故障是穩態,而非例外,所以問題從來不是「這能不能跑」,而是「當這其中的每一塊死去時會發生什麼」。⁶ 這個教訓遠不止適用於 Amazon 的規模:不要先寫好正常路徑、再補上錯誤處理——先把故障模式列舉出來,讓能跑的那條路徑,從一個已經能挺過它們的系統裡自然流出。這是把證據之門應用到可靠性上——「在示範裡能跑」不是證據;「我在請求進行到一半時殺掉一個節點,它依然保持可用」才是,而這與 Radia Perlman 建構進網路的那種自癒是同一標準——那些網路無需人介入迴路便能重新收斂。

選擇你的一致性,而不是承襲它。 Dynamo 裡最深的那步動作,是拒絕那個預設設定:每次讀取都必須看到先前每一次寫入。Vogels 把一致性變成一個你按工作負載來設定的旋鈕——正確性要求的地方就調強,可用性更重要的地方就用最終——並對一個系統實際提供的是哪種保證保持精確。⁴⁷ 這套紀律,就是確切知道你的一致性主張所憑依的是什麼,且絕不為某個工作負載並不需要的保證付費。這與 Leslie Lamport 為分散式時間帶來的那種對正確性的精確如出一轍:不要假定那個性質,要把它精確地定義出來,並知道它何時成立。

透過解耦來圍堵爆炸半徑。 硬性 API 之後的獨立服務,意味著一個故障被困在它發生的地方,而不是級聯蔓延。⁵ 這個始終在場的習慣,是這樣去劃定邊界:讓最壞情形是一個降級的功能,而絕不是一個當掉的系統——對每一項相依都問一句「當它出故障時,這個洞有多大」,並把洞做小。這是最小可敬產品的架構形態:最乾淨的邊界,是那種恰好只做自己分內之事、並且獨自出故障的邊界。

讓建構者擁有維運。 「you build it, you run it」把設計了某個服務的人放到它的呼叫器前,合上了脆弱點與那個能修復它的人之間的迴路。⁵ 這個教訓是:維運的痛苦,是世上最誠實的品質訊號——一個與正式環境隔絕的團隊會對韌性投入不足,因為脆弱的代價落在了別人身上。擁有是一種可靠性機制,這正是被鑄成組織架構圖的品質是唯一的變數:保證品質的唯一辦法,是讓建構者親身感受品質缺席的後果。

把取捨公開講清楚。 Dynamo 的影響力,不是來自它的程式碼——那程式碼從未發布——而是來自一篇明明白白講清了放棄哪些保證、為什麼放棄的論文。²³ 這個習慣,是讓推理變得可讀:給取捨命名,為你所選的那一側辯護,並教會下一個工程師去對它進行推理,而不是照搬結果、奉若神明。對為什麼的清晰,正是讓一個設計活得比它的作者更久的東西——這與讓 Perlman 和 Lamport 的論文在數十年後仍可教學的,是同一種解釋的紀律。

影響鏈

誰塑造了他

Ken Birman 與康乃爾的可靠分散式系統傳統。 Vogels 在康乃爾的那十年,身處 Birman 的研究組以及 Isis/可靠群組通訊的譜系之中,正是他奠基前提的源頭。¹ 那個傳統的核心問題——一群機器如何在其成員不斷故障與復原的同時保持正確與可用——恰恰就是「一切都會一直出故障」所回答的問題。他並沒有發明一句口號;他是為一個行星級的受眾,重新陳述了他這一領域的第一性原理。(塑造性影響)

Andrew Tanenbaum 與分散式系統學界。 他的自由大學博士學位,部分由 Tanenbaum 指導,後者是該領域作業系統與分散式系統的奠基性教師之一。¹ 這份根底顯而易見:Dynamo 讀起來像是分散式系統正典的一次可執行的綜合——一致性雜湊、向量時鐘、法定人數、流言——由一個對文獻瞭如指掌的人組裝而成。(塑造性影響)

Eric Brewer 與 CAP 取捨。 Vogels 為最終一致性所做的論證,明確地建立在那個 CAP 觀察之上:一個分區容錯的系統必須在一致性與可用性之間做取捨。⁴⁷ Brewer 框定了那個不可能性;Vogels 在 Amazon 的規模上把這個選擇落地為操作,並讓「選可用、然後收斂」成了一個體面的預設選項。(直接影響)

他塑造了誰

整個 NoSQL 運動。 Dynamo 論文是 Cassandra、Riak 和 Voldemort 的直系祖先,也是 DynamoDB 的同名之源——那種無主、最終一致的設計範式,從2007年的一篇論文,傳播進了一代系統的資料層。³

雲端原生架構與 DevOps 文化。 「you build it, you run it」成了現代 DevOps 的奠基思想之一——全程服務擁有、值班開發者,以及開發/維運之牆的消融,都可直接追溯到 Vogels 在2006年所描述的那個模式。⁵

一代雲端架構師。 透過 AWS 的設計原則以及他持續不斷的佈道,「為故障而設計」「把爆炸半徑降到最小」「透過服務解耦」成了工程師們用來推理如何在雲端上建構可靠系統的預設詞彙。⁶

貫穿始終的主線

Vogels 是本系列的維運規模拱頂石——那位把分散式系統理論拿來、在一整個行星的機器上跑起來的人物。Leslie Lamport 給了分散式系統它們的根基:如何精確地定義時間、定序與共識,以及當參與者出故障或行為任意時如何讓系統保持正確。Vogels 則是那些根基在不得不去支撐一個黑色星期五購物車時的樣子——同樣是關於一致性與故障的問題,但回答的現場不是白板,而是真實負載之下,真金白銀的營收押在「保持可用」上。⁴ 而 Radia Perlman 建構的網路,把故障情形當作設計的中心,無需人介入迴路便能自我治癒;Vogels 則在更上一層、恰恰憑著那種本能建構了服務——複製、解耦、圍堵爆炸半徑,並讓系統自行收斂。Lamport 說定義正確性、並證明它能挺過故障,Perlman 說把它建構成能自我治癒,而 Vogels 說:一切都會一直出故障,所以別再試圖防止它了——要這樣設計,讓系統徑直穿過故障而保持可用,並讓維運它的那些建構者感受到每一道裂縫。(系列橋接)

我從中汲取的

我從 Vogels 這裡留下的教訓,是把故障當作常態,而非例外。我的本能,和大多數建構者一樣,是去寫那條呼叫成功、相依應答、磁碟就在那裡的路徑——然後等它跑通了,再栓上一個 try/catch。「一切都會一直出故障」是對此的反駁:在任何真實的規模下,故障都不是一樁稀罕的、發生在我系統身上的事件,而是我系統所身處其中生活的一個恆常條件。所以現在當我建構某樣東西時——一個同步作業、一個 API 用戶端、一個佇列消費者——我會試著從「什麼會死,而當它死去時其餘部分還繼續提供服務嗎」出發,而不是最後才走到那一步。「它能跑」的誠實版本,不是那個一片綠的示範;而是在請求進行到一半時殺掉一個相依,看著系統優雅降級而不是翻倒。一個只能挺過正常路徑的系統,是一個我還沒設計完的系統。

第二個教訓是:可用性與一致性,是一樁我必須刻意去做的取捨。兩個都想要是很誘人的——每次讀取都看到每一次寫入,而且系統永遠不說不——而對一台單機,你確實可以兩全。可一旦我複製了任何東西,那份安逸就沒了,而 Vogels 的紀律,是為每個工作負載刻意去選擇一側,而不是出於習慣在所有地方都預設用最強的保證。我所建構的大多數東西,並不需要一次讀取立即反映最新的寫入;它需要的是永不拒絕客戶。最終一致性為我把這件事重新框定了:從一個嚇人的妥協,變成一件精確的工具——確切地說出一個讀者能容忍多陳舊,用這份餘量換來可用性,並停止為一個功能從不需要的保證付費。這門手藝不在於總是去搆那個最強的承諾——而在於知道這項工作實際需要的是哪個承諾。

常見問題

「everything fails all the time」(一切都會一直出故障)是什麼意思?

這是 Werner Vogels 對一個關於規模、來之不易的教訓所做的壓縮:當你執行著足夠多的機器時,元件故障不再是一樁罕見的例外,而成為一個恆常的、統計上必然的條件。⁶ 一種在單台伺服器上罕見到可以忽略的故障模式,在一個大機群的某處會持續不斷地發生。其實際後果,是對常規工程的顛倒:不是去試圖防止故障,而是假定每一塊磁碟、每一台伺服器、每一條鏈路、每一項相依都會出故障,並設計出能在故障之中保持可用的系統——透過冗餘、解耦,以及被圍堵的爆炸半徑——使任何單一故障都能被挺過去,理想情況下還不可見。¹⁶

Dynamo 論文是什麼?

《Dynamo: Amazon’s Highly Available Key-value Store》是一篇2007年的 SOSP 論文,由 Vogels 共同撰寫,描述了 Amazon 為了讓購物車這類服務即使在故障與網路分區期間也保持可寫而建構的儲存系統。²³ 它把這些技術結合在了一起:用於分區的一致性雜湊、用於追蹤並行寫入的向量時鐘、用於在故障下保持可用的寬鬆法定人數與提示移交、用於修復的以默克爾樹為基礎的反熵,以及用於去中心化成員管理的流言——全都服務於始終接受一次寫入、稍後再調和。Amazon 從未發布程式碼,但這篇論文成了 NoSQL 運動的基石,直接影響了 Cassandra、Riak、Voldemort 以及 Amazon DynamoDB。³

什麼是最終一致性?

最終一致性是 Vogels 所倡導、並在其文章《Eventually Consistent》中定義的一種寬鬆的一致性模型:「如果不再對該物件做新的更新,最終所有存取都將回傳最後更新的那個值。」⁴ 在一個複製的系統裡,一次寫入可能先到達某些副本、再到達另一些,所以在一個短暫的窗口裡,不同副本可以回傳不同的答案——但誰都絕不拒絕一次請求。系統保持可用,在背景收斂,而不是阻塞到每個副本都達成一致為止。它是 CAP 取捨中偏可用性的那一側:當網路發生分區時,系統可以是一致的(拒絕作答,直到所有人達成一致)或可用的(用手頭已有的內容作答,稍後再調和),而最終一致性選擇了可用。⁴⁷

「you build it, you run it」是什麼意思?

「you build it, you run it」(誰建構,誰維運)是 Vogels 在2006年一次 ACM Queue 對話中,對 Amazon 全程服務擁有模式的描述:建構某個服務的團隊「對該服務負完全責任——從界定功能範圍,到對它做架構設計,再到建構它、維運它。」⁵ 開發與維運之間沒有一堵牆——寫下程式碼的工程師為它背上呼叫器。Vogels 主張,這「讓開發者接觸到自己軟體的日常維運」,並「與客戶產生日常接觸」,而由此產生的回饋迴路,正是驅動品質的東西。⁵ 這個理念成了現代 DevOps 文化的奠基原則之一。

Sources