Voice of the DBA

Category: Editorial

  • Republish: Always Canary

    Starting my second week away, so I’m republishing Always Canary today.

  • The Challenge of Failure and of Being Unwired

    Today is my last day at work for a couple weeks. Actually, I’m not done yet. I travel to Louisville today forthe SQL Saturday tomorrow and then I return home Sunday. I’ll be traveling away on Monday, so this is really my last day in the office. I hope. It’s possible I’ll realize over the weekend I’ve forgotten something and need to tackle it remotely, but I’m hoping that won’t be the case.

    While I won’t be completely unable to do anything, I am hoping that I’ll remain unwired for the two weeks. We are traveling to remote locations for some of the time, and there might not be cell service, and certainly not wi-fi. There will be some access on some days, as my son is taking an online class this summer and he has work to do, but I’m going to try and stay off email and Twitter, using my phone to just read and take/post pictures.

    Getting away from work is a challenge for many of us in technology. Earlier in my career, and for many years running this site, I struggled to take time off. I’d regularly check on the site, even writing editorials at times while on holiday. I can still remember using a public terminal at a hotel years ago to connect with work. In the last few years, I’ve gotten better, and taking time off for a 6 week sabbatical really helped. I even take all my vacation most years.

    That’s something that plenty of us still need to learn. I saw a post from someone recently that was on vacation and checking email. There were issues, though a backup person was supposed to handle them. I get the compulsion to check on anything for which you have responsibility. I get the habit of looking at email. I get the desire to just fix things. Those are feelings that I think many of us experience.

    What I’ve learned over time is that most of the work we do isn’t that critical. Certainly our employer’s systems can affect operations, profitability, and more, but they’re not our systems. They’re the responsibility of the organization to run, which includes ensuring there are backup resources, human and otherwise, that can manage systems. For those of us that are on top of our jobs, that are the go-to person, that don’t just maintain, but actively improve systems, we need to let others make decisions, even poor ones, and bear that same burden. Ultimately that’s how others learn and get better.

    I experience this as a parent, and I’m sure many of you do as well. We want our children to do better, to avoid the mistakes we’ve made in the past. We often try to actively manage how our kids live, or prevent them from making a poor decision. Across three kids and many years, I’ve learned to step back more and allow my kids to fail. It’s hard, one of the harder things in my life to not act or say something, but allow them to make a mistake. Even at work I’ve started to step back at times and hold my tongue if I’m not positive I need to say something. Instead, I try to listen more and accept that things will be less than perfect.

    That’s OK. We strive to become better, to improve our systems, to increase efficiency, but it’s possible to do too much. To overspend resources on tuning, or indeed, not make things better but worse. We can overcomplicate things to the point where others can’t understand them, or  perhaps worse, we encourage mistakes from the complexity we’ve introduced.

    Life requires some balance, as do our careers. Work hard, improve things where you can, meet your obligations and take responsibility for your mistakes. Accept that others will make mistakes, and that you are not irreplacible while you enjoy your time away. I’m hoping I will during the next two weeks.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.9MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • The Combinations of Software

    Security issues seem to be appearing more frequently, not less. I’d expect that we would be getting better at writing software, and I think many of us are. The problem is that more and more people are writing software and we still haven’t found a way to better train developers early in their careers. Perhaps the one good thing is that more and more developers are using frameworks, which create more consistent software. If issues are discovered, a patch can ensure a large swath of systems can be patched.

    The bad news is that far too many development groups build systems quickly, but don’t patch them in an expedient manner. They may be afraid or just not bother.

    A short while ago there was a loss of data from Ticketmaster ticket sales. Apparently a chatbot was used to steal information. As soon as Ticketmaster discovered the issue, they disabled the software. There is some disagreement as to who is at fault here. The chatbot vendor says their JavaScript chatbot should not have been running on a secure payment page.

    The specifics here aren’t important, but it is a concern that more and more often we are assembling applications from pieces of software. We often use plugins on websites and other building blocks when we put together a system. In more and more cases, we will be connecting this software to our data stores. That wasn’t the case here, but often there is some data access, and since we may keep both secure and non secure data in the same database, any vulnerabilities in one building block can cause security issues in others. The weakest link in the chain saying applies here.

    I wonder how many of you worry about issues with the assembly of whole pieces of software. The pieces should be more secure, or at least, more easily patched. There should be more incentive and resources to patch software used by many people, though many times vendors become hesitant to do any more than absolutely necessary.

    I’m not sure if it’s better to build out of pre-written pieces of code, but I do know that security is a shared responsibility and I wish it was more of a priority for all developers. The security of our application can depend on that weakest link.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.9MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Storage that Expires

    Whether you like the idea of the GDPR (and the new California law), I’m sure you agree that these laws will likely change our data handling in business. Even if they are weakened through legal challenges, many companies have already started to comply and change some of their practices.

    I’ve written about the GDPR plenty of times this year, and I like the law. I hope the law stands strong and resists most challenges. While I’m sure there will be plenty of spurious or silly requests and complaints, I do think these laws are asking for the good data handling practices that most data professionals have advocated for years. These include not only security but also integrity. How often have many of us advocated for corrections to problematic data and been told no? How many times have we complained about security practices?

    One area that I think has been neglected too long in most industries is the area of retention. Most companies I’ve worked for have retained data indefinitely, without any thought or policy. In my mind, we ought to explicitly think about how long we hold data, and remove older data that isn’t needed for our organization’s operation. I feel more strongly about this over time as we find that data beaches become more and more prevalent.

    Azure has started a preview of immutable storage, essentially WORM (Write Once, Read Many) drives as an Azure container. I’ve used WORM storage, but it’s often been viewed as a way of keeping information forever. that can change with this new Azure storage, as you can set a lifecycle management period. The blobs will be removed after this time, which removes one management headache from administrators.

    I could see quite a few uses for this type of storage. If it’s inexpensive enough, what about storing backups here? We could have policies set to remove files after some limited period. I’m sure there are plenty of other uses for storage the is immutable, but also contains lifecycle management options. What creative use would you have for this type of expiring WORM storage?

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.5MB) podcast or subscribe to the feed at iTunes and Libsyn.