談DevOps是不是很難抓到重點？我們為您收集了生動的類比、引人注目的表達和專家的建議，即使是非專家也能幫助您明白要點。最後，紅帽員工自己的 DevOps 是紅利。
DevOps 一詞起源於 10 年前，已經從 Twitter 的話題標籤發展成為 IT 世界中一場強大的文化運動，這是一種鼓勵開發人員更快地完成工作、進行實驗和迭代的真正哲學。 DevOps 已經與數位轉型的概念密不可分。但正如 IT 術語中經常發生的那樣，在過去十年中，DevOps 獲得了許多關於自己的定義、解釋和誤解。
因此，你經常會聽到關於 DevOps 的問題，例如它和敏捷一樣嗎？或者這是某種特殊的方法論？或者它只是「協作」一詞的另一個同義詞？
DevOps 包含許多不同的概念（持續交付、持續整合、自動化等），因此提煉出重要的內容可能具有挑戰性，尤其是當您對該主題充滿熱情時。然而，無論您是想向上級傳達您的想法，還是只是向家人或朋友講述您的工作，這項技能都非常有用。因此，讓我們暫時拋開 DevOps 術語的細微差別，專注於大局。
什麼是 DevOps：6 個定義和類比
我們請專家盡可能簡單、簡短地解釋 DevOps 的本質，以便任何技術知識水平的讀者都能清楚地了解它的價值。根據這些對話的結果，我們選擇了最引人注目的類比和引人注目的表述，這將幫助您建立有關 DevOps 的故事。
1.DevOps是一種文化運動
「DevOps 是一種文化運動，雙方（軟體開發人員和IT 系統營運專家）都認識到，除非有人開始使用軟體，否則軟體不會帶來真正的好處：客戶、客戶、員工，這不是重點，”資深研究人員Eveline Oehrlich 說DevOps 研究所的分析師。 “因此，雙方共同確保軟體的快速、高品質交付。”
2. DevOps 是為開發人員賦能。
“DevOps 使開發人員能夠擁有應用程式、運行它們並從頭到尾管理交付。”
Liberty Mutual 保險公司 DevOps 平台總監 Jai Schniepp 表示：“通常，DevOps 被認為是透過建立和實施自動化流程來加速應用程式交付到生產的一種方式。” “但對我來說，這是更基本的事情。” DevOps 使開發人員能夠擁有應用程式或特定軟體，運行它們並從頭到尾管理它們的交付。 DevOps 消除了責任混亂，並指導每個參與創建自動化、開發人員驅動的基礎設施的人。”
3. DevOps 是關於創建和交付應用程式的協作。
BMC 總裁兼數位業務自動化主管 Gur Staf 表示：“簡單來說，DevOps 是一種軟體生產和交付方法，每個人都可以一起工作。”
4.DevOps是一個管道
“只有所有部件裝配在一起才可能實現輸送機組裝。”
「我會將 DevOps 比作汽車裝配線，」Gur Staff 繼續說道。 – 這個想法是提前設計和製造所有零件，以便無需單獨調整即可組裝它們。只有所有部件組裝在一起才能組裝輸送機。設計和製造引擎的人必須考慮如何將其安裝到車身或車架上。製造煞車的人必須考慮車輪等等。軟體也應該如此。
創建業務邏輯或用戶介面的開發人員必須考慮儲存客戶資訊的資料庫、保護用戶資料的安全措施，以及當服務開始為大量甚至數百萬美元的用戶受眾提供服務時，所有這些將如何運作」。
「讓人們協作並思考其他人正在做的工作部分，而不是僅僅專注於自己的任務，是需要克服的最大障礙。如果你能做到這一點，那麼你就有絕佳的數位轉型機會。」Gur Staff 補充道。
5. DevOps 是人員、流程和自動化的正確組合
DevOps Institute 執行董事 Jayne Groll 提供了一個很好的類比來解釋 DevOps。用她的話來說，「DevOps 就像一個包含三類主要成分的食譜：人員、流程和自動化。這些成分大部分可以從其他領域和來源取得：精實、敏捷、SRE、CI/CD、ITIL、領導力、文化、工具。 DevOps 的秘訣就像任何好的配方一樣，是如何獲得這些成分的正確比例和混合，以提高創建和發布應用程式的速度和效率。”
6. DevOps 是指程式設計師像一級方程式車隊一樣工作
“比賽不是從頭到尾都計劃好的，相反，是從結束到開始。”
「在談論 DevOps 計畫的期望時，我使用了 NASCAR 或一級方程式賽車隊的例子，」紅帽雲端平台行銷高級經理兼 DevOps 新聞通訊的出版商 Chris Short 說道。 – 這樣一支團隊的領導者有一個目標：在比賽結束時獲得盡可能高的位置，同時考慮到球隊可用的資源和麵臨的挑戰。在這種情況下，比賽不是從開始到結束進行計劃，而是相反，從結束到開始進行。首先，設定一個雄心勃勃的目標，然後確定實現該目標的方法。然後它們被分解為子任務並委託給團隊成員。”
「車隊在比賽前花了整整一週的時間來完善進站。他進行力量訓練和有氧運動，以在艱苦的比賽日保持體形。練習共同努力解決比賽中可能出現的任何問題。同樣，開發團隊應該培養經常發布新版本的技能。如果您擁有此類技能和運作良好的安全系統，那麼新版本投入生產的情況也會更頻繁。在這種世界觀中，速度的提高意味著安全性的提高。」肖特說。
“這不是做‘正確的事’，”肖特補充道，“而是盡可能多地消除阻礙實現預期結果的因素。根據您即時收到的回饋進行協作和適應。為異常情況做好準備，並努力提高質量，盡量減少其對實現目標的影響。這就是 DevOps 世界中等待著我們的東西。”
如何擴展 DevOps：專家的 10 個技巧
只是 DevOps 和大眾 DevOps 是完全不同的東西。我們將告訴您如何克服從第一個到第二個過程中的障礙。
對於許多組織來說，DevOps 之旅的開始是輕鬆愉快的。充滿熱情的小團隊被創建，舊流程被新流程取代，第一個成功很快就會到來。
唉，這只是一種虛假的浮華，一種進步的幻覺，北高地諮詢公司董事總經理兼數位主管 Ben Grinnell 表示。早期的勝利當然令人鼓舞，但它們無助於實現在整個組織中廣泛採用 DevOps 的最終目標。
不難看出，其結果是一種「我們」和「他們」之間的分裂文化。
「通常，組織啟動這些開創性計畫時，認為它們將為主流 DevOps 鋪平道路，而不考慮其他人是否能夠或願意遵循這條道路，」Ben Grinnell 解釋道。 – 實施此類專案的團隊通常是從自信的「瓦蘭吉人」中招募的，他們已經在其他地方做過類似的事情，但對您的組織來說是新手。同時，他們被鼓勵打破和破壞對其他人仍然具有約束力的規則。很容易看出，結果是「我們」和「他們」的文化抑制了知識和技能的轉移。
「這種文化問題只是 DevOps 難以擴展的原因之一。 DevOps 團隊面臨越來越多的技術挑戰，這是快速成長的 IT 優先公司所特有的。」Scalyr 創辦人兼董事長 Steve Newman 表示。
「在現代世界，只要有需求，服務就會改變。不斷實現和實施新功能固然很棒，但協調這一過程並消除出現的問題是一件真正令人頭疼的事情，Steve Newman 補充道。 – 在快速發展的組織中，跨職能團隊的工程師努力維持對變化及其產生的依賴級聯效應的可見性。此外，當工程師被剝奪這個機會時，他們會感到不高興，因此，他們更難理解所出現問題的本質。”
如何克服上述挑戰並在大型組織中大規模採用 DevOps？專家敦促您保持耐心，即使您的最終目標是加快軟體開發週期和業務流程。
1. 請記住，文化變革需要時間。
DevOps 研究所執行董事 Jayne Groll： 「在我看來，DevOps 的擴展應該像敏捷開發一樣增量和迭代（並且同樣涉及文化）。敏捷和 DevOps 強調小型團隊。但隨著這些團隊數量的增加和整合，我們最終會有更多的人採用新的工作方式，從而發生巨大的文化轉型。”
2.花足夠的時間規劃與選擇平台
Perfecto 首席技術佈道師 Eran Kinsbruner： 「為了擴展工作，DevOps 團隊必須先學會結合傳統流程、工具和技能，然後慢慢培育和穩定 DevOps 的每個單獨階段。這一切都從仔細規劃用戶故事和價值流開始，然後使用基於主幹的開發或其他最適合分支和合併程式碼的方法編寫軟體和版本控制。”
「然後是整合和測試階段，其中已經需要可擴展的自動化平台。對於 DevOps 團隊來說，選擇適合他們的技能水平和專案最終目標的正確平台非常重要。
下一階段是部署到生產，這應該使用編排工具和容器完全自動化。在 DevOps 的各個階段（生產模擬器、QA 環境和實際生產環境）都擁有虛擬化環境非常重要，並且始終僅使用最新數據進行測試以獲得相關結論。分析必須是智能的，能夠處理大數據並提供快速且可操作的反饋。”
3. 消除責任感中的愧疚感。
戈登‧哈夫 (Gordon Haff)，紅帽佈道者： 「創建一個允許和鼓勵實驗的系統和氛圍可以避免敏捷軟體開發中所謂的成功失敗。這並不意味著沒有其他人對失敗負責。事實上，確定責任人變得更加容易，因為「負責」不再意味著「造成事故」。即責任的本質發生了質的變化。有四個因素變得至關重要：顛覆的程度、方法、生產流程和激勵措施。” （您可以在 Gordon Huff 的文章「DevOps 課程：健康實驗的 4 個方面」中閱讀有關這些因素的更多資訊。）
4. 掃清前進道路
North Highland 顧問公司董事總經理兼數位主管 Ben Grinnell： 「為了實現規模化，我建議與開創性計畫一起啟動『道路清理』計畫。該計劃的目標是清理 DevOps 先驅者留下的垃圾，例如過時的規則之類的東西，以便前進的道路保持清晰。”
「透過廣泛慶祝新工作方式的成功，透過超越先鋒群體的溝通，為人們提供組織支持和動力。指導參與下一波 DevOps 計畫並對首次使用 DevOps 感到緊張的人員。請記住，這些人與先驅者非常不同。”
5.工具民主化
Scalyr 創辦人兼董事長 Steve Newman： 「工具不應該對人們隱藏，而且對於任何願意投入時間的人來說，它們應該相對容易學習。如果查詢日誌的能力僅限於「經過認證」使用某個工具的三個人，那麼即使您擁有非常大的運算環境，您始終最多只有三個人可以處理該問題。換句話說，這裡存在一個瓶頸，可能會導致嚴重的（業務）後果。”
6.為團隊合作創造理想的條件
ITV 通用平台負責人 Tom Clark： 「你可以做任何事情，但不能同時做所有事情。因此，設定大目標，從小事做起，並快速迭代地前進。隨著時間的推移，您將獲得完成任務的聲譽，因此其他人也會想使用您的方法。並且不用擔心建立一支高效率的團隊。相反，為人們提供理想的工作條件，效率就會隨之而來。”
7. 不要忘記康威定律和看板
CollabNetVersionOne 軟體交付與 DevOps 策略總監 Logan Daigle： 「了解康威定律的後果很重要。用我鬆散的話說，這條法律規定，我們創建的產品和我們用於創建產品的流程（包括 DevOps）的結構與我們的組織相同。”
「如果組織中有很多孤島，並且在規劃、建置和發佈軟體時控制權多次易手，那麼擴充的效果將為零或短暫。如果一個組織圍繞著以市場為重點的產品建立跨職能團隊，那麼成功的機會就會大大增加。”
「擴充的另一個重要面向是在看板板上顯示所有正在進行的工作（WIP、workinprogress）。當一個組織有一個讓人們可以看到這些東西的地方時，它會極大地鼓勵協作，這對擴展有積極的影響。”
8.尋找舊疤痕
Manuel Pais，DevOps 顧問和 Team Topologies 的合著者： 「將 DevOps 實踐超越 Dev 和 Ops 本身並嘗試將其應用到其他功能並不是最佳方法。這肯定會產生一些影響（例如，透過自動化手動控制），但如果我們從了解交付和反饋流程開始，可以取得更多成果。”
「如果組織的 IT 系統中存在舊傷痕——由於過去的事件而實施的程序和管理機制，但已經失去了相關性（由於產品、技術或流程的變化）——那麼它們肯定需要被移除或平滑化，而不是自動化低效或不必要的流程。”
9. 不要滋生 DevOps 選項
Eggplant 營運總監 Anthony Edwards： 「DevOps 是一個非常模糊的術語，因此每個團隊最終都會有自己的 DevOps 版本。當一個組織突然擁有 20 種無法好好相處的 DevOps 時，沒有什麼比這更糟糕的了。三個開發團隊不可能在開發和產品管理之間擁有自己的特殊介面。當轉移到生產模擬器時，產品也不應該對處理回饋有自己獨特的期望。否則，你將永遠無法擴展 DevOps。”
10.宣揚DevOps的商業價值
Scalyr 創辦人兼董事長 Steve Newman： 「努力認識 DevOps 的價值。學習並隨意談論您所做的事情的好處。 DevOps 可以節省大量時間和金錢（想想看：更少的停機時間，更短的平均恢復時間），DevOps 團隊必須不懈地強調（並宣傳）這些舉措對業務成功的重要性。這樣你就可以擴大 DevOps 的追隨者圈子並增加 DevOps 在組織中的影響力。”
BONUS
上 我們自己的 DevOps 將於 13 月 XNUMX 日到來——是的，紅帽作為軟體製造商，擁有自己的 DevOps 團隊和實踐。
我們的工程師 Mark Birger 為整個組織的其他團隊開發內部自動化服務，他將以純俄語講述他自己的故事 - 紅帽 DevOps 團隊如何將應用程式從 Ansible 管理的 Hat Virtualization 虛擬環境遷移到成熟的容器格式OpenShift平台。
但這還不是全部：
一旦組織將工作負載轉移到容器中，傳統的應用程式監控方法可能無法運作。在第二次演講中，我們將解釋改變日誌方式的動機，並展示引導我們採用現代日誌記錄和監控方法的道路的延續。
來源： www.habr.com