Difference: Supporters (1 vs. 40)

• 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

• Controllo dei dati di accounting: verificare la regolare pubblicazione dei dati di accounting, seguendo queste indicazioni (pagina vecchia su xoops)

Strumenti di Monitoring

• 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)

• 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

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

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

Descrizione delle operazioni

• 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

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• cert-bdii-update.conf: lista dei siti per il bdii usato per certificae i siti

• 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

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).

pagina vecchia su xoops

• Gestione ticket vecchi: Verificare, una volta al giorno, lo stato dei ticket.

• 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
• Controllo dei dati di accounting: verificare la regolare pubblicazione dei dati di accounting, seguendo queste indicazioni (pagina vecchia su xoops)

• il portale GSTAT mostra le informazioni pubblicate dai siti e segnala eventuali errori od incongruenze

Azioni

Alcune indicazione su come comportarsi con allarmi e ticket:

Attività TPM

Dear site-admin,

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

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.

• 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"

• ticket aperti quel giorno
• problemi rimasti in sospeso
• problemi generali che affliggono molti siti
• eventuali problemi dei sistemi di monitoring

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

CHAT

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

• problemi rimasti in sospeso
• problemi generali che affliggono molti siti
• eventuali problemi dei sistemi di monitoring

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)

Documentazione

documentazione varia

Descrizione delle operazioni

Descrizione delle operazioni

Strumenti di Monitoring

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

• 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

Descrizione delle operazioni

• 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

• 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:

Una volta subentrati, i supporter della NGI provvederanno a chiuderlo

Contatti

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

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

Descrizione delle operazioni

• 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:

• Cambiare lo stato del ticket in “in progress” quando si risponde la prima volta

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.

Contatti

Descrizione delle operazioni

Strumenti di Monitoring

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

• 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

• 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)

• Controllare se il messaggio d’errore è tra quelli noti, in modo da poter già fornire una soluzione oppure chedere di controllare alcune cose specifiche

• • 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

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.

• 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"

Contatti

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

Descrizione delle operazioni

Attività TPM

Descrizione delle operazioni

• • In caso, coinvolgere gli sviluppatori
• Cambiare lo stato del ticket in “in progress” quando si risponde la prima volta

-- AlessandroPaolini - 2011-10-27

Descrizione delle operazioni

• 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

Descrizione delle operazioni

• 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

• 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

• 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.

• il portale MyEGI mostra l'esito dei test lanciati da Nagios sulle varie macchine monitorate

ljglgulgvfgv