DevOpsとは何ですか?

現時点では、これは市場でほぼ最も高価なポジションです。 「DevOps」エンジニアをめぐる大騒ぎは想像できる限界を超えており、上級 DevOps エンジニアの場合はさらにひどいです。
私は統合および自動化部門の責任者として働いています。英語で解読すると、DevOps Manager となります。 英語の記録が私たちの日常の活動を反映しているとは考えにくいですが、この場合はロシア語の方が正確です。 私の活動の性質上、チームの将来のメンバーにインタビューする必要があるのは当然であり、過去 50 年間で約 XNUMX 人が私を通過し、同じ数が従業員との事前審査で除外されました。

DevOps というラベルの背後には、さまざまな種類のエンジニアの非常に大きな層が隠れているため、私たちはまだ同僚を探しています。

以下に書かれていることはすべて私の個人的な意見であり、それに同意する必要はありませんが、このトピックに対するあなたの態度に彩りを与えることは認めます。 支持されなくなるリスクがあるにもかかわらず、私が自分の意見を発表するのは、それがあるべき場所だと信じているからです。

DevOps エンジニアが誰であるかについて企業はさまざまな理解を持っており、人材を迅速に雇用するために、全員にこのレッテルを貼り付けています。 企業はこれらの人々に非現実的な報酬を支払う用意があり、ほとんどの場合、彼らのためにツール管理者を雇っているため、状況は非常に奇妙です。

では、DevOps エンジニアとは誰でしょうか?

その登場の歴史から始めましょう - 開発オペレーションは、予想された結果として、製品生産の速度を向上させるために、小規模チームでの対話を最適化するための新たなステップとして登場しました。 その目的は、製品環境を管理する手順とアプローチの知識を備えた開発チームを強化することでした。 言い換えれば、開発者は、製品が特定の条件でどのように動作するかを理解し、製品を展開する方法、パフォーマンスを向上させるために環境のどの特性を調整できるかを理解する必要があります。 そこで、しばらくの間、DevOps アプローチを採用する開発者が現れました。 DevOps 開発者は、アクティビティと運用環境のパフォーマンスを簡素化するために、ビルドおよびパッケージ化のスクリプトを作成しました。 しかし、ソリューション アーキテクチャの複雑さと、時間の経過とともにインフラストラクチャ コンポーネントの相互影響により、環境のパフォーマンスが低下し始めました。反復するたびに、特定のコンポーネントについてのより深い理解が必要になり、追加のコンポーネントによる開発者の生産性が低下しました。コンポーネントを理解し、特定のタスクに合わせてシステムを調整するコスト。 開発者自身のコストが増大し、それに伴って製品のコストも上昇し、チーム内の新しい開発者に対する要件が急激に上昇しました。なぜなら、彼らは開発の「スター」の責任もカバーする必要があり、当然のことながら「スター」の数は減りました。そして利用できるものは少なくなります。 私の経験では、オペレーティング システム カーネルによるパケット処理の詳細、パケット ルーティング ルール、およびホスト セキュリティの側面に興味を持っている開発者はほとんどいないことも注目に値します。 論理的なステップは、これに精通した管理者を引き付け、同様の責任を彼に割り当てることでした。これにより、彼の経験のおかげで、「スター」開発のコストと比較してより低いコストで同じ指標を達成することが可能になりました。 このような管理者はチームに配置され、彼の主なタスクは、特定のチームのルールに従って、この特定のチームにリソースが割り当てられたテスト環境と運用環境を管理することでした。 実際、これが大多数の人の心の中に DevOps が登場した経緯です。

時間の経過とともに、これらのシステム管理者は、開発分野におけるこの特定のチームのニーズ、開発者とテスターの作業を楽にする方法、金曜日に徹夜せずにアップデートを展開する方法を理解し始めました。オフィスで展開エラーを修正します。 時が経ち、今では「スター」は開発者が何を求めているかを理解するシステム管理者になりました。 影響を最小限に抑えるために、管理ユーティリティが登場し始めました。OS レベルを分離する古くて信頼性の高い方法を誰もが思い出し、セキュリティ、ネットワーク部分の管理、およびホスト構成の要件を最小限に抑えることが可能になりました。その結果、新しい「スター」の要件が軽減されます。

