Acompanhando e verificando itens de ação pós-incidente

A blameless post-mortem that produces no durable change is just storytelling. The real value is in the action items that prevent recurrence.

This lesson covers how to write, assign, track, and verify them.

A strong action item is specific and verifiable. Vague items like 'be more careful' never get done.

• Owner: a single named person
• Outcome: an observable change
• Due date: a realistic deadline
• Tracking link: a ticket

Classify each action by how it reduces future risk:

• Prevent: stop the cause entirely
• Mitigate: reduce blast radius if it happens again
• Detect: catch it faster next time

A healthy post-mortem usually produces all three categories.

It is tempting to record only the obvious code fix. But incidents have layers. Use the contributing factors from your timeline to generate items addressing process and detection gaps too.

One root cause often yields several action items across these layers.

You cannot do everything at once. Score items by impact and effort.

• High impact, low effort: do first
• High impact, high effort: schedule deliberately
• Low impact: question whether to keep

An item owned by 'the team' is owned by no one. Assign a single accountable individual, even if they delegate the work.

The owner is responsible for status, not necessarily for typing the code.

Create action items as tickets linked to the incident, with a consistent label so they are queryable.

This lets you report on completion rate across all post-mortems, not just one.

A team that closes 90% of action items within deadline is learning. A team sitting at 30% is repeating incidents.

Track completion as a leading indicator of reliability culture and review it in operational meetings.

Closing a ticket is not proof. Verify the remediation with evidence:

• A new alert that actually fired in a test
• A chaos experiment reproducing the old failure safely
• A regression test added to CI

When verification succeeds, update the original post-mortem with the outcome. This builds an institutional memory: future readers see not just what happened, but what was done and that it worked.

Putting it together:

• Derive items from contributing factors
• Classify prevent/mitigate/detect
• Assign one owner and a due date each
• File linked tickets with a shared label
• Review completion rate regularly and verify before closing

You learned to convert post-mortem findings into durable change.

• Write specific, owned, dated action items
• Cover prevent, mitigate, and detect
• Track in tickets and measure completion rate
• Verify fixes with evidence before closing