DevOpsとは

DevOps の定義は非常に複雑なので、毎回それについての議論を最初からやり直す必要があります。 このトピックに関する出版物はハブレに関するものだけでも XNUMX 冊あります。 しかし、これを読んでいるなら、おそらく DevOps が何であるかを知っているでしょう。 私はそうではないからです。 こんにちは、私の名前は アレクサンダー・チトフ (@オスミノグ)、DevOps についてだけ説明し、私の経験を共有します。

私は自分のストーリーをどのように役立つものにするかについて長い間考えてきました。そのため、私自身に尋ねる質問や、当社のクライアントに尋ねる質問など、ここでは多くの質問が出てきます。 これらの質問に答えることで、理解が深まります。 私の観点から見てなぜ DevOps が必要なのか、私の観点から見て DevOps とは何なのか、私の観点から見て皆さんが再び DevOps に向かっていることをどのように理解すればよいのかを説明します。 最後のポイントは質疑応答となります。 自分でこれらの質問に答えることで、あなたの会社が DevOps に向かって進んでいるのか、それとも何らかの問題があるのか​​を理解することができます。

かつて私は合併・買収の波に乗っていた時期がありました。 最初、私は Qik という小さなスタートアップで働き、次にそれが Skype という少し大きな会社に買収され、さらにそれが Microsoft という少し大きな会社に買収されました。 その瞬間、DevOps の考え方がさまざまな規模の企業でどのように変化しているかが見え始めました。 その後、DevOps を市場の観点から見ることに興味を持ち、同僚と Express 42 という会社を設立しました。これまで 6 年間、私たちは市場の波に沿って歩んできました。

とりわけ、私は DevOpsモスクワ コミュニティの主催者の 2017 人であり、DevOps-Days 2018 の主催者でもありますが、42 年は主催しませんでした。 Express XNUMX は多くの企業と連携しています。 私たちはそこで DevOps を成長させ、それがどのように起こるかを観察し、結論を導き出し、分析し、結論を全員に伝え、DevOps 実践で人々を訓練します。 一般的に、私たちはこの点に関する経験と専門知識を増やすために最善を尽くしています。

なぜDevOpsなのか

誰もが常に頭を悩ませる最初の疑問は、「なぜ?」です。 多くの人は、DevOps は単なる自動化、またはすべての企業がすでに導入している類似のものだと考えています。

— 継続的インテグレーションがありました。これは、すでに DevOps があったことを意味します。なぜこれだけのものが必要なのでしょうか? 彼らは海外で楽しんでいますが、私たちの仕事は妨げられています。

コミュニティと方法論の 9 年間の開発を通じて、これが依然としてきらびやかなマーケティングではないことはすでに明らかになりましたが、なぜそれが必要なのかはまだ完全には明らかではありません。 他のツールやプロセスと同様、DevOps にも最終的に達成する特定の目標があります。

これはすべて、世界が変化しているという事実によるものです。 彼は、サンクトペテルブルクの古典が歌ったように、企業が特定の戦略に従ってポイント A からポイント B まで、そのために構築された特定の構造を持って夢に向かってまっすぐに進む、エンタープライズ アプローチから離れています。

原則として、IT のすべてはこのアプローチに従って構築される必要があります。 ここでは、IT はプロセスを自動化するためにのみ使用されます。

自動化は頻繁に変更されるものではありません。なぜなら、企業がよく踏まれた轍を踏むとき、何を変える必要があるのでしょうか? 動作しますので、触らないでください。 現在、世界のアプローチは変化しており、アジャイルと呼ばれるものは、エンドポイント B がすぐには見えないことを示唆しています。

企業が市場を歩き回り、クライアントと協力するとき、常に市場を探索し、エンドポイント B を変更します。さらに、企業が方向性を変える頻度が高ければ高いほど、より多くの市場を選択するため、最終的にはより成功します。ニッチ。

この戦略は、私が最近知った興味深い企業によって実証されています。 One Box Shave は、カミソリとシェービング アクセサリーを箱に入った定期購入の配送サービスです。 彼らは、さまざまなクライアントに合わせて「ボックス」をカスタマイズする方法を知っています。 これは特定のソフトウェアによって行われ、製品を生産する韓国の工場に注文が送信されます。

