Voice of the DBA

Category: Editorial

  • Rogue Colleagues

    The economy might be good or bad for you right now. Some of that depends on where you live, what your employment situation is like, what your habits dictate about how you live life, and more. No matter what your situation, likely there are people around you that complain about the world and others who think things are fine. There are likely more of the former than the latter, but that’s because humans tend to complain out loud more than they praise.

    When people think there is an economic downtown for themselves, they may be more likely to engage in malicious activities. While I don’t think most data professionals will start to hack other systems, or even their own employer’s systems, there is evidence to support the idea that some might be susceptible to recruitment by bad actors. This piece references some research and warns security groups to be wary.

    There is no shortage of books, or television and movie scripts that might show creative ways to access information, but how can you tell if a colleague makes a simple mistake or they are a bad actor? Clicking on a phishing email could be either one. Not removing anonymous access to an S3 bucket could be either. Losing their credentials through social engineering is something that happens every day. Who’s to say that this happened purposefully?

    I don’t want to second guess the people I work with making mistakes, but I also think these possibilities are why we want to use our computer systems with strong auditing and multiple groups reviewing logs. We might not necessarily stop all activity, but we can often detect it quickly and mitigate the issues. It’s also why DevOps and automated deployments with logging are a good idea. They can limit the problems from both accidents and malicious actors.

    My employer has started to do more education around security and how individuals can avoid accidentally causing issues. We use a lot of automation, and more all the time, that ensures once we know how we ought to patch and update systems, we can do it regularly and confidently. Repeatable, reliable deployments of changes are what we aim for.

    We know they’ll be some mistakes, but we also know that we can quickly identify issues (MTTD) and fix them (MTTR). Even if we get a bad patch from a vendor, we can quickly deploy a “fix” if we get one, or even reinstall and re-patch to lower levels, if needed.

    DevOps, GitOps, and other xxOps aren’t just about getting new features out quickly. They also include the ability to fix problems when the need arises. They don’t prevent rogue actors from causing issues, but they should help you detect and recover quicker than you might expect.

    Steve Jones

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

  • Looking Forward to the PASS Data Community Summit 2023

    I was lucky enough to attend the very first PASS Summit in 1999. It was a brand new event, and while not overly large, it was busy and crowded in the basement of a Chicago Loop hotel. I had the chance to meet Kalen Delaney there and ask her a question. That was the highlight of the trip, but I also learned a lot about SQL Server 6.5 and 7 there, spending all the time I could in sessions and hanging out after each one listening to the questions others asked the speakers.

    Since then, I have been lucky enough to go to most of the Summits. The event has changed a bit, and I look forward to going to see friends each year and re-connect with them. I’ve also loved meeting new people, often those I’ve corresponded with online. Each event has been memorable and exhausting at the same time. It’s a busy week, and I can sometimes feel overwhelmed. However, it’s always felt like it was worth the trip.

    I saw a video from Kendra Little where she talks about what she’s looking forward to this year. She has a few things on her mind: connecting with people, learning from the people who write the software, learning from those that use the software, broadening her horizons, and being a part of the data community.

    My thoughts are similar. Last year I was looking forward to the event in person, but apprehensive with all the commitments I had for Redgate with speaking. This year I’m much less involved, working more on things before the Summit and I’m hoping I can enjoy the experience more with less work during the event.

    For many years I was always excited about the SQL Server Central party. That was a highlight for me and I was sad when the referrals that funded it went away. Perhaps I’ll get find a way to get it back in the future. For now, I want to connect with more people. I want to do this casually in a few ways. From the #sqltrain on Sunday to a few quiet dinners with friends during the week to taking time at night to attend some of the events that various vendors will sponsor, that will be a great chance to bond with friends (new and old) in a social way.

    I also want to connect more professionally with people, which I’ll do in the Community Zone, as Kendra suggests, but also around the convention center. I am planning on not having to rush to many things, which means I’ll have more time in hallways and after sessions to talk tech with speakers and attendees. I’m always amazed by the ways some of you use databases and software, and I find myself learning creative solutions that I might suggest to others in the future.

    The last thing that I’m looking forward to is the chance to motivate a few more people to run SQL Saturday events in 2024. We’ve had some new events in 2023, a few more than 2022, but not nearly as many as we used to see each year. I’m hoping to connect with more community leaders and volunteers to try and get them to consider organizing an event in the future.

    The Summit is a great investment in your career as a data professional, and it can be a good investment for your employer. Make a case, show them you want to learn and grow, and that what you learn there will help you in your job. It’s a park for those of you that bring value to your employer and the can help with retention. You’ll gain knowledge and make contacts that help you on a daily basis.

    I hope to see you in Seattle this November.

    Note: The price goes up Sept 20, so get registered before then.

    Steve Jones

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

  • The IT Jobs AI Can’t Do

    This was a provocative title: 6 ITOps Skills That Will Never Be Automated. In a time when AI use is growing quickly and many people fear for their jobs, it’s nice to see someone writing about areas that AI will struggle to handle.

    Ironically, lots of these articles are written by writers without much technical expertise and who are more likely than others to struggle in the age of AI. If a computer can mimic styles, less writers will be employed. That might be fitting with so many journalists hyping technologies without really understanding them, doing so in a way that creates stress among actual IT professionals.

    The article lists 6 jobs: policy config, incident response, complex scaling, app feedback, ITOps tool deployments, and end-user support. Of these, I’m not sure that app feedback and end-user support are good-paying jobs that many people want, but I know there certainly are people working in these areas who depend on those jobs.

    The others are often jobs that few people do. I do think that these are complex jobs where a computer can’t really take in enough information to do a great job here, but I do think that one smart worker could learn to guide an AI that does a lot of the busy work. Someone could specify a policy from an AI and then ask the AI to tweak it as holes or gaps are identified. I think over time a lot of quick incident response items could be handled by an AI, albeit with a human guiding it. Again, that reduces the need for humans in these roles.

    To me, that’s where the AI revolution becomes scary. AI is a lever to get a lot done. Fewer humans can be used to accomplish tasks with the aid of AIs, which reduces a lot of the labor needed. After all, we know that in any area, there are lots of beginners and advanced beginners doing work. If we can use an AI assistant to help one or two humans, we might remove the need for a dozen others.

    Maybe that’s what a future 10x engineer looks like. Someone that’s way more productive than many others because they’ve leveraged the computer (in the form of an AI) to get a tremendous amount of work done.

    I do think there are likely jobs that AIs can’t easily do, but I also think that a lot of the work in these areas might get copy/pasted between organizations. Policies, scaling choices, and more are things that one human might learn from others and mimic those efforts. With better judgment than an AI, but not as much as if a true expert were coming up with the best solution for a particular situation.

    Unfortunately, most of us don’t come up with optimal solutions, and our organizations run fine with sub-optimal code/policies/decisions/whatever. Will companies get by with very few highly paid people or a few more low ones and accept mediocre software?

    That already happens far too often already. I suspect like most trends, we’ll see quite a few organizations move in this direction. However, I think the human ingenuity will win out and as a few companies realize that the creativity of humans can better target their goals than an AI that merely summarizes other work, the pendulum will swing back.

    Unfortunately, a lot of people will get caught in bad situations as this happens. Work on your skills, technical and soft, and be sure that you are in the best position you can be in as the world embraces and evolves with AI technology.

    Steve Jones

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

  • Power BI and Git

    When Power BI was released, I was working with customers to try and adopt DevOps for their database code. At that time, I thought the Microsoft developers had made an extremely poor decision with the PBIX format in that it wasn’t well suited for version control. In 2011, when it was first released, we not only had decades of knowledge about version control and the power of DevOps, but we’d also been living with the extremely poor format of code in Integration Services packages (among other data tools), that were poorly suited for understanding in version control systems.

    Power BI has grown, and with the Fabric announcements, there are integrations with git for your workspace. There is also a Power BI Developer mode that saves your project in a folder structure rather than one file, which is better. I’m not sure it’s great, especially if it doesn’t enforce text in a way that ensures a developer can easily see changes between settings and understand them. I can certainly diff the XML in two SSIS packages, but that doesn’t mean that it’s easy to understand what has changed.

    I think all modern tools used to build software, including the various reporting systems, need to be built with a pipeline and team development in mind, and set up to ensure that multiple developers can review code in some sort of Git-pull-request format. For those tools that use GUI formatting, I’d hope they separate out GUI elements from others, as no one needs to pull request a change that moves a visual box on screen left 2 pixels. However, if you change the OnError response or formula inside the box, that should be easy to see in code.

    This isn’t a simple concept to design for, especially for software that is based on a novel idea and is often built by a small team. However, periodic review of how the software stores changes and how a less experienced developer might review those changes is important to ensuring that our tools scale to the modern needs of distributed team development where our collaboration is often through protocols like pull requests.

    Steve Jones

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