開発者は火星出身、管理者は金星出身

偶然は偶然で、確かに別の惑星にありました...

バックエンド開発者が管理者とチームでどのように連携するかについて、成功例と失敗例を XNUMX つ紹介したいと思います。

最初の話。
Webスタジオ、従業員数は片手で数えられるほど。 今日はレイアウトデザイナー、明日はバックエンダー、明後日は管理者です。 一方で、膨大な経験を積むことができます。 一方で、あらゆる分野で能力が不足している。 仕事の初日のことを今でも覚えています。私はまだ青いです。上司は「パテを開けてください」と言ったけど、それが何なのかわかりません。 管理者とのコミュニケーションは除外されます。 あなた自身が管理者です。 この状況の長所と短所を考えてみましょう。

+ すべての力はあなたの手の中にあります。
+ サーバーへのアクセスを誰かに懇願する必要はありません。
+ あらゆる方向への素早い反応時間。
+ スキルがよく向上します。
+ 製品アーキテクチャを完全に理解します。

— 責任感が高い。
— 生産を中断するリスク。
— すべての分野で優れたスペシャリストになるのは難しいです。

興味がないので先に進みましょう

XNUMX番目の話。
大企業、大規模プロジェクト。 5 ～ 7 名の従業員を擁する管理部門と、いくつかの開発グループがあります。 そのような会社で働くことになると、管理者は誰でも、製品の開発に取り組むためにここに来たのではなく、何かを壊すために来たのだと考えるでしょう。 署名されたNDAにも、面接での選考にも、それ以外の記載はありません。 いいえ、この男は汚い小さな手で私たちのキスの演出を台無しにするためにここに来ました。 したがって、そのような人とは、最低限のコミュニケーションが必要であり、少なくとも、それに応じてステッカーを投げることができます。 プロジェクトのアーキテクチャに関する質問には答えないでください。 チームリーダーが要求するまでアクセスを許可しないことをお勧めします。 そして彼が要求すると、彼らが要求したよりもさらに少ない権限でそれを返すでしょう。 このような管理者とのほとんどすべての通信は、開発部門と管理部門の間のブラックホールに吸収されます。 問題をすぐに解決することは不可能です。 ただし、直接来ることはできません。管理者は 24 時間年中無休で多忙です。 (いつも何をしているのですか?) いくつかのパフォーマンス特性:

• 実稼働環境での平均デプロイ時間は 4 ～ 5 時間です
• 本番環境での最大導入時間は 9 時間
• 開発者にとって、本番環境のアプリケーションは、本番サーバー自体と同様にブラック ボックスです。 全部で何個ありますか？
• リリースの品質が低く、エラーが頻繁に発生する
• 開発者はリリースプロセスに参加しません

さて、当然のことですが、新しい人が本番環境に入るのは許可されていません。 そうですね、忍耐力を身につければ、他の人からの信頼も得られるようになります。 しかし、何らかの理由で、管理者にとって物事はそれほど単純ではありません。

行為 1. 管理者は見えません。
リリース日、開発者と管理者はコミュニケーションを取りません。 管理者に質問はありません。 しかし、その理由は後でわかります。 管理者は原則的な人物で、メッセンジャーを持たず、電話番号を誰にも教えず、ソーシャル ネットワーク上のプロフィールも持ちません。 彼の写真すらどこにもないんだけど、どんな顔してるの？ 私たちは担当マネージャーと当惑しながら約 15 分間座って、このボイジャー 1 号との通信を確立しようと試みました。その後、彼が終了したというメッセージが会社の電子メールに表示されました。 郵送で対応するつもりですか？ なぜだめですか？ 便利ですね。 まあ、わかりました、クールダウンしましょう。 プロセスはすでに進行しており、後戻りはできません。 もう一度メッセージを読んでください。 "私は終えた"。 何を終えましたか？ どこ？ どこで探せばいいですか？ ここで、リリースまでに 4 時間が正常である理由がわかりました。 開発ショックはありましたが、リリースは完了しました。 もう解放したいという欲求はありません。

