🔥

【汎用ソフトスキル】本番障害対応のやり方

2022/02/21に公開

障害

この記事の目的

障害対応をなんだかんだでやり続けているので、その知見をアウトプットにしたくなった。

想定読者

今まさに障害が起こって、対応しなきゃいけないけどどうしようかパニクって「障害対応」でググっちゃった人
システム運用任されたけど、何かあった時に何すればいいのかわからん、という人
障害復旧のために本番環境触るのが怖くてたまらない人

想定読者ではない人

障害対応になれてる人
- 自分なりのルーチンができているなら多分それが一番いいと思います
開発者が自分1人の会社で働くエンジニア or それに近い環境の人
- 組織やら意思決定やらの話が入ってきます

書いている人のスペック(参考)

歴５年くらいのなんちゃってフルスタックエンジニア
普段は Node.js / React.js or React Native あたりでアプリ制作をしている。たまにインフラぽちぽちする。(I ♡ aws-cdk)
３年くらい所属している会社は「運用」と「開発」で部門が分かれていないので、本番障害の対応などもあれば対応もするポジション

障害対応のやりかた

概要

STEP1 まず落ち着く
STEP2 関係者に速報を入れる
STEP3 暫定対応をする
STEP4 恒久対応をする

文章にするのは初めてですが、多分こんな感じだと思います。
ちなみに、この中で一番大事なのは STEP1「まず落ち着く」 だと思います。
早速みていきましょう。

STEP1 まず落ち着く

本番障害発生。ダッシュボードに赤いアラートが灯る、サーバが何をしても 503 を返すようになる、スマホアプリがロード状態でハングして何も動かなくなるーーー
エンジニアをしばらくやっていれば誰しもが経験する、最悪に近い状況の一つです。

しかし、この状況はまだ最悪ではありません。まだ下があります。
これよりも悪い状況、それは二次障害です。 障害対応でさらに大きな障害を引き起こすことは、残念ながらしばしばおこります。
まずは落ち着きましょう。

本番環境には、テストや品質チェックを通ったものがリリースされています。
しかし、今からあなたがする恐ろしい「暫定対応」というやつは、大抵の場合そうではありません。
少しのコマンドの打ち間違えで、あるいはほんのわずかな勘違いで、システムはさらに致命的な被害を受けます。

ならせめて先に関係各所に連絡を？それもあまりお勧めできません。
今、おそらくあなたはパニックを起こしています。
そんな状態でわかりやすく、的確な情報提供ができるでしょうか？
本番障害はビジネス ~ 開発者まで、広く影響を与えることが多いです。
多くの関係者に 伝わる言葉で 過不足なく情報を提供する ことはこれまた難しいです。

まずは一旦落ち着きましょう。
一旦モニタの電源を落とし、席を立ち、暖かい or よく冷えたコーヒーを飲みましょう。紅茶でもいいです。
結果として「最も効果的に障害が収まればいい」のです。冷静に、あらゆる手段を検討しましょう。

過去発生したgitlabの大規模障害では、そのトリガを引いてしまったエンジニアが、
「もう今日は自分がこれ以上sudoコマンドを実行しないほうがいいだろうと言って、リストア作業を同僚に依頼する」という対応をしたそうです。
「自分の発生させたインシデントの対応を同僚に任せる」というのは無責任のように感じてしまえる選択ですが、
これは「自分の状態を冷静に分析した最も責任感のある判断」だとおもいます。

岡目八目。当事者ではない人ほど最も冷静な対応ができます。
もし、あなたがチームで開発しているようであれば、同じチームの仲間に声をかけ、手伝ってもらいましょう。

STEP2 速報を入れる

落ち着きましたか？それでは次のステップです。
障害発生時に連絡すべき人が決まっていれば、その人に速報を入れましょう。
決まっていないなら、とりあえずあなたの上長に報告を入れましょう。
STEP3ではビジネス上の意思決定が必要になることが多いので、その権限がある人と連絡をつける必要が出てきます。

この際大切なのは「現状でわかっていることだけを伝える」ということです。

例えばリリース直後、本番環境のサービスが常に503を返す様になってしまったとします。
おそらく原因は直前のリリースです。システムログを見たカンのいいあなたは、「あっ、原因がわかったかもしれない！」となり。。。
はい、これがよくやってしまう本番対応の初動ミスです。

落ち着いたあとにまずすべきことは速報であり、原因調査ではありません。
カンが冴えていれば良いですが、そうでなかった場合、不要に速報を入れるタイミングが遅くなってしまいます。
(そして、焦っているときの人間のカンはあてになりません)
この場合であれば、まずシステムログを見る前に以下の内容で速報を入れましょう。

【概要】
本番環境で障害が発生

