《代碼英雄》第一季（4）：DevOps，拆掉那堵牆

本文是《代碼英雄》系列播客第一季（4）：DevOps，拆掉那堵牆的音頻腳本。

當應用開發的爭鬥暫告一段落，橫亘在開發者與運維之間的那堵牆開始崩塌。在牆徹底倒塌的時候，牆兩邊的人都應該學會如何合作，彼此變得親密無間。

不過到底什麼是 DevOps？開發者一方的嘉賓，包括來自微軟的 Scott Hanselman 和 Cindy Sridharan（即 @copyconstruct），他們從開發者的角度認為 DevOps 是一種慣實踐。而來自運維一方的成員則他們一直在努力捍衛的東西。雙方依然存在差異，不過因為 DevOps 的誕生，大家的合作效率會比之前更上一層樓。這集節目講述了這種方法的誕生對於大家有多重要。

Saron Yitbarek： 請你想像這樣一堵牆：這堵牆從你目之所及的最右側延伸到最左側。牆比你高，你無法看見牆背後。你知道牆的另一側有很多很多人，但你不清楚他們是否和你一樣，不清楚他們是敵是友。

00:00:30 - Gordon Haff： 開發者創造代碼，然後把代碼扔過牆丟給運維，之後發生的問題都是運維的責任了。

Richard Henshall： 他們隨心所欲，並不真正關心服務質量。

Sandra Henry-Stocker： 牆這兩面的人幾乎做著相反的工作 —— 一方做出改變，另一方儘可能抵制那些改變。

Richard Henshall： 但對於他們到底想共同達成什麼，卻沒有在同一幅藍圖中規划過。

00:01:00 - Saron Yitbarek： 我是 Saron Yitbarek，這裡是《代碼英雄》，由紅帽公司推出的原創播客欄目。第四期，我們的標題是《DevOps，拆掉那堵牆》。

是的，數十年來，IT 界劃分為各種角色。一邊是開發者，他們要儘可能快地去創造更多變化。然後另一邊是運維團隊，他們要去阻止太多改變發生。與此同時，代碼在沒有充分共鳴和溝通的條件下，被盲目扔過兩方之間的牆。怎樣才能拆掉這堵牆呢？這需要一個重大的轉變。

00:01:30 - Saron Yitbarek： 開源運動震撼了整個戰場。上一期，我們看到了新的敏捷方法論，它重視不間斷的迭代改進，而這種對速度的要求將迫使我們改變彼此的工作方式。一群彼此孤立的人工作的速度是有極限的，而這個極限是一個問題，因為……

00:02:00 - Richard Henshall： 因為都是為了更快的將產品推向市場、提高敏捷性、更多的迭代，而不是長期而大量的工作。

Saron Yitbarek： Richard Henshall 是 Ansible 的一位產品經理。

Richard Henshall： 是的。還記得你以前下單購買伺服器，四個月後到貨。所有東西都整合在一起，所以整個堆棧是一個整體，要花幾年時間來設計和建造那些東西。現在這種情況已經不存在了，對於很多組織來說，這種方法已經……已經壽終正寢，偶爾拿過來試試，然後放棄它。

00:02:30 - Saron Yitbarek： 如今，像亞馬遜這樣的公司每分鐘都會部署幾次新的代碼。想像一下，用按部就班的瀑布式工作流，簡直不可能完成這些工作。所以為了繼續快速完成工作，那些關於穩定性、安全性、可靠性的顧慮都會被運維丟到一邊不管。

00:03:00 - Saron Yitbarek： 同時，開發者也沒有意識到他們的責任是創造真實環境可用的代碼。開發者對穩定性和安全性毫無興趣，但這些恰恰是我們需要解決的問題。所以，我們最終會有很多無謂的修改，在雙方之間來來回回。

想像一下過度分工會如何拖慢公司效率，但開發法者很少被鼓勵思考除代碼之外的其他事務。

Sandra Henry-Stocker： 他們的目錄規模只會越來越臃腫，但他們從不清理。除非已經無法工作才不得不清理。

00:03:30 - Saron Yitbarek： Sandra Henry-Stocker 是位退休的系統管理員，為 IDG 雜誌撰稿。

