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, domenica e feste)
  • Sono previsti turni di 2 persone
  • L'Italia ha in carico anche l'attività TPM, che verrà svolta congiuntamente a quella ROD dalle persone in turno ogni settimana (i supporter di NGI_CZ agiranno come backup nel caso in cui nessuno di NGI_IT possa occuparsene). 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 (pagina vecchia su xoops) 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 Grid Oversight 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
    • Ricordarsi che all'apertura di un nuovo ticket si deve impostare il reminder tra 15 giorni
  • Controllo dei dati di accounting: verificare la regolare pubblicazione dei dati di accounting, seguendo queste indicazioni (pagina vecchia su xoops)

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 Operations Staff". 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 nella Grid Oversight 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)
Quando si apre il ticket:
  • Impostare la scadenza (reminder) dopo 15 giorni, per i ticket "Less urgent"
  • 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
  • Follow-up tickets
    • Se non ci sono risposte da parte del sito interessato - al primo reminder, dopo 15 giorni dall'apertura, viene alzata la priorita' del ticket a "Urgent" e si imposta il prosismo reminder tra altri 15 giorni
    • Al secondo reminder, dopo 15 giorni dal primo reminder, se non ci sono risposte da parte del sito interessato, la priorita' del ticket viene alzata a "Top Priority*, con reminder dopo 7 giorni
    • Al terzo reminder, dopo 1 mese e 7 giorni dall'apertura del ticket, se non ci sono risposte da parte del sito interessato si notifica il sito con e-mail diretta e viene cambiato lo stato del sito in godDB in Suspended
Il turnista dovra' inoltre rispondere ai ticket fornendo supporto ai site-manager, eseguire delle diagnosi sui problemi occorsi e cercare di fornire una soluzione.

Un altro compito importante è la certificazione dei siti, seguendo la consueta procedura prevista in questi casi

Siti con availability e reliability sotto la soglia minima

Nella dashboard viene visualizzato l'andamento di Availability e Reliability per ogni sito relativo ai 30 giorni precedenti.

Per quei siti con un'availability inferiore al 70%, comparirà un allarme, che dovrà essere trattato come ogni altro allarme presente sulla dashboard.

Andrà pertanto aperto un ticket, possibilmente con il seguente testo:

Dear site-admin,
in the last 30 days period your site has achieved poor performance,
in particular an Availability value of <valore>

Could you please provide explanation for this low value?
What actions are you planning to do in order to improve the behaviour?

the ticket will be closed when the avalability is above the threshold of 85%

Best Regards,
Nel testo conviene anche inserire il link all'andamento del sito mostrato sul MyEGI centrale http://mon.egi.eu/myegi/sa/

Quando si apre il ticket, conviene impostare la scadenza ad un numero di giorni maggiore dei tre previsti di default, visto che ci vorrà tempo perchè l'availability torni sopra la soglia.

il ticket potrà essere chiuso quando l'allarme tornerà nello stato OK, ovvero quando l'availability avrà superato la soglia minima del 75%: onde evitare riaperture repentine, conviene aspettare qualche giorno accertandosi che l'availability sia davvero in aumento

Attività TPM

L'attività di Ticket Processing Manager è svolta a livello di tutta EGI e pertanto viene usato il sistema di ticketing GGUS . Lo scopo principale del TPM è assicurarsi che i ticket vengano assegnati alle unità di supporto più appropriate, dopo aver vagliato i problemi segnalati e cercato, ove possibile, di indagare e di fornire un primo supporto, od almeno richiedere il maggior numero di informazioni utili per le unità di supporto di destinazione: non è previsto che il TPM abbia una competenza tecnica (e su tutto), ma una conoscenza generale del sistema GRID sicuramente aiuta nel compito. Un certo sforzo deve essere impiegato poi nel controllo dei ticket vecchi, sollecitando le persone coinvolte verso la soluzione dei ticket.

Questi in sintesi i compiti del TPM (consultare anche questa WIKI per ulteriori indicazioni):

  • occuparsi dei ticket entro un'ora dalla loro apertura (in orario lavorativo)
    • nei casi in cui è necessario un po' di tempo per effettuare delle indagini e rispondere quindi al ticket, conviene cambiare subito lo stato in "in progress"
  • in caso di dubbio, chiedere più informazioni al submitter
  • tutti i ticket riguardanti il middleware, devono essere assegnati alla DMSU (le unità di supporto dei batch system non vi sono contenute)
  • duplicare i ticket se riguardano più unità di supporto, oppure assegnare relazioni di tipo parent-child o master-slave quando ci sono dipendenze tra di essi
  • controllare lo situazione dei ticket più vecchi, sollecitando risposte se mancano da diverso tempo, oppure chiuderli se si ritiene che il problema sia stato risolto
    • ignorare i ticket in stato "on hold"
Utile documentazione per il TPM è presente nella sezione "Support Staff" di GGUS, tra cui anche le informazioni sulle varie unità di supporto

Report di fine turno e passaggio di consegne

Per l'attività di controllo della grid italiana è richiesto di inviare un report di fine turno ogni lunedì, tramite la funzione di "handover" dell'operations portal. Nel report indicare:

  • ticket aperti quel giorno
  • problemi rimasti in sospeso
  • problemi generali che affliggono molti siti
  • eventuali problemi dei sistemi di monitoring
Lo scopo del report è facilitare il lavoro di chi subentra nel turno. Tutti i report saranno raccolti su base mensile in un'apposita sezione di questa wiki

Per quanto riguarda l'attività di TPM, il passaggio di consegne (handover) prevede una semplice apertura di un ticket ogni due settimane, attorno alle 14 del lunedì, quando il turno passa in carico all'altra NGI.

Il ticket va lasciato assegnato all'unità di supporto TPM e nel titolo deve comparire: shift handover from NGI_IT to NGI_DE

Una volta subentrati, i supporter della NGI provvederanno a chiuderlo

Raccolta dei report di fine turno

Nella seguente pagina sono raccolti i report ROD di fine turno

CHAT

E' disponibile una chat a cui collegarsi per comunicare durante il turno (e non solo):

  • protocollo IRC
  • server salento.cnaf.infn.it
  • porta 6667
  • stanza #CMT

Contatti

La mailing list dei ROD italiani è igi-ops-support AT lists.italiangrid.it

Essa è inserita nella mailing list che raccoglie i ROD di tutta EGI: All-operator-on-duty AT mailman.egi.eu

La mailing list del COD è central-operator-on-duty AT mailman.egi.eu

Le mailing list dei TPM sono tpm-it AT lists.italiangrid.it e tpm-de AT lists.kit.edu

Documentazione

documentazione varia

BDII e WMS per la certificazione dei siti

Il top-BDII che pubblica i siti che non sono ancora in produzione è gridit-bdii-01.cnaf.infn.it: la sua lista dei siti è questa

Il WMS che si appoggia a questo BDII è gridit-cert-wms.cnaf.infn.it

-- AlessandroPaolini - 2011-10-27

Topic attachments
I Attachment Action Size Date Who Comment
Unknown file formatconf cert-bdii-update.conf manage 8.3 K 2015-04-21 - 13:07 AlessandroPaolini lista dei siti per il bdii usato per certificae i siti - aggiunto sito di test di perugia
Edit | Attach | PDF | History: r40 < r39 < r38 < r37 < r36 | Backlinks | Raw View | More topic actions
Topic revision: r40 - 2015-11-11 - CristinaAiftimiei
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback