この記事は書評ではなく、筆者自身の過去経験や考えの記事となっています。ご了承ください。
書籍
ポストモーテム - postmortemについて
言葉の意味としては、「検死解剖」に該当しますが、
ことITでは「事後分析」という意味合いで使われています。
このポストモーテムはGoogleが提唱したSRE（Site Reliability Engineering）で記載されたことで、
今では業界では一般的に意味が通じることになっているかと思います。
この Postmortem に関する記載はGoogleが公開していますので、
さらに知りたい方は次のサイトに訪れてみてください。
インシデント発生時の対応記録表のサンプルもあります。
Google - Postmortem Culture: Learning from Failure
「The cost of failure is education.」とは、正しくそのとおりだと思います。
私自身も自ら失敗を引き起こすこともありましたし、また巻き込まれたこともあり、
この書籍を読みながら、「あのときは〜」や「近いことがあったな〜」など思い返すとともに、
そういった経験を偶然にも積み重ねることができたことで、
今のエンジニアの端くれとして生きている自分があるのかなと思います。
過去に参加した翔泳社主催のデベロッパーサミットでも以下のようなセッションがあり、
「そうだよなぁ」と思いました。
トラブルこそ成長の機会――「手のかからない」インフラを目指してオンプレからクラウドに移行した60日間の奮闘【デブサミ2020】
- 機会は平等ではない＝成長する機会は平等には訪れない。
- 大事なことは積極性＝成長する機会を得るには、やはり積極性が必要。
- 一歩踏み出す勇気＝トラブルが発生していたら、進んで手を貸そう。
書籍を読んで振り返ってみた
アプリケーションタイムアウト
当初読んでいるときは、
機器で異常な状態になっていたのでアプリケーション側で想定時間を超えたと見ていました。
どうも読みすすめるとアプリケーションが 最小 の時間でタイムアウトを設定していたことで、
ネットワーク機器自体は規定の 最大 の時間を掛けて切り替わった後、
アプリケーション側で時間内に応答がなくサービスが止まったとありました。
これは実装時に 最大 時間で設計・実装していれば防ぐことができてのではないか？と思います。
また、経路におけるそれぞれのタイムアウトをきちんと把握することが必要で、
例えば、一般的なWebアプリケーションでロードバランサ-Webサーバ間、
Webサーバ-APサーバ間などのそれぞれのタイムアウト値が異なっていないか、
異なっている場合は、想定されるクライアントへの影響はどういったものがあるかといったことが挙げられるかと思います。
そういった情報が可視化、記録されている情報へ即座にキャッチできる状況としておくことの重要性を改めて認識しました。
テスト不十分
本番環境での切り替え作業で、実行可能な件数が上限に達したためDBの更新ができなかったとありました。
テストで実測した想定件数に対して、実際に本番環境で実行した件数が多かったため、発生しているものですが、
書籍では踏み込んでいないので不明なところが、どうやってその想定件数でテストしたものを良しとしたかです。
テストをする上でパターンは仕様を満たしているか^1、など色々とあると思いますが、
実際の件数が多かったため、というのは最近のシステムでは聞いたことがありませんでした。
以前はよくあったパターンとしては、
本番環境と比べて検証環境や開発環境では費用面から環境差異（サーバスペックを抑えたものばかり）で、
本番環境に出たとこ勝負という面があったかと思います。
今回は金融機関でありマルチベンダー策におけるハードウェアが多岐にわたることで、この環境差異が起きていたのかなと推測しました。
とはいえ、私自身も1年目の頃に、初めて任されたPG開発でデータベースに格納している日付（文字列型）の加減算するロジックで、
本来は、DATE型への変換や共通で定義されているファンクションを使うべきのところを理解が足りておらず、普通に式で書いてしまい、
かつ、テストフェーズでは同月内の日付のみ行っていたことで正常に通ってしまい、
本番環境に出て初めて月跨ぎで異常な値が設定されることが発覚したことがあります。
そうした経験からテストの重要性を認識しました。
RDMSの統計情報
書籍を通じて一番驚いたのが、運用でRDBMSの統計情報を元に運用していたことです。
私自身は、新卒から関わっていたプロジェクトが大規模なOracleDBを使っていたこともあり、
またオプティマイザが算出する都度、最適な実行計画が採択されるかもしれませんが、
一方でコストの掛かる実行計画となる可能性を潰している環境にいました。
要は、統計情報をOFFにして、SQLは必ずヒント句^2を書くという文化です。
特にミッションクリティカル、様々なシステムとデータの連携が必要で連携を行う時間が定時で決まっている環境では、
そうすることが当然だと刷り込まれていました。
そういった環境である程度経験を積んでから、
Oracleのイベントに参加したときに「ヒント句は最終手段で〜」と聞いたときは、
衝撃を受けました。。
とはいえ、そういった環境で学んだことでデータを操作する際は、
どういうようにテーブル間を結合するべきだ^3とか書き方^4について、
一般的な環境では考える必要がないことも考慮できる力は身につけることができたと思います。
ストレージのコントローラ異常
こればかりはストレージベンダーのファームウェア次第なところが多分に占めていると思います。
私自身も実際の現場で見たことはありませんが、
人が作っているものには完璧なものはないと思っています^5。
また、大手のストレージベンダーも初期時点では不具合がないものの、
稼働時間が一定を超えると突然発生することも過去にあります[^6][^7]。
NIC故障
経年劣化だと起こりやすくなるのは周知の事実かなと思います。
実際にNIC自体の故障に伴うサーバ停止、物理基盤の交換を見守って、
サーバ起動後の正常性確認もあります。
初めて見たケースとしては、企業内だと当然のように接続しているSFPにおけるケーブルの光量不足でした[^8]。
あるとき、データベースのスローダウンと思われるI/Oの遅延に気づいてハードウェア保守担当者に確認をしても、
「特にアラートは検知していない」という回答で、しかしながらI/Oは遅延しているので前述したヒント句の異常か？など、
色々な要因を検討している段階で、「どうもケーブルの光量が減衰しているようだ」とのことでした。
10年近く稼働していて、特に完全停止する期間もなかったことから起こりうるんだなと改めて認識しました。
処理実行タイミングの異常
これは何か起きたときの障害対応で、2次障害として起きやすいものでした。
よくある定時起動バッチ処理で一部が異常終了となった際に、
後続が正常であれば待ち合わせなしで起動しても影響がないものが、
異常な状態になって初めて気づくことができました。
特に規模が大きければ大きいほど制御が難しいところもあります。
気づいたときに、次発生しないように記録と対応をしていました。
データの異常（ゼロ件処理）
こちらも何か起きたときの障害対応で、2次障害として起きやすいものでした。
何かしら異常なデータがあり異常終了が発生し、
そのデータに対してはトリアージを行い正常に戻した後に、
「ふぅ...」と息をついて直後の処理も正常終了したからと過信して、
実際の処理結果が0件であることに気づいて慌てて停止させて、
先頭から再度やり直しということもありました。
以降は必ず戻り値だけで判断するのではなく、実際に処理を行った件数や、
データまで確認した上で後続の処理を再開させる癖が付きました。
運用軽視
これは悲しいことに過去に経験があります。
やはりITエンジニアの多くはモノづくり（コーディング）を行うことに目が行きがちとは思いますが、
サービスインしてからが本番ではあるので、どうも運用を軽んじている風潮を体験しました。
また、運用を行っている方々に対しても「マニュアル以外のことはできない」といったこともあったりと、
個人的には「確かに、業務上はマニュアル以外にはできないかもしれない。だが、選択肢を与えることも必要だ」と思ってはいます。
もしかすると中には「マニュアル以上のことはしなくていい。それで飯が食えればいい。」と割り切っている方がいるかもしれませんが、
それでも踏み込んで改善していきたいと思う人がいると思っています。
あとはそういった声をどう拾って、どう繋げていくか、かなと思います。
開発フェーズから保守フェーズへの移行で人員削減
こちらも悲しいことに過去に経験があります。
確かに保守フェーズになって開発フェーズの人数が全員必要はなく、
次の開発フェーズへの参画を促して、バリューを発揮してもらいたいという人的リソースのコントロールする側の気持ちもわかります。
一方で、開発時の仕様などを全く把握していないメンバに十分な引き継ぎもなく保守を渡すのは違うと思います。
ではどのくらい残すと最適なのか？ということについては正解はないですが、少なくとも0人は違うというのが個人的な考えです。
実際に私は1年目で右も左も分からない中、基礎も無い中で1回1〜2時間の引き継ぎ会で聞いたシステムの担当にもなったことがあり、
半年後にちょっとしたトラブルでデータの不整合状態に関する問い合わせで十分な回答ができず、
その後「なんですぐに答えられなかったの？」と問われて「いきなり担当に割り当てられたため」とは言えず悔しく思いました。
そうしたときに、なりふりかまっていられず、資料から当時の開発担当者たちの情報をかき集めて、聞きまわる経験も得られましたが、
それは今の精神衛生上はよくないことなので、作ったものは引き継がないとなとは思います。。
説明会だけではなく実際に引き継ぎ先に作業を回してもらうことを数回は見ないとはと思います。
振り返ってみて
個人的には、アプリケーション運用保守エンジニアから、インフラ運用保守、クラウド設計とキャリアを積んできましたが、
今回の書籍に記載されている事項に近い事象に出会えたのは、アプリケーション運用保守であった新卒から3年以内に色々と起きすぎて、
その経験値が今でも基礎になっているなと思いました。
かといって、その経験を今改めてしたいですか？という問いには食い気味でNoと答えます。
色々なスタックで発生したことを経験できたのは自分の財産ではありますが、それらを引き継ぐというのは難しいなという形でまとめとします。
[^6]: HPEのサーバー向けSAS SSD、稼働32,768時間超えでデータ喪失。復旧も不可
[^7]: 50自治体システム障害続報、不具合は米デルのストレージで発生
[^8]: SFPモジュールの光信号強度を確認する方法