DevOps is the work of keeping a running system understandable: releases that can be reversed, alerts that point at the user-facing path, and an on-call shift that leaves evidence behind.
03:00The page that wakes you up
An alert says the checkout error rate doubled. The first move is not to restart the service. Check the deploy history, the dependency status and the traffic pattern; separate the first symptom from the cascade it caused.
A restart can erase the evidence. Stabilise the user path first, then investigate.
10:00Releases and rollback
The morning release includes an API change and a database migration. The team deploys the backward-compatible part first, watches the error budget, then removes the old path only after the new one has run in production.
Every release needs a rollback that has been tried, not a sentence in a document. A migration that cannot be reversed needs a different plan before it runs.
14:00Observe the whole path
Dashboards are grouped by the user path rather than by server: request rate, latency, error rate and saturation from the edge through the API to the database. A green CPU graph does not prove the checkout works.
Logs use request identifiers, masked personal data and a retention period. The on-call engineer should be able to answer "what changed?" and "who is affected?" without opening five tools.
Production access is least-privilege; secrets are rotated; incident notes omit customer data. A recovery step that bypasses those rules is not a shortcut.
Read the safety thread17:00Safety is an operational property
Backups are tested, certificates and credentials expire on a schedule, and the runbook names the owner of each dependency. Security patches are part of release planning, not a separate project after launch.
After the incident, write the timeline and the follow-ups. The next on-call shift should inherit evidence, not a rumour.
After this day, what can you take away?
- Stabilise the user path before chasing the root cause.
- A rollback is part of the release, not an emergency improvisation.
- Observability is organised around the product, not the server list.
A day in the role
The work, step by step
01Make the failure visible
Check the alert, the dashboard and the deploy history before changing anything; separate the first symptom from the cascade it caused.
02Reduce the blast radius
Roll back or shift traffic to a healthy version, then confirm the user-facing path before fixing the root cause.
03Automate the repeatable part
Turn the manual recovery step into a tested runbook or pipeline change, with a dry run and a rollback path.
04Write the incident down
Record the timeline, the customer impact, the decision points and the follow-up owner so the next on-call starts from evidence.
Across the eras
Where this work appears in the timeline
- Connection Era
1969–1993
System administrators, managing machine rooms, accounts, tape backups, and network connectivity.
- Web
1994–2000
Network administrators and system administrators, managing server hosting, dial-up access, and mail servers.
- Community & Search Era
2001–2008
System administrators (SA) and database administrators (DBA), responsible for managing hundreds or thousands of servers, monitoring, and releases.
- Mobile Era
2009–2015
Shifts from manual operations toward automation and DevOps, and starts using cloud servers.
- Cloud & Intelligence Era
2016–2022
Setting SLOs, managing Kubernetes clusters, building monitoring and alerting, and running on-call and incident reviews. The ops role page at `/roles/devops/` marks the "Ops → SRE" evolution.
- Large Model Era
2023–present
LLMOps and GPU cluster operations, responsible for model versions and for the stability and cost of inference services.
Occupation records
Recognition, mappings and market data
The U.S. occupation system has no standalone DevOps code. Systems engineers and network and computer systems administrators are separate proxy occupations, so their figures are listed separately.
Occupation names and classifications
China · Official occupation listing · A
Cloud Computing Engineering Technician
Occupation listing · 2019.
人力资源社会保障部办公厅（中国政府网）China · Official occupation listing · A
Cloud-Network Intelligent O&M Operator
Occupation listing · 2024.
人力资源社会保障部（中国政府网转载）China · Occupation classification / mapping · A
IS O&M Engineering Technician
Classification code · 2-02-10-08.
中国就业网（人社部）United States · Occupation classification / mapping · A
Software Developers（报告职称含 DevOps Engineer）
O*NET / SOC classification · 1252.
O*NET OnLine（美国劳工部资助）
Pay, hiring and outlook indicators
United States · Proxy occupation · A
Computer Systems Engineers/Architects
Median annual pay： US$116,580
2025 median (P50) · USD/year
O*NET OnLine（美国劳工部资助） · 15-1299.08 Computer Systems Engineers/Architects
United States · Proxy occupation · A
Computer Systems Engineers/Architects
Projected growth / sample change： Faster than average (5% to 6%)
2025–2035 projected growth band
O*NET OnLine（美国劳工部资助） · 15-1299.08 Computer Systems Engineers/Architects
United States · Proxy occupation · A
Network and Computer Systems Administrators
Median annual pay： US$99,130
2025 median (P50) · USD/year
O*NET OnLine（美国劳工部资助） · 15-1244.00 Network and Computer Systems Administrators
United States · Proxy occupation · A
Network and Computer Systems Administrators
Projected growth / sample change： Decline (-1% or lower)
2025–2035 projected growth band
O*NET OnLine（美国劳工部资助） · 15-1244.00 Network and Computer Systems Administrators
Global · Proxy occupation · B
Devops Engineer
List position / share of job postings： #14
WEF Future of Jobs Report · 2025–2030 fastest net-growing roles list
Report list position; no in-chart percentage is shown.
World Economic Forum · The Future of Jobs Report 2025 (PDF)
Role record
History notes
These notes preserve the occupation names used by their sources. Era groupings and adjacent occupation names provide historical context; they do not mean those occupations are identical to this site’s role.
云工程师 · Cloud engineer
The role report lists “云工程师” (cloud engineer) in its 2008–2015 cloud-computing era. This is an era grouping, not an equivalent name for this site’s DevOps role or a verified first-appearance year.
云计算工程技术人员 · Cloud Computing Engineering Technician
The 2019 new-occupations notice lists “云计算工程技术人员” (Cloud Computing Engineering Technician). It is adjacent to infrastructure operations, but is not presented as identical to this site’s DevOps role.
云网智能运维员 · Cloud-Network Intelligent Operations Technician
The 2024 new-occupations list from three government departments includes “云网智能运维员” (Cloud-Network Intelligent Operations Technician). It is an official occupation-name milestone, not a synonym for every operations or DevOps role.
Related evidence · L1 · 7 papers
Contemporary research
These papers directly discuss responsibilities, skills, or tools relevant to the role. Topical relevance alone does not establish role history or replace employment and hiring data.
Market-Oriented Cloud Computing: Vision, Hype, and Reality for Delivering IT Services as Computing Utilities
Cloud resource management and SLA-aligned allocation are relevant to infrastructure operations.
Abstract“SLA-oriented resource allocation”
GridSim: A Toolkit for the Modeling and Simulation of Distributed Resource Management and Scheduling for Grid Computing
GridSim models distributed resource management and application scheduling.
Title“resource management and scheduling”
iFogSim: A Toolkit for Modeling and Simulation of Resource Management Techniques in Internet of Things, Edge and Fog Computing Environments
iFogSim models resource-management techniques.
Title“resource management techniques”
Modeling and Simulation of Scalable Cloud Computing Environments and the CloudSim Toolkit: Challenges and Opportunities
CloudSim evaluates resource-allocation policies and application-scheduling algorithms.
Abstract“resource allocation policies and application scheduling algorithms”
InterCloud: Utility-Oriented Federation of Cloud Computing Environments for Scaling of Application Services
Cloud-to-cloud load coordination and automatic service allocation.
Abstract“dynamically coordinating load distribution”
Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider
Serverless workload characteristics and resource-provisioning optimization.
Abstract“allocating and provisioning resources to the cloud provider”
An introduction to Docker for reproducible research, with examples from the R environment
Docker environments and reproducible research workflows.
Title“reproducible research”