Joining up Agile and ITIL for DevOps success

Joining up Agile and ITIL®

for DevOps success

In association with Unicom Seminars

Agile (Scrum), ITIL®, DevOpsAligning Scrum and ITIL®

Focus on feedbackPractical steps for Agile + ITIL®

Skelton ThatcherIntroduction and Services Overview

‘Cloud’ changes the way we mustdesign, deliver, and operate

our software systems

Changes for ‘cloud’

Agile, ITIL®, DevOpsAligning Agile and ITIL®


Terminology

Agile

AgileIterative, early delivery

Collaboration with stakeholdersRespond to changes“Working software”

Jeff Patton, agileproductdesign.com

Jeff Patton, agileproductdesign.com

ITIL®

ITIL®

A library of good practices for ITSMNot a prescriptive framework!

Continual improvementOngoing services, not finished s/w

ITIL® is a Registered Trade Mark of AXELOS Limited

DevOps

DevOpsPractices & approaches

Effective web-scale softwareThemes: Culture, Automation, Measurement, Sharing

Avoiding handover

Not DevOps:“Automation”

“Build & Release”“Infrastructure Development”

“System Administration”

DevOps“Highly effective, daily collaboration between

software developers and IT operations people to produce relevant, working systems” *

*also QA/Testing, IT Service Desk, Programme Management, Commercial, Marketing, etc.

Agile, ITIL®, DevOpsA shared focus on working software

Iterative improvementCollaboration



Aligning Agile and ITIL®

Feedback in Agile (Scrum)

Feedback in ITIL®

Agile and ITIL®



Focus on feedback

Feedback for improved control

Plan – Do – Check – Act

Agile and ITIL®

Mapping Agile & ITIL® to PDCA

DevOps feedback

Gene Kim, http://itrevolution.com/the-three-ways-principles-underpinning-devops/

DevOps feedback


DevOps feedback


Focus on feedbackFeedback is essential for effective software

Agile: feedback during devITIL®: feedback during operation

DevOps: feedback during dev and operation


Feedback loopsPractical steps for Agile + ITIL®

Practical steps for Agile + ITIL®


Run Book collaborationChoose tools that encourage collaboration

Test early for operational readinessSingle product backlog

Keep changes smallRotate people through Dev and Ops teams

Run Book / Ops Manual•Detailed description of how the system operates•Maintenance•Repair•Error recovery

Run Book / Ops Manual• 1 Table of Contents

• 2 System Overv iew • 2.1 Serv ice Overv iew• 2.2 Contr ibu t ing Appl ica t ions, Daemons, and Windows Serv ices• 2.3 Hours of Opera t ion• 2.4 Execut ion Des ign• 2.5 In f ras t ructure and Network Des ign• 2.6 Res i l i ence, Fau l t To le rance and High -Ava i lab i l i ty• 2.7 Throt t l i ng and Par t ia l Shutdown• 2.8 Requ i red Resources• 2.9 Expected Tra f f ic and Load

• 2.9 .1 Hot or Peak Per iods• 2.9.2 Warm Per iods• 2.9 .3 Cool or Qu ie t Per iods

• 2.10 Env i ronmenta l D i f fe rences• 2.11 Too ls

• 3 Secur i ty and Access Contro l

• 4 System Conf igurat ion • 4.1 Conf igura t ion Management

• 5 System Backup and Restore • 5.1 Backup Requ i rements

• 5.1 .1 Spec ia l F i l es

• 5.2 Backup Procedures• 5.3 Restore Procedures

• 6 Moni tor ing and Aler t ing • 6.1 Er ror Messages

• 6.2 Events• 6.3 Hea l th Checks• 6.4 Other Messages

• 7 Operat ional Tasks • 7.1 Deployment• 7.2 Batch Process ing• 7.3 Power Procedures• 7.4 Rout ine Checks

• 7.4 .1 Sys tem Rebu i l ds

• 7.5 Troubleshoot ing

• 8 Maintenance Tasks • 8.1 Ma in tenance Procedures

• 8.1.1 Patch ing • 8.1 .1 .1 No rma l C y c l e

• 8.1 .1 .2 Ze ro -D ay Vu l ne r ab i l i t i e s

• 8.1 .2 GMT/BST t ime changes• 8.1 .3 Cleardown Act i v i t i es

• 8.1 .3 .1 Log R o t a t i on

