Learn the practices used by teams to break down barriers between Development and Operations and optimize the deployment pipeline.

DevOps Culture

A developer and an operations members arguing about who is to blame for the crashing application. They should be working together instead!

_Ariadne needs a new database server to support her new search feature. This should only take a few minutes but it’s stuck in the Operations team’s backlog! She might have to wait months for this simple task. What’s going on?! Ariadne's coworker Jenna suggests trying out a new team strategy called DevOps. Ariadne is not familiar with this term — what's DevOps?_

**DevOps is a culture** that shifts the way that Development and Operations team members work together. DevOps culture aims to foster trust, collaboration, problem resolution, and continuous improvement across the entire team. So how can Ariadne's team adopt a DevOps culture to increase collaboration and reduce barriers between these departments? 

Teams use a variety of practices and tools in order to foster a DevOps culture. You may have even heard of some of these practices, such as **automation** or **blameless retrospectives**. Your team may already use some of these tools, such as **version control systems**.  On their own, these practices and tools can certainly make improvements. When used within a DevOps culture, a team can be transformed.

This lesson will start by looking at traditional team culture before introducing the core pillars of a DevOps culture. We'll cover:
* Development versus Operations teams
* Dev+Ops: Shared Responsibilities and Roles
* Systems-Level Thinking
* Learning From Failure
* Feedback Loops

Introduction

A dashboard shows the health of several parts of a system. An alert is flashing indicating an issue.

_Ariadne's project manager Yuri regularly tracks the average time it takes for various tasks. She notices that since the start of the new year her developers are taking an unusually long time to respond to user-submitted bug reports. She digs deeper and discovers that the automation tool her team had been using for years to assign bug reports to developers has been shut down! She quickly pivots and finds a new tool for her team to use._

In this situation, Yuri created a **feedback loop**. A feedback loop is created when a team identifies and tracks a key piece of data, or **metric**. Teams can then use that information to drive process improvements. A typical feedback loop may look like this:

* The system is monitored and data is collected.
* Data is analyzed and bottlenecks are identified.
* Solutions are created and implemented.
* New solutions are monitored again. 

Choosing which metrics to track is perhaps the most important step in creating a feedback loop. Metrics that can't provide meaningful insight into a system just distract from the real bottlenecks. 

Focusing on metrics that affect the customer is a great place to start. Some of these include:
* Time to load a website page
* Time to resolve an issue/outage
* Time to release new features

When and where metrics are tracked is another important aspect to consider. A defect, or problem, becomes more expensive to fix as it moves along the development process. DevOps seeks to discover defects as early as possible, a strategy known as **shifting left**.

When we collect and utilize feedback loops, we are also embracing, rather than turning away from, the inefficiencies in our system. Feedback loops contribute directly to a culture of continuous learning.


Feedback Loops

Systems level thinking is illustrated by a globe. Continuous experimentation & learning shows a cycle of experiment, fail, and learn. Feedback loops shows a magnifying glass over a graph.

DevOps culture centers around collaboration between team members across all domains of software development. Teams practicing DevOps can likely include developers, IT specialists, QA testers, and security experts. Rather than siloing information, teams can share knowledge and make informed decisions together, also known as **"building quality in"**.

In order to foster a DevOps culture, teams can make use of key DevOps practices:
* **Systems-level thinking** — thinking of the whole system to identify **bottlenecks**
* **Continuous experimentation and learning** — embracing failure through practices such as **blameless retrospectives**
* **Feedback loops** — using **metrics** and **shifting left** to drive process improvement

By fostering DevOps culture and following DevOps practices, teams can build and release software with greater speed, quality, and reliability than ever before. Throughout the rest of this course, you will learn about some of the specific tools that teams use to implement this culture and its practices.


Review

A developer tries to identify who to blame for a bug in the code. It was them.

_The team is called into their manager's office once again and Thomas is nervous. His team has been losing people and is struggling to keep up with demand. The user response to the latest feature he spearheaded has not been positive. Everyone in the room is silent, waiting to see who their manager will be blaming this time. A few minutes of yelling and finger-pointing later, Thomas is packing his things, the latest member to be fired._

Organizations that punish failure create a culture of fear that gets in the way of innovation and growth. DevOps seeks to change this by viewing failure as a natural part of everyday work. Rather than having mistakes be punished, DevOps culture stresses the importance of failure as a learning opportunity. 

