Unit-5

CAMS Approach to DevOps

 Every DevOps model consists of certain core values
that follow the CAMS approach for successful
implementation.
C= Culture
A= Automation
M= Measurement
S= Sharing
 CAMS model represents the four pillars of DevOps.
CAMS Approach to DevOps
 If an organization wants to adopt DevOps, it must
start the organization's transformation with CAMS.
CAMS approach
 Developing a culture by respecting one other.
 Automate wherever possible to eliminate errors
 Measuring progress based on specific metrics and
KPls.
 Share feedbacks, ideas and resources with trusted
people.
Culture
 The purpose of DevOps is to bring together different
teams so that they all work as a single entity to achieve
designated target for the organisation.
 Since the teams are working together, it creates a
positive attitude or culture among the teams
 Teams are capable of handling situations more wisely,
enables continuous learning and sharing skills are
developed.
 All this leads to efficient and innovative software
development and delivery.
Culture
 DevOps culture emphasizes on offering high quality
service.
 To offer better service, DevOps teams should have the
knowledge of how the product will be received and
used by its customers. This will enable the teams to
offer continuous service support even after the product
has reached the customers.
 Performance is tracked throughout the lifecycle of
product to ensure that it continues to offer value to its
customers.
Culture
 Service mindset is a critical aspect of DevOps culture
which has the following .
1. Quality is given utmost importance right from the
source.
2. Early discovery of errors.
3. Happy customers.
Culture
 Establishing a DevOps culture means teams are at
environment that promotes continuous learning,
autonomy to experiment, a product thinking mindset,
an engineering culture & focus on quality.
Automation
 Technology advancements are leading to
automation of routine tasks in different industry
such as manufacturing, healthcare, transportation
and IT.
 In a software delivery lifecycle, many of the tasks
are repeated and become routine. Automation of
routine tasks improve the efficiency of the entire
delivery process.
Automation
 First, the routine tasks need to be identified and then
automated. Some routine tasks are test execution,
deployment execution and code compilation.
 Automation helps delivery teams to focus on non
routine tasks that have a high level of variability.
 Automated processes are repeatable.
 With Automation, Cost of process execution is
minimized.
Automation
 Automation is the most vital factor of the DevOps.
 The purpose of automation is to build a system such
that it eliminates various human errors and can fix
errors and repeating the successful process again
without any delay.
 Automation greatly improves the workflow and
productivity of the organisation.
Measurement
 Like Automation, Measurement is also important
because by measuring the different system metrics, we
can know how the system works or what needs to be
done to increase performance and productivity etc.
 Measuring progress based on specific metrics and KPls
 Measurement is needed for continuous improvement.
Tracking important metrics and offering feedback
helps improve the process.
Measurement
Measurement is all about four things:
1. Monitoring and tracking performance through out
the software development lifecycle.
2. Collecting, analysing, and providing ways of acting on
feedback.
3. Analysing mistakes and figuring out how to avoid
them
4. Assisting teams to help them work on common goals.
Measurement
 DevOps drives continuous improvement only if
specific metrics are collected and analysed in a
continuous manner.
 Some of these metrics and KPls are MTTR (mean
time to repair), cycle time appears (i.e., lead time),
costs, revenue, and employee satisfaction.
 If you want to drive value to your customer more
quickly and efficiently, make sure that you can
measure and act on the results.
Measurement
Here are few tips on how to collect and analyse
metrics:
1. Devise metrics to measure specific stages of the
DevOps lifecycle.
2. Keep your metrics open and transparent for all
stakeholders.
3. Ensure that your metrics aren't mostly technical
but prioritize business goals as well.
4. Follow up and re-establish measurement targets
that are not fulfilled.
Sharing
 DevOps by definition is the collaboration of
development and operations and implementing
DevOps involves knowledge sharing.
 The key success of DevOps in any organization is
sharing the ideas and knowledge among teams.
 Sharing has many benefits inside and outside
