恒久対応とは

止血で被害が止まったら、原因を直します。恒久対応は、原因を直すことと、同じ原因で二度と起きないようにすることの2つです。

再発防止のテストは「外すと落ちる」まで確かめる

直したら、その不具合をとらえるテストを書きます（テストの書き方は講座16で扱っています）。ここで大事なのは、修正を一時的に外すと、そのテストが落ちることを確かめることです。修正があってもなくても通るテストは、何も守っていません。

naminori では、これを不具合を直すときの決まりにしています。応募が「失敗」と表示された不具合では、「応募すると完了の画面に進み、『応募が完了しました』と出る」ことを確かめるテストを足し、修正前のコードではそのテストが落ちることを確かめました。

本番で確かめるまでが恒久対応

手元でテストが通っても、本番で直ったとは限りません。naminori では、直したら本番で同じ操作をして確かめ、7日後にもう一度、再発していないかを見るようにしています。

第2回の「日本語をそのまま含むURL」の不具合では、公開の直後に同じ形のURLで正常に表示されることを確かめ、その後も同じエラーが1件も出ていないことを確かめてから「効果あり」と記録しました。

記録する（ふりかえり）

最後に、何が起きて何をしたかを書き残します。ふりかえり（ポストモーテム）と呼ばれる文書です。形は次のくらいで十分です。

# 応募で「失敗しました」と表示された
何が起きたか: 応募は保存されるのに、失敗の画面が出た
影響: 期間中の応募2件。経路によっては失敗に見えていた
時系列: 8/10 通知の変更を公開 → 10/11 別の作業中に発見・修正
原因: 通知の文面で、求人が持っていない項目を読んでいた
なぜ気づけなかったか: エラーをログに書くだけで、通知していなかった
再発防止: 完了画面を確かめるテスト。捕まえたエラーも追跡ツールへ
次に確かめる日: 修正の7日後

「なぜ気づけなかったか」を書くのがポイントです。原因を直しても、気づけない作りのままなら、次の別の障害もまた長引きます。そして、ふりかえりは誰かを責めるための文書ではありません。人が間違えるのは前提で、間違えても早く気づける・被害が小さく済む仕組みを考えるための文書です。

記録しないと、後から困ること

• 半年後に同じ症状が出たとき、同じ調査をゼロからやることになる
• 「前にもあった気がする」が、確かめられない
• 直した人がいなくなると、なぜその作りになっているのかが誰にも分からない

naminori では、記録を次の仕事にも使っています。エラー追跡ツールの調べ方や、よくある偽陽性（第5回）を手順書にまとめておき、次の調査はそこから始めます。定期処理が6週間止まっていた件（第1回）は、記録に「いつ確かめるか」を書いておいたので、約6週間後に見直しました。そのとき、別の定期処理の失敗が新しく作った通知で実際に届いていたことも確かめられました。

中級へ：そもそも困らない作りにする

この講座では、起きた障害に対応する手順を学びました。中級（講座35）では、その一歩手前を扱います。

• 長く使っても困らない設計
• 当番（オンコール）として、通知をどう受け取り、どう設定するか
• 機能を足すときのデータの設計

「後から困ること」を、作る段階で減らしていく講座です。

この講座のまとめ

• 障害対応は、気づく・影響・止血・原因・恒久対応・記録の6段階
• 直し始める前に、誰が・何が・いつから・今もを確かめ、短く報告する
• ログは層ごとに違う。数える・最初を見る・リクエストIDでつなぐ
• エラー追跡ツールに無い ＝ 起きていない、ではない
• 比べる・直近の変更・層・半分にする、で切り分ける
• 止血の前に、証拠とデータを残す
• 外すと落ちるテストと、本番での確認と、記録までが恒久対応

• 恒久対応の2つの意味
• 外すと落ちる再発防止テスト
• 本番で確かめ、7日後にもう一度見る
• ふりかえりの書き方と「なぜ気づけなかったか」
• 中級（講座35）への橋渡しと講座のまとめ