DevOps エンジニアはいません。 それでは誰が存在し、それをどうするのでしょうか?

最近、このような広告がインターネット上に氾濫しています。 嬉しい給料にもかかわらず、その中にはとんでもない異端が書かれていることに恥ずかしさを感じずにはいられません。 最初は、「DevOps」と「エンジニア」が何らかの方法で XNUMX つの単語に結合できると想定されます。その後、要件のランダムなリストが作成され、その一部は明らかにシステム管理者の欠員からコピーされたものです。

この投稿では、私たちがどのようにしてこのような状況に至ったのか、DevOps とは実際には何なのか、そしてこれから何をすべきかについて少しお話したいと思います。

このような欠員はあらゆる方法で非難される可能性がありますが、事実は変わりません。欠員はたくさんあり、これが現時点での市場の仕組みです。 私たちは Devops カンファレンスを開催し、次のように公然と宣言しました。DevOops - DevOps エンジニア向けではありません。」 多くの人にとって、完全に商業的なイベントを行っている人々がなぜ市場に逆らうのか、これは奇妙で突飛なものに思えるでしょう。 それではすべてを説明します。

文化とプロセスについて

DevOps はエンジニアリングの分野ではないという事実から始めましょう。 すべては、歴史的に確立された役割分担が製品の品質には機能しないという事実から始まりました。 プログラマがプログラミングだけをしていて、テストについては何も聞きたくない場合、ソフトウェアにはバグがたくさんあります。 管理者がソフトウェアがどのように書かれたのか、なぜ書かれたのかを気にしない場合、サポートは地獄と化します。

たとえば、サービス管理に対するシステム管理者と SRE のアプローチの違いについて説明します。 有名な Google SRE Book が始まります。 興味深い研究が国内で行われています DORA調査 — 優秀な開発者が、何らかの方法で 10 時間に XNUMX 回よりも早く新しい変更を運用環境にデプロイできることは明らかです。 彼らは手でテストするのは XNUMX% 未満です (これは次のことからわかります) 去年のドラ）。 彼らはどうやってこれを行うのでしょうか？ レポートの見出しの XNUMX つに「Excel or die」という言葉があります。 テストのコンテキストにおけるこれらの統計の詳細な説明については、Baruch Sadogursky の基調講演を参照してください。 「私たちにはDevOpsがあります。 試験官全員を解雇しましょう。」 私たちのもう一つのカンファレンス、ハイゼンバグで。

「仲間内で合意がないときは、
彼らはうまくいきません。
そして、それは小麦粉だけから出てきません。
むかしむかし、白鳥、ザリガニ、パイク…」

Web プログラマーのどの部分が、アプリケーションが運用環境で使用される条件を本当に理解していると思いますか? そのうち何人が管理者に連絡して、データベースがクラッシュした場合に何が起こるかを調べようとするでしょうか? そして、そのうちの誰がテスターのところへ行って、テストの正しい書き方を教えてくれるように頼むでしょうか? そして、警備員、プロダクトマネージャー、その他大勢の人たちもいます。

DevOps の全体的な考え方は、役割と部門間のコラボレーションを生み出すことです。 まず第一に、これは巧妙に構成されたソフトウェアによってではなく、コミュニケーションの実践によって実現されます。 DevOps とは、文化、実践、方法論、プロセスに関するものです。 これらの質問に答えられるエンジニアリングの専門家はいません。

悪循環

「DevOps エンジニアリング」という学問はどこから来たのでしょうか? バージョンがあります！ DevOps のアイデアは素晴らしく、あまりに優れていたため、自らの成功の犠牲者になりました。 独自の雰囲気を持つ一部の怪しげな勧誘員や人身売買業者が、この話題全体を巡って渦巻き始めました。

想像してみてください。昨日あなたはヒムキでシャワルマを作っていましたが、今日あなたはすでに大物で、上級採用担当者です。 候補者を検索して選択するプロセス全体があり、すべてが簡単ではないため、理解する必要があります。 部門長が「X のスペシャリストを見つけてください」と言ったとします。X に「エンジニア」という単語を割り当てれば完了です。 Linux が必要ですか? そうですね、これは間違いなく Linux エンジニアです。DevOps が必要な場合は、DevOps エンジニアです。 空白部分はタイトルだけでなく、テキストも入力する必要があります。 最も簡単な方法は、想像力に応じて、Google から一連のキーワードを入力することです。 DevOps は「Dev」と「Ops」という 42 つの単語で構成されており、開発者と管理者に関連するキーワードをすべて 20 つの山に貼り付ける必要があることを意味します。 このようにして、XNUMX のプログラミング言語の熟練度、および Kubernetes と Swarm の XNUMX 年間の同時使用に関する欠員が生じます。 動作図。

このようにして、特定の「devops」スーパーヒーローの無意味で無慈悲なイメージが人々の心に根付き、誰もがジェンキンスに配備されるように設定され、幸福が訪れるでしょう。 ああ、すべてがとてもシンプルだったらいいのに。 「これは、システム管理者を追い詰める方法でもあります。これは流行の言葉です。キーワードは同じです。彼らは餌を取るべきです。」と人事担当者は考えています。

需要が供給を生み出し、これらのゴミの欠員はすべて、以前と同じようにすべてを実行できるが、自分自身を「devops」と呼ぶことで数倍多くのことができることに気づいた非常識な数のシステム管理者によって埋められました。 SSH 経由でサーバーを一度に XNUMX つずつ手動で構成したのと同じように、引き続き構成を行いますが、これは Devops の実践であると考えられます。 これはある種の複雑な現象であり、古典的な管理者の過小評価と DevOps に関する誇大宣伝に部分的に関係していますが、一般的に、起こったことは起こったのです。

したがって、需要と供給があります。 自分自身を養う悪循環。 これに対して私たちは (DevOops カンファレンスの創設などによって) 戦っているのです。

もちろん、「devops」と改名したシステム管理者以外にも、プロの SRE や Infrastructure-as-Code 開発者など、他の参加者もいます。

DevOps で人々が行うこと (実際)

したがって、DevOps プラクティスを学習して適用することで先を進みたいと考えています。 しかし、これをどのように行うか、どの方向に目を向けるべきでしょうか? もちろん、人気のあるキーワードに盲目的に頼るべきではありません。

仕事があるなら誰かがやるべきだ。 彼らが「DevOps エンジニア」ではないことはすでにわかっていますが、では誰が「DevOps エンジニア」なのでしょうか? これは役職という観点ではなく、特定の仕事分野という観点から定式化する方が正しいと思われます。

まず、DevOps の核心であるプロセスと文化に取り組むことができます。 文化は時間のかかる困難なビジネスであり、伝統的にマネージャーの責任ですが、プログラマーから管理者に至るまで、全員が何らかの形で関与しています。 数か月前 ティム・リスター インタビューで言った:

「文化は組織の中核となる価値観によって決まります。 通常、人々はこれに気づきませんが、私たちは長年コンサルティングの仕事をしているので、それに気づくことに慣れています。 会社に入ると、文字通り数分以内に何が起こっているのかを感じ始めます。 私たちはこれを「風味」と呼んでいます。 たまにはこの香りもいいですね。 場合によっては吐き気を引き起こすこともあります。 (...) 特定の行動の背後にある価値観や信念が理解されるまで、文化を変えることはできません。 行動を観察するのは簡単ですが、信念を探すのは困難です。 DevOps は、物事がいかに複雑化しているかを示す好例にすぎません。」

もちろん、この問題には技術的な部分もあります。 新しいコードが XNUMX か月以内にテストされても、リリースされるのが XNUMX 年後で、すべてを高速化することが物理的に不可能な場合は、適切なプラクティスに従っていない可能性があります。 優れた実践は優れたツールによってサポートされます。 たとえば、Infra Structure-as-Code のアイデアを念頭に置くと、AWS CloudFormation や Terraform から Chef-Ansible-Puppet まで、あらゆるものを使用できます。 これらすべてを理解し、実行できるようにする必要がありますが、これはすでにかなりのエンジニアリング分野です。 原因と結果を混同しないことが重要です。まず SRE の原則に従って作業し、その後でこれらの原則を特定の技術ソリューションの形で実装します。 同時に、SRE は非常に包括的な方法論であり、Jenkins のセットアップ方法については説明しませんが、次の XNUMX つの基本原則について説明します。

• 役割間および部門間のコミュニケーションの向上
• 仕事の不可欠な部分として間違いを受け入れる
• 徐々に変化を加えていく
• ツールやその他の自動化の使用
• 測定できるものはすべて測定する

これは単なる一連のステートメントではなく、特定の 行動ガイド。 たとえば、エラーを受け入れる過程では、リスクを理解し、SLI などを使用してサービスの可用性と非可用性を測定する必要があります (サービスレベルインジケーター) および SLO (サービスレベル目標）、事後分析の書き方を学び、それを書くのが怖くないようにしましょう。

SRE 分野では、ツールの使用は重要ではありますが、成功の一部にすぎません。 私たちは常に技術を開発し、世界で何が起こっているのか、そしてそれを私たちの仕事にどのように応用できるのかを見つめる必要があります。

その結果、現在ではクラウド ネイティブ ソリューションが非常に人気になっています。 現在、Cloud Native Computing Foundation によって定義されているように、Cloud Native テクノロジを使用すると、組織はパブリック クラウド、プライベート クラウド、ハイブリッド クラウドなど、今日の動的な環境でスケーラブルなアプリケーションを開発および実行できます。 例には、コンテナー、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などがあります。 これらの技術はすべて、疎結合システムの弾力性、管理性、および高度な監視性を維持することを可能にします。 優れた自動化により、エンジニアは大きな変更を頻繁に行うことができ、面倒な作業にならずに予測可能な結果が得られます。 これらはすべて、Docker や Kubernetes などのよく知られたツールのスタックによってサポートされています。

このかなり複雑で広範な定義は、この領域が非常に複雑であるという事実によるものです。 一方で、このシステムに新しい変更を非常に簡単に追加する必要があると主張されています。 一方で、疎結合されたサービスがソフトウェア デファインド インフラストラクチャ上に存在し、そこに継続的な CI/CD を使用して配信される、一種のコンテナ化された環境を作成する方法を見つけ出し、これらすべてを中心に DevOps プラクティスを構築するには、さらに多くの作業が必要です。犬を食べるよりも。

これをどうするか

誰もが独自の方法でこれらの問題を解決します。たとえば、悪循環を断ち切るために通常の求人情報を公開することができます。 DevOps や Cloud Native などの言葉の意味を理解して、正しく要点を押さえて使用することができます。 DevOps で開発し、例によって適切なアプローチを実証できます。

私たちはカンファレンスをやっています DevOops 2020 モスクワ、今話した内容をさらに深く掘り下げる機会を提供します。 これには、いくつかのグループのレポートがあります。

• プロセスと文化。
• サイト信頼性エンジニアリング。
• クラウドネイティブ。

行き先をどうやって選ぶか？ ここには微妙な点があります。 一方で、DevOps は対話が重要なので、さまざまなブロックのプレゼンテーションにぜひ参加していただきたいと考えています。 一方、あなたが XNUMX つの特定のタスクに集中するためにカンファレンスに参加した開発マネージャーの場合、誰もあなたを制限しません。明らかに、これはプロセスと文化に関するブロックになります。 カンファレンス終了後 (フィードバック フォームへの記入後) に録画が行われることを忘れないでください。そうすれば、重要度の低いプレゼンテーションを後でいつでも見ることができます。

当然のことながら、カンファレンス自体では一度に XNUMX つのトラックを進めることはできません。そのため、各時間帯にあらゆる好みに合わせたトピックが含まれるようにプログラムを編成します。

残っているのは、あなたが DevOps エンジニアである場合に何をすべきかを理解することだけです。 まず、実際に何をするかを決めてみましょう。 通常、彼らはこの言葉を次のように呼びます。

• インフラストラクチャに取り組む開発者。 SRE とクラウド ネイティブに関するレポート グループが最適です。
• システム管理者。 ここではさらに複雑です。 DevOops はシステム管理に関するものではありません。 幸いなことに、システム管理のテーマに関する優れたカンファレンス、書籍、記事、インターネット上のビデオなどが数多くあります。 一方、文化やプロセスを理解し、クラウド テクノロジーやクラウド ネイティブでの生活の詳細について学ぶという点で自分自身を成長させることに興味がある場合は、ぜひお会いしましょう。 これについて考えてみましょう。あなたは管理を行っていますが、その後、何をしますか? 突然不快な状況に陥ることを避けるために、今すぐ学ぶ必要があります。

別の選択肢もあります。それは、あなたが粘り強く、自分はそうだと主張し続けることです。 特にDevOpsエンジニア それが何を意味するにせよ、他には何もありません。 それでは、皆さんをがっかりさせなければなりません。DevOops は DevOps エンジニアのためのカンファレンスではありません。

からスライド コンスタンティン・ディーナーによるレポート ミュンヘンで

DevOops 2020 モスクワは 29 月 30 ～ XNUMX 日にモスクワで開催され、チケットはすでに入手可能です 公式サイトで購入する.

または、 レポートを提出する 8月XNUMX日まで。 フォームに記入する際は、レポートから最も恩恵を受ける対象読者を選択する必要があることに注意してください (リストの中に驚きが隠されています).

出所： habr.com