システム障害起きたときの焦りってすごいよね

この記事はこんな人へ

エンジニアがシステム障害に向き合うときに心がけていることを知りたい方

システム障害とは、システムの問題により正常に動作することはできなくなった状態のことを言います。

ひとえにシステム障害と言えど、アクセスが集中したことによるサーバーダウンやランサムウェアによる障害、仕様の理解不足による誤ったコード記述など理由は多岐にわたります。

手作業でどうにかなるようなシステムならユーザ部門が手作業で業務を行いながら、システム部門が障害原因の特定をすることができますが、必ずしもそういったシステムだけではありません。

実際に障害発生時に行う作業について、例をもとに解説していきます。

例）
システム：レストランのオンライン注文システム
システムに存在する機能：注文機能、マイページ機能
発生している障害：3個注文したが、5個注文したことになっている。

障害が起きたらまずは「今何が起きているか」を確認します。

いたって普通のことのように聞こえますが、現状を把握しなければ障害解消のゴールにたどり着くことができないため書かせてください。

現状何が起こっているかについて、以下の点は必ず押さえなくてはいけません。

① どのシステムのどの機能にて障害が発生しているか。
② 障害が起きているものについてどのような状態が正しいのか。
③ ②と障害が起こっている内容について具体的にどのような部分が異なるのか。

今回の例を整理すると以下のようになります。

① どのシステムのどの機能にて障害が発生しているか。
⇒⇒レストランのオンライン注文システムの「注文機能」となります。

② 障害が起きているものについてどのような状態が正しいのか。
⇒⇒対象の商品を3個注文した状態

③ ②と障害が起こっている内容について具体的にどのような部分が異なるのか
⇒⇒対象の商品を5個注文した状態になっている。

現状の把握をしたら、その後は根本原因の調査を行います。システムは、システムを動かす土台のインフラとインフラ上で動くアプリケーションに大きく分けられます。

それぞれ障害が起きる可能性の原因の一例をあげると以下のようになります。

インフラ側（一例）
・想定を大幅に上回る人数がアクセスしたことによるサーバダウン
・サーバに高負荷をかけてサーバを落とすDDos攻撃
・サーバに使用している機器の故障
・クラウドシステムがサービス停止

アプリケーション側（一例）
・設計書の仕様通りにコーディングされていなかった。
・設計書の内容が要件と異なっていた。
・定義した要件に差異があった。
・システム全体を考えた場合、障害が発生するようになってしまっていた。

今回の例ではアプリケーション側に「設計書の仕様通りにコーディングされていなかった」ことが原因だったとします。

根本原因が判明したところで、リカバリ方法の決定に移ります。

リカバリ方法決定時に考慮しなければならないことは主に二点あります。

一点目は業務目線の考え方です。この障害が起きることによってユーザにどれほどの影響があるか。それは緊急の対応が必要なものか、ユーザへの補償はどうするかなどの視点が必要になります。

二点目は技術目線の考え方です。この障害の復旧作業を行った結果、他のシステムや機能への影響はないか、障害の復旧にかかる工数はどれくらいか、プログラムの改修の難易度はどれくらいかなどの視点が必要になります。

この段階になると、システムの全体像を知る人間が必要なことが多く、経験年数が1～2年の人間では対応できないことが多々あります。

結論、関係各所への調整やシステム全体像を知りながら、迅速な対応しなければいけないからめちゃくちゃきついっす。

ミスを起こさないコンピュータを作るのは、ミスをよく起こす人間という話。