Answer: SRE is a discipline that applies software engineering principles to operations and infrastructure challenges, building highly scalable and reliable software systems. SRE treats operations as a software problem.

Answer:

• SLI (Service Level Indicator): A quantitative measure of service performance (e.g., "The latency of successful HTTP requests is < 200ms").
• SLO (Service Level Objective): The target reliability target defined for the SLI (e.g., "99% of HTTP requests will meet the SLI over a rolling 30-day window").
• SLA (Service Level Agreement): The legal/commercial agreement with users defining the consequences if the SLO is not met (e.g., refunding fees if uptime drops below 99.9%).

Answer: An Error Budget is the allowable downtime or failure rate of an application, calculated as: $$\text{Error Budget} = 100% - \text{SLO}$$ For example, a 99.9% availability SLO yields a 0.1% error budget. The team can spend this budget on shipping updates, running experiments, or executing maintenance. If the budget is depleted, deployments are halted, and the team redirects focus entirely to stabilization.

Answer:

• MTTD (Mean Time to Detect): The average time it takes to detect a service disruption.
  • Reduction: Implement granular real-time alerting, log parsing engines, and trace visualizations.
• MTTR (Mean Time to Resolution/Recovery): The average time required to restore the system to full service after a disruption.
  • Reduction: Automate rollbacks, document runbooks, and design self-healing recovery processes.

Answer: Capacity Planning is the SRE practice of analyzing resource growth trends and application workloads over time to predict and provision the hardware, storage, and networking resources needed to prevent future service bottlenecks or budget overruns.

Answer: A Blameless Postmortem is a meeting and document hosted after an incident. It assumes that engineers make decisions with good intentions based on the information available at the time. Rather than finding a person to blame, the focus is entirely on identifying system vulnerabilities, understanding root causes, and creating action items to prevent recurrence.

Answer:

1. Detection: Alert triggers based on SLO breaches.
2. Triage: Assess severity and page the designated On-Call engineer.
3. Mitigation: Restore service immediately (e.g., rollback, restart, failover). Do not spend triage time debugging root causes.
4. Resolution: Apply permanent fixes to prevent future occurrences.
5. Postmortem: Document findings and establish follow-up action items.

Answer: Toil is operational work that is manual, repetitive, automatable, tactical, lacks long-term value, and scales linearly with service size (e.g., manually restarting a service daily). SRE targets keeping toil below 50% of engineer workloads, automating tasks using code and scripts to free up time for engineering projects.

Answer:

• Replace manual scripts with declarative orchestrators (Kubernetes, CronJobs).
• Implement self-healing tasks (kubelet auto-restarts, auto-scaling groups).
• Create automated API triggers instead of requesting manual server logins.