Failure itself is never something that teams seek out. However, once failure is normalized, teams can be more open to experimentation. Teams can try out ambitious solutions, fail quickly, learn from those mistakes, and then experiment again. This cycle enables teams to regularly make product and process improvements, both big and small.

One method DevOps uses to normalize failure and learn from experimentation is through **blameless retrospectives** (or "post-mortems"). These retrospectives are meetings held at the end of a sprint, project, or issue resolution. Here, team members discuss what went well and the areas where they can improve.

Learning from Failure

_Ariadne has really gotten behind her coworker Jenny's idea that combining Development and Operations is the way to go. Excited to adopt DevOps, Ariadne gets to work learning about the key components of a positive DevOps culture._

The culture of DevOps is the most critical factor to its success. Collaboration cannot occur from only applying a set of practices and tools. It requires a culture in which collaboration can thrive. 

The central pillars of a DevOps culture include (click on each item to learn more!):

<details>
<summary> Systems-level thinking</summary>

> Systems-level thinking means thinking about the whole production system, rather than a single department. Doing so allows teams to identify **bottlenecks**.

</details>

<details>
<summary>Continuous experimentation and learning</summary>

> Teams that embrace continuous experimentation and learning encourage rapid development of new features and accept failure as a learning opportunity.
</details>

<details>
<summary>Feedback loops</summary> 

> Feedback loops allow teams to draw information from each part of the system. As they gain insight into their systems, processes can be improved and optimized.
</details>

To have a successful DevOps culture within an organization, these components must be implemented at both a team and individual level. Only with a positive culture can the practices and tools be utilized to their fullest.


Cars driving in three lines that merge into one, clogging up the road.

Within a traditional team, team members often focus on their own tasks rather than the big picture. Developers might concentrate on the code without considering infrastructure or testing needs. The Operations team might only consider infrastructure needs without considering impacts on functionality. 

DevOps seeks to have each team member consider all aspects of the development process. This practice is known as **systems-level thinking**. Though this may sound daunting, the shared-responsibility team structure of DevOps makes this possible. When a team has developers, IT specialists, QA testers, and security experts, information is shared and decisions are made as a team. Meanwhile, individuals are given the opportunity to grow and gain knowledge in new domains.

One important outcome of systems-level thinking is the identification and resolution of **bottlenecks**. A bottleneck is a system’s slowest point, resulting in the slowing down of the entire process. A Development team with a systems-level view can more easily see where these slowdowns occur, resolve systemic issues, and optimize processes.




Systems-Level Thinking

In DevOps culture, Development and Operations teams share responsibilities, learning from each other and making decisions as a team with shared objectives.

_Tired of the lack of communication and collaboration, Ariadne approaches her engineering manager and the Operations manager with a proposal to share responsibilities._

Teams that foster DevOps culture seek to be highly communicative, sharing knowledge and experience across team members. By integrating Development and Operations teams, we can resolve many of the issues that arise due to conflicting goals. As a result, we have:
* Faster development and deployment cycles due to fewer handoffs & shared knowledge
* Environment consistency from Development to Staging to Production
* Improvement of operations activities by applying dev best-practices like version control

A typical engineering team within a DevOps culture may include various engineers, quality assurance (QA) testers, security operations, and information technology (IT) specialists. Rather than siloing information, these team members can share responsibilities, align on team objectives, and make decisions together. 

Through this collaboration, teams can produce better software in less time and more reliably than ever before.


Dev + Ops

In a traditional team culture, Development team handles writing code and hands off complete featuers to Operations. Operations deploys software on infrastructure.

_Ariadne is frustrated by how long it takes to get things done. She's just submitted a fix for a bug but can't deploy her code until the Operations team gets out of their hour-long meeting. Why can't she just deploy the fix herself?_

A traditional software company often has a separate Development and Operations team. 
* The **Development team** writes an application’s features. 
* The **Operation team** creates and maintains the infrastructure that the application runs on. 

In this arrangement, the Development team sends its code to the Operations team who deploys it on the infrastructure. 

While each team can have clearly defined responsibilities, there is an inherent conflict between the two teams. Developers want to produce new functionality as fast as possible. Meanwhile, Operations members want the infrastructure to be stable and reliable. Unfortunately, new changes are the biggest threat to the stability of a system. 

This difference in goals gets in the way of software development. Specifically, a few issues arise when an Operations team is separate from a Development team:
* Development and Operations teams own different environments in the deployment process. Differences between environments can lead to bugs that are difficult to resolve.
* Handoffs between teams take time
* Information is siloed, meaning decisions are often made without consideration of the other team.
