こんにちは、Habr！
今日は珍しい資料があります。 チュートリアルを公開したり、新しいフレームワークを検討したりするのではなく、発言できる同僚にフロアを提供するだけです。
著者の意見は、会社や他の同僚の立場を反映していない場合があります。
会う-構成マネージャー/ DevOpsのAlexander Efimov
私には、一流のシステム管理者としてプログラマになることを夢見ている友人がいます。 彼によると、彼は既存のものを使用したくないので、作成したいと考えています...あまり良いソフトウェアではありません。 ある意味では、私は彼を理解しています。「純粋な」創造性は確かにクールです。 しかし、実際に何がどのように発生するかを把握しましょう。
私はかなり長い間、献身者として働いてきました。 私が参加する名誉を与えられたプロジェクトは、必然的に次の段階を経ました。
- 無秩序。 各開発者は、必要なすべてを実行し、コミットします（いずれにしても、これは外部のオブザーバーに見られます）。 スプリントの終わりに、「最も有罪」は、彼のマシンおよび（理論的には）一部のサーバーで作業している特定のcadavreのすべての成果を収集します。 その後、痛みと地獄の輪を経て、サーバーに導入され、そこで何らかの形で機能します。
- 「ステージングで動作します。」 最後に、顧客は1つのステージングサーバーにお金を割り当てました。 現在、作業プロトタイプのアセンブリに関する地獄もステージングのために繰り返されています。 この状況の不便な点は、データベース、キューサーバー、キャッシュサーバーなどの「バインド」全体がローカルホストに存在することです。 つまり、同じ開発者マシンをリモートでのみ入手します。 機密性の高い接続パラメーターの一部をハードコーディングするなど、すべての結論が出されます。
- 管理者が必要です。 この段階では、以前に作成されたすべてのものはすでに管理不能になっており、ステージングは不良であり、生産は更新されていません。 次に、DevOpsと呼ばれる誰かが入って、混乱を
掻き集め、個人的なペンダントに動機付けの手段を与え始めます。 まったく来たら。
そこで、最も重要なこと、つまり開発と運用の対立に注目します。 すでにすべての側面から検討および議論されており、簡単に次のようになります。
次に、この矛盾の解決策が記事のタイトルに記載されている理由を説明します。
創造性vs. 注文する
ソフトウェア開発は創造的なプロセスです。 創造的なプロセスを管理するには、柔軟性と干渉しない能力が必要です。 実際、アジャイル方法論はこれから正確に成長します。その目標は、カオスを制御し、その順序を最小限にすることです。 私の意見では、これは本当に良いことです。適切なアジャイルがあれば、良い製品を手に入れることができます。
それどころか、運用には、システムのすべての要素、構成、不安定性の可能性のあるポイントなどに関する完全に明確な知識が必要です。ITILおよび類似の方法論がここで支配的です。
開発者は、原則として、すべてを戦略的に整理するために研ぎ澄まされていません-それは彼らのプロフィールではありません。 さらに、ほとんどの場合、大きな結果につながる可能性のある小さなことを考えないでください。
人生からの例。 デフォルトで、ログファイルがアプリケーションディレクトリにあるとします。 開発者にとっては便利です。どこを見るべきかを常に知っています。 開発者は、アプリケーションをテストサーバーにデプロイします。 3日後、サーバーディスクがいっぱいになり、キューサーバーが低下し、データベースがログに書き込み先がないことを叫んでいます。 何も機能せず、3時間後のデモで、すべてがショック状態です。 そしてその理由は簡単です。ログを特別なセクションに転送したり、ローテーションを設定したりする必要がありました。 初心者の管理者/ DevOpsでさえ、なぜこれが必要なのか不思議に思うことなく、マシンでこれを処理します。 ただ「注文のために」。
既存のソリューションを使用する機能
私が最初にソフトウェア会社（社内用）で働き始めたとき、私は彼らの監視システムに驚きました。 彼女は自作で、信じられないほどバギーでした。 2009年に インフラ部門は、Zabbixを実装する必要があることを当局に納得させるために多くのことを行わなければなりませんでした。
さまざまな企業で何度か同じような問題に直面しましたが、どこでも同じことでした。「他人のことを理解するよりも自分で書く方が簡単です」。 後で、この考え方の理由に気付きました。開発者が開発するのは本当に簡単です。 この管理者は、複数のシステムを1つのシステムに「スニッフィング」して設定を掘り下げることに慣れています。 時にはパラメーターを介して、時にはスクリプトによって、時には両方によって。 開発者は、ドキュメントや構成を理解するよりも、100行のコードを書く方が簡単です。
一般的に、ここではアプローチの矛盾が非常に顕著に見られます。 開発者が設定に入らないように、管理者は焼くまでコードに入らないでしょう。
能力差
これは上記のことから一部は成り立ちますが、事実は残ります。システム管理者/ DevOpsとプログラマ/開発者は完全に異なる能力を持っています。
プログラマーはサーバーを構成できます。 おそらく。 しかし、彼には明らかではない潜在的な問題を考慮に入れてすぐに解決することはほとんどありません。 同じことがインフラストラクチャにも当てはまります。開発者は単にそれを理解せず、StackOverflowからのアドバイスに従って「デフォルトで」すべてを行います。
人生からの例。 以前の職場の1つで、小さなソフトウェア会社で、「なぜ管理者/ DevOpsが必要なのか」という当局からの質問に出会いました。 実際、彼らはシステム管理者が何をしているかを理解していなかったと指摘しています。 ローカルネットワークのIPアドレス指定は、インターネットの範囲からのものでした（残念ながら、このサブネットはアメリカのホームインターネットアクセスプロバイダーの一部に属していました）。 「ソープボックス」スイッチと通常の「ホーム」ルーターを使用してインターネットにアクセスしました。 これらの人々は、非常に真剣な分散システムを開発し（何も言いません）、フォールトトレラントにしようとしました。 約半年の開発の後、それにもかかわらず、サーバーハードウェアとOSに精通した人を雇う必要があるという認識が勝ちました。
結論と結論
私の意見では、影響圏の分離は素晴らしいです。 あなたはarbitrarily意的に普遍的な「真空の球体ITスペシャリスト」になることができますが、すべてを行うことは決してできません。 開発者がソフトウェアを開発し、管理者がインフラストラクチャと同じソフトウェアを作成および管理するのはこのためです。
プログラマは、彼らが悪いからではなく、これが彼らの関心事ではないからではなく、サーバーに許可されるべきではありません。 これを行うために、開発者の陣営の人間管理者である「あなた自身の人々の間で見知らぬ人」、混乱に適応し、その中にフレーズの束と呼ばれる奇妙な秩序を作成した「継続的な統合/展開/配信/運用」という開発者がいます。
そのため、深夜にセーターを着たひげを生やした男が「設定形式を変更しましたが、私の展開は落ちました」と非難して夢見るならば、親愛なるプログラマー、開発者、建築家は気分を害しません。
そして、親愛なるdevopsと管理者は、開発者に対してより寛容になります。 彼らは常に新しい、より良いソリューションを探しています。 このため、彼らの仕事はカオスに似ていますが、より高い次数を含んでいます。
ただし、とにかくサーバー上でそれらを許可しないでください。