DevOps とカオス: 分散型世界におけるソフトウェア配信

OTomato Software の創設者兼ディレクターであり、イスラエル初の DevOps 認定資格の創設者および講師の XNUMX 人であるアントン・ワイス氏は、昨年の講演会で講演しました。 DevOpsDays モスクワ カオス理論とカオス エンジニアリングの主な原理について説明し、将来の理想的な DevOps 組織がどのように機能するかについても説明しました。

レポートのテキスト版をご用意しました。

おはようございます！

モスクワでの DevOpsDays は 2018 年連続で、私がこのステージに立つのは今回が XNUMX 回目で、皆さんの多くはこの会場に来るのが XNUMX 回目です。 それはどういう意味ですか？ これは、ロシアにおける DevOps 運動が成長し、拡大していることを意味します。そして最も重要なことは、XNUMX 年に DevOps とは何かについて議論する時期が来たことを意味します。

2018 年に DevOps がすでに職業になっていると思う人は手を挙げてください。 そのようなものがあります。 この部屋に、職務内容に「DevOps エンジニア」と記載されている DevOps エンジニアはいますか? この部屋に DevOps マネージャーはいますか? そのようなはありません。 DevOpsアーキテクト? また、いいえ。 足りない。 自分が DevOps エンジニアであると誰も言っていないというのは本当ですか?

ということは、ほとんどの人がこれはアンチパターンだと思いますか? そんな職業は存在してはいけないのでしょうか？ 私たちは何を考えても構いませんが、私たちが考えている間も、業界は DevOps のラッパの音に合わせて粛々と前進しています。

DevDevOps という新しいトピックについて聞いたことがある人はいるでしょうか? これは、開発者と DevOps 間の効果的なコラボレーションを可能にする新しいテクニックです。 そして、それほど新しいものではありません。 Twitter から判断すると、彼らはすでに 4 年前にこのことについて話し始めていました。 そして現在に至るまで、これに対する関心はますます高まっており、つまり問題があります。 問題を解決する必要があります。

私たちはクリエイティブな人間ですが、ただ安心しているだけではありません。 私たちは、「DevOps という言葉は包括的な言葉ではなく、あらゆる種類の興味深い要素がまだ欠けている」と言います。 そして私たちは秘密研究所に行き、DevTestOps、GitOps、DevSecOps、BizDevOps、ProdOps などの興味深い突然変異を生成し始めます。

ロジックは鉄壁ですよね？ 配信システムは機能しておらず、システムは不安定でユーザーは不満を抱いており、ソフトウェアを予定通りに展開する時間がなく、予算に収まりません。 これらすべてをどうやって解決するのでしょうか？ 新しい言葉を考えてみましょう！ 「Ops」で終了し、問題は解決されます。

そこで私はこのアプローチを「大丈夫、問題は解決した」と呼んでいます。

なぜこのようなことを思いついたのかを思い出してみると、これらすべては背景に消えていきます。 私たちは、ソフトウェア配信とこのプロセスにおける私たち自身の作業を、できるだけ妨げられず、苦痛なく、効率的に、そして最も重要なことに楽しいものにするために、この DevOps のすべてを思いつきました。

DevOps は苦痛から生まれました。 そして私たちは苦しみにうんざりしています。 そして、これらすべてを実現するために、私たちは効果的なコラボレーション、フローの実践、そして最も重要なシステム思考といった常緑の実践に依存しています。これがなければ、DevOps は機能しないからです。

システムとは

すでにシステム思考について話している場合は、システムとは何かを思い出してください。

あなたが革命的なハッカーであれば、あなたにとってシステムは明らかに悪です。 それはあなたを覆い尽くし、やりたくないことを強制する雲です。

システム思考の観点から見ると、システムは部分から構成される全体です。 この意味で、私たち一人ひとりはシステムです。 私たちが働いている組織はシステムです。 そして、あなたと私が構築しているものはシステムと呼ばれます。

これらすべては XNUMX つの大きな社会技術システムの一部です。 そして、この社会技術システムがどのように連携して機能するかを理解した場合にのみ、この問題に関して何かを真に最適化することができるようになります。

