影響を受けたのは何人だったのか — ルールで数える影響

目標

決済障害のアクセスログからユーザーではないリクエストを取り除き、リトライをまとめ、人をルールどおりに数えて、リクエスト・失敗・エラー率・影響を受けたユーザーを求めます。そのルールをスクリプトにして初めて見るログにも合うようにし、最後に互いに違う数字を出す三つのチームのスクリプトを直します。

なぜ重要なのか

影響の数字は、状況告知・補償・規制当局への報告・SLOがそのまま使う値です。ところが同じログでも、何を除き何をまとめるかによって数字が何倍も変わります。ヘルスチェックを含めると障害が実際より大きく見え、リクエスト数を人数として使うと影響が膨らみ、区間のタイムゾーンを捨てると見当違いの時間帯を数えます。「誰が正しいか」を争う前にルールを揃え、ルールをコードとして残すことがこのラボの要点です。

ステップ

python3 /opt/fixtures/ic/ickit.py open impact で素材を展開し、/root/ic/impact/README.txt の数え方のルールを読んでください。access.log のうちヘルスチェック(パスがちょうど /healthz または /readyz)の行数を、/root/ic/impact/answers/health.txt に数字一つで書いてください。
ログ全体から、ヘルスチェック・ボット(User-Agentにbot・crawler・spiderを含む、大文字小文字を区別しない)・社内アドレス帯(クライアントIPが10.で始まる)を除いた行数を、/root/ic/impact/answers/external.txt に数字一つで書いてください。
インシデント区間(window.txt、KST)に最初の試行が入る外部リクエストの数と、そのうち最後の試行のステータスが500以上のリクエストの数を、/root/ic/impact/answers/requests.txt に requests=<n>、failed=<n> の2行で書いてください(同じ req の行は一つのリクエストです)。
同じルールで、インシデント区間のエラー率と、ログの先頭から区間開始前までの平常時のエラー率をパーセント(小数第2位まで)で計算し、/root/ic/impact/answers/rate.txt に error_rate=<percent>、baseline_rate=<percent> の2行で書いてください。
区間に失敗したリクエストが一つでもある人の数と、区間にリクエストを送った人の数を、/root/ic/impact/answers/users.txt に affected_users=<n>、active_users=<n> の2行で書いてください。人は user= で数え、ログインしていないリクエスト(user=-)は session= 一つを一人として数えます。
/root/ic/impact/impact.sh <log> <start-iso> <end-iso> がREADMEのルールどおりに requests=<n>、failed=<n>、affected_users=<n> の3行を出力するようにしてください(実行権限が必要、言語は自由で、1行目のシバンで決めます)。区間引数は 2026-11-04T14:10:00+09:00 の形式です。採点ツールはこのラボのログに加え、その場で新しく作った別のログ・区間でも実行して確かめます。
incident ic-impact-dispute を実行するとインシデントが発生します。同じログ(/srv/impact/access.log)・同じ区間(/srv/impact/window.txt)なのに、/srv/impact/bin/statuspage・support・sre の三つのスクリプトの affected_users が互いに違います。三つのスクリプトをREADMEのルールどおりに直し、三つとも同じ真の値を出すようにしてください(呼び出し方はそのまま。数字を直接書き込むと別のログで不合格になります)。/root/incident/ic-impact-dispute/report.txt に statuspage: <code>、support: <code>、sre: <code> の3行と evidence: <defective-line> を書いてください。コードはスクリプトごとに次のいずれかです: includes-probes(ヘルスチェック・ボット・社内アドレス帯を除いていない)、requests-as-users(失敗リクエスト数を人数として使う)、retries-double-counted(リトライ中に一度でも失敗すれば失敗とする)、sampling-gap(ログのサンプルが欠けている)、sessions-as-users(ログインした人もセッションごとに別々に数える)、window-timezone(区間の時刻のタイムゾーンを捨てる)。

参考

素材ツール: python3 /opt/fixtures/ic/ickit.py open <name> が素材を /root/ic/<name>/ に展開します。素材は人ごとに異なるランダムなシードで作られ、採点ツールは同じシードで正解を計算し直します。他人の数字は合いません。展開し直しても同じ素材で、--fresh を付けると新しい素材で最初からやり直しになります。
答えは /root/ic/<name>/answers/ の下に書きます。セッションが終わると消えるので、必要なら別途保存してください。
インシデントツール: incident list で発生させられるインシデントと一行の症状を、incident show <name> でチケットを再表示します。同じインシデントをもう一度発生させると、新しいランダムな素材で最初の故障状態に戻ります(先に書いた答えは合わなくなります)。
レポートは /root/incident/<name>/report.txt です。対象ごとに <target>: <cause-code> を1行ずつ、最後に evidence: <line> をそのまま付けます。証拠は素材や観察記録にそのまま存在する1行(20文字以上)でなければなりません。採点ツールは修正後の実際の状態を先に確認し、レポートは判断を確かめるために使います。
ログの1行: <utc-time> <IP> "<method> <path> <protocol>" <status> <bytes> "<User-Agent>" user=<id|-> session=<id|-> req=<id> attempt=<n>。 User-Agentの中に空白があるので、空白だけで分割すると列がずれます。正規表現か引用符での区切りが安全です。
区間の比較はタイムゾーン付きの時刻同士で行います。pythonの datetime.fromisoformat は +09:00 を読み取り、Z は +00:00 に置き換えれば読み取れます。
よくある間違いは二つです。行数をリクエスト数として数えること(リトライの重複)と、失敗リクエスト数を影響を受けたユーザー数として使うことです。