この製品はユニリーバによって1億ドルで買収されました。 現在ではジレットと競合しており、アメリカ市場で消費者のかなりのシェアを奪っている。 ワンボックスシェーブはこう言います。

— 4枚刃？ まじめに？ なぜこれが必要なのか - 髭剃りの品質は向上しません。 特別に選ばれたクリーム、フレグランス、そして 4 枚の刃を備えた高品質のカミソリは、ジレットの愚かな 10 枚の刃よりもはるかに多くの問題を解決します。 もうすぐXNUMX時になりますか？

こうして世界は変わっていくのです。 ユニリーバは、これを可能にする優れた IT システムがあると主張しています。 結局のところコンセプトみたいです 市場投入までの時間、まだ誰も話していません。

市場投入までの時間のポイントは、導入の頻度ではありません。 頻繁にデプロイできますが、リリース サイクルは長くなります。 3 か月のリリース サイクルを重ね合わせて XNUMX 週間ずらすと、同社は週に XNUMX 回デプロイしているように見えることがわかります。 そして、アイデアから最終的な実装までにはXNUMXか月かかります。

市場投入までの時間とは、アイデアから最終実装までの時間を最小限に抑えることです。

この場合、ソフトウェアは市場と相互作用します。 これが、One Box Shave Web サイトがクライアントとやり取りする方法です。 彼らには販売員はいません。訪問者がクリックして要望を残すだけのウェブサイトです。 したがって、常に新しいものをサイトに投稿し、要望に応じて更新する必要があります。 たとえば、韓国ではロシアとは異なる髭剃りをしており、松の香りではなく、ニンジンやバニラなどの香りを好みます。

サイトの内容を迅速に変更する必要があるため、ソフトウェア開発は大きく変わります。 ソフトウェアを通じて、クライアントが何を望んでいるのかを見つけ出さなければなりません。 以前は、経営管理などの回りくどい方法でそれを学びました。 それから私たちはそれを設計し、要件を IT システムに組み込みました。そして、すべてがうまくいきました。 今は違います。ソフトウェアは、技術仕様を通じて市場がどのように機能するかを学び、洞察をビジネスと共有するため、エンジニアを含むプロセスに関与する全員によって設計されます。

たとえば、Qik では、人々が連絡先リストをサーバーにアップロードするのが大好きであることを突然知り、彼らが私たちにアプリケーションを提供してくれました。 当初、私たちはそれについて考えていませんでした。 従来の企業であれば、誰もがこれはバグだと判断したでしょう。なぜなら、仕様にはうまく機能するはずとは書かれておらず、通常は膝の上で実装されているからです。そのため、機能をオフにして、「これは誰も必要としません。最も重要なことは、主要な機能が動作することです。」 そしてテクノロジー企業はこれをチャンスと捉え、これに合わせてソフトウェアを変更し始めます。

1968 年、先見の明のある男、メルビン コンウェイは次のアイデアを策定しました。

システムを作成する組織は、その組織の通信構造を再現する設計によって制約されます。

もっと詳しく言うと、異なるタイプのシステムを作成するには、社内でも異なるタイプのコミュニケーション構造が必要になります。 通信構造が最上位階層である場合、非常に高い市場投入までの時間を提供できるシステムを作成することはできません。

読む コンウェイの法則について 1ことができます リンク経由。 これは DevOps の文化や哲学を理解するために重要です。 DevOps で根本的に変わる唯一のことは、チーム間のコミュニケーションの構造です.

プロセスの観点から見ると、DevOps 以前は、分析、開発、テスト、運用のすべての段階が直線的でした。
DevOps の場合、これらすべてのプロセスが同時に発生します。

それを実現できる唯一の方法は、市場投入までの時間を短縮することです。 古いプロセスで作業していた人々にとって、これはいくぶん宇宙的なものに見えますが、一般的にはまあまあです。

では、なぜ DevOps が必要なのでしょうか?

デジタル製品開発用。 あなたの会社にデジタル製品がない場合、DevOps は必要ありません。これは非常に重要です。

DevOps はソフトウェアの逐次生産の速度制限を克服します。 その中ですべてのプロセスが同時に発生します。

