高負荷ITシステムの運用・サポートプロセスにおけるXNUMXつの問題

こんにちは、ハブル！ 私は 1000 年間にわたって Highload IT システムをサポートしてきました。 この記事では、XNUMX+ RPS モードで動作するように nginx を設定する際の問題やその他の技術的なことについては書きません。 このようなシステムのサポートと運用で発生するプロセスの問題について、私の観察を共有します。

監視

テクニカル サポートは、「なぜ...サイトが再び機能しなくなったのですか?」という内容のリクエストが届くまで待ちません。 サイトがクラッシュしてから XNUMX 分以内に、サポートはすでに問題を認識し、解決を開始するはずです。 しかし、この現場は氷山の一角だ。 その可用性は最初に監視されるものの XNUMX つです。

オンライン ストアの残りの商品が ERP システムから届かなくなった場合はどうすればよいでしょうか? それとも、クライアントの割引を計算する CRM システムが応答を停止したのでしょうか? サイトは機能しているようです。 条件付き Zabbix は 200 応答を受け取ります。 当番シフトは監視からの通知を受け取っておらず、ゲーム・オブ・スローンズの新シーズンの最初のエピソードを喜んで見ています。

多くの場合、監視はメモリ、RAM、サーバー プロセッサの負荷の状態の測定のみに限定されます。 しかし、ビジネスにとっては、Web サイトで製品を入手できるようにすることの方がはるかに重要です。 クラスター内の XNUMX つの仮想マシンに条件付き障害が発生すると、その仮想マシンへのトラフィックが停止し、他のサーバーの負荷が増加します。 会社はお金を失うことはありません。

したがって、サーバー上のオペレーティング システムの技術パラメータを監視することに加えて、ビジネス メトリクスを構成する必要があります。 お金に直接影響する指標。 外部システム (CRM、ERP など) とのさまざまな対話。 一定期間内の注文数。 クライアント認証の成功または失敗とその他のメトリクス。

外部システムとの対話

年間売上高が XNUMX 億ルーブルを超える Web サイトやモバイル アプリケーションは、外部システムとやり取りします。 前述の CRM と ERP から始まり、購入を分析し、顧客が間違いなく購入する (実際には購入しない) 製品を提案するための外部ビッグ データ システムへの販売データの転送で終わります。 このような各システムには独自のサポートがあります。 そして、これらのシステムとの通信は痛みを引き起こすことがよくあります。 特に問題がグローバルであり、さまざまなシステムで分析する必要がある場合はそうです。

一部のシステムでは、管理者に電話番号または電報が提供されています。 どこかでマネージャーに手紙を書くか、外部システムのバグトラッカーに行く必要があります。 XNUMX つの大企業内であっても、異なるシステムが異なるアプリケーション会計システムで動作することがよくあります。 場合によっては、アプリケーションのステータスを追跡できなくなることがあります。 XNUMX つの条件付き Jira でリクエストを受け取ります。 次に、この最初の Jira のコメントに、別の Jira の課題へのリンクを追加します。 アプリケーションの XNUMX 番目の Jira では、誰かがすでに次のようなコメントを書いています。 問題を解決するには、条件付き管理者の Andrey に電話する必要があります。 などなど。

この問題に対する最善の解決策は、Slack などでコミュニケーション用の単一のスペースを作成することです。 外部システムの運用プロセスに参加するすべての参加者を招待します。 また、アプリケーションが重複しないように単一のトラッカーを使用します。 アプリケーションは、通知の監視から将来のバグ解決の出力に至るまで、XNUMX か所で追跡される必要があります。 これは非現実的であり、私たちがあるトラッカーで作業し、彼らが別のトラッカーで作業するということは歴史的に起こってきたことだとあなたは言うでしょう。 さまざまなシステムが登場し、独自の自律的な IT チームが存在しました。 私も同意します。したがって、問題は CIO またはプロダクトオーナーレベルで上から解決する必要があります。

やり取りするすべてのシステムは、優先順位に従って問題を解決するために、明確な SLA を備えたサービスとしてのサポートを提供する必要があります。 条件付き管理者のアンドレイがあなたのために時間を割いてくれるときではありません。

ボトルネックマン

プロジェクト (または製品) の全員に、休暇を取ることで上司の間で混乱を引き起こす人がいますか? これは、devops エンジニア、アナリスト、または開発者である可能性があります。 結局のところ、どのサーバーにどのコンテナがインストールされているか、問題が発生した場合にコンテナを再起動する方法を知っているのは Devops エンジニアだけであり、一般に、複雑な問題は彼なしでは解決できません。 複雑なメカニズムがどのように機能するかを知っているのはアナリストだけです。 どのデータ ストリームがどこに送信されるか。 どのサービスへのリクエストのどのパラメータの下で、どのサービスからの応答が受信されますか。
ログにエラーがある理由をすぐに理解し、製品の重大なバグを即座に修正できる人は誰でしょうか? もちろん同じ開発者です。 他にもありますが、何らかの理由で彼だけがシステムのさまざまなモジュールがどのように機能するかを理解しています。

