Photo: Tony Webster (CC BY 2.0)
Job description
SREs build monitoring, logging, and alerting tools to catch problems before they become outages, automate deployment and scaling so fewer things require manual intervention, and lead the response when something does break, often on tight on-call rotations. After an incident, they write postmortems documenting what failed and how to prevent it from happening again, and maintain runbooks so other engineers can resolve common issues quickly. Outside of incidents, the role allows a lot of independent judgment on how to harden systems ahead of anticipated demand.
Pros
- Strong pay (up to $200k), with strong pay even at the entry level
- Blends software engineering and systems work, keeping the job technically varied
- Largely independent, self-directed work outside of active incidents, often remote-friendly
Cons
- Above-average hours (up to 50/week), often extended by on-call incident response
- On-call rotations mean outages can strike at any hour, including nights and weekends
- High-pressure incident response whenever customer-facing systems go down
A typical day
The morning starts with the dashboards and yesterday's error budgets: one service burned 30% of its monthly allowance in a single bad deploy, and the SRE's first meeting negotiates slowing that team's release pace — reliability is a feature with a budget, and the SRE is its accountant. Mid-morning is project work: automating away the toil of certificate renewals that paged someone twice last quarter, because the SRE creed is that humans shouldn't do what scripts can. At 2:14pm the pager fires — latency spiking in one region — and the SRE joins the incident bridge, reads the graphs, and coordinates the mitigation: fail traffic over first, find root causes after. The blameless postmortem gets scheduled before the adrenaline fades. The job is engineering calm into chaos.
Tasks at the job
- Build and maintain monitoring, logging, and alerting systems for production infrastructure.
- Automate deployment, scaling, and recovery of services to reduce manual intervention.
- Respond to incidents and outages, diagnosing root causes under time pressure.
- Write postmortems documenting what failed and how to prevent recurrence.
- Improve system reliability and capacity ahead of anticipated demand.
- Write and maintain runbooks so on-call engineers can resolve common issues quickly.
Workplace & working conditions
Work happens indoors at a desk, in an office or remote, centered on a computer and dashboards.
On-call rotations bring real time pressure during outages, when the stakes of a customer-facing system going down are high. Outside of incidents, the work allows for significant independent judgment on how to harden systems.
Education necessary or common
Bachelor's degree in computer science or a related field, or equivalent hands-on systems experience
Common college majors
Licenses & certifications
- AWS/GCP/Azure certifications
- CKA (Kubernetes, later)
- Linux certifications (LFCS/RHCSA)
Career path
Related fields
Courses to take
- AP Computer Science A — the software foundation
- AP Statistics — SLOs, percentiles, and capacity are statistics
- Physics — systems thinking under constraints
- AP Calculus — the engineering math base
- English — postmortems and runbooks are load-bearing writing
Clubs, activities & competitions
- Computer science club or hackathons
- CyberPatriot — systems under pressure
- Run a game server or homelab for friends — real uptime obligations teach fast
- Robotics team — debugging complex systems
First steps you can take now
- Set up a Linux server (old laptop or free cloud tier) and keep a service running on it
- Learn Git, the command line, and basic networking this semester
- Break your own server and practice diagnosing from logs
- Read Google's free SRE book online — the field's founding document
