Habit one: sizing for the incident, not the average
After any outage caused by resource exhaustion, the instinctive fix is a permanent headroom increase, not a better autoscaling policy. That headroom is rarely removed once the postmortem closes, because removing it feels like reintroducing risk — even though the autoscaler was supposed to absorb exactly this kind of spike.
Habit two: requests and limits copied, not calculated
Kubernetes resource requests are frequently copy-pasted from a similar-sounding service rather than derived from actual profiling data, then never revisited. Multiply this across dozens of services and the cluster-wide waste becomes structural rather than incidental.
Habit three: no cost signal at the point of the decision
The engineer setting a resource limit rarely sees the cost implication at the moment they set it — that information lives in a separate monthly FinOps report, read by a different team, weeks later. Decisions and feedback are structurally disconnected.
The fix is not another dashboard; it's moving the signal into the pull request itself, so the cost of a sizing decision is visible at the exact moment it's made, not a month after it's already shipped.
Elastic infrastructure does not remove waste. It just makes waste easier to leave in place.MNB Cloud Practice
Key actions
- Expire incident-driven headroom increases on a fixed review date
- Derive resource requests from profiling, not copy-paste
- Surface cost delta in the pull request, not the monthly report
- Treat autoscaler tuning as an ongoing practice, not a one-off setup