Voice of the DBA

Category: Editorial

  • Licensing Audit Advice

    I’ve never been through  a licensing audit at work, but I have been worried about them a few times in my career. A few bosses have warned me about them possibly coming. While I’ve tried to ensure that the organizations I worked for were compliant, I’ve always worried about losing track, making a mistake, or mis-interpreting the EULA rules. Those EULA rules and licensing guidelines are not written for most people to understand, and the verbiage is ambiguous at times.

    I saw an article containing advice on going through a licensing audit that caught my eye. This was for an Oracle audit, but I suspect the advice would be similar if this were for SQL Server or any other product. Since an audit is a legal proceeding, it’s worth treating any licensing audit as you would a legal matter.

    I am not a lawyer, and don’t take this to be advice or a recommendation. These are just my thoughts. For me, I would try to go slow with everything. Not to delay, but to be careful and sure of what I was doing. I would concentrate and read all documents carefully, being sure that I know what they mean, asking for clarification if there is any doubt, and ensuring my organization’s legal representative was available for questions.

    I’d especially be careful about only answering questions and not being overly talkative and volunteering information. I’ve seen plenty of people get into trouble because they talk more than necessary. That might be good advice for life in general: listen more; talk less.

    SQL Server, unlike many products, can be tricky because no license key is really checked. I’ve seen scripting and manual processes use the same product key for ever installation. There’s nothing fundamentally wrong with this, but it does mean that someone is still responsible for ensuring that licenses are being tracked against installations and upgrades.

    While I have no desire to deal with licensing, I know that if I act as a DBA in any way, it’s likely part of my job. I would (and have) tried to get someone in an Accounting role to keep track of purchases and usage of licensing, updating them whenever I install or decommission an instance. At least then we have more than one person tracking the data and potentially another person that might be in charge of handling the audit ;).

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Sabotage at Work

    I caught a link to the OSS’s Simple Sabotage Field Manual from David Perell. It was written as a guide to destroying organizations during WWII to be distributed to citizens of enemy states. The OSS later became the CIA, but their goal was to find ways to disrupt the governments of enemy states.

    What was surprising to me was that some of the advice seemed to still be in use in places I worked in my career. Such as the advice for managers: ” To lower morale and production, be pleasant to inefficient workers; give them undeserved promotions. Discriminate against efficient workers; complain unjustly about their work.”

    This might seem to be human behavior, and it is, but it also destroys organizations. Too many people in authority don’t seem to do a good job of evaluating those that perform well and drive our software forward. While I do think this is subjective, often the group view from workers and the managerial view of who is efficient can be quite different. Being transparent and open with expectations and evaluations can help here.

    Working in committees and large groups is all too common, at least in US organizations. We hold meetings and have discussions with large groups instead of making decisions. I do agree with getting opinions from a large group, but discussions should be relatively short and then decisions made. We don’t want a dictatorship nor a large democracy of debate, but something in between.

    Maybe one of the more interesting ideas is the work slowly. I don’t know of many workers that want to work slow. Some do, and sometimes we all struggle to get things done, but so often management doesn’t want to invest in tools for workers. Tools can make a job much easier, and much more efficient. Part of DevOps is learning to use tools and become better. Or fabricate your own tools, something we can do in software easily. Too many managers don’t want to budget time or money or build or buy tools.

    It’s easy to self sabotage ourselves, and too often, it’s easy for managers to destroy an organization from within. This might be an interesting manual to review in a meeting and debate if our rules, protocols, and decisions are helping or hurting our organization. Unfortunately, too many managers aren’t willing to perform that self-evaluation.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Challenges of Working Under Quarantine

    It’s been nearly two months since the Redgate Software offices closed. I am not normally in the office, but I did cancel a trip that I normally would have taken to touch base with a number of teams. That’s a minor change for me, but a still a change. It’s much less than the change for most other people, and by now, I expect many people have somewhat adapted to working at home.

    Working at home under this pandemic isn’t the same as working remotely. This has been forced upon us, and I agree with Scott Hanselman. Like me, he’s worked remotely for years, and this is different. We have kids, partners, roommates, and others around. We can’t easily change our scenery or engage in some of our usual activities. This is stressful, overwhelming, upsetting, disconcerting, and more.

    Some of you might have accepted this and are learning to work in a new way. Some are coping, but expecting to go back to normal at some point. Some of us are getting much less work done, which adds another level of stress. Performance reviews, and the inevitable comparison with others will weigh on our minds. Whether we go back to normal soon or not, companies will add and remove staff. There are new projects to tackle, raises to award, and all the regular work of running a company.

    This is a difficult time for all, and most of us are experiencing life in our own unique ways. Our view of the world, of coping and getting our daily work done is much different than our co-workers. Even if we appear to be the same people, we aren’t. We may react differently day to day, and there may not be a good explanation.

    This is not the same as remote work, and I hope managers understand that. It is important that we all appreciate that our view of any big or little thing at work is not necessarily the same way others view the same action. A daily standup meeting might seem like a little thing to you, but perhaps it’s exam day for someone else’s child and they can’t focus, or maybe not even attend.

    Be kind, be more flexible, and be more understanding. You never know what someone else might be dealing with in their life today.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Jumping Air Gaps

     

    There are all sorts of viruses, worms, and malware out in the world, and some of us have had to deal with them at different points in our career. SQL Slammer was particularly memorable for me, but there were plenty of non data related virus issues I’ve had to work on at various employers.

    To keep sensitive information safe, many high security environments have built air-gapped computers, where these systems aren’t connected to a network, or at least not a general network in an organisation, and certainly can’t access the Internet. At home, you could think of this as an older computer with no network card, or even a spare laptop with a broken network radio. To get information to/from this computer, you’d use some sort of removable media.

    Apparently there are concerns about malware being able to jump this air gap, using the removable media. Nothing terribly new here, as infected USB sticks have been a concern for years, but this appears to be a twist and apparently the malware waits for a chance to send information off to a receiver.

    If your system is truly air gapped, then there might not be a way for this information to be ever be copied, but what if that isn’t the goal. Imagine ransomware uses this technique and infects database backups. If you have an offline place for backups, could a copy of a new backup infect other backups? With separate tapes this isn’t an issue, but if you use some sort of part-time connection to move data, this could be an issue.

    I’m always wary of online backups or even live copies of data. I know many large systems find tape unusable and impractical, but I know that having physical copies of tapes ensured some level of security for my backups.

    The creativity of malicious actors and the threat vectors they devise are scary and incredibly hard to guard against. I don’t know what the best solution is for data and database backups, but I certainly hope that someone smarter than me is working on the problem.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.