Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

TSA2.5 Deployed Middleware Support Unit

From EGIWiki
Jump to navigation Jump to search

DMSU people and expertise

DMSU_People_Institutes page provides the list of people with their expertise.

Ticket handling procedure

The purpose of DMSU work is twofold: to find solution to problems problems which do not require changes in code, documentation, ... (whatever is released by the TP), and to provide thorough analysis, yielding well-specified bug report otherwise.

The following ticket handling guidelines contribute to achieving these goals:

  • The first mandatory step of DMSU work on a ticket is understanding what is the reason of the reported problem. The outcome of the analysis is documented with the ticket, preferably as a response to the user. The analysis may or may not include thorough reproduction of the problem; it is left to common sense.
  • During the analysis DMSU also assesses the priority of the ticket (see bellow) and adjusts Type of problem and Ticket category fields eventually.
  • Typically, the analysis involves communication with the users. DMSU sets ticket state to Waiting-for-reply whenever expecting feedback by the user. It is foreseen GGUS will implement automatic switch to In-progress when the user answers.
  • DMSU expertise should cover most tickets. When necessary developers (i.e. the 3rd line support) can be involved for brief consultation. As long as no considerable effort is required from the 3rd line support, the control on the ticket is still kept within DMSU, i.e. the ticket is not reassigned to another support unit. On the other hand, tough issues when DMSU expertise runs out should be still reassigned.
  • If solution of the problem does not induce changes in code, documentation, default configuration etc., i.e. release of anything by the technology provider, DMSU closes the ticket.
  • Otherwise, the ticket is reassigned to the appropriate 3rd line support unit. In this case, the most recent comment (i.e. on reassignment) should contain a brief summary of the DMSU analysis on the ticket, pointing to what is wrong exactly, how to reproduce the problem etc., so that 3rd line supporters don't have to gather all information from the ticket correspondence, which tends to be rather long.

A special case are tickets that were solved in DMSU but they require comment by th 3rd line, i.e. to confirm feasibility of the solution. Those tickets should be closed in DMSU just with a comment indicating the 3rd line was contacted, and the 3rd line approached by other means. The standard GGUS workflow must not be used for this communication, in order to keep the statistics clean, mostly.

If a ticket is wrongly assigned to 3rd line support, i.e. the problem is quite simple and it should have been solved by DMSU preferably, then:

  • 3rd line support reassign back the ticket to DMSU. A comment pointing to appropriate documentation or giving justification why this is a trivial issue must be given in this case.
  • this mechanism will be used as a metric of DMSU failures, and checked thoroughly, therefore it should not be abused.

When the user does not react on a raised question, she is typically reminded weekly, on the DMSU meetings. If there is no reaction for more than one month, the ticket is closed as unsolved.

Ticket priorities

In GGUS, tickets are classified to 4 priority levels. Middleware ticket handling in DMSU and 3rd line support differs according to their priority as described bellow.

Top Priority

Issues which affect the entire infrastructure, its significant portion, or a very large number of users, with paralyzing impact. Immediate reaction is required.

DMSU reaction -- immediate within working hours. DMSU work is restricted to assessment whether the ticket really deserves Top-priority category, no thorough analysis is done for the sake of speed. The ticket is reassigned to 3rd line support unit immediately.

TP reaction -- typically, SLA guarantees 4 hour reaction. The reaction should contain estimation of ETA (Estimated Time of Arrival of the fix). The time is not formally bounded, however, it should be within a few days.

ETA monitoring the top priority tickets are quite rare, currently we evaluate ETA manually.

Very Urgent

Issues of broad impact, where no workaround is known or feasible.

DMSU reaction -- preferably on the same day, the ticket handling guidelines above apply, however, the ticket should not be delayed for more than 2 working days before reassignment to 3rd line.

TP reaction -- typically, SLA guarantees 2 working days. The problem is expected to be fixed in 45 days, typically in the next scheduled bugfix release.

ETA monitoring -- support in GGUS will be required, to be negotiated, though not urgent, the number of very-urgent tickets is quite low too.


Urgent

Less Urgent

Followup of tickets with 3rd line support units

DMSU shifts

The main purpose of DMSU shift is no surprise: keep the things running, not to leave an important issue without fast reaction etc.

The shifts are held by groups of people with expertise on different middleware stacks. However, due to the prevailing gLite-related traffic in DMSU only gLite shifts are formally organized currently, the other stacks are handled on the best effort basis.

The specific duties of the person on shift are:

  • to follow incoming emails from GGUS, being able to react within approx. 2 hours in normal working hours
  • to identify "top priority" and "very urgent" issues, not only by the priority set by the submitter but also by using common sense, and to make sure an appropriate expert starts looking into the issue; this includes assigning the ticket to a specific person
  • to keep checking that there is reasonable response time, namely as a reaction to further submitter's correspondence; it should be almost immediate on "top priority", and we can probably afford upto 1 week for "less urgent"

One person holds the shift for one week, the duty is passed to the other on Monday afternoon.

Shift schedule

Dec 5 Zdeněk Salvet
Dec 12 INFN
Dec 19 Aleš Křenek
Dec 26 best effort
Jan 2 Aleš Křenek
Jan 9 Alessandro Paolini
Jan 16 Zdeněk Salvet
Jan 23 Sergio Traldi
Jan 30 Aleš Křenek
Feb 06 Sara Bertocco

DMSU Digests

Brief description and indexing of issues solved within DMSU that are likely to have broader impact on EGI Operations.

Maintained on separate page Middleware_issues_and_solutions

Operations Documentation

DMSU contributes to maintenance of EGI Operations_Manuals, in particular


Systems available for DMSU

In order to debug issues and design workaround availability to some systems is needed. DMSU_machines page contains the list of systems available for the DMSU staff per partner.

Obsolete stuff

DMSU_Old_Stuff

Not used anymore but keeping the old links here.