The Holy Grail called Immutable Infrastructure

it is quite common to fix small problems directly on production servers by directly logging on to them and then back propagating the configuration to where ever you save the configuration. This is such a common practice that there a lot of tools available that will allow you to sync your configuration between production, or even staging, QA, Dev and your source of truth for configuration. For ITIL if you store your entire configuration in CMDB, any product worth its weight offers a discovery tool that facilitates this kind of sync. Conversely if you support your configuration via software like Chef, Ansible etc you might quickly make changes at source and push out your changes to the server. Or make changes to both the places at the same time to keep them in “sync”.

The problems with this approach are immediately clear. Configuration drift can happen between the servers and the source of configuration. Patches are applied every time a new server is built. Long running servers can begin to rot and smell. Servers can become prima donnas that need to be handled in a certain way by certain people or they refuse to work. In short, there are lots of avenues and opportunities for things to go wrong.

You can read the complete post here The holy grail of Immutable Infrastructure