Logs you can read, and a rollback you have rehearsed
Structured logs with a request id, the three things you check first when something is wrong, and the button that puts yesterday back.
Log as structured objects, not sentences. A line with a level, a message, a request id and a few named fields can be searched, filtered and counted; a beautifully worded English sentence with values interpolated into it cannot. Generate a request id at the edge, attach it to every log line for that request, and return it in the error response, so a user complaint becomes one query.
Log what a decision was, not that you reached a line. "user 42 denied: role viewer, needed editor" is worth twenty instances of "in handler". Never log secrets, tokens, full request bodies or personal data you have no business retaining: logs get shipped to third parties and read by people who are not you.
Rollback is a skill, not a feature. Know before you need it: which button, how long it takes, and what it does not revert. It does not undo a database migration, a message already consumed from a queue, an email that has been sent or a webhook you have delivered. That asymmetry is exactly why the expand-migrate-contract pattern earlier in this phase matters: reversible code changes are cheap and irreversible data changes are not.
You should now be able to
- Emit logs you could search under pressure
- Trace one request through a service by id
- Roll back a deployment and know what a rollback does not undo
Loading…