Storicamente c'è stata una tensione naturale tra le operazioni e gli sviluppatori. La missione delle operazioni è di mantenere i sistemi stabili e funzionanti. Per la maggior parte dei sistemi, se nulla cambia con il sistema, esso tenderà a comportarsi come in passato. Gli sviluppatori, tuttavia, sono tipicamente incentivati a far crescere l'uso del sistema, il che significa, che sia buono o cattivo, più funzionalità. Le nuove caratteristiche portano a rapidi cambiamenti nel sistema e un certo livello di instabilità e di rischio viene introdotto nel sistema. Questi incentivi opposti creano un'immensa tensione tra le due squadre. Questo si traduce in operazioni che rimuovono l'accesso alle macchine e quindi la libertà di fare qualsiasi operazione connessa. Questo mette fine a nuove idee come i microservizi all'interno dell'organizzazione perché le infrastrutture sono sempre necessarie per mettere in piedi nuovi servizi e nuove infrastrutture richiedono una profonda collaborazione con un altro team. Questa tensione non è buona e crea una divisione all'interno dei team di ingegneria che non porta a nessun progresso perché i due team si rifiutano di aiutarsi a vicenda. Questo non solo danneggia la produttività ma, in ultima analisi, anche la felicità dei vostri dipendenti, che cominceranno ad andarsene. Se c'è una cosa che ho imparato durante il mio mandato come capo ingegnere è questa: se vuoi che i tuoi dipendenti siano felici, devi assicurarti che siano produttivi. Felicità significa andare d'accordo con gli altri team di ingegneri e unificare la cultura contro la creazione di una cultura che crea divisioni.

"Con grande potere viene una grande responsabilità"

Come team siamo tutti responsabili del software che mettiamo in produzione, non solo degli operatori o degli sviluppatori. Questo significa che dobbiamo creare una struttura di incentivazione che dia sia alle operazioni che agli sviluppatori un obiettivo comune. Devops ha molti significati per diverse persone, ma per noi significa che c'è una forte sovrapposizione tra le aree funzionali di operazioni, sviluppo e QA. ShareThis Quindi, affinché gli sviluppatori possano ottenere il potere di apportare modifiche alla produzione, devono essere responsabili delle loro azioni. Questo è il motivo per cui crediamo che sia fondamentale che gli sviluppatori abbiano una rotazione di chiamata nel caso in cui qualcosa vada storto. Gli sviluppatori dovrebbero sperimentare cosa significa essere avvisati quando il loro codice causa problemi inaspettati. In questo modo si condivide l'onere di risolvere i problemi nelle ore di riposo di tutto il team e non solo sulle spalle delle operazioni o di un singolo team.

SLA e indennità SLA

Una delle attività più importanti è la definizione di uno SLA per i servizi. Questo definisce le aspettative di stabilità di un sistema per i clienti, gli sviluppatori e le operazioni. Ma l'obiettivo non dovrebbe mai essere quello di avere il 100% di uptime, perché potrebbe significare che ci si muove troppo lentamente e non si corre abbastanza rischi. Una startup è tutta una questione di prendere rischi calcolati e muoversi velocemente. Per essere più quantitativi sul rischio, usiamo le quote SLA. Possiamo calcolare la nostra tolleranza al rischio assumendo lo SLA e sottraendo 1. Quindi, se si dispone di uno SLA del 99,9% di uptime, possiamo calcolare una franchigia SLA con i seguenti valori 1 - 0,999 = .001 che è la nostra franchigia SLA. Ciò significa che il sito può avere 43m di tempo di inattività prima di aver esaurito il tempo di attività concordato. In questo modo, gli sviluppatori possono utilizzare il sito con la frequenza desiderata, a patto che non raggiungano il loro margine SLA. Una volta che lo fanno, non possono essere implementate nuove funzionalità e il team dovrebbe invece concentrarsi sulla stabilità. Questo pone l'accento su test e monitoraggio automatizzati per verificare che le loro applicazioni non causino problemi in produzione. Questo pone anche un sano equilibrio tra velocità e tolleranza al rischio che può essere concordato in anticipo. In tutto l'ufficio stiamo costruendo dei cruscotti in grado di mostrare rapidamente eventuali anomalie, in modo da poter annullare eventuali modifiche prima che causino violazioni dello SLA.

I risultati

Da quando lavoriamo nella cultura "DevOps" abbiamo assistito a un notevole aumento della collaborazione tra i team e anche a un aumento della produttività. La proprietà totale delle applicazioni, dallo sviluppo alla produzione, si è diffusa in tutto il team e ora siamo in grado di aumentare i server e l'infrastruttura in pochi secondi rispetto alle settimane. Per i nostri clienti questo significa nuove funzionalità e stabilità del servizio. Per i nostri interlocutori interni ciò significa tempistiche prevedibili. Ma soprattutto, per il nostro team, questi cambiamenti danno loro un senso di proprietà e di produttività.

Se questo tipo di ambiente di lavoro ti interessa, visita la nostra pagina delle opportunità:
https://sharethis.com/careers/