Anton Weiss，Otomato Software 創辦人兼董事，以色列首個 DevOps 認證的發起人和講師之一，在去年的大會上發表了講話 關於混沌理論和混沌工程的主要原理，也解釋了未來理想的 DevOps 組織如何運作。
我們準備了該報告的文本版本。
早上好
連續第二年在莫斯科舉行 DevOpsDays，這是我第二次登上這個舞台，你們中的許多人也是第二次來到這個房間。 這是什麼意思？ 這意味著俄羅斯的 DevOps 運動正在成長、倍增，最重要的是，這意味著 2018 年是時候談論 DevOps 是什麼了。
認為 DevOps 在 2018 年已經成為一個職業的舉手？ 有這樣的。 房間裡是否有任何 DevOps 工程師的職位描述為「DevOps 工程師」？ 房間裡有 DevOps 經理嗎？ 不存在這樣的。 DevOps 架構師？ 也沒有。 不夠。 真的沒有人說自己是 DevOps 工程師嗎？
所以你們大多數人認為這是一種反模式？ 這樣的職業不應該存在嗎？ 我們可以想怎麼想就怎麼想，但就在我們思考的同時，業界正在DevOps的號角聲中莊嚴前進。
誰聽過一個名為 DevDevOps 的新主題？ 這是一項新技術，允許開發人員和開發人員之間進行有效的協作。 而且也不那麼新了。 從 Twitter 來看，他們四年前就已經開始討論這個問題了。 而直到現在，人們對此的興趣越來越大，那就是有一個問題。 問題需要解決。
我們是富有創造力的人，我們不只是安逸地休息。 我們說：DevOps這個字還不夠全面；它仍然缺乏各種不同的、有趣的元素。 我們走進秘密實驗室，開始產生有趣的突變：DevTestOps、GitOps、DevSecOps、BizDevOps、ProdOps。
邏輯是鐵定的吧？ 我們的交付系統無法正常運行，我們的系統不穩定，我們的用戶不滿意，我們沒有時間按時推出軟體，我們不符合預算。 我們要如何解決這一切？ 我們會想出一個新字！ 將以“Ops”結束，問題就解決了。
所以我稱這種方法為“Ops，問題就解決了。”
如果我們提醒自己為什麼會想到這一切，那麼這一切都會消失在背景中。 我們提出了整個 DevOps 的概念，以使軟體交付和我們自己在此過程中的工作盡可能不受阻礙、無痛、高效，最重要的是，盡可能令人愉快。
DevOps 是從痛苦中誕生的。 我們厭倦了苦難。 為了實現這一切，我們依賴常青實踐：有效協作、流程實踐，以及最重要的系統思維，因為沒有它，DevOps 就無法發揮作用。
系統是什麼？
如果我們已經在談論系統思維，那麼讓我們提醒自己什麼是系統。
如果你是一個革命性的駭客，那麼對你來說這個系統顯然是邪惡的。 它就像一片烏雲籠罩著你，迫使你做你不想做的事情。
從系統思維的角度來看，系統是由部分組成的整體。 從這個意義上說，我們每個人都是一個系統。 我們工作的組織是系統。 你和我正在建造的東西被稱為系統。
所有這一切都是一個龐大的社會技術系統的一部分。 只有當我們了解這個社會技術系統如何協同工作時，我們才能真正優化這件事。
從系統思維的角度來看，系統具有各種有趣的屬性。 首先，它由部件組成，這意味著它的行為取決於部件的行為。 此外，它的所有部分也是相互依賴的。 事實證明，系統的部件越多，理解或預測其行為就越困難。
從行為的角度來看，還有另一個有趣的事實。 該系統可以做一些其各個部分都無法做到的事情。
正如拉塞爾·阿科夫博士（系統思維的創始人之一）所說，透過思想實驗很容易證明這一點。 例如，房間裡誰知道如何寫程式碼？ 有很多手，這很正常，因為這是我們職業的主要要求之一。 你知道怎麼寫，但是你的手能脫離你而獨立地寫程式嗎？ 有人會說：“不是我的手寫程式碼，而是我的大腦寫程式。” 你的大腦可以與你分開寫程式嗎？ 嗯，可能不會。
大腦是一個神奇的機器，我們甚至不知道它是如何運作的 10%，但它不能脫離我們身體的系統而獨立運作。 這很容易證明：打開你的頭骨，取出你的大腦，把它放在電腦前，讓他試著寫一些簡單的東西。 例如，Python 中的「Hello, world」。
如果一個系統可以做一些其任何部分都無法單獨完成的事情，那麼這意味著它的行為不是由其部分的行為決定的。 那麼它是由什麼決定的呢？ 它是由這些部分之間的相互作用決定的。 因此，部件越多，互動越複雜，理解和預測系統的行為就越困難。 這使得這樣的系統變得混亂，因為系統任何部分的任何，甚至是最微不足道的、看不見的變化都可能導致完全不可預測的結果。
這種對初始條件的敏感度首先由美國氣象學家艾德·洛倫茲發現並研究。 隨後，它被稱為“蝴蝶效應”，並導致了一場被稱為“混沌理論”的科學思想運動的發展。 該理論成為 20 世紀科學的主要典範轉移之一。
混沌理論
研究混沌的人稱自己為混沌學家。
實際上，寫這份報告的原因是，在與複雜的分散式系統和大型國際組織合作的過程中，在某個時刻我意識到這就是我想要的人。 我是一名混沌學家。 這基本上是一種聰明的說法：“我不明白這裡發生了什麼，我不知道該怎麼辦。”
我想你們很多人也常有這樣的感覺，所以你們也是混沌學家。 我邀請你加入混沌學家協會。 親愛的混沌學家同事，你和我將研究的系統稱為「複雜自適應系統」。
什麼是適應性？ 適應性意味著這種適應性系統中各個部分的個體和集體行為會發生變化和自組織，以回應系統中的事件或微事件鏈。 也就是說，系統透過自組織來適應變化。 這種自組織能力是基於自由自主主體的自願、完全去中心化的合作。
此類系統的另一個有趣的功能是它們可以自由擴展。 身為混沌學家兼工程師，我們無疑應該對什麼感興趣。 那麼，如果我們說一個複雜系統的行為是由其各部分的相互作用決定的，那麼我們應該對什麼感興趣呢？ 相互作用。
還有兩個更有趣的發現。
首先，我們明白複雜的系統不能透過簡化其組成部分來簡化。 其次，簡化複雜系統的唯一方法是簡化其各部分之間的交互作用。
我們如何互動？ 你和我都是人類社會這個龐大資訊系統的一部分。 我們透過一種共同語言進行互動，如果我們有它，如果我們找到它的話。
但語言本身是一個複雜的適應性系統。 因此，為了更有效、更簡單地交互，我們需要創建某種協議。 也就是說，一些符號和動作的序列將使我們之間的訊息交換更簡單、更可預測、更容易理解。
我想說的是，一切事物都可以追溯到複雜性、適應性、去中心化、混亂的趨勢。 在你和我正在建構的系統中，以及在我們所屬的系統中。
並不是沒有根據的，讓我們看看我們創建的系統正在如何變化。
我明白，你在等這個詞。 我們正在參加一個 DevOps 會議，今天這個詞將會被聽到十萬次，然後我們會在晚上夢見它。
微服務是第一個針對 DevOps 實踐而出現的軟體架構，旨在使我們的系統更加靈活、更具可擴展性，並確保持續交付。 她是怎麼做到的？ 透過減少服務量、縮小這些服務處理的問題範圍、縮短交付時間。 也就是說，我們減少和簡化了系統的各個部分，增加了它們的數量，相應地，這些部分之間相互作用的複雜性必然增加，也就是說，出現了我們必須解決的新問題。
微服務並不是終結，總的來說，微服務已經是昨天的事了，因為無伺服器即將到來。 所有伺服器都被燒毀，沒有伺服器，沒有作業系統，只有純粹的可執行程式碼。 配置是獨立的，狀態是獨立的，一切都由事件控制。 美麗、乾淨、安靜，沒有事件，什麼事都沒有發生，秩序井然。
複雜性在哪裡？ 當然，困難在於互動。 一個功能單獨可以做多少事情？ 它如何與其他功能互動？ 訊息佇列、資料庫、平衡器。 發生故障時如何重新建立某些事件？ 問題很多，答案卻很少。
微服務和無伺服器就是我們這些極客潮人所說的雲端原生。 一切都與雲有關。 但雲端的可擴展性也存在固有的限制。 我們習慣於將其視為分散式系統。 事實上，雲端提供者的伺服器位於哪裡？ 在數據中心。 也就是說，我們這裡有一個集中式的、非常有限的分散式模型。
今天，我們了解到，物聯網不再只是一個大詞，即使根據適度的預測，在未來五到十年內，連接到互聯網的數十億設備正在等待著我們。 大量有用和無用的數據將合併到雲端並從雲端上傳。
雲端不會持久，因此我們越來越多地談論邊緣運算。 或者說我也喜歡「霧計算」這個精彩的定義。 它籠罩在浪漫主義和神秘主義的神秘色彩之中。
霧計算。 關鍵是雲是水、蒸氣、冰和石頭的集中團塊。 霧是散佈在我們周圍大氣中的水滴。
在霧範例中，大部分的工作都是由這些液滴完全自主或與其他液滴合作完成。 只有當他們確實感到壓力很大時，他們才會轉向雲端。
也就是說，再次去中心化、自治，當然，你們中的許多人已經了解這一切的走向，因為你不能在不提及區塊鏈的情況下談論去中心化。
有些人相信，這些人投資了加密貨幣。 有些人相信但又害怕，像我。 還有一些人不相信。 在這裡你可以區別對待。 有技術，有新的未知事物，有問題。 與任何新技術一樣，它提出的問題多於它回答的問題。
圍繞區塊鏈的炒作是可以理解的。 拋開淘金熱不談，這項技術本身就蘊含著對更光明未來的非凡承諾：更多自由、更多自主、分散式全球信任。 什麼是不想要的？
因此，全球越來越多的工程師開始開發去中心化應用程式。 這是一種不能僅僅說「啊，區塊鏈只是一個實施得很差的分散式資料庫」就可以忽視的力量。 或者正如懷疑論者喜歡說的那樣：“區塊鏈沒有真正的應用程式。” 如果你想想，150 年前他們對電力也說過同樣的話。 他們在某些方面甚至是正確的，因為今天電力所帶來的一切在 19 世紀是不可能實現的。
對了，誰知道螢幕上是什麼標誌？ 這就是超級帳本。 這是一個在 Linux 基金會的支持下開發的項目，包含一套區塊鏈技術。 這確實是我們開源社群的優勢。
混沌工程
因此，我們正在開發的系統變得越來越複雜、越來越混亂、適應性越來越強。 Netflix 是微服務系統的先驅。 他們是最早了解這一點的人之一，他們開發了一套被稱為「Simian Army」的工具，其中最著名的是 。 他定義了後來被稱為 .
順便說一句，在編寫報告的過程中，我們甚至將這篇文章翻譯成俄語，所以請訪問 、讀、評論、罵。
簡而言之，混沌工程的原理如下。 複雜的分散式系統本質上是不可預測的且本質上是有缺陷的。 錯誤是不可避免的，這意味著我們需要接受這些錯誤並以完全不同的方式使用這些系統。
我們自己必須嘗試將這些錯誤引入我們的生產系統，以便測試我們的系統是否具有相同的適應性，即自我組織和生存的能力。
這改變了一切。 不僅包括我們如何將系統投入生產，還包括我們如何開發它們、如何測試它們。 程式碼不存在穩定或凍結的過程；相反，存在持續不穩定的過程。 我們正在努力消滅這個系統並讓它繼續生存。
分散式系統整合協議
因此，這需要我們的系統做出某種改變。 為了使它們變得更加穩定，它們需要一些新的協定來實現各部分之間的交互作用。 這樣這些部分就可以達成一致並形成某種自組織。 各種新工具、新協定出現，我稱之為「分散式系統互動協定」。
我在說什麼？ 一、項目 。 有些人試圖創建一個通用的分散式追蹤協議，它是調試複雜分散式系統絕對不可或缺的工具。
更遠 - 。 我們說我們無法預測系統會發生什麼，就是我們需要增加它的可觀察性、可觀察性。 Opentracing 屬於一系列為我們的系統提供可觀察性的工具。 但我們需要可觀察性來確定係統的行為是否符合我們的預期。 我們如何定義預期行為？ 透過定義某種政策、一些規則。 開放策略代理專案致力於定義從存取到資源分配等一系列規則。
正如我們所說，我們的系統越來越由事件驅動。 無伺服器是事件驅動系統的一個很好的例子。 為了讓我們在系統之間傳輸事件並追蹤它們，我們需要一些通用語言，一些通用協定來描述我們如何談論事件以及如何將它們相互傳輸。 這是一個項目的名字 .
不斷的變化流沖刷著我們的系統，不斷地破壞系統的穩定性，這是一種連續的軟體工件流。 為了讓我們保持這種持續的變化流，我們需要某種通用協議，透過它我們可以談論什麼是軟體工件、它是如何測試的、它通過了哪些驗證。 這是一個項目的名字 。 即軟體工件的通用元資料協定。
最後，如果我們希望我們的系統完全獨立、適應性和自組織，我們必須賦予它們自我認同的權利。 專案名為 這正是他所做的。 這也是雲端原生運算基金會贊助的計畫。
所有這些項目都很年輕，它們都需要我們的愛，我們的認可。 這都是開源的，我們的測試，我們的實作。 他們向我們展示了科技的發展方向。
但 DevOps 從來都不是主要關注技術，它始終關注人與人之間的協作。 因此，如果我們希望我們開發的系統改變，那麼我們自己就必須改變。 事實上，無論如何我們都在改變；我們沒有太多選擇。
有一個美妙的 英國作家雷切爾·博茨曼 (Rachel Botsman) 在書中講述了人類歷史上信任的演變。 她說，最初，在原始社會，信任是局部的，也就是說，我們只信任那些我們親自認識的人。
然後是一個很長的時期——一個信任集中化的黑暗時期，當時我們開始信任那些我們不認識的人，因為我們屬於同一個公共或國家機構。
這就是我們在現代世界中看到的情況：信任變得越來越分散和去中心化，並且它基於資訊流動的自由和資訊的可用性。
如果你仔細想想，這種可訪問性使這種信任成為可能，這正是你和我正在實施的。 這意味著我們的協作方式和工作方式都必須改變，因為舊的集中式、分層式 IT 組織已不再有效。 它們開始死亡。
DevOps 組織基礎知識
未來理想的 DevOps 組織是一個由自治團隊組成的去中心化、自適應系統，每個團隊都由自治個人組成。 這些團隊分散在世界各地，透過非同步通訊和高度透明的通訊協定相互有效協作。 非常漂亮，不是嗎？ 一個非常美好的未來。
當然，如果沒有文化變革，這一切都是不可能的。 我們必須具備變革型領導、個人責任感、內在動力。
這是 DevOps 組織的基礎：資訊透明度、非同步通訊、變革型領導、權力下放。
燃盡
我們所屬的系統和我們所建構的系統越來越混亂，我們人類很難應付這種想法，很難放棄控制的幻想。 我們試圖繼續控制它們，這往往會導致倦怠。 我是根據我自己的經驗這麼說的，我也被燒傷過，我也因生產中不可預見的故障而癱瘓。
當我們試圖控製本質上無法控制的事情時，就會出現倦怠。 當我們精疲力盡時，一切都失去了意義，因為我們失去了做新事物的慾望，我們變得防禦性並開始捍衛我們所擁有的東西。
正如我經常提醒自己的那樣，工程職業首先是一個創造性的職業。 如果我們失去了創造東西的慾望，那麼我們就會變成灰燼，變成灰燼。 人們精疲力盡，整個組織都精疲力盡。
在我看來，只有接受混沌的創造力，只有根據其原則建立合作，才能幫助我們不失去我們職業的優點。
這就是我對你的祝福：熱愛你的工作，熱愛我們所做的事情。 這個世界以資訊為食，我們很榮幸能夠提供資訊。 因此，讓我們研究混沌，讓我們成為混沌學家，讓我們帶來價值，創造新的東西，好吧，正如我們已經發現的那樣，問題是不可避免的，當它們出現時，我們只會說「Ops！」問題就解決了。
除了混沌猴還有什麼？
事實上，所有這些樂器都非常年輕。 同一個 Netflix 為自己建立了工具。 建立您自己的工具。 閱讀混沌工程的原理並遵守這些原理，而不是試圖尋找其他人已經建立的其他工具。
嘗試了解您的系統如何崩潰，並開始將其分解，看看它們如何維持下去。 這是第一位的。 您可以尋找工具。 各種各樣的項目都有。
當你說系統不能透過簡化元件來簡化時，我不太明白，並立即轉向微服務，微服務透過簡化元件本身和複雜化互動來簡化系統。 這本質上是兩個相互矛盾的部分。
沒錯，微服務整體來說是一個非常有爭議的話題。 事實上，簡化零件可以提高靈活性。 微服務提供什麼？ 它們給了我們靈活性和速度，但它們肯定沒有為我們帶來簡單性。 它們增加了難度。
那麼，在DevOps理念中，微服務不是什麼好事呢？
任何好事都有反面。 好處是它增加了靈活性，使我們能夠更快地進行更改，但它增加了複雜性，從而增加了整個系統的脆弱性。
不過，哪個比較強調：簡化互動還是簡化部件？
當然，重點是簡化交互，因為如果我們從與您合作的角度來看，那麼首先我們需要專注於簡化交互，而不是簡化工作。我們每個人分別。 因為簡化工作意味著變成機器人。 在麥當勞，當你有指示時，它會正常工作：在這裡你把漢堡放在這裡，在這裡你把醬汁倒在上面。 這在我們的創意工作中根本不起作用。
難道你所說的一切都生活在一個沒有競爭的世界裡，而且那裡的混亂是如此仁慈，而且這混亂之中沒有任何矛盾，沒有人想吃或殺任何人？ 競賽和 DevOps 應該如何發展？
嗯，這取決於我們談論的是哪種類型的競爭。 是職場競爭還是公司之間的競爭？
關於服務存在的競爭，因為服務不是幾家公司。 我們正在創造一個新型的資訊環境，任何環境都離不開競爭。 到處都有競爭。
同樣是Netflix，我們以他們為榜樣。 他們為什麼想出這個？ 因為他們需要具有競爭力。 這種靈活性和移動速度正是非常有競爭力的要求；它為我們的系統帶來了混亂。 也就是說，混亂不是我們有意識地做的事情，因為我們想要它，它是因為世界需要它而發生的事情。 我們只需要適應。 而混亂，正是競爭的結果。
這是否意味著混亂就是缺乏目標？ 或是那些我們不想看到的目標？ 我們在家裡，不了解別人的目標。 事實上，競爭是因為我們有明確的目標，我們知道下一個時刻我們會到達哪裡。 在我看來，這就是 DevOps 的本質。
還看一下問題。 我認為我們都有相同的目標：生存並與之共存
最大的榮幸。 任何組織的競爭目標都是相同的。 生存往往是透過競爭來實現的，你對此無能為力。
今年的會議 將於 7 月 11 日在 Technopolis 舉行。 我們在 XNUMX 月 XNUMX 日之前接受報告申請。 如果您想發言，請聯絡我們。
參與者註冊現已開放，門票價格為 7000 盧布。 加入我們！
來源： www.habr.com