Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Fase 4: operare
Hai creato un'applicazione resiliente e l'hai testata. Ora è la realtà quotidiana a farla funzionare. Ma in una startup non puoi guardare tutte le operazioni e non dovresti provare a farlo. La chiave è stare attenti a ciò che conta senza fornire troppe metriche o sovraccaricare il team.
Inizia dal punto di vista del cliente. I canarini Amazon CloudWatch Synthetics agiscono come clienti automatizzati. Testano continuamente i percorsi degli utenti critici. Invitali ad accedere, a simulare acquisti utilizzando account di prova o ad accedere alle funzionalità chiave, soprattutto durante le ore più affollate. Questo ti aiuta a comprendere l'esperienza del cliente e a individuare i problemi prima che lo facciano gli utenti reali. Quando un canarino fallisce, sai subito che qualcosa non va dal punto di vista del cliente.
Costruisci su questa base con un monitoraggio mirato dell'infrastruttura di supporto. Quali segnali ti dicono che ci sono problemi? Amazon ti CloudWatch aiuta a creare dashboard che tengono traccia di questi segnali. Non limitarti a monitorare le metriche tecniche, ma collegale all'impatto aziendale. Ad esempio, un elevato utilizzo della CPU è importante, ma ciò è dovuto al fatto che potrebbe peggiorare l'esperienza del cliente che stai monitorando con Canaries.
Come approccio pratico, associa il monitoraggio ai percorsi dei clienti. Se utilizzi una piattaforma SaaS (Software as a Service), probabilmente ti interessano i tempi di risposta delle API, le percentuali di successo dell'autenticazione e la disponibilità delle funzionalità principali. Imposta avvisi che ti avvisino quando queste metriche variano. Tuttavia, sii selettivo. Ogni avviso dovrebbe richiedere un'azione. Se il tuo team inizia a ignorare gli avvisi perché «probabilmente non sono niente», significa che ne hai impostati troppi o stai monitorando le metriche sbagliate.
Indirizza questi avvisi tramite strumenti già utilizzati dal team. Se i tuoi tecnici utilizzano una particolare applicazione di messaggistica, invia gli avvisi lì. L'obiettivo è una rapida consapevolezza senza creare un nuovo processo. Quando viene attivato un avviso, il team deve sapere esattamente cosa significa e cosa fare al riguardo.
Mantieni la tua documentazione operativa snella e pratica. Archivia i runbook con il codice nel controllo delle versioni, ma ricorda che non sono romanzi. Quando qualcosa si rompe, il tuo team ha bisogno di misure chiare e attuabili. Ogni avviso deve essere collegato a un runbook corrispondente e ogni runbook deve rispondere a tre domande:
-
Cosa si è rotto?
-
Perché è importante?
-
Come posso risolvere il problema?
Implementa un semplice processo di gestione degli incidenti. Non sono necessari framework complessi, ma solo definizioni chiare di cosa costituisce un incidente e chi chiamare quando le cose si aggravano. Conserva i registri degli incidenti perché ti aiutano a migliorare la resilienza dell'applicazione.
La chiave è trovare il punto debole tra vigilanza e spese generali. Usa AWS gli strumenti per automatizzare ciò che puoi, concentrati sul monitoraggio delle metriche che influiscono sui clienti e mantieni i processi sufficientemente leggeri da evolversi man mano che cresci.
Il prossimo capitolo esplora come promuovere una mentalità di resilienza senza sacrificare la velocità e l'innovazione che rendono speciali le startup. In fin dei conti, la resilienza riguarda tanto le persone quanto la tecnologia.