Downloaded 15 times
Uploaded byMatthew Skelton
Software operability and run book collaboration London Feb 2014
This document provides a summary of a presentation on software operability, run book collaboration, and DevOps. The presentation covered several key topics: 1. Software operability - the properties that allow software systems to work well in production. Examples of operational criteria include deploying, monitoring, diagnosing issues. DevOps helps improve operability through better collaboration. 2. Run book collaboration - Using run books as a means for developers and operations teams to collaborate and improve their understanding of systems. This leads to fewer outages and reduced costs over time. 3. Making operability work - Teams must take operational considerations seriously from the start by prioritizing "operational features" and avoiding "on-call anti
More Related Content
Similar to Software operability and run book collaboration London Feb 2014
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Software operability and run book collaboration London Feb 2014
- 1. #unidevops Software Operability, Run BookCollaboration, and DevOps Matthew Skelton 27th February 2014 DevOps Summit, London, UK www.devopssummit.com @matthewpskelton softwareoperability.com
- 2. • Software Operability •Run Book Collaboration • Making Operability Work • Questions #unidevops Agenda
- 3. • Software systemssince 1998 • Continuous Delivery specialist, DevOps enthusiast, Operability nut • London Continuous Delivery meetup group - londoncd.org.uk • Experience DevOps workshops • PIPELINE Conference #unidevops Background
- 4.
- 5. • • • • Definitions Examples Why focus onoperability? How DevOps can help #unidevops Software Operability
- 6.
- 7. • Cognates: – Opera –Operate – Operational – Inter-operability #unidevops Etymology of Operability?
- 8.
- 9. • Operability: theproperties of a system which make it work well in Production #unidevops Software Operability
- 10.
- 11. • David Copeland(@davetron5000): “How your software runs in production is all that matters. The most amazing abstractions, cleanest code, or beautiful algorithms are meaningless if your code doesn’t run well on production.” • http://www.naildrivin5.com/blog/2013/06/16/production-is-all-that-matters.html #unidevops Software Operability
- 12.
- 13.
- 14. • Hooks (internalAPIs) for: – Logging – Monitoring – Diagnostics – Health checks – Data clear-down – Service / daemon / container control #unidevops Shaped by Operability
- 15. #unidevops Ops Folk areUsers Too!
- 16.
- 17. • Deploy morerapidly, frequently • High cost of Production outage • Systems now more complicated #unidevops Why focus on Operability?
- 18.
- 19.
- 20.
- 21.
- 22. • DevOps isone way to address poor operability • Improved collaboration and communication between Dev teams and Ops teams • Example: Run Book Collaboration #unidevops How DevOps can help
- 23.
- 24. • Feedback loopsand learning • What is a run book? • How can run book collaboration help operability? #unidevops Run Book Collaboration
- 25.
- 26.
- 27.
- 28. #unidevops Example • • 1 Table ofContents 2 System Overview – – – – – – – – – 2.1 Service Overview 2.2 Contributing Applications, Daemons, and Windows Services 2.3 Hours of Operation 2.4 Execution Design 2.5 Infrastructure and Network Design 2.6 Resilience, Fault Tolerance and HighAvailability 2.7 Throttling and Partial Shutdown 2.8 Required Resources 2.9 Expected Traffic and Load • • • 4.1 Configuration Management – – – • 7.5 Troubleshooting – 8.1 Maintenance Procedures 7 Operational Tasks • • 5.2 Backup Procedures 5.3 Restore Procedures – – 6.1 Error Messages 6.2 Events 6 Monitoring and Alerting 8.1.1 Patching – – • • – • – 8.1.3.1 Log Rotation 8.2.1 Technical Testing 8.2.2 Post-Deployment 9 Failure and Recovery Procedures – – – • 8.1.1.1 Normal Cycle 8.1.1.2 Zero-Day Vulnerabilities 8.1.2 GMT/BST time changes 8.1.3 Cleardown Activities 8.2 Testing • • 5 System Backup and Restore 5.1.1 Special Files 7.4.1 System Rebuilds 8 Maintenance Tasks • 5.1 Backup Requirements 3 Security and Access Control 4 System Configuration • 7.1 Deployment 7.2 Batch Processing 7.3 Power Procedures 7.4 Routine Checks – 2.10 Environmental Differences 2.11 Tools – • – – – – • 6.3 Health Checks 6.4 Other Messages 2.9.1 Hot or Peak Periods 2.9.2 Warm Periods 2.9.3 Cool or Quiet Periods – – • • – – 9.1 Failover 9.2 Recovery 9.3 Troubleshooting Failover and Recovery 10 Contact Details
- 29. #unidevops Example • • 1 Table ofContents 2 System Overview – 2.1 Service Overview – 2.2 Contributing Applications, Daemons, and Windows Services – 2.3 Hours of Operation – 2.4 Execution Design – 2.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 • • • • • • • • 3 Security and Access Control 4 System Configuration 5 System Backup and Restore 6 Monitoring and Alerting 7 Operational Tasks 8 Maintenance Tasks 9 Failure and Recovery Procedures 10 Contact Details
- 30. #unidevops Example 2.1 Service Overview 2.2Contributing Applications, Daemons, and Windows Services 2.3 Hours of Operation 2.4 Execution Design 2.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
- 31.
- 32.
- 33. • • • • • Better understanding Better cross-teamworking Reduction in operational problems Fewer outages Reduced long-term cost-ofownership #unidevops Outcomes
- 34. • • • • Focus on thecollaboration Run book is a means, not an end Throw it away when complete (?) Aim to automate more over time • See http://runbookcollab.info/ #unidevops Run Book as Collaboration
- 35.
- 36. • • • • • NFRs vs OperationalFeatures Budget changes Organisation changes Responsibility changes Avoid on-call anti-patterns #unidevops Making Operability Work
- 37.
- 38.
- 39. • Single productbacklog – End-user + Operational features – New features + bugs • Product Owner on call – Accountable for operational failures – Seriously! #unidevops Taking Operability Seriously
- 40.
- 41. • “What isyour budget code?” • Capex vs. Opex? • Remove budget barriers to regular, effective communication #unidevops Budget changes
- 42. #unidevops Niek Bartholomeus (@niekbartho)- http://niek.bartholomeus.be/ https://speakerdeck.com/niekbartho/self-organization-vs-global-optimization-a-comparison-betweentraditional-and-modern-organizations
- 43. • “I‟ll needto ask my manager first” • Lack of autonomy • Remove reporting barriers to regular, effective communication • More at http://bit.ly/DevOpsTopologies #unidevops Organisation changes
- 44. #unidevops “I just wantto write code”
- 45.
- 46.
- 47. • • • • • • Too much overtimepay Too little overtime pay Rota team too small No training in incident response No team ownership of product No team autonomy for changes #unidevops On-call Anti-Patterns
- 48. • Team memberswant to help make things better • Empowered to fix problems • Reduce the times they are woken up #unidevops On call - Goal
- 49. • • • • • Operational Features, not“NFRs” Sustainable collaboration Sensible, fair on-call rotas Over-compensate in time off Avoid burn-out #unidevops The operability of operability
- 50.
- 51. Making software systems workwell in Production #unidevops Software Operability
- 52. Shared focus on operability throughoutthe delivery cycle #unidevops Run Book Collaboration
- 53. Use DevOps team patternsfor sustainable operability #unidevops Making Operability Operable
- 54.
- 55. • Patterns for Performanceand Operability – Ford, Gileadi, Purba, Moerman • http://whoownsmyoperability.com/ – Recommended reading lists #unidevops Further Reading
- 56. • Release It! –Michael Nygard (@mnygard) • http://www.michaelnygard.com/ #unidevops Further Reading
- 57. • Software Operability– How to make software work well in Production – Due early late 2014 • Sign up at OperabilityBook.com • Discount code for DevOps Summit attendees #unidevops Operability Book
- 58. • A hands-onworkshop for DevOps culture • Forthcoming dates: – London: 28th February 2014 • http://experiencedevops.org/ #unidevops Experience DevOps
- 59. • • • • • • Continuous Delivery „Unconference‟ format Tuesday8th April 2014 London, UK http://pipelineconf.info/ @PipelineConf #unidevops PIPELINE
- 60.
- 61.
- 62.
- 63.
- 64.