The latest News and Information on Service Reliability Engineering and related technologies.
Site Reliability Engineering (SRE) is a practice for managing the reliability of systems that began at Google in the early 2000s. Ben Treynor Sloss from Google started the first SRE team and coined the name.
We recently released Catchpoint’s SRE Report 2020 that analyzed results from the SRE survey we conducted early this year along with a recent addendum survey. The report offers a detailed look at the current state of SRE and how the shift to an all-remote work environment has impacted SRE teams. In this blog, we take a deeper look at one of the report highlights – ‘Heavy Ops Workload Comes at a Cost’.
“Welcome to Tomorrowland.” That’s how Moogsoft Chairman and CEO Phil Tee kicked off the launch event of Moogsoft Express, the next-generation AIOps and observability solution built from the ground up for DevOps and SRE teams. The reference to a better future is fitting. With its arrival, Moogsoft Express helps these teams maintain visibility and control over increasingly complex CI/CD pipelines, so they can detect issues earlier, fix them faster and prevent outages.
Our 2020 SRE Report is ready! We launched the SRE survey 2020 this January with the goal of understanding the current state of SRE. The survey covered a range of topics including: As we neared the end of the survey period, the SRE community was in the midst of a sudden change. SRE teams were forced to migrate to all-remote IT. We realized we would not be able to provide an accurate analysis without considering this shift in how SRE teams were operating in this new environment.
It’s 3 AM and you are roused out of sleep by the dull buzzing of your phone in the other room. Some sort of emergency, you conclude as you fumble with the lockscreen. There it is: an alert that the API governing user registration is acting up. When we think about the lag between time of incident and time to respond, it’s not just about how long the system went down. How long it physically takes us to respond to the problem also contributes to lost downtime.