「素晴らしい」ものが現れました、それはdockerです。 なぜ素晴らしいのでしょうか？ はい。chroot またはjail、および OpenVZ で分離を作成するには、OS に関する重要な知識が必要でした。対照的に、このユーティリティを使用すると、必要なものすべてを内部に用意して、特定のホスト上に分離されたアプリケーション環境を簡単に作成できます。開発の手綱が再び管理され、システム管理者は XNUMX 台のホストだけで管理できるため、そのセキュリティと高可用性が確保され、論理的に簡素化されます。 しかし、進歩は止まらず、システムは再びますます複雑になり、コンポーネントがますます増え、XNUMX つのホストではシステムのニーズを満たせなくなり、クラスターを構築する必要が生じ、私たちは再びシステム管理者の元に戻りつつあります。これらのシステムを構築できるようになります。

サイクルを重ねるごとに、開発や管理を簡素化するさまざまなシステムが登場し、標準プロセスから逸脱する必要があるまでは使いやすいオーケストレーション システムが登場します。 マイクロサービス アーキテクチャも、上記のすべてを簡素化し、関係を減らし、管理を容易にすることを目的として登場しました。 私の経験では、完全なマイクロサービス アーキテクチャは見つかりませんでした。マイクロサービスの 50 ～ 50 パーセント、つまりブラック ボックスが入ってきて、処理されて出てきました。残りの 50 は引き裂かれたモノリスであり、サービスは他のサービスから分離して動作することができません。コンポーネント。 これらすべてにより、開発者と管理者の両方の知識レベルに再び制限が課されました。

特定のリソースに関する専門知識のレベルにおける同様の「変動」は、今日まで続いています。 しかし、少し話がそれましたが、強調すべき点はたくさんあります。

ビルドエンジニア/リリースエンジニア

ソフトウェアのビルド プロセスとリリースを標準化する手段として登場した、非常に専門性の高いエンジニア。 アジャイルを広く導入する過程で、アジャイルの需要がなくなったかのように思われがちですが、決してそうではありません。 この専門化は、産業規模でのソフトウェアの組み立てと配信を標準化する手段として現れました。 すべての会社製品の標準技術を使用します。 DevOps の出現により、開発者はその機能を部分的に失いました。これは、開発者が製品の提供の準備を始めたためであり、変化するインフラストラクチャと、品質に関係なくできるだけ早く提供するアプローチを考慮すると、時間の経過とともに、開発者は機能を部分的に失いました。品質基準を遵守すると必然的に納品が遅くなるため、変化を阻止する役割を果たします。 そのため、徐々に、ビルド/リリース エンジニアの機能の一部がシステム管理者の肩に移行しました。

オペレーションが違いすぎます

私たちは、広範な責任の存在と資格のある人材の不足により、雨後の筍のように、厳格な専門化へと私たちを後押しし、さまざまな業務が発生します。

• TechOps - enikey システム管理者、別名ヘルプデスク エンジニア
• LiveOps - 主に運用環境を担当するシステム管理者
• CloudOps - パブリック クラウド Azure、AWS、GCP などを専門とするシステム管理者。
• PlatOps/InfraOps/SysOps - インフラストラクチャ システム管理者。
• NetOps - ネットワーク管理者
• SecOps - 情報セキュリティを専門とするシステム管理者 - PCI コンプライアンス、CIS コンプライアンス、パッチ適用など。

DevOps とは、(理論上は) 開発サイクルのすべてのプロセス (開発、テスト) を直接理解し、製品アーキテクチャを理解し、セキュリティ リスクを評価でき、アプローチと自動化ツールに少なくとも高度に精通している人物です。これに加えて、レベルは前処理と後処理、製品リリースのサポートも理解します。 運用と開発の両方の擁護者として行動できる人材。これにより、これら XNUMX つの柱の間で良好な協力が可能になります。 チームによる作業の計画と顧客の期待の管理のプロセスを理解します。

この種の仕事と責任を遂行するには、この担当者は開発およびテストのプロセスだけでなく、製品インフラストラクチャの管理やリソース計画も管理する手段を持っている必要があります。 この理解における DevOps は、IT、研究開発、さらには PMO のいずれかに位置付けられるものではなく、これらすべての領域、つまり企業のテクニカル ディレクター、最高技術責任者に影響力を持たなければなりません。

あなたの会社でもこれは本当ですか？ - 私は疑う。 ほとんどの場合、これは IT または研究開発のいずれかです。

