Voice of the DBA

Tag: career

  • Organized Learning

    I really wish I’d do something like the DBA Training plan from Brent. Honestly, I don’t have the time to do it the way he is, and certainly can’t respond to any volume of emails, but I applaud the way he’s doing this. Brent is sharing a lot of ideas and information on how to start getting a handle on your environment. As of this writing, there are 8 posts (part 8). I expect more in the future.

    Becoming a DBA is often a random collection of experiences that almost everyone goes through in a different order. Maybe you started by having to recover a database with a restore. Maybe it was the need to install the server software and configure users. Maybe you find yourself more interested in writing database queries in T-SQL than methods in C# and switch over. However you learn, there are two things I know: your environment will drive your learning and there’s always more to learn.

    My start as a DBA came about when I needed to install a SQL Server instance to handle a new application. It was important that I understood the general admin duties to ensure backups and manage security. At first I didn’t think much of the platform, but as I tried to troubleshoot performance issues, I started to learn about how connections are made, resources are used, and what bad T-SQL looks like. From there, I moved on to more development before coming back to the admin side later.

    It would be great to have a class that teaches you to be a DBA, but really, the job has somewhat varied at each position I have held. There are some specific things that are important at every job, but the exception is often the rule as to how you ensure your environment works well. Once the system is in production, it becomes very hard to change anything, from security to code, without lots of testing and approvals. I find that often trying to work within constraints drives a lot of learning, though not often deep or varied enough to investigate all the options.

    I don’t know everything about SQL Server, but I have developed two very important skills in my career. I’ve learned how to learn, by reading, researching, and practicing new skills. I feel comfortable that I can come up to advanced beginner on a topic very quickly, usually competent enough to make something work. Second, I’ve learned how to ask for help. I’m lucky in that I have lots of friends I can call on for questions in specific areas. If you don’t know someone that’s an expert, I hope you know about #sqlhelp on Twitter and the forums at SQLServerCentral. These are great places to get help on whatever is troubling you about SQL Server.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Production Kubernetes

    Still learning more about Kubernetes. I’ve been working through the 50 days of Kubernetes (K8s). Let’s keep exploring

    The API is the security boundary

    Everything happens with the Kubernetes API. Therefore, we want some RBAC here for the roles of individuals, as well as processes, like CI/CD pipelines. We want to ensure we have validation, security scans, etc..

    Things will go wrong

    In addition, we need some monitoring on the cluster. We need this on any system, but with scale and complexity of containers in Kubernetes, we need something in place.

    In addition, you want to test failover, which is likely between clusters. Containers do make this easier, but it’s something we want to ensure is a part of our process. This means practice. We know practice matters in most places, but we often don’t practice well in IT.

    Scaling

    There is planning to think about a large application, or maybe large for your environment means thinking about global access and ensuring that you have a way for your app to easily redirect across clusters or regions. There are also data challenges, as Brendon notes, with things like databases. It’s an opportunity to push CosmosDB, but in the relational world, we know how to handle this.

    Kubernetes will make AGs and HA easier.

  • Salaries in Job Ads

    Hiring at Basecamp is interesting. I caught this interview and think it’s a good look at a process most of us have gone through, but perhaps not thought about. Maybe we ought to try and not start out our relationship as employer/employee with a “I got one over on you”.

    Of course, many companies are not interested in treating employees well and just assume they’ll hire/fire/turnover often. Makes sense in some places (McDonalds type work), but less sense in our industry.

    I do think that we hide salaries too much in our industry. Certainly this aids in favoritism and entitlement for works with seniority. I’d really prefer to see salary ranges published for jobs, both internally and in the description. And not some huge range, but put something like a junior DBA from US$35,000-50,000. Or whatever range you think is appropriate.

    This would do a few things for me. First, it ensures that candidates that want to work for that range will apply. It also ensures you don’t waste time with a developer that wants to move to DBA work, but really needs $70,000 for their financial commitments. This also helps you determine if you’re range is correct for the market.

    I am a big proponent of disclosing more info up front and finding a good match between employer and employee.

  • The Aware DBA

    A long time ago, at least, a long time in the eyes of my kids, I worked for a large organization as a production DBA. We had a generic monitoring tool, but it wasn’t SQL Server specific. I ended up writing my own enhancements for the tool that used its data, as well as gathering other SQL Server specific items into a local database on each instance. From there, I had this data copied to a central location each night and a report generated. This helped us with ISO certification (originally) and later, Sarbanes-Oxley compliance.

    I was reminded of that when I read Pamela Mooney’s post on Things You Should Know About Your Server. She follows the simple method of ensuring each server monitors itself and rolls up that data. This works well, even if I’d never want to do this again. The time I spent building a monitoring system wasn’t really time well spent. These days I’d buy some monitoring software and then query that data, bother the vendor for enhancements and have either a notebook or a smaller set of processes that gathered specific data I might need. Likely I’d use XE and some stored query data, but if I monitor infrastructure, I don’t want to have to worry about building and maintaining monitoring software.

    The main point from Pamela’s post, however, is that she seeks awareness of how the systems work. That’s the key for a successful sysadmin of any system. You should not, and do not want to, check each system every day, but you do want to know how to find out what is “normal” quickly and be aware of changes. We want to quickly narrow down potential and possible problems because of our experience and history with some server/instance/application/etc.

    Most of us get calls on a few systems regularly. We may know those well, but often we’re fire fighting and normal can be an elusive definition. There are often many systems that we rarely get called to examine, but most good DBAs I know have some idea of how almost every system performs. Having a little data available quickly allows us to diagnose whether a problem is real or imaginary, chronic or transient, as well as how to proceed to resolve any issue.

    Awareness is an important skill when dealing with anything on a regular basis in your life. Certainly in parts of life outside of work, but even at work, paying attention and having some idea how how your environment should work will help you catch, diagnose, and solve issues. The best DBAs might do this before the client even calls.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.