システム思考の観点から見ると、システムにはさまざまな興味深い特性があります。 まず、パーツで構成されているため、その動作はパーツの動作に依存します。 さらに、そのすべての部分も相互依存しています。 システムに含まれる部品が増えるほど、その動作を理解したり予測したりすることが難しくなることがわかりました。

行動の観点から見ると、もう一つ興味深い事実があります。 システムは、その個々の部分では実行できないことを実行できます。

ラッセル・アコフ博士 (システム思考の創始者の一人) が言ったように、これは思考実験で非常に簡単に証明できます。 たとえば、部屋の中でコードの書き方を知っている人は誰でしょうか? 人手がたくさんありますが、これは私たちの職業の主な要件の XNUMX つであるため、これは正常なことです。 あなたは書き方を知っていますが、あなたの手はあなたとは別にコードを書くことができますか? 「コードを書いているのは私の手ではない、コードを書いているのは私の脳だ」と言う人もいます。 あなたの脳はあなたとは別にコードを書くことができますか? まあ、おそらくそうではありません。

脳は驚くべき機械であり、脳がどのように機能するのかは 10% もわかっていませんが、私たちの体であるシステムから切り離して機能することはできません。 これは簡単に証明できます。頭蓋骨を開け、脳を取り出し、コンピュータの前に置き、簡単なことを書いてみてください。 たとえば、Python の「Hello, world」。

システムが、そのどの部分も単独では実行できないことを実行できる場合、これは、システムの動作がその部分の動作によって決定されないことを意味します。 では、それは何によって決まるのでしょうか？ それはこれらの部分間の相互作用によって決まります。 したがって、部品の数が増えれば増えるほど、相互作用が複雑になり、システムの動作を理解して予測することが難しくなります。 そして、これがそのようなシステムを混乱に陥らせます。システムのどの部分でも、たとえ最も些細な目に見えない変化であっても、完全に予測できない結果を引き起こす可能性があるからです。

初期条件に対するこの敏感さは、アメリカの気象学者エド・ローレンツによって最初に発見され、研究されました。 その後、それは「バタフライ効果」と呼ばれ、「カオス理論」と呼ばれる科学思想の発展につながりました。 この理論は、20 世紀の科学における大きなパラダイムシフトの XNUMX つになりました。

カオス理論

カオスを研究する人は自分自身をカオス学者と呼びます。

実際、このレポートを作成した理由は、複雑な分散システムや大規模な国際機関で働いているうちに、ある時点で、これが自分の気持ちだと気づいたからです。 私はカオス学者です。 これは基本的に、「ここで何が起こっているのか理解できず、どうすればよいのかわかりません」ということを伝える賢い方法です。

皆さんもこのようによく感じることが多いと思いますので、あなたもカオスロジストです。 カオスロジストのギルドにあなたを招待します。 親愛なるカオス学者の皆さん、私が研究するシステムは「複雑適応システム」と呼ばれます。

適応力とは何ですか？ 適応性とは、そのような適応システム内の各部分の個別および集合的な動作が、システム内のイベントまたはマイクロイベントの連鎖に応答して変化し、自己組織化することを意味します。 つまり、システムは自己組織化を通じて変化に適応します。 そして、この自己組織化能力は、自由な自律エージェントの自発的で完全に分散化された協力に基づいています。

このようなシステムのもう XNUMX つの興味深い特性は、自由に拡張可能であることです。 カオス学者兼エンジニアとして、私たちが間違いなく興味を持っているものは何でしょう。 では、複雑なシステムの動作がその部分の相互作用によって決定されると言ったら、私たちは何に興味を持たなければならないのでしょうか? 交流。

さらに興味深い発見が XNUMX つあります。


まず、複雑なシステムは、その部分を単純化することによって単純化することはできないことを理解しています。 第 XNUMX に、複雑なシステムを単純化する唯一の方法は、その部分間の相互作用を単純化することです。

どのように交流するのでしょうか？ あなたも私も、人間社会という大きな情報システムの一員です。 私たちは共通言語を持っていれば、それを見つければ、それを通じて対話します。

