Voice of the DBA

Category: Editorial

  • Learn More than Technology

    I’ve been lucky and successful in life in many ways. Certainly I’ve worked hard, may long days and nights, but plenty of others have as well. In fact, there are plenty of people I know that have worked more hours, but been less successful. Conversely, I know some that have worked much less and been more successful. It’s hard to know what the best way is for each of us to examine how to move forward in life, but it’s also not really helpful to compare yourself with others as a measurement. What I’d note you should do is decide if you think you’re becoming more or less successful and find your own path.

    This could mean very different things to different people, and that’s fine. I don’t want to live other people’s lives. I want to live my own, learning from positive and negative things that happen to others, but following the path that best suits my wife and me. I include my wife because we’re a partnership. We decided to spend our lives together, and that means we work with each other, sharing success and sacrifice, making joint decisions. It’s worked out well for us, and I am looking forward to the next few decades of continuing on that path.

    I got inspired to write this by Troy Hunt’s 10 Personal Finance Lessons for Technology Professionals, which is better written than what I’d do if i wrote it. My wife and I haven’t been as focused as Troy has, but we’ve gone through a similar set of thoughts and execution in our careers. We were less money focused, and we don’t live on the Gold Coast, but we’re pretty happy with where we are. We’ve made a few real estate investments, along with some traditional ones, and I think we’ve been fairly successful.

    What inspired me, however, isn’t the advice about how to make money as much as the need to understand what money means to you and the implications of your choices. I do think money is necessary, at least some to live in the US. I also think money can make life better, but you have to learn to enjoy life first. Money should help you with things you enjoy, not make you buy things you think you (or others) will enjoy. However, to ensure you can make the choices you want to, learning a bit about money is useful.

    Most of us don’t get good financial literacy, and more importantly, we don’t think about what money really means. It’s a representation of time, and your time is the most valuable asset you have. I don’t advocate that everyone try to be rich, or retire at 40, or save every penny/pence/shilling/lira/yen and live like a pauper.

    Enjoy your life as you live it and learn to appreciate the small things that touch your days. Along the way, learn a bit about money so you can make choices. Develop a hobby outside of work, and enjoy the moments with friends and family. Life is short. Try to actively live to enjoy it.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Forgiveness

    We are frail, fragile creatures. I think this is one of the main reasons I push for and try to work in an agile, DevOps style of development. I know that I make mistakes, as do others. My goal is often to ensure our system, our process, our way of working can transcend those mistakes and we can still be effective. We can use automation and regular examination of what works and what doesn’t to ensure our system works well and isn’t overly dependent on one person.

    Part of dealing with mistakes and failures is learning from them. Not only do we need to learn ourselves, and avoid repeating mistakes, but we also need to learn to forgive others. I thought about this as I was reading Derik Hammer’s post on Active Forgiveness. In his post, he covers the situations where we acknowledge mistakes without a punishment. Instead, we forgive the act and go to work on finding ways to prevent the same situation from happening in the future.

    I think this is one of those concepts and practices that are very difficult for most leaders, and maybe more followers. We don’t want to excuse the behavior, and we certainly don’t want to tolerate this in the future. What we want is for this person, and others, to learn from the mistake and work to prevent it in the future. What often happens is that we blame the person, we’re glad we’re not the person, and we may not learn a lesson because we think that we wouldn’t make the same mistake.

    Throughout my career I’ve seen the same mistakes occur over and over. Sometimes the same person makes a mistake again, but often different people make the same mistake because there wasn’t a product retrospective where everyone learned for the future. Having a blameless meeting where discussions take place, mistakes aren’t minimized, and everyone learns is hard, but it is important if we are going to improve our teams performance over time.

    I’d encourage you to try to find ways to learn from failures and grow. Forgive others actively, but don’t minimize the mistake. Hopefully you can also help your management learn to do this.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Complex Constrained Security

    I was reading about Kerberos and authentication with SPNs recently. It’s a topic that seems to make sense and appears orderly, but when I’ve had issues with SPNs, it feels like voodoo and black magic sometimes might be needed to get things working. As I read through the document, trying to ensure I would learn a bit more about how impersonation and delegation work, I noticed this sentence:

    “As a security best practice, Microsoft recommends constrained delegation over unconstrained delegation.”

    That seems reasonable to me. We ought to limit where users can connect to specific systems to ensure good security. This makes perfect sense where we have systems like web servers or application servers and we should limit delegation to specific databases servers. This wouldn’t prevent all security breaches, but it would limit the scope of many.

    The complexity comes when we start to have multiple servers that might connect to multiple back ends, especially as we grow our architectures to include additional HA nodes with Availabilty Groups. Tightly linking security complicates the configuration and requires that our sysadmins setup new machines and properly add new delegation targets as machines change. DevOps and configuration as code can help here with ensuring that we always add the required security changes to the right machines.

    That still doesn’t make it easy to manage a tight security environment without lots of resources. As we rotate or retire machines, we need cleanup of the security settings that refer to these objects. If we rotate host machines, which is usually rare, we need to remember to update out configuration scripts to work with new machines and accounts. If we add nodes, we need additional lines in scripts. If we move to containers for database servers, this might require even more changes.

    None of these items is complex, but when you must repeat them for many systems, many accounts, and on a semi-rare basis, they add some overhead that is both tedious and difficult to keep up with for a staff. This is especially true as staff turns over. Do you want to let the new people know that they need to make all these updates while handling their “normal work”? I could see all these details becoming a chore because we’re human, we’re flawed, and we make mistakes.

    I like the idea of tighter security, but at a scale, at random times, in between all the other tasks we must complete, the tools and techniques we have don’t make this something that seems manageable. I don’t have solutions, but I think that we do need some better tools that ensure security can be both flexible and convenient, while enforcing the principle of least privilege. The management of systems at scale is helping (forcing?) companies rethink some security tools and features, but there is still work to be done to ensure our employees will correctly and consistently configure security.

    Steve Jones

    The Voice of the DBA Podcast

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

  • DR Planning

    Data professionals know that protecting and ensuring our data is safe is one of our primary jobs. Many of us worry that if we were unable to recover a database, our job might be jeopardy, which makes sense. If we lose data, an organization might make the decision that we aren’t trustworthy enough to manage a database system. This leads many of us to plan and prepare for different types of disasters, with procedures and systems in place to ensure that we can quickly get things running after an issue.

    Natural disasters, or other large scale disruptions of business sometimes exceed the plans we’ve put into place. Fortunately they’re rare, but I ran across an article that talks about a few items that we might not consider when making plans. Even if you can fail your database over with an Availability Group running in another location, there are still some points you might want to think about.

    Perhaps the biggest one for me is that testing is not optional. I’ve seen some amazing plans put into place, but never tested because no one wanted to disrupt ongoing business activities. Testing is really critical, perhaps because of the second more important item I see cause issues: failback. This isn’t always as simple as we’d like, even with some of the amazing work that Microsoft has done with SQL Server. We want to ensure that we do know that if something happens to our primary systems and we move them, we can come back. After all, these are the primary systems for a reason.

    While other items such as making DR planning something your organization cares about can matter, I think the viability of this depends on how likely these disasters are. If you’re in a seasonal hurricane path, or some other disaster, you likely need to have better plans than if you’re in a stable region. Not that you can avoid any plans, but most of the time a disaster is a rare event and it’s really IT’s job to ensure that systems are resilient.

    I do think it is worth noting that regulatory compliance isn’t optional. While your auditor might have sympathy if they are likewise affected by the disaster, that sympathy dissipates over time. A disaster next month might not factor into an audit review in 20 months. More laws are on the books and more are coming than most of us have dealt with in the past. Design your system and process to be compliant, even in a disaster.

    Lastly, the people side of business can’t be emphasized enough. While some of us might be expected to shoulder a greater workload during a disaster, keep in mind that we would still need support outside of work, perhaps even a replacement worker to handle some of our work tasks or even help with personal items. The longer our lives are disrupted, the less likely we are to work as hard, or remain focused. Part of any plan should be how can our organization help support those that are struggling themselves. After all, the effects of a localized disaster on business could get compounded if staff stops coming to work.

    Steve Jones

    The Voice of the DBA Podcast

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