DevOpsに関する神話

DevOpsはマーケティング用語であり、何もありません！ それともとにかくありますか？ たぶん、DevOpsは「正しい」ツールのセットなのか、それともそんな特別な文化なのか。 誰がこれを行うべきなのか、DevOpsエンジニアとは何ですか？ つまり、 概念にはいくつかの違いがあり、多くの神話があります。 完全に些細なものもあれば、それを信じる人も少なく、尊敬される専門家の心に根付く人もいます。 経験豊富なDevOps'erのAlexander TitovとIvan Evtuhovich （ evtuhovich ）に対処します。 彼らは、 DevOpsはデジタル製品の製造の問題に対する解決策であり、そのような個人をロシアのビジネススタイルで呼ぶと信じていますが。


スピーカーについて ：Alexander TitovとIvan Evtukhovichは、DevOpsの分野でコンサルティングを行うExpress 42を代表しています。 彼女のクライアントには、MTS、Raiffeisenbank Bank、Alfa Bankなど、多くの有名な企業が含まれます。

5年間の作業で、社会に存在するDevOpsに関する多くの神話が集まりました。 RIT ++ 2017のレポートで、AlexanderとIvanはこのトピックについて話しました。 イヴァンは強引な口調で従来の知恵を発表し、アレクサンダーはこれが単なる神話であることを聴衆に納得させようとしました。

神話＃1. DevOpsは、DevOps部門またはDevOpsエンジニアが実行できる

通常のDevOpsを作成するために、DevOpsエンジニアを雇うか、DevOps部門を作成します。それだけです。完全なDevOps会社があります！

これは、私たちが常に耳にしているという非常に覚えやすい言葉です。 DevOpsエンジニアがいない理由、DevOps部門を作成する必要 がない理由などを説明する膨大な資料があります。 しかし、やはり同じように、DevOps部門が発生し、DevOpsのエンジニアがそこで採用され、DevOpsスペシャリストにはますます多くの空きがあります。

どうやら、人々は記事やレポートで提示された議論を完全に信じていないようです。 これについてもう一度話をしようと思います。 これは私の個人的な意見であり、個人的な経験に裏付けられています。

私はしばしばこの状況を見ます。 CEOまたは取締役会がデジタルトランスフォーメーションで病気になるまで、普通の会社では何も起こりません。 これは非常に伝染性の病気であり、通常、CEOや経営陣の会議で広がります。 その後、アジャイル、DevOps、デジタル、製品などの言葉が頭の中に現れます。ある人が部下を集めて、「みんな、アジャイル、DevOps、デジタルが必要です」と言います。

実際、これを理解することは監督の仕事ではありません。 彼は、例えば、収入、価値の流れを増やす方法を自分で演ducし、これが互いに相関していることに気づきました。

その後、みんなが集まり、それをどうするか考え始めます。 ウィキペディアはDevOpsについて読みました ： 「開発者、操作、ソフトウェアの継続的な供給のためのテストを統合する方法論 。 」

同社では、ソフトウェアの供給は継続的であり 、3か月ごとに展開されています。 開発者とシステム管理者は常に一緒にバーにアクセスします- 相互作用に問題はありません。 強い意思決定を下し、DevOpsの一部の部門名を変更する必要があります。

最終的に、品質部門は、それを行う人々の経験に応じて、DevOpsまたは運用部門に名前が変更されます。 しかし、品質/問題エンジニアがいる場合、この部門で何をすべきか？ これは間違っています。名前をDevOpsエンジニアに変更する必要があります。

従業員の名前が変更され、 新しい空席が投稿されます。 私たちとクライアントはエンジニアを探しているため、DevOpsの仕事を定期的に確認しています。 また、私のサークルhh.ruにアクセスして、DevOpsエンジニアの求人を見ることができます。 それらはすべてとても違います！

厳密な標準化や類型化はまったく区別できません。ジェンキンスでパイプラインを構成する人から、セルフテストを書くテスターまで。 展開の専門家からAmazon、監視のセットアップ、ソフトウェアの展開などまで。 ITの可能なすべての職業は、DevOpsエンジニアとしてラベル付けされています。

