金曜夕方のサーバ障害対応メモ。定時退社は消えたけど学びは残った
金曜の夕方って独特のテンションがある。あと少し耐えれば休み。今週も生き延びた、と思っていた。
うちのチームは金曜に一週間の振り返りミーティングをやっていて、それが終われば基本解散。30分で終わるので、そのまま帰ってゲームするつもりだった。
そのミーティング直前に連絡が来た。
サーバ周りでまずい兆候が見つかったらしい。今すぐ影響が出るタイプではないけど、放置したら週末のどこかで事故になる可能性がある。金曜夕方のインフラ担当にとって、いちばん聞きたくない種類の話だった。
「今すぐ対応」か「週明けに回す」かの判断
最初にやったのは、この障害を今すぐ対応すべきかどうかの判断だった。インフラ障害にはざっくり2つの軸がある。「すでにサービスに影響が出ているか」と「放置した場合のリスクの大きさ」。
今回は前者はNO、後者はYESだった。週末に負荷パターンが変わるタイミングで顕在化する可能性がある。顕在化した場合、土曜の深夜にアラートが鳴って、寝ぼけた頭で対応するという最悪のシナリオが見える。
金曜の夕方に2時間残業するか、土曜の深夜に叩き起こされるか。どう考えても前者のほうがマシだった。
障害対応の初動で一番やってはいけないのは「たぶん大丈夫」で見送ることだと思っている。大丈夫じゃなかったときのダメージが大きすぎる。特に週末前は、障害が起きても翌営業日まで人が集まらないリスクがあるから、判断基準を厳しめにしておくほうがいい。
帰れない空気
振り返りミーティングはやったけど、内容はほぼ頭に入らない。裏でずっと対応手順を考えていた。
対応できるのは自分ともう1人だけ。他メンバーはこの領域の経験が薄いので、今回は二手で進めるしかない。相手が調査を深掘りして、自分は設定変更の準備と切り戻し案を作った。
ここで意識したのは役割分担の明確化だ。障害対応で人が2人しかいないとき、同じことを調べ始めると時間がもったいない。「あなたは原因調査、自分は対応準備」と最初に決めて、進捗は5分おきにチャットで同期する形にした。人数が少ないときほど、役割のオーバーラップを避けるのが効く。
調査側から上がってきた情報は想定どおりの原因だった。設定値の変更で対処できるが、適用のタイミングとロールバック手順を間違えるとサービスに影響が出る。ここからが本番。
対応前に作った「3点セット」
設定変更を実施する前に、自分はいつも「3点セット」を用意する。
1つ目は「変更理由の1行要約」。何をなぜ変えるのか、1行で書けないなら理解が足りていない。関係者への説明でも、長々とした経緯より「○○の値が△△になっているため、□□に変更する。これで週末の負荷増加時のリスクを回避する」のほうが伝わる。
2つ目は「切り戻し手順」。変更が裏目に出た場合、何をどの順番で戻せば元に戻るか。手順だけでなく、切り戻しにかかる想定時間も書く。「5分で戻せます」と「30分かかります」では判断が変わるからだ。
3つ目は「監視ポイント」。変更適用後、何を見れば成功したと判断できるか。メトリクスの具体的な名前と、正常時の値の範囲を書いておく。障害対応中は焦っているので、あとから「何を見ればいいんだっけ」と迷う時間を削りたい。
この3点セットは障害対応に限らず、本番環境への変更全般で使っている。作るのに10分くらいかかるけど、対応中の判断速度が上がるので結果的に時間を節約できる。
偉い人への「報告」
ありがたいことに、意思決定できる人がまだ社内にいた。金曜の夕方に。
方針、リスク、実施手順、戻し方、監視ポイントまでまとめて説明した。形式としては許可取りだけど、実態は「この理由で実施します。認識だけ合わせたいです」に近い。現場の時間はいつも足りない。
上への報告で心がけているのは、判断に必要な情報だけを渡すことだ。技術的な詳細をすべて説明しても相手の判断材料にならない。「何が起きていて」「どう対処して」「うまくいかなかったらどうするか」。この3つが伝われば十分。
説明後の返答は即決で「それで進めて」。ここで止まらなかったのは本当に助かった。障害対応で一番困るのは、技術的な問題よりも「承認待ち」で手が止まることだったりする。
実際の対応フロー
設定変更の適用は以下の流れで進めた。
まずステージング環境で同じ変更を適用して、挙動を確認。本番と完全に同じ条件ではないが、設定ミスや構文エラーは検出できる。ここで問題がなければ本番に進む。
本番適用はカナリアリリースの考え方を採用した。一部のサーバだけ先に適用して、メトリクスに異常がないか5分間監視。問題なければ残りに展開。全台適用後、さらに10分間メトリクスを見続けた。
この「段階的に適用して、間に監視を挟む」パターンは障害対応だけでなく、通常のリリースでも使える。全台同時に変更を入れて問題が起きると切り戻しも全台になるが、段階的にやれば被害範囲を最小化できる。
気づいたら二時間
対応そのものは大崩れしなかった。事前準備と相方の調査結果が噛み合って、設定適用と監視確認まで予定どおり進んだ。
時計を見たら、定時からほぼ2時間経過。平日の2時間より、金曜の2時間は心理的に重い。帰りの電車で「今ごろ家でゲームしていたはずだった」とずっと思っていた。
ただ、2時間で収まったのは運が良かった面もある。原因が想定の範囲内だったこと、対応できるメンバーが2人いたこと、承認がスムーズだったこと。どれかひとつ欠けていたら深夜コースだった可能性は高い。
今回のサーバ障害対応で残したメモ
感情としては「帰りたかった」で終わるけど、次回のために運用メモを残した。
- 影響が顕在化していなくても、週末前の潜在リスクは先に潰す
- 設定変更は「理由」「戻し手順」「監視項目」を必ずセットで共有する
- 特定メンバー依存の領域は、翌週に手順書化して属人化を下げる
- 2人体制のときは最初に役割分担を決めて、調査と対応を並行させる
- 本番適用は段階的に。全台一括は避ける
障害対応の「型」を持っておくということ
障害対応は毎回違う内容に見えるけど、進め方には共通パターンがある。検知→影響範囲の確認→原因調査→対応方針の決定→承認取得→実施→監視→振り返り。このフローを頭に入れておくだけで、初動の判断が早くなる。
自分の場合、過去の対応で一番時間をロスしたのは「次に何をすればいいか迷った時間」だった。技術的な難易度よりも、手順が決まっていないことによる逡巡のほうが対応を遅らせる。
だから今回のような小さめの障害でも、対応後にメモを残すようにしている。メモの目的は記録よりも「型の蓄積」だ。次に似たようなことが起きたとき、ゼロから考えなくて済むようにしておく。
定時退社は消えたけど、障害対応の型は少し固まった。次に同じ種類のインシデントが来たら、もう少し早く終わらせたい。
関連記事
他の記事
ブラウザ横スクロールアクションゲーム開発記｜TypeScript×Canvasで作るネオンランナー
HTML5 CanvasとTypeScriptで横スクロールアクションゲーム「ネオンランナー」を自作した。物理エンジン、衝突判定、操作性の工夫を解説する。
ブラウザで遊べるテトリス風パズルをTypeScriptで作った話
HTML5 CanvasとTypeScriptでテトリス風ブロックパズルを実装した。エンジンとUIを分離するSnapshotパターンや、ネオン演出のこだわりを解説する。
ゲーム実況のサムネイル作りで学んだデザインの基本
非デザイナーがゲーム配信のサムネイルを自作し続けて気づいた、視認性・配色・構図の基本ルール。試行錯誤の記録。
配信のコメント欄が動いた瞬間の話。ゼロからイチの体験
ゲーム配信でコメントがゼロの日々を超えて、初めてリアルタイムでコメントが来た瞬間の話。ゼロからイチの体験がモチベーションを変えた。