“A good DBA is a lazy DBA”

I’m borrowing from Andy Leonard (blog | twitter) who says all the time, “Good engineers are lazy.”

If you’re thinking, “Why would I want (to be) a lazy DBA?” let me explain. There’s a lot to be said for hard work. However, have you ever seen someone who is always busy but seems to get very little done? Hard work, in and of itself, isn’t the goal. The goal is to get things done. This is where laziness comes in.

If I have to repeat a task, I should look at automating it. I don’t want to have to repeat those steps each time. I want to be lazy. For instance, as an operational person, there are a lot of things I need to review within my production environment on a periodic basis to ensure my systems are running as they should. Case in point: ensuring the SQL Server drives don’t run out of free space. This is something that I should monitor regularly (daily).  There are different ways I could handle this:

  • I could log on to each server and check each drive.
  • I could use a tool like TreeSize to hit the drives one by one.
  • I could automate the checks which results in a report in my inbox.

I prefer the last option. If I’m smart, I’ll even schedule it to run so it’s ready for me when I get in each morning. But why stop there? I could not only automate gathering the data, but also automate some of the analysis. Let’s say I set thresholds and the automation bubbles up anything crossing a threshold to the top of my report, meaning the most important data gets seen first. I don’t want to just be lazy, I want to be very lazy. By being this lazy and automating, I free up the one resource I can never get more of: time.

What can you automate? Anything and everything you can successfully automate frees up time for you to spend tackling other things. The more your organization sees and understands that you do, the more valuable you are. If you are in IT but don’t happen to be a DBA, this is still a solid approach. Let me generalize and say being a lazy IT pro is being a good IT pro.

 

What If Someone Tampered with the Process?

I’m a big fan of automation. Automation means I can do more. Automation means I eliminate the mundane stuff to focus on critical things. I like automation as an IT professional.

However, as a security professional, a question that is ever present in my mind is,

“What if someone tampered with the process?”

Case in point: you have an automated process to build VMs. That includes configuring particular security groups for a particular type of build in the local Administrators group (you should already be doing some of this with group policy, but that is automation as well). What if an attacker was able to slip into the automation to include a particular account or a particular group? How long would it be before you caught it?

This is why I’m a big believer in a human putting eyes on automation results at some point and relatively frequently at that. In fact, I’m a big believer in multiple levels of verification. Maybe it’s my military background and things like the two person rule. If you’ve watched a movie like Crimson Tide you’ve seen it in action. Two people have keys that must be used together. This ensures that one person, acting alone, can’t do something devastating (in a relative sense).

I know there’s a balance to be met. Too much manual effort and you undo the benefits of automation. However, too much reliance on automation and you’re eventually going to miss something.