[Note from Pinal]: This is a 91st episode of Notes from the Field series. Divas is a new buzz word with lots of substance behind it. Not everyone understands what it means and not everyone actually related it to their daily job. Lots of people think that it is alright to not explore and learn about this as after a few days or months it will be meaningless. However, the reality seems very different about DevOps as it is one of the concepts which is just rediscovered. I recently asked my friend Stuart about what it means by DevOps for DBA and he had a informative answer to this question.
In this episode of the Notes from the Field series database expert Stuart Ainsworth explains about DevOps for the DBA. Let us read the story in his own words.
Not every problem that a DBA encounters is a technical one; sometimes, it’s a procedural one. I’ve recently become enamored with the philosophy of DevOps, and have tried to find ways to transform those concepts and ideas into practical, actionable advice for my clients. It’s still a work in progress, but I’ll try to summarize my thoughts today (and, they could change tomorrow).
A Brief Summary of DevOps
DevOps is a collaborative approach to software development and delivery that is influenced by Agile development methods and Lean IT principles; the idea is to
decrease time-to-market by looking at (primarily enterprise) software development as a life cycle, and finding ways to automate and increase efficiency. The general framework is often described as consisting of the Three Ways (a phrase fully explored in The Phoenix Project):
- The First Way: Systems Thinking. A complete software development lifecycle encompasses all the functionality involved in both development and operations (including QA and acceptance testing); the entire system is intertwined in order for the business to bring value to customers. Development responsibility isn’t complete when software passes QA, and Operational responsibilities don’t simply begin during the install. Both groups should be involved to some degree throughout the process.
- The Second Way: Amplify Feedback Loops. No system is complete without feedback, and DevOps approaches focus on increasing the immediacy of that feedback. Bugs need to be simple to report and acknowledge; suggestions should be taken seriously.
- The Third Way: Culture of Continual Experimentation and Learning. Success is found when you take a risk, and DevOps is about creating an environment where risk is encouraged and rewarded. This is often problematic for Operations, who are usually responsible for maintaining the stability of an environment, but that’s a key to this principle: Ops MUST be involved in finding a way for Dev to take risks while continuing to ensure the stability of the environment.
From Philosophy to Practice
All that’s well and good, but what does it mean for the average DBA? How do we go from thinking about processes, procedures, and philosophy to real meaningful change? Here’s three specific practices that operational DBA’s should implement as soon as possible:
- Respect the role of development. Consider the following scenario: some performance issue has occurred, in operations, and the DBA has stepped in to make a fix (say an index change, or something more drastic like a stored proc rewrites). The implemented fix is now different than the source of truth for development (their source control), and that’s bad. It hampers the development effort, but sometimes emergency interventions are necessary to keep the business afloat; what do you do?First and foremost, DBA’s need to limit the changes that they make to strictly emergency fixes; emergency fixes need to be reported to develop as soon as possible. Not all performance changes need to be emergency fixes; those should be reported to dev, but unless the business is grinding to a halt, the DBA’s should not change the code in operations. This practice illustrates both the First and the Second Way above.
- Request simple methods to supply feedback. If developers are responsible for writing code, they have to be receptive to feedback from operations. I’ve worked in shops where only the developers and QA had access to create bugs; this kills the feedback loop. Operational DBA’s must find ways to report issues to development as soon as possible; any electronic tracking measure should be simple to identify who reported an issue, when they reported it, and what was decided to do about. If the feedback is associated with an emergency change, the DBA should include the code that they changed, so that source control can be edited to include the current production version. The key takeaway is that EVERY change to an operational system must be reported to the developers.
- Strive to provide operational support to development efforts. The best development environment is one that is identical to operations; that’s not always feasible or practical to implement. DBA’s need to be part of the development process by finding ways to make the dev environment as similar to production as possible; virtualization technology can be a great tool for that, whether it’s virtualizing servers (e.g., VMware, Hyper-V, VirtualBox) or databases (e.g., Delphix). Short of that, you can just make sure that your developers have a good representation of the current production statistics.
Summary
Software development is hard; systems administration is hard. Working together can make it easier, but you have to focus on practical changes to your software culture to make things happen.
If you want to get started with SQL Server with the help of experts, read more over at Fix Your SQL Server.
Reference: Pinal Dave (https://blog.sqlauthority.com)
