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

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

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

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

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

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

データベースのロック競合でシステムが詰まっていた。原因の切り分けに手間取っていたとき、半年前に読んだデータベースの本に、待ちの形は二通りあると書かれていたのを思い出した。

一方向に待っているだけなら、前のトランザクションが終わるか、待ち時間の上限に達すれば解けます。互いに相手が持つロックを待ち合う形になっていれば、放っておいても解けません。もう 1 点、待たされている側を一覧することと、そのロックを握っている側を突き止めることは別の作業だという注意も書かれていました。MySQL なら、待ち側の見当は SHOW PROCESSLIST の状態列からもつきますが、保持側までたどるには InnoDB のロック情報を確認することになります。

この区別を思い出せたおかげで、待ち側の一覧を見比べるだけで時間を使う遠回りを避けられました。原因の当たりがつくまでの時間が数十分縮まる場面では、この差は小さくありません。

読んだときは「ふーん、そういうこともあるのか」程度の感想だった。しかし、その知識が必要になった瞬間に、本を読んだ意味が後から立ち上がってきます。

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

障害対応の現場で役立つ知識は、コードの書き方とは少し違うところにあります。筆者の経験では、主に次の 3 種類です。

1. 原因の切り分け方

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

パフォーマンスチューニングの本には、この切り分けの手順が体系的に書かれています。ただし本に載るのは一般的な構成を前提にした手順です。自分の環境では、その手順のどこにあたる装置が入っているか (キャッシュ、プロキシ、マネージドサービスなど) を平時に対応づけておかないと、有事に手順書として使えません。

2. ツールの使い方

top、vmstat、iostat、tcpdump、strace。これらのコマンドの存在と基本的な使い方を知っているだけで、障害の原因に迫るスピードが変わります。普段は出番のないツールでも、障害時には手がかりを得る唯一の手段になることがあります。

3. 過去の障害パターン

「この症状は、あのパターンに近い」と思い当たれば、対応方針を早く立てられます。障害パターンの知識は、自分の経験だけでなく、本を通じて他人の経験からも学べます。逆に、パターンに当てはめた時点で調べる手を止めてしまうと、似ているだけの別の原因を見落とします。当てはめたら、その仮説なら他にどんな症状が出ているはずかを 1 つ確かめてから進むのが安全です。

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

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

こうした知識は、平時にはほとんど使いません。しかし障害が起きたとき、この知識があるかないかで、その場で取れる手数が変わります。

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

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

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

本に書かれた障害事例を読んだら、「もし自分が担当しているシステムで同じことが起きたら、どう対応するか」を 30 秒だけ考えてください。この 30 秒を挟んでおくと、実際の障害時に「あ、これ読んだことがある」という反応につながりやすくなります。

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

アプリケーション開発者は、インフラやデータベースの章を飛ばしがちです。しかし、障害の原因はアプリケーション層だけにあるとは限りません。インフラの基礎知識があると、担当者の説明を聞いて次に何を測ればよいかを一緒に考えられるようになります。

ポストモーテムを読む

自社の過去の障害報告書 (ポストモーテム) を読むのも、優れた読書です。「何が起きて、どう対応して、何を学んだか」が凝縮されています。他社が公開しているポストモーテムも参考になりますが、構成も規模も違うため、対処そのものより「どこを見て原因に近づいたか」を持ち帰るほうが役に立ちます。

関連記事

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

まとめ

障害対応の夜に助けてくれるのは、半年前に読んだ本の 1 ページかもしれません。原因の切り分け方、ツールの使い方、過去の障害パターン。これらの知識は平時にはほとんど使いませんが、有事には手元の選択肢の数を左右します。すぐ役立つ知識だけを追わずに読み続けたことが、こういう夜に効いてきます。