orangeitems’s diary

クラウドではたらくエンジニアの日々の感想です。

障害報告書を書くときに気を付けるポイント

f:id:orangeitems:20180725102112j:plain

 

はじめに

最近は、システム障害ウォッチャーとしていろんな種類の障害報告書を読んでいます。個人的に様々気が付くことがあるのですが、ある基準をもってコメントを入れています。これをまとめておきたいと思います。

 

 

ポイント

以下、ポイントが5つあります。

 

1. 現象と影響

まずは客観的に、ユーザー目線でどういう不具合が起こったかをわかりやすく記載することが大切です。技術者目線で書き始めるとこの時点で読み手から「意味がわからない」と言われてしまいます。システムを使うのは技術者ではないことが多いので、あくまでも平易な言葉で現象を明確に記載しましょう。また、この時点で経緯は不要です。結論から先に話す、という意図を持って現象を記載します。

また、この現象が発生したことによるユーザー側への影響も、現象の次に記載すべきです。そのシステムが使えなかったこと(現象)により、何がユーザーに不利益が起きたのか(影響)ということです。例えば、ストレージの過負荷が現象とすれば、影響は仮想OSが応答不能になりロードアベレージが上昇しサービスできなくなる、といった具合です。

このように、現象と影響は表裏一体であり、影響がゼロである場合はおそらく報告書すら出さないと思います。影響の大きさにより障害のレベルが変わっていきます。

 

2. 経緯

ユーザーは厳しいので、障害は分かったが本当に運用/障害対応は適切に行われていたのか?という目線で見てきます。特に問題が長期化するとユーザーのストレスはこの一点に集中します。問題を切り分けたり解決したりする技術力がないのではないか。誤った判断で二次被害を引き起こしているのではないか。運用体制に欠陥があり対応できる技術者がすぐにアクションできなくなっていないか。技術者ばかりでこれらを統括する経営側が把握できていないのではないか。などです。

経緯を細やかに表現することにより、運用や経営、つまり中の人が適切にアクションを行っていたことを表現する必要があります。ここで個人名を出す必要はありません。法人としてのプロセス運用・プロセス管理が問われているのです。

経緯を適切に情報公開することにより、かえってユーザーからの信頼を勝ち取るケースもあります。大切な情報の一つです。

 

3. 原因の考察

原因を考えるときに2つの目線が必要です。

・なぜその不具合は障害前に予見できなかったのか(作り込み)
・作り込まれてしまった不具合が、なぜ今のタイミングで発現したのか(流出)

案外、流出の理由しか述べてない報告書が散見されます。例えば、オペレーターが環境を誤ってコマンドを投入したから、と言って終わりにする報告書はよくあります。この時点でヒューマンエラーだけを原因としてしまうと、後段の再発防止策は、手順書作成の徹底、レビューの徹底、本番運用ルールの教育徹底、といわゆる徹底の濫用が発生します。

問題は、なぜ環境を誤ったか。ホスト名が本番と開発で同じであり間違いやすかったのかもしれません。運用部門が手薄で大変な量のメンテナンスを一人で行わなければならず、間違いは単に確率の問題だったのかもしれません。エラー率は一定なので、作業をやればやるほど誤る可能性は高くなります。障害の前日、社内の飲み会が遅くまであり翌日の注意力が落ちていたのかもしれません。

運用体制の不備、であればもはや障害前からの問題であり、環境を誤ってコマンドを投入したことは流出要因なのですが、もともといろいろな理由で引き起こす条件が整っていたのかもしれません。

このように、起こったことだけに注目せず、なぜ起こってしまったのかは深掘りする必要があります。特に経営者目線であれば、運用体制や作業環境、人間関係や指揮系統など広い目線で検討する必要があります。技術者に報告書を書かせると、確実にこの視点が抜けてきますし、報告書に前日飲み会だったからとは書けないですよね。

対外向けにどれだけ、本当の考察結果を晒すかはともかく、社内的には一番大切な活動だと思います。ここで、流出させたエンジニアだけを責めて終わりにする企業は二流三流だと思います。

 

4. 暫定対応

再発防止策に入る前に、まずは影響を最小限に抑えるために、どんな暫定対応を取ったかまとめる必要があります。これ以上影響が広がらないことをユーザーに伝えて安心感を得ることが目的です。

 

5. 再発防止策

大した原因の考察も無しにいきなり再発防止策に入る報告書は、内容が薄いことが多いです。その場合、基本的に「徹底」が増えます。これは流出要因たるエンジニアに、経営がプラスアルファの負担を要求する図になりがちです。

正直言って、障害を起こしたいエンジニアは一人もいません。でも起きるのです。起きないようにするためには運用体制の充実や、ミスしても影響が最小限に済むような構成にするための投資が重要です。

例えば経営的には、どんどんアプリケーションのリリースをして売上を伸ばしていきたいと考えているとします。しかしリリース作業などの変更の前提として、インフラが耐えられるかという側面からのキャパシティープランニングや、ステージング環境の準備試験、変更作業に伴う手順書の準備やレビューなど、いろいろな作業が発生します。作業がどんどん増えると、確率の問題としてヒューマンエラーが発生します。どんなに作業をしても失敗しないようにしなさい、というコマンドで疲弊するインフラエンジニアが多いのも事実です。

Kubernetesなどのコンテナ技術や、サーバーレスといったアーキテクチャーはこのあたりの問題を解決するために今盛んにアップデートされています。私個人はまだ中立的なのですが、アプリケーションのリリースが激しいWEBサービスの分野では一理あると思っています。変更が緩やかなシステムだと、これまでの3層(WEB/AP/DB)の方が相変わらず安定すると思っています。

このように、再発防止策を現場の技術者だけに押し付けることなく、経営資源の最適化と言った部分でマネジメントと技術者が一体感を持って再発防止策につなげられる会社が強いと思います。

エンジニア目線では作業すればするほど、障害に当たる可能性は高くなりますので、たまたま引いてしまったときに責任追及されるというのは、バカげているというのが私の意見です。作業を避けまくるエンジニアが得してしまうことになりかねません。

 

最後に

障害発生中においては、障害報告書を書くべき人が障害対応を行っていたり、リモート対応しているために何が起こっているか情報が社内で錯そうしたりと、難しい状況に追い込まれます。この中でポイントを抑えた報告書を出せる企業は、結果として顧客から信頼を得ます。

そして、障害報告書から学びそれを経営や現場に活かせていく企業が、最終的にITの世界では生き残っていくと思います。

 

新人ガール ITIL使って業務プロセス改善します!