今日から新しい内容、緊急対応についてみていきます。
前置き
組織の長期的な健全性に寄与するものの一つとして、緊急事態において、人々がどのように対応するかが挙げられます。
しかし、緊急事態に初めから適切に行動できる人はほとんどいません。
適切な対応をするためには、準備に加えて、定期的なハンズオントレーニングが必要になります。
この章では、緊急対応においてのインシデントの具体例について学んでいきます。
そして、どの緊急対応においても、以下の点を念頭に置く必要があります。
- まずパニックにならない。
- 圧倒されてしまうなら、多くの人を巻き込む
- インシデント対応の手順があれば、それに馴染んでおく
テストによって引き起こされた緊急事態
Googleは、障害や緊急事態のテストについて、予防的なアプローチをとっています。
故意にシステムに障害を起こさせ、その障害の様子を観察します。
コントールされた障害は、通常予想通りに動作しますが、それが想定を超える場合があります。
テスト内容
テストの目的は大規模な分散MySQLデータベースの1つにあるテスト用のデータベースへの隠れた依存関係を洗いだすことでした。100個あるデータベースの中の1つのデータベースへのアクセスをすべてブロックするというテストが行われました。
レスポンス
テストが始まってから、数分の内にこのデータベースに依存していた無数のサービスから社内、社外からユーザーが重要なシステムへアクセスできないという報告が上がりました。
断続的、部分的にアクセスできるシステムもありました。
即座にテストを中止し、ロールバックを行おうとしましたが、それは上手くいきませんでした。
しかし、パニックにならずに、話し合い、テスト済みのアプローチからパーミッションのリストアを行いました。
障害の回復後に問題のライブラリ群は素早く徹底的に調査され、問題が起こらないように修正と定期的な再テストの計画が立てられました。
障害からわかったこと
うまくいったこと
- コントロールから離れたしまったテストを即座に中止するという判断ができた
- 最初の報告があがってから、1時間以内に障害の回復ができた。
- 同じような問題が起きないように丁寧に修正され、定期的なテストが行われた。
悪かったこと
- テストにおける影響範囲を理解した上で行われていると思っていたが、実際には依存関係にあるシステム間のやり取りに関して、理解が足りなかった。
- インシデントレスポンスは作られていましたが、その周知が足りなかったため、それに従うことができなかった。そのレスポンスの中では、サービスや顧客がサービス障害を認識することを保証するはずでした。
- ロールバック手順のテストを行っていなかった。
まとめ
- システムの理解不足や周知不足、準備不足があると、障害が大きいものになってしまう。
- テストの際は、テストの周知とロールバックテストのを徹底して行う必要がある。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 157-159