organization.
 Create new opportunities for people to collaborate .
 Finding people with common interests will result in
better engagement among them.
Sharing
 Outside the organization, sharing resources within
trusted communities helps to get new features
implemented in open-source software more
quickly.
 DevOps is a continuous improvement culture.
 In continuous improvement, you discover and fix
bottlenecks, automate against their appearance,
integrate fixes into the DevOps lifecycle, and
communicate changes to stakeholders (and
customers).
Sharing
Sharing
 People make mistakes and they tend to hide their
mistakes because of the fear of getting blamed or
punished.
 Bear in mind that people are always going to make
mistakes. punishing and blaming people for their
mistakes won't help your organization.
 A blame-free environment is required for effective
sharing.
How to encourage sharing
information and feedback
 Don't try to fix people - fix errors. Identify the
error and quickly fix it,
 Don’t focus who did mistake and why. Use
mistakes to make your system more strong.
 Encourage employees to ask questions and share
their opinions to eliminate problems.
Test Driven Development
 Test Driven Development (TDD) is a software
development practice that focuses on creating unit
test cases first before developing the actual code.
 In TDD, developers write a test before they write
just enough production code to fulfill that test and
the subsequent refactoring.
 It is an iterative approach that combines
programming, creation of unit tests, and
refactoring.
Test Driven Development
 TDD approach originates from the Agile manifesto
principles and Extreme programming.
 In TDD, developers start creating small test cases
for a feature based on their initial understanding.
 The primary intention of this technique is to
modify or write new code only if the tests fail.
How TDD works?
How TDD works?
 The first step in test-driven development is to plan and
create tests for each application's functionality.
 Test cases are generated and tested for each capability
first, and if the test fails then only new code is
produced to pass the test and provide simple, bug-free
code.
 The test-driven development framework tells
programmers to build new code only in the event that
an automated test fails. This prevents code
duplication.
Frameworks for TDD
 PyUnit : Popular Unit testing framework for
Python.
 Junit: Widely used unit testing tool for Java
 TestNG: Another popular Java based testing
framework.
 Rspec: A testing framework for Ruby projects.
Test Driven Development
 A Red/Green/Refactor cycle is a common way to
explain the TDD process.
Test Driven Development
Test Driven Development
Red phase
 Developers create a test for the behaviour that is about
to be implemented.
 This is the most challenging stage as the developer
need to design a test against no code or absence of
code.
 When the test case is attempted to be run using the
developer's unit test framework it will throw a red flag.
The test case failed at this point. This is why it is
known as the red stage.
Test Driven Development
Green Phase
 In this stage developers write code that is required to
pass the failed test. Developers write simple code and
this code need not to be the most efficient .
 The developer will create the next test to fail once and
keeps adding code to make it pass.
 At this point, we can either move on to the Refactor
phase, or return to the Red phase where we write a new
test that breaks the implementation we've developed.
Test Driven Development
Refactor Phase
 Improve the code without changing the functionality .
 By the end of this phase, we have clean, simple and
efficient code.
 we end up with code that has passed the test, and with
a design that is as simple as possible.
Benefits of Test-Driven
Development (TDD)
 Code written using test-driven development is of higher
quality and has fewer errors.
 The addition and testing of new functionalities become
much easier in the latter stages of development.
 Test coverage under TDD is much higher compared to
the conventional development models. This is because the
TDD focuses on creating tests for each functionality right
from the beginning.
 Enhances the productivity of the developer and leads
to the development of a codebase that is flexible and
easy to maintain.
Configuration Management
 Configuration management refers to the process by
which all environments hosting software are configured
and maintained.
 Every development pipeline requires multiple
environments - unit testing , integration testing ,
acceptance testing , load testing , system testing, end-
user testing etc.
 The environment set ups for these tests would become
more complex as it moves towards pre-production and
production environment.
Configuration Management
 Devops Configuration management is the automated
