SRE: mercato

Posizione

un'offerta aperta che ha superato il controllo di qualità e indica almeno due tecnologie

Candidato osservato

un candidato il cui stack contiene questa tecnologia; un dato aggregato: nessun singolo record esce dal perimetro

Candidato abbinabile

non ancora conteggiato

Finestra

offerte aperte nel momento in cui è stato creato lo snapshot

Junior SRE è raro (ingresso tipico: DevOps Middle / Backend Middle + interesse per l'affidabilità). Il salto Junior → Middle: dopo la prima risoluzione di un incidente in produzione + la prima configurazione degli SLO per un servizio. Middle → Senior: responsabilità degli SLO multi-servizio + padronanza dell'on-call (responsabilità delle metriche Mean Time to Detect / Recovery) + programmazione per l'automazione a livello Backend Middle/Senior. Senior → Staff / Principal: strategia di affidabilità a livello di organizzazione + guida della cultura del production engineering + mentoring tecnico. Percorso di carriera: DevOps Middle (2-3 anni) → SRE Junior / Middle (1-2 anni) → Senior → oppure Staff / Principal SRE, Engineering Manager (SRE), passaggio a Backend Distributed Systems Senior, o specializzazione in Chaos Engineering o Performance Engineering.

La distinzione originale di Google (libro Site Reliability Engineering): il DevOps è una cultura / filosofia («abbattere i silos tra Dev e Ops»). L'SRE è un'implementazione concreta della filosofia DevOps tramite pratiche specifiche: SLI / SLO / error budget + riduzione del toil + automazione prima di tutto + 50% del tempo su lavoro ingegneristico rispetto a quello operativo + post-mortem senza colpe. SRE = «cosa succede quando chiedi a un ingegnere del software di progettare un team operativo». Realtà pratica 2026: 70% di sovrapposizione a livello di stack (entrambi usano K8s + Terraform + Prometheus + Grafana). Differenze osservabili nelle aziende di prodotto: 1) Profondità di programmazione: l'SRE scrive più strumenti personalizzati in Go / Python (logica di autoscaling, automazione dei deploy, algoritmi di capacity planning). Il DevOps Engineer più spesso configura strumenti esistenti. 2) Disciplina SLI / SLO: l'SRE è responsabile dell'architettura degli SLO (Pyrra / OpenSLO / Sloth), dell'applicazione della policy sull'error budget, di alert tarati sui burn rate degli SLO. Il DevOps spesso configura il monitoraggio senza SLO formali. 3) Padronanza della reperibilità: l'SRE è in turni di reperibilità regolari (24×7 per i servizi critici), più forte nel coordinamento degli incidenti + nella conduzione dei post-mortem. Il DevOps Engineer di solito è reperibile solo per il proprio prodotto. 4) Regola del 50% di ingegneria: policy di Google: un SRE non dovrebbe passare >50% del tempo in lavoro operativo, il resto è automazione ingegneristica. Il DevOps Engineer non ha un vincolo simile. 5) Teoria dei sistemi distribuiti: i colloqui SRE includono spesso teorema CAP / algoritmi di consenso / modelli di consistenza / analisi delle modalità di guasto. I colloqui DevOps sono più pratici, sugli strumenti. Nelle startup questa distinzione è spesso sfumata (una persona = sia DevOps sia SRE).

