Operations | Monitoring | ITSM | DevOps | Cloud

In traditional IT environments, services to customers are delivered and supported by the organization. A Service Level Agreement (SLA) is created with details like what would be the availability of service be, how reliable the service would be, what penalties can be charged in case of downtime, etc. The internal teams like the network administration team, development team, IT service desk, etc. would then draw up Operational Level Agreements (OLAs) to support the SLA.

The Community and Advocacy Team here at PagerDuty recently spruced up our library of ops guides, and we’re excited to share them with you. If you’re not familiar with the ops guides, they are an open-sourced collection of long-form documents that cover a variety of topics related to real-time operations and incident management. We’ve given them some spiffy new headers, cleaned up some sneaky errors, and added a new section titled “Next Steps.”

We asked in a recent poll which popular TV show your IT team resembles the most. Big Brother came out on top, with almost 40% of respondents saying that their incident resolution process most resembled this show. Would you compare your incident management process to an episode of Big Brother? If so, it's likely that your IT environment is highly monitored, but incidents still seem to slip through the cracks.

SLA basically means a Service Level Agreement. It’s a formal agreement between you and your customer. It basically describes the reliability of your product/service so you can have a formal agreement which basically says our product will be online 99 percent of the time annually and if we fail to achieve that objective we will give 30% of your annual license fee back. SLA’s also include penalties in the contract.