Writing the Incident Report

Goal

Based on the synthetic source logs provided in this environment, you will be able to write a one-page incident report that a non-engineer can read.

Why it matters

An FDE's incident response ends not in the system but in the report. Even if it is technically fixed perfectly, if the report is late or vague, only anxiety remains in the customer's memory.

All four things this lab enforces are rules of the field. Impact before cause — what the reader needs to know first is who cannot do what right now. Write in numbers — an adjective is interpreted differently by each person and that difference becomes a dispute later. Do not name people — if an owner is named in a customer report, at the next outage that person hides information, and the price comes back as delayed detection next time. Promise the time of the next report — promising a resolution time at a stage where you do not know the cause is a gamble, but the next report time is set so that the owner can keep it given the currently confirmed situation.

Grading checks the required sections, some figures, the length, and technical terms; it does not judge the factuality of the whole text or the safety of the customer's actions. Whether you wrote facts that are not in the source must be reviewed yourself against the evidence scope below.

Error responses in an access log do not prove per-order processing or billing failures. This material has no order ledger or billing reconciliation result, so do not assert that there is no duplicate billing or tell the customer to pay again immediately. Distinguish the confirmed service symptoms, the per-order results under verification, and the records the customer should check first. The observation that errors decreased after recovery and the processing results of past orders are also different questions.

Six required sections — ## 영향, ## 현재 상태, ## 잠정 원인, ## 타임라인, ## 다음 단계, ## 고객 안내 (in order: impact, current state, provisional cause, timeline, next steps, customer notice)

Steps

1. Create /root/incident.md.
2. Include all six sections above, with ## 영향 coming before ## 잠정 원인.
3. In the ## 영향 section, include the broken path (/api/pay) and the exact error response count you counted from the source, with the unit (records).
4. In the ## 잠정 원인 section, include the deployment version that caused the problem (2.7.0) and the table that slowed down (payments).
5. In the ## 타임라인 section, include all five times 03:19, 03:27, 03:31, 03:36, and 03:39.
6. In the whole document, do not use the owner's account name from the log, and do not use blaming expressions (mistake, fault, negligence, blame).
7. Include a line that starts with 다음 보고: (next report:) and write a time or cadence.
8. Write the ## 고객 안내 section in 30 or more characters excluding spaces, without using 타임아웃 (timeout), 쿼리 (query), 500, payments, or 2.7.0, and explain what happened using the word 결제 (payment).

Notes

• Files from each lab do not carry over automatically. Even if you do not have the previous lab's summary files, you can investigate from this environment's source.
• Read the access log /opt/data/web.log, the app log /opt/data/app.jsonl, the deployment history /opt/data/deploy.log, the slow query record /opt/data/db-slow.log, and the alarm history /opt/data/alert.log. The source is already provided and you must not create or overwrite it.
• The error response count is the number of requests that saw an error. Per-order success and billing counts cannot be confirmed from this material alone, so leave them as under verification.
• The intent of step 8 is practice in turning "the Pod has fallen into a restart loop" into "the server is repeatedly turning off and on, so connections are being cut."
• Common mistake 1: copying the log's actor=oncall-kim value as is in step 6.
• Common mistake 2: copying and pasting sentences from the technical sections in step 8. You must rewrite the same content in different words.

Create the report file

Create /root/incident.md.

Create /root/incident.md. A skeleton is fine, but it must have content.

Provide the required sections

Include all six sections above, with ## 영향 coming before ## 잠정 원인.

Six sections are needed, and the impact must come before the provisional cause.

Write the impact in numbers

In the ## 영향 section, include the broken path (/api/pay) and the exact error response count you counted from the source, with the unit (records).

The impact section must contain which path broke and the error count. Numbers, not adjectives.

Write the root cause values

In the ## 잠정 원인 section, include the deployment version that caused the problem (2.7.0) and the table that slowed down (payments).

The provisional cause section must contain the deployment version that caused the problem and the name of the table that slowed down.

Fill in the timeline section

In the ## 타임라인 section, include all five times 03:19, 03:27, 03:31, 03:36, and 03:39.

All five times must be inside the timeline section. They are the values found in the previous courses.

Write in blameless sentences

In the whole document, do not use the owner's account name from the log, and do not use blaming expressions (mistake, fault, negligence, blame).

Do not copy the log's actor value, and do not use blaming expressions either.

Promise the time of the next report

Include a line that starts with 다음 보고: (next report:) and write a time or cadence.

On the line that starts with "next report:", write a time or cadence.

Translate into the customer's language

Write the ## 고객 안내 section in 30 or more characters excluding spaces, without using 타임아웃 (timeout), 쿼리 (query), 500, payments, or 2.7.0, and explain what happened using the word 결제 (payment).

The customer notice section must not contain technical terms. Write in everyday language which business function was affected.