DevOpsとは何ですか？DevOpsエンジニアが行うタスク
DevOps (開発オペレーション、または社内でのオペレーション) という用語
豊富なプラクティスの武器により、DevOpsが他のユーザーに近づきますアジャイル手法を使用してIT分野で人気があります。これは、変化する要件に適応できるようにする反復的な設計アプローチです。したがって、DevOpsスペシャリストは製品をより良くしようとし、ビジネスプロセスはより予測可能でより透明になります。また、市場投入までの時間の短縮など、ビジネス指標も改善されます。これは、製品開発の開始から市場投入までの期間です。ソフトウェアとシステムアプローチの作成にかかる時間を伸ばす要因に関する知識により、DevOpsエンジニアは生産を継続的かつ高速にすることができます。わかりやすくするために、自動車を組み立てるためのコンベヤーベルトとの類似点を描くことができます。すべての部品は、組み立て時に完全にフィットするように事前に設計されています。エンジンを設計するエンジニアは、ホイールやブレーキシステムなどと組み合わせてエンジンがどのように機能するかを考えます。 DevOpsも同じことを行います。開発者よりも多くの製品に責任を持ち、すべてのチームが確実にコラボレーションするようにします。
ピンクポニーワールド：ファッション哲学の競争
ただし、すべての企業がDevOpsを必要としているわけではありません。たとえば、デジタル製品の生産に関与していない既存のIT部門がないチームでは、DevOpsの哲学はまったく適用されません。これらの分野には、顧客が相互作用するIT製品にどれだけ満足しているかに直接依存しない利益を持つ企業が含まれます。さらに、それはしばしば中小企業には適していません。この方法論では、確立された多くのビジネスプロセス、さらには企業文化の変更が必要です。中小企業は、プロジェクトの経済性の観点から、そのような変化を単に容認しないかもしれません。
デジタルトランスフォーメーションのファッショナブルな病気はしばしばそのような会社の頭に関係します。無限の最適化を追求して、彼らはビジネスに影響を与える他の要因を忘れています。その結果、企業はお金と効率を失い、最悪の場合、長年にわたって構築されてきたビジネスプロセスを失います。ITの巨人、銀行、大規模な貿易および産業イベントは別の問題です。彼らにとって、DevOpsは非常に有益です。したがって、2017年のアルファ銀行の年次報告書によると、この方法論の実装により、開発と実装を60倍加速することができました。
スタハノフ運動-ワークショップの代わりにマルチマシンオペレーター
もちろん、そのような広範な機能は難しいです従業員1人あたりなので、理想的には、部門の枠を超えたチーム全体がDevOpsに関与します。これには、プロセスおよび製品マネージャー、インフラストラクチャコード開発者、エンジニア、およびその他の多くの役割を担う専門家が含まれます。ただし、ロシアの慣行では、DevOpsスペシャリストは、製品作成にかかる費用を節約するためのファッショナブルな方法になることがよくあります。通常、この状況は、会社のトップマネージャーがデジタルトランスフォーメーションの時期が来たと判断した後に発生します。同社は緊急に新しいスペシャリストを採用するか、既存の開発者とシステム管理者の責任のリストを拡大しています。その結果、採用サービスはDevOpsエンジニアではなく、マルチステーションの従業員に欠員を生み出します。
そのような従業員は個別に義務付けることができますサーバーの構成、ケーブルシステムの敷設、エラーの追跡、データベースとプロジェクトのホスティングの構成など。この例は極端ですが、現実的です。その結果、従業員はすぐに燃え尽き、会社の仕事における方法論の実装は失敗します。 DevOpsスペシャリストを、多数のタスクを同時に処理できるマジシャンとして扱い、システム全体の動作を監視することは、ビジネスに利益をもたらしません。
別の一般的な問題はに関連していますチームを互いに仲良くできない2つのグループに分けます。 IT企業にDevOps部門があり、通常の作業手順を変更できると想像してみてください。ただし、これらのルールは他の開発者を拘束し続けます。もちろん、この場合、仕事の協力や「シームレスさ」について話す必要はありません。 2つのチームが衝突し始め、生産性が低下します。
ホールド中のパウダーバレル：DevOpsは単なるスキルではありません
DevOps部門のタスクの1つは、確立することです会社のさまざまなITスペシャリスト間のコミュニケーション。 DevOpsエンジニアは、テクノロジーとデバッグプロセスを実装するだけでなく、開発チームをビジネスの過程に没頭させる必要があります。責任を共有し、能力の向上を支援します。それにもかかわらず、そのような専門家は、通常、彼らと能力を高める必要がある人々の両方にとって、時間の平凡な不足のために、純粋に技術的なタスクを扱うことがよくあります。
その結果、ファッショナブルに導入されたという事実のために誰もがテクノロジーを使用し、知識とスキルが1つの部門に集中しているため、壊滅的な状況を含む問題のある状況が発生します。 DevOpsエンジニアが作成した新しいソリューションは、さまざまな部門の調整作業なしで、最初に解決すべき問題をいくつでももたらす可能性があります。これは、国内の専門家がよく考えているように、DevOpsスペシャリストが企業文化をゼロから作成する必要があるという意味ではありません。 。リーダー。デジタル制作パイプラインの統一と新しいスキルとコミュニケーションの移転の奨励は、会社のリーダーからもたらされなければなりません。これがないと、DevOpsチームでさえ開発が不十分になり、チームと知識を共有できなくなります。
DevOpsのアウトソーシングも外部の専門家に相談する。最初のケースでは、外部チームはクライアント企業のニーズではなく、市場で引用されている標準的なテクノロジーのセットによって導かれます。クライアントにとって、これは宝くじです。外部委託された従業員は、市場のDevOpsについて漠然とした理解を持っています。その結果、ビジネスプロセスはますます複雑になりますが、これはビジネスに何のメリットももたらしません。多くの場合、企業自体がこのアプローチを推奨しています。たとえば、開発プロセスを変更しないように依頼しています。これがDevOpsの概念そのものに反していることは明らかです。
長く、高価で、問題がある：ロシア語での過酷なDevOps
DevOps哲学をに適用する代わりに国内企業は、すべてのビジネスプロセスに対して、作業速度に影響を与えないツールでの作業を好むことがよくあります。たとえば、結果の1つは「レンガの壁」です。つまり、運用、つまりシステム管理者のチームは孤立したままであり、開発者はアプリケーションをそれらに投げかけるだけです。もちろん、ツールボックスは結果としてまだ改善されています。ただし、根本的な変更は行われておらず、透明性は向上しておらず、ITチームのコラボレーションは改善されていません。
彼らがつまずく別の障害DevOps を実装する際の管理者 - 企業の知識ベースの欠如。 2019 年の DORA レポートによると、社内情報ソースを使用したチームは他のチームよりも 1.73 倍効果的でした。この問題もまた、チームが知識を共有しない、多くのロシア企業の閉鎖的な文化に帰着します。この閉鎖的な性質のため、企業は技術的負債を蓄積し始めます。ツールは古くなり、アーティファクトは削除されず、ドキュメントは更新されません。
生産の安定性、ひいては利益に対するビジネスの客観的なニーズと、時代遅れのテクノロジー ベースおよび技術的負債が相まって、DevOps の使用が失敗に終わります。
これはすべて、長い苦しみの後、DevOpsチームによって提供された新しいソリューションが単に破棄され、プロセスが「ロールバック」されるという事実につながることがよくあります。
各企業には、独自のデジタル変革の道があります。ほとんどの場合、コードの開発方法とデプロイ方法が実際に変わります。これは、DevOpsがまだロシアに存在することを意味します。毎月、この方法論に関連する多くの欠員が市場に出回っています。もう1つのことは、その背後にある専門分野と実践的なタスクの定義が異なることです。ただし、企業は、幽霊のように理想的なITシステムを追いかけるのをやめ、自社のニーズを優先して、流行しているが必ずしも有益ではない哲学を採用することに批判的である必要があります。
また見なさい：
ブラックホールに宇宙があるかもしれません。新しい発見についてお話しします
病気の3日目、ほとんどのCOVID-19患者は嗅覚を失い、そしてしばしば鼻水に苦しむ
調査：海底で発見された1500万トンのマイクロプラスチック