難易度が上がります。 DevOps エバンジェリストが、これによってソフトウェアのリリースが容易になると言っていますが、これはナンセンスです。

DevOps では、事態はさらに複雑になるだけです。

Avito スタンドでのカンファレンスでは、非現実的なタスクである Docker コンテナのデプロイがどのようなものかを見ることができました。 複雑さは法外になり、同時に多くのボールをジャグリングする必要があります。

DevOps は社内のプロセスと組織を完全に変える — より正確に言えば、変化するのは DevOps ではなく、デジタル製品です。 DevOps に移行するには、このプロセスを完全に変更する必要があります。

専門家への質問

何を持っていますか？ 企業で働き、スペシャリストとして成長する際に自問できる質問。

デジタル製品を作成するための戦略はありますか? あるなら、それはもういいです。 これは、あなたの会社が DevOps に移行していることを意味します。

あなたの会社はすでにデジタル製品を開発していますか? これは、これも DevOps の観点から、もう XNUMX つ上のレベルに上がって、物事をより興味深いものにできることを意味します。 私はただこの観点から話しているだけです。

あなたの会社はデジタル製品ニッチ市場のリーダーの XNUMX つですか? Spotify、Yandex、Uber は、現在テクノロジーの進歩の頂点にある企業です。

これらの質問を自分自身に問いかけて、答えがすべて「ノー」であれば、この会社では DevOps を行うべきではないかもしれません。 DevOps のトピックに本当に興味があるのであれば、おそらく...別の会社に移ったほうがよいでしょうか? あなたの会社が DevOps に参入したいと考えているにもかかわらず、すべての質問に「いいえ」と答えた場合、それは永遠に変わらない美しいサイのようなものです。

組織

先ほども言いましたが、コンウェイの法則によれば、会社の組織は変化します。 まず、組織の観点から、DevOps が社内に浸透するのを妨げるものから始めます。

「井戸」の問題

英語の「Silo」はここではロシア語に「井戸」と訳されています。 この問題のポイントは、 チーム間での情報交換はありません。 各チームは、ナビゲートするための共通の地図を構築せずに、専門知識を深く掘り下げます。

ある意味、これはモスクワに到着したばかりで地下鉄路線図の使い方をまだ知らない人のことを思い出させます。 モスクワ人は通常、自分たちの地域をよく知っており、モスクワ全域で地下鉄の地図を使用して移動できます。 初めてモスクワに来たとき、あなたはそのようなスキルを持っておらず、ただ混乱しているだけです。

DevOps では、この混乱の瞬間を乗り越え、すべての部門が協力して共通のインタラクション マップを構築することを提案しています。

これを妨げる要因が XNUMX つあります。

企業管理システムの影響。 これは、個別の階層的な「ウェル」に構築されます。 たとえば、このシステムをサポートする企業には特定の KPI があります。 一方で、専門分野の境界を越えてシステム全体を操作することが難しい人の脳は邪魔になります。 ただ不快です。 あなたがバンコクの空港にいると想像してください。すぐには道が見つからないでしょう。 DevOps はナビゲートするのが難しいため、そこに到達するにはガイドを見つける必要があると言われます。

しかし、最も重要なことは、DevOps の精神に染まり、ファウラー氏や他の多くの本を読んだエンジニアにとっての「井戸」の問題は、次の事実で表現されているということです。 「井戸」では「当たり前のこと」ができない。 私たちは DevOps モスクワの後によく集まり、お互いに話をしますが、人々は次のように不満を言います。

— 私たちは CI を立ち上げたかっただけですが、経営陣はそれを必要としていないことが判明しました。

これはまさに次の理由で起こります CI и 継続的デリバリープロセス 多くの試験の境界線にあります。 組織レベルでの「井戸」の問題を乗り越えなければ、何をしても、どんなに悲しくても、前に進むことはできません。

社内のプロセスの各参加者、つまりバックエンド開発者とフロントエンド開発者、テスト、DBA、運用、ネットワークがそれぞれ独自の方向に進んでおり、マネージャー以外には共通の地図を持っている人はいません。マネージャーは何らかの方法でそれらを監視し、「分断」を使用して管理します。そして征服する」という方法です。