資金が不足し、これら XNUMX つの活動領域の少なくとも XNUMX つに影響を与える能力が不足すると、問題の重みが、静的なコードに基づく「ダーティ」コードに関連したリリースに対する技術的制限の適用など、これらの変更をより適用しやすい方向に移すことになります。分析システム。 つまり、PMO が機能のリリースに厳格な期限を設定すると、R&D はその期限内に高品質の結果を生み出すことができず、できる限り最善を尽くして結果を出し、リファクタリングは後回しになり、IT 関連の DevOps が技術的手段でリリースをブロックします。 。 責任ある従業員の場合、状況を変える権限の欠如は、特に従業員が間違いを理解し、それを修正する方法を理解している場合、自分が影響を及ぼせないものに対する過大な責任の発現につながります - 「至福は無知です」その結果、従業員の燃え尽き症候群や喪失につながります。

DevOpsリソース市場

さまざまな企業の DevOps ポジションの求人をいくつか見てみましょう。

次のような場合には、いつでもお会いできます。

1. あなたは Zabbix を所有しており、Prometheus が何であるかを知っています。
2. イプタブルス。
3. BASH博士課程の学生。
4. アンシブル教授。
5. Linux の第一人者。
6. デバッグの使用方法を理解し、開発者と一緒にアプリケーションの問題を発見する方法 (php/java/python)。
7. ルーティングによってヒステリックになることはありません。
8. システムのセキュリティには十分な注意を払ってください。
9. 「あらゆるもの」をバックアップし、この「あらゆるもの」を正常に復元します。
10. あなたは、最小値から最大値を引き出すようにシステムを構成する方法を知っています。
11. Postgres と MySQL で就寝前にレプリケーションをセットアップします。
12. CI/CD の設定と調整は、朝食/昼食/夕食と同じように必要です。
13. AWS の使用経験がある。
14. 会社とともに開発する準備ができています。

だから：

• 1 から 6 - システム管理者
• 7 - システム管理者にも適した少しのネットワーク管理、中級レベル
• 8 - 多少のセキュリティ。中級レベルのシステム管理者には必須です。
• 9-11 – 中間システム管理者
• 12 — 割り当てられたタスクに応じて、中間システム管理者またはビルド エンジニアのいずれか
• 13 - 仮想化 - 中間システム管理者、いわゆる CloudOps 。資金を効率的に使用し、メンテナンスの負荷を軽減するための、特定のホスティング サイトのサービスに関する高度な知識

この欠員を要約すると、中級/上級システム管理者であれば十分であると言えます。

ちなみに、Linux/Windows では管理者を強く分けるべきではありません。 もちろん、これら XNUMX つの世界のサービスやシステムが異なることは理解していますが、すべての基本は同じであり、自尊心のある管理者であればどちらの世界にも精通しており、たとえ詳しくなくても、有能な管理者であれば、これに慣れるのは難しくありません。

別の空席について考えてみましょう。

1. 高負荷システムの構築経験。
2. Linux OS、一般的なシステム ソフトウェア、Web スタック (Nginx、PHP/Python、HAProxy、MySQL/PostgreSQL、Memcached、Redis、RabbitMQ、ELK) に関する優れた知識。
3. 仮想化システム (KVM、VMWare、LXC/Docker) の経験。
4. スクリプト言語の熟練度。
5. ネットワークプロトコルネットワークの動作原理を理解する。
6. フォールトトレラントなシステム構築の原則を理解する。
7. 独立性と自発性。

を見ようよ：

• 1 – 上級システム管理者
• 2 - このスタックに込められた意味に応じて - 中級/上級システム管理者
• 3 - 職務経験 (以下を含む) を意味する場合があります - 「クラスターは起動しませんでしたが、仮想マシンを作成して管理しました。Docker ホストは XNUMX つあり、コンテナーへのアクセスは利用できませんでした。」 - 中間システム管理者
• 4 - ジュニア システム管理者 - はい、言語に関係なく、基本的な自動化スクリプトの作成方法を知らない管理者であり、管理者 - enikey ではありません。
• 5 - 中間システム管理者
• 6 – 上級システム管理者

要約 - 中級/上級システム管理者

もう一つ:

1. Devops の経験。
2. XNUMX つ以上の製品を使用して CI/CD プロセスを作成した経験。 Gitlab CI は利点になります。
3. コンテナと仮想化の操作。 docker を使用した場合は問題ありませんが、k8s を使用した場合は問題ありません。
4. アジャイルチームで働いた経験。
5. あらゆるプログラミング言語の知識。

様子を見よう：

• 1 - うーん...どういう意味ですか? =) おそらく彼ら自身も、その背後に何が隠されているかを知りません。
• 2 - ビルドエンジニア
• 3 - 中間システム管理者
• 4 - ソフト スキル。アジャイルも都合の良いように解釈されるものですが、今は考慮しません。
• 5 - 冗長すぎる - スクリプト言語またはコンパイル言語である可能性があります。 学校でPascalやBasicで書くのは合うのかな？ =)

