基礎知識

システム監視と障害対応の基本。何を測り、どう動くか

監視は設定して終わりではなく、障害対応は起きてから考えるものではありません。この記事では、何を測り、起きたときにどう動くのかを整理します。

監視は何のためか

監視の目的は、問題に気づくことです。当たり前に見えますが、実務では目的が曖昧なまま設定されている例が多くあります。

気づくべきは、利用者に影響が出ている状態です。サーバーの数値が高いことそのものではありません。

この区別が重要です。CPU使用率が90%でも、応答が正常なら問題ではありません。逆に、使用率が低くても、利用者が使えなければ障害です。

したがって、まず「利用者から見て正常か」を測る指標を置くべきです。機器の状態は、その次に来ます。

何を監視するか

測る対象を、層に分けて整理します。

• 利用者視点／画面が開くか、処理が成功するか、応答時間
• アプリケーション／エラーの発生数、処理の遅延、待ち行列の長さ
• 基盤／CPU、メモリ、ディスク、ネットワーク
• 外部依存／連携している他社サービスの状態
• 費用／クラウドの使用量。予算超過も一種の異常

優先順位は上からです。基盤の監視だけを設定している現場は多くありますが、それだけでは利用者の困りごとに気づけません。

5つ目は見落とされがちです。クラウドでは、設定の誤りが高額な請求につながります。

通知の設計

監視の失敗で最も多いのが、通知の出しすぎです。

大量の通知は、無視されるようになります。本当に重要な通知が埋もれ、監視の意味がなくなります。

設計の原則は、人が行動すべきものだけを通知することです。見るだけで何もしない通知は、通知にすべきではありません。

段階を分けるのが有効です。即座に対応が必要なもの、翌営業日でよいもの、記録だけで足りるもの。

また、閾値の設定には根拠が要ります。「なんとなく80%」ではなく、その値を超えると何が起きるかを踏まえて決めます。

障害時の動き方

実際に障害が起きたときの手順を整理します。

①影響の把握。誰が、何を、どの程度できないのか。原因より先に、影響範囲を確認します。

②連絡。関係者への共有と、必要なら利用者への告知。原因が分からなくても、起きていることは伝えます。

③復旧を優先。原因の究明より、まず使える状態に戻すことを優先します。切り戻し、再起動、切り離し。

④記録。時刻、事象、対応を残します。後の振り返りに必要です。

⑤原因の究明と再発防止。復旧後に行います。

③と⑤を混同すると、復旧が遅れます。原因を調べながら止まったままにするのは、多くの場合誤りです。

振り返りの記録

障害後の振り返りは、組織の資産になります。

記録すべきは、時系列、影響、原因、対応、再発防止策です。

個人の責任を追及しないのが原則です。誰が操作を誤ったかではなく、なぜその操作が可能だったかを問います。責める文化では、事実が出てこなくなります。

再発防止策は、具体的で実行可能なものにします。「注意する」は対策ではありません。仕組みで防ぐか、検知できるようにするか。

そして、記録を読み返せる場所に置くことです。書いたきり誰も見ない記録は、学習になりません。

起きる前の準備

障害対応の質は、事前の準備で決まります。

連絡先と役割。誰に連絡し、誰が判断するか。深夜や休日も含めて決めておきます。

切り戻しの手順。更新を戻せるか。戻せない変更は、それ自体がリスクです。

訓練。実際に障害を起こしてみる演習を行う組織もあります。手順が機能するかを確認するためです。

記録の場所。障害中に情報を集約する場所を、あらかじめ決めておきます。

これらがないと、実際に起きたときに混乱します。手順がある組織とない組織では、復旧時間が大きく変わります。

使われる仕組み

監視に使われる技術を、役割ごとに整理します。

指標の収集と可視化。数値を集め、グラフで見られるようにするもの。PrometheusとGrafanaの組み合わせが広く使われます。

ログの集約。複数のサーバーに散らばるログを、1か所で検索できるようにします。

分散トレース。複数のサービスにまたがる処理の流れを追跡します。構成が複雑な場合に有効です。

クラウド事業者の標準機能もあり、まずこれで足りる場合も多くあります。

道具を増やす前に、何を測るかを決めるべきです。目的が曖昧なまま導入すると、設定だけが増えます。

どこまで安定させるか

監視の設計には、目標値の設定が伴います。

稼働率100%は目標になりません。費用が無限に増え、変更もできなくなります。

現実的な目標は、事業への影響から決めます。月に数十分止まっても業務に支障がないシステムと、1分の停止が損失になるシステムでは、かけるべき費用が違います。

稼働率の水準は、費用と直結します。桁が1つ上がるごとに、必要な構成と体制が大きく変わります。

すべてを同じ水準にする必要はありません。重要なものだけ高い水準にし、他は緩やかにする。この判断が設計の出発点になります。

記録の設計

監視と並んで重要なのが、記録の残し方です。

何を残すか。誰が、いつ、何をしたか。処理の開始と終了。誤りが起きた場合の詳細。

残してはいけないもの。パスワード、個人情報、決済情報。記録に含めてしまう事故が実際に起きています。

形式を揃える。後から検索・集計できる形にします。自由な文章では、機械的に扱えません。

保管期間を決める。法令上の要件がある場合もあります。無制限に貯めると費用がかかります。

記録は、障害時に唯一の手がかりになります。足りないことに気づくのは、たいてい必要になった後です。