Voice of the DBA

Category: Editorial

  • The Quiet Zone

    I’ve been in a data center when most servers turned off. I’ve actually heard dozens of systems powered off quickly, and it’s a strange sound. You become so used to the white noise of numerous fans that having them turned off is a little unnerving. It’s neat when it’s a scheduled patch day and all servers cleanly shut down together. It’s an altogether different experience when there’s an unexpected issue and management sees their expensive hardware not working.

    However, imagine losing your servers because of a loud noise. That’s what happened to ING Bank when a fire extinguishing test caused a number of hard drives to fail. To be fair, the loud noise was north of 130db, which is very loud. Since sound is really vibration, the impact to read/write heads caused numerous failures. The bank needed 10 hours to restart systems in their DR center, and managed to do so. While that might not have been what the bank officials wanted, this is a good DR test, and I hope they learned a few things that might help to fail over much quicker in the future.

    This might be a good reason to think about SSDs, which are less susceptible to vibration than the older, spinning rust drives. I’d guess that there are other issues that could affect SSDs and someone is going to discover them at an inopportune time. Already we’ve seen dramatic improvement in SSD technology, driven by numerous early issues relate to writes and reliability.

    Engineering facilities is hard, and there can be many unexpected issues. I’m sure the people that designed the fire suppression system weren’t concerned about the noise; they were concerned about shutting down flames quickly. I’m sure that the people filling the system didn’t think a little extra pressure would matter. These seemingly innocuous decisions can cascade, which is why we practice and preach DR preparation. Not just backups, but restores and quick fail over.

    If it’s not your organization, it might be humorous rather than stressful, but you never know what design flaws might lurk inside your facilities. I once worked in a data center that had only about half the cooling that we expected. Why? The engineers assumed that since we worked an 8 hour day, so did the computers, which we’d turn off at night. Luckily they had built a pad into their calculations so we were only short half the capacity rather than two thirds.

    Steve Jones

    The Voice of the DBA Podcast

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

  • What is the Future of Monitoring?

    I read Tom LaRock’s post on the future of monitoring, looking at the rise of machine learning and complex algorithms to evaluate systems. Tom notes that the data input into a system is crucial in determining whether the system can produce a prediction or output that has value. Since the humans that decide what data is included may not choose wisely, the system won’t necessarily reduce the time required to manage a system.

    I tend to agree. From my conversations with those people having success with machine learning systems, the data preparation is the most critical (and difficult) step. Shortcut the cleansing and organizing, or make poor choices of what data to include and you won’t likely get actionable results.

    However, I have a different view of monitoring. After my watching of the Darpa Grand Challenge (editorial on this recently), I think the future of monitoring is perhaps actually making changes to code in-line. Perhaps with approval from humans, but I suspect that we can train some process to understand how particular batches can cause issues. We can certainly set filters that might note index changes on large tables could be problematic and should be investigated before an issue arises. We can teach a system to recognize code deployments, perhaps even roll back certain changes if the application fails. We certainly could have a machine learning system watching index usage and query plans to recommend indexes in a real time manner, perhaps even turning on and off on-line rebuilds.

    I think there is possibility, but where I’d really like to see advanced monitoring is not in production environments. I’d like to see better systems that can watch development, helping suggest or rewrite SQL before it’s deployed. Perhaps applications can warning developers of potential performance or security issues. Such systems could help us in building more consistency into our applications. We can have systems that help our developers code better.

    As our databases and software become more critical to the functioning of most of our businesses, we certainly need more reliable and robust development practices.

    Steve Jones

    The Voice of the DBA Podcast

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

  • DevOps at Microsoft

    I’ve been watching Microsoft for quite a few years, with my career being tightly intertwined with the company for 25 years.  I’m amazed by the way the company has changed in the last five years. It’s probably been longer than that, but from the outside, the last 5 years have been surprising. Certainly the way Microsoft produces software is a process worth studying by almost any organization with developers. There are some scale advantages Microsoft has, and their mission is to reach and touch people at a level far beyond what many of us deal with, but there are lessons to be learned.

    There’s a great piece that shows some of the ways in which Microsoft is practicing DevOps in their own software development. I like that the focus isn’t just that developers do more, but that operations staff are involved in working closely with the development teams. In fact, there’s a quote I like that notes in addition to technology changes and habits, ” we found that the organizational changes and cultural shifts required to embrace these practices have been just as significant.”

    As I talk about smoothing the database development pipeline and creating efficiency in the process, I want people to be aware that cultural change is required. My employer, Redgate Software, can sell you tools that solve the technology challenges, but if you don’t change the way you build software in your culture, with your staff, the tools don’t help. At best they make a few tasks easier for developers, but you will still have issues releasing your software consistently on your schedule, whatever that may be.

    There is also the emphasis on developers deciding when to release. In Microsoft’s domain, this probably works, but not likely for many line of business applications in organizations. However, the focus should be getting changes to customers quickly after development. The sooner they see features, the sooner they can provide feedback on whether the software works as expected or changes are needed. This quick feedback also means that developers have the architecture and flow of the code in their recent memory. Always a recipe for smoother continued development and quicker bug fixes.

    Testing isn’t emphasized much, though I think as developers become more accountable, and they can get changes to customers quicker, they’ll start to want automated testing that allows them to check for regressions, as well as ensure requirements are being met. Microsoft has the advantage that many of their internal teams can actually use the end product, something that isn’t always easy for those of us in other industries.

    DevOps works. The principles are sound, and it doesn’t matter if you’ve followed the principles for decades (maybe under another name) or just started a new process by asking for more coordination and collaboration from your teams. Learn to build a coherent system with your developers and operations staff, throughout your software development process, and your whole organization will benefit.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Black Boxes

    Machine learning and artificial intelligence seem to be the hot topics these days. From bots that can interact with people to systems that learn and grow as they process more data, it seems that science fiction is becoming reality. At least, in limited ways. Autonomous cars, perhaps the highest profile example of these topics, are advancing and being tested in a few locations around the world, but I think we are a long way from having human controlled and autonomous cars interacting freely at any scale. There are still plenty of issues to work out, and the consequences from mistakes require serious consideration.

    I was thinking of this as I read an interesting question: Whose black box do you trust? It’s a look at algorithms and machine learning, and the impact they have on the world around us, despite many of us not understanding how they work. The main examples in the piece are in the area of journalism as it relates to social media (primarily Google and Facebook), but also touches on autonomous vehicles, both autos and planes. The latter was a bit of a shock to me as I assumed humans always handled takeoff and landing, something the author says doesn’t happen at SFO. Some searches around pilot sites seem to note that automated landing is done regularly to test systems, but is used in a minority of cases.

    The question is, do we trust the black boxes that run our systems, and really, does it matter? In the piece, Tim O’Reilly says he has four tests for trusting an algorithm:

    • the outcome is clear
    • success is measurable
    • the goals of the creators align with the goals of the consumer
    • does the algorithm lead creators and users to better long term decisions.

    Those are interesting ways to evaluate a system, though I think the problem is that the last two are a bit nebulous. One of the things that I see more and more as I get older is that the same data or the same facts can lead two different people (or groups) to two different results. Our goals, our interpretation of events, even the weights we place on the various factors in a complex system vary dramatically from person to person. In such a world, can we truly evaluate what the goals of a creator are? Forget about consumers, assume one person building a software system. They will have multiple goals, and do we really think their goals can be easily listed? Or weighted/ranked appropriately? What about when the goals change?

    I really think that the black boxes need more disclosure, though I freely admit there isn’t a good way I know of to do this. However, I do know one thing that can be better disclosed: data. We can have more openness and analysis of data from software systems along with some accountability by creators for the impacts of their software. Again, I don’t know how to enforce accountability, especially at scales that encompass millions of consumers and easily cross country borders. That is a problem I think we need to find ways to tackle, at least at some manageable level. Maybe using the 80/20 rule where 80% of consumers and creators find the outcome to be a good one.

    The world of technology and software are advancing and growing extremely quickly. Certainly hardware advances, but it seems the last 5-10 years have been more about new and different software applications that fundamentally alter the way humans can interact in social, business, and government situations. Underpinning all the changes is data. New data, more data, and novel ways of working with this data in ways that were unheard of 20 years ago. It’s an amazing time to be a data professional.

    Steve Jones

    The Voice of the DBA Podcast

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