Voice of the DBA

Category: Editorial

  • Are You a Good Engineer?

    I would guess that many of us think we’re good at our jobs, or at least that we do a good job. Whether you’re a system administrator or software engineer, I’m sure you think you earn the compensation you get.  I wonder if others in your company would see you this way? If they know what you do as a job, and understand the role, then you should hope they see you a good engineer/admin. Perhaps you should even ask a few people if they do.

    There is a good thread about software engineers, talking about some of the things that make a good developer. It’s from a longtime engineer, and the thread talks about the things that you might consider important in a good software developer.  Actually, I think most of these items would apply to admins and even other business people.

    The first item in the thread really caught my eye because I see many people taking requirements as facts and then working to meet them exactly, or complaining and trying to avoid meeting them exactly. It isn’t often that I find people really digging in and trying to be a partner with their clients. Too often we’re too accepting or too argumentative, without trying to find a solution that makes the entire system better.

    The second item about not being a jerk is also important. It took me some time to learn that, and I still find too many people that think being right, or more talented, makes up for poor behavior. I’m sure it does in some places, but none where I’d want to work. Instead, follow the other advice and build relationships with others. That’s important, especially over time in your career. I know plenty of people who get poor recommendations from peers, and that causes them issues when looking for a job in their local area.

    There are some other items, but the one I find especially important is work ethic. Often hires need to be taught about our environment, even if they are the 10x engineer. I’d rather have someone willing to learn, someone I like working with, and someone that isn’t going to be afraid to work hard and help improve things. I’ll take those skills over past “expertise” in most situations.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Defining DevOps

    DevOps has become somewhat mainstream in that many companies, perhaps most, are talking about it or trying to implement some of the principles behind this software development approach. However, even as I talk with people that practice DevOps, I find the idea of what DevOps actually includes can vary widely among developers, even inside the same company.

    There are lots of definitions, and this one caught my eye recently. It says, among other things, that there should be “increased collaboration among not only developers and operations staff but users.” I like that there is some emphasis on working together, which is often the hardest part of changing how we build software. I find that many customers struggle because they end up adopting the technology tools, but fail to change how they communicate with others. Culture change is hard, and DevOps requires a culture change.

    The article is high level, but it does highlight some of the complexities of DevOps, mainly that lots of stuff is happening at once. Good reporting, tracking, and management are important, and unfortunately, lots of managers don’t want to change their approaches to managing teams, which further complicates the process of building better software faster. Certainly, the need to have developers work with ops people, including supporting production systems, is important, but it never happens without management requiring and supporting this collaboration.

    The drawbacks to DevOps are many. Plenty of teams slap together code, getting the “faster” part but forget the “better” part, which means increasing and higher quality code over time. They embrace new tools, but they sometimes forget to run small experiments and change their approaches across time when they find better ways of building and operating code. Or they refuse to stick with current techniques or software because they crave change. Developers also find that some groups, like security and compliance departments, aren’t ready for the pace of change, which can be frustrating.

    Ultimately, DevOps is better collaboration, getting all teams on board working together. Like many people rowing a boat, every group needs to align their work with others to ensure a smooth and successful journey. Actually creating that alignment requires strong leadership and culture, two of the hardest, and rarest, things to build inside many organizations.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Knowing When to Respond

    I ran into this quote on the Microsoft Learn site, which I thought was a great way to think about how to administer a system: “Without a baseline, every issue encountered could be considered normal and therefore not require any additional intervention.”

    When I’ve had users file tickets or complain about things not working well, I’ve found more often than not their perception has changed more than the actual performance. I’ve been called for “slow applications” only to find out that “slow” was 30 seconds and the complainer wasn’t sure how long it used to take, but today being end of the quarter, it is slow. Digging into monitoring history has shown that the query always took at least 20s and could take over 30s. My main takeaway was a little stress for users sometimes culminates in unnecessary work for operations staff.

    There certainly are times when a database query takes longer than expected but is it because the system is overloaded or there’s a lot more data? When was the last time this ran and what changed? Are there more queries against the same objects than in the past? Even when there are real problems, without knowing how a system typically looks at this time, we may struggle to quickly determine where the problem lies. We may not even know how to craft a good solution without some baseline.

    Maybe the best reason for me to know a baseline is for triaging and prioritizing issues. Seeing a server at 100% CPU is one thing, but if this is a daily occurrence, I might decide another issue is more important. Especially at 2 am.

    Having a baseline for your systems is important. Build a system if you must, buy one if you can, but get monitoring set up for your systems. It will help you focus development efforts when changed code doesn’t work as expected. It also helps your operations staff to help them respond more efficiently to future issues.

    Steve Jones

  • Reusing Tools for New Purposes

    One of the things you learn early on in programming is that you ought to reuse code whenever possible. This often means refactoring code into functions or methods. This ensures that the code is more easily maintained and that the knowledge and work of solving the problem is reused in many places.
    In database code we don’t do this too often. We certainly can reuse some code by encapsulating it in a view, but this often brings performance penalties. We often don’t want to reuse code in stored procedures and functions as embedding this into queries can cause lots of issues. In fact, it seems that much of the way databases optimize query performance isn’t that amenable to reusing code.

    That being said, I ran into an interesting case recently when thinking about maintenance in the cloud. Someone was asking about SQL Agent and the lack of support for it in many PaaS database systems. I understand that, and while there are some ways to do this, they feel complex compared to using a SQL Agent on a local instance, which is usually easy to set up and readily available. One of the speakers taking questions mentioned that they user shouldn’t forget about Azure Data Factory as an automation agent.

    That caught my attention as I hadn’t thought about it before. This week, there was a blog on that very topic and I read through it to see what I thought. While this isn’t as easy as SQL Agent, it does seem to be easier than Azure Automation, and likely more familiar than elastic jobs.  That’s if you already have ADF running in pipelines. In many ways, this feels like using the maintenance plans in SQL Server, though just the call a stored procedure task. Since many people use a solution like Ola’s, this is very easy to implement.

    I like that this pattern reuses skills and a system that you may already be using, transferring the skills from one area (ETL) to another (administration). This might not seem like much, but limiting the tools and technology, reduces complexity and means that each person needs to know less to support your environment. I’m a fan of code re-use, outside of T-SQL), and I think reusing other technology systems, where appropriate, is a good idea..

    Steve Jones