Voice of the DBA

Category: Editorial

  • Ransomware and DevOps

    Ransomware.

    A scary topic and one attack that is apparently more common than I suspected. Before you go further, if you haven’t restored a database backup in the last month, stop and go verify your DR plan works. That’s one of the overconfident issues facing lots of government and businesses. While this might not help your entire organization, at least you’ll have some confidence in your process and that you can recover a database.

    This is a great article from Ars Technica and worth reading: A take of two cities: Why ransomware will just get worse. I’d recommend you read it and think about a few things. First, do you have insurance because things (or substitute your own word here) happen? Second, have you really tested a DR plan for some sort of software issue like this? You might think about a way to restore systems in an air-gapped manner that prevents them from re-triggering encryption from a remote source, or maybe even in a scenario where you reset dates/times to prevent timer triggered issues. If you don’t think you need to, read this article as well.

    Perhaps the bigger issue is are you actually patching and updating systems? Too many organizations can’t, don’t, or won’t. The former means you aren’t sourcing software properly. Either you’re using vendors with poor practices or have a poor development process. Organizations that don’t or won’t bother prioritizing patching, especially security issues, are likely those that will have issues as more criminals spread and use ransomware and other attacks for profit. Software and environments continue to be more complex, which means that the less you ensure the system is patched, the more likelihood there is of a vulnerability in your environment.

    DevOps and the cloud PaaS/SaaS platforms are attractive for a few reasons. One is that the platforms are constantly kept up to date, forcing you to move along with them. SaaS cloud vendors know this and are constantly patching and updating their software in order to keep it running. DevOps asks that we always have the ability to release, that we have the ability to patch on demand, not only at certain intervals. This is something I try to emphasize when talking about DevOps. It isn’t necessarily about velocity, but it is about being able to release when you need to, whether that’s today or next month. This is especially important for security issues.

    I have had hope for a long time that insurance would drive software to higher quality, and I still do. With the attacks and issues of ransomware, and who knows what other techniques that will be developed, I still believe more companies will buy insurance. I then hope, because of selfish motives, the insurance companies will require frequent patching, regular vendor certification of new platform versions, and better development processes. If insurance drives DevOps, I’m all for it, but I’d prefer you decide to adopt it yourself and start making changes today.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Republish: Dig Out the Root Cause

    Off to SQL Saturday Austin today, so you get Dig Out the Root Cause from the archives.

    Have a margarita and fajitas tonight in celebration of the great food I hope to enjoy in Austin.

  • Learning to Stop Being a Hero

    A few weeks ago I re-published a piece on whether we might be giving too much of ourselves for our employers. At the time I was on holiday with my family and since this was a popular piece years ago, I decided to run it again. I was surprised at the response, with quite a few individuals writing about their experiences in their current positions.

    A good friend of mine read the editorial and then sent me a link to a post by Paul Cunningham that looks at the IT hero. This talks about some of the ways in which we put ourselves out as employees. It’s a good read, and it’s certainly something to think about when you look for a new job. When I talk about finding a dream job, I’m not talking about a specific job or career path, but rather, what’s the right fit for you. That might not be the job I want, or even that your friends want. It’s the job that you’d want.

    To find your job, you really need to think about more than the work, the company, the location, or benefits. Instead, think about everything and start to rate those items against each other. A friend always tries to scale everything to some monetary value to make it easy to compare jobs. You can put a value on a 5 minute commute v a 45 min commute by thinking of the cost of time. Same for other benefits. Perhaps you can even do this in terms of future opportunities. You certainly can do this in terms of expected work week, on call time, and more.

    What you don’t want to do is let an employer take advantage of you by asking for a lot more of your time than you feel comfortable giving for the salary. Most of us are happy to pitch in when extra work is needed. I’ve seen this in restaurants, lawn care, and IT. What we don’t want to do is get taken advantage of when extra work is required on a regular basis. You don’t need to be a hero to be successful.

    Perhaps the final caveat in all of this is that you can’t control how all employers treat or view employees. Sometimes you might take a job that isn’t a good fit because you need a job, or maybe because you’re trading a poor situation for some experience. Just be sure you know you’re making that trade.

    The other thing I’d note is that finding a dream job, or maybe just a job that fits your life well, means you need to be able to compete with the others wanting that job. Work on improving your technical and soft skills to ensure that when the time comes, you are in the best position to get that job.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Waking Up to No Support

    When you wake up on July 10, SQL Server 2008 and 2008 R2 will be out of support. Microsoft has been talking about this for some time, there’s been a Migration Tour from PASS with live events in quite a few cities, webinars, and more to let you know that you might want to upgrade to a supported version.

    While I typically think that systems that run are fine and don’t necessarily need support, there are compliance and security concerns here. If you work in a regulated industry, you might need support to stay compliant. If that’s the case, you might want to ensure you have plans to move to SQL Server 2017 (or 2019) soon.

    The same goes in this era of attacks and potential security issues. While SQL Server has relatively few patches for security, you never know. I haven’t worried about this in the past, often with internal servers, but I do get more concerned over time as we seem to constantly find more complex bugs in hardware and software.

    SQL Server 2008 support is over, but you have options. Microsoft will continue to support you if you move your servers to Azure. That’s not a bad option if you need to move quickly, but don’t forget to really think through what this means for your applications. Moving to Azure isn’t necessarily as smooth or simple as you might think. Authentication and authorization need some attention to detail to get working well. It’s not hard, but it is work.

    When SQL Server 2005 went out of support, it didn’t seem there was as much emphasis on migrating. Certainly lots of people ran SQL Server 2000 instances for many years without support. You can do it, but the world feels more dangerous, and there are more implications with regard to regulation, security, insurance, and other complex topics that can impact your business.

    Think carefully about the implications of migrating and not migrating. You’ll have to make the decision, and it can be hard, but it’s something you should spend quality time thinking carefully about.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.