Voice of the DBA

Category: Editorial

  • Digging into an AI Algorithm

    One of the more successful uses of AI (artificial intelligence) has been in the medical field. It seems that there is a tremendous amount of data, high variability in some aspects of the target of the data (the patient), and a need to constantly review very tedious volumes of data. A place where AI might, and has, made a difference to help humans, not replace them.

    There’s a neat article that dives into a bit of how a medical algorithm works for detecting sepsis. As you scroll, the article tries to explain in layman’s terms what the AI system(s) are doing. It goes through the necessity of regular data, which I think is a good design to push humans to gather data. It then talks about a variety of neural networks being used to analyze data, based on previous training from humans and past results.

    It’s interesting to think of multiple nodes coming to their own conclusions are different times of the day and then later nodes looking at the results of previous nodes. That’s what a human would often do, looking back at recent history and giving that some weight. The system comes up with a number that a human can use to consider in their diagnosis.

    It is interesting that the article talks about the need for humans to better communicate to use this system. I think that’s often a key with any computer assistance. The humans still need to use the computer as a tool and not as the final decision maker. However, at least in this instance, the tool seems to be helping reduce deaths in the hospital. I would hope that this is because the algorithm is detecting some patterns that are easy for a doctor to miss. It could be because the new system is focusing people’s attention better, and possibly this is a combination of both of these possibilities.

    I do think that AI systems can be very helpful in assisting humans in many tasks, and medicine might be one of the places where AI will be most useful. The sheer volumes of data, the complexity of the cases, and the load placed on medical workers to monitor many people can overwhelm any one doctor or nurse. Having a system that might remind them of a small detail will hopefully save lives.

    Steve Jones

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

  • 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.

  • 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

  • Being Reasonable

    The last two years have changed the way many of us work in technology. The pandemic allowed many of us to work remotely, a challenge that many companies are struggling with. Or perhaps, management is struggling with and employees appreciate. In any case, no matter what your situation, the way we work has changed.

    The change wasn’t easy at times, and even though many people appreciated the extra time in their day from not commuting to work, they often had other challenges. Co-existing with others in a residence, finding a place to work that allows concentration, and even learning how to separate work from home life. These have been issues for many data professionals and other technologists. Even if we’ve had an easy time adapting, not all of our colleagues have felt the same way.

    One of the core values that we have at Redgate Software is being reasonable. It’s a somewhat amorphous value that I didn’t know how to interpret or act on at first. Our former CEO repeated this often in updates, to the point where I have heard other management and employees use the verbiage in meetings on a regular basis.

    I think as a company, we’ve learned how to be reasonable with others. We don’t overly rely on policies or rules to guide us in how we accomplish work and interact with each other. Instead, we use judgment, and managers are flexible in their interactions with employees. As a Type-A, driven American, it has sometimes felt strange to not have everyone trying to outwork everyone else. It was an adjustment for me.

    The idea is not that we do little work or avoid work, but that we avoid working too much. It’s not about the hours anyone puts in, it’s the contribution they make to their department. No one watches the parking lot to see who’s in the office or who’s logged in. Instead, we expect people to manage themselves, meet their commitments, and be accountable for the tasks they’ve been assigned. At the same time, we cover for each other and support the team. We’ve had people out sick, out for maternity/paternity leave, or struggle with other life-altering issues. The rest of their team will help cover for someone, knowing they will do the same for us.

    We treat each other as humans, have empathy for others, and act towards others as we would want to be treated. At the same time, we have goals and missions to drive us forward to build a better company. We find balance in how we do this, and it’s worked very well for over 20 years. In many ways, it’s how I try to live life. There are good and bad days. There are busy ones, some hectic, chaotic times, but also slower times when I can recover and recharge.

    It is really hard to describe what being reasonable means, and at times I am not quite sure how to act in a situation, but I try to put myself in someone else’s shoes, see their point of view, and then decide how I would want to be treated. That usually guides me as to how I should proceed. It’s worked well for 15 years for me and I look forward to being reasonable for the next 15.

    Steve Jones

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