この問題の根本は文書の欠如です。 結局のところ、システムのすべてのサービスが記述されていれば、アナリストなしで問題に対処することが可能になります。 もし devops が多忙なスケジュールの合間を縫って数日かけて、典型的な問題を解決するためのすべてのサーバー、サービス、手順を説明したとしたら、彼の不在中に問題は彼なしでも解決できるでしょう。 休暇中にビーチでビールを急いで飲み終えて、問題を解決するために Wi-Fi を探す必要はありません。

サポートスタッフの能力と責任

大規模なプロジェクトでは、企業は開発者の給与をケチることはありません。 彼らは同様のプロジェクトから高額な中高年層を探しています。 サポートがあれば状況は少し異なります。 彼らはあらゆる方法でこれらのコストを削減しようとしています。 企業は昨日のエニキー労働者を安価に雇い、果敢に戦いに臨む。 ゼレノグラードにある工場の名刺 Web サイトについて話している場合、この戦略は可能です。

大規模なオンライン ストアの場合、ダウンタイム 1 時間あたりのコストは Enikey 管理者の月給よりも高くなります。 年間売上高XNUMX億ルーブルを出発点として考えてみましょう。 これは、評価から得られるオンライン ストアの最低売上高です。 100 年のトップ 2018。 この金額を年間の時間数で割ると、純損失は 100 ルーブル以上になります。 夜間の時間を考慮しなければ、安全にその量を 000 倍にすることができます。

でも、一番大事なのはお金じゃないですよね？ （いや、もちろん一番大事なことですが）風評被害もあります。 有名なオンライン ストアの崩壊は、ソーシャル ネットワーク上でのレビューの波と、テーマ別メディアでの出版の両方を引き起こす可能性があります。 そして、キッチンでの友人たちの「そこでは何も買わないでください、彼らのウェブサイトはいつもダウンしています」というスタイルの会話はまったく測定できません。

これからは責任を持って。 私の実務では、サイトが利用できないという監視システムからの通知に、勤務中の管理者が時間内に応答しなかったケースがありました。 心地よい夏の金曜日の夜、モスクワの有名なオンラインストアのウェブサイトが静かに横たわっていた。 土曜日の朝、このサイトのプロダクト マネージャーはサイトが開かない理由を理解できず、Slack のサポートや緊急通知チャットは沈黙しました。 このようなミスにより、我々は XNUMX 桁の損害を被り、この当番職員は仕事を失いました。

責任感は身につけるのが難しいスキルです。 人がそれを持っているかどうかのどちらかです。 したがって、面接では、その人が責任を取ることに慣れているかどうかを間接的に示すさまざまな質問によって、その存在を特定しようとします。 「親に言われたから大学を選んだ」「妻に収入が少ないと言われたから転職した」と答える人は、そのような人とは関わらないほうが良いでしょう。

開発チームとのやり取り

ユーザーが製品の運用中に簡単な問題に遭遇した場合、サポートは自らの問題を解決します。 問題の再現、ログの分析などを試みます。 しかし、製品にバグが現れた場合はどうすればよいでしょうか? この場合、サポートは開発者にタスクを割り当てます。ここからが楽しみの始まりです。

開発者は常に過負荷にさらされています。 彼らは新しい機能を生み出しています。 販売に関するバグを修正することは、最も興味深い作業ではありません。 次のスプリントを完了するための期限が近づいています。 そして、サポートから不快な人々がやって来て、「問題が発生したので、すぐにすべてをやめてください」と言います。 このようなタスクの優先順位は最小限です。 特に、問題が最も重大ではなく、サイトの主要な機能が機能しており、リリース マネージャーが目を丸くして走り回って「このタスクを次のリリースまたはホットフィックスに緊急に追加してください」と書かない場合は特にそうです。

通常または低い優先度の問題は、リリースごとに移動されます。 「そのタスクはいつ完了しますか?」という質問に対して「申し訳ありませんが、現在たくさんのタスクがあります。チームリーダーかリリースマネージャーに聞いてください。」という形式の回答が届きます。

生産性の問題は、新しい機能を作成することよりも優先されます。 ユーザーが常にバグに遭遇すると、すぐに悪いレビューが来ることになります。 傷ついた評判を回復するのは困難です。

開発とサポートの間の相互作用の問題は、DevOps によって解決されます。 この略語は、開発用のテスト環境の作成を支援し、CICD パイプラインを構築し、テストされたコードを迅速に運用環境に導入する特定の人物の形でよく使用されます。 DevOps は、プロセスのすべての参加者が相互に緊密に対話し、ソフトウェア製品とサービスを迅速に作成および更新できるようにする、ソフトウェア開発へのアプローチです。 つまり、アナリスト、開発者、テスター、サポートです。

このアプローチでは、サポートと開発は、独自の目標や目的を持つ別の部門ではありません。 開発が運用に関与することもあれば、その逆も同様です。 分散チームの有名なフレーズ「問題は私の側にはない」がチャットに頻繁に登場しなくなり、エンド ユーザーは少し幸せになりました。

出所： habr.com