Difference: Supporters (1 vs. 40)

Revision 402015-11-11 - CristinaAiftimiei

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 15 to 15
 
  • 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
Added:
>
>
    • Ricordarsi che all'apertura di un nuovo ticket si deve impostare il reminder tra 15 giorni
 

Strumenti di Monitoring

Line: 39 to 40
 
  • 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:
Changed:
<
<
>
>
  • 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
Added:
>
>
  • 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

Revision 392015-04-21 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 130 to 130
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - cambiato site-bdii INFN-CATANIA" date="1427704626" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8369" user="AlessandroPaolini" version="16"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - aggiunto sito di test di perugia" date="1429621650" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8476" user="AlessandroPaolini" version="17"

Revision 382015-03-30 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 130 to 130
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - aggiunto INFN-PADOVA-STACK" date="1401261766" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8367" user="AlessandroPaolini" version="15"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - cambiato site-bdii INFN-CATANIA" date="1427704626" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8369" user="AlessandroPaolini" version="16"

Revision 372014-10-24 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Descrizione delle operazioni

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

Revision 362014-07-24 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 63 to 63
 Could you please provide explanation for this low value? What actions are you planning to do in order to improve the behaviour?
Changed:
<
<
the ticket will be closed when the avalability is above the threshold of 75%
>
>
the ticket will be closed when the avalability is above the threshold of 85%
  Best Regards,
Changed:
<
<
Nel testo conviene anche inserire il link all'andamento del sito mostrato sul MyEGI centrale http://grid-monitoring.cern.ch/myegi/sa/
>
>
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.

Revision 352014-05-28 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 130 to 130
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - modificato il site-bdii di infn-lecce" date="1398765820" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8258" user="AlessandroPaolini" version="14"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - aggiunto INFN-PADOVA-STACK" date="1401261766" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8367" user="AlessandroPaolini" version="15"

Revision 342014-05-08 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 52 to 52
  Nella dashboard viene visualizzato l'andamento di Availability e Reliability per ogni sito relativo ai 30 giorni precedenti.
Changed:
<
<
Dal mese di Ottobre, per quei siti con un'availability inferiore al 70%, comparirà un allarme, che dovrà essere trattato come ogni altro allarme presente sulla dashboard.
>
>
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:
Line: 67 to 67
  Best Regards,
Added:
>
>
Nel testo conviene anche inserire il link all'andamento del sito mostrato sul MyEGI centrale http://grid-monitoring.cern.ch/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

Revision 332014-04-29 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 127 to 127
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - modificato il site-bdii di legnaro" date="1392195296" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8260" user="AlessandroPaolini" version="13"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - modificato il site-bdii di infn-lecce" date="1398765820" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8258" user="AlessandroPaolini" version="14"

Revision 322014-02-12 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 127 to 127
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - cambiate le URL per i siti cloud" date="1389966756" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8260" user="AlessandroPaolini" version="12"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - modificato il site-bdii di legnaro" date="1392195296" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8260" user="AlessandroPaolini" version="13"

Revision 312014-01-17 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 127 to 127
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - aggiunto PRISMA-INFN-BARI" date="1384268370" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7958" user="AlessandroPaolini" version="10"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - cambiate le URL per i siti cloud" date="1389966756" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8260" user="AlessandroPaolini" version="12"

Revision 302013-11-12 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 127 to 127
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - corretto il nome del sito ReCaS-Bari" date="1379576198" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7869" user="AlessandroPaolini" version="9"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - aggiunto PRISMA-INFN-BARI" date="1384268370" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7958" user="AlessandroPaolini" version="10"

Revision 292013-09-19 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 127 to 127
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - aggiunto il sito ReCas-Bari" date="1377765763" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7869" user="AlessandroPaolini" version="8"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - corretto il nome del sito ReCaS-Bari" date="1379576198" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7869" user="AlessandroPaolini" version="9"

Revision 282013-08-29 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 127 to 127
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - cambiato il site-bdii di INFN-GENOVA" date="1375430912" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7796" user="AlessandroPaolini" version="7"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - aggiunto il sito ReCas-Bari" date="1377765763" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7869" user="AlessandroPaolini" version="8"

Revision 272013-08-02 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 127 to 127
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - cambiato il site-bdii di SNS-PISA" date="1366189825" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7796" user="AlessandroPaolini" version="6"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - cambiato il site-bdii di INFN-GENOVA" date="1375430912" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7796" user="AlessandroPaolini" version="7"

Revision 262013-04-17 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 127 to 127
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - cambiati in maiuscolo i nomi di molti siti" date="1357909320" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7798" user="AlessandroPaolini" version="5"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - cambiato il site-bdii di SNS-PISA" date="1366189825" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7796" user="AlessandroPaolini" version="6"

