Rule#1
Every system is perfectly designed to produce the results it gets.
FMS field reference · Rev. 01
Murphy’s Rules
for DevOps
27 rules / zero warranties
Collected from servers, service calls, midnight command lines, and other controlled learning environments.
Read before maintenance. Re-read after saying, “It’ll only take five minutes.”
Rule#2
Nothing is more permanent than a temporary fix that works.
Rule#3
The most reliable system is the one you stop touching after it starts working.
Rule#4
The difference between a stable server and a project is whether you SSH into it after 10 PM.
Rule#5
Run it until it gives you a reason not to.
Rule#6
If everything is working, document it before you forget why.
Rule#7
Before changing anything, prove there is actually a problem.
Rule#8
One step at a time. If you change three things, you’ll troubleshoot four.
Rule#9
A backup is only a backup if you’ve restored from it.
Rule#10
The probability of failure is directly proportional to the confidence level of the phrase: “It’ll only take five minutes.”
Rule#11
Every maintenance window expands to consume all available evening hours.
Rule#12
Production is the most comprehensive test environment ever created.
Rule#13
If you’re not monitoring it, it’s broken and just hasn’t told you yet.
Rule#14
Disk space consumed by an old image is a nuisance. Disk space consumed by an overenthusiastic cleanup command is a recovery project.
Rule#15
The best troubleshooting tool remains: “Tell me exactly what you changed.”
Rule#16
Logs are innocent until proven guilty.
Rule#17
If the logs are empty, you’re looking in the wrong place.
Rule#18
When the solution appears obvious, collect one more piece of evidence.
Rule#19
There is no problem so small that automation cannot make it happen at scale.
Rule#20
The second most dangerous phrase in DevOps is: “We should optimize that.”
Rule#21
The most dangerous phrase in DevOps is: “Everything’s working… I wonder if I can make it even better.”
Rule#22
A system that has run flawlessly for six months is preparing a surprise.
Rule#23
The outage begins the moment you say: “I’ll just make one quick change.”
Rule#24
Never perform maintenance when tired, hungry, angry, or in a hurry.
Rule#25
The ancient Viking incantation appearing in a terminal is rarely the root cause.
Rule#26
When in doubt: Maintain present heading and velocity.
Rule#27
No new problems required.
Field additions
The rules that followed us home.
Not part of the numbered twenty-seven. Too useful to leave lying on the shop floor.
Perfect is the enemy of Good.
At some point you’re no longer improving the solution. You’re just delaying its existence.
Trust—but verify.
A green light is encouraging. A tested result is evidence.
At 11:31 PM, every problem is either a tomorrow problem or a 3:00 AM problem.
Your next decision determines which. Fatigue changes the odds.
Sharpen the saw.
Maintenance, documentation, learning, and rest are part of the work.
Leave people better off than you found them.
Everything else is implementation details.
Standing order