Instead, picture this: The meltdown of the production database is treated as a learning opportunity. Your manager brings everyone into a postmortem meeting to provide candid feedback. Everyone exhibits a level of candor that might make you squirm, but it's never at a level that places blame. The root cause is determined, and new tests are built around your mistake so that it's caught next time and everyone acts like it's simply another day. This is when you know your company has adopted an important devops philosophy.
If you are no longer trusted with commit rights to production because you have made or might make a mistake, you're doing devops wrong.
Sign No. 6: You blame others for system problems
Devops philosophy has borrowed heavily from lean, and not blaming others for systemic errors is a key facet that has influenced the human aspect of devops. As with embracing failure, removing individual blame for problems associated with the system is essential to successful devops practices.
True devops practitioners believe that when something goes wrong the fault doesn't lie with the individual using the system but the system itself. For developers and systems ops to get along, a blameless culture must be supported. Suppose a developer creates an application, tests the application on his computer, and hands the code over to operations. If a problem occurs when ops puts the code into production, ops can’t blame the developer for writing shoddy code, nor can the developer blame operations for not managing servers correctly.
Devops resolves this issue by first figuring out the difference between the two testing environments. Once discovered, the fix is implemented, and preferably, an automated test is created to ensure that, in the future, any flawed code will fail the newly automated test, which will prevent that change from ever getting into production.
If your company is firing staff simply for bringing down production, you're doing devops wrong -- regardless of any presumed role or responsibilities you attribute to those involved.
Sign No. 7: The developers and operations groups look like two grain silos
Devops weds the word "developer" to the word "operations." If your developers and operations people still aren't on speaking terms, you don't have a chance at doing devops right. Devops is all about collaboration. It's about coming together as a team to help the company, as a whole, achieve its goal. If your operations people refuse to communicate to developers other than throwing work over the proverbial wall, your devops dreams are toast.
This is the most important part of the devops philosophy. All of the activities I've touched on previously move toward this end result. It doesn't mean developers should be forced to eat lunch with operations people or operations staff must invite developers to their weddings. It's not about liking one another; it's about looking past our human emotions to work as a professional team to build a product that propels the business forward.
Sign up for CIO Asia eNewsletters.