process to manage all the configurations of each of
these environments.
Traditional vs DevOps
Configuration Management
 In traditional configuration management methods,
the team used to manage these configurations of
various environments via formal documentation where
each of the configurations are recorded in the
documents.
 when s/w undergoes changes, team take the
responsibility of setting up the environment and
managing the configurations manually.
Traditional vs DevOps
Configuration Management
 In DevOps, typically all these configuration
management processes are well automated and the
configurations are encapsulated in the form of code or
scripts and controlled through the version control
tool.
 The key highlights of configuration management in
DevOps is delivering
 Infrastructure as a code.
 Configuration-as-a-Code
Configuration Management
 What does 'Infrastructure as a code' mean?
 It is defining the entire environment definition as a
code or a script instead of recording in a formal
document.
 It automates the environment necessary for
development, without manually completing all the
steps necessary to build the environment.
 Environment definition generally includes set up of
servers, configuring networks, and setting up other
computing resources, which are a part of the
infrastructure .
Configuration Management
 Infrastructure as a code
 Example: if we want to add a server to the specific
environment, all that we would is to update this
information in to the environment scripts and run the
delivery pipeline, instead of manually going and
spinning out a new environment with the added
server.
 Several tools are available to carry out the
infrastructure automation in the market.
 Few of them are Chef, Puppet,Terraform etc.,
Configuration Management
Configuration-as-a-Code
 Configuration as a·code is a code or script that
standardizes configurations with in a given resource,
like a server or network.
 These configurations are applied during the
deployment phase to ensure the configuration of the
infrastructure makes sense for the application.
Configuration Management
Elements of DevOps Configuration Management
 Configuration Identification: Identity the
configuration of the environment need. One can also
use discovery tools to identify configurations
automatically.
 Configuration Control : It's likely that configuration
needs will change over time. Most configuration
management frameworks have a change management
process regulating these configurational changes not
to destabilize integrations and existing infrastructure.
Configuration Management
Elements of DevOps Configuration Management

 Configuration Audit: Even with control mechanisms,

changes may by pass them. Configuration audits at
regular intervals prevent such incidents i.e. to ensure
that it stands up to compliance regulation and
validations.
Configuration Management
Benefits of Configuration Management in DevOps
 All the configurations and infrastructure details are
version controlled which is a big benefit in DevOps
implementation.

 Teams can manage the changes to the servers and

configuration in an automated fashion and helps
to debug quickly if anything fails with in a short time
span.
Configuration Management
Benefits of Configuration Management in DevOps
 Since the scripts are located on the central server and
everyone in the team knows what are the changes
made in each of these versions. This also enables the
team, to restore older version, if there is any problem
in the latest versions.
 Since configuration management is totally automated,
manual intervention either to set up or update is
completely eliminated avoiding human errors and
improving the quality.
Configuration Management
Benefits of Configuration Management in
DevOps
 configuration as a code removes the dependency
on a single person or a team called config manager
or config team. Development team need not have
to wait for the config team to come and fix any
infra or config problem.
 Boosts collaboration between Operations and
Development team.
Infrastructure Automation
 A software development infrastructure typically
consists of tools, processes, and environments
used to develop, test, deploy, and manage software
applications.
 When all these components work together,
provide a streamlined way to develop software
applications.
Infrastructure Automation
 As the scale of organizations increases, the
structure of IT infrastructure also become more
complex.
 IT teams often find it challenging to keep pace
with increasing complexities.
 Applying automation simplifies operations , giving
you greater control over your infrastructure.
Infrastructure Automation
 Infrastructure Automation under DevOps refers to
a concept of managing infrastructure with the help
of code.
 This is done with the help of certain tools .
 Some of the leading IAC tools are Ansible,
Terraform, SaltStack,Azure Resource Manager etc
Infrastructure Automation
 It allows for controlling and customizing the
