In previous a post I talked about lost time associated with manual processes and hand-offs between teams, but in this post I want to look at time from a different perspective…
One of the big arguments I hear against automation is, “We don’t have time to work on automation!” If you don’t think you have time now, how are you going to make time when you have to deal with another 10, 100, 1000 servers? I don’t know about you, but every week I have to deal with more stuff, not less. If I waited for a convenient opportunity to work on automation, it would never happen.
I think a lot of this comes from a flawed mindset as far as automation is concerned. There seems to be this attitude that we have to get from where we are now to a full blown private cloud solution in a single step/project. Instead we should be trying to incrementally improve things. This idea of continuous improvement has been part of agile and DevOps for years. It doesn’t have to be great leaps. It can be small incremental changes, that over time amount to something big.
As a DBA we might think of these baby steps along the path.
- Stop doing GUI software installations. Instead focus on silent installations of software. This is probably the easiest thing a DBA can automate because Oracle have done all the hard work for you. Silent installations of most Oracle products are really easy. What’s more you can put your scripts into Git and you have a proper record of what you did. It’s surprising how many people have no record of what they did and how they did it!
- Stop doing GUI database creation. Just like the silent installations, Oracle has done all the hard work for you here. You can use the DBCA in silent mode and once again put your scripts into Git.
- Once you’ve got 1 & 2 sorted you can start thinking about scripting post installation and post DB creation tasks including patching and other operational tasks.
- Once that’s all running, you have some basic automation in place, which you can improve over time, you might want to try out some alternatives, like switching from shell scripting to something like Ansible.
- Once you’ve got some stable and reliable automation, you can start trying to integrate it with your System Administrator’s build and patching processes.
- At some point you might want to make some of these operations self-service, so users/developers don’t even have to ask you anymore, they initiate the automation themselves. You will still be responsible for creating and maintaining the automation, but you don’t have to be there 24×7 to manually run the scripts.
If all you have time to do is steps 1 & 2, you will still have saved yourself some time, as you can start a script and do something else until it finishes. That could be working on improving your automation. Added to that you’ve improved the reliability of those steps of the process, so you won’t have to redo things if you’ve made mistakes, or live with those mistakes forever.
I understand that company politics or internal company structure can make some things difficult. Believe me, I run into this all the time. I can build whole systems with a single command at home, but at work I have to break up some of my automation processes into separate steps because other teams have to perform certain tasks, and they haven’t exposed their work to me as a service. As frustrating as that can be, it doesn’t stop you improving your work, and maybe trying to gently nudge those around you to join in.
Remember, each time you save some time by automating something, invest some of that “saved” time into improving your automation, and automation skill set. Over time this will allow you to take on more work with the same number of staff, or even branch out into some new areas, so you aren’t left out on a limb when everything becomes autonomous. 🙂
Check out the rest of the series here.
Cheers
Tim…
PS. Continuous improvement (Kaizen – Masaaki Imai – 1986)
“Kaizen means ongoing improvement involving everybody, without spending much money.“
“The starting point for improvement is to recognize the need. This comes from recognition of a problem. If no problem is recognized, there is no recognition of the need for improvement. Complacency is the archenemy of Kaizen.”
So true, thank you for the Vagrant scripts.
Peter: No worries. I’m glad they’ve been helpful.
Well, for this automation, you need to write mountains of scripts, which all have to be maintained and modified over the years. When a new DBA comes in, he/she has to learn the automation language. Maybe the automation language gets outdated after a few years. Then, use another automation language and rewite. More and more scripts, scripts calling scripts. Been there, seen that happening for years. I think this is exactly what Oracle is trying to prevent with its cloud database and autonomous features. Before the cloud came along, Oracle was taking about Enterprise Manager automation and its ability to avoid scripting.
Keedi: Absolutely, cloud can shortcut much of your automation efforts, but you still have to learn. On AWS and Oracle Cloud, you will need to interact with APIs to automate deployments, so there is a still a task for you, even if once you initiate it, they automate the rest.
Cheers
Tim…