障害報告書を書く
目標
今回の環境で提供された合成の原本ログを根拠に、非エンジニアが読める障害報告書1枚を書けるようになります。
なぜ重要なのか
FDEの障害対応は、システムではなく報告書で終わります。技術的に完璧に直しても、報告が遅かったりあいまいだったりすると、顧客の記憶には不安だけが残ります。
このラボが強制する4つは、すべて現場のルールです。影響が原因より先: 読む人が最初に知るべきことは、いま誰が何をできないのかです。数字で書く: 形容詞は人ごとに違う解釈をされ、その差があとで紛争になります。人を名指ししない: 顧客企業の報告書に担当者が名指しされると、次の障害でその人は情報を隠し、その代償は、次回の検知の遅れとして返ってきます。次の報告時刻の約束: 原因がわからない段階で解決時刻を約束するのは賭けですが、次の報告時刻は、現在確認されている状況で、担当者が守れるように決めます。
採点は、必須の節・一部の数値・長さ・技術用語を確認し、文章全体の事実性や、顧客の行動の安全性は判定しません。原本にない事実を書いていないかは、下の根拠の範囲と照らして、自分で確認する必要があります。
アクセスログのエラー応答は、注文ごとの処理・請求の失敗を証明しません。この資料には、注文の元帳や請求の突合結果がないので、二重請求がないと断定したり、すぐに再決済するよう案内したりしないでください。確認されたサービスの症状、確認中の注文ごとの結果、顧客が最初に確認すべき内訳を区別します。復旧後にエラーが減ったという観測と、過去の注文の処理結果も、別々の問いです。
必須の節6つ: ## 영향、## 현재 상태、## 잠정 원인、## 타임라인、## 다음 단계、## 고객 안내(韓国語の見出しで、順に影響、現在の状態、暫定原因、タイムライン、次のステップ、顧客向け案内を意味します)
ステップ
/root/incident.mdを作成してください。- 上の6つの節をすべて入れ、
## 영향が## 잠정 원인より前に来るようにしてください。 ## 영향の節に、壊れた経路(/api/pay)と、原本で数えた正確なエラー応答の件数を、単位(件に当たる韓国語の単位)とともに入れてください。## 잠정 원인の節に、問題になったデプロイのバージョン(2.7.0)と、遅くなったテーブル(payments)を入れてください。## 타임라인の節に、03:19、03:27、03:31、03:36、03:39の5つの時刻をすべて入れてください。- 文書全体で、ログの担当者アカウント名を書かず、責任を問う表現(ミス・間違い・過失・せい)も書かないでください。
다음 보고:(韓国語で「次の報告:」を意味します)で始まる行を入れ、時刻または周期を書いてください。## 고객 안내の節を、空白を除いて30文字以上で書き、타임아웃・쿼리・500・payments・2.7.0(韓国語の語は、順にタイムアウト、クエリを意味します)を使わずに、결제(韓国語で「決済」を意味する語です)という言葉で、何があったかを説明してください。
参考
- ラボごとのファイルは、自動的には引き継がれません。前のラボの要約ファイルがなくても、今回の環境の原本で調査できます。
- アクセスログ
/opt/data/web.log、アプリログ/opt/data/app.jsonl、デプロイ履歴/opt/data/deploy.log、遅いクエリの記録/opt/data/db-slow.log、アラート履歴/opt/data/alert.logを読んでください。原本はすでに提供されており、新しく作ったり、上書きしたりしません。 - エラー応答の件数は、エラーを見たリクエストの数です。注文ごとの成否・請求回数は、この資料だけでは確認できないので、確認中として残します。
- ステップ8の意図は、「Podが再起動ループに陥りました」を「サーバーが停止と起動を繰り返している状態なので、接続が切れます」に言い換える練習です。
- よくあるミス1: ステップ6で、ログの
actor=oncall-kimの値をそのまま書き写すことです。 - よくあるミス2: ステップ8で、技術の節の文をコピーして貼り付けることです。同じ内容を、別の言葉で書き直す必要があります。
レポートファイルを作成する
/root/incident.mdを作成してください。
/root/incident.mdを作成してください。骨組みだけでも構いませんが、内容が必要です。
必須の節を揃える
上の6つの節をすべて入れ、## 영향が## 잠정 원인より前に来るようにしてください。
6つの節が必要で、影響が暫定原因より先に出てくる必要があります。
影響を数字で書く
## 영향の節に、壊れた経路(/api/pay)と、原本で数えた正確なエラー応答の件数を、単位(件に当たる韓国語の単位)とともに入れてください。
影響の節に、どの経路が壊れたかと、エラーの件数が入っている必要があります。形容詞ではなく数字です。
根本原因の値を書く
## 잠정 원인の節に、問題になったデプロイのバージョン(2.7.0)と、遅くなったテーブル(payments)を入れてください。
暫定原因の節に、問題になったデプロイのバージョンと、遅くなったテーブルの名前が入っている必要があります。
タイムラインの節を埋める
## 타임라인の節に、03:19、03:27、03:31、03:36、03:39の5つの時刻をすべて入れてください。
5つの時刻がすべて、タイムラインの節の中にある必要があります。前のコースで求めた値です。
非難のない文で書く
文書全体で、ログの担当者アカウント名を書かず、責任を問う表現(ミス・間違い・過失・せい)も書かないでください。
ログのactorの値を書き写さず、責任を問う表現も書かないでください。
次の報告時点を約束する
다음 보고:(韓国語で「次の報告:」を意味します)で始まる行を入れ、時刻または周期を書いてください。
「次の報告:」にあたる韓国語の表現で始まる行に、時刻または周期を書いてください。
顧客の言葉に翻訳する
## 고객 안내の節を、空白を除いて30文字以上で書き、타임아웃・쿼리・500・payments・2.7.0(韓国語の語は、順にタイムアウト、クエリを意味します)を使わずに、결제(韓国語で「決済」を意味する語です)という言葉で、何があったかを説明してください。
顧客向け案内の節には、技術用語が入ってはいけません。どの業務が影響を受けたかを、日常の言葉で書いてください。