@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

「システム障害対応の教科書」を読んだ

え?まだ読んでないの*1と言われたこともあり、ごめんなさい読んでませんと思いながら読んでみた。

読み始めていきなり分かるなと思う文章に出会った。

システム障害対応は未知かつ非計画的であるため、教育が難しい領域です。そして、多くの先輩たちがぶっつけ本番の障害対応の中で成長してきたのも事実です。それゆえに、教育が不可能と認識されていることも多いのです。
出典 : システム障害対応の教科書 | 木村 誠明 |本 | 通販 | Amazon p.13

自分も障害対応を行っているときにシステムのことを理解することが多かった経験がある。なぜかと考えてみると、障害を早急に倒すために詳しい先達が投入され対応している姿をみるので口伝や先達しか知らないことを学ぶ経験をすることが多い、必要なことだけ集中して話がされているので情報がよくまとまっているってことによるのかなと思う。

障害が起こった際のことは考えたくないので障害時を考えて準備しておく、練習をしておくということが少ないのかなと思った。ここ数年だとカオスエンジニアリングなどが話題になったこともあり障害が起きることは当たり前だと認識されているのではないかと思う。最近では障害を短い時間で終わらせるために対応方法を考えておく、練習を行うようにする事ができるといった考えをする人が大半な気がしている*2

本書は、属人化する、その時にしか思い出さないような暗黙知になってしまっている障害対応のノウハウが体系的に書かれた一冊になっている。
目次は以下

第1章 システム障害対応を学ぶ意義
第2章 システム障害の定義
第3章 システム障害対応の登場人物と役割
第4章 各プロセスの基本動作〜発生から終息まで
第5章 障害対応に必要なドキュメント
第6章 システム障害対応力を高めるツールと環境
第7章 組織の障害対応レベル向上と体制づくり
第8章 システム障害対応力の改善と教育 Appendix 難易度の高いシステム障害ケース

自分が障害対応時に行っていることは書かれていることとズレが少なかったので間違ったことをしていたわけではないのだろうと自信が少しだけ持てた。
特に以下のことを気にしながら僕は障害対応をしている。

  • 不明なことは不明と言って早めに広報
  • 復旧と言える状態の合意
  • 事実と仮設を混同せず作業をする
  • 振り返りを行う

特に振り返りは必要だろうなと思っておりポストモーテムを記載をするようにしている。
主に記載しているのは以下。

  1. 概要
  2. 障害原因
  3. 行った暫定対応
  4. 行うべき恒久対応
  5. 障害対応時系列記載
  6. 作業中に起こしてしまったまたは気がついてしまったヒヤリハット
  7. 広報した宛先、内容

1〜4 はトラブル自体、対応した内容について記載しているので当たり前だと思う。
5 の時系列に書かれている対応は後で読み返してみると対応方針や調査手段などを学ぶのにとても役立つ。他にも、復旧までにかかった時間がわかるので次回起きたときにユーザが影響受けるのがどれくらいか、復旧するために時間がかかってしまっているのがどこかを調べることができる。時間がかかっている箇所の手順を見直したり、ツールを開発することで障害復旧までの時間が短縮できる部分を見つけることができるので良いなと思っている。
またヒヤリハットでは作業ミスしそうになったこと、今回の障害とは直接影響ないが同じような障害がいつか起きそうなことが分かったなど次の障害の兆しを見つけるヒントになることが多いと思うのでオススメ。
これ以外にも必要なものなどあったら追加していきたいなと思っているので、みんなどうしているのか話し合ってみたりしたい。

まとめ

  • 効率的に障害対応について学べるなと思った
  • 今の自分たちが行っている障害対応について考え直してみようかなと思った
  • 公開されている障害情報や報告書を読んでみようと思った

*1:ここまでの言い方ではなかった

*2:障害が起きることを推奨しているわけではない。障害は起きないに越したことはない