管理者、DevOps、企業内の終わりのない混乱と DevOps 変革について

IT企業が2019年に成功するには何が必要でしょうか?カンファレンスや交流会の講師は、常人には理解できないような大きな言葉をたくさん言います。デプロイメント時間、マイクロサービス、モノリスの放棄、DevOps 変革などを巡る闘争。言葉の美しさを捨ててロシア語で直接話せば、すべては単純な命題に帰着します。それは、高品質の製品を作り、チームにとって快適にそれを行うということです。

後者は非常に重要になっています。ビジネスは最終的に、快適な開発プロセスにより生産性が向上し、すべてがデバッグされて時計のように機能すれば、危機的な状況である程度の対処の余地が得られるという結論に達しました。かつて、この作戦のために、ある賢い人がバックアップを考え出しましたが、業界は発展しており、私たちは DevOps エンジニアにたどり着きました。DevOps エンジニアは、開発と外部インフラストラクチャの間の相互作用のプロセスを適切なものに変える人々です。シャーマニズムとは関係ありません。

この「モジュール式」のストーリー全体は素晴らしいのですが...たまたま管理者の一部が突然 DevOps と呼ばれるようになり、DevOps エンジニア自身も少なくともテレパシーと透視のスキルを要求され始めました。

インフラストラクチャの提供に関する現代の問題について話す前に、この用語の意味を定義しましょう。現時点では、状況はこの概念の二重性に到達する形で発展しています。つまり、インフラストラクチャーは条件付きで外部にも、条件付きで内部にもなり得るということです。

外部インフラストラクチャとは、チームが開発しているサービスや製品の機能を保証するすべてのものを意味します。これらは、アプリケーションまたは Web サイトのサーバー、ホスティング、および製品の機能を保証するその他のサービスです。

内部インフラストラクチャには、開発チーム自体と他の従業員 (通常は多数の従業員) が使用するサービスと機器が含まれます。これらは、コード ストレージ システムの内部サーバー、ローカルに配置されたタスク マネージャー、および企業イントラネット内に存在するすべて、すべて、すべてです。

システム管理者は会社で何をする人ですか?この企業イントラネットを管理する作業に加えて、オフィス機器の操作性を確保するという経済的問題の負担も負うことがよくあります。管理者は、新しいシステム ユニットやすぐに使用できる予備のラップトップを奥の部屋から素早く引きずり出し、新しいキーボードを差し出し、オフィス内を四つん這いでイーサネット ケーブルを伸ばすのと同じ人です。管理者は、内部および外部サーバーのローカル所有者および支配者であるだけでなく、ビジネス幹部でもあります。はい、一部の管理者はハードウェアなしでシステム プレーンでのみ作業できます。これらは、「インフラストラクチャ システム管理者」という別のサブクラスに分離する必要があります。また、オフィス機器の保守のみを専門とする企業もあり、幸いなことに、従業員が 100 名を超える会社であれば、仕事に終わりはありません。しかし、どちらも DevOps ではありません。

DevOpsとは何ですか? Devops は、ソフトウェア開発と外部インフラストラクチャの相互作用について話す人たちです。より正確に言うと、最新の Devops は、更新を FTP にアップロードするだけの管理者がこれまで関与していたよりもはるかに深い開発および展開プロセスに関与しています。現在、DevOps エンジニアの重要なタスクの 1 つは、開発チームと製品インフラストラクチャ間の対話プロセスを快適かつ効果的に構築することです。ロールバックおよび展開システムの展開を担当するのはこれらの人々であり、開発者の負担の一部を軽減し、非常に重要なタスクに可能な限り集中するのはこれらの人々です。同時に、devops は新しいケーブルを配線したり、バックルームから新しいラップトップを発行したりすることはありません (c) KO

キャッチは何ですか？

「DevOps とは何ですか?」という質問に対して現場の従業員の半数は、「つまり、これは管理者です。...」というようなことを答え始め、さらに本文に記載されています。そうです、かつて、DevOps エンジニアという職業がサービス保守の点で最も才能のある管理者から生まれてきたばかりの頃、両者の違いは誰にとっても明らかではありませんでした。しかし、チーム内の DevOps と管理者の機能が根本的に異なっている現在、それらを混同したり、同一視したりすることさえ受け入れられません。

しかし、これはビジネスにとって何を意味するのでしょうか?

雇用、それがすべてです。

「システム管理者」の求人を募集すると、そこに記載されている要件は「開発や顧客とのやり取り」「CI/CD提供体制」「社内サーバーや設備の保守」「社内システムの管理」などです。の上;雇用主がナンセンスなことを言っているのは理解できます。問題は、欠員の役職名を「システム管理者」ではなく「DevOps エンジニア」にする必要があり、この役職を変更すると、すべてが適切になることです。

しかし、このような求人情報を読んだとき、人はどのような印象を受けるでしょうか。同社は、バージョン管理と監視システムの両方を展開し、歯でねじり取るような複数のマシンのオペレーターを探していると...

