DevOps とは何ですか? DevOps が不要になるのはどんな場合ですか?

DevOps はここ数年で非常に人気のあるトピックになっています。 多くの人がそれに参加することを夢見ていますが、実際に示されているように、多くの場合、給与水準だけが理由です。

DevOps という用語の本質を必ずしも知っているわけではありませんが、履歴書に DevOps を記載する人もいます。 Ansible、GitLab、Jenkins、Terraform などを勉強すれば (好みに応じてリストを続けることができます)、すぐに「開発者」になれると考える人もいます。 もちろん、これは真実ではありません。

ここ数年、私は主にさまざまな企業でDevOpsの導入に携わってきました。 それ以前は、システム管理者から IT ディレクターまで、20 年以上勤務していました。 現在、Playgendary の DevOps リード エンジニア。

DevOpsとは

記事を書こうというアイデアは、「DevOps とは何ですか?」という別の質問の後に生まれました。 それが何であるか、または誰であるかを表す確立された用語はまだありません。 答えの一部はすでにこの中にあります ビデオ。 まず、その要点を取り上げ、その後、私の観察と考えを共有します。

DevOps は、雇用できるスペシャリストではなく、一連のユーティリティでも、エンジニアを含む開発部門でもありません。

DevOps は哲学であり方法論です。

言い換えれば、これは開発者がシステム管理者と積極的に対話するのに役立つ一連のプラクティスです。 つまり、業務プロセスを相互に接続し、統合することです。

DevOps の出現により、スペシャリストの構造と役割は変わりません (開発者がいて、エンジニアがいます) が、相互作用のルールは変わりました。 部門間の境界があいまいになりました。

DevOps の目標は次の XNUMX つの点で説明できます。

• ソフトウェアは定期的に更新する必要があります。
• ソフトウェアは迅速に実行する必要があります。
• ソフトウェアは、便利かつ短時間で導入できる必要があります。

DevOps に単一のツールはありません。 いくつかの製品を構成、提供、検討したからといって、DevOps が社内に導入されたことを意味するわけではありません。 ツールは数多くあり、それらはすべてさまざまな段階で使用されますが、XNUMX つの共通の目的を果たします。

これは DevOps ツールの一部にすぎません

私は 2 年以上、DevOps エンジニアのポジションに就く人々にインタビューしてきましたが、この用語の本質を明確に理解することがいかに重要であるかを認識するようになりました。 私には共有したい具体的な経験、観察、考えが蓄積されています。

インタビューの経験から、次のようなイメージが見えます。 DevOps を役職の XNUMX つと考えている専門家は、通常、同僚と誤解を持っています.

印象的な例がありました。 ある若者が履歴書に気の利いた言葉をたくさん書いて面接にやって来ました。 過去 5 つの仕事では 6 ～ XNUMX か月の経験がありました。 私がスタートアップ XNUMX 社を辞めたのは、それらが「うまくいかなかったから」です。 しかし、XNUMX 番目の会社については、誰も自分のことを理解してくれないと彼は言いました。開発者は Windows でコードを書き、ディレクターはこのコードを通常の Docker に「ラップ」して CI/CD パイプラインに組み込むことを強制します。 その男は、現在の職場や同僚について否定的なことをたくさん言っていました。私はただこう答えたかったのです。「だから、象は売らないんですね。」

それから私は、すべての候補者に対する私のリストの上位にある質問を彼に尋ねました。

— あなた個人にとって、DevOps とはどのような意味ですか?
- 一般的に、または私はそれをどのように認識しますか？

彼の個人的な意見に興味がありました。 彼はこの用語の理論と由来を知っていましたが、それらには強く反対しました。 彼は、DevOps は役職であると信じていました。 ここに彼の問題の根源がある。 同様の意見を持つ他の専門家も同様です。

雇用主は「DevOps の魔法」についてよく聞いており、この「魔法」を創造してくれる人材を探しています。 そして、「DevOps は仕事である」カテゴリーの応募者は、このアプローチでは期待に応えられないことを理解していません。 そして一般に、DevOps がトレンドであり、それに多額のお金を払っているため、履歴書に DevOps と書きました。

DevOps の方法論と哲学

方法論は理論的でも実践的でもあります。 私たちの場合はXNUMX番目です。 上で述べたように、DevOps は、定められた目標を達成するために使用される一連の実践と戦略です。 そして、いずれの場合も、企業のビジネスプロセスに応じて大きく異なる場合があります。 それが良くなったり悪くなったりするわけではありません。

DevOps 方法論は、目標を達成するための手段にすぎません。

次に、DevOps の哲学とは何かについて説明します。 そしてこれがおそらく最も難しい質問です。

まだ正式化されていないため、短く簡潔な答えを定式化することは非常に困難です。 そして、DevOps 哲学の信奉者は実践により熱心に取り組んでいるため、哲学に費やす時間はまったくありません。 ただし、これは非常に重要なプロセスです。 また、それはエンジニアリング活動にも直結します。 専門的な知識分野もあります - テクノロジーの哲学.

