Many engineering and operations teams would like to move to a Service Ownership: "You build it, you own it" operating model. However, as with many ancillary objectives driving DevOps across an organization, this is easier said than done. Often this is because teams lack the human-to-technology mechanisms that allow for a culture of service ownership. Within the context of incident response, teams need to be able to clearly define who is responsible for tending to issues, how they're notified, and who to lean on for help. This is true for non-incident response scenarios too. How can teams operate at a fast pace and at a large scale, while still maintaining valid and safe service ownership? One of the keys to allowing for service ownership outside of incident response is by imbuing an organization with a culture of self-service operations. This is where a service owner builds and delegates self-service mechanisms for end-users (non service owners) to make use of a given service safer while also reducing the number of interruptions to the service creator/owner. In this webinar, you'll learn: How self-service helps organizations adopt a ‘You Build it, You Own it’ model Necessary mechanisms for service owners to create self-service interfaces to address the needs of their service-users How to apply self-service while continuing to maintain security and compliance standards How to allow developers and SREs to safely delegate automation as self-service requests to other teams and IT users Help developers regain productivity and quality of life by doing what they do best: coding

1. Proprietary & Confidential
Service Ownership with
PagerDuty & Rundeck.
Help others help you.
Jake Cohen
Sr. Solutions Consultant - Rundeck

2. Proprietary & Confidential
A culture and operating model where the people
writing the code for a service own it in production
You Build It. You Run it.
What does it mean to “own a service?”
What does this operating model look like in practice?

3. How do you “own” a service?
Development
● New features
● Testing
● CI pipelines
Deployment
● Push Deployments
● Manage data
● Manage configuration
Production support
● Meet SLAs
● Urgent incidents
● Important tasks

4. Service Ownership in Incident Response
Rotation of on-call developers. Ops engineers are first-responders
and escalate to developers.
Developers always paged for their
specific service.

5. PagerDuty allows for all variations of
incident response operating models.

6. Incidents still escalate.
Not everyone knows your service the way you do.

7. Incidents
Other Ops
Work
Provisioning,
Maintenance,
Environment
Management,
Capacity
Management,
Performance Tuning,
Reporting, etc.
Non-incident
tasks.
Feature
development
Incidents are just a portion of Service Ownership.
How can we reduce interruptions and escalations?

8. Reduce escalations with docs.
Not always utilized.
Not everyone has expertise to follow.
Not everyone has (safe) access to
execute.

9. Runbook Automation:
Equip others with your expertise.
1.
2.
3.
4.
5.
6.
7.
8. ….
>_
Service owners author workflows.

10. Standardize. Secure. Distribute.
1.
2.
3.
4.
5.
6.
7.
>_

11. What does this look like in practice?
Demo

12. eCommerce Platform Microservices Architecture
Tags showcase SLA priorities for each service.
99.xxx
99.xxx
99.xxx
99.x
99.x
99.x
99.xxx
99.x
99.x
99.x
99.x

13. A few of our Service Owners
Alice
Paul Carl
Rachel
Charlie

14. Service Owners - On Call Scenario
Paul
3rd-Party
Services
Rachel

15. eCommerce Platform on K8s
Metrics, Traces,
Logs, Synthetics...
PagerDuty filters noise and
notifies correct responder
Rundeck automates Service-owner’s
expertise to enable others to assist.

16. Schedule a demo:
● Rundeck.com/see-demo

17. Thank you!

18. Under the hood with Rundeck.
Webhooks allow for secure, standard invocation.
Rundeck jobs tie various programmatic mechanisms
together for fully automated workflows

19. Runbook Automation
Demo

20. Standardize. Secure. Distribute.
1.
2.
3.
4.
5.
6.
7.
>_

21. 1. Account Manager asks
that Customer’s portal is
changed.
2. Ops engineer can either assign
request to the Service Owner.
Or they can fulfill the request on their
own...
3. Service Owner has provided their
specialized knowledge within Rundeck so
that any ops engineer can fulfill these
requests.
Standardize. Secure. Distribute.

22. 1. User submits request
to pull information about
Polling App customer’s
portal.
2. Ops engineer reviews request and
approves request.
3. From Jira, they invoke an
automated-runbook to pull requested
info into Jira.
4. Jira triggers Rundeck job via webhook.
5. Rundeck pulls information from varying
sources to pass requested information back
to Jira.
Standardize. Secure. Distribute.

23. Internal BI Tool Dashboard is Broken
Who should we call to fix it?
112
45 min
? ?
8 12 50
15 min 20 min 30 min
Zoom Group Chat
From Me to Everyone:
Where is the Expert?