required infrastructure when required.
 With IAC, developers don’t need to manually
provision and manage servers, operating systems,
storage, and other infrastructure components each
time they develop or deploy an application.
Challenges for Infrastructure
Automation in DevOps
Culture
 Every organization needs a culture of innovation,
learning. Not having the right mindset among
employees can lead to the failure of projects.
 However, with the right culture an organization can
resolve any skill and infrastructure issue.
Challenges for Infrastructure
Automation in DevOps
Communication and processes
 DevOps is to bring different teams work together at
the same time.
 It is very important for an organization to keep all
team members on the same page.
 Provisioning resources takes longer with outdated
communications and manually built test
processes.
 This weakens the quality of testing and development.
Challenges for Infrastructure
Automation in DevOps
Infrastructure
 Automation is the key to DevOps.
 An outdated infrastructure with no self-service
and little to automation can never be efficient.
 Infrastructure Automation needs constant
improvements and upgrades to avoid challenges of
any kind.
Challenges for Infrastructure
Automation in DevOps
Tools and Apps
 The gap between the business users and
developers is something that it needs to be
reduced.
 Using unauthorized tools by both developers and
users makes the process even more complex.
 However, with automation in DevOps an
organization can make these changes a lot faster.
Challenges for Infrastructure
Automation in DevOps
Budgeting
 Companies begin to scale up their DevOps
infrastructure through quick automation, and in
doing so create another functional team.
 This adds to the existing infrastructure and is not
quite budget friendly.
 They would rather adopt cloud infrastructure to
scale up their operations.
Benefits of IAC in DevOps
 Cost reduction
 Increase in speed of deployments
 Reduce errors
 Improve infrastructure consistency
 Eliminate configuration drift i.e. inconsistencies
between the servers, which sometimes happens
due to manual update .
Root Cause Analysis
 Root-cause analysis is defined as the process of
investigating an issue using proven techniques to
gather data about the problem, identifying causes,
prioritizing them, and coming up with potential
solutions.
 It aims to locate the fundamental reason of an
issue by employing a specified set of processes and
accompanying tools.
How to Perform Root Cause
Analysis
 The following are the fundamental steps in the root
cause analysis process:
Step 1: Define the Issue
The first step is clearly defining the problem. The team
in charge of the RCA should then analyze the problem
definition to determine its viability and accuracy.
How to Perform Root Cause
Analysis
Step 2: Collect as Much Data as Possible.
The next step is collecting adequate evidence or
information about the problem statement. Your
focus should be on quantitative and qualitative
data, as it helps you understand the issue
comprehensively.
Step 3: Identify the Causes
Once you have enough data, it's easier to evaluate
every cause and pinpoint the root cause that
triggers the issue.
How to Perform Root Cause
Analysis
Step 4: Determine the Solutions
This step focuses on finding solutions for the
particular root causes. The solutions can be:
Preventive Solutions - These are detailed long-
term measures to prevent future ocurrence.
Corrective Solutions - These are short-term
solutions that address the current issues.
How to Perform Root Cause
Analysis
Step 5: Develop Action Plans or Strategies to Apply
the Solution
After defining the solutions, you need to devise a plan
to implement the solutions systematically.
Necessary actions to apply the solutions
The resources these actions need
Schedule of the particular actions
The people responsible for the actions
How to Perform Root Cause
Analysis
Step 6:Track the Solution and Check the Functionality
This step is regular monitoring of the implemented
solutions. Doing so ensures the solutions remain feasible
to prevent the root causes from recurring.
Techniques used in Root Cause Analysis
5 Why’s Analysis
 5 Whys analysis involves answering several follow-up
questions about the issue. This technique gives you
deeper insights into the problem.
 Checking the answers gives you a clearer picture of the
issue ,while strategically highlighting the actual cause
of the issue.
Techniques used in Root Cause
Analysis
Failure Mode and Effects Analysis (FMEA)
Failure Mode and Effects Analysis focuses on the
failure modes and suggests corrective action. This
technique has two particular aspects:
 Failure Mode -This involves pinpointing the
