Soup to Nuts SRE:

How to leverage ITSI, VictorOps and Phantom

to be a site reliability engineering super hero

Chris Crocco
Senior Sales Engineer | Splunk
 © 2019 SPLUNK INC.

Forward-Looking Statements
During the course of this presentation, we may make forward-looking statements regarding future events or
the expected performance of the company. We caution you that such statements reflect our current
expectations and estimates based on factors currently known to us and that actual events or results could
differ materially. For important factors that may cause actual results to differ from those contained in our
forward-looking statements, please review our filings with the SEC.

The forward-looking statements made in this presentation are being made as of the time and date of its live
presentation. If reviewed after its live presentation, this presentation may not contain current or accurate
information. We do not assume any obligation to update any forward-looking statements we may make. In
addition, any information about our roadmap outlines our general product direction and is subject to change
at any time without notice. It is for informational purposes only and shall not be incorporated into any contract
or other commitment. Splunk undertakes no obligation either to develop the features or functionality
described or to include any such feature or functionality in a future release.
Splunk, Splunk>, Listen to Your Data, The Engine for Machine Data, Splunk Cloud, Splunk Light and SPL are trademarks and registered trademarks of Splunk Inc. in
the United States and other countries. All other brand names, product names, or trademarks belong to their respective owners. © 2019 Splunk Inc. All rights reserved.
 © 2019 SPLUNK INC.

What is SRE?
And why is my boss so excited about it?
 © 2019 SPLUNK INC.

Site Reliability Engineering is….

1. A set of core tenants adhered to by SRE teams to ensure the day to day
operational requirements of their service are met.

2. Meant to ensure focus remains on engineering, not operations

3. A mechanism to maximize the pace of innovation and product stability

4. A way to ensure your resources and capacity are in line with scheduled
deployments

5. Most importantly…..a little different for everyone!

 © 2019 SPLUNK INC.

Site Reliability Engineering should not be….

1. A catch all for the Dev teams deployment work

2. A strictly operational mindset

3. A single point of contact for all teams

4. ”In Charge” of DevOps team priorities

5. A “by the book” organization

 © 2019 SPLUNK INC.

Who should be Site Reliability Engineer?

1. Highly technical and top performing resources from your traditional ops team

2. Problem solvers

3. Curious and creative individuals

4. Self-directed and team focused

 © 2019 SPLUNK INC.

SRE and DevOps

Different roles with the same goals
 © 2019 SPLUNK INC.

How people think DevOps and SRE work together

I’m the SRE and you’re

doing it wrong!

Whatever, I’m in
DevOps and I know
my code is good.
 © 2019 SPLUNK INC.

How DevOps and SRE should work together

I’m the SRE and I found

this as the root cause of
that event, you might want
to check it out.

Thanks man! I’m gonna

do a bug fix for that
since I’m DevOps
 © 2019 SPLUNK INC.

Tenants of SRE
The core of what your SRE team should be doing
 © 2019 SPLUNK INC.

Core Tenants
Building blocks for success

Maximizing Efficiency
Emergency Change Capacity Focus on
Monitoring Change and
Response Management Planning Engineering
Velocity Performance

Traditional Change
Traditional NOC Traditional Infra Ops
Management
 © 2019 SPLUNK INC.

Core Tenants
Building blocks for success

Phantom Emergency Response

Focus on Engineering
Change Velocity

Emergency Response VictorOps

Focus on Engineering
Change Management

ITSI

Monitoring
Capacity Planning
Efficiency and Performance
 © 2019 SPLUNK INC.

Making Monitoring Matter

Alerting, ticketing, logging and so much more!
 © 2019 SPLUNK INC.

Changing what and why you monitor

Stop fighting fires.
Traditional Monitoring Monitoring in SRE
• Waiting for specific conditions to • Automation of condition
occur, minimal correlation interpretation and correlation

• Alert interpretation and • Humans only engaged when

decisions requires human manual action is required
interaction
• Ticketing, logging and alert
• Dedicated people for taking tuning are also automated
action on alert conditions
• Neighbor/dependent services
• Manual ticketing, logging of are intelligently associated
events • Symptom events are informed
only if self-recovery doesn’t
• Silo’d RCA and problem occur
resolution
 © 2019 SPLUNK INC.

Monitoring services in ITSI

Building blocks for success

▶ Decompose your service first

