DevOps的定義非常複雜，所以我們每次都要重新開始討論它。 僅就哈布雷而言，就有上千篇關於該主題的出版品。 但如果您正在閱讀本文，您可能知道 DevOps 是什麼。 因為我不是。 你好我的名字是 亞歷山大·蒂托夫（@），我們只討論 DevOps，我會分享我的經驗。
我已經思考了很長一段時間如何讓我的故事變得有用，所以這裡會有很多問題——我問自己的問題和我問我們公司客戶的問題。 透過回答這些問題，理解會變得更好。 我將從我的角度告訴您為什麼需要 DevOps，從我的角度再次告訴您 DevOps 是什麼，以及如何從我的角度理解您正在再次走向 DevOps。 最後一點將透過問題進行。 透過親自回答這些問題，您可以了解您的公司是否正在向 DevOps 邁進，或者是否存在某種問題。
有一段時間，我正乘著併購浪潮。 首先，我在一家名為 Qik 的小型新創公司工作，然後它被一家規模稍大的公司 Skype 收購，然後被一家規模稍大的公司 Microsoft 收購。 那一刻，我開始看到DevOps的概念在不同規模的公司中是如何轉變的。 之後，我開始對從市場角度看待DevOps產生了興趣，我和我的同事創立了Express 42公司。六年來，我們一直沿著市場的浪潮前進。
除此之外，我是 DevOps 莫斯科社群的組織者之一，也是 2017 年 DevOps-Days 的組織者，但 2018 年我沒有組織。 Express 42 與許多公司合作。 我們在那裡發展 DevOps，看看它是如何發生的，得出結論，分析，告訴每個人我們的結論，並培訓人們進行 DevOps 實踐。 總的來說，我們正在盡最大努力增加這方面的經驗和專業知識。
為什麼選擇 DevOps
始終困擾著每個人的第一個問題是──為什麼？ 許多人認為 DevOps 只是自動化或每家公司已經擁有的類似東西。
— 我們有持續整合 - 這意味著我們已經有了 DevOps，為什麼需要所有這些東西？ 他們在國外玩得很開心，卻阻止我們工作！
社群和方法論經過 9 年的發展，已經很清楚這仍然不是行銷閃光，但仍然不完全清楚為什麼需要它。 與任何工具和流程一樣，DevOps 也有最終實現的特定目標。
這一切都是因為世界正在改變。 他放棄了企業方法，當公司直接朝著夢想前進時，正如我們聖彼得堡的經典歌曲所唱的那樣，根據特定的策略從A點到B點，並為此建立了特定的結構。
原則上，IT 中的一切都應該按照這種方法來建構。 在這裡，IT 專門用於自動化流程。
自動化不會經常改變，因為當一家公司陷入困境時，還有什麼需要改變的？ 它有效 - 不要碰它。 現在世界上的方法正在發生變化，而所謂的敏捷方法表明終點 B 並不是立即可見的。
當一家公司走過市場，與客戶合作時，它不斷地探索市場並改變終點B。而且，公司改變方向的次數越多，最終就越成功，因為它選擇了更多的市場利基市場。
我最近了解到的一家有趣的公司展示了這個策略。 One Box Shave 是一項訂購外送服務，提供盒裝刮鬍刀和刮鬍配件。 他們知道如何為不同的客戶定制他們的“盒子”。 這是透過某種軟體完成的，然後該軟體將訂單發送到生產商品的韓國工廠。
該產品被聯合利華以 1 億美元收購。 現在它與吉列競爭，搶走了美國市場相當大的消費者份額。 一盒剃鬚 說：
— 4 個刀片？ 你認真的嗎？ 為什麼您需要這個 - 它不會提高剃須品質。 特選的奶油、香水和帶有兩個刀片的高品質剃須刀比那些愚蠢的 4 個吉列刀片解決了更多的問題！ 我們很快就會達到 10 嗎？
世界就是這樣改變的。 聯合利華聲稱他們有一個很酷的 IT 系統可以讓你做到這一點。 最後看起來像是個概念 上市時間，沒有人談論過這一點。
上市時間的重點不在於我們部署的頻率。 可以經常部署，但是發布週期會很長。 如果將三個月的發布週期相互疊加，將其移動一周，則結果表明該公司似乎每週部署一次。 而從產生想法到最終實施需要3個月的時間。
上市時間是指最大限度地縮短從想法到最終實施的時間。
在這種情況下，軟體與市場相互作用。 這就是 One Box Shave 網站與客戶互動的方式。 他們沒有銷售人員——只有一個網站，訪客可以點擊並留下願望。 因此，必須不斷在網站上發布新內容並根據意願進行更新。 例如，在韓國，他們的剃鬚方式與在俄羅斯不同，他們喜歡的不是松樹的氣味，而是胡蘿蔔和香草的氣味。
由於需要快速更改網站內容，因此軟體開發發生了很大變化。 透過軟體我們必須找出客戶想要什麼。 以前我們是透過一些迂迴的方式了解到這一點的，例如透過企業管理。 然後我們設計它，將需求放入IT系統中，一切都很酷。 現在不同了 - 軟體是由參與過程的每個人設計的，包括工程師，因為透過技術規範，他們了解市場如何運作，並與業務分享他們的見解。
例如，在 Qik，我們突然了解到人們非常喜歡將聯絡人清單上傳到伺服器，他們為我們提供了一個應用程式。 最初我們沒有考慮這個問題。 在一家經典公司中，每個人都會認為這是一個錯誤，因為規範沒有說它應該很好用並且通常是在膝蓋上實現的，他們會關閉該功能並說：「沒有人需要這個，最重要的是主要功能有效。” 而科技公司將此視為一個機會，並開始據此改變軟體。
1968 年，一位有遠見的人 Melvin Conway 提出了以下想法。
創建系統的組織受到複製該組織通訊結構的設計的約束。
更詳細地說，為了生產不同類型的系統，您還必須在不同類型的公司內擁有通訊結構。 如果您的通訊結構是頂級的，那麼您將無法建立可以提供非常高的上市時間指標的系統。
讀 人們可以 。 這對於理解 DevOps 文化或哲學非常重要，因為 DevOps 中唯一從根本上改變的是團隊之間的溝通結構.
從流程的角度來看，在 DevOps 之前，所有階段：分析、開發、測試、營運都是線性的。
就 DevOps 而言，所有這些過程同時發生。
上市時間是實現這一目標的唯一方法。 對於在舊流程中工作的人來說，這看起來有點宇宙，而且一般般。
那為什麼需要 DevOps？
用於數位產品開發。 如果你的公司沒有數位產品，就不需要DevOps——它非常重要。
DevOps 克服了順序軟體生產的速度限制。 其中所有過程同時發生。
難度增加。 當 DevOps 傳播者告訴您它將讓您更輕鬆地發佈軟體時，這是無稽之談。
有了 DevOps，事情只會變得更加複雜。
在 Avito 展位的會議上，您可以看到部署 Docker 容器的感覺 - 這是一項不切實際的任務。 複雜性變得令人望而卻步；你必須同時處理許多球。
DevOps 徹底改變了公司的流程和組織 ——更準確地說，改變的不是 DevOps，而是數位產品。 來到DevOps，你還是需要徹底改變這個流程。
向專家提問
你有什麼？ 在公司工作和發展成為專家時可以問自己的問題。
您有創建數位產品的策略嗎？ 如果有的話就已經很好了。 這意味著您的公司正在轉向 DevOps。
貴公司已經在開發數位產品了嗎？ 這意味著您可以更上一層樓，做更有趣的事情——同樣是從 DevOps 的角度來看。 我只是從這個角度來說。
貴公司是數位產品領域的市場領導者之一嗎？ Spotify、Yandex、Uber 都是目前處於技術進步最高峰的公司。
問自己這些問題，如果所有答案都是“否”，那麼也許您不應該在這家公司從事 DevOps。 如果 DevOps 主題對您來說真的很有趣，也許…您應該跳槽到另一家公司？ 如果你的公司想要進入DevOps，但你對所有問題都回答“否”，那麼它就像那頭美麗的犀牛永遠不會改變。
組織
正如我所說，根據康威定律，公司的組織會改變。 我將從組織的角度開始討論阻礙 DevOps 滲透到公司內部的因素。
「井」的問題
英文單字“Silo”在這裡被翻譯成俄語“井”。 這個問題的重點在於 團隊之間沒有資訊交換。 每個團隊都深入挖掘自己的專業知識，但沒有建立通用的導航地圖。
在某些方面，這讓我想起一個剛到達莫斯科、還不知道如何導航地鐵地圖的人。 莫斯科人通常非常了解自己所在的地區，他們可以使用地鐵地圖在整個莫斯科進行導航。 當你第一次來莫斯科時，你沒有這個技能，你只是迷失了方向。
DevOps 建議度過這個迷失方向的時刻，所有部門共同努力建立一個共同的交互圖。
有兩個因素阻礙了這一點。
公司管理體系的後果。 它建立在單獨的分層“井”中。 例如，支援該系統的公司有某些 KPI。 另一方面，如果一個人發現很難超越自己的專業知識範圍並駕馭整個系統，那麼他的大腦就會成為障礙。 就是不舒服。 想像一下，您在曼谷機場 - 您不會很快找到路。 DevOps 也很難駕馭，這就是為什麼人們說你需要找到一個指南才能到達那裡。
但最重要的是，對於一個充滿 DevOps 精神、讀過 Fowler 和其他一堆書籍的工程師來說，「井」的問題表現為： 「井」不允許你做「明顯」的事情。 我們經常在莫斯科 DevOps 之後聚在一起互相交談，人們抱怨：
——我們只是想推出 CI，但結果發現管理階層不需要它。
發生這種情況正是因為 CI и 持續交付流程 正處於許多考試的邊緣。 如果不克服組織層面的「井」問題，無論你做什麼，無論多麼悲傷，你都無法前進。
公司流程中的每個參與者：後端和前端開發人員、測試、DBA、營運、網絡，都在自己的方向上挖掘，除了經理之外，沒有人有共同的地圖，經理以某種方式監視他們並使用“劃分”來管理他們並征服”的方法。
人們都在爭奪一些明星或旗幟，每個人都在挖掘自己的專長。
因此，當出現將所有這些連接在一起並建立一個共同管道的任務時，並且不再需要爭奪星星和旗幟時，問題就出現了 - 無論如何該怎麼辦？ 我們需要以某種方式達成協議，但在學校沒有人教我們如何做到這一點。 我們從學校就被教導：八年級 - 哇！ - 與七年級相比！ 這裡也是一樣。
你們公司也是這樣嗎？
要檢查這一點，您可以問自己以下問題。
團隊是否使用通用工具並為這些通用工具的變更做出貢獻？
團隊重組的頻率是多少——一個團隊的一些專家轉移到另一個團隊？ 在 DevOps 環境中，這變得很正常，因為有時一個人根本無法理解另一個專業領域在做什麼。 他調到另一個部門，在那裡工作了兩週，為自己繪製了一張與該部門的定位和互動地圖。
是否有可能成立一個變革委員會來改變現狀？ 還是需要最高管理階層的強力指導？ 我最近在 Facebook 上寫道，一家鮮為人知的銀行如何透過訂單實施工具：我們寫下訂單，實施一年，看看會發生什麼。 當然，這是漫長而悲傷的。
對管理者來說，不考慮公司的成就而獲得個人的成就有多重要？
如果你自己回答這些問題，你的公司是否有這樣的問題就會變得更清楚。
基礎設施即代碼
這個問題通過之後，第一個重要的實踐，沒有它很難在DevOps中進一步推進，就是 基礎設施即程式碼.
大多數情況下，基礎設施即代碼被認為如下：
— 讓我們在 bash 中自動化一切，用腳本覆蓋我們自己，這樣管理員就可以減少手動工作！
但事實並非如此。
基礎架構即代碼表示您以程式碼的形式描述您所使用的 IT 系統，以便不斷了解其狀態。
與其他團隊一起，以程式碼的形式創建一個每個人都可以理解並且可以導航和導航的地圖。 無論是在 Chef、Ansible、Salt 還是在 Kubernetes 中使用 YAML 文件，都沒有什麼區別。
在會議上，2GIS 的一位同事講述了他們如何為 Kubernetes 製作自己的內部東西，它描述了各個系統的結構。 為了描述 500 個系統，他們需要一個單獨的工具來產生此描述。 當有這個描述時，每個人都可以互相檢查，監控變化，如何改變它和改進它，缺少什麼。
同意，個別 bash 腳本通常不提供這種理解。 在我工作的一家公司中，甚至有一個「只寫」腳本的名稱——當腳本被寫入時，但不再可能讀取它。 我想這對你來說也很熟悉。
基礎設施即程式碼 描述基礎設施目前狀態的程式碼。 許多產品、基礎設施和服務團隊共同處理此程式碼，最重要的是，他們都需要了解此程式碼的實際運作原理。
程式碼根據最佳程式碼實踐進行維護：聯合開發、程式碼審查、XP 程式設計、測試、拉取請求、程式碼基礎設施 CI - 所有這些都是合適的並且可以使用。
程式碼成為所有工程師的通用語言。
改變程式碼中的基礎設施並不需要太多時間。 是的，基礎設施代碼也可能有技術債。 通常，團隊會在開始以一堆腳本甚至Ansible 的形式實現「基礎設施即程式碼」一年半後就會遇到這種情況，他們編寫的腳本就像義大利麵程式碼一樣，而且他們也會將bash 腳本混入其中！
這一點很重要：如果您還沒有嘗試過這些東西，請記住 Ansible 不是 bash！ 仔細閱讀文檔，研究他們寫的內容。
基礎設施即代碼是將基礎設施代碼分離到不同的層。
在我們公司，我們區分了3個基本層，非常清晰和簡單，但可能還有更多。 您可以查看您的基礎設施代碼並判斷您是否有這種情況。 如果沒有突出顯示任何圖層，那麼您需要花一些時間進行一些重構。
基層 - 這就是作業系統、備份和其他低階事物的配置方式，例如 Kubernetes 在基礎層級的部署方式。
服務水準 - 這些是您提供給開發人員的服務：日誌記錄作為服務、監控作為服務、資料庫作為服務、平衡器作為服務、佇列作為服務、持續交付作為服務 - 各個團隊提供的一系列服務可以提供發展。 這一切都需要在組態管理系統的單獨模組中進行描述。
進行應用程式的層 並描述它們將如何在前兩層之上展開。
控制問題
貴公司有通用的基礎設施儲存庫嗎？ 您是否正在管理基礎設施中的技術債？ 您是否在基礎架構儲存庫中使用開發實務？ 您的基礎設施是否分層？ 您可以查看Base-service-APP圖。 做出改變有多難？
如果您經歷過需要一天半的時間才能進行更改，這意味著您有技術債務並且需要處理它。 您剛剛在基礎設施代碼中偶然發現了技術債。 我記得很多這樣的故事，為了改變一些CCTL，你需要重寫一半的基礎設施代碼，因為創造力和自動化一切的願望導致一切都到處被腐蝕，所有的手柄都被移除了，並且有必要重構。
持續交付
讓我們比較一下借方和貸方。 首先是對基礎設施的描述，這可能非常基礎。 您不必詳細描述所有內容，但需要一些基本描述，以便您可以使用它。 否則持續交付接下來要做什麼就不清楚了。 當您接觸 DevOps 時，所有這些實踐都會同時展開，但首先要了解您擁有什麼以及如何管理它。 這正是基礎設施即程式碼的實踐。
一旦明確您擁有它以及如何管理它，您就開始弄清楚如何盡快將開發人員程式碼傳送到生產環境。 我的意思是與開發商一起 - 我們記得“井”的問題，也就是說，不是個人提出這個問題，而是一個團隊。
當我們和 瓦尼亞·葉夫圖霍維奇 看過第一本書 傑茲謙卑 和作者群體 “持續交付”2009年上映時，我們思考了很長時間如何將其標題翻譯成俄語。 他們想將其翻譯為“Constantly Deliver”，但不幸的是，它被翻譯為“Continously Delivery”。 在我看來，我們的名字裡有一些俄羅斯的東西，帶著壓力。
不斷傳遞手段
產品儲存庫中的程式碼始終可以下載到生產環境。 他可能不會洩氣，但他總是做好準備。 因此，你在寫程式時總是帶著一種難以解釋的焦慮感。 當您推出基礎設施代碼時，它經常出現。 這種焦慮感應該存在——它會觸發大腦過程，讓你以稍微不同的方式編寫程式碼。 這應該記錄在開發的規則中。
為了一致地交付，您需要一種跨基礎架構平台運行的工件格式。 如果你把不同格式的「生活垃圾」丟到一個基礎設施平台上，那麼它就會變得統一，難以維護，並且會出現技術債問題。 工件的格式需要保持一致——這也是一項集體任務：我們都需要聚在一起，開動腦筋，想出這個格式。
當工件通過交付管道時，它會不斷改進和更改以適應生產環境。 當工件沿著管道移動時，它不斷遇到一些對其不方便的事情，這與您投入生產的工件遇到的情況類似。 如果在經典開發中，這是由進行部署的系統管理員完成的，那麼在DevOps 過程中，這種情況一直在發生：這裡他們通過一些測試對其進行了測試，這裡他們將其放入Kubernetes 集群中，這或多或少是相似的到生產，然後突然他們開始負載測試。
這有點讓人想起吃豆人遊戲——這個神器經歷了某種故事。 同時，控製程式碼是否真正貫穿故事以及它是否與您的製作有某種關係也很重要。 生產中的故事可以拖到持續交付過程中：當東西掉下來時就像這樣，現在讓我們在系統內編寫這個場景。 每次程式碼也會經歷這個場景，下次就不會再遇到這個問題了。 在它到達您的客戶之前，您會更早了解到它。
不同的部署策略。 例如，您使用 AB 測試或金絲雀部署在不同客戶端上以不同方式測試程式碼，獲取有關程式碼如何運作的信息，並且比向 100 億用戶推出的時間早得多。
「持續交付」看起來像這樣。
交付過程 Dev、CI、Test、PreProd、Prod 不是一個單獨的環境，這些是您的工件所經過的具有防火總和的階段或站。
如果您有被描述為基礎服務應用程式的基礎架構程式碼，那麼它會有所幫助 不要忘記所有的腳本，並將它們寫下來作為該工件的程式碼， 推廣神器 並隨時更改它。
自測題
95%的情況下從功能描述到發佈到生產的時間不到一週？ 工件的品質是否在流程的每個階段都有提升？ 有沒有一個故事是這樣發生的呢？ 您是否使用不同的部署策略？
如果所有的答案都是肯定的，那你就太酷了！ 在評論中寫下你的答案 - 我會很高興）。
反饋
這是所有練習中最困難的。 在 DevOpsConf 會議上，Infobip 的一位同事在談到這個問題時，語氣有點困惑，因為這確實是一個非常複雜的實踐，因為你需要監控一切！
例如，很久以前，當我在 Qik 工作時，我們意識到我們需要監控一切。 我們這麼做了，現在 Zabbix 中有 150 萬個項目，這些項目受到持續監控。 嚇人了，技術總監扭了扭太陽穴：
- 夥計們，你們為什麼要用一些不明確的東西來強姦服務器？
但後來發生的一件事表明，這確實是一個非常酷的策略。
其中一項服務開始不斷崩潰。 最初，它沒有崩潰，這很有趣，程式碼沒有添加到那裡，因為它是一個基本代理，實際上沒有業務功能 - 它只是在各個服務之間發送訊息。 該服務 4 個月沒有改變，突然開始崩潰並出現「分段錯誤」錯誤。
我們很震驚，在 Zabbix 中打開圖表，結果發現一周半前，該代理人使用的 API 服務中的請求行為發生了很大變化。 接下來我們看到發送某種類型訊息的頻率發生了變化。 後來我們發現這些都是安卓客戶端。 我們問：
— 夥伴們，一週半前你們發生了什麼事？
作為回應，我們聽到了一個關於他們如何重新設計使用者介面的有趣故事。 不太可能有人會立即說他們更改了 HTTP 庫。 對於 Android 用戶端來說，這就像在浴室裡更換肥皂一樣 - 他們只是不記得了。 結果，經過 40 分鐘的交談，我們發現他們更改了 HTTP 庫，並且其預設計時也發生了變化。 這導致 API 伺服器上的流量行為發生變化，從而導致出現了導致代理內部競爭的情況，並且開始崩潰。
如果沒有深度監控，一般不可能打開這個。 如果組織仍然存在「井」的問題，當每個人互相扔錢時，這種情況可能會持續很多年。 你只需重新啟動伺服器，因為這是不可能解決問題的。 當您監視、追蹤、追蹤您擁有的所有事件，並將監視用作測試時- 編寫程式碼並立即指示如何監視它，也是以程式碼的形式（我們已經有了程式碼形式的基礎設施），一切都變得清晰起來在手掌上。 即使如此複雜的問題也很容易追蹤。
收集有關工件在交付過程的每個階段（而不是生產階段）發生的情況的所有資訊。
將監控上傳到CI，一些基本的東西已經在那裡可見了。 稍後您將在 Test、PredProd 和負載測試中看到它們。 收集各個階段的信息，不僅包括指標、統計數據，還包括日誌：應用程式如何推出、異常情況 - 收集一切。
不然的話就很難弄清楚了。 我已經說過 DevOps 更複雜。 為了應對這種複雜性，您需要進行正常的分析.
自我控制問題
您的監控和記錄開發工具適合您嗎？ 在寫程式碼的時候，你的開發者，包括你，有沒有想過如何監控？
您是否聽過客戶提出的問題？ 您是否透過監控和記錄更了解客戶端？ 透過監控和日誌記錄，您是否對系統有了更深入的了解？ 你改變系統只是因為你看到系統的趨勢正在成長並且你知道再過三週一切都會消亡嗎？
一旦有了這三個組件，您就可以考慮您的公司擁有什麼樣的基礎設施平台。
基礎設施平台
重點不在於它是每家公司都擁有的一套不同的工具。
基礎設施平台的重點是所有團隊都使用這些工具並共同開發它們。
顯然，有一個單獨的團隊負責基礎設施平台各個部分的開發。 但同時，每一位工程師都對基礎設施平台的開發、性能和推廣負有責任。 在內部層面，它成為一種通用工具.
所有團隊都開發基礎設施平台並將其視為自己的 IDE。 在 IDE 中，您可以安裝不同的插件以使一切變得又好又快，並配置熱鍵。 當你打開 Sublime、Atom 或 Visual Studio Code 時，程式碼錯誤蜂擁而至，你意識到根本無法工作，你立即感到悲傷，並跑去修復你的 IDE。
以同樣的方式對待您的基礎設施平台。 如果您了解其中存在問題，並且您無法自行修復，請留下請求。 如果有簡單的東西，你自己編輯它，發送拉取請求，人們會考慮它並添加它。 這是開發人員腦中工程工具的一種略有不同的方法。
基礎設施平台確保工件從開發到客戶端的轉移，並持續提高品質。 IP 是用生產中的程式碼中發生的一組故事進行程式設計的。 經過多年的發展，有很多這樣的故事，其中一些是獨一無二的並且只與您相關 - 它們無法通過谷歌搜索。
此時，基礎設施平台就成為您的競爭優勢，因為它內建了競爭對手工具中沒有的東西。 您的智慧財產權越深，您在上市時間上的競爭優勢就越大。 出現在這裡 供應商鎖定問題：你可以拿別人的平台，但是用別人的經驗，你不會明白它與你有多大的相關性。 是的，並不是每家公司都能建立像亞馬遜這樣的平台。 這是一條困難的線，公司的經驗與其在市場中的地位相關，而且你不能在那裡使用供應商鎖定。 這也是值得思考的重要問題。
駕駛
這是基礎架構平台的基本圖，它將幫助您在 DevOps 公司中設定所有實踐和流程。
讓我們看看它由什麼組成。
資源編排系統，它為應用程式提供CPU、記憶體、磁碟等服務。 最重要的是—— 低水準服務：監控、日誌記錄、CI/CD 引擎、工件儲存、基礎架構即係統代碼。
更高水準的服務：資料庫即服務、佇列即服務、負載平衡即服務、影像調整大小即服務、大數據工廠即服務。 最重要的是—— 向您的客戶提供不斷修改的程式碼的管道.
您將收到有關您的軟體如何為客戶端工作的信息，對其進行更改，再次提供此代碼，接收信息 - 這樣您就可以不斷開發基礎設施平台和您的軟體。
在圖中，交付管道由許多階段組成。 但這只是作為範例給出的示意圖，無需一一重複。 階段與服務交互，就好像它們是服務一樣——平台的每個磚塊都有自己的故事：如何分配資源、如何啟動應用程式、如何使用資源、如何監控和更改。
重要的是要了解平台的每個部分都承載著一個故事，並問問自己這塊磚塊承載著什麼故事，也許它應該被扔掉並用第三方服務替換。 例如，是否可以安裝 Okmeter 來代替磚塊？ 也許這些人在這方面的專業知識已經比我們成熟得多了。 但也許不是——也許我們擁有獨特的專業知識，我們需要安裝 Prometheus 並進一步開發它。
平台創建
這是一個複雜的溝通過程。 當您有了基本實踐後，您就開始在開發需求和標準的不同工程師和專家之間進行溝通，並不斷將其更改為不同的工具和方法。 我們在 DevOps 中擁有的文化在這裡很重要。
有了文化，一切就變得很簡單了—— 這是關於協作和溝通的，即渴望在共同的領域中彼此合作，渴望共同使用一種工具。 這裡沒有火箭科學——一切都很簡單、平庸。 例如我們都住門口，保持乾淨──這樣的文化水準。
你有什麼？
再說一遍，你可以問自己一些問題。
基礎設施平台是否專用？ 誰負責其發展？ 您了解您的基礎設施平台的競爭優勢嗎？
你需要不斷問自己這些問題。 如果有東西可以轉移到第三方服務，就應該轉移；如果第三方服務開始阻止你的行動，那麼你需要在自己內部建立一個系統。
那麼，DevOps...
……這是一個複雜的系統，它必須有：
- 數碼產品。
- 開發此數位產品的業務模組。
- 編寫程式碼的產品團隊。
- 持續交付實踐。
- 平台即服務。
- 基礎設施即服務。
- 基礎設施即代碼。
- DevOps 中內建的維護可靠性的單獨實踐。
- 描述這一切的回饋實踐。
您可以使用此圖表，以某種形式突出顯示您公司中已有的內容：已開發或仍需要開發。
幾週後就會結束 。 作為 RIT++ 的一部分。 參加會議，您會發現許多有關持續交付、基礎架構即程式碼和 DevOps 轉型的精彩報告。 ，最後價格截止日期為 20 月 XNUMX 日
來源： www.habr.com