different ways or types in which something can
go wrong.
 Effects Analysis - It involves evaluating the
consequences and effects of every failure mode
you identified.
Techniques used in Root Cause
Analysis
CED (Cause-and-Effect Diagram) or Fishbone
Diagram/Ishikawa Diagram
 This fish diagram has all possible root causes
linked to a particular problem.
 The fish head represents the problem, while the
possible causes branch out of the spine. The
secondary causes form the spine's sub-branches.
 It would help if you tackled each branch at a time
by brainstorming and questioning the causes.
BLAMELESSNESS
 In DevOps, "blamelessness" is a cultural and
operational concept that emphasizes creating an
environment where individuals are not blamed for
failures but instead focus on learning from them
and improving processes to prevent similar issues
in the future.
 Blamelessness is closely tied to the principles of
blameless post-mortems and blameless culture.
BLAMELESSNESS
Blameless Post-Mortems:
 When an incident or failure occurs, a blameless
post-mortem is conducted to analyze what went
wrong, why it happened, and how to prevent it from
recurring.
 The primary goal is to understand the root causes
of the problem rather than assigning blame to
specific individuals or teams.
 Blameless post-mortems encourage open and
honest communication, allowing team members to
share their observations and experiences without
fear.
BLAMELESSNESS
Psychological Safety:
 Blamelessness is closely linked to the concept
of psychological safety, which means that team
members feel comfortable admitting mistakes,
asking questions, and providing feedback.
A psychologically safe environment
encourages transparency and a willingness to
learn from failures.
BLAMELESSNESS
Continuous Improvement:
 Blamelessness aligns with the DevOps principle of
continuous improvement. When failures occur, teams
use the insights gained from blameless post-mortems
to implement changes and enhancements to their
processes, systems, and automation.
Documentation and Knowledge Sharing:
 Documentation is essential in a blameless culture to
capture knowledge about past incidents, their
resolutions, and preventive measures.
 Teams should actively share this knowledge to ensure
that everyone benefits from the lessons learned.
 organizational learning
 Organizational learning is a crucial aspect of DevOps,
as it helps teams and companies continuously improve
their processes, culture and performance.
key elements of organizational learning:
 Blameless Culture: A blameless culture is essential
for learning. When something goes wrong, instead of
blaming individuals, the focus is on understanding
what went wrong and why. This encourages
transparency and fosters a culture of learning from
failures.
Organizational learning
 Continuous Improvement: DevOps teams should
constantly seek ways to improve their processes, tools,
and collaboration.
 Knowledge Sharing: Encouraging the sharing of
knowledge and best practices across teams is vital.
This can involve documentation, regular meetings,
and cross-functional collaboration. Knowledge sharing
helps prevent silos and ensures that lessons learned in
one area benefit the entire organization.
Organizational learning
 Metrics and Key Performance Indicators (KPIs):
Establishing metrics and KPIs that align with business
goals is essential. These measurements provide
valuable data for assessing the effectiveness of DevOps
practices and identifying areas for improvement.
 Experimentation and Innovation: Encourage teams
to experiment with new technologies and approaches.
Innovation often comes from trying new things and
learning from both successes and failures.
Organizational learning
 Cross-Functional Teams: DevOps promotes the
breaking down of silos between development,
operations, and other departments. This cross-
functional approach encourages learning from
different perspectives and experiences.
 Training and Education: Invest in training and
education for team members. Keeping up-to-date with
new technologies and best practices is crucial for
organizational learning.
Organizational learning
 Post-Incident Reviews: Conduct post-incident
reviews (PIRs) or post-mortems after major incidents.
These reviews provide an opportunity to understand
what led to the incident, how it was resolved, and what
steps can be taken to prevent similar incidents in the
future.