• 8.2 Test ing • 8.2 .1 Techn ica l Tes t ing• 8.2 .2 Pos t -Dep loymen t

• 9 Fai lure and Recovery Procedures • 9.1 Fa i lover• 9.2 Recovery• 9.3 Troubleshoot ing Fa i lover and Recovery

• 10 Contact Detai ls

Run Book / Ops Manual2.1 Service Overview2.2 Contributing Applications, Daemons, and Windows Services

2.3 Hours of Operation

2.4 Execution Design2.5 Infrastructure and Network Design

2.6 Resilience, Fault Tolerance and High-Availability

2.7 Throttling and Partial Shutdown

2.8 Required Resources

2.9 Expected Traffic and Load

Run Book collaboration•The Dev team is responsible for the first draft• “But I know nothing about Production!”•Encourages collaboration with Ops team

Run Book collaboration• It’s not about documentation!•A means to an end•Builds trust and understanding•Aim to throw it away when complete!•Automate more over time•See http://runbookcollab.info/





http://rashidkpc.github.io/Kibana/images/screenshots/searchss.png

“How does [the use of] this tool help people to collaborate*?”

* Work together, at the same keyboard/screen

‘How to choose tools for DevOps and Continuous Delivery’

http://bit.ly/ChooseDevOpsTools

‘DZone guide to Continuous Delivery 2014’

http://bit.ly/DZoneCDreport





Operational readiness•Network testing•Security testing•Performance testing•Auxiliary infrastructure testing:•Monitoring•Log aggregation

•… (see http://softwareoperability.com/)

Network testing• iTrinegy network emulators•Scripted setup and automated test runs•http://www.itrinegy.com/

•Saboteur: •Network fault injection tool•https://github.com/tomakehurst/saboteur

Security testing•Gauntlt: http://gauntlt.org/# nmap-simple.attack

Feature: simple nmap attack to check for open ports

Background:

Given "nmap" is installed

And the following profile:

| name | value |

| hostname | example.com |

Scenario: Check standard web ports

When I launch an "nmap" attack with:

"""

nmap -F <hostname>

"""

Then the output should match /80.tcp\s+open/

Then the output should not match:

"""

25\/tcp\s+open

"""

Deployment pipeline•Make operational testing visible





Single product backlog


Use ‘operational features’, not NFRs


Features





Keep changes small•Smaller changes are easier to comprehend*•People are fearful of large changes•Fear prevents clear thinking (psychology)•Small changes allow easier monitoring•Make changes monitorable

* There is also sound mathematics behind small change size





Rotate people through teams•Developers sitting with Ops people•Ops people sitting with developers•Sharing on-call duties•Learning about:•Version control•Logging•etc.


Collaborate on draft Run BooksFavour tools that enable real collaboration

Test for operability in a deployment pipelineUser-visible & operational features togetherMonitoring tools enable small changes oftenRotate people through Dev and Ops teams

Recapitulation

Agile, ITIL®, DevOpsComplementary, not conflicting

All use iterative improvementAll aim for working software

Agile, ITIL®, DevOpsFocus on feedback loops

Shorten the feedback cyclesEncourage collaboration

Agile, ITIL®, DevOpsPractical steps to join up:

Run Book collaborationChoose tools for collaboration

Test for operability up frontA single backlog for user-visible and operational features

Use monitoring to increase confidence in changesShare on-call responsibilities

Joining up Agile + ITIL®

for DevOps successSee Agile & ITIL® as complementary

Test early for operabilityCollaborate on operational features

Shorten feedback cyclesUse monitoring to increase confidence

Further readingAgile and ITIL: and how they integrate[BCS]

http://bit.ly/BCSAgileITIL

Best practice in the cloud [Axelos]

http://bit.ly/CloudITIL







Further readingBuild Quality Inbuildqualityin.com

Forewords by Dave Farley and Patrick Debois

Discount for webinar attendees!https://leanpub.com/buildqualityin/c/UnicomSeminars

http://bit.ly/BQIUnicomSeminars

Valid until 14th January 2015

Effective DevOps for Leadershalf-day seminar, run by Skelton Thatcher

Locations: London & Leeds

http://effectivedevops.com/

Promo code ‘UNICOM’ – 10% discount

Thank you!

http://skeltonthatcher.com/

[email protected]

@SkeltonThatcher

+44 (0)20 8242 4103

Software

Joining up Agile and ITIL for DevOps success