【影響範囲】
全てのユーザがサービスを利用できない

【現状】

サービスが常に503を表示するようになっている
リリース作業を行った直後から発生している
現在調査中
おそらく先程のリリースが原因で、すぐに復旧できる可能性あり
判明次第続報を入れます

大事なのは「続報を入れる」として速報を打つことです。
システムに障害が起こっていることがわかれば、運用やサポートで取れる選択肢が増え、ビジネスへのダメージを抑えられることも多いです。
まずは最初にわかっていることだけをまとめましょう。

STEP3 暫定対応をする

速報を入れたら次は暫定対応です。
暫定対応のゴールは本番障害におけるサービスの損失を最も少なくすることです。
あらゆる手段が選択肢になります。メンテナビリティ / 仕様の正しさ / 手順の正しさ / 設計思想など、普段の開発で考えるべき長期視点の話は一旦すべて忘れましょう。

情報をあつめて対応方針を決めよう

対応方針がみつかるまで、調査しつつ情報を整理しましょう。
いくつかポイントを書いておきます。

1.調べた内容はすべてメモをとろう

「わかったこと」はもちろん「調べたけど意味がなかった」ことも、調べたことは全部メモしましょう。
「調べたけど効果がなかった」という情報は、後の調査の役に立つことが多いです。
「システムログには障害の原因が特定できるログが出ていなかった」という情報があれば、「障害の原因をすぐに特定することは困難である」という事が判断できるかもしれません。
暫定対応は時間との勝負です。障害の正確な原因が判明するまで、暫定対応の実行を待てないかもしれません。
「今はわからない」という情報は、大切な情報の一つです。

２.様子見の暫定対応という選択肢がある

先の例のようなリリース直後の障害の場合、「一旦システム旧バージョンにロールバックして様子を見る」ということをまず試すと思います。
この方針は「リリースが原因でなかった場合、システムの問題が解決しない」というリスクをはらんでいます。
しかし、その場合でも「リリースは障害の原因ではない」という情報が得られます。今回のリリースされたコード以外の原因を調査すれば良くなり、障害の解決に向けて大きく前に進みます。
発生するリスクが許容できる場合、「解決策である確率が高い暫定対応をとりあえず入れてみる」というのは、強力な選択肢です。

3.必要なら意思決定をしよう

障害の規模や原因によっては、運用担当者だけでは有効な暫定対応が取れないことがあります。
うまく意思決定者を巻き込みましょう。

1.意思決定者でないと取れない選択肢が必要なケース
これは「強い権限を持った人でないと下せない決断が最適解であるケースがあるため」です。
わかりやすい例で言うと「大規模なセキュリティインシデントが発生した場合、システムをすべて一時的に停止する」が暫定対応として最も有効なものになります。
この決断は、運用担当者の独断では下すことができないことが多いでしょう。

２.意思決定者のほうが判断に使う情報を多く持っているケース
暫定対応では「今見つかっている選択肢の中で、もっとも効率がよさそうな暫定対応」を選ぶ必要があります。
持っている情報の多い意思決定者でないと見えない影響や、懸念事項があるケースです。
「リリース後の障害で、ロールバックすればすぐに動くことがわかっている」状態でも、
「明日までに正常稼働していないと会社が潰れる」みたいな状態であれば、
「暫定対応は入れずに原因を調査する」というのが最適解になるでしょう。

本番対応をしよう

対応方針が決まったら、恐怖の本番対応です。
会社に決まったルールがあれば、かならずそれを守りましょう。
ルールに書いてなくても、以下は意識することをオススメします。

やることを書き出してチェックリストにする
- 実際に行う本番操作
- 障害が解消されたことの検証
- 他に影響は出ていないかの検証など
可能であれば、検証環境でそのチェックリストの内容を実行して練習する
本番対応を入れることを周知する
チェックリストの内容は一つずつ実行する
絶対に一人でやらない/ダブルチェックする
想定外のことが起こったら一旦対応をやめる/慌ててリカバーしようとしない

障害が解決し、他に悪影響が出ていないことがわかれば、とりあえ障害対応は完了です。
おつかれさま✋

STEP4 恒久対応をする

さて、ここまでくればもうシステムは正常に動いています。
しかし、障害対応はコレで終わりではありません。
とはいえ多分あなたは本番対応でヘトヘトだとおもうので、できればこのSTEPは翌日以降にやりましょう。
脳みそを「障害対応モード」から「通常モード」に戻しましょう。

後片付けをしよう

