Postmortem

「ポストモーテム みずほ銀行システム障害 事後検証報告」を読んでみての感想

midnight480
この記事は書評ではなく、筆者自身の過去経験や考えの記事となっています。ご了承ください。 書籍 ポストモーテム みずほ銀行システム障害 事後検証報告 ポストモーテム - postmortemについて 言葉の意味としては、「検死解剖」に該当しますが、 ことITでは「事後分析」という意味合いで使われています。 このポストモーテムはGoogleが提唱したSRE(Site Reliability Engineering)で記載されたことで、 今では業界では一般的に意味が通じることになっているかと思います。 SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム この Postmortem に関する記載はGoogleが公開していますので、 さらに知りたい方は次のサイトに訪れてみてください。 インシデント発生時の対応記録表のサンプルもあります。 Google - Postmortem Culture: Learning from Failure 「The cost of failure is education.」とは、正しくそのとおりだと思います。 私自身も自ら失敗を引き起こすこともありましたし、また巻き込まれたこともあり、 この書籍を読みながら、「あのときは〜」や「近いことがあったな〜」など思い返すとともに、 そういった経験を偶然にも積み重ねることができたことで、 今のエンジニアの端くれとして生きている自分があるのかなと思います。 過去に参加した翔泳社主催のデベロッパーサミットでも以下のようなセッションがあり、 「そうだよなぁ」と思いました。 トラブルこそ成長の機会――「手のかからない」インフラを目指してオンプレからクラウドに移行した60日間の奮闘【デブサミ2020】 機会は平等ではない=成長する機会は平等には訪れない。 大事なことは積極性=成長する機会を得るには、やはり積極性が必要。 一歩踏み出す勇気=トラブルが発生していたら、進んで手を貸そう。 書籍を読んで振り返ってみた アプリケーションタイムアウト 当初読んでいるときは、 機器で異常な状態になっていたのでアプリケーション側で想定時間を超えたと見ていました。 どうも読みすすめるとアプリケーションが 最小 の時間でタイムアウトを設定していたことで、 ネットワーク機器自体は規定の 最大 の時間を掛けて切り替わった後、 アプリケーション側で時間内に応答がなくサービスが止まったとありました。 これは実装時に 最大 時間で設計・実装していれば防ぐことができてのではないか?と思います。 また、経路におけるそれぞれのタイムアウトをきちんと把握することが必要で、 例えば、一般的なWebアプリケーションでロードバランサ-Webサーバ間、 Webサーバ-APサーバ間などのそれぞれのタイムアウト値が異なっていないか、 異なっている場合は、想定されるクライアントへの影響はどういったものがあるかといったことが挙げられるかと思います。 そういった情報が可視化、記録されている情報へ即座にキャッチできる状況としておくことの重要性を改めて認識しました。 テスト不十分 本番環境での切り替え作業で、実行可能な件数が上限に達したためDBの更新ができなかったとありました。 テストで実測した想定件数に対して、実際に本番環境で実行した件数が多かったため、発生しているものですが、 書籍では踏み込んでいないので不明なところが、どうやってその想定件数でテストしたものを良しとしたかです。 テストをする上でパターンは仕様を満たしているか1、など色々とあると思いますが、 実際の件数が多かったため、というのは最近のシステムでは聞いたことがありませんでした。