第三次會議於7月XNUMX日舉行 由莫斯科 DevOps 社群在 Mail.ru Cloud Solutions 的支持下舉辦。除了來自領先的 DevOps 從業者的演講之外，參與者還可以參加簡短的激勵人心的閃電演講、研討會和在開放空間進行的交流。
我們從六次演講中收集了重要見解，並採訪了幾位演講者，以了解更多演講之外的內容。
裡面：
- Baruch Sadogursky，JFrog：“讓軟體像液體一樣從供應商流向用戶”
- Southbridge 的 Pavel Selivanov：“開發和營運有一個共同的任務——製造出能用的產品”
- X5 零售集團 Vladimir Utratenko：“企業中的 DevOps 是一種無痛無火的開發”
- Sergey Puzyrev，Facebook：“生產工程師關心的是整個服務：讓用戶和開發者都感覺良好”
- AMBOSS 的 Mikhail Chinkov：“一個部門不能走 DevOps 路線；整個公司都必須走這條路”
- 俄羅斯銀行 DevOps 愛好者：“在血腥企業中實施 DevOps 的 1000 天”
1. Baruch Sadogursky，JFrog：“讓軟體像液體一樣從供應商流向用戶”
軟體更新失敗每小時都會發生一次，而且每個人都會發生。這裡只講一個令人恐懼的故事：更新失敗後，Knight Capital 在一小時內損失了 440 億美元。
Baruch 談到了持續更新的 DevOps 模式，這將有助於避免故障和用戶厭惡：
本地復原 — 在您的裝置上保留軟體的先前版本，以便在必要時回滾。當情況變得非常糟糕以致您無法透過無線方式發送補丁時，這將保護您。
無線更新 - 連續的更好。否則，就會像捷豹開發商的情況一樣：由於煞車系統存在無法透過無線方式更新的漏洞，他們不得不召回銷售的汽車。這是痛苦的並且昂貴的。
持續更新 - 一旦有新功能推出，就持續更新軟體。當更新很少時，功能會被分組；非關鍵更新可以等待關鍵更新。就像特斯拉一樣，原本應該修復隨機減速問題的更新卻在等待西洋棋遊戲的更新。
自動部署 - 用機器代替人，因為人類不擅長執行日常任務。
頻繁更新 - 幫助養成習慣並擺脫恐懼。罕見的更新變成了緊急事件。
了解設備狀態 - 測試更新，而不是從頭開始安裝。這很重要，因為更新可能會根據裝置的狀態而表現不同。
金絲雀發布 - 向少數用戶推出更新並觀察。一旦發生問題，這可以減少損失。
持續更新 — 讓客戶只注意到新功能，而不會在推出更新時數週內無法獲得服務。
我們與 Barukh Sadogursky 討論了俄羅斯和西方 IT 對 DevOps 的看法有何不同，雲端是否很快就會為我們做所有事情，以及所有軟體服務是否都會納入 aaS 方案 - 觀看採訪：
2. Southbridge 的 Pavel Selivanov：“開發和運營有一個共同的任務——製造出能用的產品”
實施 Kubernetes 不會幫助您實現 DevOps，相反，它可能會破壞一切。帕維爾解釋了為什麼科技（即使是最酷的技術）無法解決你所有的問題：
專案複雜度已超越程式碼。以前，有一個複雜的應用程式：專案內部的互動和複雜的開發，但結構簡單——管理員部署它，一切正常。我們轉向微服務：每個服務都是一個簡單的應用程序，透過標準協定進行通訊和快速開發，但專案結構變得更加複雜。採用微服務架構的專案的複雜性並沒有消失——它已經超越了程式碼。現在有一位 DevOps 工程師負責此事。
開發人員不希望在實施 DevOps 後發生改變。因此，Kubernetes 工作流程仍然看起來像是將任務從 Dev 扔到 Ops 的牆上，只是不再是一個隱喻——Git 成為了那堵牆。開發人員將程式碼放在那裡並像以前一樣工作，管理員擁有 Kubernetes、CI/CD 和其他一切。
然而，開發人員需要接受這些變化。。當開發人員不知道管理員在做什麼，而管理員也不知道開發人員在做什麼時，就會產生問題。
如果對於開發人員來說什麼都沒有改變，他們就沒有意識到應用程式的運作是他們的責任——各種技術技巧都將不起作用。
隨著 DevOps 和 Kubernetes 的出現，開發中許多事情將會改變。開發人員必須精通操作，反之亦然。這些專家都有各自的特定技能，但他們必須了解彼此的工作。在實施 Kubernetes 之前，Dev 和 Ops 需要成為朋友，否則你將破壞你所擁有的一切。
Pavel Selivanov 談到了 Kubernetes 在 5 年後將發生什麼，以及現代新創公司應該基於什麼構建技術堆疊——觀看採訪：
3. X5 零售集團 Vladimir Utratenko：“企業中的 DevOps 是一種無痛無火的開發”
當企業意識到開發速度太慢，不符合現實，有更好的開發和更快推出的願望時，他們就會進行 DevOps 轉型。
弗拉基米爾解釋了這種情況是如何發生的，以及問題是什麼：
- 首先，公司聘請 DevOps 工程師。這是一位高級系統管理員，他致力於將發布部署到生產環境、標準化開發環境、設置基礎設施、檢測和修復各種問題、自動化流程和其他技術任務。
- 然後，一名 DevOps 工程師不再足夠，公司會聘請一個 DevOps 團隊。它是一個能力中心，可以組織不同工程師的努力並使他們專注於一個方向。
- 事實上，DevOps 工程師和 DevOps 團隊是 DevOps 轉型的反模式。由於 DevOps 涉及實務和文化，因此科技公司（SRE、生產工程）中也有 DevOps 實施。
我們該怎麼辦？聘請一個臨時的 DevOps 團隊，協助實施 DevOps 轉型、進行實務、發展開發文化和技術文化。
當一家企業加入這場遊戲並投資 DevOps 時，可能會出現以下幾種結果：一切都會在起飛時崩潰；將繼續擔任 SRE/生產工程或嵌入式操作；將轉向 BizOps，其流程基於業務指標。
Vladimir Utratenko 向我們講述了企業中的 DevOps 到底有多麼“血腥”，以及大型零售商內部是如何實施的——觀看採訪：
4. Sergey Puzyrev，Facebook：“生產工程師關心的是整個服務：讓用戶和開發者都感覺良好”
Facebook 是一家龐大的公司，擁有許多元件、伺服器、人員和資料中心。儘管規模龐大，但速度非常快——開發人員每天可以推出多次服務。 Facebook 也在快速發展，不只是用戶和伺服器的數量在增長，開發人員的數量也在增長，這使得事情變得更加複雜。
謝爾蓋解釋了 Facebook 生產工程師的職責：
- 生產工程師需要進行大量的編碼工作，並且必須具備系統知識：作業系統、檔案系統、資料庫、網路等。必須具有分散式系統和可靠性工程工作經驗，即支援產品的可靠性。它必須處於隨叫隨到狀態，也就是說，可以隨時呼叫。
- 生產工程師與軟體工程師在高級操作技能方面有所不同，但本質上是軟體工程師的亞種。軟體工程師編寫更多程式碼，並且可能具有與資料處理等相關的額外技能。在 Facebook，這樣的專家也必須隨時待命，這讓很多人感到不快。
- 公司生產工程師的需求金字塔從監控伺服器及其生命週期開始，即接收新硬體、進行設定並投入運作。下一個等級與服務等級相同：監控服務及其生命週期。然後是無縫擴展和高級監控。自動縮放在服務生命週期實現自動化後使用。最後，您需要進行一些調整，以便有效擴展並為公司節省金錢和資源。
5. AMBOSS 的 Mikhail Chinkov：“DevOps 之路不能只由一個部門走，整個公司都必須走”
Mikhail 認為 DevOps 是持續開發。您不能僅僅實施一些工具然後就止步於此。哪些問題阻礙企業走向 DevOps 以及如何執行？
對 DevOps 理解的差異。在福音派看來，典型的 DevOps 建立在以下五大支柱之上：
- 文化－注重以人為本、協作；
- 自動化－將日常任務委託給工作流程；
- 精實－專注於為使用者提供價值；
- 分享－不斷交流知識；
- 指標並在他們的幫助下獲得回饋。
公司通常只專注於自動化和向用戶提供價值。但是，用於追蹤進度的文化、知識共享和 DevOps 指標卻被推到了次要地位。
DevOps 標準化的挑戰。每個公司的產品目標都不同，無法標準化。一家公司的 DevOps 狀態取決於公司本身，但許多人不了解這一點，認為聘請 DevOps 工程師就足夠了。
為什麼我們還沒有實作 DevOps？ 有兩個關鍵問題。在企業中，組織發展緩慢，數千名員工的思想觀念難以轉變。新創公司存在知識來源不足、轉型資源配置問題。
公司 DevOps 發展階段:
- 第一是基礎設施在雲端，但除了一兩個管理員之外沒有人知道它是如何運作的；
- 二是基礎設施對所有工程師來說都是透明且可理解的，但流程並不精簡；
- 第三 - 工程師獨立啟動和修復即時服務；
- 第四，工程師自願貢獻核心基礎設施，程式碼在雲端透明，一鍵部署。
理想的設置是每個人都可以平等地訪問基礎設施，所有工程師都可以訪問產品並了解他們正在做什麼。
透過關閉所有文化和技術格式塔，公司的 DevOps 轉型將考慮來自業務和平台指標的回饋。
6. 俄羅斯銀行 DevOps 愛好者：“1000 天在血腥企業中實施 DevOps”
來自俄羅斯銀行的 Yuri Bulich、Dina Maltseva 和 Evgeniy Pankov 講述了他們如何在三年內走向 DevOps。有兩個目標：解決特定團隊的特定問題並實施集中式工具。
所取得的成果如下：
產品團隊的結果：組裝速度提高 30 倍，安裝速度提高 6 倍，整個週期節省高達 30%。我們只需按一下按鈕即可投入生產
平台團隊的結果：組裝安裝速度提高10倍，安裝數量增加87％，自動化測試覆蓋率提高46％。整合團隊不再是瓶頸
那麼如何在血腥的企業中實施 DevOps 實踐？
一、實施試點：選擇團隊、決定如何實現架構、選擇工具。我們選擇了具有開放許可的工具，這些工具可以在銀行安裝，並且具有使用它們的專業知識。俄羅斯銀行在部署 DevOps 平台的同時也部署了私有雲，這在開始時起到了幫助作用。在雲端，只需按下按鈕，15分鐘內即可獲得必要的資源；以前，這樣的過程可能需要一週時間。
在銀行和其他企業中，需要提前與資訊安全團隊制定限制措施，並找到允許實施變更的解決方案。
試點後，成功的解決方案需要擴大規模.
- 重要的是盡可能地「拉直」傳送帶，消除其中不必要的環節，確定有價值的供應商，並移除剩餘的組件。中間連結是反模式。例如，在俄羅斯銀行，許多團隊的內部發展並沒有奏效，只剩下外部發展。這導致了專門的 DevOps 團隊的創建，以促進程式碼從外部開發人員到內部開發人員的轉移。透過將外部開發整合到 CI/CD 中解決了這個問題，這樣他們不僅可以將程式碼從自己轉移到銀行，而且還要對其成功負責。
- 成熟度模型包括 DevOps 實踐元素、列出的工具，並考慮了與外部供應商合作的具體情況——這後來有助於在新團隊實施時快速減少任務積壓。
- 我們需要以軟控制和建議形式進行的治理。好的 DevOps 手冊是一組組織和工具特徵，可協助團隊正確使用平台。
- 值得立即關注文化，那麼許多變化將會更快、更容易發生。發展您的內部社區，舉辦聚會、技術研討會、培訓和有趣的活動。這樣做的結果是：人們分享實踐，了解誰做了什麼，知道該向何處求助，公司內部形成了炒作和良性競爭。
- 與那些沒有參與流程、團隊不夠成熟的人一起工作是沒有意義的，最好投資有興趣的團隊和忠誠的人。
- 所選的解決方案必須方便使用它的工程師。
- 外部發展不是阻礙；實踐也可以在那裡實施，主要的是團隊本身有這種願望。
只是多一點好處
對於 DevOps 人士來說值得一讀的書籍清單，來自 Alexander Chistyakov，vdsina.ru：
- 伊琳娜·雅庫堅科（Irina Yakutenko）「意志與自製」。
- 丹尼爾‧卡尼曼《思考，快與慢》。
- 芭芭拉·奧克利 (Barbara Oakley) 的“數字思維”。
- 馬克西姆·多羅費耶夫“絕地技巧”。
- 維克多·弗蘭克爾《追尋生命的意義》。
敬請關注
我們也喜歡 DevOps。請繼續關注劇集公告 以及@Kubernetes，以及其他Mail.ru Cloud Solutions活動，在我們的Telegram頻道：
來源： www.habr.com