Sandra Henry-Stocker： 我過去經常勸說別人，說，「嘿，你看，你用了這麼多的磁碟空間。是不是有什麼東西你可以整理一下，這樣我們就有更多的存儲空間來運行了 —— 因為伺服器上的存儲空間快用完了。」是的，我們經常經歷這些事。

Saron Yitbarek： 歸根結底，這是一個心態問題。這種開發者和運維之間的態度分裂，一方不必去理解另一方的擔憂。好吧，在過去這還沒太大問題，但隨著開發速度成為一種重要的優勢，這種分裂的文化急需改進。孤立在自己的工作圈子裡，效率太低了。

Jonah Horowitz 在 Stripe 的可靠性工程團隊工作。他描述了即使開發人員和運維人員想一起工作，他們也無法做到。因為從某種意義上說，他們被安排在對立的團隊中。

00:04:30 - Jonah Horowitz： 運維團隊經常以正常運行時間和可靠性來衡量，而提高正常運行時間的最大方法之一，就是減少系統的變化量。當然，發布新功能就是在改變系統，而做產品工作的軟體工程師有動力去儘快發布儘可能多的功能。所以，當開發和運維的職責不同時，他們自然有了衝突。

00:05:00 - Saron Yitbarek： 開發者致力於新建功能，運營致力於維持運行，兩者目標相互矛盾。但就像我說的，由於對速度的需求越來越大，對快速迭代發布的需求越來越大，開發和運維之間的脫節已經到了一個臨界點，必須要有所改變。

00:05:30 - Saron Yitbarek： 在 2009 年左右，將開發和運維分開的那堵牆看起來像是監獄的牆。我們需要的是一種新的方法論，它能使開發和運維之間的隔閡順暢過度，讓雙方以更快、更整體化的方式工作。

視頻平台 Small Town Heroes 的首席技術官 Patrick Debois 為想要拆掉這堵牆的人發起了一場會議。他把這個的腦洞叫做 DevOps Days（開發運維日）。為了便利，他將其縮短為 DevOps，於是這場改革就有了名字。

00:06:00 - Saron Yitbarek： 不過名字並不代表改革的一步，我們知道為什麼我們需要 DevOps，但究竟該如何做？我們應該如何將開發和運維結合起來而不引發戰爭？幸運的是，我有 Scott Hanselman 來指導我。Scott 是微軟 .NET 和 ASP.NET 的首席項目經理。

所以，Scott，我認識你確實有幾年了，但感覺還是相見恨晚啊。

00:06:30 - Scott Hanselman： 我也是，相見恨晚哈。

Saron Yitbarek： 我想和你聊聊你如何成為一個開發者，和 DevOps 這些年的變化。覺得如何？

Scott Hanselman： 嗯，聽上去挺有意思。

00:07:00 - Saron Yitbarek： 好的。我認為究竟什麼是 DevOps 是一個好的開場問題。你會怎麼定義它呢？

Scott Hanselman： 在 2008 年，維基百科有個關於 DevOps 的定義確實很棒。它說，這是一套「慣例」，目的是在保證質量的前提下，縮短提交變更和變更投入生產之間的時間。所以，如果你想想，假如今天是周二，我檢查了一些代碼，而這些代碼將在 6 月的版本中上線。這就很糟糕了，因為這不是持續集成，而是一年幾次的集成。

00:07:30 - Scott Hanselman： 如果你有一個健康的 DevOps 體系，如果你已經有「 設置 - 上線 set - up 」的慣例，那麼你就可以不斷地將代碼集成到生產中去。那麼，你能做什麼？你可以定義、創造怎樣是最佳「慣例」，這將決定你能否成功。所以，我在周二檢查的一些代碼，周四就上線了。那麼現在，為了保證高質量，最重要的事情就會是 —— 謹慎上線。

00:08:00 - Saron Yitbarek： 這個定義真的很有趣呢，是個「慣例」。但我覺得當我聽人們談論 DevOps 時，它具體一點。他們談論它就像它是一個角色、一個工作、一個職位或一個頭銜。你覺得這與它是一套「慣例」的觀點是否有衝突？

Scott Hanselman： 我認為，當一套新的方法或一個新的流行語出現時，人們喜歡把它加在名片上。我不是不尊重那些正在收聽這個播客，並且感到被我冒犯、正罵罵咧咧把名片掏出來看的人們。雖然，他們現在可能正要怒蓋筆電、退出這個播客。

00:08:30 - Scott Hanselman： 有一個帖子寫得非常好，作者是 Brian Guthrie，他是一個腦力勞動者，在 SoundCloud 工作。他是一個超級聰明的人，幾天前他在 Twitter 上的帖子中說到 DevOps。他說 DevOps 就是一套慣例，不是一個工作頭銜、不是一個軟體工具、不是一個你安裝的東西、也不是一個團隊的名字。

00:09:00 - Scott Hanselman： 他的原話是：「DevOps 不是神奇的『企業萬能葯』」。如果你沒有好的慣例，如果你沒有良好的習慣，你就沒有 DevOps。所以，這更多的是一種心態，而不是擺出一個工作頭銜，然後「我們要僱傭一個 DevOps 工程師，然後我們要把這些神奇的 DevOps 工程師撒到組織中。雖然整個組織沒有意志力，也沒有信奉 DevOps 的想法。」 所以，如果你認為 DevOps 是一個工具或者是用來安裝的東西，那麼你就完全理解錯了。

00:09:30 - Saron Yitbarek： 好吧，讓我們回到過去，在 DevOps 這個名詞出現之前，在我們往名片上寫 DevOps 或者把它作為一套「慣例」來討論之前。在 10 年前，你會如何描述開發者和那些運維人員之間的關係？

Scott Hanselman： 那是相當的水火不容。舉個例子，運維控制著生產，但開發人員從來沒有接近過生產。我們站在一堵不透明的牆的兩側。我們在開發部的時候，儘可能地去做一些看起來像生產環境能用的東西，但實際上從來沒有……從來沒有像樣的產品。

00:10:00 - Scott Hanselman： 我們有相當多問題。我們的開發環境從各個方面來說都不像生產環境，所以你不可避免地會遇到那些 「嘿，它在生產環境中的工作方式和在開發環境中的不同」 的問題。然後，從開發到投入生產之間的間距是幾周幾周的長久間隔，所以你的大腦甚至不在正確的頻道上。比如說，我在一月份的時候就在研究這個功能，現在四月份才剛剛上線，那麼當 bug 不可避免地出現的時候，要等到六月份才能修復，我甚至不記得我們之前在幹嘛。

所以運維團隊的人，他們的工作是……他們的工作幾乎就是有意識地讓我們慢下來。好像他們的存在是為了讓開發人員更慢，然後他們還覺得我們隨時會讓生產環境崩壞。

00:11:00 - Saron Yitbarek： 那麼為什麼會這樣呢？是對開發者想要做什麼和他們做了什麼不了解？還是信任問題？為什麼會有這麼大的衝突？

Scott Hanselman： 我覺得你已經回答了，而且回答得很到位。你說的很對，確實是信任的問題。我覺得開發人員認為他們是特殊的，或者某些方面比 IT 人員更優越，而 IT 人員認為開發人員不尊重生產。

00:11:30 - Scott Hanselman： 我認為這種文化的產生，一部分來源於高層。他們認為我們是不同的組織，並且我們的目標也不同。我認為軟體業正在走向成熟，因為我們都意識到，無論業務是什麼，我們寫軟體都是為了推動業務發展。

所以現在有種 「我們都在往正確的方向推進」 的感覺，就像他們說的，「專註一件產品並做到極致」。但這是需要絕對的信任，可 DevOps 工程師不信任產品工程師來部署代碼，對吧？

00:12:00 - Scott Hanselman： 但 DevOps 工程師傳統上並不寫代碼，所以他們並不了解什麼被修改了。所以他們對於在各個層面的人都缺乏信任。沒有人理解部署過程，人們只信任自己，他們的心態……舉個例子，就像「我只信任自己的工作。我不能相信 Saron 的工作，她甚至不知道她在幹些什麼。我會做完所有的事情。」

00:12:30 - Scott Hanselman： 所以如果沒有人真正理解這個系統，那麼 全棧工程師 full stack engineer 的概念就是一個神話。但是現在，我們開始將一整個組織稱之為全棧。我們已經有了 全產品所有權 full product ownership 這樣的名詞，敏捷方法論也出現了，也就是說每個人都應該擁有產品。社區對於軟體所有權和對於代碼的想法都慢慢發生了變化，這種改變帶來了一個充滿信任的環境。

00:13:00 - Saron Yitbarek： 我是 Saron Yitbarek，你現在收聽的是《代碼英雄》，來自紅帽公司的一檔原創播客欄目。所以，要想讓 DevOps 發揮出它的潛力，我們就需要雙方都有更多的信任，這就意味著要有更多的溝通。回到 Richard Henshall 身上，他認為雙方的共情是 DevOps 的基石 。

00:13:30 - Richard Henshall： 一些 DevOps 的從業者，一群真正優秀的從業者，都參與過這兩種角色。我認為這才是真正的力量所在 —— 當人們真正做過了兩種角色，而不是只看到其中一種。所以，你不該保持孤立，你實際上……你應該去和雙方都一起工作一段時間。我想這才是讓人恢復同理心的方法。

Saron Yitbarek： 現在，這不僅僅是為了溫情的溝通。Richard Henshall 所描述的是行業重點的轉向 —— Scott 剛剛提到過。

00:14:00 - Saron Yitbarek： 一個關於 持續集成 continuous integration （CI）的觀點。軟體不僅要以小批量快速編寫和發布，還要以小批量進行快速測試。這意味著，開發人員需要即時反饋他們正在編寫的代碼在現實世界中的表現。

隨著上市時間從幾個月縮短到幾天，再到幾個小時，我們四處尋找一套新的工具，可以將任何可以自動化的元素自動化。

00:14:30 - Gordon Haff： 你需要一個全新的生態系統和工具，來最有效地進行 DevOps。

Saron Yitbarek： Gordon Haff 是一位紅帽公司高級工程師。

Gordon Haff： 我們看到有很多巨大的、DevOps 可以利用的新種集合工具和平台，它們都誕生於開源。

Saron Yitbarek： Gordon 是對的。新的集合工具是很龐大，關於開源這點他說的也對。在一個嚴格的專有系統中，自動化工具是不可能發展的。

00:15:00 - Gordon Haff： 其中有很多監控工具，Prometheus 是其中一個常見的工具。它開始引起很多人興趣，用於編排服務的 STO 也出自這裡。

Saron Yitbarek： GitHub 讓你跟蹤變化，PagerDuty 管理數字業務，NFS 可以跨網路掛載文件系統，Jenkins 讓你自動測試你的構建。

00:15:30 - Saron Yitbarek： 這麼多工具，這麼多自動化流程。最終的結果是，開發人員可以將他們的變更直接推送到生產現場，自動創建構造，實行經過嚴格管理的編譯與針對性的自動測試。Sandra Henry-Stocker 描述了這是怎樣的變化。

Sandra Henry-Stocker： 所以，我可以把我正在工作編寫的東西快速部署。我可以只在一個系統上，通過命令行控制許多系統，而不是必須在在很多不同的系統上工作，也不用學習就可以利用網路，將代碼部署到其他機器上。

00:16:00 - Sandra Henry-Stocker： 現在，在計算機系統中進行改動更容易了。坐在一個地方，就能實行一切操作。

Saron Yitbarek： 自動化工具已經解決了速度問題。但我不希望我們只讚美工具，而忽略了實際的方法論，文化的轉變。Scott Hanselman 和我談到了這個微妙的界限。

00:16:30 - Saron Yitbarek： 你在這次談話開始時說，DevOps 是一套慣例，是一種心態，是一種思維方式。聽起來，我們創造的工具是我們應該思考和操作方式的具體代碼實現。

Scott Hanselman： 我喜歡這句話，你真是個天才。沒錯，我們以前讓產品開發在 Word 文檔中寫下這些代碼是如何工作的。他們寫的是規範，對吧？這些文檔過期了嗎？

00:17:00 - Saron Yitbarek： 沒錯。（答非所問）

Scott Hanselman： 哈？

Saron Yitbarek： 好吧，我只是很高興 Scott 剛才說我是天才。但我也確實認為，這些工具幾乎是我們文化轉變的象徵。它們鼓勵我們拓寬我們的角色定義。我們開發者已經被迫，至少偶爾關注代碼的運行。這樣一來，開發和運維的主要職責就部分統一了。事實上，DevOps 的興起告訴我們的是，在一個速度不斷提升的世界裡，沒有人能夠保持孤島狀態。

00:17:30 - Saron Yitbarek： Jonah Horowitz 曾在灣區多家公司工作，包括 Quantcast 和 Netflix。他說即使是世界上一些最大的公司，也從這個角度重新塑造了他們的文化。

Jonah Horowitz： 我們在文化上得到了整個公司的認同，就像，「這就是我們要部署軟體的方式，我們將以小批量的方式進行部署，我們將使用這些程序幫助部署。」 如果 DevOps 只是被運營團隊所驅動，我不認為它可以……我不認為它可以成功。

00:18:00 - Jonah Horowitz： 這必須成為公司的管理層和領導層所認同的東西才能發揮作用，而這件事很大程度上，意味著一種文化轉變。

Saron Yitbarek： 當 MacKenzie 對 800 名 CIO 和 IT 高管進行調查時，80% 的人表示，他們正在規劃讓自己的一部分下屬組織實施 DevOps，超過一半的人計划到 2020 年，在全公司範圍內實施。高管們意識到，自動化工具可以提升交付速度。

00:18:30 - Saron Yitbarek： 這些人過去也是這樣的人，他們習慣於讓一個貨板先到達數據中心，然後在新機器上線之前讓它在那裡放上整整一個月。不過在今天，如果你等待的時間超過 10 分鐘，就說明你做錯了什麼。隨著競爭對手的速度增加，沒有人能夠承受得起落後。

00:19:00 - Saron Yitbarek： 我可以想像，運維團隊一定很緊張，因為他們把所有的工具都交給開發人員。運維團隊習慣了做成年人，而現在叫他們把車鑰匙交給一貫的孩子 —— 開發人員？呀，我想我們開發人員正在學習，如何在不破壞東西的前提下快速移動。但隨著 DevOps 革命的塵埃落定，變化最大的可能是運維團隊。

00:19:30 - Saron Yitbarek： DevOps 是否真的威脅到了運維的存在？開發是否在用它閃亮的新工具來吃掉運維？Cindy Sridharan 是一位開發者，她寫了一篇長篇調查文章來討論這些問題。在你的文章和博客中，你提到運維人員對事情這樣的發展並不一定滿意。到底發生了什麼？你會說什麼？

Cindy Sridharan： 這麼說吧，DevOps 的理想是責任共享。開發者和運維將有，就像你知道的，更多的是五五分成，以真正確保軟體的整體交付。

00:20:00 - Cindy Sridharan： 我認為很多運維工程師的不快樂源於這樣一個事實，那就是這些改變都沒有實際功效。他們仍然是總被雞蛋挑骨頭的人，他們仍然是總做苦力工作的那些人，他們還是那些主要肩負著實際運行應用的責任的人，而開發者不一定要做得足夠好。

Saron Yitbarek： 這個問題在未來幾年將至關重要。DevOps 的作用到底有多大？隨著我們的自動化進程，運維的作用是會被削弱，還是會發生轉變？

00:20:30 - Saron Yitbarek： 但是我們要記住，DevOps 不僅僅是工具和新技術的應用。這種方法論實際上是在塑造技術，反過來技術也在塑造方法論，這樣就有了一個神奇的反饋循環。文化造就了工具，而工具又強化了文化。

00:22:00 - Saron Yitbarek： 最後，我們在節目開頭描述的那堵牆，也就是把開發和運維劃分開來的那堵牆，我甚至不知道五年後「把你的代碼扔過牆」的比喻對一個開發者來說是否有意義，如果五年後大家都聽不懂這個比喻，那真是一件大好事。不過目前為止的訪談很有價值，我聽到了很多新的故事。

