SRE (Site Reliability Engineering) è un approccio per rendere accessibili i progetti web. È considerato un framework per DevOps e spiega come avere successo nell'applicazione delle pratiche DevOps. Questo articolo traduce libri da Google. Ho preparato personalmente questa traduzione e ho fatto affidamento sulla mia esperienza nella comprensione dei processi di monitoraggio. Nel canale Telegram и Ho anche pubblicato un collegamento a una traduzione del capitolo 4 dello stesso libro sugli obiettivi del livello di servizio.
Traduzione per gatto. Buona lettura!
I team di Google SRE dispongono di principi di base e best practice per creare sistemi di monitoraggio e notifica efficaci. Questo capitolo fornisce consigli su quali problemi può incontrare un visitatore di una pagina Web e su come risolvere i problemi che rendono difficile la visualizzazione delle pagine Web.
definire
Non esiste un unico vocabolario utilizzato per discutere argomenti relativi al monitoraggio. Anche su Google i termini sottostanti non sono di uso comune, ma elencheremo le interpretazioni più comuni.
Monitoraggio
Raccolta, elaborazione, aggregazione e visualizzazione di dati quantitativi in tempo reale sul sistema: numero di richieste e tipi di richieste, numero di errori e tipi di errori, tempo di elaborazione delle richieste e uptime del server.
Monitoraggio della scatola bianca
Monitoraggio basato sulle metriche visualizzate dagli elementi interni del sistema, inclusi log, JVM o metriche di profilazione del gestore HTTP che generano statistiche interne.
Monitoraggio della scatola nera
Testare il comportamento dell'applicazione dal punto di vista dell'utente.
Dashboard (dashboard)
Un'interfaccia (di solito un'interfaccia web) che fornisce una panoramica dei principali indicatori di salute dei servizi. La dashboard può avere filtri, la possibilità di selezionare quali metriche visualizzare e così via.L'interfaccia è progettata per identificare le metriche più importanti per gli utenti. La dashboard può anche visualizzare informazioni per il personale di supporto tecnico: una coda di richieste, un elenco di errori ad alta priorità, un ingegnere assegnato per una determinata area di responsabilità.
Avviso (notifica)
Notifiche destinate a essere ricevute da una persona tramite e-mail o altro, che possono essere attivate a seguito di errori o di un aumento della coda delle richieste. Le notifiche sono classificate come: ticket, avvisi e-mail e messaggi di messaggistica.
Causa principale (causa principale)
Un difetto del software o un errore umano che, una volta corretto, non dovrebbe ripresentarsi. Il problema può avere diverse cause principali: insufficiente automazione del processo, difetto del software, insufficiente studio della logica dell'applicazione. Ciascuno di questi fattori può essere la causa principale e ciascuno di essi deve essere eliminato.
Nodo e macchina (nodo e macchina)
Termini intercambiabili per fare riferimento a una singola istanza di un'applicazione in esecuzione su un server fisico, una macchina virtuale o un contenitore. Ci possono essere diversi servizi su una macchina. I servizi possono essere:
- correlati tra loro: ad esempio, un server cache e un server web;
- servizi non correlati sullo stesso hardware: ad esempio, un repository di codice e una procedura guidata per un sistema di configurazione, come o .
Spingi
Qualsiasi modifica alla configurazione del software.
Perché è necessario il monitoraggio
Ci sono diversi motivi per cui le applicazioni dovrebbero essere monitorate:
Analisi delle tendenze a lungo termine
Quanto è grande il database e quanto velocemente sta crescendo? Come cambia il numero giornaliero di utenti?
Confronto delle prestazioni
Le query sono più veloci su Acme Bucket of Bytes 2.72 rispetto ad Ajax DB 3.14? Quanto sono migliori le richieste memorizzate nella cache dopo la comparsa di un nodo aggiuntivo? Il sito è diventato più lento rispetto alla scorsa settimana?
Avvisi (notifiche)
Qualcosa è rotto e qualcuno deve ripararlo. Oppure qualcosa si romperà presto e qualcuno deve controllarlo presto.
Creazione di dashboard
I dashboard dovrebbero rispondere a domande di base e includere qualcosa da - ritardi (latenza), traffico (traffico), errori (errori) e valore di carico (saturazione).
Esecuzione di analisi retrospettive (debug)
La latenza di elaborazione delle richieste è aumentata, cos'altro è successo nello stesso periodo?
I sistemi di monitoraggio sono utili come fonte di dati per i sistemi di business intelligence e per facilitare l'analisi degli incidenti di sicurezza. Poiché questo libro si concentra sulle aree ingegneristiche in cui gli SRE hanno esperienza, non discuteremo qui le tecniche di monitoraggio.
Il monitoraggio e gli avvisi consentono al sistema di sapere quando si è rotto o sta per rompersi. Quando un sistema non è in grado di ripararsi automaticamente, vogliamo che un essere umano analizzi l'avviso, determini se il problema è ancora presente, lo risolva e ne determini la causa principale. Se non controlli i componenti del sistema, non riceverai mai un avviso solo perché "qualcosa sembra un po' strano".
Il caricamento di avvisi umani è un uso piuttosto costoso del tempo di un dipendente. Se il dipendente sta lavorando, l'avviso interrompe il flusso di lavoro. Se il dipendente è a casa, l'avviso interrompe il tempo personale ed eventualmente il sonno. Quando gli avvisi si verificano con troppa frequenza, i dipendenti ignorano, ritardano o ignorano gli avvisi in arrivo. Di tanto in tanto ignorano il vero allarme, che è mascherato da eventi rumorosi. Le interruzioni del servizio possono durare a lungo poiché gli eventi rumorosi impediscono una rapida diagnosi e risoluzione dei problemi. I sistemi di diffusione sonora efficaci hanno un buon rapporto segnale/rumore.
Determinare aspettative ragionevoli dal sistema di monitoraggio
L'impostazione del monitoraggio per un'applicazione complessa è di per sé un'attività ingegneristica complessa. Anche con un'infrastruttura significativa di strumenti di raccolta, visualizzazione e avviso, un team di Google SRE di 10-12 membri include in genere una o due persone il cui scopo principale è creare e mantenere sistemi di monitoraggio. Questo numero è diminuito nel tempo man mano che generalizziamo e centralizziamo l'infrastruttura di monitoraggio, ma ogni team SRE in genere ha almeno un membro dello staff che si occupa solo del monitoraggio. Va detto che mentre è abbastanza interessante guardare i cruscotti del sistema di monitoraggio, i team SRE evitano accuratamente le situazioni che richiedono che qualcuno guardi lo schermo per monitorare i problemi.
In generale, Google è passata a sistemi di monitoraggio semplici e veloci con strumenti di analisi post-fatto ottimali. Evitiamo i sistemi "magici" che tentano di prevedere le soglie o scoprire automaticamente la causa principale. I sensori che rilevano contenuti non intenzionali nelle richieste degli utenti finali sono l'unico controesempio; fintanto che questi sensori rimangono semplici, possono rilevare rapidamente le cause di gravi anomalie. Altri formati per l'utilizzo dei dati di monitoraggio, come la pianificazione della capacità o la previsione del traffico, sono più impegnativi. Un'osservazione per un tempo molto lungo (mesi o anni) a una bassa frequenza di campionamento (ore o giorni) rivelerà una tendenza a lungo termine.
Il team di Google SRE ha lavorato con vari gradi di successo con complesse gerarchie di dipendenze. Raramente usiamo regole come "se scopro che il database è diventato lento, ricevo un avviso di rallentamento del database, altrimenti ricevo un avviso di sito lento". Le regole basate sulle dipendenze di solito si riferiscono alle parti immutabili del nostro sistema, come il sistema per filtrare il traffico degli utenti verso il data center. Ad esempio, "se il filtro del traffico del data center è configurato, non avvisarmi dei ritardi nell'elaborazione delle richieste degli utenti" è una regola comune per gli avvisi del data center. Pochi team in Google supportano gerarchie di dipendenze complesse perché la nostra infrastruttura ha un tasso costante di refactoring continuo.
Alcune delle idee delineate in questo capitolo sono ancora valide: c'è sempre un modo per passare più velocemente dal sintomo alla causa principale, specialmente nei sistemi in continua evoluzione. Pertanto, mentre questo capitolo delinea alcuni obiettivi per il monitoraggio dei sistemi e come raggiungerli, è importante che i sistemi di monitoraggio siano semplici e comprensibili a tutti i membri del team.
Allo stesso modo, per mantenere basso il livello di rumore e alto il livello del segnale, gli approcci al monitoraggio degli oggetti che vengono allertati devono essere molto semplici e affidabili. Le regole che generano avvertimenti per gli esseri umani dovrebbero essere facili da capire e presentare un chiaro problema.
Sintomi contro cause
Il tuo sistema di monitoraggio dovrebbe rispondere a due domande: "cosa è rotto" e "perché è rotto".
"Cosa si è rotto" si riferisce al sintomo e "perché si è rotto" si riferisce alla causa. La tabella seguente mostra esempi di tali collegamenti.
sintomo
Causare
Ricezione dell'errore HTTP 500 o 404
I server di database rifiutano le connessioni
Risposte lente del server
Utilizzo elevato della CPU o cavo Ethernet danneggiato
Gli utenti in Antartide non ricevono GIF di gatti
Il tuo CDN odia scienziati e felini, quindi alcuni IP sono nella lista nera
I contenuti privati sono disponibili ovunque
L'implementazione di una nuova versione del software ha fatto sì che il firewall dimenticasse tutti gli ACL e consentisse a tutti di entrare
"Cosa" e "perché" sono uno degli elementi costitutivi più importanti per creare un buon sistema di monitoraggio con il massimo segnale e il minimo rumore.
Scatola nera contro scatola bianca
Combiniamo un ampio monitoraggio white-box con un modesto monitoraggio black-box per metriche critiche. Il modo più semplice per confrontare Black-box con White-box è che Black-box è incentrato sui sintomi ed è un monitoraggio reattivo piuttosto che proattivo: "il sistema non funziona correttamente in questo momento". White-box dipende dalle capacità di controllo interno dei sistemi: registri eventi o server web. Pertanto, White-box ti consente di rilevare problemi imminenti, malfunzionamenti che sembrano una ritrasmissione di una richiesta, ecc.
Si noti che in un sistema multistrato, un sintomo nell'area di responsabilità di un ingegnere è un sintomo nell'area di responsabilità di un altro ingegnere. Ad esempio, le prestazioni del database sono diminuite. Le letture lente del database sono un sintomo dell'SRE del database che le rileva. Tuttavia, per un SRE front-end che guarda un sito Web lento, il motivo della stessa lettura lenta del database è che il database è lento. Pertanto, il monitoraggio white-box a volte si concentra sui sintomi e talvolta sulle cause, a seconda di quanto sia esteso.
Quando si raccolgono i dati di telemetria per il debug, è necessario il monitoraggio white-box. Se i server Web sono lenti a rispondere alle query del database, è necessario sapere quanto velocemente il server Web sta comunicando con il database e quanto velocemente sta rispondendo. Altrimenti, non sarai in grado di distinguere tra un server database lento e un problema di rete tra il server web e il database.
Il monitoraggio della scatola nera ha un vantaggio chiave quando si inviano avvisi: si attiva una notifica al destinatario quando il problema ha già causato sintomi effettivi. Invece per il problema Black-box che non si è ancora presentato, ma che sta per arrivare, il monitoraggio è inutile.
Quattro segnali d'oro
I quattro segnali di monitoraggio d'oro sono latenza, traffico, errori e saturazione. Se puoi misurare solo quattro metriche del sistema utente, concentrati su quelle quattro.
ritardo
Il tempo necessario per elaborare la richiesta. È importante distinguere tra la latenza delle richieste riuscite e quelle non riuscite. Ad esempio, un errore HTTP 500 causato da una connessione persa a un database o a un altro back-end può essere diagnosticato molto rapidamente, tuttavia, un errore HTTP 500 può indicare una richiesta non riuscita. Trovare l'impatto di un errore 500 sulla latenza complessiva può portare a conclusioni errate. D'altra parte, un errore lento è anche un errore veloce! Pertanto, è importante tenere traccia della latenza degli errori piuttosto che limitarsi a filtrare gli errori.
traffico
Il numero di richieste al tuo sistema, misurato in metriche di sistema di alto livello. Per un servizio Web, questa misurazione rappresenta in genere il numero di richieste HTTP al secondo diviso per la natura delle richieste (ad esempio, contenuto statico o dinamico). Per un sistema di streaming audio, questa misurazione può essere centrata sulla velocità di I/O della rete o sul numero di sessioni simultanee. Per un sistema di archiviazione di valori-chiave, questa misurazione potrebbe essere costituita da transazioni o ricerche al secondo.
Errori
Questa è la percentuale di richieste non riuscite, in modo esplicito (ad esempio, HTTP 500), implicito (ad esempio, HTTP 200 ma combinato con contenuti non validi) o per criterio (ad esempio, "Se acquisisci una risposta in un secondo, qualsiasi un secondo è un errore"). Se non sono disponibili codici di risposta HTTP sufficienti per esprimere tutte le condizioni di errore, potrebbero essere necessari protocolli secondari (interni) per rilevare l'errore parziale. Il monitoraggio di tutte queste richieste errate può essere poco informativo, mentre i test di sistema end-to-end possono aiutarti a scoprire che stai elaborando il contenuto sbagliato.
saturazione
La metrica mostra quanto pesantemente viene utilizzato il tuo servizio. Si tratta di una misura di monitoraggio del sistema che identifica le risorse più limitate (ad esempio, in un sistema con memoria limitata, mostra la memoria, in un sistema con I/O limitati, mostra il numero di I/O). Tieni presente che molti sistemi si degradano prima di raggiungere il 100% di utilizzo, quindi è essenziale avere un obiettivo di utilizzo.
Nei sistemi complessi, la saturazione può essere integrata da una misurazione del carico di livello superiore: il tuo servizio può gestire correttamente il doppio traffico, gestire solo il 10% di traffico in più o gestire ancora meno traffico di quanto possa fare attualmente? Per servizi semplici che non hanno parametri che modificano la complessità della richiesta (ad esempio "Dammi niente" o "Ho bisogno di un numero intero monotonico univoco") che cambiano raramente la configurazione, un valore di test di carico statico può essere adeguato. come discusso nel paragrafo precedente, la maggior parte dei servizi dovrebbe utilizzare segnali indiretti come l'utilizzo della CPU o la larghezza di banda della rete che hanno un limite superiore noto. L'aumento della latenza è spesso il principale indicatore di saturazione. La misurazione del tempo di risposta al 99° percentile in una piccola finestra (ad es. un minuto) può fornire un segnale di saturazione molto precoce.
Infine, la saturazione è anche associata a previsioni di saturazione imminente, come: "Sembra che il tuo database riempirà il tuo disco rigido in 4 ore".
Se misuri tutti e quattro i segnali d'oro e quando c'è un problema con una delle metriche (o, in caso di saturazione, quasi un problema), notifichi la persona, il tuo servizio sarà più o meno coperto dal monitoraggio.
Preoccuparsi della coda (o della strumentazione e delle prestazioni)
Quando si crea un sistema di monitoraggio da zero, si è tentati di sviluppare un sistema basato sulle medie: latenza media, utilizzo medio della CPU del nodo o occupazione media del database. Il pericolo degli ultimi due esempi è evidente: processori e database vengono eliminati in modo molto imprevedibile. Lo stesso vale per il ritardo. Se esegui un servizio Web con una latenza media di 100 ms a 1000 richieste al secondo, l'1% delle richieste può richiedere 5 secondi. Se gli utenti dipendono da più servizi Web di questo tipo, il 99° percentile di un singolo backend può facilmente diventare il tempo di risposta medio dell'interfaccia.
Il modo più semplice per distinguere tra una media lenta e una coda molto lenta delle richieste è raccogliere le misure delle richieste espresse in statistiche (gli istogrammi sono uno strumento adatto per la visualizzazione), piuttosto che i ritardi effettivi: quante richieste sono state servite dal servizio che ha preso tra 0 ms e 10 ms, tra 10 ms e 30 ms, tra 30 ms e 100 ms, tra 100 ms e 300 ms, ecc.
Scelta della giusta granularità per le misurazioni
Diversi elementi del sistema dovrebbero essere misurati con diversi livelli di dettaglio. Per esempio:
- Osservare l'utilizzo dell'utilizzo della CPU per un periodo di tempo non mostrerà picchi lunghi che si traducono in latenze elevate.
- D'altra parte, per un servizio Web destinato a non più di 9 ore di inattività all'anno (tempo di attività annuale del 99,9%), il controllo di una risposta HTTP 200 più di una o due volte al minuto sarebbe probabilmente inutilmente frequente.
- Allo stesso modo, il controllo dello spazio libero sul disco rigido per la disponibilità del 99,9% più di una volta ogni 1-2 minuti probabilmente non è necessario.
Fai attenzione a come strutturi la granularità delle dimensioni. Un tasso di utilizzo della CPU di 1 al secondo può fornire dati interessanti, ma misurazioni così frequenti possono essere molto costose da raccogliere, archiviare e analizzare. Se il tuo obiettivo di monitoraggio richiede un'elevata granularità e non richiede un'elevata reattività, puoi ridurre questi costi impostando la raccolta delle metriche sul server e quindi configurando un sistema esterno per raccogliere e aggregare tali metriche. Potresti:
- Misura l'utilizzo della CPU ogni secondo.
- Riduci i dettagli al 5%.
- Metriche aggregate ogni minuto.
Questa strategia ti consentirà di raccogliere dati altamente granulari senza dover affrontare costi generali elevati per l'analisi e l'archiviazione.
Il più semplice possibile, ma non più facile
L'impilamento di diversi requisiti uno sopra l'altro può portare a un sistema di monitoraggio molto complesso. Ad esempio, il tuo sistema potrebbe avere i seguenti elementi complicati:
- Avvisi in base a soglie diverse per la latenza delle richieste, in percentili diversi, in tutti i tipi di metriche diverse.
- Scrittura di codice aggiuntivo per rilevare e identificare possibili cause.
- Crea dashboard correlati per ciascuna delle possibili cause di problemi.
Le fonti di potenziali complicazioni non finiscono mai. Come tutti i sistemi software, il monitoraggio può diventare così complesso da diventare fragile, difficile da modificare e mantenere.
Pertanto, progetta il tuo sistema di monitoraggio per semplificarlo il più possibile. Quando scegli cosa monitorare, tieni presente quanto segue:
- Le regole che più spesso rilevano incidenti reali dovrebbero essere il più semplici, prevedibili e affidabili possibile.
- La configurazione per la raccolta dei dati, l'aggregazione e gli avvisi che viene eseguita raramente (ad esempio, meno che trimestralmente per alcuni team SRE) deve essere rimossa.
- Le metriche raccolte ma non mostrate in alcun riquadro di anteprima o utilizzate da alcun avviso sono candidate per l'eliminazione.
In Google, la raccolta e l'aggregazione di base delle metriche, combinate con avvisi e dashboard, funziona bene come un sistema relativamente autonomo (il sistema di monitoraggio di Google è in realtà suddiviso in diversi sottosistemi, ma di solito le persone sono a conoscenza di tutti gli aspetti di questi sottosistemi). Può essere allettante combinare il monitoraggio con altri metodi di test di sistemi complessi: profilazione dettagliata del sistema, debug dei processi, tracciamento dei dettagli di eccezioni o errori, test di carico, raccolta e analisi dei registri o ispezione del traffico. Sebbene la maggior parte di queste cose condivida punti in comune con il monitoraggio di base, mescolarle si tradurrà in troppi risultati e creerà un sistema complesso e fragile. Come per molti altri aspetti dello sviluppo del software, supportare diversi sistemi con punti di integrazione chiari, semplici e debolmente accoppiati è la strategia migliore (ad esempio, utilizzare un'API Web per recuperare i dati di riepilogo in un formato che può rimanere costante per un lungo periodo di tempo ).
Collegare i principi insieme
I principi discussi in questo capitolo possono essere combinati in una filosofia di monitoraggio e avviso approvata e seguita dai team SRE di Google. È auspicabile aderire a questa filosofia di monitoraggio, è un buon punto di partenza per creare o rivedere una metodologia di avviso e può aiutarti a porre le domande giuste alle operazioni indipendentemente dalle dimensioni della tua organizzazione o dalla complessità del servizio o del sistema.
Durante la creazione di regole di monitoraggio e avviso, porre le seguenti domande può aiutarti a evitare falsi positivi e avvisi non necessari:
- Questa regola rileva uno stato del sistema altrimenti non rilevabile che è urgente, invita all'azione e ha inevitabilmente un impatto sull'utente?
- Posso ignorare questo avviso sapendo che è benigno? Quando e perché posso ignorare questo avviso e come posso evitare questo scenario?
- Questo avviso indica che gli utenti sono interessati negativamente? Ci sono situazioni in cui gli utenti non subiscono un impatto negativo, ad esempio a causa del filtraggio del traffico o quando si utilizzano sistemi di test, i cui avvisi devono essere filtrati?
- Posso agire in risposta a questo avviso? Queste misure sono urgenti o possono aspettare fino al mattino? È sicuro automatizzare l'azione? Questa azione sarà una soluzione a lungo termine o una soluzione alternativa a breve termine?
- Alcune persone ricevono più avvisi per questo problema, quindi è possibile ridurne il numero?
Queste domande riflettono la filosofia fondamentale sugli avvisi e sui sistemi di avviso:
- Ogni volta che arriva un avviso, devo reagire con urgenza. Posso correre più volte al giorno prima di stancarmi.
- Ogni avviso deve essere aggiornato.
- Ogni risposta a un avviso deve richiedere l'intervento umano. Se la notifica può essere elaborata automaticamente, non dovrebbe arrivare.
- Gli avvisi dovrebbero riguardare un nuovo problema o un evento che non si è mai verificato prima.
Questo approccio offusca alcune distinzioni: se un avviso soddisfa le quattro condizioni precedenti, non importa se l'avviso viene inviato da un sistema di monitoraggio White-box o Black-Box. Questo approccio rafforza anche alcune differenze: è meglio dedicare molto più impegno all'identificazione dei sintomi che alle cause; quando si tratta di cause, devi solo preoccuparti delle cause inevitabili.
Monitoraggio a lungo termine
Negli ambienti di produzione odierni, i sistemi di monitoraggio monitorano un sistema di produzione in continua evoluzione con architettura software, caratteristiche di carico e obiettivi prestazionali in continua evoluzione. Gli avvisi, che attualmente sono difficili da automatizzare, possono diventare comuni, forse anche meritevoli di essere affrontati. A questo punto, qualcuno deve trovare e risolvere le cause alla radice del problema; se tale risoluzione non è possibile, la reazione all'allerta richiede una completa automazione.
È importante che le decisioni di monitoraggio vengano prese tenendo conto degli obiettivi a lungo termine. Ogni avviso che viene eseguito oggi allontana una persona dal migliorare il sistema domani, quindi c'è spesso una diminuzione della disponibilità o delle prestazioni di un sistema produttivo per il tempo necessario per migliorare il sistema di monitoraggio a lungo termine. Diamo un'occhiata a due esempi che illustrano questo fenomeno.
Bigtable SRE: una storia sull'eccessiva allerta
L'infrastruttura interna di Google viene in genere fornita e misurata in termini di livello di servizio (SLO). Anni fa, lo SLO del servizio Bigtable era basato sulla performance media di una transazione sintetica che simulava un client in esecuzione. A causa di problemi in Bigtable e livelli inferiori dello stack di archiviazione, le prestazioni medie sono state guidate da una "grande" coda: il peggior 5% delle query era spesso significativamente più lento del resto.
Le notifiche e-mail sono state inviate all'avvicinarsi della soglia SLO e gli avvisi di messaggistica sono stati inviati quando lo SLO è stato superato. Entrambi i tipi di avvisi sono stati inviati abbastanza frequentemente, consumando una quantità inaccettabile di tempo di progettazione: il team ha trascorso una notevole quantità di tempo analizzando gli avvisi per trovarne alcuni che fossero effettivamente rilevanti. Spesso ci siamo persi un problema che interessava effettivamente gli utenti perché solo alcuni degli avvisi riguardavano quel problema specifico. Molti degli avvisi non erano urgenti a causa di problemi infrastrutturali comprensibili e sono stati gestiti in modo standard o non gestiti affatto.
Per porre rimedio alla situazione, il team ha utilizzato un approccio su tre fronti: mentre lavorava duramente per migliorare le prestazioni di Bigtable, abbiamo temporaneamente impostato il 75° percentile per il ritardo di risposta alle query come obiettivo SLO. Abbiamo anche disattivato gli avvisi e-mail, poiché ce n'erano così tanti che era impossibile perdere tempo a diagnosticarli.
Questa strategia ci ha permesso di riprendere fiato per iniziare a risolvere i problemi a lungo termine in Bigtable e nei livelli inferiori dello stack di archiviazione, piuttosto che risolvere costantemente i problemi tattici. Gli ingegneri potevano effettivamente portare a termine il lavoro quando non erano continuamente bombardati da avvisi. In definitiva, il temporaneo ritardo nell'elaborazione degli avvisi ci ha permesso di migliorare la qualità del servizio.
Gmail: risposte umane prevedibili e algoritmiche
All'inizio, Gmail è stato costruito su un sistema di controllo del processo Workqueue modificato che è stato creato per elaborare in batch blocchi dell'indice di ricerca. Workqueue è stato adattato a processi di lunga durata e successivamente applicato a Gmail, ma alcuni bug nel codice opaco dello scheduler si sono rivelati molto difficili da correggere.
A quel tempo, il monitoraggio di Gmail era strutturato in modo che gli avvisi si attivassero quando le singole attività venivano annullate utilizzando Workqueue. Questo approccio non era l'ideale, perché anche a quel tempo Gmail eseguiva molte migliaia di attività, ognuna delle quali veniva assegnata a frazioni dell'uno percento dei nostri utenti. Abbiamo fatto molta attenzione a garantire agli utenti Gmail una buona esperienza utente, ma gestire così tanti avvisi era fuori questione.
Per risolvere questo problema, Gmail SRE ha creato uno strumento per aiutare a eseguire il debug dello scheduler nel miglior modo possibile per ridurre al minimo l'impatto sugli utenti. Il team ha avuto diverse discussioni sull'opportunità di automatizzare semplicemente l'intero ciclo dall'individuazione del problema alla sua risoluzione fino a quando non è stata trovata una soluzione a lungo termine, ma alcuni erano preoccupati che tale soluzione avrebbe ritardato l'effettiva risoluzione del problema.
Tale tensione era comune all'interno del team e spesso rifletteva una sfiducia nell'autodisciplina: mentre alcuni membri del team vogliono dare tempo per una corretta correzione, altri temono che la correzione finale verrà dimenticata e la correzione temporanea richiederà per sempre. Questo problema merita attenzione, poiché è troppo facile risolvere i problemi temporaneamente, invece di apportare una soluzione permanente. I dirigenti e il personale tecnico svolgono un ruolo chiave nell'implementazione di correzioni a lungo termine supportando e dando priorità a correzioni a lungo termine potenzialmente a lungo termine anche quando il dolore iniziale si attenua.
Gli avvisi ricorrenti regolari e le reazioni algoritmiche dovrebbero essere una bandiera rossa. La riluttanza del tuo team ad automatizzare questi avvisi significa che il team non è sicuro di potersi fidare degli algoritmi. Questo è un problema serio che deve essere affrontato.
Lungo termine
Un tema comune collega gli esempi Bigtable e Gmail: la competizione tra disponibilità a breve e lungo termine. Spesso un grande sforzo può aiutare un sistema fragile a raggiungere un'elevata disponibilità, ma questo percorso è solitamente di breve durata, irto di esaurimento del team e dipendenza da un piccolo numero di membri di questo stesso team eroico.
Un declino controllato ea breve termine della disponibilità è spesso doloroso, ma strategicamente importante per la stabilità a lungo termine del sistema. È importante non considerare ogni allarme in modo isolato, ma considerare se il tasso complessivo di allarmi porta a un sistema sano e adeguatamente accessibile con una squadra valida e una prognosi favorevole. Analizziamo le statistiche sul tasso di allerta (solitamente espresse come incidenti per turno, in cui un incidente può essere costituito da più incidenti correlati) in rapporti trimestrali con la direzione, consentendo ai responsabili delle decisioni di presentare continuamente il carico del sistema di allerta e lo stato generale del team.
conclusione
Il percorso verso un monitoraggio e avvisi integri è semplice e diretto. Si concentra sui sintomi del problema per il quale vengono generati gli avvisi e il monitoraggio della causa serve come ausilio per il debug dei problemi. Il monitoraggio dei sintomi è più semplice quanto più si è in alto nello stack che si controlla, sebbene il carico del database e il monitoraggio delle prestazioni debbano essere eseguiti direttamente sul database stesso. Le notifiche e-mail sono di uso molto limitato e tendono a trasformarsi facilmente in rumore; invece, dovresti utilizzare una dashboard che monitora tutti i problemi attuali che vengono avvisati tramite e-mail. La dashboard può anche essere abbinata a un registro eventi per analizzare le correlazioni storiche.
A lungo termine, è necessario raggiungere un'alternanza riuscita tra allerta dei sintomi e problemi reali imminenti e adattare gli obiettivi per garantire che il monitoraggio supporti una diagnosi rapida.
Grazie per aver letto la traduzione fino alla fine. Iscriviti al mio canale Telegram sul monitoraggio и .
Fonte: habr.com