The One Line Config Change Is Now Officially a Procedure
The change is one line. The systems that depended on the previous value of that line are not one system.
Phase One: The Description
A configuration change is proposed. The engineer says it is a one-line change. This is true. The change occupies one line in one file. It is small by any typographic measure.
Phase Two: What One Line Means
The line sets a timeout value. The timeout value is read by seven services. Three of those services have hardcoded assumptions that the timeout will never exceed a certain threshold. Two services will fail silently if the value is lower than expected. One service will fail loudly.
None of this is in the configuration file. None of this is in the pull request description. Some of it is in a comment added eighteen months ago by an engineer who has since left.
Phase Three: Deployment
The one-line change is deployed. Ninety seconds later, one service begins failing loudly.
Phase Four: The Incident
The loud failure is investigated. The configuration change is identified as the cause within four minutes. The value is reverted. The service recovers.
Phase Five: Documentation
The incident is recorded. The learning is: this timeout value has dependencies that are not documented. An action item is created to document them. The action item is assigned. It is not completed within the sprint.
Governing Rule: Under the applicable standard, any one-line config change that restores service once may be reused until someone proves why it worked. The change has been reverted. Proof of why the original value worked has been added to the backlog.
The backlog has 43 other items. The one-liner waits.