Site Reliability (SRE): рынок

Вакансия

открытая вакансия, прошедшая гейт качества и содержащая не менее двух технологий

Наблюдаемый кандидат

кандидат, чей стек содержит эту технологию; агрегат, без единой записи наружу

Подходящий кандидат

пока не считается

Окно

открытые вакансии на момент сборки снимка

Google's original distinction (Site Reliability Engineering book): DevOps — culture / philosophy («break down silos между Dev и Ops»). SRE — concrete implementation of DevOps philosophy via specific practices: SLI / SLO / error budgets + toil reduction + automation-first + 50% time on engineering vs operational work + blameless post-mortems. SRE = «what happens when you ask a software engineer to design an operations team». Practical reality 2026: 70% overlap на stack-level (оба используют K8s + Terraform + Prometheus + Grafana). Отличия observable в продуктовых компаниях: 1) Programming depth — SRE пишет больше custom Go / Python tooling (autoscaling logic, deployment automation, capacity planning algorithms). DevOps Engineer чаще configures existing tools. 2) SLI / SLO discipline — SRE owns SLO architecture (Pyrra / OpenSLO / Sloth), error budget policy enforcement, alerting tuned против SLO burn rates. DevOps часто sets up monitoring без formal SLO. 3) On-call mastery — SRE на on-call rotation regular (24×7 для critical services), сильнее в incident command + post-mortem facilitation. DevOps Engineer обычно on-call для own product только. 4) 50% engineering rule — Google policy: SRE не должен spend >50% time на operational work, остальное — engineering automation. DevOps Engineer не имеет такого guard. 5) Distributed systems theory — SRE-interviews часто включают CAP theorem / consensus algorithms / consistency models / failure mode analysis. DevOps interviews — больше practical tooling. В стартапах эта differentiation often blurred (один человек = и DevOps и SRE).

SLI (Service Level Indicator) — measurable metric service health (availability / latency / error rate / throughput). SLO (Service Level Objective) — target value для SLI (например: 99.9% availability over 30 days). SLA (Service Level Agreement) — contractual commitment к customers (обычно weaker чем SLO, e.g. 99.5% если SLO 99.9%, чтобы был safety margin). Error budget = 100% - SLO. Если SLO 99.9% за 30 days → error budget = 0.1% = 43 minutes downtime/month. Когда error budget burning fast → freeze new feature deployments, focus team на reliability work. Когда error budget healthy → ship features aggressively. Practical framework setup (12 steps): 1) Identify customer-facing critical user journeys (CUJs). 2) Pick SLIs для каждого CUJ (типично availability + latency для синхронных, throughput + freshness для async). 3) Choose initial SLO target (rule: чуть менее чем current performance). 4) Set up SLI measurement (Prometheus + Grafana или managed). 5) Configure burn-rate alerts (multi-window: fast burn 1h 14.4× rate, slow burn 6h 6× rate — Google formula). 6) Setup SLO-as-code (Pyrra / OpenSLO / Sloth) для version-control. 7) Document error budget policy (что происходит при exhaustion — feature freeze? incident review?). 8) Quarterly SLO review (target adjustment based на actual performance + customer impact). 9) Toil tracking + reduction roadmap (target: <50% time on toil). 10) Post-mortem culture — blameless, focus на action items. 11) Chaos engineering integration (Gremlin / Chaos Mesh — pre-test SLO under failure). 12) Customer trust dashboard (public status page — Statuspage / Atlassian / Better Uptime).

Linux / systems deep: процессы, namespaces, cgroups, сети (TCP/IP, DNS, load balancing), performance debugging (strace / perf / eBPF). Observability stack: Prometheus + Grafana (PromQL deep), distributed tracing (Tempo / Jaeger / OpenTelemetry), logs (Loki / ELK), managed APM (Datadog / Grafana Cloud / Honeycomb) — SRE «видит» систему через метрики. SLO-практика: SLI / SLO / error budget (см. отдельный вопрос), burn-rate alerts, SLO-as-code. Incident response + on-call: PagerDuty / Opsgenie, runbooks, blameless post-mortems, оценка severity. Kubernetes: production-эксплуатация (CKA-уровень) — workloads, networking, troubleshooting. IaC + автоматизация: Terraform / OpenTofu, Ansible; ключевой навык SRE — сокращение toil (ручной повторяющейся работы) через автоматизацию, цель <50% времени на toil. CI/CD: безопасные деплои — canary, blue-green, progressive delivery, rollback. Programming: Python и / или Go на уровне написания поддерживаемых инструментов автоматизации, не «скриптов». Distributed systems: модели отказов, retry / timeout / circuit breaker, идемпотентность, consistency — фундамент для capacity planning и DR. Chaos engineering: Gremlin / Chaos Mesh — проверять надёжность до инцидента. Главное: SRE относится к надёжности как к продукту — измеряет (SLO), автоматизирует рутину и системно убирает причины инцидентов, а не тушит их вручную. Английский обязателен — вся SRE-литература (Google SRE book) и сообщество англоязычные.

Да, 45% SRE-вакансий — full-remote или гибрид. SRE work — cloud-based + monitoring dashboards. Аутсорсеры — почти всегда remote. Российские продуктовые — гибрид или remote после probation. Российские банки — гибрид/офис security compliance. Международные tech-companies — full-remote standard. Caveat для SRE specifically: on-call rotation — нужна reliable internet + power backup + quiet space для night-emergency response. Some companies требуют home-office setup audit перед remote SRE offer. Time zone — SRE-roles обычно требуют overlap с team primary timezone (US-companies often want 4+ hours overlap с PT/ET). Релокант-хабы: Польша / Германия / Канада / Сербия / Грузия. Английский для international SRE-remote — must (incident command on Zoom in English под stress).

