Voice of the DBA

Author: way0utwest

  • Daily Coping 2 Aug 2022

    I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

    Today’s tip is to what do you appreciate in life?

    My health.

    I’ve talked with a few people lately that are

    a) either worried about COVID and health (for good reasons),

    b) have gotten sick or had a family member get sick and had a rough time

    c) struggle to accomplish things they want to do

    I’m fairly healthy. Yes, I had ankle surgery a few months back and the ankle still hurts, but it’s getting stronger and healing. I’ve had COVID a few times and been fine. I had to take a week off, from last Tues to today after getting some hormone therapy.

    Those things make me appreciate how lucky I am to not have had any major health issues and that the treatment I’ve sought for minor ones has worked well.

  • How Often Do You Update During Issues?

    I use Libsyn to store podcast files. They’ve been a reliable service for me for years. Once in awhile uploads are slow, but things seem to work. The other day I went to upload a file and got a status message that there was an issue with database maintenance. When I looked at the status page, I saw a few updates. This was for a platform issue, and I saw this set of updates. I have the timing that I saw on the page with my own comments added:

    • 1139 – reports of issues. We’re looking into this
    • Three hours ago – Identified the issue related to db maintenance, working on it, other services affected.
    • Three hours ago – all services affected, working, update soon
    • Three hours ago – emergency maintenance on db systems, we will provide regular updates
    • One hour ago – db maintenance in progress, now healthy nodes, turning things on.

    That was what I saw at around 3:30 my time. I went back the next day and saw a more detailed set of times listed and a note that the cluster was fixed and then all services were restored. While I couldn’t upload things that day, I did check that downloads for listeners were working, and they were at that time.

    I have no idea what happened, and I did appreciate an email the next day that apologized and noted this outage was not the result of malicious attacks and that no data breach had taken place. The latter item hadn’t occurred to me, but I thought that was a good reassurance sentence in the email. I’m sure it was a rough day for DBAs and the Ops staff, and hopefully, they were able to restore all data.

    My concern, however, was that multiple times they noted they would post updates soon, but there were some pretty good gaps in the status messages. While I liked a few quick messages together (3 in 30 minutes), the long gaps are disconcerting to me as a customer. I expect management would feel the same way and hopefully, management was updated more often.

    If you’ve been in an outage, sometimes there isn’t a change in status. A long restore or rebuild of some sort can take time, with platforms not always reporting progress or an estimate of time remaining. Even when you get some progress, we all know that the time to go from 25% to 50% could be shorter than the time to go from 90% to 95%.

    When I have had to report to management, or to an incident team, usually we have regular updates. Even if these are “no change, we’re still working,” it’s good to let others know what you know. I think that’s important for customers as well, especially those that might have time-sensitive expectations for using your application. Without an update, anyone checking a status might not know if anything has changed, if things are worse, or maybe that you forgot to post an update.

    My recommendation is that there is someone dedicated to logging what is happening and taking notes for later review. This person is also someone that ought to be responsible for updating others on a regular basis. Every hour, every two hours, something regular. If you have external customers, then they should expect and get regular updates, even if these are “no change, the cluster is still rebuilding.”

    A little transparency goes a long way for your customers.

    Steve Jones

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

  • Daily Coping 1 Aug 2022

    I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

    Today’s tip is to find 3 things you feel hopeful about and write them down.

    Three things that make me feel good about life:

    1. People are excited about live events. SQL Saturday New Jersey was a good sign.
    2. My kids are coping better in the world this summer, which makes me feel good about things. They all see the world differently and are in different places in life, but all happy.
    3. More opportunities for travel for my wife and I keep appearing, which makes me think the future will be better.

  • GitHub vs. Azure DevOps

    I work often with Azure DevOps. I have enjoyed the platform and it does what I need. I also work regularly with GitHub and GitHub Actions. Those rebuild SQL Saturday and SQL Memorial when I need to make changes. It also works very well.

    This week I saw a post on choosing between Azure DevOps and GitHub, which is something I get asked at times. The post goes into some of the differences and provides a lot of links that you can use to read about features. There also are plenty of links on using the two products together, which is something I see regularly. Code in GitHub and the build/test/release in Azure DevOps.

    On the question of which one, the author doesn’t give a recommendation, but rather some questions on things you might think about. The author asks about the features you use or think you will need and using that information to help guide your decision. I think that’s fair, but here’s what I’d say.

    If you have no automated version control or build/test/release tool in your organization, then choose Azure DevOps. It has a lot built in that I like and it’s simple to use. I think it’s visually pleasing and I think it is easier to teach people how to use it for this reason. GitHub is fine, but I find it slightly more confusing to move around in, though to be clear, I spend more time in Azure DevOps, so I’m likely biased.

    I’ll also separate out version control. I assume your organization has someone using version control. Whatever system they use is the one to adopt. There’s no reason to argue or get them to change. Most people use Git and all Git host services are essentially the same. We could argue some small thing you want, but really Git is Git. Use what others use.

    I would say the same thing for build, test, and release. Use what software developers use. These systems are all good, and they all have pros and cons. They all do some things well and have some disadvantages, but they are really interchangeable. I wouldn’t move build systems or release systems without a really good set of reasons to do so. Just because the new lead or CTO likes another system or has experience there isn’t a good reason. If you don’t have any system in your organization, then see my recommendation above.

    Modern software development needs a team, and for teams to work well and efficiently, you need version control and an automated build/release system. Use what others use, or have some people conduct a few pilots and then take vote and go with the results. Really, all these systems are similar enough that it’s not worth more than a few minutes of discussion.

    Steve Jones