また、システム管理者がなぜこの点をカバーするのかについての理解を強化するために、点 3 についてメモを残したいと思います。 Kubernetes は単なるオーケストレーションであり、ネットワーク ドライバーと仮想化/分離ホストへの直接コマンドをいくつかのコマンドでラップし、それらとの通信を抽象化できるようにするツールです。それだけです。 たとえば、「フレームワークの構築」Make を考えてみましょう。ちなみに、私はこれをフレームワークとは考えていません。 はい、私は Make を必要なところとそうでないところに押し込むという流行について知っています。たとえば、Maven を Make でラップするなど、真剣に考えますか?
基本的に、Make はシェルの単なるラッパーであり、k8s と同様に、コンパイル、リンク、およびコンパイル環境コマンドを簡素化します。

以前、OpenStack 上の作業で k8s を使用している人にインタビューしたことがあります。彼は、その上にサービスをどのようにデプロイしたかについて話していました。しかし、OpenStack について尋ねると、OpenStack はシステムによって生成されるだけでなく、管理されていることが判明しました。管理者。 OpenStack をインストールした人は、使用しているプラ​​ットフォームに関係なく、k8s を使用できないと本当に思いますか? =)
この応募者は実際には DevOps ではなく、システム管理者であり、より正確には Kubernetes 管理者です。

もう一度要約してみましょう - 中級/上級システム管理者であれば十分です。

重さは何グラムですか

表示されている欠員に対する提案給与の範囲は 90 ～ 200 です。
ここで、システム管理者と DevOps エンジニアの金銭的報酬を比較してみたいと思います。

原則として、物事を単純化するために、職務経験に基づいて成績を分散できますが、これは正確ではありませんが、この記事の目的では十分です。

経験：

1. 3歳まで - ジュニア
2. 6歳まで – 年中
3. 6歳以上 - シニア

従業員検索サイトでは次のことが提供されます。
システム管理者:

1. ジュニア - 2 年 - 50k こすります。
2. 中年 - 5年 - 70万摩擦。
3. シニア - 11 歳 - 100k 摩擦。

DevOps エンジニア:

1. ジュニア - 2 年 - 100k こすります。
2. 中年 - 3年 - 160k摩擦。
3. シニア - 6 歳 - 220k 摩擦。

「DevOps」の経験によれば、少なくとも何らかの形で SDLC に影響を与える経験が使用されました。

上記のことから、実際には企業は DevOps を必要とせず、管理者を雇用することで当初計画したコストの少なくとも 50% を節約でき、さらに、求める人材の責任をより明確に定義できることがわかります。そしてニーズをより早く満たします。 また、責任を明確に分割することで、人材の要件を軽減できるだけでなく、重複がないためチーム内により好ましい雰囲気を作り出すことができることも忘れてはなりません。 求人の大多数はユーティリティや DevOps のラベルでいっぱいですが、それらは DevOps エンジニアの実際の要件に基づいておらず、ツール管理者に対する要求のみに基づいています。

DevOps エンジニアのトレーニング プロセスも、特定の作業やユーティリティのセットにのみ限定されており、プロセスとその依存関係についての一般的な理解を提供しません。 Terraform を使用し、このクラスターの Fluentd サイドカーとロギング システムの AWS ELK スタックを組み合わせて、コンソールで 10 つのコマンドを使用するだけで XNUMX 分で AWS EKS をデプロイできるのは確かに良いことですが、コンソールで XNUMX つのコマンドを使用するだけで済みます。ログの処理自体の原則と、ログが何に必要であるか、ログに関するメトリクスを収集してサービスの低下を追跡する方法が分からない場合、ユーティリティの使用方法を知っているのは依然として同じ暗号になります。

しかし、需要が供給を生み出すため、DevOps ポジションの市場は非常に過熱しており、要件が実際の役割に対応していないにもかかわらず、システム管理者がより多くの収入を得られるだけになっています。

それで、彼らは誰ですか？ DevOps ですか、それとも貪欲なシステム管理者ですか? =)

さらに生きる方法は？

雇用主は要件をより正確に策定し、レッテルを貼り付けるのではなく、必要とされる人材を正確に探す必要があります。 DevOps が何をするのか知りません。その場合、DevOps は必要ありません。

労働者 - 学びましょう。 常に知識を向上させ、プロセスの全体像を把握し、目標への道筋をたどります。 あなたはなりたい人になれる、ただ努力するだけです。

出所： habr.com