Per fortuna, poiché l'ingegneria dell'affidabilità del sito si è sviluppata internamente in Google e solo di recente ha iniziato a farsi strada nella comunità più ampia, è abbastanza ben definita. Ciò che non è , tuttavia, sono le operazioni sul web (o "amministrazione dei sistemi" - come esempio della mancanza di chiarezza, le usi entrambe nella tua domanda). È difficile discutere le differenze tra due cose quando non sei del tutto sicuro di quale di esse sia.
Ma sono un tipo avventuroso, quindi ci proverò.
In negozi molto tradizionali, sviluppatori e amministratori di sistema sono molto contorti l'uno dall'altro. Gli sviluppatori creano un'app, quindi considerano il loro lavoro completo non appena il loro codice è stato impegnato. Gli amministratori di sistema prendono gli artefatti di compilazione (che potrebbero essere solo il codice, se è un linguaggio interpretato) e li distribuiscono ai server di produzione. È compito dei amministratori di sistema mantenere l'applicazione senza intoppi e in generale gestire l'ambiente di produzione. Tuttavia, spesso i problemi di prestazioni derivano da problemi di architettura nell'app; gli amministratori di sistema non hanno le conoscenze di programmazione per sapere cosa sta facendo l'app e gli sviluppatori non sanno come l'app agisce nella topologia di produzione con traffico di produzione, quindi nessuno è attrezzato da solo per risolvere il problema.
Inoltre, gli sviluppatori vengono generalmente valutati sulla velocità con cui possono produrre nuove funzionalità, mentre i amministratori di sistema vengono valutati sulla frequenza con cui l'app si interrompe nella produzione. Poiché il cambiamento è una delle principali cause di rottura, ciò mette in conflitto i due dipartimenti: una vecchia rivalità che danneggia il business e le persone coinvolte.
Ad un certo punto, alcune aziende incentrate sugli sviluppatori si sono così infastidite da questo che hanno iniziato a praticare "NoOps" - hanno eliminato i loro dipartimenti operativi e i blocchi stradali percepiti che ne derivavano. In realtà, ciò significa che gli sviluppatori hanno assunto ruoli operativi, ma hanno mantenuto i loro vecchi titoli.
In una discussione su NoOps , John Allspaw, allora vicepresidente delle operazioni tecniche di Etsy e redattore del rispettato libro delle operazioni Web , ha definito i ruoli di Etsy in questo modo:
Etsy Operations è responsabile di:
- Rispondere alle interruzioni, richiede una chiamata
- Soglia dei sistemi di allarme, progettazione
- Progettazione e revisione dell'architettura
- Raccolta di metriche di costruzione
- Configurazione dell'applicazione
- Sviluppo / gestione dell'infrastruttura
Lo sviluppo di Etsy è responsabile di:
- Rispondere alle interruzioni, richiede una chiamata
- Soglia dei sistemi di allarme, progettazione
- Progettazione e revisione dell'architettura
- Raccolta di metriche di costruzione
- Configurazione dell'applicazione
- Spedizione codice pubblico
Nessuna di queste liste è completa, sono sicuro che mi sto perdendo qualcosa. Mentre Etsy Ops ha apportato modifiche alle applicazioni rivolte alla produzione, sono poche ma reali (e talvolta piuttosto profonde). Mentre Etsy Dev apporta modifiche allo Chef, sono poche ma reali. Se c'è così tanta sovrapposizione nelle responsabilità, perché la differenza, potresti chiedere? Competenza e background nel dominio. Non molti sviluppatori hanno una profonda conoscenza di come funziona TCP slow start, ma Ops lo fa. Non molte operazioni operative hanno una conoscenza completa degli algoritmi di ordinamento o di pertinenza, ma Dev lo è. Ops ha anni di esperienza nella previsione dell'utilizzo rapido delle risorse con un'accuratezza accettabile, mentre Dev non lo fa. Lo sviluppatore potrebbe non essere a conoscenza dei pro e dei contro della distribuzione delle opzioni di carico di lavoro su tutti i livelli 1-7, forse solo a 7, Ops lo fa. La modellazione entità-relazione può diventare naturale per uno sviluppatore, potrebbe non essere operativa. Alla fine, entrambi scoprono soluzioni a varie forme di scenari di fallimento bizantini e modelli di resilienza, a tutti i livelli e livelli.
Nel suo mondo, sviluppatori e ingegneri operativi avevano competenze e responsabilità molto simili; dove differivano era nella loro competenza. Le loro diverse specialità li hanno incoraggiati a lavorare insieme per risolvere i problemi, e le loro abilità comuni a livello base hanno dato loro un linguaggio in cui farlo.
Questa è generalmente la definizione di operazioni web su cui approdo per la maggior parte dei casi. Quindi è quello con cui continueremo.
Allora, qual è l'ingegneria dell'affidabilità del sito?
Il libro SRE di Google si apre con una definizione di SRE ... e poi un altro ... e quindi passa un capitolo continuando a definire il ruolo e un intero libro che copre le specifiche. Anche se sviluppato in un'organizzazione, sembra difficile condensare il lavoro in un'unica definizione concordata.
Per cominciare, dobbiamo tornare indietro al 2003, quando Ben Traynor si unì a Google e fondò quello che divenne il primo team di ingegneria dell'affidabilità del sito. Ricordiamo che alcuni paragrafi fa eravamo all'inizio del 2010; ma nel 2003, l'industria era ancora piuttosto impostata sulla divisione sysadmin / sviluppatore come il modo naturale delle cose. Quindi, quando Ben dice che SRE sarebbe quello che succederebbe se un ingegnere del software creasse un team operativo, questa era una fusione molto più radicale dei due mondi di quanto sembri ora.
La definizione fornita nella prefazione sottolinea ciascuna delle tre parole singolarmente:
- Ingegneria : l'uso dei concetti di informatica e ingegneria per risolvere i problemi
- Affidabilità : attenzione a rendere i sistemi più scalabili, più affidabili e più efficienti
- Servizio - la successiva evoluzione del "sito", sottolineando che gli SRE sono responsabili dei servizi in rete
Il capitolo introduttivo elenca i principi dell'ingegneria dell'affidabilità del sito come:
- Garantire un'attenzione duratura all'ingegneria - adottare misure preventive per evitare pagine frequenti e altre "fatiche"
- Perseguire la massima velocità di modifica senza violare lo SLO di un servizio, un argomento che può facilmente avere una propria risposta di diverse centinaia di parole, ma riassunto approssimativamente come aiutare gli sviluppatori ad apportare modifiche, purché non causino troppi problemi
- Monitoraggio : avvisi automatici in caso di problemi
- Risposta di emergenza - sistemare le cose quando sono rotte
- Cambio gestione
- Pianificazione della capacità
- Approvvigionamento
- Efficienza e prestazioni - garantendo che un servizio funzioni a un livello previsto - il collo di bottiglia fa male agli utenti, ma l'eccesso di capacità costa denaro
Classificherei Site Reliability Engineering come un sottoinsieme specializzato di moderne operazioni Web. Un'organizzazione SRE si concentra fortemente sull'automazione di tutto , a un livello che è solo conveniente in aziende abbastanza grandi. Idee come i budget degli errori possono funzionare solo quando il tuo servizio ha molte, molte richieste, altrimenti perdi granularità (per un servizio più piccolo, un particolare errore potrebbe influire sullo 0-20% delle tue richieste, a seconda del minuto). Le aree correlate come la sicurezza sono assenti dalla definizione SRE perché le aziende abbastanza grandi da avere veri team SRE hanno team dedicati per la sicurezza.
Il programma SRE, come definito da Google, è un sito web sviluppato per le esigenze specifiche di Google e non necessariamente applicabile altrove.
Tuttavia, recentemente la tecnologia dell'affidabilità del sito si sta espandendo in un più ampio utilizzo del settore. Il mio attuale incarico è SRE, anche se lavoro in un'azienda molto più piccola e la descrizione del mio lavoro si adatta abbastanza bene alla definizione di Web op di Etsy del 2012 di John Allspaw. La mia teoria è che stiamo procedendo attraverso i titoli come una scorciatoia per sposare l'evoluzione di un singolo campo:
- Abbiamo iniziato come amministratori di sistema .
- Quindi quando i siti web sono diventati più "una cosa", le offerte di lavoro hanno iniziato a riferirsi agli ingegneri delle operazioni web per distinguere i amministratori di sistema specializzati nel web da quelli che gestivano anche l'IT generale dell'ufficio.
- Quindi DevOps avrebbe dovuto separare coloro che erano a proprio agio nell'usare la programmazione per ridurre il carico di lavoro delle operazioni sul web.
- Ma quando DevOps è stato confuso dalla mancanza di una definizione chiara , abbiamo adottato la progettazione dell'affidabilità del sito per specificare che siamo alla ricerca di persone che supportano i servizi di produzione di guardia.
Quindi qual è la differenza tra un amministratore di sistema e un SRE? L'anno in cui hanno ricevuto il titolo. Qual è la differenza tra operazioni tradizionali e ingegneria dell'affidabilità del sito? SRE è semplicemente l'attuale incarnazione di operazioni operative, utilizzando nuovi strumenti (ciao, contenitori!) E, man mano che i programmi in rete continuano a diventare più grandi e più importanti, una maggiore attenzione alle pratiche che consentono a un ingegnere di fare di più .