SRE

SRE was founded by Google in 2003, with the core philosophy of applying software engineering methods to operations work.

SRE (Site Reliability Engineering) is an engineering practice proposed and popularized by Google, whose core idea is to solve operational problems using software engineering methods and to quantify system reliability as SLOs for continuous measurement.

AI agents are better suited to take on steps requiring dynamic judgment and fault tolerance, while stable, highly deterministic core assertions can retain traditional approaches.

Minions的分层恢复机制借鉴了分布式系统故障分类学（崩溃故障、遗漏故障、拜占庭故障）和SRE领域的工程实践

In the book 《SRE: How Google Runs Production Systems》, Google systematized metrics such as MTTR, MTTD, and MTBF.

MTTR is one of the four key DORA metrics, measuring the average time from failure occurrence to service recovery, including detection time, response time, diagnosis time, and repair time.

Postmortem (post-incident review document) follows the principle of "blameless postmortem" in SRE culture, focusing on system and process defects rather than assigning personal responsibility.

In SRE practice, a fix going live does not equal the end of an incident; an observation window is needed to confirm that SLIs such as error rates and latency percentiles have returned to normal ranges and remain stable for several minutes.

Cloud platforms and low-code tools are both packaging operations capabilities into built-in services, and the platform layer is absorbing more and more work that originally belonged to SRE.

On-call is a common rotation system in SRE/operations and infrastructure teams, and the on-call process generally includes steps such as acknowledgment, triage, escalation, and postmortem.

MTTR (mean time to recovery) is a core metric for measuring the efficiency of alert handling processes and is one of the most frequently cited KPIs in the SRE field.

MTTD (Mean Time to Detect / Diagnose) is a metric commonly used in the SRE and DevOps field, referring to the average time from when a problem occurs or a test failure is recorded to when an engineer clearly identifies the root cause.

SRE practice recommends moving renewal warnings to 7 to 14 days before the expiration date, and attaching context such as listing number, price, sales, and renewal history to make the alert actionable.

In DevOps and SRE scenarios, a single erroneous delete operation or a misjudged handling of an alert can lead to a production incident.

A medium-scale service can generate several GB to several TB of logs per day, of which the number of lines that truly indicate a failure or security incident is often less than one in ten thousand

DevOps leans more toward the integration of culture, processes, and engineering practices, emphasizing development-operations collaboration, CI/CD, automation, and rapid feedback; SRE (Site Reliability Engineering) leans more toward solving operations problems through software engineering methods, focusing on reliability, SLOs, and automation.

Manish believes AI cannot be avoided and should be treated as a tool for improving delivery speed and quality rather than as a competitor, and that DevOps and SRE are still currently directions with high demand and high pay.

Google SRE's statistical experience shows that about 70% of production incidents are triggered by some kind of change—new deployments, configuration pushes, dependency upgrades, and scaling policy adjustments all count.

A postmortem is a retrospective document written after failure recovery, usually including the failure timeline, scope of impact, root cause analysis, handling process and improvement items to prevent recurrence, emphasizing "focus on the issue, not the person".

In cross-national collaborative SRE scenarios, uniformly recording event timelines in UTC is an industry convention.