Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Tips for Avoiding a DevOps Disaster (Part 1)

DZone's Guide to

Tips for Avoiding a DevOps Disaster (Part 1)

While most would argue that DevOps is vital for a company to survive in a hyper-competitive tech market, there are definitely things that can go wrong if it's not implemented with care.

· DevOps Zone
Free Resource

“Automated Testing: The Glue That Holds DevOps Together” to learn about the key role automated testing plays in a DevOps workflow, brought to you in partnership with Sauce Labs.

DevOps is a revolutionary practice that creates a company culture of openness and collaboration between developers and operators. It enables businesses to release new software and updates with fewer bugs more rapidly than ever before. Most would argue that it is vital for a company to implement to survive in a hyper-competitive market. But, sometimes things can go wrong.

Here’s a list of some bad scenarios and how to avoid them:

  1. Lack of understanding of workflows. When IBM first began implementing DevOps, they invested heavily in agile—a set of principles for collaboration in software development. On paper, it seemed like a great solution to a problem with efficiency, but it turned out to be less than successful. Agile could only take IBM so far. Development became very fast, but slow-responding operations canceled out any speed gains on the development side.
    The company next began to automate code deployment to make up for the operations bottleneck. IBM quickly found that this, too, failed to decrease product release time. The DevOps application was initially a failure because IBM did not understand the workflows of their employees. They failed to achieve a complete understanding of their processes from initiation to completion.
  2. Too many people have too much access. In 2006, SlideShare—a startup of 20 employees—launched their own DevOps. In what is now a well-known DevOps no-no, the burgeoning company granted unprecedented full production server and database access to engineers.
    One day an engineer was working on a project and he decided to reorganize the database columns to make his work more convenient. He did not realize that what he was doing affected the actual production and he brought down the entire company.While the employee did not have ill intent, his access was unnecessarily open and his actions managed to create a whole new set of problems for the company to solve. When it comes to server access, workers should only have admission to what they need and, as much as possible, should not have the sole ability to bring down the company.

Stay tuned for Part 2!

Learn about the importance of automated testing as part of a healthy DevOps practice, brought to you in partnership with Sauce Labs.

Topics:
company culture ,workflow ,ibm ,slideshare ,disaster

Published at DZone with permission of Yaniv Yehuda, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}