I try to summarize some impressions and thoughts I've had on configuration management. At this point I've worked with information technology for about 22 years, and for the last ten-or-so years become convinced that formal configuration management is the way to go. And no, by formal I do not mean a suit, tie and a binder!
What is configuration management
"Configuration Management" is a specific term in frameworks such as ITIL. Do not let this scare you. I promise it's a good idea!
In its broadest sense configuration management is managing the configuration of a device or system of devices. By managing I mean keeping track of changes and ensuring that the system is configured according to your requirements.
As soon as you have even one singular computer that is relied upon to do some kind of task, you enter the realm where you are in need of some kind of configuration management.
The process of managing configuration is surprisingly often done by hand in the industry. It may be that some document describes the system at a broader level, there might be wiki articles that describe parts of the system in more detail, and there are checklists, scripts or both to do tasks that are done a more or less regularly (software updates and such).
Why automate?
Configuration management sounds straight forward. Why do we need to automate it? There are a number of reasons. Here are two central ones:
Quality: Even if you have a good description of you requirements, there is no guarantee that your system actually ends up configured according to the description. And even if it does, the configuration will drift. The drift can have multiple reasons, but often it can be system updates nudging the config or operators tweaking the system to diagnose problems. Keeping the system consistent can require substantial effort.
Legal and contractual: By providing a service you are most likely bound by both legal and contractual obligations to demonstrate an appropriate quality assurance process. By automating the configuration management process in a clever way, you can connect it to your QA system so that you simply by performing configuration management provide a good part of the required documentation.
Versioning and documentation
Actually, this ties into several other processes as well. If you pick a configuration managment tool that can keep its definitions in a GIT repository, you get versioning. I've had good experience using Puppet definitions stored in Gitlab. This also means that you can set up access control the way you need it.
Gitlab projects also include "issues", which can be used for things like change requests. You can then employ DevOps-like methodology to your definitions repository:
- Issue templates can contain the required checklist points
- From the issue (change request) you can create merge requests - a separate branch where you can test changes without touching production systems.
- Changes are automatically tested on push by CI automations (you can even validate the checklist in the issue if needed)
- Before the change is accepted you can employ code review and other approval sign-offs
When the changes are merged, the configuration agents pick it up and ensure they are effected throughout your system.
Your project now contains your system configuration definitions, versioned and for each change there is a signed checklist to document it.
...and the reports from your monitoring system prove that your systems are configured as defined in the code. You have monitoring, right?