第 2 幕。そのバージョンではありません。
次のリリース。 経験を積んでから、管理者向けにサーバーに必要なソフトウェアとライブラリのリストを作成し、一部のバージョンを示します。 いつものように、管理者がそこで何かを終えたことを示す弱い無線信号を受信します。 回帰テストが始まります。これには約 XNUMX 時間かかります。 すべてが機能しているように見えますが、重大なバグが XNUMX つあります。 重要な機能が動作しません。 次の数時間は、タンバリンで踊り、コーヒーかすで占いをし、コードの各部分を詳細にレビューしました。 管理人はすべてをやったと言っています。 不正な開発者が作成したアプリケーションは動作しませんが、サーバーは動作します。 彼に何か質問はありますか？ XNUMX 時間の終わりに、管理者に運用サーバー上のライブラリのバージョンをチャットとビンゴに送信してもらいます。これは私たちが必要とするものではありません。 管理者に必要なバージョンをインストールするよう依頼しましたが、OS パッケージ マネージャーにこのバージョンがないためインストールできないとの返答を受け取りました。 ここで、管理者は記憶の片隅で、別の管理者が必要なバージョンを手動で組み立てるだけでこの問題をすでに解決していたことを思い出します。 しかし、いいえ、私たちのものはそんなことはしません。 条例では禁止されています。 カール、私たちはここに数時間座っていますが、制限時間は何ですか?! また衝撃を受けてなんとかリリースを終える。

第 3 幕、短い
緊急チケット、主要な機能が実稼働環境のユーザーの 24 人に対して機能しません。 私たちは数時間かけて突いて確認します。 開発環境ではすべてが機能します。 php-fpm ログを調べることが良いことであることは明らかです。 当時のプロジェクトには ELK や Prometheus のようなログ システムはありませんでした。 管理部門にチケットを発行し、サーバー上の php-fpm ログへのアクセスを許可します。 ここで、私たちがアクセスを求めているのには理由があることを理解する必要があります。ブラック ホールと管理者が年中無休で忙しいことを覚えていますか? 彼らにログ自体を見てもらうと、これは「この世にはない」優先順位のタスクになります。 チケットが作成されると、管理部門の責任者から即座に「運用ログにアクセスする必要はありません。バグを含まずに書き込んでください。」という返答を受け取りました。 カーテン。

第4幕以降
さまざまなバージョンのライブラリ、未構成のソフトウェア、準備されていないサーバー負荷、その他の問題が原因で、実稼働環境で数十の問題がまだ収集されています。 もちろん、コードのバグもあります。すべての罪を管理者に責めるつもりはありません。そのプロジェクトのもう XNUMX つの典型的な操作についてだけ言及します。 スーパーバイザーを通じて起動されるバックグラウンド ワーカーがかなり多くあり、いくつかのスクリプトを cron に追加する必要がありました。 時々、同じ労働者が仕事をやめることもありました。 キューサーバーの負荷は電光石火の速度で増大し、悲しむユーザーは回転するローダーを見つめました。 このようなワーカーを迅速に修正するには、単に再起動するだけで十分ですが、これも管理者のみが実行できます。 このような基本的な操作を行っていると、丸一日が過ぎてしまうことがあります。 もちろん、ここで、不正なプログラマーはワーカーがクラッシュしないようにワーカーを作成する必要があることに注意してください。ただし、ワーカーがクラッシュした場合は、その理由を理解しておくとよいでしょう。本番環境へのアクセスがないために、それが不可能な場合もあります。もちろん、その結果、開発者からのログが不足します。

変身。
かなり長い間これらすべてに耐えてきたので、私たちはチームとともに、より成功する方向に舵を切り始めました。 要約すると、どのような問題に直面しましたか?

• 開発者と管理部門間の質の高いコミュニケーションの欠如
• 管理者は、アプリケーションがどのように構成され、どのような依存関係があり、どのように動作するのかをまったく理解していないことが判明しました (!)。
• 開発者は実稼働環境がどのように機能するかを理解していないため、問題に効果的に対応できません。
• 導入プロセスに時間がかかりすぎます。
• 不安定なリリース。