SLI (Service Level Indicator): una metrica misurabile della salute del servizio (disponibilità / latenza / tasso di errore / throughput). SLO (Service Level Objective): un valore obiettivo per un SLI (ad es. disponibilità del 99.9% su 30 giorni). SLA (Service Level Agreement): un impegno contrattuale verso i clienti (di solito più debole dello SLO, ad es. 99.5% se lo SLO è 99.9%, per mantenere un margine di sicurezza). Error budget = 100% − SLO. Se lo SLO è 99.9% su 30 giorni → error budget = 0.1% = 43 minuti di inattività al mese. Quando l'error budget si consuma rapidamente → bloccare i deploy di nuove funzionalità, concentrare il team sul lavoro di affidabilità. Quando l'error budget è in buona salute → rilasciare funzionalità in modo aggressivo. Impostazione pratica del framework (12 passi): 1) Individuare i percorsi utente critici rivolti ai clienti (CUJ). 2) Scegliere gli SLI per ogni CUJ (di solito disponibilità + latenza per i servizi sincroni, throughput + freschezza per quelli asincroni). 3) Scegliere l'obiettivo SLO iniziale (regola: leggermente al di sotto delle prestazioni attuali). 4) Impostare la misurazione degli SLI (Prometheus + Grafana o servizio gestito). 5) Configurare gli alert sul burn rate (multi-finestra: burn rapido 1h a 14.4× la velocità, burn lento 6h a 6× la velocità: la formula di Google). 6) Impostare gli SLO-as-code (Pyrra / OpenSLO / Sloth) per il controllo di versione. 7) Documentare la policy sull'error budget (cosa succede quando si esaurisce: blocco delle funzionalità? revisione degli incidenti?). 8) Revisione trimestrale degli SLO (aggiustamento dell'obiettivo in base alle prestazioni effettive + all'impatto sui clienti). 9) Tracciamento del toil + roadmap di riduzione (obiettivo: <50% del tempo sul toil). 10) Cultura dei post-mortem: senza colpe, focus sulle azioni da intraprendere. 11) Integrazione del chaos engineering (Gremlin / Chaos Mesh: testare prima gli SLO in caso di guasto). 12) Dashboard di fiducia per i clienti (pagina di stato pubblica: Statuspage / Atlassian / Better Uptime).

Linux / sistemi a fondo: processi, namespace, cgroup, reti (TCP/IP, DNS, bilanciamento del carico), debug delle prestazioni (strace / perf / eBPF). Stack di osservabilità: Prometheus + Grafana (PromQL a fondo), tracing distribuito (Tempo / Jaeger / OpenTelemetry), log (Loki / ELK), APM gestiti (Datadog / Grafana Cloud / Honeycomb): l'SRE «vede» il sistema attraverso le metriche. Pratica degli SLO: SLI / SLO / error budget (vedi la domanda dedicata), alert sul burn rate, SLO-as-code. Risposta agli incidenti + reperibilità: PagerDuty / Opsgenie, runbook, post-mortem senza colpe, valutazione della gravità. Kubernetes: operazioni di produzione (livello CKA): workload, reti, risoluzione dei problemi. IaC + automazione: Terraform / OpenTofu, Ansible; la competenza SRE chiave è ridurre il toil (lavoro manuale ripetitivo) tramite l'automazione, obiettivo <50% del tempo sul toil. CI/CD: deploy sicuri: canary, blue-green, progressive delivery, rollback. Programmazione: Python e / o Go a un livello da scrivere strumenti di automazione manutenibili, non «script». Sistemi distribuiti: modalità di guasto, retry / timeout / circuit breaker, idempotenza, consistenza: la base per capacity planning e DR. Chaos engineering: Gremlin / Chaos Mesh: verificare l'affidabilità prima dell'incidente. Il punto principale: l'SRE tratta l'affidabilità come un prodotto: la misura (SLO), automatizza la routine ed elimina sistematicamente le cause degli incidenti invece di spegnerli a mano. L'inglese è obbligatorio: la letteratura SRE (il libro SRE di Google) e la community sono anglofone.