しかし、言語自体は複雑な適応システムです。 したがって、より効率的かつ簡単に対話するには、何らかのプロトコルを作成する必要があります。 つまり、私たちの間の情報交換をよりシンプルに、より予測可能に、より理解しやすくする一連のシンボルとアクションです。

私が言いたいのは、複雑化、適応性、分散化、混乱への傾向はあらゆるものに見られるということです。 そして、あなたと私が構築しているシステム、そして私たちがその一部であるシステムでも。

根拠がないわけではないので、私たちが作成したシステムがどのように変化しているかを見てみましょう。

この言葉を待っていたんですね、分かりました。 私たちは DevOps カンファレンスに出席していますが、今日この言葉は約 XNUMX 万回聞かれ、夜になると夢に見るでしょう。

マイクロサービスは、DevOps 実践への反応として登場した最初のソフトウェア アーキテクチャであり、システムの柔軟性と拡張性を高め、継続的デリバリーを保証するように設計されています。 彼女はどうやってこれを行うのでしょうか？ サービスの量を減らし、これらのサービスが処理する問題の範囲を減らし、配信時間を短縮します。 つまり、システムの部品を削減および簡素化し、その数を増やすと、それに応じてこれらの部品間の相互作用の複雑さが常に増加します。つまり、解決しなければならない新しい問題が発生します。

マイクロサービスは終わりではありません。サーバーレスが到来しているため、マイクロサービスは一般的にすでに昨日のことになっています。 すべてのサーバーが焼失し、サーバーもオペレーティング システムもなくなり、純粋な実行可能コードだけが残されました。 設定は個別に行われ、状態も個別に行われ、すべてがイベントによって制御されます。 美しさ、清潔さ、静寂、何も起こらず、何も起こらず、完全な秩序。

複雑さはどこにあるのでしょうか? もちろん、難しいのは相互作用にあります。 XNUMX つの関数だけでどれだけのことができるでしょうか? 他の機能とどのように連携するのでしょうか? メッセージキュー、データベース、バランサー。 障害が発生したときにイベントを再作成するにはどうすればよいですか? 質問はたくさんありますが、答えはほとんどありません。

マイクロサービスとサーバーレスは、私たちオタクの流行に敏感な人々がクラウドネイティブと呼ぶものです。 すべてはクラウドに関するものです。 しかし、クラウドは本質的にスケーラビリティに限界があります。 私たちはそれを分散システムとして考えることに慣れています。 実際、クラウドプロバイダーのサーバーはどこにあるのでしょうか? データセンター内。 つまり、ここではある種の集中型で非常に限定された分散型モデルが存在します。

今日、私たちは、モノのインターネットがもはや単なる大げさな言葉ではなく、控えめな予測によれば、今後 XNUMX ～ XNUMX 年の間に数十億台のデバイスがインターネットに接続されることを待っていることを理解しています。 クラウドに統合され、クラウドからアップロードされる膨大な量の有益なデータと役に立たないデータ。

クラウドは長くは続かないので、エッジ コンピューティングと呼ばれるものについての話題が増えています。 あるいは、「フォグ コンピューティング」という素晴らしい定義も好きです。 ロマンチシズムとミステリーの神秘性に包まれています。

フォグコンピューティング。 重要なのは、雲は水、蒸気、氷、石の集中した塊であるということです。 そして霧は、大気中に私たちの周りに散らばる水滴です。

霧のパラダイムでは、ほとんどの仕事はこれらの液滴によって完全に自律的に、または他の液滴と協力して行われます。 そして、彼らは本当に切羽詰ったときにのみクラウドに頼ります。

つまり、やはり分散化、自律性です。そしてもちろん、ブロックチェーンに触れずに分散化について語ることはできないため、これらすべてがどこへ向かうのかをすでに理解している人も多いでしょう。

と信じている人たちがいて、彼らは暗号通貨に投資している人たちです。 たとえば私のように、信じていても恐れている人もいます。 そして信じない人もいます。 ここでは別の方法で扱うことができます。 テクノロジーがあり、新しい未知の事柄があり、問題があります。 他の新しいテクノロジーと同様に、答えよりも多くの疑問が生じます。