素材の展開 — ヘルスチェックは何行か

python3 /opt/fixtures/ic/ickit.py open impact で素材を展開し、/root/ic/impact/README.txt の数え方のルールを読んでください。access.log のうちヘルスチェック(パスがちょうど /healthz または /readyz)の行数を、/root/ic/impact/answers/health.txt に数字一つで書いてください。

リクエスト行は引用符の中にメソッド・パス・プロトコルがあります。空白で分割するとパスは4番目の列になります。

外部ユーザーの行だけを残す

ログ全体から、ヘルスチェック・ボット(User-Agentにbot・crawler・spiderを含む、大文字小文字を区別しない)・社内アドレス帯(クライアントIPが10.で始まる)を除いた行数を、/root/ic/impact/answers/external.txt に数字一つで書いてください。

User-Agentは引用符で囲まれた2番目の列です。引用符を区切り文字にすると(awk -F'"')4番目の列になります。行全体からbotを探すと、別の列に引っかかることがあります。

区間のリクエストと失敗 — リトライは一つに

インシデント区間(window.txt、KST)に最初の試行が入る外部リクエストの数と、そのうち最後の試行のステータスが500以上のリクエストの数を、/root/ic/impact/answers/requests.txt に requests=<n>、failed=<n> の2行で書いてください(同じ req の行は一つのリクエストです)。

ログはUTC、区間はKSTです。リクエストごとに、最初の試行の時刻と最後の試行のステータスを別々に保持しておく必要があります。pythonのdictを二つ使うと便利です。

エラー率と平常時のエラー率

同じルールで、インシデント区間のエラー率と、ログの先頭から区間開始前までの平常時のエラー率をパーセント(小数第2位まで)で計算し、/root/ic/impact/answers/rate.txt に error_rate=<percent>、baseline_rate=<percent> の2行で書いてください。

エラー率 = 失敗リクエスト ÷ リクエスト × 100。分母と分子が同じルール(外部リクエスト、リトライは一つのリクエスト)でなければなりません。比率(0.09)ではなくパーセント(9.33)です。

影響を受けた人を数える

区間に失敗したリクエストが一つでもある人の数と、区間にリクエストを送った人の数を、/root/ic/impact/answers/users.txt に affected_users=<n>、active_users=<n> の2行で書いてください。人は user= で数え、ログインしていないリクエスト(user=-)は session= 一つを一人として数えます。

失敗リクエスト数と人数は違います。ログインした人のセッションが複数あっても一人です。

ルールをスクリプトに

/root/ic/impact/impact.sh <log> <start-iso> <end-iso> がREADMEのルールどおりに requests=<n>、failed=<n>、affected_users=<n> の3行を出力するようにしてください(実行権限が必要、言語は自由で、1行目のシバンで決めます)。区間引数は 2026-11-04T14:10:00+09:00 の形式です。採点ツールはこのラボのログに加え、その場で新しく作った別のログ・区間でも実行して確かめます。

前の三つのステップの計算を、引数を受け取る一つのファイルにまとめれば十分です。区間引数のタイムゾーン表記を捨てないでください。

インシデント — 三つのチームの影響の数字が互いに違う

incident ic-impact-dispute を実行するとインシデントが発生します。同じログ(/srv/impact/access.log)・同じ区間(/srv/impact/window.txt)なのに、/srv/impact/bin/statuspage・support・sre の三つのスクリプトの affected_users が互いに違います。三つのスクリプトをREADMEのルールどおりに直し、三つとも同じ真の値を出すようにしてください(呼び出し方はそのまま。数字を直接書き込むと別のログで不合格になります)。/root/incident/ic-impact-dispute/report.txt に statuspage: <code>、support: <code>、sre: <code> の3行と evidence: <defective-line> を書いてください。コードはスクリプトごとに次のいずれかです: includes-probes(ヘルスチェック・ボット・社内アドレス帯を除いていない)、requests-as-users(失敗リクエスト数を人数として使う)、retries-double-counted(リトライ中に一度でも失敗すれば失敗とする)、sampling-gap(ログのサンプルが欠けている)、sessions-as-users(ログインした人もセッションごとに別々に数える)、window-timezone(区間の時刻のタイムゾーンを捨てる)。

方向: 三つのスクリプトは同じ雛形から分かれたものです。READMEの五つのルールと一行ずつ突き合わせると、食い違う箇所がスクリプトごとに一つずつ見つかります。ツール: diff(二つのスクリプトを並べて比較)、python3 -X がなくてもprintで途中の値を見ること、前のステップのimpact.sh。具体: 取り除く条件(パス・User-Agent・IP)、最後の試行を選ぶ行、人を集めるデータ型(集合かリストか、何を入れるか)、区間引数を読む行を順に見てください。直した後、三つを同じ引数で実行し、数字が一つに揃うか確認します。