Escalation. Scenari tipici del servizio di monitoraggio dei siti web

Pubblicato: Alex Shashenko 2014-06-12 all articles | Glossario | DOMANDE FREQUENTI

Sono stato svegliato da un SMS alle tre del mattino. Il mio sito è caduto per tre minuti, e si è risollevato da solo.
Ma non sono riuscito a riaddormentarmi.

Storia di vita vera

Come molti sanno, HostTracker è un sistema di monitoraggio dell'efficienza dei siti. Una delle sue funzioni principali è quella di notificare tempestivamente all'utente eventuali problemi. L'efficienza delle notifiche e il livello accettabile di “dettaglio” sono importanti. Se si inviano avvisi a ogni “starnuto”, la persona non troverà le informazioni importanti in questo flusso.

Abbiamo previsto diversi meccanismi che aiuteranno le persone giuste a ottenere le notifiche necessarie:

  • Separazione delle notifiche in diversi gruppi in base alla loro criticità;
  • Nessuna notifica in caso di breve durata.
  • Nessuna notifica in caso di guasti a breve termine;
  • Segnalazione del problema a chi di dovere
  • Segnalare tempestivamente il problema al responsabile;
  • Segnalare un guasto di breve durata
  • Segnalare un guasto prolungato all'amministrazione;
  • Utilizzare prima gli avvisi gratuiti – e-mail, gtalk, e poi quelli a pagamento – SMS o chiamata telefonica;
  • A livello di contatto – impostare l'orario di lavoro in cui questo contatto deve ricevere gli avvisi.

Ci sono tre tipi di notifiche:

  • Il sito web è caduto”.
  • Il sito web è ancora “down”
  • Il sito web è “aumentato

Il “down” e il “rose” sono chiari. Le notifiche “il sito è ancora giù” vengono inviate a ogni fallimento del test, ma solo alle cadute confermate. L'algoritmo di conferma dei fallimenti è stato descritto nell'articolo “Esclusione dei falsi avvisi”

Per ogni coppia sito-contatto è possibile attivare o disattivare il tipo di notifica appropriato. L'impostazione si trova nelle proprietà del contatto e nella “matrice generale” alla pagina “Notifiche sottoscritte”.

Escalation e il livello di detalizzazione delle notifiche.

Supponiamo che due persone siano responsabili del sito:

  • Amministratore
  • Gestore

Proviamo a implementare il seguente scenario:

  • In caso di “caduta” vogliamo inviare immediatamente un messaggio di posta elettronica all'amministratore;
  • Se il sito non si alza entro 15 minuti, inviamo un SMS all'amministratore;
  • Se il sito rimane “down” per più di un'ora, allora inviamo un SMS all'amministratore.

Aggiungi i contatti per gli utenti. Durante l'aggiunta, prestare attenzione alla finestra “Ritardo di notifica”.

Sembra che abbiamo tre contatti con i seguenti ritardi:

  • Amministratore (e-mail) – nessun ritardo;
  • Amministratore (SMS) – 15 minuti di ritardo;
  • Gestore (SMS) – 1 ora di ritardo;

Secondo questa configurazione, l'amministratore riceverà tutte le notifiche dei guasti via e-mail, ma le notifiche via SMS saranno inviate solo se il sito è “down” per più di 15 minuti. Il manager riceverà solo gli SMS relativi a guasti gravi che durano più di un'ora. Impostazione del programma di lavoro dei contatti

Supponiamo che un amministratore non possa farcela e che ne abbiamo assunto un altro. Il primo lavora nella prima metà della settimana, il secondo nella seconda. Di conseguenza, le notifiche devono essere inviate all'amministratore “in servizio” Per impostare questo scenario, la finestra “Imposta l'orario di lavoro del contatto” viene utilizzata nelle impostazioni del contatto.

In questo caso il primo amministratore riceverà le notifiche via SMS dal lunedì al giovedì compreso. Inoltre, è possibile dividere le notifiche per i diversi dipendenti in base all'orario, ad esempio nominando amministratori diurni e notturni.

Conclusioni: Con l'aiuto di meccanismi relativamente semplici possiamo coprire la maggior parte delle notifiche e mettere a punto gli scenari degli utenti.

Tags: usecase
Responsabile delle comunicazioni e della tecnologia di HostTracker. Alex fa parte del team fin dagli inizi dell'azienda. Il suo lavoro si concentra sulla reportistica aziendale, sull'analisi delle statistiche del database e sull'amministrazione del sistema. Alex si occupa anche della comunicazione con il team di sviluppo e i clienti.