現在、IT サポートやインシデント管理に従事している人たちは、大規模なリモートワークをサポートし、予測不可能なワークロードを管理するという異常な困難に直面しています。Reddit 上では、システム管理者やその他の IT のプロが、問題を解決し、高い SLA を維持しようとしている間、孤立して作業することのちょっとした問題や面倒くささを嘆いています。トラブルシューティングのために専門家を捕まえたいところですが、彼らもまた家にいて、多くの異なるツールからのメッセージやアラートが殺到しているので、それができません。

ネットワーク、VPN、およびサーバーは、SaaS アプリやコラボレーションツールの利用率が高いため、現在、さらに厳しい状況に置かれています。ユーザーの期待は通常よりもさらに壮大なものになっています。IT 組織は、アプリケーションやサービスを夜間でも完璧に動作させることを期待されています。間違いなく、IT のプロは、危機的な状況下でも会社のために仕事の歯車を動かし続けるために、冷静に仕事をしています。しかし、長時間労働は解決策ではありません。私たちには新しい働き方が必要であり、それは長期的には現在の状況よりも優れていることを証明するものかもしれません。

多くの組織では、インシデント管理と解決のプロセスは、人々がメトリクスの画面を見ることから始まります。ネットワーク I/O のような何かが急増しているのを見て、すぐに最悪の事態を想定して調査を開始します。さらに悪いシナリオは、ユーザーが Twitter や Reddit、その他の人気のあるテックコミュニティで問題を指摘した場合で、IT とビジネスが迅速に対応し、管理しなければならない有害な PR 状況が発生します。このような臨機応変な訓練には時間がかかり、特定の問題を解決することがその日の最も重要な項目ではないかもしれません。ソフトウェア開発では、まずシステムのアーキテクチャを設計してからユーザーエクスペリエンスを設計するという悪しき習慣に似ています。

在宅勤務の義務化が予想される将来に関わるすべての問題を考えると、SRE (Site Reliability Engineer) と IT サポート技術者は、インシデント管理プロセスを反転させる必要があります。問題がある場合には、まずメトリクスから始め、問題を明らかにするために後ろ向きに作業するのではなく、解決すべき最も重要な問題を探すことから始めます。次に、そのエンドユーザープロセスをサポートするリソースとコンポーネントを発見し、最後に最も関連性の高いメトリクスを分析します。

例えば、以下のような例があります

1. あるストリーミング動画サービスの B to C プロバイダでは、日中のトラフィックが 200% 増加しています。これにより、ユーザーのロード時間が遅くなり、不具合が発生しています。
2. IT 部門は、そのサービスの下にあるコンポーネントにタグを付けたので、IT オペレータは、どの VM、データベース、およびロードバランサーの役割を果たしているかを正確に知ることができます。
3. 次に、運用チームは、例えば CPU アイドルタイムなど、最も関連性の高いメトリクスを特定して測定し、修正のための措置を講じることができます。

問題第一主義のアプローチ

プロセスを反転させます。それはとても簡単に聞こえますが、実際にはそうではありません。IT オペレーターや SRE は、解決すべき問題や予防すべき問題を考えることに慣れていません。プロアクティブであることや予測的であることは、一般的なワークフローではありませんでした。
ここでは、IT 運用および DevOps チームがエンタープライズサービスの可用性と健全性を管理するためにプロアクティブなアプローチを取る方法を紹介します。

部門を超えた調整

今すぐ解決すべき最も重要な問題を特定することは、最も困難なステップであり、最も時間がかかるものです。最近よくある問題は、コストと規模に関連しています。コストを削減したり、より多くのワークロードを処理したりするために、どのように環境を適切なサイズにするか？財務報告書のウェブサイトのページロードが遅いなど、具体的な問題を絞り込むために入力分野を広げましょう。カスタマーエクスペリエンスに最も近いプロダクトマネージャー、アカウントマネージャー、ビジネスユニットのリーダーは、顧客やユーザーの満足度に影響を与える上位の問題についてフィードバックを提供することができます。また、チームは最近のサポートチケットを確認し、問題の共通テーマを特定する必要があります。

メトリクスへのアプローチの微調整

Utilization Saturation and Errors (USE) Method は、問題優先のインシデント管理プロセスにアプローチするための 1つの方法です。Netflix のシニアパフォーマンスアーキテクトである Brendan Gregg 氏が詳述しているように、この方法論は、質問を投げかけ、答えを求め、メトリクスに遡って作業することから始まります。測定したいリソースごとに、利用率、飽和度、エラーの 3つのメトリクスを特定します。
「USE メソッドは、チェックしていなかったことに気づかせてくれます。かつては未知であったことが、今では既知の未知となっています」と Gregg 氏は説明しています。

ワークフローの標準化

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

自動化の強化

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

燃え尽き症候群に注意

仕事が増えたり、長い隔離期間中の時間を埋める必要があるかどうかに関わらず、多くのソフトウェアエンジニア、テスター、アーキテクトは今、長時間労働をしています。しかし、疲労困憊や燃え尽き症候群は、エラーや見落とし、士気の低下につながる可能性があります。従業員が休憩を取り、合理的な日数を働き、個人的なニーズに対応するための時間とエネルギーを持っているかどうかを確認するのは、管理者次第です。