Lista di controllo della preparazione alla produzione

La traduzione dell'articolo è stata preparata appositamente per gli studenti del corso "Pratiche e strumenti DevOps", che inizia oggi!

Lista di controllo della preparazione alla produzione

Hai mai rilasciato un nuovo servizio in produzione? O forse sei stato coinvolto nel sostenere tali servizi? Se sì, cosa ti ha motivato? Cosa è bene per la produzione e cosa è male? Come si formano i nuovi membri del team sui rilasci o sulla manutenzione dei servizi esistenti.

La maggior parte delle aziende finisce per adottare approcci da “selvaggio West” quando si tratta di pratiche operative industriali. Ogni team decide i propri strumenti e le migliori pratiche attraverso prove ed errori. Ma questo spesso influisce non solo sul successo dei progetti, ma anche sugli ingegneri.

Prove ed errori creano un ambiente in cui sono comuni il puntare il dito e lo spostare la colpa. Con questo comportamento diventa sempre più difficile imparare dagli errori e non ripeterli più.

Organizzazioni di successo:

  • rendersi conto della necessità di linee guida per la produzione,
  • studiare le migliori pratiche,
  • avviare discussioni sui problemi di preparazione alla produzione durante lo sviluppo di nuovi sistemi o componenti,
  • garantire il rispetto delle regole di preparazione alla produzione.

La preparazione per la produzione include un processo di “revisione”. La revisione può assumere la forma di una lista di controllo o di una serie di domande. Le revisioni possono essere eseguite manualmente, automaticamente o entrambe. Invece di elenchi statici di requisiti, puoi creare modelli di liste di controllo che possono essere adattati a esigenze specifiche. In questo modo, agli ingegneri può essere data la possibilità di ereditare conoscenze e flessibilità sufficiente quando richiesto.

Quando verificare che un servizio sia pronto per la produzione?

È utile condurre un controllo di preparazione alla produzione non solo immediatamente prima del rilascio, ma anche quando lo si trasferisce a un altro team operativo o a un nuovo dipendente.

Controlla quando:

  • Stai rilasciando un nuovo servizio in produzione.
  • Trasferisci l'operazione del servizio di produzione a un altro team, come SRE.
  • Trasferisci la gestione del servizio di produzione a nuovi dipendenti.
  • Organizzare il supporto tecnico.

Lista di controllo della preparazione alla produzione

Qualche tempo fa, ad esempio, I pubblicato lista di controllo per testare la disponibilità per la produzione. Sebbene questo elenco abbia avuto origine dai clienti Google Cloud, sarà utile e applicabile al di fuori di Google Cloud.

Progettazione e sviluppo

  • Sviluppare un processo di compilazione ripetibile che non richieda l'accesso a servizi esterni e non dipenda dal guasto dei sistemi esterni.
  • Durante il periodo di progettazione e sviluppo, definisci e imposta gli SLO per i tuoi servizi.
  • Documentare le aspettative sulla disponibilità dei servizi esterni da cui dipendi.
  • Evita un singolo punto di errore rimuovendo le dipendenze su una singola risorsa globale. Replicare la risorsa o utilizzare un fallback quando la risorsa non è disponibile (ad esempio, un valore hardcoded).

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.
  • Una configurazione dinamica deve avere impostazioni di fallback nel caso in cui il servizio di configurazione non sia disponibile.
  • La configurazione dell'ambiente di sviluppo non deve essere correlata alla configurazione di produzione. In caso contrario, ciò potrebbe comportare l'accesso dall'ambiente di sviluppo ai servizi di produzione, il che potrebbe causare problemi di privacy e fuga di dati.
  • Documentare cosa può essere configurato dinamicamente e descrivere il comportamento di fallback se il sistema di consegna della configurazione non è disponibile.

Gestione dei rilasci

  • Documentare dettagliatamente il processo di rilascio. Descrivi in ​​che modo i rilasci influiscono sugli SLO (ad esempio, aumenti temporanei della latenza dovuti a errori di cache).
  • Documentare le versioni di Canary.
  • Sviluppare un piano di revisione del rilascio Canary e, se possibile, meccanismi di rollback automatici.
  • Assicurati che i rollback possano utilizzare gli stessi processi delle distribuzioni.

Osservabilità

  • Assicurarsi che venga raccolto l'insieme di parametri richiesti per lo SLO.
  • Assicurati di poter distinguere tra dati client e server. Questo è importante per individuare le cause dei malfunzionamenti.
  • Imposta avvisi per ridurre i costi di manodopera. Ad esempio, rimuovere gli avvisi causati da operazioni di routine.
  • Se utilizzi Stackdriver, includi le metriche della piattaforma GCP nelle tue dashboard. Configura avvisi per le dipendenze GCP.
  • Propagare sempre le tracce in entrata. Anche se non sei coinvolto nella traccia, ciò consentirà ai servizi di livello inferiore di eseguire il debug dei problemi in produzione.

Protezione e sicurezza

  • Assicurati che tutte le connessioni esterne siano crittografate.
  • Assicurati che i tuoi progetti di produzione abbiano la configurazione IAM corretta.
  • Utilizza le reti per isolare gruppi di istanze di macchine virtuali.
  • Utilizza una VPN per connetterti in modo sicuro alle reti remote.
  • Documentare e monitorare l'accesso degli utenti ai dati. Assicurarsi che tutti gli accessi degli utenti ai dati siano controllati e registrati.
  • Assicurarsi che gli endpoint di debug siano limitati dagli ACL.
  • Disinfetta l'input dell'utente. Configura i limiti delle dimensioni del payload per l'input dell'utente.
  • Assicurati che il tuo servizio possa bloccare selettivamente il traffico in entrata per i singoli utenti. Ciò bloccherà le violazioni senza influenzare gli altri utenti.
  • Evita endpoint esterni che avviano molte operazioni interne.

Pianificazione della capacità

  • Documenta la scalabilità del tuo servizio. Ad esempio: numero di utenti, dimensione del payload in entrata, numero di messaggi in entrata.
  • Documenta i requisiti delle risorse per il tuo servizio. Ad esempio: numero di istanze di macchine virtuali dedicate, numero di istanze di Spanner, hardware specializzato come GPU o TPU.
  • Limitazioni delle risorse del documento: tipo di risorsa, regione, ecc.
  • Documentare le restrizioni sulle quote per la creazione di nuove risorse. Ad esempio, limitando il numero di richieste API GCE se utilizzi l'API per creare nuove istanze.
  • Prendi in considerazione l'esecuzione di test di carico per analizzare il degrado delle prestazioni.

È tutto. Ci vediamo in classe!

Fonte: habr.com

Aggiungi un commento