Revision 252013-01-11 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 127 to 127
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - modificata la url di trieste e torino" date="1357902250" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8022" user="AlessandroPaolini" version="4"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - cambiati in maiuscolo i nomi di molti siti" date="1357909320" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7798" user="AlessandroPaolini" version="5"

Revision 242013-01-11 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 127 to 127
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - aggiunto FBF-Brescia-IT" date="1357659326" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8021" user="AlessandroPaolini" version="3"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - modificata la url di trieste e torino" date="1357902250" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8022" user="AlessandroPaolini" version="4"

Revision 232013-01-08 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 127 to 127
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti" date="1355404186" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7935" user="AlessandroPaolini" version="2"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti - aggiunto FBF-Brescia-IT" date="1357659326" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="8021" user="AlessandroPaolini" version="3"

Revision 222012-12-13 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 127 to 127
 -- AlessandroPaolini - 2011-10-27
Changed:
<
<
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti" date="1355329267" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="9135" user="AlessandroPaolini" version="1"
>
>
META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti" date="1355404186" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="7935" user="AlessandroPaolini" version="2"

Revision 212012-12-12 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 119 to 119
  documentazione varia
Added:
>
>

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

META FILEATTACHMENT attachment="cert-bdii-update.conf" attr="" comment="lista dei siti per il bdii usato per certificae i siti" date="1355329267" name="cert-bdii-update.conf" path="cert-bdii-update.conf" size="9135" user="AlessandroPaolini" version="1"

Revision 202012-11-09 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 6 to 6
 
  • 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
Changed:
<
<
  • 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
>
>
  • 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).

Revision 192012-11-05 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 12 to 12
 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.
Changed:
<
<
  • 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.
>
>
  • 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)
Line: 25 to 25
 
  • 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
Changed:
<
<
Per quanto riguarda l'escalation dei ticket aperti tramite la Regional Dashboard bisogna seguire la procedura descritta nel COD Escalation Procedure.
>
>
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:

Revision 182012-10-10 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 63 to 63
 Could you please provide explanation for this low value? What actions are you planning to do in order to improve the behaviour?
Changed:
<
<
the ticket will be closed when the avalability is above the threshold of 70%
>
>
the ticket will be closed when the avalability is above the threshold of 75%
  Best Regards,
Changed:
<
<
il ticket potrà essere chiuso quando l'allarme tornerà nello stato OK, ovvero quando l'availability avrà superato la soglia minima del 70%: onde evitare riaperture repentine, conviene aspettare qualche giorno accertandosi che l'availability sia davvero in aumento
>
>
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

Revision 172012-10-08 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 63 to 63
 Could you please provide explanation for this low value? What actions are you planning to do in order to improve the behaviour?
Changed:
<
<
the ticket will be closed when the avalability will be above the threshold of 70%
>
>
the ticket will be closed when the avalability is above the threshold of 70%
  Best Regards,

Revision 162012-10-08 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 57 to 57
 Andrà pertanto aperto un ticket, possibilmente con il seguente testo:
Dear site-admin,
Changed:
<
<
in the past 30 days period your site has achieved poor performance,
>
>
in the last 30 days period your site has achieved poor performance,
 in particular an Availability value of

Could you please provide explanation for this low value?

Added:
>
>
What actions are you planning to do in order to improve the behaviour?
  the ticket will be closed when the avalability will be above the threshold of 70%

Revision 152012-10-05 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 48 to 48
 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

Added:
>
>

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.

Dal mese di Ottobre, 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 past 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?

the ticket will be closed when the avalability will be above the threshold of 70%

Best Regards,

il ticket potrà essere chiuso quando l'allarme tornerà nello stato OK, ovvero quando l'availability avrà superato la soglia minima del 70%: 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.

Revision 132012-05-28 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 61 to 61
 
  • 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
Changed:
<
<

Report di fine turno e passaggio di consegne

>
>

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

Added:
>
>

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

Revision 122012-05-28 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Line: 68 to 68
 
  • problemi rimasti in sospeso
  • problemi generali che affliggono molti siti
  • eventuali problemi dei sistemi di monitoring
Changed:
<
<
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
>
>
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.

Revision 112011-12-12 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Added:
>
>
 

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)
Line: 88 to 90
  La mailing list del COD è central-operator-on-duty AT mailman.egi.eu
Changed:
<
<
Le mailing list dei TPM sono tpm-it AT lists.infn.it e tpm-de AT lists.kit.edu
>
>
Le mailing list dei TPM sono tpm-it AT lists.italiangrid.it e tpm-de AT lists.kit.edu
 

Documentazione

documentazione varia

Revision 102011-11-24 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Descrizione delle operazioni

Revision 92011-11-04 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Descrizione delle operazioni