私の大学にはそのような学科はなく、90年代に入手できた教材を使ってすべてを独学で勉強しなければなりませんでした。 このトピックは工学教育では任意であるため、回答が形式化されていません。 しかし、DevOps に真剣に没頭している人々は、会社のすべてのプロセスにある種の「精神」または「無意識の包括性」を感じ始めます。

私は自分自身の経験を使って、この哲学の「公準」のいくつかを形式化しようとしました。 結果は次のとおりです。

• DevOps は、知識や活動の別の領域に分離できる独立したものではありません。
• すべての従業員は、活動を計画する際に DevOps 方法論に従う必要があります。
• DevOps は企業内のすべてのプロセスに影響を与えます。
• DevOps は、企業内のあらゆるプロセスの時間コストを削減し、サービスの開発と顧客の快適さを最大限に確保するために存在します。
• DevOps は、現代の言葉で言えば、時間コストを削減し、周囲の IT 製品の品質を向上させることを目的とした、会社の全従業員の積極的な立場です。

私の「仮説」は別の議論のトピックだと思います。 しかし今は、そこに基づいて構築すべきものがあります。

DevOps が行うこと

ここでのキーワードはコミュニケーションです。 コミュニケーションはたくさんありますが、その発信者はまさに同じ DevOps エンジニアでなければなりません。 何故ですか？ なぜなら、これは哲学であり方法論であり、それがあって初めてエンジニアリングの知識になるからです。

私は西側の労働市場について100%の自信を持って語ることはできません。 しかし、私はロシアの DevOps 市場についてはよく知っています。 過去 XNUMX 年半にわたって、何百もの面接に加えて、ロシアの大企業や銀行向けの「DevOps の実装」サービスの何百もの技術プリセールスに参加してきました。

ロシアでは、DevOps はまだ非常に新しいトピックですが、すでにトレンドになっています。 私の知る限り、モスクワだけでも2019年にはそのような専門家が1000人以上不足していた。 そして、雇用主にとって Kubernetes という言葉は、雄牛にとっての赤い布のようなものです。 このツールの支持者は、必要がなく、経済的に利益が得られない場合でも、いつでも使用することができます。 雇用主は、どのような場合に何を使用するのがより適切であるかを必ずしも理解しているわけではありません。また、適切にデプロイした場合、Kubernetes クラスターの維持には、従来のクラスター スキームを使用してアプリケーションをデプロイするよりも 2 ～ 3 倍のコストがかかります。 本当に必要な場所に使用してください。

DevOpsの導入には費用がかかります。 そして、それ自体が正当化されるのではなく、他の分野に経済的利益をもたらす場合にのみ正当化されます。

実際、DevOps エンジニアは先駆者であり、最初にこの方法論を社内に実装し、プロセスを構築する必要があります。 これを成功させるには、スペシャリストはあらゆるレベルの従業員や同僚と常に対話する必要があります。 私がいつも言っているように、掃除婦から CEO に至るまで、すべての会社の従業員が DevOps 実装プロセスに関与する必要があります。 そしてこれは前提条件です。 チームの最年少メンバーが DevOps とは何か、そして特定の組織アクションがなぜ実行されるのかを理解していない場合、実装を成功させることはできません。

また、DevOps エンジニアは、管理リソースを時々使用する必要があります。 たとえば、「環境の抵抗」を克服するため、チームが DevOps ツールや方法論を受け入れる準備ができていない場合です。

開発者はコードとテストのみを作成する必要があります。 これを行うには、プロジェクト インフラストラクチャ全体を展開してローカルでサポートする超強力なラップトップは必要ありません。 たとえば、フロントエンド開発者は、データベース、S3 エミュレーター (minio) などを含むアプリケーションのすべての要素をラップトップ上に保持します。 つまり、彼はこのローカル インフラストラクチャの維持に多くの時間を費やし、そのようなソリューションのすべての問題に独力で取り組んでいます。 フロント用のコードを開発する代わりに。 そのような人は、あらゆる変化に対して非常に抵抗する可能性があります。

しかし、それどころか、新しいツールや手法を喜んで導入し、このプロセスに積極的に参加するチームもあります。 ただし、この場合でも、DevOps エンジニアとチーム間のコミュニケーションはキャンセルされませんでした。

DevOpsが必要ない場合

DevOps が必要ない状況もあります。 これは事実であり、理解して受け入れる必要があります。

まず、これはあらゆる企業 (特に中小企業) に当てはまります。企業の利益が、顧客に情報サービスを提供する IT 製品の有無に直接依存しない場合です。 そして、ここで私たちは会社のウェブサイトについて話しているのではありません。それが静的な「名刺」であれ、動的なニュースブロックなどであれ。

DevOps は、クライアントの満足度や、クライアントが再びあなたに戻りたいという欲求が、クライアントとの対話のためのこれらの情報サービスの可用性、その品質、ターゲットに依存する場合に必要です。

