Uzrakstīt incidenta analīzi bez vainas meklēšanas

Kad izmantot

An incident was just closed — outage, data mistake, missed deadline, angry-customer event — and the cause is not yet understood or its fix is not yet tracked. Not while the incident is still open — use agents.incident-response first; a review of an unresolved incident is fiction. Not for a single customer complaint with no operational cause — use ops.customer-complaint. Not for a security incident with possible legal consequences — use tech.security-audit and involve the owner before anything is written.

Pirms sāc

• The incident is closed and its record has a start time, detection time, and close time.
• Raw material is collected within 48 h of closure: chat threads, alerts, deploys, screenshots. Logs age badly.
• A facilitator is named (the agent drafts; a person facilitates the review meeting if one is held).
• Everyone involved knows the rule up front: the review assumes everyone acted reasonably with the

Ko izpilde pieprasa1

Ceļš8 soļi

1. S1

   Assemble the raw timelineaģents

   Walk the material chronologically: first symptom, first alert, first human action, each fix attempt, the actual fix, the close. Record times in one timezone (Europe/Riga).

   Izdarīts, kad a draft timeline exists with a source (log line, message, deploy id) next to every entry.

2. S2

   Quantify the impactaģents

   Write down: duration from detection to fix, who or what was affected, what customers experienced, what it cost or could have cost, what customers were told and when.

   Izdarīts, kad the impact section has numbers or an explicit "no customer impact" with the reason.

3. S3

   Find the root cause — ask why until it stops being a personaģents

   Trace the chain: the trigger, why the trigger was possible, why detection took as long as it did, why the fix took as long as it did. Stop at a system, process, or missing-check cause, never at "X made a mistake".

   Izdarīts, kad the root cause is a sentence about a system or process, and the contributing factors are listed separately. ⛔ If the draft says a person "forgot" or "didn't check", it is not done — find the check or guardrail that was missing instead.

4. S4

   Draft the reviewaģents

   Use the template: summary, impact, timeline, root cause, what went well, what went badly, lessons, proposed actions. Keep it under two pages.

   Izdarīts, kad the draft is in the documents module, linked to the incident record, and readable by someone who was not there.

5. S5

   Review and accept the documentīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S5 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   The owner reads the draft, corrects facts, and accepts it or sends it back once with specific changes.

   Izdarīts, kad the owner has said "accepted" in writing, or returned it with changes that the agent then applies and resubmits. ⛔ Do not soften the root cause to protect anyone — if the owner wants it softened, record the owner's wording but keep the factual chain in an appendix.

6. S6

   Turn lessons into owned actionsaģents

   Each lesson becomes a task with an owner and a due date (typically 14–30 days). Create them in the tasks module with bc tasks add, and link them to the incident record. If an action is big enough to be a goal, create it with bc goals add instead.

   Izdarīts, kad every proposed action is a task or goal with a named owner and a date — or is explicitly rejected by the owner with a reason.

7. S7

   File and circulateaģents

   File the accepted document in the documents module under postmortems, and send the owner a three-line summary: what happened, root cause, actions and owners. If customers were affected, note whether management.crisis-communication output needs updating.

   Izdarīts, kad the document is filed, the summary is sent, and the tasks appear in the owners' task lists.

8. S8

   Track actions to closureaģents

   Check the linked tasks weekly until all are closed. Escalate any action past its due date to the owner once.

   Izdarīts, kad every action is closed or the owner has accepted a written reason why it will not be.

Pārbaudes — kā zinām, ka izdevās

• Read the root-cause sentence aloud: it names no person and no team as the cause.
• Every timeline entry has a time and a source.
• Every lesson has a corresponding task or an explicit rejection.
• The document is findable by someone searching the documents module for the incident id.
• 90 days later: no repeat incident with the same root cause (check at the next quarterly review).

Ja noiet greizi

Ko atstāj katrs solis

1. S1a draft timeline exists with a source (log line, message, deploy id) next to every entry.
2. S2the impact section has numbers or an explicit "no customer impact" with the reason.
3. S3the root cause is a sentence about a system or process, and the contributing factors are listed separately. ⛔ If the draft says a person "forgot" or "didn't check", it is not done — find the check or guardrail that was missing instead.
4. S4the draft is in the documents module, linked to the incident record, and readable by someone who was not there.
5. S5the owner has said "accepted" in writing, or returned it with changes that the agent then applies and resubmits. ⛔ Do not soften the root cause to protect anyone — if the owner wants it softened, record the owner's wording but keep the factual chain in an appendix.
6. S6every proposed action is a task or goal with a named owner and a date — or is explicitly rejected by the owner with a reason.
7. S7the document is filed, the summary is sent, and the tasks appear in the owners' task lists.
8. S8every action is closed or the owner has accepted a written reason why it will not be.

Ko saglabāt

The incident id · the accepted document and its version · the raw timeline with sources · the owner's acceptance (who, when) · the task ids for every action · the closure status of each action at 30 and 90 days.

Kā šī procedūra uzlabojas

After every 5 reviews ask: how many days from close to accepted document, and what caused the delay? What share of actions closed by their due date? Did any incident repeat a root cause from a previous review — if so, its actions failed and the S6 format needs changing. A new version changes the step behind the worst measure and says so in its change note.