人々はスターや旗を求めて争っており、誰もが自分の専門知識を掘り下げています。

その結果、これらすべてを接続して共通のパイプラインを構築するという課題が生じ、星や旗を争う必要がなくなったとき、「何をすべきか」という疑問が生じます。 何とか合意に達する必要がありますが、学校ではその方法を誰も教えてくれませんでした。 私たちは学校のときから教えられてきました：中学XNUMX年生 - すごい！ - XNUMX年生と比べて！ ここでも同じです。

あなたの会社でも同じですか？

これを確認するには、次の質問を自分自身に問いかけてください。

チームは共通ツールを使用し、それらの共通ツールの変更に貢献していますか?

チームの再編成はどのくらいの頻度で行われますか? あるチームの一部のスペシャリストが別のチームに移動します。 これが普通になるのは DevOps 環境です。なぜなら、人は別の専門分野が何をしているのかを単純に理解できない場合があるからです。 彼は別の部門に移り、そこで XNUMX 週間働き、オリエンテーションとこの部門とのやり取りのマップを自分で作成しました。

変革委員会を作って変えることは可能でしょうか？ それとも最高の経営陣の強い手と指示が必要なのでしょうか？ 私は最近、あるあまり知られていない銀行が注文を通じてツールを導入している方法を Facebook に書きました。注文を書き、それを XNUMX 年間導入して、何が起こるかを確認します。 もちろん、これは長くて悲しいことです。

経営者にとって、会社の業績を考慮せずに個人の業績を評価することがどれほど重要でしょうか?

これらの質問に自分で答えてみると、あなたの会社にそのような問題があるかどうかが明確になります。

コードとしてのインフラストラクチャ

この問題が解決された後、最初の重要な実践は、これなしでは DevOps をさらに進めることが困難になります。 コードとしてのインフラストラクチャ.

ほとんどの場合、コードとしてのインフラストラクチャは次のように認識されます。

— bash ですべてを自動化し、スクリプトでカバーして管理者の手作業を減らしましょう。

しかし、そうではありません。

コードとしてのインフラストラクチャとは、その状態を常に理解するために、作業する IT システムをコードの形式で記述することを意味します。

他のチームと協力して、誰もが理解でき、ナビゲートできるコードの形式でマップを作成します。 Chef、Ansible、Salt、または Kubernetes での YAML ファイルの使用など、何を実行するかは関係ありません。違いはありません。

カンファレンスでは、2GIS の同僚が、個々のシステムの構造を記述する Kubernetes 用の内部的なものを独自に作成した方法を語った。 500 のシステムを説明するには、この説明を生成する別のツールが必要でした。 この記述があると、何が足りないのか、どう変更して改善するのか、みんなで確認し合って変化を監視することができます。

同意します。通常、個々の bash スクリプトではこの理解が提供されません。 私が働いていた会社の XNUMX つでは、「書き込み専用」スクリプトという名前さえありました。つまり、スクリプトは書かれていますが、現在はそれを読むことはできません。 これは皆さんもご存知かと思います。

コードとしてのインフラストラクチャは インフラストラクチャの現在の状態を説明するコード。 多くの製品、インフラストラクチャ、サービス チームがこのコードに協力して取り組んでいますが、最も重要なのは、チーム全員がこのコードが実際にどのように機能するかを理解する必要があることです。

コードはベスト コード プラクティスに従って保守されます。: 共同開発、コード レビュー、XP プログラミング、テスト、プル リクエスト、コード インフラストラクチャの CI - これらすべてが適切であり、使用できます。

コードはすべてのエンジニアの共通言語になります。

コードでインフラストラクチャを変更するのにそれほど時間はかかりません。 はい、インフラストラクチャ コードにも技術的負債が生じる可能性があります。 通常、チームは、スパゲッティ コードのように記述した大量のスクリプトまたは Ansible の形で「コードとしてのインフラストラクチャ」を実装し始めてから XNUMX 年半後にこの問題に遭遇します。さらに、bash スクリプトも混合に投入します。

それが重要だ: まだこのことを試していない場合は、覚えておいてください。 Ansible は bash ではありません！ ドキュメントを注意深く読み、それについて書かれている内容を研究してください。

コードとしてのインフラストラクチャは、インフラストラクチャ コードを個別のレイヤーに分離することです。

