「トラブル対応が得意」と経歴書に書ける理由

私のスキルシートの自己アピール欄には、昔から「トラブル対応」と書いてある。

考えてみれば、妙なアピールである。

トラブルが得意。

火事が得意な消防士のようで、字面だけ見ると、少し物騒だ。

でも、30年やってきて、エンジニアの実力が一番はっきり出るのは、平常時ではなく障害の夜だと思っている。

今日は、私がトラブルの現場で守っている型と、なぜこれが「得意」になり得るのかを書いてみたい。

型その一:原因より先に、止血

障害の一報が入ると、エンジニアの本能は「原因究明」に向かう。

なぜ落ちた?

何が悪い?

この本能は、抑えなければならない。

最初にやるのは、原因究明ではなく、止血である。

影響を止める。

広げない。

サービスを縮退させてでも、出血を止める。

原因が分からなくても、直前のリリースを戻せば止まるなら、まず戻す。

「原因も分からず戻すのは気持ち悪い」と言う人がいる。

分かる。

でも、原因の解明は朝でもできる。

いま流れている実害は、いましか止められない。

気持ち悪さは、エンジニアの都合である。

障害対応は、お客様の都合で動く時間なのだ。

型その二:再現条件を、固定する

止血が済んだら、次は原因である。

ここで大事なのは、手を動かす前に、再現条件を固定することだ。

いつから起きているのか。

どの操作で起きるのか。

必ず起きるのか、ときどきなのか。

障害対応が下手な人は、ここを飛ばして、思いついた仮説から手当たり次第に触り始める。

すると何が起きるか。

触っているうちに状況が変わり、「さっきまで再現していたのに、しなくなった」という最悪の状態に陥る。

直ったのではない。

証拠を、自分の手で消したのである。

再現する障害は、もう半分解決している。

再現しない障害が、本当の地獄である。

だから、再現条件は宝物のように扱う。

型その三:疑う順番を、間違えない

原因の当たりをつけるとき、私は決まった順番で疑う。

一番目。直近の変更。

昨日まで動いていて今日壊れたなら、犯人はほぼ確実に、昨日と今日の間の変更である。

リリース、設定変更、証明書の期限、外部サービスの仕様変更。

障害の大半は、ここで見つかる。

二番目。環境の変化。

変更していないのに壊れた場合は、勝手に変わるものを疑う。

データ量の増加、アクセスの増加、ディスクの残量、日付に依存する処理。

「何も変えていないのに壊れた」の「何も」には、たいてい嘘がある。

世界のほうが、変わっているのだ。

三番目。まさかの層。

アプリでもインフラでもなく、もっと下。

DNS、ネットワーク機器、そしてクラウド事業者自身の障害。

疑う順番を持っているだけで、調査の速度は数倍変わる。

これは知能の差ではない。

場数のデータベースの差である。

型その四:深夜に、大手術をしない

深夜の障害対応には、特有の誘惑がある。

「ついでに、ちゃんと直したい」

応急処置ではなく、根本対応をしたくなるのである。

やってはいけない。

深夜の脳は、確実に劣化している。

判断力が落ちた人間が、疲れと焦りの中で行う大手術は、二次災害の母である。

私は何度か、この二次災害を見てきた。

障害対応の傷が浅かったのに、深夜の「ついで根本対応」で本当の大怪我になった現場を。

深夜にやるのは、止血と、朝を安全に迎える処置まで。

根本対応は、明るい時間に、覚めた頭でやる。

これを自分に課すには、少しの謙虚さがいる。

「いまの自分は賢くない」と認める謙虚さである。

なぜ「得意」と書けるのか

さて、冒頭の問いに戻る。

なぜ私は「トラブル対応が得意」と書けるのか。

型を知っているから、ではない。

型なら、この記事を読めば、今日から誰でも知っている。

本体は、別のところにある。

障害の現場で、心拍数が上がらなくなったのである。

障害対応の質を一番下げるのは、技術力の不足ではなく、パニックである。

焦りは、手順を飛ばさせ、確認を省かせ、二次災害を呼ぶ。

では、なぜ私は焦らないのか。

30年分の障害を浴びてきて、体が知っているからである。

たいていの障害は、直る。

直らなかった障害を、私はほとんど覚えていない。

あれだけ絶望的に見えた夜も、すべて朝が来て、すべて収束した。

この体感だけは、本にも研修にも書けない。

浴びた量が、そのまま落ち着きになる。

トラブル対応が得意というのは、つまり、たくさん失敗してきましたという告白と、ほぼ同じ意味なのである。

AI時代の障害対応

最後に、現在の話を。

障害対応にも、AIは入ってきた。

ログの解析は、劇的に速くなった。

大量のログを渡して「異常な傾向を探せ」と頼めば、人間が目を皿にする何倍もの速度で候補が挙がる。

過去の類似障害の検索も、仮説出しも、頼りになる。

ただ、障害対応の核心は、いまもAIに渡せていない。

本番環境で、その操作を実行するかどうかの判断。

縮退させるか、粘るかの判断。

お客様に、いつ、何を報告するかの判断。

そして、「今夜はこれ以上触らない」という判断。

気づけば、全部「判断」である。

先日、AIに渡せない仕事のリストの記事を書いたが、障害対応はまさにその凝縮だった。

平常時の開発は、AIとの共同作業になった。

障害の夜は、まだ当分、人間の夜である。

だから私は、これからもスキルシートに書き続けると思う。

トラブル対応、得意です。

それは30年分の失敗と、上がらなくなった心拍数の、短い要約なのである。