- [Instructor] The six most prevalent DevOps methods used
by many DevOps practitioners are
people over process over tools,
continuous delivery,
lean and agile practices,
visual ops-style change control,
and infrastructure automation,
including infrastructure as code
and site-reliability engineering.
Let's have a look at how these fit
within ITIL-driven shops.
People over process over tools was coined
by Alex Honor.
The method is as simple as follows.
First, identify who's responsible for a job,
then define the processes that need
to happen around them
and finally, select and implement the tool
to perform that process.
This may seem like the obvious thing to do,
but the process often happens in reverse.
You may recall the saying from ITIL,
a fool with a tool is still a fool.
In this thinking, it's important for you
to understand what you're trying to do
and even more importantly, why,
before selecting a tool.
One thing you can do here is
to apply this concept to ITIL roles.
For example, Ben Rockwood of Chef talk about
an emerging cloud governance role
that builds tools to reap, prune,
and report on consumption,
and to integrate into financial and vendor management,
especially around annual renewal cycles.
That's the job function.
Now, who owns it, what's the process,
and finally, what tools should enable that process?
The aim of continuous delivery can be summed up
in the phrase smaller plus faster equals better.
CD is the practice of coding, testing,
and releasing software in short cycles,
in really small batches,
ensuring that software can be reliably released at any time,
reducing the time, cost, and risk
of building, testing, and releasing software
by allowing for more incremental updates
to applications in production.
Studies show that in CD environments,
teams spend 22% less time on unplanned work and re-work,
changes have a three times lower failure rate,
and teams recover 24 times faster from failures.
These are all great numbers to pursue.
Introducing continuous delivery affects the ITIL, design,
and transition lifecycle phases the most.
When you move to continuous delivery,
the most critical shift will be in your service design
and transition processes,
specifically, in the automation of testing,
including unit testing, integration testing,
and testing from the outside in,
as in, test-driven development,
behavior-driven development,
and acceptance test-driven development.
Also, infrastructure testing, performance,
and security testing.
Lean practices focus on continual improvement
and the elimination of unnecessary activities.
Agile practices focus on responding
to changing needs, shorter release cycles,
and collaboration.
Lean and agile practices are fundamental to DevOps
and compatible with ITIL-driven shops.
One thing you could do here is to apply the lean
and agile practices of rapid iteration
for continuous improvement
for the operation phase of a service lifecycle,
resulting in faster time to value
for consumers of software.
For example, run a weekly ops metrics meeting
covering SLAs, SLOs, internal goals,
and customer-facing targets aimed at continual improvement,
then take an agile approach to improvement.
Try a scrappy or janky solution
with the attitude of, if it works great,
if not, we'll try something else.
In all cases, collect and use data
to tell whether it's working or not.
For example, for event management,
if you get 50 alerts on a regular basis
that you must respond to, you need to figure them out.
You may learn that not all 50 alerts are the same,
some are urgent, some not,
so you tune your alerts
and respond through experimentation,
frequent ones you automate, for example.
Visible ops-style change control
is described in the book Visible Ops,
which describes a light-weight
and practical approach to change control.
It emphasizes eliminating fragile artifacts,
creating a repeatable build process,
managing dependencies,
and creating an environment of continual improvement.
Adopting visible ops-style change control methods
and applying them to your ITIL-driven change control process
is one of the most important things you can do
to adapt your ITIL-driven shop for DevOps.
Legacy enterprise change and release gates are often overrun
by the pace of DevOps,
so getting agile around change management is essential.
The idea here is not to get the process out of the way,
but to attack the source of process overhead,
fragile artifacts,
manual and varying build processes,
unnecessary dependencies, and so forth
as a basis for lighter weight
but effective change control.
Infrastructure automation is based
in a cloud-based reality
and infrastructure components can
and should be treated like code.
System specifications should be checked into source control,
go through a code review,
automated testing, and so forth.
This enables you to automatically create
uniform instances from the specification
and to manage them programmatically.
There are so many ITIL challenges you can overcome
by infrastructure automation.
For example, you can start by applying the DevOps method
of infrastructure automation
to your ITIL-driven IT service continuity
or disaster recovery process.
We used to talk a lot about design for availability
and a DR site and hardware in another city,
keeping two data centers in sync.
Now because I can script my infrastructure deployment,
I can just grab my script,
point it at the other data center,
run it and bam,
I've got another instance of my infrastructure.
Some organizations I work with have gone
beyond infrastructure as code to operations as code,
automating every ITIL process with code.
Alerts, incidents, problems,
provisioning, capacity, demand,
availability, performance,
everything can be reduced to automation through code.
Site reliability engineering, or SRE,
is defined by Ben Treynor,
founder of Google's Site Reliability team as,
what happens when a software engineer is tasked
with that used to be called operations?
SRE is a discipline that incorporates aspects
of software engineering and applies that
to operations with a goal of creating ultra scalability
and highly reliable software systems.
SRE focuses on engineering continuous operations
at the point of customer consumption.
The largest impact of SRE on ITIL-driven shops
is the new role of the SRE.
Part system administrator, part second tier support,
and part developer, SREs are encouraged
to be inquisitive, to acquire new skills,
to ask questions, to solve problems,
and embrace automation.
SREs have the ability to code
and an unwavering thirst for knowledge and improvement.
The largest impact of SRE on ITIL-driven shops is
that the SRE role is an entirely new role in many shops.
Part system administrator, part second tier support,
and part developer, SREs ask questions,
acquire new skills and knowledge,
and embrace automation,
and have the coding skills to solve problems
and ensure the highest levels of reliability
and availability.
SREs are involved in handling and management
of late-night incidents, escalations,
root cause analysis, service-level objectives,
availability metrics,
and other ITIL-driven practices.
SREs provide a basis for instilling agility
into many ITIL processes
to meet changing demands brought about
by the marks of the cloud
and DevOps, lean, and agile practices.