Sì, il 41% delle offerte SRE è completamente da remoto o ibrido. Il lavoro SRE: cloud + dashboard di monitoraggio. Gli outsourcer: quasi sempre da remoto. Aziende di prodotto russe: ibrido o da remoto dopo il periodo di prova. Banche russe: ibrido/in sede per la compliance di sicurezza. Aziende tech internazionali: completamente da remoto come standard. Avvertenza specifica per gli SRE: la rotazione di reperibilità richiede internet affidabile + alimentazione di riserva + uno spazio tranquillo per le emergenze notturne. Alcune aziende richiedono una verifica della postazione di lavoro a casa prima di un'offerta SRE da remoto. Fuso orario: i ruoli SRE richiedono di solito una sovrapposizione con il fuso principale del team (le aziende statunitensi vogliono spesso 4+ ore di sovrapposizione con PT/ET). Hub per chi si trasferisce: Polonia / Germania / Canada / Serbia / Georgia. Inglese per il lavoro SRE internazionale da remoto: indispensabile (gestione degli incidenti su Zoom in inglese sotto stress).

Production Engineer (PE): il termine di Facebook / Meta per l'SRE. Stessa disciplina, responsabilità quasi identiche: focus su affidabilità + automazione + reperibilità + capacity planning + sistemi distribuiti. La differenza è storicamente filosofica: l'SRE di Google è «un ingegnere del software che si trova a fare operazioni», il PE di Facebook è «un ingegnere inserito in un team di prodotto per l'affidabilità». Nella pratica del 2026 si sovrappongono quasi del tutto. Altri titoli equivalenti: Reliability Engineer (LinkedIn), Infrastructure Engineer (spesso si sovrappone all'SRE), Production Operations Engineer (termine legacy). Come leggere gli annunci 2026: cerca i segnali nella JD: se cita «SLI/SLO», «error budget», «riduzione del toil», «50% del tempo in ingegneria», «post-mortem senza colpe», «turni di reperibilità», è un ruolo in stile SRE indipendentemente dal titolo. Se cita «configurazione CI/CD», «migrazione al cloud», «infrastructure as code» ma SENZA menzionare gli SLO, è DevOps generico.

Roadmap: 1) Base DevOps solida: padronanza di Linux + Docker + Kubernetes (CKA) + una piattaforma cloud a fondo + IaC (Terraform). Senza questa base non ha senso passare all'SRE. 2) Programmazione a livello Backend Middle: Go (lo standard per l'SRE: Kubernetes / Prometheus / la maggior parte degli strumenti SRE è in Go) o Python a fondo (analisi dei dati + scripting). Libri: "The Go Programming Language" di Donovan / Kernighan, "Fluent Python" di Ramalho. 3) Il libro di Google "Site Reliability Engineering" (PDF gratuito): da leggere assolutamente, due volte. 4) "The Site Reliability Workbook" di Google: complemento pratico (casi di studio + esercizi). 5) Padronanza di SLI / SLO: configura SLO-as-code (Sloth / Pyrra / OpenSLO) per un servizio reale, imposta alert sul burn rate (multi-finestra: veloce 1h 14.4×, lento 6h 6×). 6) Teoria dei sistemi distribuiti: teorema CAP, modelli di consistenza (linearizzabilità / sequenziale / causale / eventuale), consenso (basi di Paxos / Raft), analisi delle modalità di guasto. Libri: "Designing Data-Intensive Applications" di Martin Kleppmann (da leggere assolutamente 2026), "Database Internals" di Petrov. 7) Chaos engineering: Chaos Mesh / Gremlin / LitmusChaos. Imposta esperimenti di chaos sul tuo cluster K8s. Libro: "Chaos Engineering" di Nora Jones / Casey Rosenthal. 8) Padronanza del load testing: k6 (moderno, basato su JS, in crescita) o Gatling (DSL Scala) o Locust (Python). Imposta test di carico integrati nella CI. 9) Osservabilità in profondità: Prometheus avanzato (padronanza di PromQL + recording rule + federazione), Grafana avanzato (templating + alerting), Loki + Tempo + OpenTelemetry. Caso d'uso: tracing distribuito tra microservizi. 10) Formazione sulla risposta agli incidenti: basi dell'incident command, framework dei post-mortem senza colpe, comunicazione durante gli incidenti. Risorse: "Incident Response & Computer Forensics" di Luttgens / Pepe / Mandia, formazione di Google sulla gestione degli incidenti. 11) Progetto personale: deploy di un'app distribuita su K8s con configurazione SLO completa + esperimenti di chaos + simulazione della reperibilità. Documentalo come sistema pronto per la produzione. Corsi russi: Slurm SRE, Otus "SRE", Karpov.Courses SRE Track. Internazionale (EN): "Database Reliability Engineering" di Campbell / Majors, talk di USENIX SREcon (gratuiti su YouTube), Google Cloud SRE Certification Path. DevOps Middle + interesse → SRE Junior: 4-10 mesi (serve rafforzare la programmazione + la teoria dei sistemi distribuiti).

