DevOps 到底是什麼？
已發表: 2022-03-11時間簡史
為了理解 DevOps，我們必須回到過去只有程序員的時代。
正如道教我們：
古代的程序員是神秘而深刻的。 我們無法理解他們的想法，所以我們所做的只是描述他們的外表：
- 覺知，如渡水的狐狸
- 警覺，像戰場上的將軍
- 親切，就像女主人迎接客人一樣
- 簡單，就像未雕刻的木塊
- 不透明，就像黑暗洞穴中的黑色水池
程序員誕生了機器語言。 機器語言催生了彙編程序。 彙編器催生了編譯器。 現在有成千上萬種語言。 每種語言都有其目的，無論多麼謙虛。 每種語言都表達了軟件的陰陽。 每種語言在軟件中都有自己的位置。
當時，軟件開發辦公室大多被稱為實驗室，程序員是科學家。 為了創建一個好的應用程序，程序員必須完全理解應用程序要解決的問題。 他們必須知道應用程序將在哪裡使用以及運行它的系統類型。 從本質上講，程序員對他們的應用程序從規範到開發，再到部署和支持都瞭如指掌。
然後人性開始發揮作用，我們開始要求更多。 更快的速度，更多的功能，更多的用戶，更多的一切。
作為謙虛、謙遜、和平的生物，程序員幾乎沒有機會在如此大量的有需要的用戶總是要求更多的情況下生存下來。 獲勝的最佳機會是開始向不同的方向發展，並創造種姓。 很快，程序員作為開發人員、軟件工程師、網絡管理員、數據庫開發人員、Web 開發人員、系統架構師、QA 工程師等新品種的祖先而滅絕。 快速發展和適應外部世界的挑戰成為他們 DNA 的一部分。 新種姓可能會在幾週內進化。 Web 開發人員變成了後端開發人員、前端開發人員、PHP 開發人員、Ruby 開發人員、Angular 開發人員……這一切都下地獄了。
很快他們都忘記了他們來自同一個父親，一個程序員。 一個單純而平和的科學家，只想讓世界變得更美好。 他們開始互相爭鬥，聲稱他們每個人都是“程序員”的真正後裔，並且他們的血統比其他人更純潔。
隨著時間的流逝，他們將互動減少到最低限度，只在真正需要時才相互交談。 他們不再為遠方家人的成功慶祝，最終甚至不再每隔一段時間就寄一張明信片。
如果他們只探尋自己的感受，就會發現程序員的火花就在他們心中，等待著閃耀，為銀河繫帶來和平。
在他們自私和以自我為中心的征服世界的競賽中，程序員的後代忘記了他們工作的真正目的——為他們的客戶解決問題。 客戶開始感受到項目延遲、成本過高甚至失敗等行為的痛苦。
每隔一段時間，一顆璀璨的星星就會閃耀，有人會得到靈感，試圖在後裔之間建立和平。 他們想出了瀑布。 這是一個絕妙的想法，因為它利用了不同開發人員組僅在必要時進行交流的事實。 當一組完成他們的部分工作時，它會與下一組進行溝通，將工作發送到整個過程中，並且從不回頭看。
這工作了一段時間，但像往常一樣，人類（客戶）再次想要更多。 他們想更積極地參與到軟件開發的整個過程中，更頻繁地發表意見，甚至在為時已晚的情況下要求更改。
軟件項目變得如此容易失敗，以至於它被接受為行業標準。 統計數據顯示，超過 50% 的項目都失敗了，似乎沒有什麼可做的（ZDNet、CNet）
每一代人都有一些思想開放的人，他們知道所有這些開發人員群體都必須找到一種方法來一起工作、溝通並保持靈活性，以確保他們的客戶將獲得最佳解決方案。 早在 1957 年，偉大的約翰·馮·諾依曼 (John Von Neumann) 的同事就已經有這些嘗試的痕跡。 然而，我們不得不等到 2001 年初才開始革命，當時十幾個骯髒的人創建了敏捷宣言。
敏捷宣言基於十二項原則：
- 通過早期和持續交付有價值的軟件來滿足客戶的需求
- 歡迎不斷變化的需求，即使是在後期開發中
- 工作軟件經常交付（幾周而不是幾個月）
- 業務人員和開發人員之間密切的日常合作
- 項目是圍繞有動力的個人建立的，他們應該被信任
- 面對面交談是最好的溝通方式（同地辦公）
- 工作軟件是衡量進度的主要標準
- 可持續發展，能夠保持恆定的步伐
- 持續關注卓越的技術和良好的設計
- 簡單——最大化未完成工作量的藝術——是必不可少的
- 自組織團隊
- 定期適應不斷變化的環境
敏捷宣言是為銀河帶來和平和恢復原力平衡的第一步。 很長一段時間以來，第一次在軟件開發過程中連接所有利益相關者是基於文化和“人”的方式，以及程序化和機械化的方式。 人們開始互相交談，定期見面，並一直在交流想法和評論。 他們意識到他們的共同點比他們想像的要多得多，客戶也成為了團隊的一部分，而不僅僅是一些外部因素，這些因素預計會寄錢而不會問任何問題。
還有一些障礙需要克服，但未來似乎比以往任何時候都更加光明。 敏捷意味著開放並願意適應不斷的變化。 然而，由於變化太多，很難專注於最終目標和交付。 這就是精益軟件開發如何實現的。
迷上了 LSD（雙關語）並冒著被流放和被拋棄的風險，一些後代在他們的種姓和軟件行業之外尋找解決方案。 他們在一家大型汽車製造商的工作中找到了救贖。 豐田生產系統的簡單性令人驚嘆，它的精益製造可以很容易地應用於軟件開發。
精益有7個原則：
- 消除浪費
- 建立質量
- 創造知識（擴大學習）
- 推遲承諾（盡可能晚地決定）
- 盡快交付
- 尊重人（授權團隊）
- 優化整體
除了敏捷之外，精益原則支持心態和專注於做正確的事情，同時在整個過程中保持靈活性。
一旦軟件開發團隊採用了敏捷和精益，只需再邁出一步，就可以將整套原則應用到整個 IT 中——這最終將我們帶到了 DevOps！
進入 DevOps - 三車道高速公路
軟件開發團隊的老派觀點包括業務分析師、系統架構師、前端開發人員、後端開發人員、測試人員等等。 優化軟件開發過程，包括敏捷和精益原則，主要集中在這些方面。 一旦應用程序“生產就緒”，它就會被發送給“運維”，包括系統工程師、發布工程師、DBA、網絡工程師、安全專業人員等。消除Dev和Ops之間的長城是DevOps的主要驅動力。
DevOps 是對整個 IT 價值流實施精益原則的結果。 IT 價值流將開發延伸到生產，結合了原始程序員的所有“遠親”。
Gene Kim 對 DevOps 解決方案給出了最好的解釋，如果你還沒有讀過The Phoenix Project ，我建議你花點時間去做。
你不應該僱傭 DevOps 工程師，並且 DevOps 不應該是你 IT 中的一個新部門。 DevOps 是一種文化和思維方式，它是整個 IT 的一部分。 沒有任何工具可以讓您的 IT 成為DevOps 組織，也沒有任何級別的自動化能夠使您的團隊能夠為您的客戶提供最大價值。
DevOps 通常被稱為三路方法，但我將它們視為同一條高速公路的三個車道。 您從第一車道開始，然後加速並切換到第二車道，最終您在第三車道超速行駛。
第一道 - 整個系統的性能是主要焦點，強調系統任何單個元素的性能
通道二 - 確保有一個恆定的反饋循環向上游發送，並且不被忽略
第三道 - 培育實驗，不斷改進，快速失敗
第一道 - 加快速度
了解整個系統的重要性並正確確定工作項的優先級是 IT 組織在採用 DevOps 原則時必須學習的第一件事。 不允許 IT 價值流中的任何人製造瓶頸並減少工作流程。
確保不間斷的工作流程是流程中每個人的最終目標。 無論一個人或一個團隊扮演什麼角色，他們都必須尋求對系統的深刻理解。 採用這種思維方式對質量有直接影響，因為缺陷永遠不會發送到下游，因為它們會導致瓶頸。
確保工作不會停滯是不夠的。 一個富有成效的組織應該始終尋求增加流量。 有許多方法可以增加流量。 您可以在約束理論、六西格碼、精益或豐田生產系統中找到解決方案。 隨意選擇其中任何一個，想出自己的，或將它們組合起來。
DevOps 原則並不關心您屬於哪個團隊，如果您是系統架構師、DBA、QA 或網絡管理員。 同樣的規則適用於每個人，每個人都應該遵循兩個簡單的原則：
- 保持系統流程不間斷
- 隨時增加和優化工作流程
車道二 - 加速
不間斷的系統流程是單向的，預計從開發到運營。 在理想的世界中，這意味著軟件可以快速創建高質量、部署到生產環境並為客戶提供價值。
但是，DevOps 不是烏托邦，如果可以實現單向交付，瀑布方法就足夠了。 評估可交付成果和溝通流程對於確保質量非常重要。 第一個必須實施的“上游”溝通渠道是 Ops to Dev。
給自己打五分很容易，但尋求反饋並提供反饋是了解真實情況的方式。 當務之急是下游的每一個小步驟都必須有一個即時的上游確認。
如何建立反饋循環並不重要。 您可以邀請開發人員加入支持團隊會議，或讓網絡管理員參與每週的 sprint 計劃。 只要您的反饋到位，並且評論得到處理和處理，您的組織就會加快 DevOps 的發展速度。
車道三 - Warp 10
DevOps 快車道不適合弱者。 要進入 DevOps 快車道，您的組織必須足夠成熟。 這一切都是關於冒險和從失敗中學習，不斷嘗試，並接受重複和實踐是掌握的先決條件。 您經常會聽到 Kata 這個詞，這是有原因的。 持續的訓練和重複會導致精通，因為它使復雜的動作成為例行公事。
但是在你開始組合動作之前，你必須先掌握每一個單獨的步驟。
“適合師父的，不適合新手。 在超越結構之前，您必須了解道。”
DevOps 第三條路/快速通道包括每天分配時間進行持續試驗，不斷獎勵團隊承擔風險，以及將故障引入系統以提高彈性。
為了確保您的組織在實施這些措施時不會崩潰，您必須在所有團隊之間創建頻繁的反饋循環，同時確保所有瓶頸都清晰且系統流程不中斷。
實施這些措施可以讓您的組織時刻保持警惕，並能夠快速有效地應對挑戰。
摘要 - DevOps 組織清單
這是一個清單，您可以使用它來驗證DevOps 是如何啟用您的 IT 組織的。 請隨時對文章發表評論並添加您自己的觀點。
- 開發團隊和運營團隊之間沒有隔牆。 兩者都是同一過程的一部分
- 從一個團隊發送到另一個團隊的工作始終經過驗證且質量一流
- 沒有“堆砌”的工作，所有的瓶頸都處理好了
- 開發團隊沒有將運營時間用於其活動，因為部署和維護是同一時間框的一部分
- 開發團隊不會在周五下午 5 點交付部署代碼，讓運營部門在周末清理工作
- 開發環境是標準化的，操作可以很容易地複制和擴展它們到生產中
- 開發團隊可以在他們認為合適的時候交付新版本，並且操作可以輕鬆地將它們部署到生產中
- 所有團隊之間都有清晰的溝通渠道
- 所有團隊成員都有時間進行實驗並致力於改進系統
- 定期在系統中引入（或模擬）和處理缺陷。 從每個實驗中吸取的經驗教訓都被記錄下來並與所有相關人員分享。 事件處理是例行公事，主要以已知方式處理
結論
使用 Chef、Docker、Ansible、Packer、Troposphere、Consul、Jenkins、SonarQube、AWS 等現代DevOps 工具並不意味著您正在應用 DevOps 原則。 DevOps 是一種思維方式。 我們都是同一個過程的一部分，我們共享相同的時間並共同創造價值。 參與軟件交付過程的每個人都可以加快或減慢整個系統的速度。 在開發過程中創建的錯誤可能會導致系統崩潰，以及錯誤的防火牆配置。
所有人都是 DevOps 的一部分，一旦您的組織了解這一點，幫助您管理它的工具和技術堆棧就會神奇地出現。