当社では、非常に明確かつシンプルな 3 つの基本レイヤーを区別していますが、さらに多くのレイヤーがある場合もあります。 インフラストラクチャ コードを確認すると、この状態にあるかどうかがわかります。 強調表示されているレイヤーがない場合は、時間をかけて少しリファクタリングする必要があります。


ベースレイヤー - これは、OS、バックアップ、その他の低レベルのものの構成方法です。たとえば、Kubernetes が基本レベルでデプロイされる方法です。

サービスレベル - これらは開発者に提供するサービスです: サービスとしてのロギング、サービスとしてのモニタリング、サービスとしてのデータベース、サービスとしてのバランサー、サービスとしてのキュー、サービスとしての継続的配信 - 個々のチームが提供する一連のサービス開発に提供できる。 これらはすべて、構成管理システムの個別のモジュールで説明する必要があります。

アプリケーションが作成される層 そして、前の XNUMX つのレイヤーの上にそれらがどのように展開されるかを説明します。

質問を制御する

あなたの会社には共通のインフラストラクチャ リポジトリがありますか? インフラストラクチャの技術的負債を管理していますか? インフラストラクチャ リポジトリでの開発プラクティスを使用していますか? インフラストラクチャは複数の層に分割されていますか? Base-service-APP 図を確認できます。 変化を起こすのはどれくらい難しいですか?

変更を加えるのに XNUMX 日半かかったという経験がある場合、これは技術的負債があり、それに対処する必要があることを意味します。 インフラストラクチャ コードで技術的負債が増大していることに遭遇しました。 一部の CCTL を変更するために、インフラストラクチャ コードの半分を書き直す必要があるときの、そのような話をよく覚えています。創造性とすべてを自動化したいという欲求により、あらゆるものがあらゆる場所で腐食し、すべてのハンドルが削除され、リファクタリングが必要です。

継続的デリバリー

借方と貸方を比較してみましょう。 最初にインフラストラクチャについて説明しますが、これは非常に基本的なものになります。 すべてを詳細に説明する必要はありませんが、作業を進めるためにいくつかの基本的な説明は必要です。 そうしないと、次に継続的デリバリーをどうするかが明確になりません。 DevOps を始めると、これらすべてのプラクティスが同時に展開されますが、それは、自分が持っているものとそれを管理する方法を理解することから始まります。 これはまさに、コードとしてのインフラストラクチャの実践です。

それを持っていることとそれを管理する方法が明確になると、開発者コードをできるだけ早く運用環境に送信する方法を見つけ始めます。 つまり、開発者と一緒に - 私たちは「井戸」の問題について覚えています。つまり、これを思いついたのは個人ではなく、チームです。

私たちが一緒にいるとき ヴァーニャ・エフトゥホビッチ 最初の本を見た ジェズ・ハンブル および著者のグループ 「継続的デリバリー」2009年にリリースされたこの作品では、そのタイトルをロシア語に翻訳する方法について長い間考えました。 「常に配信する」と訳したかったのですが、残念ながら「継続的配信」と訳されてしまいました。 私たちの名前には、圧力を伴う何かロシア的なものがあるように思えます。

継続的に配信する手段

製品リポジトリにあるコードはいつでも運用環境にダウンロードできます。。 彼は気力が抜けていないかもしれないが、いつでもその準備ができている。 したがって、常に尾てい骨の下に説明の難しい不安を感じながらコードを書くことになります。 これは、インフラストラクチャ コードをロールアウトするときによく表示されます。 この多少の不安感は存在するはずです。それが脳のプロセスを引き起こし、少し違った方法でコードを書くことができるようになります。 これは開発内のルールに記録する必要があります。

一貫して配信するには、インフラストラクチャ プラットフォーム全体で実行されるアーティファクト形式が必要です。 さまざまな形式の「生活の無駄」をインフラストラクチャ プラットフォームに放り込むと、インフラストラクチャ プラットフォームが統合され、維持が困難になり、技術的負債の問題が発生します。 アーティファクトのフォーマットを調整する必要があります。これは集合的な作業でもあります。私たち全員が集まり、頭を悩ませ、このフォーマットを考え出す必要があります。

