Risky Business

This presentation covers how to talk about risk in software with technical and non-technical stakeholders.

Presented at PDX DevOps 2018-02-28.

Transcript

2. Why talk about this? •I did not learn how to document risk until it became an engineering-wide initiative and I was forced to learn •Resilient systems are the outcome
4. What is risk? •What happens if component fails? •How does a failure of impact ? •What constitutes failure? •Lack of connectivity? •High latency?
5. Classify •Risk classification is based on 2 factors •Likelihood •Impact
6. Examples •One MySQL database •Server failure •Hardware/instance failure, RAID controller failure, etc. •Likelihood: Moderate •Impact: Severe •Data loss •Daily backups •Likelihood: Rare •Impact: Severe
7. Examples •Load balancer •Server failure •Bonded NIC •Failover is available •Likelihood: Rare •Impact: Moderate
8. Examples •Java application •Single JVM •Likelihood: High •Impact: Severe
9. Mitigate •Now that we’ve identified the risk, it’s time to mitigate it •How do we prioritize?
11. Mitigating •It takes a village •Risks will never go to zero (you probably don’t have the time to get them to zero anyway)
14. Getting Down to Business You are now speaking the lingua franca of business:
15. Getting Down to Business You are now speaking the lingua franca of business: spreadsheets
16. Weaponized Ops •List of work of things that are problematic right now that you can refer to when talking to teams or prioritizing your own work
17. Go forth and… •Identify risks •Document risks •Use your DevOps charm to work on solutions •Spreadsheet things
18. Thanks! @JesseDearing jessedearing 