ブロックチェーンに関する誇大宣伝は理解できます。 ゴールドラッシュはさておき、テクノロジー自体は、より多くの自由、より多くの自律性、分散された世界的信頼といった、より明るい未来への驚くべき約束を秘めています。 欲しくないものは何ですか？

したがって、世界中でますます多くのエンジニアが分散型アプリケーションの開発を始めています。 そしてこれは、単に「ああ、ブロックチェーンは不十分に実装された分散データベースにすぎない」というだけでは無視できない力です。 あるいは、懐疑論者がよく言うように、「ブロックチェーンには実際の用途はない」。 考えてみれば、150 年前も電気について同じことを言っていました。 そして、彼らはある意味では正しかったのです。なぜなら、今日電気によって可能になったことは、19 世紀には決して不可能だったからです。

ところで、画面に何のロゴがあるか誰にも分かりません。 これがハイパーレジャーです。 これは Linux Foundation の後援の下で開発されているプロジェクトであり、一連のブロックチェーン テクノロジが含まれています。 これはまさに私たちのオープンソース コミュニティの強みです。

カオスエンジニアリング

したがって、私たちが開発しているシステムは、ますます複雑になり、ますます混沌とし、ますます適応力が増しています。 Netflix はマイクロサービス システムのパイオニアです。 彼らはこれを最初に理解した一人であり、シミアン アーミーと呼ばれる一連のツールを開発しました。その中で最も有名なものは次のとおりです。 カオスモンキー。 彼は、として知られるようになったものを定義しました 「カオスエンジニアリングの原理」.

ちなみに、レポートの作成過程で、このテキストをロシア語に翻訳しました。 リンカ、読んで、コメントして、叱ってください。

カオス エンジニアリングの原理を簡単に言うと、次のようになります。 複雑な分散システムは本質的に予測不可能であり、本質的にバグが多いものです。 エラーは避けられません。つまり、これらのエラーを受け入れ、まったく異なる方法でこれらのシステムを操作する必要があります。

私たち自身も、これと同じ適応性、まさに自己組織化能力、生存能力についてシステムをテストするために、実稼働システムにこれらのエラーを導入しようと試みなければなりません。

そしてそれがすべてを変えるのです。 システムを本番環境にどのように立ち上げるかだけでなく、システムをどのように開発し、どのようにテストするかについても同様です。 コードが安定化またはフリーズするプロセスはなく、逆に不安定化のプロセスが継続的に存在します。 私たちはシステムを破壊し、システムが存続し続けるのを見届けようとしています。

分散システム統合プロトコル

したがって、これには何らかの方法でシステムを変更する必要があります。 より安定させるためには、部品間の相互作用のための新しいプロトコルが必要です。 これらの部分が一致し、ある種の自己組織化が行われるようにします。 そして、あらゆる種類の新しいツールや新しいプロトコルが誕生し、私はそれを「分散システムの相互作用のためのプロトコル」と呼んでいます。

私は何について話しているのでしょうか？ まず、プロジェクト オープントレーシング。 複雑な分散システムをデバッグするために絶対に不可欠なツールである、一般的な分散追跡プロトコルを作成しようとする人もいます。

さらに - ポリシーエージェントを開く。 システムに何が起こるかを予測することはできない、つまり、その可観測性、可観測性を高める必要があると私たちは言います。 Opentracing は、システムに可観測性を提供するツール ファミリに属しています。 しかし、システムが期待どおりに動作するかどうかを判断するには、可観測性が必要です。 期待される動作をどのように定義すればよいでしょうか? 何らかのポリシー、一連のルールを定義することによって。 Open Policy Agent プロジェクトは、アクセスからリソース割り当てに至るまでの範囲にわたって、この一連のルールを定義することに取り組んでいます。

すでに述べたように、私たちのシステムはますますイベント駆動型になっています。 サーバーレスはイベント駆動型システムの好例です。 システム間でイベントを転送して追跡するには、イベントについて話したり、イベントを相互に送信したりするための共通言語、共通プロトコルが必要です。 これがプロジェクトの名前です クラウドイベント.