Production Engineer (PE) — Facebook / Meta'овский term для SRE. Same discipline, almost identical responsibilities — focus reliability + automation + on-call + capacity planning + distributed systems. Difference исторически philosophical: Google SRE — "software engineer who happens to do ops", Facebook PE — "engineer embedded в product team for reliability". На практике 2026 — почти полностью overlapping. Other equivalent titles: Reliability Engineer (LinkedIn), Infrastructure Engineer (часто overlap с SRE), Production Operations Engineer (legacy term). How to read job postings 2026: ищи signals в JD — если упоминается «SLI/SLO», «error budgets», «toil reduction», «50% engineering time», «blameless post-mortems», «on-call rotation» — это SRE-style роль независимо от title. Если упоминается «CI/CD setup», «cloud migration», «infrastructure as code», но БЕЗ SLO mentions — это general DevOps.

Roadmap: 1) DevOps base solid — Linux mastery + Docker + Kubernetes (CKA) + cloud platform deeply + IaC (Terraform). Без этого base нет смысла идти в SRE. 2) Programming Backend Middle level — Go (standard для SRE — Kubernetes / Prometheus / большинство SRE-tooling на Go) или Python deep (data analysis + scripting). Книги: «The Go Programming Language» Donovan / Kernighan, «Fluent Python» Ramalho. 3) «Site Reliability Engineering» Google book (free PDF) — must-read, читать дважды. 4) «The Site Reliability Workbook» Google — practical complement (case studies + exercises). 5) SLI / SLO mastery — настроить SLO-as-code (Sloth / Pyrra / OpenSLO) для real service, configure burn-rate alerts (multi-window: fast 1h 14.4×, slow 6h 6×). 6) Distributed systems theory — CAP theorem, consistency models (linearizability / sequential / causal / eventual), consensus (Paxos / Raft basics), failure mode analysis. Книги: «Designing Data-Intensive Applications» Martin Kleppmann (must-read 2026), «Database Internals» Petrov. 7) Chaos engineering — Chaos Mesh / Gremlin / LitmusChaos. Set up chaos experiments на own K8s cluster. Книга: «Chaos Engineering» Nora Jones / Casey Rosenthal. 8) Load testing mastery — k6 (modern JS-based, rising) или Gatling (Scala DSL) или Locust (Python). Set up load tests integrated в CI. 9) Observability deep: Prometheus advanced (PromQL mastery + recording rules + federation), Grafana advanced (templating + alerting), Loki + Tempo + OpenTelemetry. Use case: distributed tracing across microservices. 10) Incident response training — incident command basics, blameless post-mortems framework, communication during incidents. Resources: «Incident Response & Computer Forensics» Luttgens / Pepe / Mandia, Google's incident management training. 11) Pet-проект: deploy distributed app на K8s с full SLO setup + chaos experiments + on-call simulation. Document как production-ready system. Курсы РФ: Slurm SRE, Otus «SRE», Karpov.Courses SRE Track. International (eng): «Database Reliability Engineering» Campbell / Majors, USENIX SREcon talks (free YouTube), Google Cloud SRE Certification Path. DevOps Middle + interest → SRE Junior — 4-10 месяцев (нужно усилить programming + distributed systems theory).

610 активных открытых SRE-вакансий — premium-сегмент DevOps-направления. География: 🇷🇺 Россия / 🇵🇱 Польша / remote. Реальный рынок шире за счёт международного remote-сегмента. Время закрытия Senior SRE — 6-12 недель (longer чем general DevOps за счёт rare-skill требований: programming + distributed systems + on-call mastery combination).

Senior SRE владеет полным циклом reliability engineering + technical leadership. Programming Backend Middle+ level: Go mastery (standard для SRE-automation) или Python deep — на уровне «can write production-grade autoscaling logic / capacity planning algorithms / custom K8s operators». Kubernetes mastery deep: production-scale (nodes), Operators (Kubebuilder / Operator SDK), custom CRDs, multi-tenancy patterns. Distributed systems theory: CAP theorem deep understanding, consistency models (linearizability / sequential / causal / eventual), consensus algorithms (Paxos / Raft), failure mode taxonomy, network partition handling patterns. Observability mastery: Prometheus advanced (PromQL mastery + recording rules + federation + remote_write), Grafana advanced (templating + transformations + alerting), Loki + Tempo + OpenTelemetry integration mastery, distributed tracing across microservices. SLI / SLO architecture mastery: SLO-as-code (Pyrra / OpenSLO / Sloth), error budget policy design + enforcement automation, multi-window burn-rate alert tuning (avoid alert fatigue). Incident command mastery: lead incident response under stress, blameless post-mortem facilitation, contributing factors analysis (не root cause — modern thinking), action items prioritization. Chaos engineering mastery: Chaos Mesh / Gremlin / LitmusChaos — design chaos experiments, GameDay facilitation. Capacity planning mastery: load testing methodology (k6 / Gatling / Locust), resource forecasting models, headroom analysis, peak-load handling. Performance engineering: profile-driven optimization (perf / bpftrace / flamegraphs), memory leak diagnosis, GC tuning, network performance analysis. Service mesh deep: Istio / Linkerd / Cilium — traffic management, retry policies, circuit breakers, fault injection. System design для reliability: design multi-region multi-AZ HA на whiteboard, RPO / RTO планирование, DR strategies, cell-based architecture для blast radius limitation. Soft: ADRs writing, incident communications (status page updates + stakeholder calls в crisis), on-call rotation discipline, cross-team collaboration (Backend / DevOps / Platform / Security teams), mentoring Middle SRE. Английский для Senior+ MUST — SRE интенсивно cross-team + community англоязычная (USENIX SREcon, papers).