Recently, I have been doing a lot of work a server administrator would normally do. I set up a continuous integration system and played around with virtualization at work and deployed a couple of python apps for a side project. Being a software developer, this has been both a challenging and fun experience. It also got me thinking about all the buzz about dev-ops you read nowadays. Dev-ops (development and operations) refers to a company structure where the development and server administration teams work very closely together or even without a clear distinction between the two fields. I am very much in favor of close collaboration, but the approach also has its caveats.
As a developer, my main responsibility is to create and maintain good software and although I know the basic concepts I am not trained in systems administration. Yes, I can install a server and get my application running. I will also go ahead and disable root login via ssh to prove my security lectures were not a complete waste of time. But without following the subject closely and practice and improve my skills on a day-to-day basis, like a full-time sys-admin would, it is very hard to bring a system in a state where security best practices are followed, redundancy is properly implemented and good sleep can be found at night.
For this reason it is the least we can do as developers dropped into the engine room to document very carefully what we do. Because what will happen is, we will get it to work, walk away and forget about it. Then a week later something will break and we’ll have to put on the old sys-admin gloves once more only to redo the whole research and learning process again. Or maybe somebody asks you how you set up the external juggly-tubes on that one server. „The what? Gee, I don’t remember.“ A good documentation – a recipe on how to get a specific job done – can save the day.
And the best documentation when it comes to server administration is automation.
Automation comes in many shapes and forms depending on the job and the personal preferences of the people involved. It can be an elaborate shell script or a complex automation tool. In any case you’ll end up with something that describes the task you were trying to complete and it also does complete the task. Perfect. Next time somebody calls you to tell you the fancy new app on the virtual cloud docker thing has crashed you can just press a button and automagically re-deploy the thing.
So, please don’t have any machines in an undocumented state running in your production or development environments and best make sure everything is properly automated and the process is reviewed every now and then.