At this point in my career, I’ve realized the responsibilities of database administrators (DBAs) and database reliability engineers (DBREs) can differ from company to company, from year to year, and even from quarter to quarter.
When I explain to nontechnical friends what I do at my job, I struggle to explain it beyond, “I keep a Q&A website up and running.” There’s certainly a lot more nuance to it, and I do plan to write some content in the near term about what a DBRE does and
how a DBRE role might differ from a DBA or
site reliability engineer (SRE).
In the meantime, if you’re already a DBA or DBRE—or if you aspire to be one—here are some techniques you can use that have helped me become a productive contributor in my environment.
- Have a Routine
I have several
things I check regularly—I always have dashboards up on a spare monitor, a set of browser tabs, or a desktop I can easily switch to. These can highlight an issue as it starts happening or provide a sanity check that all is well.
But there are other types of checks—
people you check in with regularly (in addition to your manager or reports and the regular work-related meetings you’re never going to avoid). Every role is a little different; sometimes you’re putting out fires all the time, and sometimes you’re focused exclusively on long-term objectives. Most of us are in between, doing a little bit of both at any given time. Set up a recurring meeting with someone at work where you can be mutual sounding boards to talk about the little things and the big things not necessarily discussed in the other meetings you’re having.
On top of this, I have a few people in my life outside of work whom I chat with all the time—one daily on Marco Polo, one quite regularly on Slack, and one during a monthly in-person lunch. Sometimes I can bounce ideas off them either from a logical or a technical viewpoint. It can be useful to have these conversations with people not directly invested in whatever problem I’m struggling with or course of action I’m considering (without violating any kind of confidentiality, of course!). Sometimes, it can be helpful to hash things out with people who are at least peripheral in terms of skills and background—my spouse, for example, is technical, but works in a completely different industry and can’t always identify with the types of problems I solve.
- Use Monitoring Capabilities
At every job in my career, we’ve invested in monitoring tools. Though we often have to write scripts and other tools to cover gaps or scenarios specific to our environment, they cover 90% of the “let’s not reinvent the wheel” stuff. Regardless of what database platform you use, there are tools out there that already answer most questions you’ll have about the performance of your system at any given time.
For my SQL Server audience specifically:
- Turn on Query Store. Eventually, this will be on by default, and upcoming features will depend on it being active.
- Embrace, learn, and be comfortable with Extended Events. I’ve said this before: Profiler is dead, and XE is the future.
- We primarily use SolarWinds® SQL Sentry® and OpServer in addition to a few other minor players (including homegrown scripts).
However, what tool you use isn’t important at a high level, as long as it meets your needs. You should make sure it’s surfacing the things you don’t want to have to find by accident or from a user or customer. It also shouldn’t
drown you in alerts—if every little thing is important enough to trigger an alert, you can’t possibly deal with all of them. This leads to alert fatigue and simply ignoring alerts altogether. Having dependable alerts is key simply because you’re never going to catch everything in real-time. Scott Fallen gave some great overall
SQL Server Alerts: Best Practices advice for SQL Server specifically, but the concepts largely apply everywhere.
Having monitoring tools in place and surfacing the right amount of information at the right times will be much better than not having them when you need them or when you’re in crisis mode.
- Keep Up with Industry News
Even after two and a half decades, seldom does a day go by where I’m not learning something new about the SQL Server platform. Kevin Kline and I talked
in this interview about reading blogs and listening to podcasts to keep up, but there are many other helpful resources you can use to stay up-to-date:
- Read authors who specialize in areas you’re not comfortable with—and find conferences and training that cover your gaps.
- Join active forums like THWACK to participate in conversations with other tech-minded members.
- Go answer questions on Stack Overflow you don’t know the answer to (yet).
- Write blog posts about problems you solved, even if you think you have no audience or others have blogged about similar solutions. Writing it in your own words can be helpful for the reader but also for you.
- Get involved in betas and early access programs for new versions of the database platforms you work with.
- Again, for my SQL Server audience, there are neat features coming out in SQL Server 2022, but how will you get ahead if you’re still catching up on 2017 or 2019? Sometimes, you’ll need to take initiative and play with these things on your own time if your employer is stuck on something older.
- Ask, Explore, Absorb
When I joined Stack Overflow, I felt like I stepped in front of 14 fire hoses on full blast. In a complicated architecture, there are lots of moving pieces, and you may have to rely on a lot of other people to help you learn the system. Hopefully, there’s also plenty of documentation to guide you; if not, start creating it! I draw little diagrams and create spreadsheets for my own use, mostly to offset failing memory. But we dog-food our Q&A format internally as well, and I’ve created multiple questions and articles to benefit myself and my colleagues (current and future).
Like answering questions out in public, documenting a feature or “a piece of the puzzle” in front of people who are more familiar with it—or who even created it—is a surefire way to make sure you know it inside and out. It’s easy to sit in an overview session and be told how things work, but I find working with others to help explain it in your own words can be much more enriching.
- Don’t Be Afraid to Try Things
I often see people afraid to try a feature, setting, or schema change because they don’t know how it will work on large data, and they don’t have enough data locally to test anything. Take the time, go through the approvals, and get a big disk in the development environment. Disk space shouldn’t be a blocker—you should be able to restore the massive production backup so you can test some massive change you wouldn’t otherwise be able to pull off.
As mentioned above, you’re just not going to be able to become an expert in a lot of things until you take them hands-on. “Get your hands dirty,” as one esteemed colleague put it—don’t avoid trying something new because you’re worried it will fail. Failure is how we learn (just don’t strive to “learn” in production).
- Always Think About What’s Next
Though in some cases you’re just always in a reactionary state, try to block off time to think about high-level futures and solving problems proactively. It doesn’t have to be much; 15 minutes here, 30 minutes there. At Stack Overflow, we publish our own personal working hours; mine end at 3:45. I didn’t do this because I want to start crushing beers at 4:00 but because it prevents people from scheduling late afternoon meetings right when my kids are getting home from school. Conveniently, I use this time before dinner to block off little windows for myself to think about larger-scale projects and longer-term goals.
As an example: cloud. You might not have
plans to migrate to the cloud tomorrow, but more and more organizations are considering moving at least some of their data and workloads there. Monitoring will be different, and some concerns are traded off for others—for example, you no longer have to worry about backups or high availability, but now I/O performance might be a bigger concern. Security, networking, and other aspects are likely to be a bit different too, so try to familiarize yourself with some of those differences so you’ll be better prepared when the time comes. Keep in mind some of this knowledge may not help you immediately in your current role, but it could be useful in your next role.
Hopefully, some of this information helps you carve out ways to be more productive (and more proactive) in your current or next role. In a future article, I’ll talk about some of the more specific differences I’ve seen in a few key roles over my career.