私たちのシステムに絶え間なく押し寄せる変更の流れは、常にシステムを不安定にし、ソフトウェア アーティファクトの継続的な流れとなります。 この絶え間ない変更の流れを維持するには、ソフトウェア成果物とは何か、どのようにテストされ、どのような検証に合格したかについて話し合うための、ある種の共通プロトコルが必要です。 これがプロジェクトの名前です グラフェアス。 つまり、ソフトウェア アーティファクトの共通メタデータ プロトコルです。

そして最後に、システムが完全に独立し、適応性があり、自己組織化されることを望むのであれば、システムに自己識別の権利を与えなければなりません。 というプロジェクト スパイフ これはまさに彼がやっていることです。 これも Cloud Native Computing Foundation の後援によるプロジェクトです。

これらのプロジェクトはすべてまだ若いため、私たちの愛と検証が必要です。 これはすべてオープンソースであり、テストと実装が行われています。 それらはテクノロジーがどこに向かっているのかを私たちに示してくれます。

しかし、DevOps は決してテクノロジーを主目的としたものではなく、常に人々間のコラボレーションを目的としています。 したがって、私たちが開発するシステムを変えたいのであれば、私たち自身も変わらなければなりません。 実際、私たちはとにかく変化しており、選択肢はあまりありません。

素晴らしいものがあります книга 英国の作家レイチェル・ボッツマンは、人類の歴史を通じて信頼の進化について書いています。 彼女によると、原始社会では当初、信頼は局地的なもので、つまり私たちは個人的に知っている人だけを信頼していました。

それから非常に長い期間があり、同じ公的機関または国家機関に属しているという事実に基づいて、私たちが知らない人々を信頼し始めた、信頼が集中化された暗黒の時代がありました。

そして、これが現代の世界で私たちが見ているものです。信頼はますます分散化され分散化されており、それは情報の流れの自由と情報の可用性に基づいています。

考えてみれば、この信頼を可能にするこのアクセシビリティそのものが、あなたと私が実装していることなのです。 これは、古い集中型の階層型 IT 組織が機能しなくなったため、コラボレーションの方法とそのやり方の両方を変える必要があることを意味します。 彼らは死に始めます。

DevOps 組織の基礎

将来の理想的な DevOps 組織は、それぞれが自律的な個人で構成される自律的なチームで構成される分散型の適応型システムです。 これらのチームは世界中に分散しており、透明性の高い通信プロトコルを使用した非同期通信を使用して効果的に連携しています。 とても美しいですね。 とても美しい未来。

もちろん、これらは文化の変化なしには不可能です。 私たちは変革をもたらすリーダーシップ、個人の責任、内なる動機を持たなければなりません。

これは DevOps 組織の基礎です。情報の透明性、非同期通信、変革的なリーダーシップ、分散化です。

燃え尽き

私たちが属しているシステムや私たちが構築するシステムはますます混沌としており、私たち人間がこの考えに対処することは難しく、コントロールされているという幻想を放棄することは困難です。 私たちはそれらをコントロールし続けようとしますが、それが燃え尽き症候群につながることがよくあります。 これは私自身の経験から言いますが、私も火傷を負い、制作中の予期せぬ失敗によって障害を負ったこともあります。

燃え尽き症候群は、本質的に制御できないものを制御しようとしたときに発生します。 燃え尽きてしまうと、何か新しいことをしたいという欲求を失い、防御的になり、自分が持っているものを守り始めるため、すべてが意味を失います。

私がよく自分に言い聞かせたいのですが、エンジニアリングという職業は、何よりもまず創造的な職業です。 何かを創造する意欲を失ったら、私たちは灰になります、灰になります。 人々は燃え尽き、組織全体も燃え尽きます。

私の意見では、カオスの創造力だけを受け入れ、その原則に従って協力を構築することだけが、私たちの職業の良いものを失わないようにするのに役立ちます。

これが私があなたに望むことです。自分の仕事を愛し、私たちの仕事を愛してください。 この世界は情報を糧としており、私たちは光栄なことに情報を養うことができます。 それで、カオスを研究しましょう、カオス学者になりましょう、価値をもたらし、何か新しいものを創造しましょう、そうですね、私たちがすでに知っているように、問題は避けられません、そして問題が現れたとき、私たちは単に「仕方ありません！」と言うだけで問題は解決されます。

