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 1: Definisci la tua stella polare
Un'implementazione efficace dell'osservabilità non riguarda solo le operazioni e gli strumenti, ma anche la promozione di una cultura della proprietà, del miglioramento continuo e della risoluzione proattiva dei problemi. Come per qualsiasi strategia di successo, la strategia per l'osservabilità richiede una considerazione olistica di tre pilastri: persone, processi e tecnologia.
Se desiderate stabilire o migliorare il vostro atteggiamento di osservabilità, vi consigliamo di iniziare definendo ciò che conta, basarvi sui risultati aziendali e rivedere, adattare e riallineare continuamente la strategia man mano che l'azienda, i team e i prodotti si evolvono.
In questa prima fase, definirete e stabilirete la vostra stella polare, ossia una definizione condivisa e ben compresa di ciò che significa «bene» per la vostra organizzazione. Ti consigliamo di rivedere alcune o tutte le attività in questa fase man mano che la tua azienda si evolve, quando lanci un nuovo prodotto, applicazione o servizio o quando progetti una modifica architettonica importante, per rivalutare la piattaforma di osservabilità e le esigenze organizzative.
Integra l'osservabilità nelle fasi iniziali del ciclo di vita dello sviluppo (approccio shift-left)
Fate dell'osservabilità una responsabilità per ogni membro dei team di progettazione, gestione operativa e prodotto e trattatela come un requisito funzionale primario, analogamente al modo in cui trattate i test unitari o la sicurezza. Ciò non trasferisce la responsabilità dal team operativo al team di sviluppo, ma evidenzia la collaborazione richiesta tra i diversi team. È utile che i team svolgano le seguenti attività in collaborazione nelle prime fasi del ciclo di vita dello sviluppo. Potresti volerle eseguire per ticket, per funzionalità o per prodotto.
-
Identifica le parti interessate. Chi sono gli stakeholder e cosa è importante per loro se questa funzionalità o prodotto non funziona come previsto? Quando identificate le parti interessate, prendete in considerazione aspetti quali funzionalità, disponibilità, sicurezza, costi, vendite e utilizzo del prodotto. Le parti interessate possono includere il tuo team, i clienti del prodotto, gli stakeholder aziendali interni, i membri del team operativo della piattaforma e gli sviluppatori di applicazioni. A seconda dello scenario, anche i team addetti alla sicurezza e alla finanza possono essere parti interessate.
-
Identifica i risultati chiave. Determina i risultati chiave e il loro impatto sull'azienda e su ogni stakeholder. Identifica il successo e il fallimento per ogni risultato e per ogni stakeholder. I risultati sono generalmente definiti come obiettivi a livello di servizio (SLOs) e devono essere quantificabili. Un SLO è una misura per ogni risultato. Un buon SLO ha un valore obiettivo che dovrebbe essere perseguito o mantenuto come obiettivo. Un SLO può essere una misura della soddisfazione degli utenti. Un indicatore del livello di servizio (SLI) è la misurazione o le metriche effettive utilizzate per determinare se stai rispettando lo SLO: è il dato quantificabile che registri rispetto al tuo obiettivo. Alcuni esempi includono la riduzione dell'MTTR del 60 percento, il mantenimento della disponibilità delle applicazioni al 99,99 percento o il miglioramento della produttività degli sviluppatori del 30 percento.
Prendiamo l'esempio del mantenimento della disponibilità delle applicazioni al 99,99 percento e definiamo lo SLO, lo SLI e le metriche necessarie per misurare e convalidare il successo. Per questo esempio, consideriamo un' RESTful applicazione e definiamo la disponibilità dell'applicazione come il completamento con successo di tutte le richieste in arrivo. Ciò richiede la misurazione del numero totale di richieste all'applicazione e dello stato di completamento di ciascuna richiesta. Quando li traduci in SLO e SLI, hai bisogno di una metrica che acquisisca le richieste in arrivo e un'altra metrica che catturi lo stato delle richieste. Se tutte le richieste vengono completate correttamente, l'applicazione viene considerata disponibile. Se una o più richieste generano errori, l'applicazione viene considerata non disponibile. Pertanto, lo SLI sarebbe la somma delle richieste completate per errore, divisa per la somma delle richieste in arrivo in un intervallo di 5 minuti, ossia un tasso di errore. Puoi aggiungere un obiettivo a questo SLI per trasformarlo in un SLO; ad esempio: cerca di far sì che il tasso di errore sia inferiore allo 0,1 percento su 3 intervalli consecutivi di 5 minuti.
-
Dai priorità ai risultati chiave.In base alla priorità che hai impostato per ogni risultato, puoi scegliere di concentrarti innanzitutto sui risultati che hanno il maggiore impatto, invece di fare tutto contemporaneamente. Inizia in piccolo, ripeti e migliora la tua postura di osservabilità con piccoli incrementi. L'osservabilità è un processo che richiede revisioni, audit, miglioramenti e miglioramenti continui per aumentare la maturità e i vantaggi. L'assegnazione delle priorità può anche darti l'opportunità di definire tappe incrementali verso i risultati identificati.
-
Identifica la strumentazione richiesta. Quali sono i componenti e le caratteristiche correlate dell'architettura o dell'implementazione che possono influenzare i risultati importanti, come identificato nei passaggi precedenti? Ad esempio, quando esegui un'applicazione su un'istanza Amazon Elastic Compute Cloud (Amazon EC2), il numero di core e la RAM disponibile possono influire sulla reattività e sul throughput dell'applicazione. In questa fase, potrebbe anche essere utile determinare se gli strumenti o le librerie che utilizzi forniscono già parte di questa strumentazione. L'esecuzione di una serie di revisioni preliminari o l'aggiunta di domande come le seguenti alla definizione di ready (DoR) di
un ticket può rendere questa attività parte del processo standard. -
Se questa operazione dovesse fallire, cosa è necessario sapere per risolvere il problema? In che modo un'operazione tipica o problematica influisce sui componenti coinvolti? Che tipo di segnale deve inviare questa operazione: log, metrico o trace? Qual è il costo di questa strumentazione rispetto al suo valore? Che tipo di aggregazione sarebbe accettabile senza violazioni? SLOs
-
Quali sono i componenti e le dipendenze che possono causare un errore in questa operazione? Come identificherete quale componente o dipendenza ha causato l'errore? Quali sono le diverse leve di configurazione di questi componenti e dipendenze e in che modo ciascuna di esse influisce sul funzionamento?
-
Quali sono la granularità metrica e la frequenza di campionamento richieste per garantire che SLI e SLO possano essere misurati con precisione?
-
-
Definisci i criteri di successo. Per ogni risultato prioritario, definisci delle soglie in linea con l'impatto del raggiungimento o del mancato raggiungimento degli obiettivi. I criteri di successo forniscono un contesto aggiuntivo ai team quando rispondono agli avvisi. Inoltre, offrono la possibilità di fare previsioni e fare compromessi rispetto al costo della strumentazione per la visibilità richiesta.
Configura un'organizzazione e una struttura di team efficaci
In base alla complessità architettonica e alle dimensioni dell'azienda, potrebbe essere necessario creare un team dedicato che si concentri sull'osservabilità. Questo team sarà responsabile della configurazione degli strumenti di osservabilità e della configurazione della piattaforma di osservabilità per altri team. Ti consigliamo inoltre di creare un team dedicato se scegli un'implementazione standard. OpenTelemetry Nelle organizzazioni più piccole, puoi assegnare l'osservabilità come responsabilità aggiuntiva a ogni membro del team e anche nominare campioni dell'osservabilità che promuovono e applicano le migliori pratiche tra i team. Questi campioni offrono volontariamente una parte della loro giornata per definire i processi e stabilire gli standard per l'organizzazione. Lavorano come un team autorormante o possono essere guidati da specialisti dedicati all'osservabilità. Il diagramma seguente mostra come l'investimento può determinare l'approccio organizzativo.
I campioni potrebbero essere integrati a pieno titolo nei team (come illustrato per il Team 2 nella figura seguente) o far parte di un team abilitante che si alterna tra i team per stabilire e promuovere le migliori pratiche (il Team 1 nell'illustrazione).
Tieni traccia dell'allocazione dei costi
Le organizzazioni devono implementare il monitoraggio e la visibilità completi dei costi su metriche, log e tracce, stabilendo al contempo la responsabilità specifica del team per l'utilizzo e i costi delle risorse. La corretta integrazione delle pratiche relative alle operazioni finanziarie (FinOps) richiede sistemi di monitoraggio automatizzati con avvisi sul budget abbinati a un'ottimizzazione sistematica della conservazione e della raccolta dei dati. I team di progettazione e finanza dovrebbero allineare i propri obiettivi attraverso dashboard condivisi e revisioni periodiche. Organizations trae vantaggio dall'implementazione di modelli di chargeback chiari e strategie di allocazione dei costi per promuovere la proprietà e la responsabilità.
Definisci gli standard
Identifica e definisci i segnali di base e la telemetria richiesti da un'applicazione, comprese le strategie di avviso e dashboard. Crea una lista di controllo o un processo di revisione formale per ogni applicazione. Il sito Web AWS
Observability Best Practices
Stabilisci processi di escalation
È importante stabilire e applicare meccanismi di segnalazione, titolarità degli avvisi e procedure di risposta. Ti consigliamo di promuovere una cultura in cui l'escalation non sia disapprovata.
Migliora le competenze attraverso la formazione
Identifica il modo migliore per migliorare le competenze dei membri del team esistenti e nuovi, rafforzare l'importanza dell'osservabilità e promuovere una cultura del miglioramento continuo. In base alle esigenze della tua organizzazione, puoi scegliere tra una formazione preregistrata su richiesta o una formazione in aula impartita da campioni o specialisti dell'osservabilità. Il tuo Account AWS team può offrire sessioni di formazione approfondite e pratiche, come il One Observability Workshop, o GameDays