KPI's
Entities
▶ Know what “Healthy” means
Nearest
Neighbor
Services ▶ Know who your neighbors are

▶ Have a process for all 3 component

ITSI Service
 © 2019 SPLUNK INC.

Monitoring Services with ITSI

You’re service….

On another team’s
Are being impacted infrastructure.
by an event….

And your nearest

neighbor….
 © 2019 SPLUNK INC.

Monitoring Services with ITSI

Alert on it!

Grab the KPI’s that

matter

Find the smoking

gun….
 © 2019 SPLUNK INC.

Monitoring Services with ITSI

Machine learning to the rescue!

Let ITSI find your weird stuff for

you…

Automated grouping
and correlation
And predict when it will happen in
the future!
 © 2019 SPLUNK INC.

Now….get the right hands

on keyboards
For things unknown….
 © 2019 SPLUNK INC.

Alerting in the SRE Age

Show the pain, make it painless

1. Alerts should be rare, significant and immediately impacting to the business

2. ITSI should have already interpreted and correlated the data

3. Unknown and complex issues should take priority

4. Triage is not the sole responsibility of the SRE or DevOps teams

5. Ensure that Incident administration is automated up to the RCA process

 © 2019 SPLUNK INC.

Intelligent routing of Episodes

Episodes to teams with no in between
 © 2019 SPLUNK INC.

Orchestration to the rescue!

For the things that are known…
 © 2019 SPLUNK INC.

Automate the simple, orchestrate the complex

Know what kind of task you’re dealing with

1. Automation is removing human intervention in singular tasks or functions

▪ Ticket Creation
▪ Adding a new cluster node
▪ Incident Notification

2. Orchestration schedules, integrates and validates automation tasks

▪ Network configuration
▪ OS configuration changes
▪ Container Orchestrations
 © 2019 SPLUNK INC.

Using Phantom for ITSI Episodes

Getting under the hood for a minute…
 © 2019 SPLUNK INC.

Incident Automation Flow

Bridging the gap between Ops responsibility and Pipeline Priority

Create/Update alerting
and agg policies for
known conditions in
ITSI

DevOps and SRE identify Send new/unknown

existing/creates new episodes to First
assets and actions in
Phantom, creates a Responders in
playbook for the incident VictorOps

​Title, 24pt ​Title, 24pt ​Title, 24pt ​Title, 24pt ​Title, 24pt

DevOps team SRE Team completes

documents and RCA and Post mortem
prioritizes bugs and of incident using ITSI
enhancements for and VictorOps
future deployment reporting
 © 2019 SPLUNK INC.

Velocity, Capacity and

staying Engineering
Focused
Turn your pipelines into hyperloops
 © 2019 SPLUNK INC.

Pipelines are…complicated
Monitor the changes and change the monitoring

1. Most organizations will have multiple CICD pipelines based on business unit,
stack, app, etc.

2. Not all pipelines will have the same capacity, velocity or success rate

3. There is likely to be a variety of deployment tools in use

4. What is being deployed directly impacts and is impacted by monitoring/alerting

 © 2019 SPLUNK INC.

Pipeline monitoring done right

Modules and apps for the whole picture
 © 2019 SPLUNK INC.

Using your deployments to change ITSI

Adjusting existing ITSI services

GET POST
Diff against objects in
/itoa_service/service?fields Are Dev, Test and Prod /maintenance_services_inte
applicable templates for Yes
='title,_key''&'filter='\{"title":” Active? rface and place service in
deployment
servicename”\}’ maintenence

No POST
/itoa_service/service?fields='title,_key''&'filter='\{"titl
e":”dev_servicename”\}’

Return failed message to

playbook

GET
/itoa_service/service?fields='title,_key''&'filter='\{"titl
POST
e":”dev_servicename”\}’
/itoa_service/base_service_templateservice?fields=
'title,_key''&'filter='\{"title":”template
name”\}$scheduled_job=‘\{sync now\}’

No Change Validated?
No

Yes

POST
Yes Change Validated? GET
/itoa_service/service?fields='title,_key''&'filter='\{"titl
/itoa_service/service/{dev service key}/templatize
e":”dev_servicename”\}’
 © 2019 SPLUNK INC.

Using your deployments to change ITSI

Adjusting existing ITSI services
Demo
 © 2019 SPLUNK INC.

Q&A
 © 2019 SPLUNK INC.

Thank
Q&A You!
Go to the .conf19 mobile app to
RATE THIS
SESSION