カオスモンキー以外には何がありますか？

実際、これらの楽器はどれも非常に若いものです。 同じNetflixも自社用のツールを構築した。 独自のツールを構築します。 他の人がすでに構築した他のツールを見つけようとするのではなく、カオス エンジニアリングの原則を読み、その原則に従ってください。

システムがどのように壊れるかを理解し、分解を開始して、どのように維持されるかを確認してください。 これが最初に来ます。 そしてツールを探すこともできます。 あらゆる種類のプロジェクトがあります。

コンポーネントを簡素化することでシステムを簡素化することはできないとあなたが言った瞬間がよく理解できず、すぐにコンポーネント自体を簡素化し、インタラクションを複雑にすることでシステムを簡素化するマイクロサービスに移行しました。 これらは本質的に互いに矛盾する XNUMX つの部分です。

そうです、マイクロサービスは一般に非常に物議を醸すトピックです。 実際、部品を簡素化すると柔軟性が高まります。 マイクロサービスは何を提供するのでしょうか? これらは柔軟性とスピードを与えてくれますが、確かに単純さは与えてくれません。 それらは難易度を高めます。

では、DevOps の哲学では、マイクロサービスはそれほど良いものではないのでしょうか?

どんな良いものにも裏がある。 利点は、柔軟性が向上し、より迅速に変更を加えられることですが、複雑さが増し、システム全体の脆弱性が高まります。

では、インタラクションを簡素化することと、パーツを簡素化することのどちらに重点を置くのでしょうか?

もちろん、やり取りの簡素化に重点が置かれています。なぜなら、私たちがお客様とどのように連携するかという観点からこれを見ると、まず第一に、作業の簡素化ではなく、やり取りの簡素化に注意を払う必要があるからです。私たち一人一人が別々に。 作業を簡素化するということはロボット化することを意味するからです。 ここマクドナルドでは、指示があると普通に機能します。「ここにハンバーガーを置き、ここにソースを注ぎます」というものです。 これは私たちのクリエイティブな仕事ではまったく機能しません。

あなたが言ったことはすべて、競争のない世界に住んでおり、そこにある混沌はとても優しく、この混沌の中に矛盾はなく、誰も誰も食べたり殺したりしたくないというのは本当ですか？ 競争とDevOpsはどのように対処すべきでしょうか?

まあ、それは私たちが話している競争の種類によって異なります。 それは職場内の競争でしょうか、それとも企業間の競争でしょうか?

サービスが複数の会社ではないからこそ存在するサービスの競争について。 私たちは新しいタイプの情報環境を構築しており、どの環境も競争なしでは生きていけません。 どこにでも競争は存在します。

同じNetflixですが、私たちは彼らをロールモデルとしています。 なぜ彼らはこれを思いついたのでしょうか? 競争力が必要だったからです。 この柔軟性と動きの速さはまさに競争上の要件であり、システムに混乱をもたらします。 つまり、混沌は私たちが望んで意識的に行うものではなく、世界がそれを要求するために起こるものなのです。 ただ適応する必要があります。 そして混沌、それはまさに競争の結果です。

これは、混沌とは、いわば目標の不在であることを意味するのでしょうか? それとも見たくないゴールでしょうか？ 私たちは家の中にいて、他人の目的を理解していません。 実際、競争は、私たちに明確な目標があり、次の瞬間にどこに到達するかを知っているという事実によって起こります。 私の観点からすると、これが DevOps の本質です。

質問も見てください。 私たちは皆、同じ目標を持っていると思います。それは、生き残ってやり遂げることです。
最大の喜び。 そして、どの組織の競争目標も同じです。 多くの場合、生存は競争によって行われますが、それに対してできることは何もありません。

今年のカンファレンス DevOpsDays モスクワ 7月11日にテクノポリスで開催されます。 レポートの応募はXNUMX月XNUMX日まで受け付けている。 書きます 話したいことがあれば、私たちに話してください。

参加者の登録は受付中、チケット料金は7000ルーブル。 参加しませんか！

出所： habr.com