Do you have a record of what the right configuration is?

Unless you’re just starting out, you already have servers doing what they need to be doing. They got configured and built in a datacenter or launched in a cloud. Either way, there was some amount of configuration that helped shape how it does its work. Just because you or your team configured it once, doesn’t mean that it’s recorded at all or even correctly. The core question to ask of yourself and your team is: “Do you have all the information you need to create an identical version of that server in a minimal amount of time if needed?” This could be part of disaster recovery. Something catastrophic happens and you need to make a new server. Do you know what that would entail? Or it could be part of something good, maybe you’re growing and want a new app server, or something more powerful. How do you make sure that the new server has all the features, configurations, and functionality the old one did?

If you don’t have the answers to these questions, don’t worry, it’s not too late to gather them.

Some questions to ask as you go through recovering or recreating this information: What software must be running on the machine for it to do its job? What configuration needs to be present for that software to work the way you need it to? Are there special users that need to be created on the machine? For example, for automation or support Are there limits or quotas on a the machine that need to be put in place or removed? What operating system does it need? Is there a specific version or patch level? What sort of network connectivity and firewall rules does the application need to be present or absent?

Once you have this information in hand, not only are you on your way to having a more robust disaster recovery process, you’ll also have begun to pave your way to have infrastructure as code and the automation that allows.

With this information at the ready you’ll be able to respond more quickly to disasters, limiting your downtime and the time that recovery takes. You’ll have opened the doors to automating your infrastructure itself.

Further, you’ll be able to use this information to answer questions and solve problems. Perhaps you’re subject to an auditing standard. With all your configuration on record and accessible, you can begin to answer questions like “Are we using a secure version of our operating system?”, “Are our firewall rules too permissive or strict?”

Already did this? Great! The next step is to automate this configuration and provisioning, using infrastructure as code.