例外は、実際にソフトウェアが途切れることなく供給されるデジタル製品を実際に製造している小さな会社です。 別の資格を選ぶのは難しいので、彼らはすべてが一体となった人々を探しています。 次に、DevOpsエンジニアの欠員を単純にレイアウトします。その中には、一般的に、Jenkins、Ansible、Chef、Docker、Kubernetes、Silex、Prometheusがすべて記述されています。 人々はよくスペルミスのテクノロジー名を書くことが好きです。



一般的に、私はDevOpsエンジニアやDevOps部門という名前に反対ではありません。 しかし、DevOpsにとって最も重要なことは、企業内でバリューストリーム全体を作成することです 。 DevOpsは、分析から特定の操作まで、すべてをカバーする必要があります。 これは、別の職業や著名な役割ではなく、デジタル製品の迅速な生産の問題を解決するものです。

この言葉の最初の言及は、 パトリック・デボワが会議で次のように言った2009年にさかのぼります。

-新しいアプローチの使用を開始しました。 現在、デジタル製品を生産していますが、問題があります。以前と同様、何も機能しません。 私だけでは解決できません。 コミュニティにみんなを招待して、一緒に暮らす方法を一緒に考えましょう。 この問題をDevOpsと呼びましょう。

DevOpsは、デジタル製品製造の問題に対するソリューションです。 これを私たちのロシアのビジネススタイルの個人と呼ぶには、人はいません-問題はありません、人はいます-解決策があります 。 逆論理。

DevOpsエンジニアを探している場合は、なぜそれが必要なのかを検討してください。 理解できない専門家よりも、特定の能力を強調し、市場でそれを探す方が良いです。

質素な人々への支援：通常、Docker知識を持つDevOpsエンジニアのDocker知識を持つシステム管理者は、知識によって区別されるのではなく、値札によって区別されます：最初の条件付きコストは90,000、2番目-150,000です。節約できます。

「壁にシートを投げる」というフレーズは、開発がそれを運用に投入したときに人気がありました-「入れて！」、彼らはそれを投げ返しました-「起きない！」 DevOps部門の出現により、壁を2回覆います：最初に、DevOps部門への開発、およびOps部門への開発。

神話番号2。DevOpsは、すべてを行えるマルチタスクスペシャリストを雇うことです。

この問題の原因についての私の解釈をお伝えします。 DevOpsでのこのストーリー全体が始まったばかりのとき、すべての作業はマルチタスクスペシャリストによって実際に行われました。 たとえば、ある人が配信パイプラインを構築し、監視を設定するなど。 私自身も同じことから始めて、自分ですべてをやりました。誰に請求できるのかわからなかったからです。ここで調査し、ここでねじ止めし、そこでやらなければなりませんでした。 その結果、私はLinuxをセットアップし、Chefで書いて、ZabbixなどのAPIをねじ込むマルチタスクスペシャリストでした。 私はすべてをしなければなりませんでした。

しかし、実際には機能しません 。

性能

• ピンを自分で作ることができる18人のマルチツール職人は、1日あたり360本のピンを作ります
  
• 18の専門分野で分けられた18人の職人が48,000本のピンを作ります。
  

これは、Adam Smithの本からのピン工場での生産成長の有名な例です。 実際、これらのピンに関する話は彼によって発明されたのではなく、英国百科事典から正直に盗まれただけです。

実際、このロジックはどこにも行っていません。 スペシャリストが職域を超えて働くべきだと聞いたとき、 チームは職域を超えて働くべきだと思いますが、スペシャリストはいません。 それ以外の場合、48,000ピンを生産する必要があるときに話をしますが、人々は単に十分ではありません。

本「プロジェクト」フェニックス」。 DevOpsがビジネスをより良く変える方法についての小説」は、ブランドンの話を説明しています。ブランドンは、会社ですべてを行い、すべてがボトルネックのように彼に閉じこもります。 これはクールなマルチパンチスペシャリストの話です。

しかし、その後、問題が発生します-あなたがマルチワーカーを雇わない場合、誰を雇うのですか？ この質問に対する明確な答えはありません。問題は、ロシアのコミュニティでは私たちがそれについてほとんど語っていないことです。 私たちは問題を投げるのが大好きですが、誰もそれを解決するのが好きではありません。 DevOpsを実践する人々向けの特定の専門分野は強調していません。

役割を分けずに、マルチステーションの専門家について常に話し合うので、これらの役割を大々的に強調してこの作業に招待しようとします。

DevOps、その他の役割：

• 本番環境でのソフトウェアのアーキテクチャと作業のアイデアを持つ開発者 （テストとインフラストラクチャコードを記述）
  

この開発者と典型的なロシアの大学の卒業生との違いは何ですか？ 典型的なロシアの大学の開発者はアルゴリズムを書くことができます-それだけです。 DevOps-developerは、説明の書き方を知っているだけでなく、この説明がどのように実現するかを知っています。

私はラジオエレクトロニクスからITに来ましたが、ここで何が起こっていたのかは驚きでした。人々は回路図は実用的な製品だと考えています。 ラジオエンジニアは頭の中にそのような神話はありませんが、ITには神話があります。

回路図は実用的な製品ではないことを知っている開発者が必要です 。 それらのいくつかはあります、それらは隣接するエリアから来ます-例えば、ラジオ電子機器から。 ロシアの大学によって訓練された人々はこれを知りません。 彼らは私たちがコードを書いたと思います-わかりました。

会社にDevOpsを実装することを計画している場合、このコンピテンシーは内部で構築するのが最も簡単です。問題を特定し、自分でできない場合は、人々を教育する人を雇い、必要なカテゴリを与え、本番環境でソフトウェアを使用する方法を教えてください。

• インフラストラクチャエンジニア （インフラストラクチャのバインディングを作成し、開発者にプラットフォームを提供します）
  

実際、この役割は非常に豊富であるため、さらに分割できます。 本質的には、継続的配信プラットフォームの製品を所有する製品所有者マネージャーと、この配信プラットフォームを構築する人々の個々の能力が含まれます。 しかし、これは大企業向けです。

中小企業にとっては、すべてが簡単です。 これは、構成管理システムに精通したエンジニアであり、Docker（Kubernetes）が継続的にソフトウェア配信プロセスを作成して開発者に提供できることを知っています。

• インフラストラクチャサービス開発者 （DBaS、サービスとして監視、サービスとしてログ）
  

これらは、製品として開発者に提供されるサービスです。 Amazonにアクセスして、これらの個別のサービスを購入できます。 AmazonはDevOpsの役割のモデルと考えることができます。つまり、Amazonが販売するものは自分自身の中で成長させることができます。

• リリースマネージャー （プロセスと依存関係を管理）
  

これはビルドをビルドする人ではありません。 依存関係 、バージョンを管理し 、統合環境に関する合意についてチームを支援し、継続的デリバリーパイプラインの動作を監視します。

多くの場合、これは人間ですが、ソフトウェアを継続的に提供できるようにチームに魔法をかける妖精です。

神話3.私たちは企業のITシステムを開発しており、1995年からDevOpsを導入しています

当社は長年にわたって企業のITシステムを開発しており、毎週リリースされます。 すべてのDevOps-それは、ジーンズにひねりを加えた男たちがやって来て、長年私たちができることを呼び直したものです。

ところで、このようなチームでは通常、インシデントが発生するとDevOpsプロセスが実際に有効になるのは非常に興味深いことです。 このような状況では、開発者、テスターなどの個々のチームの間の境界がはっきりとぼやけます。彼らは長年にわたって開発された独自のプロセスを持っています。 正式なものではありませんが、実際にはDevOpsのように見えます。

この神話はどこから来たのですか？



事実は、人々が単位時間あたりのリリースでソフトウェアの継続的な供給を測定しようとしているということです。 彼らは、「週に一度展開したら、それはDevOpsですか？」と尋ねます。一般的に言えば、これは良い結果です。 しかし、実際には、同じチーム内であっても、個々のコンポーネントのリリースサイクルは異なります。 同時に、リリースサイクルは3か月かかり、異なるリリースサイクルに応じて、実際には週に1回分割されます。 DevOpsと呼ばれるハックが判明しました。 実際、概念の代替がありました。

DevOpsの主なポイントは、 市場投入までの時間を提供することです。 これは、単位時間あたりのロールアウトの数ではなく、 コードの最初の行を記述してから実稼働でロールアウトするまでに経過する時間です 。 ここで、週の指標はすでに非常にクールで、3か月は本当にクールではありません。 これらはもはやDevOpsではありません。



市場投入までの時間は、デジタル製品を製造する企業が顧客のために成功するために必要です。 デジタル企業は、ビジネスマン、製品所有者など、ソフトウェアを書くエンジニアです。 通常、これらの企業はクライアントと個人的に仕事をしていないため、膨大なフィードバックを持っています。

Uberは、クライアントがサービスに不満を感じるまで、クライアントと個人的に通信しません。 この場合、人は電話を開き、そこにGet、Yandex-taxi、Maximがいます。 彼は決定を下し、すぐに別のプレイヤーに移動できます。 したがって、市場からのフィードバックを迅速に開発する必要があります。さらに、市場（顧客）は常に変化しています。

したがって、組織でDevOpsを推進する主なパラメーターは、市場投入までの時間です。 大規模な市場向けにデジタルソフトウェアを作成していない会社がある場合、ほとんどの場合、DevOpsは必要ありません。 これはCEOの頭に飛び込んだ単なる流行語であり、彼はそれを完全には理解していませんでした。

横から見るとこんな感じです。



Amazonは実際には11秒に1回展開します。つまり、コードの記述から展開までに11秒が経過する可能性があります。 実際、この背後には膨大な数のDevOpsプラクティスの多くの作業とアプリケーションがあります。

TTMのDevOpsプラクティス

市場投入までの時間のみに焦点を当てた基本的なDevOpsプラクティスの概要を説明しました。これがないと、顧客や市場から継続的なフィードバックを得ることができません。

• ロールアウト戦略 （青緑ロールアウト 、カナリアリリース、a / bテスト）
  

それは良さそうで非常にシンプルに聞こえます-ユーザーの0.1％を展開しましょう。 しかし、このためには、モノリシックアーキテクチャからマイクロサービスに移行するなど、多大な作業を行う必要があります。

• 継続的な監視
  

開発者が本番環境で監視する必要があるものをコードの形式で説明すると、これはテストとして監視されます。 その後、アーティファクトが監視対象の説明とともに起動され、連続配信パイプラインのすべての段階ですぐにすべてが監視に追加されます。 あなたは本当にアプリケーションで何が起こるか見ることができます。

0.1％をロールアウトすると、ソフトウェアが正常に機能するか、何か問題があるかどうかを理解できます。 ソフトウェアで何が起こっているのかわからない場合は、0.1％をロールアウトしても意味がありません。

• エンドツーエンドのロギング
  

これは、IDによってクライアントデータがどのように変化したかを見ることができる場合です：ここで彼はフロントエンドに来て、そこからバックエンドに行き、キューで非同期ワーカーに登り、非同期ワーカーがデータベースに行き、キャッシュ状態を変更しました-これはすべてログに記録されます。 これがなければ、システムで何が起こったのかを見つけることは不可能であり、0.1％もロールバックします。

ロシアのインターネットテクノロジーフェスティバルの2,000人の訪問者すべてに新しいソフトウェアを導入することに決めたが、エンドツーエンドのロギングがないとします。 これらの2,000人の人々は、仕事をしていないと書いています。 あなたの視点からはある種のポルターガイストがあるので、何がうまくいかないのかを彼らに尋ねます。 役に立たないトピック。

• 自動テスト（チーム間の合意の形式として）
  

自動テストは長い間知られており、長年にわたって存在し、ソフトウェアの品質を改善するために使用されてきました。 ここでは、チーム間の合意の形として、自動テストを多少異なる方法で処理する必要があります。 チームは、統合時にソフトウェアの小さな問題を解決する代わりに、各チームが個別のモジュール、要素などを開発する段階で自動テストを作成し、これらの問題を解決することに同意します。 自動テストの作成は別の話です。

説明されているすべてのブリック-TTMのDevOpsプラクティス-は、ゼロから始めずに、たとえばモノリスを書き換える場合、多くの時間と作業になります。 しかし、それらがなければ、市場投入までの長い時間を達成することはできません。

神話4. DevOpsは「正しい」ツールです。

「正しい」ツールを使用してDevOpsを実行できます。Kubernetesを取得し、Ansibleでコーティングし、Prometheusを配置し、Mesosphereを横にねじ込み、すべてのDockerをラップします。DevOpsはすぐに組織に導入されます。

一般に、これは一般的なエンジニアリングビューですが、次のように頻繁に発生します。



継続的な配信に進むために必要な処理の量については既に説明しました。 さらに、チーム内で同意する必要があります。 自動テストを作成する場合、それはチーム内の合意に関するものであり、自動テストを作成する機能を備えています。

多くの場合、DevOpsを実装したい場合、Kubernetesがインストールされ、時間がかかります。そして、手で簡単になり、多くのコンポーネントがあり、バグがある場合があり、これまでのところ、これはすべて不要です。

強力なツールは釘を打ち込むだけです。 もちろん、 DevOpsは適切なツールに関するだけではありません 。 しかし、同時に、DevOpsに直接関連し、Patrick Deboisによって生まれたまさにそのコミュニティによって作成されたツールのクラスが実際にあります。

このツールにはそれぞれ、使用方法も記載されています。インストール方法や内部の配置方法の説明だけでなく、マニュアル、使用方法も記載されています。

たとえば、Gitをインストールすると、内部のハッシュがどのように配置されるかを完全に理解できません。 誰かは知っているが、誰かは知らないが、一般にこの知識は役に立たない。 Kubernetesでも同じです。この知識は、それに同行するエンジニアのみが必要とします。 そして、周囲のエンジニアは彼と働く方法を知る必要があります。 この知識は重要です。忘れないでください。

会社の夜明けには、この会社にいる間だけ構成を管理するChefの展開がいくつかありました。 出発するとすぐに、シェフは別の場所に残され、プロセスは古いトラックに戻りました。 これらは、いわば私たちの試金石でした。 しかし、それにもかかわらず、私たちにはそのような物語がありました。

神話5. DevOpsは「哲学」であり、西洋で生まれた特別な文化であり、ロシアの現実に移すことはできません。

多くの人が、神話のユニコーンが神話のDevOpsを作る神話の西があると信じており、私たちはお互いに無礼であり、ここではDevOpsは生まれません。

これは非常に難しい質問です。 確かに、 デジタル技術は 、非常に開かれた心、批判的思考などのチームで生まれます 。

複雑なエコシステムで作業し、ほぼ目を閉じて作業する場合、つまりブラックボックスとそれを使用する多数のユーザーがいる場合、本当に多くのことを考える必要があるからです。

しかし同時に、哲学は最も重要なことではありません。 知識と特定のスキルもあり、DevOpsにも含まれるツールとアプローチがあります。 文化の存在は必要なプロセスの存在を引き起こしません 。 特別な訓練を受けたコーチによる2日間の訓練で特定の文化が出現しても、何ももたらされません。

それだけでなく、トレーニング後にすぐに何かを始めなければ、トレーニングに投入されたすべてが風化して痕跡もなく消えてしまいます。 私たちは、多くのトレーニングを実施した人々として、これを確実に知っています。 私たち自身がトレーニングに行きました。 これは機能しません。

新しい考え方を学ぶだけでは十分ではありません 。使用するツールを使用して、できれば実際のタスクで、すぐに自分の手で何かを試してください 。