顕著な例は、ある有名な銀行です。 同社には通常のクライアントオフィスはなく、書類のやり取りは郵便や宅配便で行われ、多くの従業員が在宅勤務を行っています。 同社は単なる銀行ではなくなり、開発された DevOps テクノロジーを備えた IT 企業になったと私は思います。

他にも多くの例や講演が、テーマ別の会合や会議の記録に収録されています。 私はそのうちのいくつかを個人的に訪問しました。これは、この方向で開発したい人にとって非常に有益な経験です。 DevOps に関する優れた講義や資料を提供する YouTube チャンネルへのリンクは次のとおりです。

• DevOops
• DevOpsConf
• HighLoad ++
• フラント
• MailRuクラウドソリューション

次に、あなたのビジネスを見て次のことを考えてください。顧客との対話を可能にするために、あなたの会社とその利益は IT 製品にどの程度依存していますか?

あなたの会社が小さな店舗で魚を販売しており、唯一の IT 製品が 1 つの XNUMXC: エンタープライズ構成 (会計および UNF) である場合、DevOps について話すことはほとんど意味がありません。

あなたが大規模な貿易および製造企業で働いている場合 (たとえば、狩猟用ライフルを製造している場合)、それについて考えてみる必要があります。 あなたが率先して、DevOps 導入の見通しを経営陣に伝えることができます。 それと同時に、このプロセスを主導してください。 プロアクティブな立場は、DevOps 哲学の重要な原則の XNUMX つです。

年間売上高の規模や量は、会社に DevOps が必要かどうかを判断する主な基準ではありません。

顧客と直接やり取りしない大企業を想像してみましょう。 たとえば、一部の自動車メーカーや自動車製造会社などです。 今はわかりませんが、私の過去の経験から言えば、長年にわたり、顧客とのやり取りはすべて電子メールと電話で行われていました。

彼らの顧客は自動車ディーラーの限られたリストです。 そして、それぞれにメーカーから専門家が割り当てられます。 すべての内部文書フローは SAP ERP を通じて行われます。 社内従業員は基本的に情報システムの顧客です。 ただし、この IS は、クラスター システムを管理する従来の手段によって制御されます。 これにより、DevOps プラクティスを使用する可能性が排除されます。

したがって、結論としては、記事の冒頭の方法論の目標を思い出せば、そのような企業にとって、DevOps の実装はそれほど重要なものではありません。 しかし、私は彼らが現在いくつかの DevOps ツールを使用している可能性を排除しません。

一方で、DevOps の方法論、哲学、実践、ツールを使用してソフトウェアを開発している中小企業も数多くあります。 そして、DevOps の実装コストは、ソフトウェア市場で効果的に競争できるコストであると信じています。 そのような企業の例をご覧いただけます ここで.

DevOps が必要かどうかを理解するための主な基準は、IT 製品が会社と顧客にとってどのような価値があるかです。

会社の利益を生み出す主な製品がソフトウェアの場合、DevOps が必要です。 また、他の製品を使用して実際のお金を稼ぐ場合、それはそれほど重要ではありません。 これには、オンライン ストアやゲームを備えたモバイル アプリケーションも含まれます。

どのようなゲームも、プレイヤーからの直接または間接的な資金提供のおかげで存在します。 Playgendary では、200 名を超える人々がその制作に直接関わって無料のモバイル ゲームを開発しています。 DevOps をどのように使用するのでしょうか?

はい、上で説明したのとまったく同じです。 私は常に開発者やテスターとコミュニケーションを取り、DevOps の方法論とツールに関する従業員向けの社内トレーニングを実施しています。

現在、Unity ですべてのアセンブリ パイプラインを実行し、その後 App Store や Play Market にデプロイするための CI/CD パイプライン ツールとして Jenkins を積極的に使用しています。 古典的なツールキットの詳細:

• Asana - プロジェクト管理用。 Jenkins との統合が構成されました。
• Google Meet - ビデオ会議用。
• Slack - コミュニケーションと、Jenkins からの通知を含むさまざまなアラート用。
• Atlassian Confluence - ドキュメントとグループ作業用。

当面の計画には、SonarQube を使用した静的コード分析の導入と、継続的インテグレーション段階での Selenium を使用した自動 UI テストの実施が含まれます。

代わりに、結論の

最後に次の考えを述べたいと思います。高度な資格を持つ DevOps エンジニアになるには、人々とライブでコミュニケーションする方法を学ぶことが不可欠です。

DevOps エンジニアはチームプレーヤーです。 何もありません。 同僚とのコミュニケーションにおける主導権は、何らかの状況の影響下ではなく、彼自身によってもたらされるべきです。 DevOps スペシャリストは、チームにとって最適なソリューションを確認し、提案する必要があります。

そして、確かに、どのようなソリューションの実装にも多くの議論が必要であり、最終的には完全に変わってしまう可能性があります。 独立して開発し、自分のアイデアを提案して実行するこのような人材は、チームと雇用主の両方にとって価値が高まります。 最終的には、月々の報酬額や追加ボーナスの形で反映されます。

出所： habr.com