 |
 |
Dear All, CIC on Duty escalation goes the following. Sites have different priorities depending on their number of CPUs. Those that have 'Low' or 'Normal' priority, have 3 working days to fix problems, while sites with 'High' priority have only 1 working day. When a problem occurs on a site, first the mail is sent to both the site and the responsible ROC. After the above metnioned days, if the problem still holds, the second e-mail is only sent to the ROC. More details about the Escalation Procedure can be found in the Operational Manual: http://lcgdeploy.cvs.cern.ch/cgi-bin/lcgdeploy.cgi/lcg-docs/EGEE-CIC-Operational-Manual/opMan.pdf (linked from https://cic.in2p3.fr/index.php?id=cic&subid=cic_dash2&js_status=2) Judit On k, nov 08, Flavia Donno wrote: > Dan, > the escalation tickets are sent automatically and I then agree with you. > The GGUS TPM (Ticket Processing Managers) normally contact supporters to > make sure an answer is provided before an escalation e-mail is generated. > For CIC-on-Duty (COD), this should be taken care by the COD team. They > normally allow for 3 working days (if I am not mistaken - Piotr or Judit > can correct me ...) before contacting the site. > > Flavia > > Dan Schrager wrote: > > >Hi Flavia, > > > >I don't know exactly how escalation is started; if an escalation > >ticket is generated by a human, then he should check first whether the > >problem reported in the first place is still there and only if it is > >still unsolved he should press the escalation button; if the > >escalation is triggered by a computer after a certain amount of time, > >the original ticketer should be so kind to check the status of the > >problem (using the same means he used when noting the problem at > >first) before escalation occurs and if so is the case he should close > >the ticket himself. > > > >Regards, > >Dan > > > > > >Flavia Donno wrote: > > > >>Dear Dan, > >> > >>Dan Schrager wrote: > >> > >>>Hi everybody, > >>> > >>>I have noticed that it appears to be a problem related to the way > >>>tickets are handled in general. > >>> > >>>I have received tickets from various issuers and then in order to reply > >>>to them I had to get access to various centers. > >>> > >>>I find this situation wrong and I would suggest that the "ticketer" > >>>first assesses which regional organization the "offending" site is > >>>part > >>>of and then submits the ticket through that regional organization > >>>designated office. > >> > >> > >> > >>I agree with you. The ticketer does not really need to assess which > >>regional organization the offending site is part as this information > >>is published and therefore known. > >> > >>> > >>>This would mean for the "ticketers" to get access to all regional > >>>offices. > >>>Since there are far less "ticketers" than "ticketees" (I could guess it > >>>from the fact that I am a "ticketee" but not a "ticketer") this > >>>would be > >>>better than ending up with all "ticketees" getting access to all > >>>regional offices. > >>> > >>>Don't you agree ? > >> > >> > >> > >>I totally agree. > >> > >>>There is another issue related to escalation. > >>>I would suggest that escalation should occur only if the reported > >>>problem is not solved at site level. > >>> > >>>Escalation should not happen just because a ticket has been ignored > >>>for too long (while the problem is already gone, in a cab, divine > >>>intervention, etc.). > >>>"Ticketees" may prefer to solve the problem first and then ignore a > >>>ticket for lack of access to "ticketer"'s office. > >> > >> > >> > >>I do not agree with this since there is the danger that a ticket gets > >>totally ignored. > >>The person responsible for the ticket, assigning the ticket to the > >>ROC, should also make sure that an answer is provided. Therefore > >>he/she needs to be notified if nothing is happening. > >> > >>>Some human intervention would be required to close the ticket from > >>>"ticketer"'s part. He is, after all, the one who generated the > >>>ticket. And there are a few "trigger-happy" "ticketers", for sure... > >> > >> > >> > >>:-) > >> > >>Flavia > >> > >>+++++++++++++++++++++++++++++++++++++++++++ > >>This Mail Was Scanned By Mail-seCure System > >>at the Tel-Aviv University CC. > > > > > >