アーティファクトは継続的に改善され、配信パイプラインを通過する際に実稼働環境に合わせて変更されます。 アーティファクトがパイプラインに沿って移動すると、プロダクションに投入したアーティファクトが遭遇するのと同様の、アーティファクトにとって不都合な出来事が常に発生します。 従来の開発ではこれがロールアウトを行うシステム管理者によって行われていましたが、DevOps プロセスではこれが常に発生します。ここではいくつかのテストでテストし、ここではそれを Kubernetes クラスターに投入しました。これは多かれ少なかれ似ています。本番環境に移行した後、突然負荷テストが開始されました。

これはパックマン ゲームをいくらか思い出させます。アーティファクトはある種のストーリーを経ます。 同時に、コードが実際にストーリーを通過するかどうか、およびコードが制作物に何らかの形で関連しているかどうかを制御することが重要です。 本番環境からのストーリーを継続的デリバリー プロセスにドラッグできます。何かが落ちたときはこのようでした。このシナリオをシステム内でプログラムしましょう。 毎回コードもこのシナリオを通過するため、次回はこの問題は発生しません。 顧客に届くよりずっと早くにそれについて知ることができます。

さまざまな展開戦略。 たとえば、AB テストまたはカナリア デプロイメントを使用して、さまざまなクライアントで異なる方法でコードをテストし、コードがどのように機能するかに関する情報を 100 億ユーザーに展開するよりもはるかに早く取得できます。

「一貫して納品」はこんな感じです。

開発、CI、テスト、PreProd、Prod の配信プロセスは別個の環境ではなく、これらはアーティファクトが通過する耐火性の合計を備えたステージまたはステーションです。

Base Service APP として記述されているインフラストラクチャ コードがある場合は、それが役立ちます すべてのスクリプトを忘れないでくださいそれらをこのアーティファクトのコードとして書き留めます。 アーティファクトを促進する そして、それを変更してください。

セルフテストの質問

機能の説明から本番環境にリリースされるまでの時間は、95% の場合 XNUMX 週間未満ですか? パイプラインの各段階でアーティファクトの品質は向上しますか? それが通る物語はありますか？ さまざまな展開戦略を使用していますか?

すべての答えが「はい」の場合、あなたは信じられないほどクールです! コメントに答えを書いてください - 喜んでお答えします）。

フィードバック

これはすべての練習の中で最も難しい練習です。 DevOpsConf カンファレンスで、これについて話した Infobip の同僚は、言葉が少し混乱していました。なぜなら、これはすべてを監視する必要があるという事実について、実際には非常に複雑な実践だからです。

たとえば、ずっと前、私が Qik で働いていたとき、すべてを監視する必要があることに気づきました。 これを実行した結果、Zabbix には 150 のアイテムがあり、常に監視されています。 恐ろしかった、テクニカルディレクターはこめかみで指をひねった。

- 皆さん、なぜ不明瞭な内容でサーバーをレイプしているのですか?

しかしその後、これが実に素晴らしい戦略であることを示す事件が発生しました。

サービスの 4 つが頻繁にクラッシュするようになりました。 興味深いことに、当初はクラッシュしませんでした。これは基本的なブローカーであり、実質的にビジネス機能を持たず、単に個々のサービス間でメッセージを送信するだけだったため、コードは追加されませんでした。 サービスは XNUMX か月間変更されませんでしたが、突然「セグメンテーション違反」エラーでクラッシュし始めました。

私たちはショックを受け、Zabbix でチャートを開いたところ、XNUMX 週間半前に、このブローカーが使用する API サービスでのリクエストの動作が大きく変化したことが判明しました。 次に、特定の種類のメッセージの送信頻度が変化したことがわかりました。 後で、これらが Android クライアントであることがわかりました。 私たちはこう尋ねました。

— 皆さん、XNUMX週間半前に何が起こりましたか？

それを受けて、UIをどのように再設計したかについて興味深い話を聞きました。 HTTP ライブラリを変更したとすぐに言う人はいないでしょう。 Android クライアントにとって、それは浴室で石鹸を交換するようなもので、単に覚えていないだけです。 その結果、40 分間の会話の後、HTTP ライブラリが変更され、そのデフォルトのタイミングが変更されたことがわかりました。 これにより、API サーバー上のトラフィックの動作が変化し、ブローカー内で競合が発生し、ブローカーがクラッシュし始めました。

