「事前に決めた小さなこと」が迅速な障害対応に貢献
続いて、野村氏はこの3つのポイントを抑えた具体事例を2点紹介した。
1点目は、ログを収集してダッシュボードで出すという管理システムにおいて、システム更改を終えてチームが縮小し、ベテランから若手にバトンを渡すケースだ。
プロジェクトのスケジュールに余裕がある場合は、事前に復旧手順を決めておけばいい。ところが実際にはギリギリのスケジュールでリリースにこぎつける場合も多く、「障害対策についてはリリースしてから考えよう」と先送りにされることが珍しくない。
野村氏はこうした状況について、「率直に言えば、先送りにされた障害対策がリリース後、本当に検討されることは稀だ」と話す。「たいていの場合、問題はそのまま放置され、数年後に大規模障害が発生したときに苦しい思いをする」。“喉元過ぎれば”の対応は、大きな時限爆弾というわけだ。
こうした状況を避けるために、野村氏は最低限の対応として「『大規模なシステム障害』の定義と、それぞれの障害パターンにおける関連組織を決定する」ことを勧めている。これ自体はそれほど負担のない意思決定だが、「ここを定義しているかどうかで、大規模障害が大きな被害をもたらすのか、小さな被害で抑えられるかを左右することが分かってきた」。
野村氏の経験によれば、多くの現場では経験の浅いエンジニアが大規模障害の定義を使いこなせていないという。そうなると、何を基準に「大規模なシステム障害」とするかに迷ってしまい、様子見をしているうちに被害が広がってしまう。これを防ぐためには、「5分間のオンライン処理が5件以下になっていたら、ベテランエンジニアのAさんに連絡」というふうに、障害の定義と初動対応を決めておくことが重要というわけだ。
このような事前準備は、サイバー攻撃への対応にも欠かせない。大規模なサイバー攻撃は数年に一度程度しかなく、何をもって攻撃とみなすべきかを迷わず断定できるエンジニアは少ない。加えて個人情報の流出などがある場合、巻き込むべき部署も変わってくる。そのため基準を「国外からのウェブアクセスが10秒以内に1000件以上」のように明確にしたうえで、セキュリティ担当者や広報など、関連部署と速やかに連携することが顧客と自社を守ることにつながるのだ。
「『障害』の定義と対応策の決定は、せいぜい1時間程度の会議で決められる。話し合いを通じて不明点を明らかにするだけでなく、不安を解消することにもつながる。私の経験上、『事前に相談しておきたい』という相談には前向きに応じてくれる人が多いので、ぜひ実施してほしい」（野村氏）。