したがって、DevOpsは哲学であるだけでなく、哲学はDevOpsの一部です。 DevOpsはすばらしいアジャイル哲学の一部であると公言しています。 アジャイルの価値があり、DevOpsは、これらの価値を実現するのに役立つエンジニアリングプラクティスとツールのセットとして含まれています。

神話6.悪魔はすでにITILに組み込まれているため、古いものを新しいものとして偽装する必要はありません。 DevOpsは同じプラクティスを使用します。

はい、確かにそうです。 しかし、私はもっと涼しいと言うことができます。 ITILで使用されるすべての分野は、化学プラントにあります。

• インシデント管理;
  
• 構成管理;
  
• 変更管理。
  
• キャパシティ管理。
  
• 可用性管理。
  

これらは一般的な工学分野です。 プロジェクト管理はすでに100年を経ており、ほぼ同じです。工場がいくつあるか、これらの分野がいくつあるかです。 かつては既存の専門分野のみがITに移されましたが、当時はそうでした。

このITは、デジタル製品を製造するITとは根本的に異なります。 これは、議論のための別のトピックです。 ポイントは、 分野は同じですが、コンテンツとコンテンツは異なるということです：標準、アプローチ、テクニック、ツール。

一般に、ITILは別の目的で作成されます。 したがって、一方で、それらは本当に似ていますが、他方では適用できず、使用できません。

神話7. DevOpsはマーケティング用語であり、何もありません。

誰もがこのラベルを掲げ、すべてがそのようなDevOpsになりましたが、実際にはこの言葉は何の意味もありません。 アジャイルJava開発者の全盛期が仕事にあったことを思い出してください。

次に、非常に論争的なトピックに触れます。 紳士、インテグレーター、大手ベンダーは、優秀なディレクターの話を聞いて、製品をDevOps製品に改名しました。 デジタル製品の生産用ではなく、古い企業IT用に作られた製品は、単に名前を変更しました-HP OpenViewで、DevOps HP OpenViewになりました-それだけです。

これは、ITILとほぼ同じ話です。



しかし、パトリック・デボワの言葉の後に始まった本当のコミュニティがあります。 DevOps Daysと呼ばれるイベントが定期的に開催され、2017年にモスクワで開催されました。 世界で毎年約150のこのようなイベントが開催されています。

これらの人々は何かについて話している、通常の筋金入りの男は、経営上の問題だけでなく、エンジニアリングの問題を含む通常の問題を解決します。 つまり、これは理にかなっており、理にかなっている場合、これは単なるマーケティング用語ではありません。

これがマーケティング用語だと思う人への私のアドバイスは、DevOps Daysが作成するコンテンツに注意を払うことです。ベンダーの攻撃や誇大広告はありません。 ロシアにも多くのリソースがあります。

• https://www.meetup.com/DevOps-Moscow-in-Russian/
• http://devopsdeflope.ru
• https://www.2d1o.ru
• http://hangops.ru

DevOpsの問題について説明します。これはマーケティングではないことを理解して聞いてください。 本当に必要なので、人々はDevOpsを行います。

この記事は、RootConf 2017での最高のパフォーマンスの1つである運用カンファレンスとRIT ++フェスティバルの一環としてのDevOpsの転写です。 次のフェスティバルは5月下旬に開催されます。すでにいくつかの興味深いアプリケーションについてお話しすることができます。

• JetBrainsのMikhail Kuzminは、インフラストラクチャ管理におけるこの継続的な配信プロセスに関連するさまざまな問題に対処することを計画しています。
  
• PostmatesのIvan Glushkovは、通常のパッケージマネージャーとの作業経験を k8に移すことを提案しています。
  
• Alexander Khayorov （Ingram Micro Cloud）と一緒に、隙間を埋め、 kubernetesのネットワークの魔法について語ります -囲炉裏からイングレスまで。
  

RootConfまたはRIT ++全体のアプリケーションの完全なリストを見て、自分にとって最も重要なものを選択してください。これは、価格が引き続き上昇する予約チケットへのリンクです。