綿密な監視がなければ、通常、これを開くことは不可能です。 組織に依然として「井戸」の問題があり、全員がお互いにお金を投げ合う場合、この状態が何年も続く可能性があります。 問題を解決することは不可能なので、単にサーバーを再起動するだけです。 発生するすべてのイベントを監視、追跡、追跡し、監視をテストとして使用すると、コードを作成し、それを監視する方法をすぐにコードの形式で指示します (コードとしてのインフラストラクチャがすでにあります)。すべてがどのように行われるか明らかになります。手のひらに。 このような複雑な問題も簡単に追跡できます。

本番環境ではなく、配信プロセスの各段階でアーティファクトに何が起こるかに関するすべての情報を収集します。

モニタリングを CI にアップロードすると、いくつかの基本的なものがそこにすでに表示されています。 後で、Test、PredProd、および負荷テストでそれらを確認します。 メトリクス、統計だけでなく、アプリケーションの展開方法、異常などのログも含め、あらゆる段階で情報を収集します。すべてを収集します。

そうしないと、それを理解するのが難しくなります。 DevOps はより複雑であるとすでに述べました。 この複雑さに対処するには、通常の分析が必要です.

自制のための質問

監視とログ記録は開発ツールですか? あなたを含む開発者は、コードを書くとき、それを監視する方法について考えますか?

顧客からのトラブルについて聞いていますか？ 監視とログ記録によってクライアントについてよりよく理解できましたか? 監視とログ記録によってシステムをよりよく理解できましたか? システムの傾向が拡大しているのを見て、あと 3 週間ですべてが消滅することがわかったからといって、システムを変更しますか?

これら XNUMX つのコンポーネントを用意したら、社内にどのような種類のインフラストラクチャ プラットフォームがあるかを考えることができます。

インフラストラクチャプラットフォーム

重要なのは、それがすべての企業が持っている異なるツールのセットであるということではありません。

インフラストラクチャ プラットフォームのポイントは、すべてのチームがこれらのツールを使用し、共同で開発することです。

インフラストラクチャ プラットフォームの個々の部分の開発を担当する別個のチームが存在することは明らかです。 しかし同時に、すべてのエンジニアはインフラストラクチャ プラットフォームの開発、パフォーマンス、推進に対して責任を負います。 社内レベルでは共通ツールとなる.

すべてのチームがインフラストラクチャ プラットフォームを開発し、それを独自の IDE として注意深く扱います。 IDE では、すべてを快適かつ高速にするためにさまざまなプラグインをインストールし、ホットキーを設定します。 Sublime、Atom、または Visual Studio Code を開くと、コード エラーが大量に発生し、まったく作業できないことに気づき、すぐに悲しくなり、IDE を修正するために走ります。

インフラストラクチャ プラットフォームも同様に扱います。 何か問題があることがわかっていて、自分で修正できない場合はリクエストを残してください。 簡単なものがあれば、自分で編集してプルリクエストを送信すると、メンバーが検討して追加します。 これは、開発者の頭の中にあるエンジニアリング ツールに対する少し異なるアプローチです。

インフラストラクチャ プラットフォームは、品質を継続的に向上させながら、開発からクライアントへの成果物の転送を保証します。。 IP は、本番環境のコードに起こる一連のストーリーを使ってプログラムされています。 長年の開発を通じて、これらのストーリーはたくさんありますが、その中にはユニークであなただけに関係するものもあります。それらは Google で検索することはできません。

この時点で、インフラストラクチャ プラットフォームが競争上の優位性となります。競合他社のツールにはないものが組み込まれているからです。 IP の深さが深いほど、市場投入までの時間の点で競争上の優位性が高まります。 ここに表示されます ベンダーロックの問題：他人のプラットフォームを利用することはできますが、他人の経験を利用しても、それが自分にとってどれだけ関連しているかはわかりません。 はい、すべての企業が Amazon のようなプラットフォームを構築できるわけではありません。 これは、企業の経験が市場における自社の地位に関係する難しい境界線であり、そこでベンダーロックを使用することはできません。 これも考えることが重要です。

