システム運用の問題管理の説明です。
開発部門では、障害管理表や課題管理表で管理することが多いですが、運用部門ではそれらを問題管理表で管理します。
呼び方は違いますが、みんな同じものです。
１．問題とは
ユーザーがITサービスを使えない状態をインシデントと呼びます。そのインシデントの原因が問題です。問題を解決すれば、そのインシデントは二度と発生しなくなります。
問題管理で重要なことは、類似の問題を発生させないことです。
例えば、APサーバーがスローダウンするインシデントが発生したとします。一次対応として、APサーバーを再起動して復旧させました。
この対応だけだと、またスローダウンする可能性があります。
GCログを調べたところ、フルGCが頻発してCPU使用率100%の状態が続いていたために、スローダウンしたことが分かりました。
フルGCが頻発した原因を調べたところ、メモリーが1GBあるにも関わらず、Javaヒープの最大値が256KBであることが判明しました。ヒープサイズを初期値のまま拡張しなかったため、ヒープが枯渇してフルGCが頻発し、スローダウンに至ったことが分かりました。
このJavaヒープを500MBに拡張することで、スローダウンの発生を解消することができます。
では問題は、Javaヒープの設定が小さかったことでしょうか？
２．問題の追求はほどほどに
問題管理で重要なことは、類似の問題を発生させないことです。インシデントの直接の原因となっている問題を解消することは当然のこととして、潜在している問題を発見し、顕在化する前に対処することが、問題管理ではとても重要です。
顕在化した問題にだけ対処していては、いつまで経ってもシステムは安定稼働しません。
ただこの潜在している問題の追及は、ほどほどにしないとメンバーが疲弊してしまうので注意が必要です。
先の例の場合、ヒープザイズ以外に初期値のままの設定は他に無かったのでしょうか？ヒープサイズを拡張することで、他の箇所がボトルネックになって再び障害が発生する可能性があります。
問題を「ヒープサイズの設定が小さかった」ことではなく、「ミドルウェアのインストール時に初期値のまま設定のチューニングをしなかった」ことにすると、対策が変わり、解消できる問題の範囲も広がります。
では初期値の見直しをすれば安心でしょうか？
設定ミスがあったとしても、そもそも性能負荷テストをきちんとやってれば、その時点で問題が見つかっていた可能性があります。
では性能負荷テストのやり直しが必要でしょうか？
といった感じで、深堀すればするほど、どんどん対策が重たくなっていきます。
３．業務影響の度合いで臨機応変に
すべての問題に対して、同じレベルで深堀していくと、メンバーも疲弊しますし、費用対効果の観点でも好ましくありません。
実運用では、業務影響の大きさによって、軽く流す問題、深堀をある程度で止めておく問題、徹底的に深堀して再発防止策を講じる問題など、バリエーションを持たせていくと限られたリソースを有効活用することができます。
属人的なやり方ではありますが、そもそもマニュアル化できるマネージメントの仕事なんて存在しません。常に判断し続けることがマネージメントの仕事なのです。
重要なことは、問題の深堀レベルを個人の思いの中だけでとどめず、メンバーと共有することです。なぜこの問題は軽く流していいのか、なぜそこまで徹底して再発防止策が必要なのか、そういった一つ一つの問題に対しての判断をメンバーと共有していくこと、可能であればディスカッションすること、それが一番深いレベルでの問題の対策なのではと思います。
【振り返り】
問題管理の説明は以上で終了となります。次回は構成管理の説明をしていきたいと思います。
①インシデント管理
②問題管理
③構成管理
④変更管理
⑤リリース管理
⑥サービスデスク
⑦サービスレベル管理
⑧キャパシティ管理
⑨可用性管理
⑩ITサービス財務管理
⑪ITサービス継続性管理
