If the Job Cannot Show What It Did, Somebody Will Do It Again

작성자

카테고리:

← 피드로
DEV Community · Serguey Shinder · 2026-09-17 개발(SW)

Serguey Shinder

Our provisioning job has worked reliably for years. It also gets checked by hand, every single time, by the engineer who triggered it, who opens the console afterwards and confirms each setting. Twelve minutes of somebody’s attention, roughly ninety runs a month, on top of an automation that already did the work.

I assumed this was habit and asked the team to stop. They declined, and they were right.

Two years ago the same job reported success while quietly skipping a step. An interface accepted a request, returned a perfectly cheerful response and applied nothing, and because the script was checking whether its call had been accepted rather than whether the world had changed, it wrote a green tick and moved on. The gap was found several weeks later by somebody who could not understand why a group had no members. Since that morning nobody on the team has believed a green tick, and no amount of encouragement from me was going to alter that.

The defect was in the reporting rather than in the logic. Our automation told us that it had run. It did not tell us what it had changed, and an exit code of zero is a statement about a script, not about a system.

So every job now finishes by reading back the state it was asked to create and writing a record of it: what existed before, what exists now, what it changed, and what it deliberately skipped and why. The last of those was the surprise. About four percent of runs were skipping something, silently and by design, in branches written years ago by people who had reasonable intentions and no way to report a partial outcome.

A daily reconciliation compares intent against reality for the whole estate, so drift is reported rather than discovered. And we set a date, with a name against it, for removing the manual check, because a habit formed by one bad morning does not dissolve on its own and somebody has to be accountable for deciding it is safe.

Automation is not trusted because it works. It is trusted because it can be checked, and the check has to be cheaper than doing the job again.

– Serguey Shinder

원문에서 계속 ↗