スキーム

これは、DevOps 企業におけるすべての実践とプロセスのセットアップに役立つインフラストラクチャ プラットフォームの基本的な図です。

それが何で構成されているか見てみましょう。

リソースオーケストレーションシステム、CPU、メモリ、ディスクをアプリケーションやその他のサービスに提供します。 この上に - 低レベルのサービス: モニタリング、ロギング、CI/CD エンジン、アーティファクト ストレージ、システム コードとしてのインフラストラクチャ。

より高いレベルのサービス: サービスとしてのデータベース、サービスとしてのキュー、サービスとしてのロードバランス、サービスとしてのイメージのサイズ変更、サービスとしてのビッグデータファクトリー。 この上に - 常に変更されたコードをクライアントに配信するパイプライン.

ソフトウェアがクライアントに対してどのように機能するかについての情報を受け取り、それを変更し、このコードを再度提供し、情報を受け取ることで、インフラストラクチャ プラットフォームとソフトウェアの両方を常に開発することになります。

この図では、配信パイプラインは多くのステージで構成されています。 ただし、これは例として示した概略図であり、XNUMX つずつ繰り返す必要はありません。 ステージは、あたかもサービスであるかのようにサービスと対話します。プラットフォームの各ブリックには、リソースの割り当て方法、アプリケーションの起動方法、リソースの操作方法、監視方法、および変更方法など、独自のストーリーが含まれています。

プラットフォームの各部分にはストーリーがあることを理解し、このレンガにどのようなストーリーがあるのか​​を自問することが重要です。もしかしたら、このレンガを捨ててサードパーティのサービスに置き換えるべきかもしれません。 たとえば、レンガの代わりに Okmeter をインストールすることは可能ですか? おそらく、彼らはすでにこの専門知識を私たちよりもはるかに開発しています。 しかし、そうではないかもしれません。おそらく私たちは独自の専門知識を持っているので、Prometheus をインストールしてさらに開発する必要があります。

プラットフォームの構築

これは複雑なコミュニケーションプロセスです。 基本的な実践を行うと、要件や標準を開発するさまざまなエンジニアや専門家の間でコミュニケーションを開始し、それらをさまざまなツールやアプローチに継続的に変更します。 ここでは、DevOps にある文化が重要です。

文化ではすべてが非常にシンプルです - それはコラボレーションとコミュニケーションに関するものですつまり、お互いに共通の分野で働きたいという願望、一緒に一つの楽器を使いこなしたいという願望です。 ここにはロケット科学はありません。すべてが非常に単純でありふれたものです。 例えば、私たちは皆、玄関に住んでいて、それをきれいに保つ、そのようなレベルの文化です。

何を持っていますか？

繰り返しになりますが、自分自身に問いかけることができる質問です。

インフラストラクチャ プラットフォームは専用ですか? その開発の責任者は誰ですか? インフラストラクチャ プラットフォームの競争上の利点を理解していますか?

これらの質問を常に自分自身に問い続ける必要があります。 サードパーティのサービスに転送できるものは転送する必要がありますが、サードパーティのサービスがあなたの動きを妨げ始めたら、自分の中にシステムを構築する必要があります。

それで、DevOps...

...これは複雑なシステムなので、次のものが必要です。

• デジタル製品。
• このデジタル製品を開発するビジネス モジュール。
• コードを書く製品チーム。
• 継続的デリバリーの実践。
• サービスとしてのプラットフォーム。
• サービスとしてのインフラストラクチャ。
• コードとしてのインフラストラクチャ。
• 信頼性を維持するための個別のプラクティスが DevOps に組み込まれています。
• すべてを説明するフィードバックの実践。

この図を使用して、社内にすでに何らかの形で導入されているもの、つまり開発済みか、まだ開発の必要があるものを強調表示できます。

あと数週間で終わるよ DevOpsConf 2019。 RIT++ の一部として。 カンファレンスにお越しください。そこでは、継続的デリバリー、コードとしてのインフラストラクチャ、DevOps 変革に関する多くの素晴らしいレポートがご覧いただけます。 チケットを予約する、最終価格の締め切りは 20 月 XNUMX 日です

出所： habr.com