Tags:
, view all tags

Descrizione delle operazioni

  • I turni settimanali cominciano alle 14 del lunedi' e terminano alle 14 del lunedi' successivo, da svolgersi in orario d'ufficio (sono esclusi sabato e domenica)
  • Sono previsti turni di 2 persone
  • Ogni due settimane, alternandosi con i tedeschi, all'Italia spetta il turno TPM: se ne occuperanno i due team italiani in turno in quelle settimane, durante la settimana di loro competenza (nell'altra agiranno come team di backup). Documentazione utile può essere trovata qui

Daily checklist

Elenco dei controlli da prendere in considerazione ogni giorno. Alcune controlli vanno verificati una volta al giorno (come per esempio Accounting e Gestione ticket vecchi), altre attivita' vanno fatte a intervalli regolari (per esempio l'apertura di nuovi ticket attraverso la dashboard).

  • Gestione ticket vecchi: Verificare, una volta al giorno, lo stato dei ticket.
  • Regional Dashboard, che consente di gestire i problemi che si verificano sui siti. Per comodità, sulla dashboard regionale è possibile visualizzare solo i siti che hanno almeno un allarme od un ticket (che abbiano raggunto o meno uno dei vari livelli di scadenza). I turnisti devono gestire gli allarmi ed i ticket con le relative procedure di escalation, seguendo la procedura descritta nel COD Escalation Procedure.
  • Sistema di ticketing italiano: i ticket che non vengono aggiornati da 6 giorni, vengono evidenziati in rosso. I turnisti devono sollecitare una risposta o chiudere il ticket se il problema e' stato risolto.
  • Apertura nuovi ticket

Strumenti di Monitoring

I turnisti dovranno controllare lo stato della grid italiana utilizzando i diversi tool a disposizione:

  • devono usare la Regional Dashboard nella quale sono riportati i vari allarmi, ticket gia' aperti o downtime dei siti. Per una corretta visualizzazione della pagina, bisogna essere registrati sul GOC-DB ed aver richiesto il ruolo "Regional First Line Supporter". I ticket andranno aperti tramite la dashboard dopo aver valutato gli allarmi che vi compaiono (in molti casi consigliamo di effettuare controlli incrociati): la dashboard e' interfacciata con il sistema di ticketing GGUS ed in base all'errore verificatosi c'e' gia' un testo preimpostato (comunque modificabile) nel ticket che verra' aperto.
Oltre alla dashboard, gli strumenti a disposizione per la gestione degli allarmi e dei ticket sono:
  • il portale MyEGI mostra l'esito dei test lanciati da Nagios sulle varie macchine monitorate
  • il portale GSTAT mostra le informazioni pubblicate dai siti e segnala eventuali errori od incongruenze
Per verificare che un problema sia stato veramente risolto e velocizzare la pubblicazione dei test di nagios, si può anche fare il "reschedule" del check relativo ad un particolare test

Per quanto riguarda l'escalation dei ticket aperti tramite la Regional Dashboard bisogna seguire la procedura descritta nel COD Escalation Procedure.

Azioni

Alcune indicazione su come comportarsi con allarmi e ticket:

  • Occuparsi degli allarmi entro 24 ore. Qualche eccezione:
    • ad esempio può succedere che compaia un allarme relativo ad un problema per il quale è stato già aperto un ticket: di solito conviene aspettare che venga risolto il problema invece che aprire un nuovo ticket. La giusta azione da intraprendere verrà decisa di caso in caso.
  • Chiudere gli allarmi per i siti che sono in downtime (se non si vuole essere bacchettati dal COD)
  • Chiudere gli allarmi che sono in stato OK
    • Quando si chiude un allarme in stato non OK, va fornita una spiegazione
  • Non lasciare in ogni caso che gli allarmi raggiungano le 72 ore
  • controllare se ci sono ticket in scadenza (o scaduti) ed intraprendere le azioni più appopriate in accordo con le procedure di escalation
  • non lasciare scadere i ticket (specialmente da 3 giorni)
Il turnista dovra' inoltre rispondere ai ticket fornendo un primo supporto ai site-manager, eseguire delle diagnosi sui problemi occorsi e cercare di fornire una soluzione.

Quando si apre il ticket:

  • Controllare se il messaggio d’errore è tra quelli noti, in modo da poter già fornire una soluzione oppure chedere di controllare alcune cose specifiche
  • Seguire i ticket e rispondere prontamente
    • Indagare sui problemi e fare un po’ di debug
    • In caso, coinvolgere gli sviluppatori
  • Cambiare lo stato del ticket in “in progress” quando si risponde la prima volta

Attività TPM

ljghljg

ljglgulgvfgv

-- AlessandroPaolini - 2011-10-27

Edit | Attach | PDF | History: r40 | r6 < r5 < r4 < r3 | Backlinks | Raw View | More topic actions...
Topic revision: r4 - 2011-10-28 - AlessandroPaolini
 
  • Edit
  • Attach
This site is powered by the TWiki collaboration platformCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback