Five DevOps Essentials for DBAs and Developers

A fundamental tension exists between development and operations/production DBAs:

• Development wants continuous change and enhancement, is focused on meeting schedule targets
• Production operations wants stability and controlled change, and is focused on meeting reliability targets
• In practice, the Production and Development groups work in their own silos, with separate tools, and are separately evaluated for successful completion of their mission.

DevOps is a philosophy intended to remove the silos separating the groups and focus them on the company business mission. It extends Agile development practices to production IT operations. DevOps attempts to reconcile the tension between conflicting objectives of stability and change.

Keys to DevOps Success for DBAs and Database Developers

1. Give developers direct monitoring visibility to production, staging and test servers. Until a developer sees the real behavior of the code hitting loaded databases and with competing queries, they have no sense of how the application will really behave. Gartner says “You will never know reality until you know production” (Murphy/Kowall, January 2012). Locked rows, blocking queries, and resource contention never come into play until an application query must contend with live traffic. 
2. Enhance collaboration by making developers self-sufficient in their performance observations. One of the objectives is to enhance collaboration between DBAs and Developers, but allowing them to work independently, rather than forcing the DBA to be the gatekeeper for all information, actually pays real benefits for collaboration. In typical sites, only DBAs have knowledge and access to the query performance information. When developers need something, they must always request it from the DBA. The result is DBAs seeing developers as “time sinks” and developers seeing DBAs as “gatekeepers” who make it hard to access the information they need. If developers get direct insight to the performance, their interaction with DBAs will be constructive, rather than one of begging for information. 
3. Make performance a stated functional requirement. For too long, performance was a “non functional” requirement in the software development process, along with the other “-ilities” like reliability and availability. Thus performance would be an afterthought, addressed only after the functional spec had been addressed. Making performance an essential part of the design process, with testing and evaluation of performance early in the development cycle, ensures it will not have to be “tacked on” later. 
4. Establish shared metrics and a basis for equal access to metric reports. Development, production, and management must have a basis for comparing results, evaluating progress and tracking change impacts. If the metrics are to be understood by all, they have to be simple in concept and presentation. When the software and system engineers have a common basis for discussion and progress evaluation, they’ll be in better shape to work towards the same goal. 
5. Focus on the end-user experience. Working in their technical silos, developers and production DBAs set targets based on meeting their own functional goals for schedule, availability and similar conventional metrics. When IT takes a service orientation, the focus needs to shift to the end user. Whether it is an external customer on a web store, or an application owner in an internal business unit, the service level delivered to the customer is really the only important metric on which to evaluate IT department. With a common goal of responsive, predictable service for end user applications, both production and development can collaborate to meet the common target.

These principles do not cover every DevOps topic, but for the problem of bringing developers and DBAs together as a collaborative team, and for focusing on end user application performance as a significant shared goal, these are essential guidelines.