暫定対応が終わったあと、そこに残されたものは本来想定された仕様や設計とは異なるものになっています。
それを本来あるべきものに寄せていきましょう。
STEP2で忘れたメンテナビリティ / 仕様の正しさ /　手順の正しさ　/ 設計思想などを取り戻す必要があります。
あなたも私も仕事はいつも忙しいので、かけられる時間は多くはないかもしれません。
それでも、アラートが鳴り止まない暫定対応の前よりはずっと多いはずです。
この時間を作るために暫定対応というの急いでやったのです。いつものやり方で、プロダクトをあるべき姿に戻していきましょう。

再発防止策を考えよう

後片付けと並行して、「同じことを繰り返さない方法」、すなわち再発防止策を考えましょう。

ここでのポイントは、その方法は 個人の努力に属するものであってはならない ということです。
もっと注意する / 担当者を罰するなどは再発防止策ではないです。

その理由は「そんな組織で働きたくないから」。。。という働く人間側の理由も勿論ありますが、
組織視点の理由もあります。
それは、「明日から成果が出る方法である必要があるから」ということと、「人間はそんなにすぐに成長しない」からです。
心構え一つで明日から絶対に失敗しなくなるほど人間は便利ではありません。

バグの見落としが原因であれば、適切な検証フローの追加する。
仕様の不整合であれば、適切な調査や保守計画を敷き直す。
極論、エンジニアが勉強不足でよくわからんコードを本番に入れたことが原因なら、コードをレビューせずに本番に入れる体制をつくる。

再発防止策というのはそういったものです。「現在の人員が変わらなくても結果を出す」方法で解決策を考えましょう。
自分のミスが原因だとなかなか言いづらいこともあるので、再発防止策はチームで相談して行うほうが望ましいです。
（ビジネス上あまり問題がない障害の場合、「再発を許容する」という選択肢もあるので）

あ、余談ですが、よくわからんコードを本番に入れるエンジニアはまず仕事のやり方をなんとかすることをおすすめします。本番対応以前に。

報告書を書こう

さて、長かった本番対応もこれで最後です。
今回のSTEP1~4までの対応を振り返り、ドキュメントにして見れるようにしましょう。

ここで大切なのは、本番障害の報告書とは決して担当者の反省文ではないということです。
本番障害の報告書は「津波が来るから家を建てるな」という石碑のようなものです。
後でそのシステムに関わる他人（まれにあなた自身)が見返し、同じ過ちを繰り返さないためにたいへん役に立ちます。
実際、私は過去の報告書を使って「今検討されている仕様だとこの障害の引き金になるからだめだな？」という議論をしたことがあります。

「後に同じ失敗をしないために失敗したんだ」という転んでもタダでは起きぬメンタルで書きましょう。

発生原因
事業に出た影響
暫定対応の内容
後片付けの内容
再発防止策

あたりが記録として残っているとベストかと思います。
残念ながら本番障害はそのうちまた起こるので、テンプレートがあるといいかもしれません。

最後に:本番障害の報告者を称賛しよう/されよう

さて、本番障害が起きたときに私がすること、というのは以上で書きれたかなぁとおもいます。
私自身、未だに本番障害が起こる焦るので、実際に出来ているのはここに書かれたことの7割ぐらいかなぁとおもいます。
特ににSTEP1が未だにできない。焦る。修行がたりませんね。

最後にちょっとだけ補足として、担当者本人ではなく、周りの人も向けた本番障害についてのことを書いておきます。
それは、「障害発生時に担当者を叱責してはいけない。むしろ褒めたほうがいい」ということです。
「自分がやったことに自分自身で責任を取らなくてはならない」という思考は、こと障害対応においては邪魔です。
自分の手にあまる作業を一人で実施しようとしたり、冷静な思考を阻害したり。二次障害を招くきっかけになります。
また、「障害を発生すると叱責される」というのが常態化すると、本番障害が起きないことの優先順位が不当に高くになり、歪んだ設計や手順がつくられかねません。もっとひどいと、障害をひた隠しにする悪しき文化が出来てしまうかもしれません。

これは実体験なのですが、本番障害を報告したら称賛されるくらいが一番組織として効率がいいと思います。
私がまだ運用を仕事してやることになって間もない頃、私は自分が実装したコードでそこそこな本番障害を起こしてしまいました。
そのときの上長はよく出来た人で、私が障害を報告するといの一番に「まずはよく報告してくれた。言いづらかっただろう」といってくれました。
まだ運用経験が浅く、焦っていた私はその一言でなんとか冷静さを取り戻し、おぼつかない手順ながらもなんとか暫定対応 ~ 恒久対応を行うことが出来ました。

本番障害は残念ながらどんなサービスでも起こります。
起きたときにいかに上手く対応ができるか / いかに上手く対応させることができるかが、
エンジニアの / エンジニア組織の腕の見せ所だろうなぁと思います。
慎重に、でも臆せずやっていきましょう。