リモートチームのインシデント解決

この記事はもともとに掲載されましたDevOps.

記事上で:

従来のインシデント管理のアドホックで事後対応型のファイアドリルプロセスは、今日のリモートワーク環境では実行できなくなりました。
問題優先アプローチを採用することで、ITは最も差し迫ったユーザーの問題を最初に解決できます。
成功には、部門間の調整の改善と指標への新しいアプローチが含まれます。

現在、ITサポートとインシデント管理に携わっている人々は、大規模なリモートワーカーをサポートし、予測できないワークロードを管理するという異常な問題に直面しています。オン Reddit, システム管理者やその他のITプロフェッショナルは、問題の解決と高いSLAの維持を試みながら、単独で作業することの問題と煩わしさを嘆いています。トラブルシューティングに欠かせないSMEを手に入れることはできません。その人も家にいて、さまざまなツールからのメッセージやアラートが殺到しているからです。

ネットワーク、VPN、およびサーバーは、SaaSアプリとコラボレーションツールの使用率の上昇により、現在、非常に大きな打撃を受けています。ユーザーの期待は通常よりもさらに壮大です。ホームベースのIT環境は、人間との対話が残っているものすべての生命線です。 IT組織は、アプリケーションとサービスを一晩で完璧に機能させることが期待されています。間違いなく、ITプロフェッショナルは、危機の時期に雇用主のために仕事の輪を動かし続けるために、支援をもって取り組んでいます。それでも、長時間働くことは答えではありません。新しい働き方が必要です。長期的には現状よりも優れている可能性があります。

多くの組織では、インシデントの管理と解決のプロセスは、人々がメトリックでいっぱいの画面を見ることから始まります。ネットワークI / Oなどのスパイクが発生し、最悪の事態を想定してすぐに調査を開始します。さらに不利なシナリオは、ユーザーがTwitter、Reddit、またはその他の人気のある技術コミュニティで問題を呼びかけ、ITとビジネスが迅速に対応して管理しなければならない有害なPR状況を作り出す場合です。この臨時の事後対応型ファイアドリルには時間がかかり、その特定の問題を解決することは、その日の最も重要な項目ではない可能性があります。ソフトウェア開発では、最初にシステムのアーキテクチャを設計し、次にユーザーエクスペリエンスを設計するという悪い習慣に似ています。

外出禁止令の予見可能な将来に危機に瀕しているすべてのものを考えると、SREとITサポート技術者はインシデント管理プロセスを反転させる必要があります。メトリックから始めて問題を明らかにするために逆方向に作業するのではなく、問題があったとしても、解決すべき最も重要な問題を探すことから始めます。次に、そのエンドユーザープロセスをサポートするリソースとコンポーネントを見つけ、最後に、最も関連性の高いメトリックを分析します。.

例えば：

ストリーミングビデオサービスのB-to-Cプロバイダーは、現在、日中のトラフィックが200％増加しています。これにより、ユーザーの読み込み時間が遅くなり、グリッチが発生します。
ITはそのサービスの下にあるコンポーネントにタグを付けているため、ITオペレーターは、どのVM、データベース、およびロードバランサーが機能するかを正確に把握しています。
次に、運用チームは、CPUアイドル時間などの最も関連性の高いメトリックを特定して、測定し、修正するための手順を実行できます。

問題第一のアプローチ

それはとても単純に聞こえます：プロセスを反転させます。しかし、そうではありません。 ITオペレーターとSREは、どの問題を解決または防止するかについて考えることに慣れていません。予防的または予測的であることは、一般的なワークフローではありませんでした。

IT運用チームとDevOpsチームが、エンタープライズサービスの可用性と正常性を管理するためのプロアクティブなアプローチをとる方法は次のとおりです。

部門間で調整する

現在解決すべき最も重要な問題を特定することは、最も困難なステップであり、最も時間がかかるステップです。最近の一般的な問題は、コストと規模に関連しています。コストを削減したり、より多くのワークロードを処理したりするために、環境のサイズを適切に設定するにはどうすればよいですか。入力のフィールドを広げて、財務報告Webサイトでのページの読み込みが遅いなど、特定の問題に絞り込みます。顧客体験に最も近い製品マネージャー、アカウントマネージャー、およびビジネスユニットのリーダーは、顧客/ユーザーの満足度に影響を与える主要な問題についてフィードバックを提供できます。チームはまた、最近のサポートチケットを確認して、痛みの一般的なテーマを特定する必要があります。

指標へのアプローチを微調整する

NS 使用率の飽和とエラー（USE）メソッド問題優先のインシデント管理プロセスにアプローチする1つの方法です。 NetflixのシニアパフォーマンスアーキテクトであるBrendanGreggが詳しく説明しているように、この方法論は、質問を投げかけ、答えを探し、指標に逆戻りすることから始まります。測定するリソースごとに、3つのメトリックを特定します。1つは使用率、1つは飽和、もう1つはエラーです。

「USEメソッドは、あなたがチェックしなかったものに気づきました。かつては未知だったもの-未知のものは今では知られている-未知のものです」とグレッグは説明しました。

ワークフローの標準化

の共通プロセスを作成する事故管理すべてのチームにわたって。大きな問題が発生したときに、ほぼ全員が同じ部屋にアドホックな方法で集まって集まるという利点がなければ、明確な手順と役割を設定することが不可欠です。そうすることで、解決を不必要に遅らせるフラストレーション、混乱、見落としを防ぐことができます。ほとんどのインシデントは複数の要因で構成されているため、チームは情報を文書化して整理するために少数のユーザーフレンドリーなツールを採用する必要があります。当社では現在、オンラインホワイトボードアプリケーションであるMiroなどのツールを使用して、物理的なホワイトボードセッションを置き換えています。もちろん、Zoom、Slack、Jira、その他のクラウドベースのツールも多くの組織ですでに導入されています。誰もがどのツールを使用すべきかを、それらの使用方法に関するいくつかのガイドラインとともに義務付けます。

自動化を強化する

一部の組織では、需要に応じたスケーリング要件が10倍に増加しています。現在、自動化は重要な役割を果たしています。たとえば、Web GUIから離れることは、よりスケーラブルであり、ChefやPuppetなどの最新のツールと連携します。ユーザーチケットは、たとえば、電子メールから自動生成され、GitHubなどのコード管理システムにリンクされます。最新の開発および運用チームは、単体テストとプロビジョニングの自動化も拡大しています。

燃え尽き症候群に注意

長い検疫日の間に、より多くの作業や時間を埋める必要があるかどうかにかかわらず、多くのソフトウェアエンジニア、テスター、アーキテクトは現在、より長い日数で働いています。それでも、倦怠感と燃え尽き症候群は、士気の低下とともにエラーや見落としにつながる可能性があります。従業員が休憩を取り、合理的な日数で働き、個人的なニーズに対応するための時間とエネルギーを持っていることを確認するのはマネージャー次第です。