Let's be honest, nobody loves surveys. Ok, well I sure don't. But surveys satisfy a huge need in our demand for insights into complex human-computer, sociotechnical systems. It turns out that we've been measuring the computer part pretty well, but the humans – not as easy to keep track of. When Google SRE first defined toil as a metric we wanted to reduce, we spent far too long trying to quantify it numerically based on tooling and insights from computer systems.

In this podcast, our panellists discuss the foundations that any team needs to put in place when designing their incident management process. Starting from the basics of defining what we really mean by an incident, to how to set your severity levels, roles and statuses, Chris and Pete share their tips for building solid foundations to run your incidents.

As a former incident responder and now as a responder advocate for FireHydrant, I’ve seen the “build vs. buy” debate play out many times. In fact, I even supported the tool that former employers used for managing incidents for years before they decided to buy (more on that in a future blog post).

IT operations move fast. If you’re an ITOps leader, you need to be moving just as fast to make sure your team has what it needs. Positioning your team for success isn’t easy: complexity in IT is increasing every year and can reach a point where it exceeds a person’s capacity to keep pace. In the face of massive growth, ITOps teams can face major challenges with productivity, burnout and efficiency.

Good incident management is critical to the successful running of any business. Get it wrong, and you risk damaging customer trust, brand reputation and, above all, your bottom line. In this article we’ll give you a 101 on incident management: what is it, why does it matter, and how can you do it well?

Is your incident response held together by a thread? Are you manually recording incident updates in a shared doc? Do you struggle to juggle the incident management workload with your other responsibilities? Does everyone on-call report data the same way? These are all common problems faced by DevOps teams still relying on homegrown incident management tooling.

If you’re in IT, no doubt you’ve heard the age-old statistic that an average minute of downtime costs $5,600. It turns out that information is a bit outdated and does not reflect the real and nuanced costs of a modern IT outage. BigPanda suspected this and wanted to uncover the true numbers behind outage costs so ITOps can have a better understanding of costs, causes and “cures” of an IT outage.

‍ Service Level Management, or SLM, is defined as the process of negotiating Service Level Agreements and ensuring that they are met. ‍ Service Level Management is a fundamental part of SRE and DevOps. It encompasses the expectations and perceptions that both the business and the customer have about the service and its performance. Service level management will include existing and new services as they are added, with the service level agreements (SLAs) being modified accordingly.