La traduzione dell'articolo è stata preparata appositamente per gli studenti del corso , che inizia già oggi!
Hai mai lanciato un nuovo servizio in produzione? O forse ti sei occupato del supporto di servizi esistenti? Se sì, quali criteri hai seguito? Cosa è considerato positivo per la produzione e cosa è negativo? Come formi i nuovi membri del team sui rilasci o sul supporto dei servizi esistenti?
La maggior parte delle aziende adotta infine pratiche di “Far West” nell'industria. Ogni team, attraverso prove ed errori, determina in autonomia gli strumenti e le migliori pratiche da utilizzare. Tuttavia, questo influisce spesso non solo sul successo dei progetti, ma anche sugli ingegneri.
Il metodo delle prove e degli errori crea un ambiente in cui si diffonde la ricerca di colpevoli e il passaggio di responsabilità. Con questo comportamento diventa sempre più difficile imparare dagli errori e non ripeterli.
Le organizzazioni di successo:
- riconoscono la necessità di linee guida per la produzione,
- studiano le migliori pratiche,
- iniziano a discutere della prontezza al rilascio durante lo sviluppo di nuovi sistemi o componenti,
- garantiscono il rispetto delle norme di preparazione alla produzione.
La preparazione per la produzione include il processo di "revisione". La revisione può assumere la forma di una checklist o di un insieme di domande. Si può effettuare manualmente, automaticamente o in entrambi i modi. Invece di liste statiche di requisiti, si possono creare modelli di checklist che si adattano a esigenze specifiche. In questo modo, gli ingegneri hanno un modo per ereditare conoscenze e la flessibilità necessaria quando è richiesta.
Quando controllare il servizio per la prontezza alla produzione?
È utile effettuare un controllo della prontezza alla produzione non solo direttamente prima del rilascio, ma anche quando si trasferisce a un altro team di gestione o a un nuovo dipendente.
Effettuate il controllo quando:
- Rilasciate un nuovo servizio in produzione.
- Trasferite la gestione del servizio in produzione a un altro team, come SRE.
- Trasferite la gestione del servizio in produzione a nuovi dipendenti.
- Organizzate il supporto tecnico.
Checklist di verifica della prontezza alla produzione
Un po' di tempo fa, come esempio, ho realizzato una checklist di verifica della prontezza alla produzione. Anche se questo elenco è emerso durante il lavoro con clienti di Google Cloud, sarà utile e applicabile anche al di fuori di Google Cloud.
Progettazione e sviluppo
- Sviluppa un processo di build riproducibile che non richieda accesso a servizi esterni e non dipenda da guasti di sistemi esterni.
- Durante la progettazione e lo sviluppo, identifica e stabilisci SLO per i tuoi servizi.
- Documenta le aspettative riguardo alla disponibilità dei servizi esterni da cui dipendi.
- Evita un singolo punto di fallimento rimuovendo dipendenze da una singola risorsa globale. Replica la risorsa o utilizza un'alternativa in caso di indisponibilità della risorsa (ad esempio, un valore hard-coded).
Gestione della configurazione
- La configurazione statica, piccola e non segreta può essere passata tramite parametri della riga di comando. Per tutto il resto, utilizza i servizi di archiviazione della configurazione.
- La configurazione dinamica dovrebbe avere opzioni di riserva nel caso in cui il servizio di configurazione sia non disponibile.
- La configurazione dell'ambiente di sviluppo non dovrebbe essere collegata alla configurazione di produzione. Altrimenti, ciò potrebbe portare ad accessi dall'ambiente di sviluppo ai servizi di produzione, causando potenziali problemi di privacy e fuga di dati.
- Documenta tutto ciò che può essere configurato dinamicamente e descrivi il comportamento di fallback in caso di mancanza del sistema di consegna della configurazione.
Gestione delle release
- Documenta in dettaglio il processo di rilascio. Descrivi come i rilasci influenzano gli SLO (ad esempio, un temporaneo aumento della latenza a causa di errori di cache).
- Documenta i rilasci canary.
- Sviluppa un piano per l'analisi dei rilasci canary e, se possibile, implementa meccanismi di rollback automatico.
- Assicurati che i rollback possano utilizzare gli stessi processi previsti per il deployment.
Idoneità al monitoraggio (Observability)
- Assicurati che venga raccolto un set di metriche necessario per gli SLO.
- Assicurati di poter distinguere tra i dati client e server. Questo è importante per la diagnosi dei guasti.
- Configura avvisi per ridurre il lavoro manuale. Ad esempio, elimina gli avvisi generati da operazioni di routine.
- Se utilizzi Stackdriver, abilita le metriche della piattaforma GCP nei tuoi cruscotti. Configura avvisi per le dipendenze di GCP.
- Diffondi sempre il tracciamento delle richieste in ingresso. Anche se non partecipi al tracciamento, questo permette ai servizi di livello inferiore di risolvere i problemi in produzione.
Protezione e sicurezza
- Assicurati che tutte le connessioni esterne siano criptate.
- Verifica che i tuoi progetti in produzione abbiano una corretta configurazione IAM.
- Utilizza le reti per isolare i gruppi di istanze di macchine virtuali.
- Usa una VPN per connetterti in modo sicuro a reti remote.
- Documenta e monitora l'accesso degli utenti ai dati. Assicurati che tutti gli accessi degli utenti ai dati siano controllati e registrati.
- Assicurati che le endpoint per il debug siano limitate dalle ACL.
- Sanitizza l'input degli utenti. Imposta limiti di dimensione per i payload dell'input utente.
- Assicurati che il tuo servizio possa bloccare selettivamente il traffico in ingresso per utenti specifici. Questo consente di bloccare le violazioni senza influenzare altri utenti.
- Evita endpoint esterni che innescano un elevato numero di operazioni interne.
Pianificazione delle capacità
- Documenta come si scala il tuo servizio. Ad esempio: numero di utenti, dimensione del carico utile in entrata, numero di messaggi in entrata.
- Documenta i requisiti di risorse per il tuo servizio. Ad esempio: numero di istanze di macchine virtuali assegnate, numero di istanze Spanner, apparecchiature specializzate come GPU o TPU.
- Documenta le limitazioni delle risorse: tipo di risorsa, regione, ecc.
- Documenta i limiti delle quote per la creazione di nuove risorse. Ad esempio, un limite sul numero di richieste all'API GCE se utilizzi l'API per creare nuove istanze.
- Considera di eseguire test di carico per analizzare la degradazione delle prestazioni.
Ecco tutto. Ci vediamo in aula!
Fonte: habr.com