現在說話的是雲架構師 Richard Henshall。

Richard Henshall： 我覺得 DevOps 開始讓人們意識到對方關心的是什麼，我看到了更多對彼此的理解。

00:23:00 - Saron Yitbarek： 現在是系統管理員 Jonah Horowitz。

00:23:00 - Jonah Horowitz： 我認為你需要很棒的技巧來寫出真正好的軟體，我在與我合作過最棒的開發者身上看到了一件事，那就是他們真的，他們貢獻了關於的軟體工程新技巧，或者說他們推動了軟體開發這個行業的發展。

Saron Yitbarek： 最後一個是系統管理員 Sandra Henry-Stocker。

Sandra Henry-Stocker： 我認為，開發者會變得更加精明、更加謹慎。他們始終要提升自己的技能，我知道這需要很多辛苦的學習。

00:23:30 - Saron Yitbarek： DevOps 是個愛的結晶。原來，在那堵牆的另一邊還有一些朋友，很高興認識你們。所以，坦白一下，我以前總覺得 DevOps 很無聊，就是一堆硬核的自動化腳本和擴展問題。我的抵觸情緒有一部分是出於它的實踐難度。作為開發者，我每周都要面對一些新出來的工具，一些新的框架。DevOps 一直是那些可怕的、快速變化的一部分。但現在，尤其是聽了這些故事之後，我明白了。

00:24:00 - Saron Yitbarek： DevOps 不僅僅是其工具。它是教導我們如何合作，更快地構建更好的產品的方法。

好消息是，隨著為你我這樣的開發者準備的新平台出現，我們的工作變得更好、更快、更能適應不同的環境，我的業務圈也可以不斷擴大。你會看到人們將 DevOps 擴大到安全部分，所以我們能得到 Sec DevOps。或者他們開始包含商務，那我們就得到了 Business DevOps。我們現在要辯論的話題是：對於一個開發者來說，不僅要了解如何使用這些工具，還有了解所有 DevOps 的東西是如何工作的必要嗎？以及我們需要所有開發者都去了解這個新世界嗎？

00:24:30 - Saron Yitbarek： 這場辯論的結果將決定未來一期《代碼英雄》的內容。

你可能已經注意到，在所有關於工具和自動化的談話中，我漏掉了一些工具。好吧，我把這些留到下一期，當所有這些 DevOps 自動化達到光速時，我們將追蹤容器的崛起。

00:25:00 - Saron Yitbarek： 是的，這些都會留到第五期。

《代碼英雄》是紅帽公司推出的原創播客欄目。想要了解更多關於本期節目和以往節目的信息，請訪問 redhat.com/commandlineheroes 。在那裡，你還可以註冊我們的新聞資訊。想免費獲得新劇集的自動推送，請務必訂閱該節目。

00:25:30 - Saron Yitbarek： 只要在蘋果播客、Spotify、Google Play、CastBox 中搜索《代碼英雄》，或者通過其他方式收聽，並點擊訂閱，這樣你就能在第一時間知道最新劇集。我是 Saron Yitbarek。感謝您的收聽，編程不止。

什麼是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特別興趣小組 Special Interest Group ，LCTT SIG 是針對特定領域、特定內容的翻譯小組，翻譯組成員將遵循 LCTT 流程和規範，參與翻譯，並獲得相應的獎勵。LCRH SIG 是 LCTT 聯合紅帽（Red Hat）發起的 SIG，當前專註任務是《代碼英雄》系列播客的腳本漢化，已有數十位貢獻者加入。敬請每周三、周五期待經過我們精心翻譯、校對和發布的譯文。

歡迎加入 LCRH SIG 一同參與貢獻，並領取紅帽（Red Hat）和我們聯合頒發的專屬貢獻者證書。

via: https://www.redhat.com/en/command-line-heroes/season-1/devops-tear-down-that-wall

作者：Red Hat 選題：bestony 譯者：LikChung 校對：acyanbird

本文由 LCRH 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive