Osservabilità operativa

L'osservabilità è necessaria per ottenere informazioni utili sulle prestazioni degli ambienti e aiutarvi a rilevare e analizzare i problemi. Ha anche uno scopo secondario che consente di definire e misurare gli indicatori chiave di prestazione (KPI) e gli obiettivi del livello di servizio (SLO) come l'uptime. Per la maggior parte delle organizzazioni, i KPI operativi importanti sono il tempo medio di rilevamento (MTTD) e il tempo medio di ripristino (MTTR) a seguito di un incidente.

In termini di osservabilità, il contesto è importante, poiché vengono raccolti i dati e quindi vengono raccolti i tag associati. Indipendentemente dal servizio, dall'applicazione o dal livello di applicazione su cui ti stai concentrando, puoi filtrare e analizzare per quel set di dati specifico. I tag possono essere utilizzati per automatizzare l'onboarding di CloudWatch Alarms in modo che i team giusti possano essere avvisati quando vengono superate determinate soglie metriche. Ad esempio, una chiave di tag example-inc:ops:alarm-tag e il relativo valore potrebbero indicare la creazione dell'allarme. CloudWatch Una soluzione che lo dimostra è descritta in Utilizzare i tag per creare e mantenere CloudWatch allarmi Amazon per le istanze Amazon EC2.

La configurazione di troppi allarmi può facilmente creare una tempesta di avvisi, quando un gran numero di allarmi o notifiche sovraccarica rapidamente gli operatori e ne riduce l'efficacia complessiva mentre gli operatori sono impegnati a classificare manualmente e a dare priorità ai singoli allarmi. È possibile fornire un contesto aggiuntivo per gli allarmi sotto forma di tag, il che significa che è possibile definire regole all'interno di Amazon EventBridge per garantire che venga prestata attenzione al problema originario anziché alle dipendenze a valle.

Il ruolo delle operazioni parallele DevOps viene spesso trascurato, ma per molte organizzazioni i team operativi centrali forniscono ancora una prima risposta fondamentale al di fuori del normale orario lavorativo. (Maggiori dettagli su questo modello sono disponibili nel white paper Operational Excellence.) A differenza del DevOps team responsabile del carico di lavoro, in genere non dispone della stessa conoscenza approfondita, quindi il contesto fornito dai tag all'interno di dashboard e avvisi può indirizzarli al runbook corretto per il problema o avviare un runbook automatizzato (consulta il post del blog Automating Amazon Alarms with). CloudWatch AWS Systems Manager