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 2: implementare l'osservabilità
A questo punto, iniziate il processo con cui i vostri team procederanno in modo incrementale verso la stella polare.
Scegli la tua piattaforma di osservabilità
Il primo passo è identificare gli strumenti giusti per importare, visualizzare e analizzare i segnali e inviare avvisi. Quando scegli uno strumento, considera il set di funzionalità, il modello di licenza, il prezzo, i requisiti di competenze e la manutenzione.
Set di funzionalità
Ecco alcune delle domande da considerare:
-
Configurabilità e personalizzazione. Quali funzionalità offre lo strumento per semplificare l'esperienza investigativa e contribuire a ridurre l'MTTR? Lo strumento fornisce la correlazione degli allarmi, la matematica metrica, la flessibilità nella gestione della telemetria mancante o il rilevamento di anomalie?
-
Granularità. Qual è la granularità supportata per l'ingestione e la visualizzazione dei segnali di telemetria?
-
Personas. Lo strumento supporta le esperienze che desideri offrire ai tuoi sviluppatori, agli ingegneri della piattaforma e ad altre persone? Funziona sia per i professionisti tecnici che per quelli aziendali?
-
Widget. Quali tipi di widget sono supportati dai dashboard? Lo strumento consente la creazione di widget personalizzati?
-
Soluzioni predefinite. Quali tipi di soluzioni di osservabilità predefinite offre lo strumento per ridurre il time to value?
-
Automazione e intelligenza artificiale generativa. Quali funzionalità offre lo strumento che possono aiutare ad automatizzare o ridurre il lavoro per te e il tuo team? Ad esempio, il rilevamento automatico delle anomalie, l'analisi predittiva e altre funzionalità di intelligenza artificiale generativa possono aiutare a ridurre lo stress causato da ipotesi e incognite sconosciute (ovvero cose di cui non sei a conoscenza né comprendi appieno). Lo strumento supporta l'uso di AI/ML modelli generativi per migliorare l'analisi dei dati su larga scala? Ti offre la possibilità di automatizzare e implementare? AIOps
-
Sicurezza.Quali tipi di integrazioni di autenticazione e autorizzazione supporta lo strumento? Le esperienze utente e di accesso soddisfano le esigenze della tua organizzazione?
-
OpenTelemetry supporto. Lo strumento e l'agente supportano OpenTelemetry? La maggior parte delle piattaforme di osservabilità supporta l'ingestione di segnali OpenTelemetry compatibili, ma non tutti gli agenti forniscono opzioni di configurazione per inoltrare questi segnali a una piattaforma di osservabilità.
-
Integrazioni. Quali integrazioni offre lo strumento? Valuta se devi inviare avvisi a Slack, ai membri del team di Page o automatizzare la risoluzione.
-
Scalabilità. Quanto è scalabile e performante lo strumento? La soluzione di osservabilità deve adattarsi all'aumento delle esigenze e dell'utilizzo, in modo da poter fornire diagnosi anche se l'applicazione non è disponibile.
-
Support. Quale modello di supporto viene offerto? Lo strumento di osservabilità deve essere disponibile anche in caso di guasto dell'applicazione, in modo da poter soddisfare gli obiettivi di MTTR e di disponibilità delle applicazioni o gli accordi sui livelli di servizio (). SLAs Le soluzioni open source potrebbero offrire un supporto formale limitato.
Modello di licenza e distribuzione
Prendi in considerazione il modello di licenza (open source o commerciale) e il modello di implementazione (ospitato autonomamente o basato sul cloud) della soluzione. Le opzioni open source spesso hanno costi iniziali inferiori, ma potrebbero richiedere più tempo per l'implementazione, l'installazione e la configurazione, la manutenzione e l'aggiornamento del team prima di fornire valore. Se state considerando le opzioni open source, potreste aver bisogno di un team dedicato di esperti di osservabilità. Il software commerciale in genere offre un time-to-value più rapido con un costo iniziale più elevato, e la necessità di un team dedicato all'osservabilità si evolve nel tempo con l'aumento dell'adozione, della complessità e della maturità. Le soluzioni self-hosted richiedono più tempo per l'implementazione, l'installazione e la configurazione, la manutenzione e i costi operativi rispetto alle soluzioni basate sul cloud.
Prezzi delle dimensioni
In che modo il modello di prezzo dello strumento influirà sul costo totale di proprietà (TCO) man mano che l'applicazione acquisirà nuovi utenti, un maggiore ingombro dell'architettura o nuove funzionalità e applicazioni? Ad esempio, alcuni modelli di licenza tipici sono perpetui o basati sugli abbonamenti, sul numero di utenti nominali, sul consumo o sul volume. Considerate in che modo la vostra applicazione e lo strumento di osservabilità saranno scalabili in termini di utilizzo e in che modo il modello di licenza può influire sul costo dello strumento.
Competenze del team
A seconda dell'attuale set di abilità e della maturità del tuo team, dovrai determinare il livello di miglioramento delle competenze richiesto. Valuta il tipo di supporto fornito dal fornitore per la formazione del tuo team. Valuta anche se la tua struttura organizzativa supporta la configurazione e la gestione dello strumento che scegli. Ad esempio, se lo desideri OpenTelemetry, dovresti prendere in considerazione la creazione di un team separato specializzato nell'osservabilità.
Operazioni e manutenzione
Valuta le seguenti domande:
-
Quali opzioni di implementazione offre l'agente o il collettore di osservabilità? Queste opzioni soddisfano i requisiti della vostra architettura? Ad esempio, se si utilizza una distribuzione containerizzata per lo strumento di osservabilità, supporta un daemonset o un sidecar? Quali passaggi o strumenti aggiuntivi dovrebbe adottare o utilizzare il team operativo per garantire l'allineamento con la sicurezza e tutti gli altri processi?
-
Qual è lo sforzo richiesto per mantenere la soluzione? Quanto è semplice o automatizzato il processo di aggiornamento dell'agente o del raccoglitore? Le interfacce di osservabilità completamente gestite e basate sul cloud hanno in genere un sovraccarico operativo inferiore rispetto alle applicazioni autodistribuite e ospitate, sebbene la gestione dell'agente o del raccoglitore rimanga la stessa. Prendete in considerazione la struttura del vostro team e tenete conto del costo umano legato al mantenimento dell'opzione scelta.
Strumenta la tua applicazione
Le risposte alle domande della sezione precedente forniscono le informazioni necessarie per strumentare l'applicazione, ovvero per aggiungere codice per acquisire segnali di telemetria all'applicazione e misurare, osservare e convalidare i comportamenti. È possibile utilizzare, SDKs ad esempio, l' OpenTelemetry SDK per il linguaggio dell'applicazione per strumentalizzare automaticamente l'applicazione. Potrebbe comunque essere necessario aggiungere codice di strumentazione manuale per colmare eventuali lacune e garantire la visibilità. end-to-end Presta attenzione alla telemetria che aggiungi e assicurati di poterla ricollegare a una o più telemetria stabilita nella fase SLIs precedente SLOs .
Raccogli dati di telemetria
Implementa componenti di osservabilità
Quando la telemetria fluisce e viene inserita in una piattaforma di osservabilità, crea dashboard, avvisi, playbook e runbook.
-
Dashboard: crea dashboard che contengano informazioni pertinenti, inclusa una rappresentazione visiva delle tendenze attuali e storiche associate ai risultati prioritari. Rendi queste dashboard disponibili agli stakeholder che hai definito nella fase 1. Per ulteriori informazioni, consulta Creazione di dashboard per la visibilità operativa sul sito
Web Amazon Builders' Library. -
Avvisi: definisci gli avvisi per avvisare il team quando i risultati sono a rischio o vengono violati. Valuta la possibilità di aggiungere avvisi per problemi di sicurezza e prestazioni. Ottimizza gli avvisi per ridurre l'affaticamento e i costi degli avvisi adottando quanto segue:
-
Utilizza il rilevamento delle anomalie per evitare di impostare soglie rigide, che richiedono aggiustamenti frequenti, e per ridurre il verificarsi di incognite sconosciute.
-
Utilizza combinazioni di avvisi intelligenti che esaminano insieme più metriche correlate anziché impostare avvisi individuali per ogni metrica. Ad esempio, invece di impostare avvisi separati per CPU, memoria e tempo di risposta, crea un avviso significativo che si attiva solo quando queste metriche indicano collettivamente un problema reale. Questo approccio riduce in modo significativo il rumore generato dagli avvisi e aiuta i team a concentrarsi sui problemi effettivi che influiscono sui servizi anziché dover rispondere a picchi di metrici isolati.
-
Genera avvisi solo quando l'esperienza utente o i risultati sono a rischio. Ad esempio, evita di ricevere avvisi su un picco della CPU causato da un aggiornamento automatico quando l'applicazione non ha utenti attivi.
-
-
Playbook: un playbook fornisce un modello mentale e un contesto alla persona che risponde a un incidente o a un avviso e la aiuta a identificare più rapidamente la causa principale. Prendi in considerazione la creazione di playbook per applicazioni complesse e altamente accoppiate e per applicazioni prive di strumentazione ma che hanno un impatto diretto sui risultati identificati e a cui hai dato priorità nella fase 1.
-
Runbook: utilizza i runbook per definire i passaggi necessari per risolvere un incidente o un avviso.
Convalida il sistema di osservabilità
Durante tutto il ciclo di vita dello sviluppo del software (SDLC), verifica che i dashboard forniscano i comportamenti e gli aggiornamenti previsti durante i test di sistema. Implementate l'ingegneria del caos e convalidate i passaggi documentati nei playbook e nei runbook, per assicurarvi che siano accurati e funzionali allo scopo. È inoltre necessario convalidare la proprietà degli avvisi e i percorsi di escalation.
