Co-trou-shロゴ
システム障害対応に困っているあなたに ちょっと役立つメディア

「複雑なシステム障害対応をマスター」~世界のインシデント対応~incident.io-Part13

「複雑なシステム障害対応をマスター」~世界のインシデント対応~incident.io-Part13

はじめに

英国のスタートアップ企業であるPineapple Technology Ltd様が運営するincident.ioに関連したブログ The Practical Guide to Incident Management のポイントと解説

ポイント!!

  • 複雑なシステムの問題に対処するためには、保守、運用、情報システム部門のマネージャーに向けて構築化されたアプローチが重要になってきます。
  • 構造化された問題解決法とは、初めは曖昧な質問から始め、段階的に具体的な調査に絞り込んで複雑なシステムの障害を理解し、解決する手法です。また、調査を正確な方向に導くために適切な調査ロジック(theory)を構築し、それを具体的な証拠で証拠で裏付けることも重要になります。
  • 個人の仮定による早期の結論はなるべく避け、仮定と根拠に基づいた結論に重きを置くことが重要です。また、有効な仮説の構築と検証のために信ぴょう性のあるデータを頻繁に使用することで、その情報ソースを理解することも不可欠になります。

参考:Solving complex problems

解説

この章ではシステム障害の調査に関して、incident.ioが考える一般論を書いているように見えます。
・質問をして情報を増やす
・調査ロジックを組み立てる
・調査ロジックの証明・反証

補足として「複数の調査ロジックを同時に調査する」「思い込みからの決めつけをしない」「情報が信頼できるものであることを確認」の3点です。

私の意見は少し違うもので、
「アクション(暫定復旧、顧客連絡など)の仮説を設定(アクション候補)」「必要な情報を集める(判断情報)」「情報をどのように見るか基準を決める(判断基準)」とあるべきです。

情報を増やしていくと、緊急で必要では無い情報や、多くの情報で混乱をしがちです。
最終的に選ぶ仮説を立てた後に、そこから逆算していく考え方にすべきです。

3カ月で改善!システム障害対応 実践ガイド より

あと2つ気になる点があり、
「複数の調査は平行せず、順番に調査を進める」で、複数の仮説を進めるよりも仮説を1つずつ採決・否決をしたほうが解決には近いです。
 確かに情報収集や調査に時間かかるときがあり平行することはありますが、基本は分散ではなく、集中したほうが障害の復旧が早くなるのがセオリーです。
 ただ一方で、1つの仮説を皆で解くには役割分担がしづらい等があるのでそこはバランスは必要だと覆います。

「情報がどのような”精度”かを確認する」で、情報が確実でなければ使えない、となると使える情報が極端に減ったり、情報が確定するまでに時間がかかりすぎます。
 今はどの程度の”精度”の情報で判断をしていいのか、集めた情報がどのような”精度”なのかをしっかり判断すべきです。
 例えば、ホームページに「現在障害中です」と表示するかという「アクション候補」を選択するかを考える時に、復旧見込みは1時間後なのか、2時間後なのかを数分単位の”高い精度”で必要かというとそうではありません。
 今後、障害が発生してそうで、数十分復旧見込みがないというレベルの低い”精度”で判断をしてよいはずです。

 ただ、この領域の考え方はまだ未確定で明確な答えはない認識です。是非いろいろな意見を見比べて見て下さい。

用語

調査ロジック(theory):システム障害の原因を特定するための条件や関係性

執筆責任者
野村浩司
野村浩司!
「3カ月で改善!システム障害対応 実践ガイド」著者

野村浩司:金融システムの開発保守運用と改善を12年担当。7年にわたり合計約 1000 件の障害事例を分析。システム障害対応の改善では、アラートを9割削減。

                                           
  • nomura野村浩司