Voice of the DBA

Category: Editorial

  • Is Data the Future of the Vibrant Web?

    Data privacy is a fascinating subject. Since the GDPR was passed, I’ve had a lot of conversations with people about the GDPR and the way different people feel varies dramatically. Moreover, the way an individual feels often varies depending on the situation. I know plenty of people that want their own data completely private, but they also want no restrictions on what they do with data inside their organization. Others feel the exact opposite.

    One type of data that many people don’t think about is the cookie data that is used by Google and Facebook (among others) to track a user across many browsing sessions. This tracking is one reason that I see Redgate ads on a movie site or a new site. If I happened to search for SQL Compare, which I do sometimes to get a link, I might later see related ads on a site that has nothing to do with technology or SQL Server.

    Apple, Firefox, and Microsoft have been experimenting with ways to give you some tracking protection in your browser. This should allow less data about individuals being captured, stored, analyzed, and then it couldn’t get lost/stolen/hacked.

    Google has a different approach, and one that I think benefits them and their paying customers more than the rest of us. The idea is to have some sort of data cap for types of information, above which the browser would return generic information. Potentially it could return inaccurate information, but I can’t see that passing any sort of business relationship test with Google customers.

    The goals here are relevant ads, and of course, information about you in order to serve relevant ads. While I think this goal will be met, I’m not sure it’s much more private than the situation today.

    Data privacy means allowing users to decide what data a company, including a tracking company, is willing to share. The way browsers have changed in the last few decades is complex and confusing. I have no idea what information they track from my system(s), and I’m not sure I would even understand the implications of enabling certain rights. While most of us wouldn’t want to share our email, there are lots of other data that we might not be sure of the way it might be used.

    Like most of the data privacy issues, I have no idea what to do here. The issues are complex and confusing. I would hope that Google would remember its “do no evil” origins and help us increase our ability to keep data private.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Working in Smaller Teams

    I don’t know what the average size of a team is, but I know I’ve worked in all sizes in my career. I’ve had teams of 1-3, which is common in database work, but I’ve also been on a 20 person Ops team. I’ve been in 2 person development teams, 25 person teams, and everything in between. At Redgate, it seems most of our development teams are less than 10 people, but I’m sure we’ve exceeded that at times.

    I do think smaller teams are better, and they are certainly easier to keep track of what everyone else is doing. Once a team becomes large, even with regular status reports or meetings, there is too much information to easily hold in one’s memory about tasks other than our own. Knowing what others are working on can be invaluable in coordinating and avoiding conflicts. This also ensures that the team can more easily ensure code is written in a similar fashion and knowledge is easily shared.

    There is research that seems to indicate that smaller teams are better. This article talks about some of the reasons small teams seem to perform better. These all seem to intuitively make sense to me, and I’ve certainly experienced people behaving in these manners. In the second piece, there is advice on how to get teams to be more effective. The biggest advice seems to be a lot of what we do at Redgate. We empower teams, give them tools, and don’t manage them in traditional ways. We hold them accountable to get work done and meet goals, and we challenge them, but we want them to move forward, not work in a particular way.

    Building a team is hard, and getting a team to perform at a high level is very hard. I do think that the internal talent and motivations of individuals can make a big difference, but I also think that management can bring out the best in people, or it can ensure you never get anywhere near the potential of team and encourage under-performance.

    It constantly surprises me how often I find managers and their organizational culture built to control and not inspire employees to do their best. I think it’s a holdover of years of working a certain way, rather than supporting and encouraging each person supervising others to get the best from others. I hope this changes, but it’s certainly something I try to detect in interviews before I ever commit to a new position. I hate working for micromanagers and never want to do it again.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • A Good Reason to use a VCS

    Imagine that you have some important year end procedures in your SQL Server database. Or maybe you have some important, but rarely run code. No matter what the circumstance, if this is a large amount of code, it might be difficult to remember how it’s structured or even how it works on different sets of data.

    Now, imagine that you have a malicious individual that thinks like Andy Mallon talks about in this post. They run an ALTER PROCEDURE and replace the entire procedure body with “RETURN 0”. Now imagine that you don’t find out about this until months later when the important code is run. That would be a bad day, and certainly one that might have you struggling to recover the code from backups. Do you have months of old backups? I used to, in a place where we kept an end of month backup from every month for a year. I always had the previous 12 months, but I wouldn’t want to restore them all to find out where code got changed.

    In most places, we don’t have that many backups, and we often assume we’d only go back a few full backups at most in the event of a disaster. I’ve also been a consultant for more than a few companies that found out that they had 2-10 full backups, all of which were corrupt and from the last few weeks. Sometimes there were older backups on dev/test machines, but in some cases, lots of data was lost.

    It’s important to run DBCC to catch corruption, but it’s also important to keep track of your code. There might not be maliciousness, but simple errors in code that’s changed without comprehensive testing. This can be especially problematic for rarely run code that we don’t test as thoroughly and won’t detect issues for a significant amount of time.

    Save your code in a VCS. Git is free. File|Save is in every editor on the planet. There’s no excuse not to use a VCS and save code. Redgate has tools to make this easy, but I worked in a file|save environment for years, and it worked. Learn about a VCS and build the habit to backup your code in a repository. It’s simple and easy, and you won’t know you need it until you do. At that point, it’s too late.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Beware, More Ransomware is Coming

    Criminals seem to take advantage of anything that will allow them to gain more money, power, or notoriety. It seems in the last year that ransomware has become more prevalent and widespread in all sorts of organizations, though a number of governments have had high profile attacks. They’ve often paid the ransom, with the help of insurers.

    While that might seem like the most expedient way to get back to working, it can be a problem, as this article points out. It can often be more expensive, in time and currency, to combat an attack than to pay a deductable and have the insurer cover the rest. When insurers start to pay for the attacks, then it provides an incentive for more attacks, especially similar attacks at governments or other corporate divisions where the security (or lack thereof) might be similar.

    This also can influence more organizations to purchase insurance, which might be part of the reason insurance companies are happy to pay out the policy. I expect that insurers can’t pay all policies, so I would hope they would start to require more proactive security measures and policies to prevent attacks against some companies. In fact, I hold out hope that insurance, not government, will drive more companies and organizations to implement better security practices.

    The downside is that sometimes paying the ransom doesn’t get the keys to decrypt files. In fact, I suspect that it’s as likely that the criminals don’t have the key as they just make a mistake in their “customer service” effort to provide the key. All sorts of organizations have trouble providing the right keys at times to customers, so I’d expect this happens to criminals as well. I also wouldn’t be surprised if some criminals aim to exact a second ransom, perhaps devised to be just below the insurance policy limit, before providing a key.

    The takeaway for most data professionals here is that we want to be very careful with our data, especially our backups. While others might lose their data to encryption, it behooves us to severely limit access to backup files to prevent a rogue account accessing them, and certainly we would want to to air gap backups wherever possible. If we find out that systems are encrypted, at least we can recover our data on new hardware. If our application code is likewise held in another system, like GitHub or BitBucket, then we might even get back to work quicker, at least for our data-driven applications.

    Security continues to be an increasing part of the data professionals job. As a way to ensure your career continues to advance and grow, pay attention to how well you secure your organization’s data.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.