Line: 17 to 17
 

Strumenti di Monitoring

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

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

Revision 82011-11-04 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Descrizione delle operazioni

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

Changed:
<
<
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).
>
>
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 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
Changed:
<
<
  • Controllo dei dati di accounting: verificare la regolare pubblicazione dei dati di accounting, seguendo queste indicazioni
>
>
 

Strumenti di Monitoring

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

Line: 73 to 73
 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

Added:
>
>

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

Line: 82 to 89
 La mailing list del COD è central-operator-on-duty AT mailman.egi.eu

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

Added:
>
>

Documentazione

documentazione varia

  fgvfvhhkfv

Revision 72011-10-28 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Descrizione delle operazioni

Line: 13 to 13
 
  • 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
Added:
>
>
  • Controllo dei dati di accounting: verificare la regolare pubblicazione dei dati di accounting, seguendo queste indicazioni
 

Strumenti di Monitoring

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

Line: 44 to 45
 
  • Cambiare lo stato del ticket in “in progress” quando si risponde la prima volta
Il turnista dovra' inoltre rispondere ai ticket fornendo supporto ai site-manager, eseguire delle diagnosi sui problemi occorsi e cercare di fornire una soluzione.
Changed:
<
<
Un altro compito importante è la certificazione dei siti, seguendo la procedura prevista in questi casi
>
>
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.

Line: 69 to 70
  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.
Changed:
<
<
Il ticket va lasciato assegnato all'unità di supporto TPM e nel titolo deve ripotare: shift handover from NGI_IT to NGI_DE
>
>
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

Contatti

Revision 62011-10-28 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Descrizione delle operazioni

Line: 16 to 16
 

Strumenti di Monitoring

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

Changed:
<
<
  • 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.
>
>
  • 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
Line: 35 to 35
 
  • 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)
Deleted:
<
<
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
Line: 44 to 42
 
    • 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
Added:
>
>
Il turnista dovra' inoltre rispondere ai ticket fornendo supporto ai site-manager, eseguire delle diagnosi sui problemi occorsi e cercare di fornire una soluzione.
 
Added:
>
>
Un altro compito importante è la certificazione dei siti, seguendo la 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.

Line: 58 to 58
 
  • 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
Added:
>
>

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 ripotare: shift handover from NGI_IT to NGI_DE

Una volta subentrati, i supporter della NGI provvederanno a chiuderlo

 

Contatti

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

Revision 52011-10-28 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Descrizione delle operazioni

Line: 47 to 47
 

Attività TPM

Changed:
<
<
ljghljg
>
>
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.
 
Changed:
<
<
ljglgulgvfgv
>
>
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

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.infn.it e tpm-de AT lists.kit.edu

fgvfvhhkfv

  -- AlessandroPaolini - 2011-10-27 \ No newline at end of file

Revision 42011-10-28 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Descrizione delle operazioni

Line: 45 to 45
 
    • In caso, coinvolgere gli sviluppatori
  • Cambiare lo stato del ticket in “in progress” quando si risponde la prima volta
Added:
>
>

Attività TPM

ljghljg

 ljglgulgvfgv

-- AlessandroPaolini - 2011-10-27

Revision 32011-10-27 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Descrizione delle operazioni

Line: 33 to 33
 
  • 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
Changed:
<
<
Il turnista dovra' inoltre rispondere ai ticket fornendo un primo supporto ai site-manager e seguire i problemi possibilimente fino alla loro soluzione.
>
>
  • 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
  ljglgulgvfgv

Revision 22011-10-27 - AlessandroPaolini

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

Descrizione delle operazioni

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

Changed:
<
<
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).
>
>
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
Added:
>
>

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
Changed:
<
<
  • il portale GSTAT mostra le informazioni pubblicate dai siti e segnala eventuali errori od incongruenze
>
>
  • 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
Changed:
<
<
Per quanto riguarda l'escalation dei ticket aperti tramite la Regional Dashboard bisogna seguire la procedura descritta nel COD Escalation Procedure (altre indicazioni utili nell'SA1 Operational Procedures Manual)).
>
>
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:

 
Added:
>
>
  • 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
 Il turnista dovra' inoltre rispondere ai ticket fornendo un primo supporto ai site-manager e seguire i problemi possibilimente fino alla loro soluzione.

ljglgulgvfgv

Revision 12011-10-27 - AlessandroPaolini

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="WebHome"

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
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 (altre indicazioni utili nell'SA1 Operational Procedures Manual)).

Il turnista dovra' inoltre rispondere ai ticket fornendo un primo supporto ai site-manager e seguire i problemi possibilimente fino alla loro soluzione.

ljglgulgvfgv

-- AlessandroPaolini - 2011-10-27

 
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