Voice of the DBA

Category: Editorial

  • Data Decisions or Instinct?

    Most of us that are data professionals think the best way to make decisions is to use data to justify some course of action. We look for patterns in data, some guidance that the information we have will lead us to make the best choice for our organization. Google has talked about making data driven decisions as a part of their success and they think more organizations should do this. Any number of other companies also use data to power their BI systems and dashboards that help their employees make better choices.

    That seems in contrast to this piece from the Harvard Business Review that says that great decisions don’t start with data. It talks about using stories and emotions, with a few key facts sprinkled in, to help sell ideas and get decisions made. On one hand I agree that stories help to sell decisions, but I often have found that successful salespeople use this technique to deceive and convince by plucking emotional heartstrings, and using relatively little data.

    In my mind, the best way to make decisions is to go with your instincts, but while examining and understanding the data. You can’t discard data, especially when it presents strong patterns. However data can be deceiving when we don’t carefully examine the ways in which it’s put together. An average doesn’t always reflect the actual value of a set of numbers, especially when we don’t also understand the range, standard deviation, and count of values.

    We also have to realize where we do and don’t have experience and expertise in some subject. We should certainly look to data to guide us and perhaps even justify our decisions, but we can’t forget that the human brain is still an important part of any computational exercise. We need employees that you use their judgement, in collaboration with data, to make the best decision for our organizations.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • DevOps

    The DevOps movement is supposed to promote a closer collaboration between developers, testers, operational people, and really anyone else that must help software gets build and deployed. The developers need to coordinate their needs and requirements with operational staff. They should work early on with any staff performing testing to help them ensure that bugs are caught quickly and fewer slip through to production. At the same time, operational staff should be responsive  and helpful in all the environments software moves through. Operational staff should help build and automate the configuration of development and testing environments, ensuring that systems are built in a repeatable fashion as well as the same way in each stage of the software development pipline.

    However, is devops killing the developer? If developers are becoming responsible for testing, that’s bad. If developers must learn to function as a DBA as well, then I certainly expect they’ll write less code. If developers need to ensure the software can be installed on production systems and train operations staff, then I suspect they aren’t very happy with their jobs.

    But that’s not DevOps. If that’s how your organization runs its development, it doesn’t understand DevOps. Developers should be leaning on and learning from, as well as teaching other staff. When I read that post, I think the developer has missed the idea of DevOps. It isn’t that developers need to become completely versed and responsible for the full stack. It’s that they should be working with everyone involved in the process the entire time that software is being developed, using the specialized knowledge each person has.

    DevOps isn’t something new. I’ve worked in teams that worked like this in the past, but we never had a name for what we did. We just thought we were part of the same team. I’ve also worked in organizations with walls between all groups. That wasn’t a team, and we had lots of four letter words for that style of process.

    DevOps is a good term and a good idea for software development. If a company implements it well, then it works and people are happier with the way software is produced. If they aren’t, then the process hasn’t been configured correctly.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Administering Securely

    This piece was originally published on Jul 8, 2009. It is being re-run as Steve is away on sabbatical.

    The other day I noticed a post where someone was asking a question that I’ve seen asked often. I still haven’t seen a great solution, and I expect this question will continue to be asked for some time to come. The poster asked how to securely set up a database to prevent administrators from accessing the data.

    Prior to SQL Server 2005 this was pretty much impossible. The sysadmin group was considered to be like a god inside the SQL Server and could access most anything. With 2005 there are more restrictions you can place on the administrator, and with the addition of encryption capabilities, you can prevent casual access to certain data.

    However it’s not easy, and most of the time the system administrator still has access to data for tuning, troubleshooting, disaster recovery, etc. That makes sense sometimes, and I feel that you really have to trust your administrator with a lot of responsibility and discretion. Sometimes, however, it’s just not appropriate for the person that runs the server to see other data. Salary information, among other data, sometimes just isn’t the business of the administrator.

    I don’t know how you handle this. Does the administrator just get access to the database as a container, able to attach it, back it up, restore it, and perform basic functions? Are they limited to setting security for users, but unable to access the objects themselves? I’m not even sure that’s a valid way to handle things since the administrator can always set up a dummy account for themselves, or change someone’s password and access data.

    To me the best solution for secure administrator access is to have a second person audit all actions performed by a sysadmin. Kind of a default trace for sysadmins that is always running, and is not accessible to the administrator. Even then, it’s probably only something that works in larger companies where you have enough people to dedicate to the task of reviewing things. Maybe policy based management (PBM) will help here at some point, limiting the access to data by administrators in an easy to understand manner that a manager of some sort can understand and audit.

    There’s no good solution now other than to trust your administrators to responsibly manage data, and that means hiring responsible people for the job.

    Steve Jones

     

  • Lockdown or Let Them Free

    This piece was originally published on Sept 21, 2009. It is being re-run as Steve is away on sabbatical/

    I ran into this blog post about IT v other workers. The post is in response to an article in Slate about workers being oppressed by their IT departments. They’re both relatively long reads, but the summary is that a writer at Slate thinks that the technology departments are too restrictive and unnecessarily hindering workers. The blog rebuts that point with the notion that many technology workers don’t understand the complexity of their systems and there are valid reasons for not allowing workers to have free choice in what applications they install.

    Having been in a number of technology departments, from small to large, I can say that I see both sides.  On one hand technology departments spend a lot of time and money cleaning up mistakes and problems from users. On the other hand, new applications and enhancements can often increase the efficiency or effectiveness of workers that find a new way to do their jobs.

    The problem in both cases is a few extremes are being chosen to  represent both sides. Most users don’t  require lots of attention from IT for their machines. And most IT solutions punish everyone for the problems that a few people provide.

    I think that as DBAs we sometimes start to feel this way about developers. We classify them all as problems and give them no rights, or we think that every person must have all rights to all instances. This extreme set of solutions isn’t practical, or effective, for most organizations. As much as I might seem to hate developers and make fun of them in these editorials, I recognize that there are many talented programmers and quite a few that know more about SQL Server than I do.

    The best way to handle rights and access is to selectively apply permissions to individuals, matching up their skills with their rights. If a user has problems creating indexes or adding tables, remove those rights. If they are a model DBA, then perhaps they deserve sysadmin rights. You can either loosely apply security and then tighten it up or lightly apply it and loosen it as people prove themselves.

    Let me say that I still highly recommend the use of roles for the actual implementation of permissions, but don’t view security as a set it and forget it. You should re-evaluate it periodically, and that would include the permissions you give to your co-workers.

    Steve Jones