しかし、労働市場における薬物中毒の度合いを増やさないためには、欠員を適切な名前で呼び、DevOps エンジニアとシステム管理者が 2 つの異なる存在であることを明確に理解するだけで十分です。しかし、候補者に可能な限り幅広い要件のリストを提示したいという一部の雇用主の抑えがたい願望は、「古典的な」システム管理者が自分の周囲で何が起こっているのかを理解しなくなるという事実につながります。なんだ、この職業は変異していて時代に乗り遅れているのか？

いやいや、もう一回いいえ。企業の内部サーバーを管理したり、L2/L3 サポート職に就いて他の従業員を支援したりするインフラストラクチャ管理者は、今も存在しており、今後も存在しなくなる予定はありません。

これらのスペシャリストは DevOps エンジニアになれるでしょうか?もちろんできます。実際、これはシステム管理スキルを必要とする関連環境ですが、これに加えて、監視、配信システム、そして一般的には開発およびテスト チームとの緊密なやり取りが追加されます。

別の DevOps 問題

実際、すべては雇用と管理者と開発者の間での絶え間ない混乱だけに限定されません。ある時点で、企業はアップデートの配信と、開発チームと最終インフラストラクチャとのやり取りという問題に直面しました。

おそらくそれは、目を輝かせたおじさんが何かのカンファレンスのステージに立ってこう言ったときのことだろう。彼らはあなたの問題をすべて解決してくれるでしょう。」 - そして、DevOps プラクティスを導入した後の会社での生活がいかに充実しているかを語り始めました。

ただし、すべてを正常に機能させるためには、DevOps エンジニアを雇用するだけでは十分ではありません。会社は完全な DevOps 変革を経験する必要があります。つまり、DevOps の役割と機能が製品開発およびテスト チームの側でも明確に理解されている必要があります。このテーマに関して、いくつかの場所で起こっているすべての残虐行為を完全に説明する「素晴らしい」物語があります。

状況。 DevOps では、バージョン ロールバック システムがどのように機能するかを詳しく検討することなく、バージョン ロールバック システムをデプロイする必要があります。ユーザー システム内に、名、姓、パスワードの個別のフィールドがあると仮定します。製品の新しいバージョンがリリースされますが、開発者にとって「ロールバック」はすべてを修正してくれる魔法の杖にすぎず、それがどのように機能するのかさえ知りません。したがって、たとえば、次のパッチでは、開発者は姓と名フィールドを結合し、実稼働環境に展開しましたが、何らかの理由でバージョンが遅くなりました。何が起こっていますか？管理者が Devops にやって来て、「スイッチを押してください!」と言い、つまり、前のバージョンにロールバックするように求めます。 DevOpsは何をするのですか?以前のバージョンにロールバックされますが、開発者はこのロールバックがどのように行われたかを知りたくなかったため、データベースもロールバックする必要があることを Devops チームに誰も伝えませんでした。その結果、すべてがクラッシュし、古いバージョンが新しいデータベースのフィールドで動作しないため、Web サイトが遅くなる代わりに、ユーザーには「500」エラーが表示されます。 Devops はこれについて知りません。開発者は沈黙している。経営陣は神経と資金を失い始め、バックアップを思い出し、「少なくとも何かがうまくいくように」バックアップからロールバックすることを申し出ました。その結果、ユーザーは一定期間にわたってすべてのデータを失います。

もちろん、問題は「適切なロールバック システムを作成しなかった」devops に送られ、この話のヘラジカが開発者であることなど誰も気にしません。

結論は簡単です。DevOps 自体に対する通常のアプローチがなければ、それはほとんど役に立ちません。
覚えておくべき重要な点は、DevOps エンジニアは魔術師ではないため、開発との質の高いコミュニケーションと双方向の対話がなければ、自分のタスクに対処することはできません。開発者を「問題」を抱えたまま放置したり、「開発者に干渉するな、彼らの仕事はコードを書くことだ」と命令したりして、重要な瞬間にすべてがうまくいくことを期待することはできません。そういうわけではありません。

本質的に、DevOps は管理とテクノロジーの境界にあるコンピテンシーです。さらに、このカクテルには管理よりもテクノロジーが必要であることは明らかではありません。本当により高速で効率的な開発プロセスを構築したい場合は、devops チームを信頼する必要があります。彼は適切なツールを知っており、同様のプロジェクトを実装しており、その方法を知っています。彼を助け、アドバイスに耳を傾け、彼をある種の自律的な単位に孤立させようとしないでください。管理者が自分で作業できる場合、この場合 DevOps は役に立ちません。あなた自身がこの支援を受け入れたくない場合、管理者はあなたの改善を支援することはできません。

最後にもう 1 つ、インフラストラクチャ管理者を攻撃するのはやめてください。彼らには独自の非常に重要な仕事の最前線があります。はい、管理者が DevOps エンジニアになることはできますが、これは圧力を受けてではなく、本人の要求によって行われる必要があります。システム管理者がシステム管理者であり続けたいという事実には何の問題もありません。これは彼の別の職業であり、彼の権利です。プロフェッショナルとしての変革を遂げたいのであれば、技術的なスキルだけでなく、マネジメント的なスキルも構築する必要があることを決して忘れてはなりません。おそらく、これらすべての人々をまとめ、同じ言語でコミュニケーションできるように教えるのは、リーダーとしてのあなたにかかっているでしょう。

出所： habr.com