障害対応の夜に思い出す、あの本の 1 ページ

この記事は約 5 分で読めます。

深夜 2 時、アラートが鳴る

本番環境のレスポンスタイムが急激に悪化している。ダッシュボードは真っ赤。Slack には「お客様から問い合わせが来ています」の通知。チームメンバーが次々とオンラインになる。

こういう場面で、頭の中に浮かぶのは直近のコード変更だけではありません。過去に読んだ本の、ある 1 ページが不意に蘇ることがあります。

知識は「使うとき」に価値が決まる

データベースのロック競合でシステムが詰まっていた。原因の切り分けに手間取っていたとき、半年前に読んだデータベースの本の一節を思い出した。「ロック待ちが連鎖するとデッドロックに至る。まず SHOW PROCESSLIST でロックを保持しているセッションを特定せよ」。

その 1 ページの知識で、原因特定までの時間が 30 分短縮された。30 分は、深夜の障害対応では途方もなく大きい。

読んだときは「ふーん、そういうこともあるのか」程度の感想だった。しかし、その知識が必要になった瞬間、本の価値は何倍にも膨れ上がります。

障害対応で効く知識の種類

障害対応の現場で役立つ知識は、コードの書き方ではありません。以下の 3 種類です。

1. 原因の切り分け方

「レスポンスが遅い」という症状から、原因がアプリケーション層なのか、データベース層なのか、ネットワーク層なのかを切り分ける手順。この手順を知っているかどうかで、対応速度が桁違いに変わります。

パフォーマンスチューニングの本には、この切り分けの手順が体系的に書かれています。

2. ツールの使い方

top、vmstat、iostat、tcpdump、strace。これらのコマンドの存在と基本的な使い方を知っているだけで、障害の原因に迫るスピードが変わります。普段使わないツールほど、障害時に真価を発揮します。

3. 過去の障害パターン

「この症状は、典型的な○○のパターンだ」と認識できれば、対応方針が即座に立ちます。障害パターンの知識は、自分の経験だけでなく、本を通じて他人の経験からも学べます。

「いつか役立つ」を信じられるか

技術書を読んでいて、「これ、自分の仕事に関係あるのかな」と思う章があります。データベースのレプリケーション、ネットワークのパケットロス、カーネルのメモリ管理。普段の開発では意識しない低レイヤーの知識。

こうした知識は、平時には使いません。しかし、障害が起きたとき、この知識があるかないかで対応の質が決定的に変わります。

消防士が火事のないときに訓練するように、エンジニアも障害のないときに知識を蓄えておく。技術書を読むことは、障害対応の訓練でもあります。

障害対応力を高める読書のコツ

読んだら「もし自分のシステムで起きたら」を考える

本に書かれた障害事例を読んだら、「もし自分が担当しているシステムで同じことが起きたら、どう対応するか」を 30 秒だけ考えてください。この 30 秒のシミュレーションが、実際の障害時に「あ、これ読んだことがある」という反応速度を生みます。

インフラ系の章を飛ばさない

アプリケーション開発者は、インフラやデータベースの章を飛ばしがちです。しかし、障害の原因はアプリケーション層だけにあるとは限りません。インフラの基礎知識があるだけで、障害対応時のコミュニケーションが円滑になります。

ポストモーテムを読む

自社の過去の障害報告書 (ポストモーテム) を読むのも、優れた読書です。「何が起きて、どう対応して、何を学んだか」が凝縮されています。他社が公開しているポストモーテムも参考になります。

関連記事

• エラーメッセージを読めるエンジニアは何が違うのか
• エラーが出たときこそ本の出番

まとめ

障害対応の夜に助けてくれるのは、半年前に読んだ本の 1 ページかもしれません。原因の切り分け方、ツールの使い方、過去の障害パターン。これらの知識は平時には使いませんが、有事に決定的な差を生みます。「いつか役立つ」知識を信じて読み続けることが、エンジニアとしての底力を作ります。