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