私たちが何をしてしまったのでしょうか？
リリースごとにリリース ノートのリストが生成され、これには次のリリースが機能するためにサーバー上で実行する必要がある作業のリストが含まれています。 このリストには、管理者、リリース責任者、開発者が実行する必要がある作業など、いくつかのセクションが含まれていました。 開発者はすべての実稼働サーバーに非 root アクセスできるため、開発全般、特に問題解決が高速化されました。 開発者は、運用がどのように機能するか、運用がどのようなサービスに分割されるか、レプリカの場所とコストについても理解できます。 戦闘負荷の一部がより明確になり、これは間違いなくコードの品質に影響を与えます。 リリース プロセス中のコミュニケーションは、インスタント メッセンジャーの 30 人のチャットで行われました。 第一に、すべての行動の記録があり、第二に、コミュニケーションがより緊密な環境で行われたことです。 行動の履歴があることで、新入社員は問題をより迅速に解決できるようになったことが一度や二度ではありません。 これは矛盾していますが、これにより管理者自身が役立つことがよくありました。 確かなことは言えませんが、管理者はプロジェクトがどのように機能し、どのように書かれているかをさらに理解し始めているように思えます。 時には、お互いに詳細を共有することもありました。 平均リリース時間は 40 時間に短縮されました。 場合によってはXNUMX～XNUMX分で終わることもありました。 バグの数は、XNUMX 倍とは言わないまでも、大幅に減少しました。 もちろん、自動テストなどの他の要因もリリース時間の短縮に影響を与えました。 リリースのたびに、私たちは振り返りを実施し始めました。 チーム全体が、何が新しくなり、何が変更され、何が削除されたのかを把握できるようにします。 残念ながら、管理者はいつも彼らのところに来てくれるとは限りませんでした。そうですね、管理者は忙しいのです... 開発者としての私の仕事の満足度は間違いなく向上しました。 自分の専門分野のほぼすべての問題を素早く解決できれば、気分は最高です。 もちろん完全ではありませんが、ある程度の DevOps 文化を導入したことは後でわかりますが、その変革の始まりでさえ印象的でした。

三話
起動する。 管理者は XNUMX 名、小規模な開発部門。 到着したとき、私は完全にゼロです、なぜなら... メール以外からはアクセスできません。 管理者に手紙を書いてアクセスを求めます。 さらに、彼が新入社員のこととログイン/パスワードの発行の必要性を認識しているという情報もあります。 これらにより、リポジトリと VPN からのアクセスが可能になります。 Wiki、teamcity、rundesk へのアクセスを許可する理由は何ですか? バックエンド部分全体を書くように呼ばれた人にとっては役に立たないこと。 時間が経てば、私たちはいくつかのツールにアクセスできるようになります。 もちろん、到着は不信感を持って迎えられた。 チャットや誘導的な質問を通じて、プロジェクトのインフラストラクチャがどのように機能するかをゆっくりと理解しようとしています。 基本的には何も認識しません。 制作はこれまでと同じブラックボックスです。 しかしそれ以上に、テストに使用されるステージサーバーですらブラックボックスです。 そこに Git からブランチをデプロイする以外に何もできません。 また、.env ファイルのようにアプリケーションを構成することもできません。 このような操作のためのアクセスは許可されません。 テストサーバー上のアプリケーションの構成内の行を変更してもらう必要があります。 (管理者がプロジェクトにおいて自分が重要であると感じることが重要であるという理論があります。構成内の行を変更するように求められなければ、管理者は単純に必要ありません)。 まあ、いつものことですが、便利ではありませんか？ これはすぐに退屈になります。管理者と直接会話した結果、開発者は悪いコードを書くために生まれてきたもので、本質的に無能な人間であり、運用環境から遠ざけた方がよいことがわかりました。 ただし、念のため、ここでもテストサーバーからのものです。 紛争は急速に激化している。 管理者とのコミュニケーションはありません。 彼が一人であるという事実によって状況はさらに悪化する。 以下は典型的な図です。 リリース。 特定の機能が動作しません。 何が起こっているのかを理解するのに長い時間がかかり、開発者からのさまざまなアイデアがチャットに投げ込まれますが、そのような状況の管理者は通常、開発者に責任があると想定します。 それから彼はチャットに「待て、私が彼を訂正した」と書きました。 問題が何であったかについての情報を残してほしいと頼まれると、私たちは有害な言い訳を受け取ります。 要らないところに鼻を突っ込まないでください。 開発者はコードを書かなければなりません。 プロジェクト内の多くの体の動きが XNUMX 人の人間を介して行われ、その人だけが全員が必要とする操作を実行できるという状況は、非常に悲しいことです。 このような人はひどいボトルネックです。 Devops のアイデアが市場投入までの時間を短縮しようとする場合、そのような人々は Devops のアイデアにとって最大の敵です。 残念ながらここで幕が閉じてしまいます。

PS 人々とのチャットで開発者と管理者について少し話した後、私の痛みを共有する人々に会いました。 しかし、中には「こんなことは初めてだ」という人もいた。 ある Devops カンファレンスで、私は Anton Isanin (Alfa Bank) に、管理者のボトルネックの問題にどのように対処しているのかと尋ねたところ、彼はこう答えました。「管理者をボタンに置​​き換えました。」 ところで ポッドキャスト 彼の参加により。 敵よりも優れた管理者の方がたくさんいると信じたいです。 はい、冒頭の写真は実際の通信です。

出典: www.habr.com