
Sign up to save your podcasts
Or


Chris Riley (@hoardinginfo, DevOps Advocate, @Splunk) talks about the state of DevOps, the evolution of Incident Response with Machine Learning, Service vs. Site Reliability, and using Incident Response to increase quality of development
SHOW: 439
SHOW SPONSOR LINKS:
CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotw
SHOW NOTES:
Topic 1 - Welcome to the show. Tell everyone a little about yourself, you’ve been active in the DevOps space for quite some time.
Topic 2 - About a year ago we had your peer and good friend of the show, Josh Atwell, on to talk about the State of DevOps in 2019. What are your thoughts on changes over the last 12 months and where we headed in 2020?
Topic 3 - One item in particular that has drawn my attention is your discussions on Incident Response and Machine Learning. Can you tell everyone a little bit about that and why you believe it will be valuable going forward?
Topic 4 - This in a way feels almost like a transition into the next evolution of our model. First we had separate dev and ops and no one talked, then we put them together, then we had every device and app start spitting out logs and alerts and next thing you knew, we were drowning in data… The complexity of the systems has grown exponentially. Fair?
Topic 5 - You recently did a post over on the Victor Ops blog about SRE and the meaning of the “S” in that blog. You propose more and more it should stand for Service Reliability Engineer vs. the more traditional Site Reliability Engineer, especially as we move into a subscription based model world. Can you explain to everyone your thoughts there?
Topic 6 - When I think Incident Response, I think production environments. As part of VictorOps I’m sure you see a lot of use cases and have solved some pretty unique customer problems. How can this be applied outside of production, say for application testing or quality before hitting production? Is that a valid approach?
FEEDBACK?
By Massive Studios4.6
147147 ratings
Chris Riley (@hoardinginfo, DevOps Advocate, @Splunk) talks about the state of DevOps, the evolution of Incident Response with Machine Learning, Service vs. Site Reliability, and using Incident Response to increase quality of development
SHOW: 439
SHOW SPONSOR LINKS:
CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotw
SHOW NOTES:
Topic 1 - Welcome to the show. Tell everyone a little about yourself, you’ve been active in the DevOps space for quite some time.
Topic 2 - About a year ago we had your peer and good friend of the show, Josh Atwell, on to talk about the State of DevOps in 2019. What are your thoughts on changes over the last 12 months and where we headed in 2020?
Topic 3 - One item in particular that has drawn my attention is your discussions on Incident Response and Machine Learning. Can you tell everyone a little bit about that and why you believe it will be valuable going forward?
Topic 4 - This in a way feels almost like a transition into the next evolution of our model. First we had separate dev and ops and no one talked, then we put them together, then we had every device and app start spitting out logs and alerts and next thing you knew, we were drowning in data… The complexity of the systems has grown exponentially. Fair?
Topic 5 - You recently did a post over on the Victor Ops blog about SRE and the meaning of the “S” in that blog. You propose more and more it should stand for Service Reliability Engineer vs. the more traditional Site Reliability Engineer, especially as we move into a subscription based model world. Can you explain to everyone your thoughts there?
Topic 6 - When I think Incident Response, I think production environments. As part of VictorOps I’m sure you see a lot of use cases and have solved some pretty unique customer problems. How can this be applied outside of production, say for application testing or quality before hitting production? Is that a valid approach?
FEEDBACK?

289 Listeners

1,093 Listeners

623 Listeners

583 Listeners

288 Listeners

302 Listeners

334 Listeners

961 Listeners

203 Listeners

205 Listeners

141 Listeners

500 Listeners

228 Listeners

36 Listeners

71 Listeners