We asked a senior database administrator to talk Computer Business Review’s readers through the life of a DBA, for this behind-the-scenes look at the job. (The author would, understandably, prefer to remain anonymous.)
There are many issues the DBA (database administrator) faces: from servers going down, to login access not being requested on time. In the modern day we would expect such little tasks to be automated. Sometimes they: but depending on where you are, automation is largely a buzz word, like your office’s “war on waste”.
However, the most challenging part of the job is “difficult” people who don’t understand the role. These can be found across all departments, from staff members right up to managers. Nothing new there. But there is a significant lack of understanding across the company of the pressures we are under in such a small team.
In fact, there appears to be little understanding of the role of the DBA: that it is not only a support role, but a programming role as well.
In SME’s, DBAs can range from operational to development DBA’s and the role can be in a state of flux because of factors like sickness, leave and recruitment issues. This makes life particularly tough for DBA’s in an SME environment.
Banks and larger organisations by contrast tend to have dedicated teams of DBAs that sit alongside development teams in open space offices. This helps cross-communication and brings a welcome camaraderie.
DBAs in an SME environment do not typically have this luxury, so you need to be a flexible DBA at all times. Across the company, “difficult” people simply don’t understand the pressures and as a result I find myself having to adopt a “difficult” stance in return, because, as a manager, I need to shield my team from these people as they can upset the delicate team balance. We’re already run ragged.
Cost-Cutting: Free Tools Don’t Necessarily Make Easier
At the moment we have massive pressure to cut costs; this is taking the form of company-wide consolidation.
We are also looking at and using new tech tools like MongoDB and MySQL as these tools are free and there is an assumption that because they often have ‘SQL’ in the name, the DBA staff will be able to confidently work with them.
However, each tool has its own nuances and can take a while to get to grips with — for example a missing command — and are far from MSSQL and Oracle’s methodically developed products. It is like assuming a Chinese person who understands Cantonese will understand Mandarin Chinese; in my experience they probably won’t.
Read this: Database Diversity: The Dirt, the Data
Earlier I mentioned automation. We have embraced this, particularly in day to day DBA tasks which look at things like SQL Agent Logs, Windows Event Logs and SQL Server Logs. We have built a dashboard around these so we can check CPU, updatestats and also cycle error logs automatically. However, the main focus of the DBA to focus on performance and fine tuning. We do this by looking at the efficiency of SQL queries and indexes. This is a time consuming. And if shortcuts are taken, for example during realistic testing, then massive performance issues can arise.
[Ed: Enterprises typically need to test changes to their database environments before they roll out these changes in their production environments.]
Staffing is a Perennial Stress
Staffing levels can also cause stress and affect the balance of the DBA team.
A key team member is off to greener pastures and their role is not being filled, owing to company belt-tightening. As a consequence, that person’s expertise is lost and steps have to be taken to compensate for this. So other staff member are having to learn new technology, which can be good — and most of the time it is.
However, in a situation like this, “crisis learning” can result in a serious knowledge deficit. In this instance, The team have new challenges as re-indexing and running performance scripts in their current environment is different from how they’ve learned to do it in MSSQL. There are also challenges running backing up and restoring.
Most companies will have a single backup and restore policy. Ours is to backup and restore every database; we have automated tools based around an MSSQL environment. However because we are now working in various flavours of SQL, this issue is more complex; as a result our automation tools are now not fit for purpose and need re-inventing. All of this, although hugely necessary, is a task that diverts assets away from analysing performance issues. And technical managers a rung up from us seem to have lost the ability to understand grassroots operations. Cuts are a false economy.
Change Control
A DBA always cares about change control and with this a DBA not only needs to know SQL but programming languages like C#. We use these tools to run stored procedures on all versions of SQL, to create logins from a front-end tool, take backups and also provide change control accounts for our change release managers. DBAs not only need to know databases but also be security experts , high-level decision makers – releasing jobs like running SOC controls. We are jacks of all trades but masters of none.
There’s always a lot to learn and do, but due to the changes in my team recently, we have gone from a fully operational DBA team and become more of a DevOps style team; but we are still doing the operational role I have talked about above.
This makes it hard to maintain focus and I don’t think upper management grasps this: all these changes look good on the balance sheet, but might not be for the people doing the roles. This also makes it hard to focus on the end game, or even know what it is. (Large enterprises usually know the end game in advance and plan over a two-year period with a road map. In the medium-sized company I work for now, I have never seen a road map and things change on a daily basis.)
One thing that really needs to change is the number of meetings we have. It severely erodes time set aside for doing day-to-day operational work.
Having moved to a DevOps-style team, we now work in sprints.
Sprints maybe good, as you know what you need to do, but in two-week sprints with all the meetings it is sometimes hard to finish what we are working on.
Is it really viable to have a meeting for performance issues, a 30 minute stand-up catch-up, a retrospective meeting, sprint planning sessions and refinements as well as other meetings? It makes it seriously hard to focus on what we are doing. Tighter tailoring of the methodology we use to make sure we do not having meetings for meetings’ sake, but because we actually have issues to cover would be welcome; I’m trying…
A knock-on effect of this, is that it leaves little time to improve the infrastructure and patch the database systems we currently have, as well as conduct performance code reviews with dev team members so changes that are released do not cause issues; we seem to be fighting a no-win situation. The more the team is trimmed and their responsibilities grow, the more opportunities for self-improvement are reduced and can only be achieved outside of working hours, unbalancing the work/life balance.
With a US office, late-night calls, and out-of-hours support, it’s only so long until something give. Meanwhile, improving the technical ability of the team gets ever harder.
Banner image credit: Sebastian Herrmann, https://unsplash.com/@officestock