701 active open SRE positions — premium segment of the DevOps direction. Geography: the US, India, the UK. The real market is broader thanks to a huge international remote segment. Time to close a Senior SRE role — 6-12 weeks (longer than general DevOps due to rare-skill requirements: programming + distributed systems + on-call mastery combination).

Un Senior SRE gestisce l'intero ciclo dell'ingegneria dell'affidabilità + leadership tecnica. Programmazione a livello Backend Middle+: padronanza di Go (lo standard per l'automazione SRE) o Python a fondo, al livello di «saper scrivere logica di autoscaling / algoritmi di capacity planning / operator K8s personalizzati di qualità da produzione». Padronanza approfondita di Kubernetes: su scala di produzione (nodi), Operator (Kubebuilder / Operator SDK), CRD personalizzati, pattern di multi-tenancy. Teoria dei sistemi distribuiti: comprensione profonda del teorema CAP, modelli di consistenza (linearizzabilità / sequenziale / causale / eventuale), algoritmi di consenso (Paxos / Raft), tassonomia delle modalità di guasto, pattern di gestione delle partizioni di rete. Padronanza dell'osservabilità: Prometheus avanzato (padronanza di PromQL + recording rule + federazione + remote_write), Grafana avanzato (templating + trasformazioni + alerting), padronanza dell'integrazione di Loki + Tempo + OpenTelemetry, tracing distribuito tra i microservizi. Padronanza dell'architettura di SLI / SLO: SLO-as-code (Pyrra / OpenSLO / Sloth), progettazione della policy dell'error budget + automazione della sua applicazione, tuning degli alert sul burn rate multi-finestra (evitare l'alert fatigue). Padronanza dell'incident command: guidare la risposta agli incidenti sotto stress, facilitazione di post-mortem blameless, analisi dei fattori contribuenti (non della root cause: il pensiero moderno), prioritizzazione delle azioni. Padronanza del chaos engineering: Chaos Mesh / Gremlin / LitmusChaos: progettare esperimenti di chaos, facilitazione dei GameDay. Padronanza del capacity planning: metodologia dei test di carico (k6 / Gatling / Locust), modelli di previsione delle risorse, analisi del margine, gestione dei picchi di carico. Performance engineering: ottimizzazione guidata dal profiling (perf / bpftrace / flamegraph), diagnosi dei memory leak, tuning del GC, analisi delle prestazioni di rete. Service mesh a fondo: Istio / Linkerd / Cilium: gestione del traffico, policy di retry, circuit breaker, fault injection. System design per l'affidabilità: progettare alla lavagna l'alta affidabilità multi-regione e multi-AZ, pianificazione di RPO / RTO, strategie di DR, architettura a celle per limitare il raggio d'impatto. Soft skill: scrittura di ADR, comunicazione durante gli incidenti (aggiornamenti della status page + chiamate con gli stakeholder in crisi), disciplina nei turni di reperibilità, collaborazione tra team (Backend / DevOps / Platform / Security), mentoring degli SRE Middle. Inglese OBBLIGATORIO per Senior+: l'SRE lavora molto tra team + la community è anglofona (USENIX SREcon, paper).