User Support User Support

Overview

EMI takes care of the user support for incidents in its middleware services. Customers such as the EGI infrastructure propagate tickets from their user support systems in case they are proven incidents of EMI components. These tickets are dealt with by EMI support staff and the solutions are returned back to the customer.

EMI uses the GGUS (Global Grid User Support) tool as its user support system. Users can get support and send requirements via GGUS. GGUS development started within the EGEE projects, and it is currently developed and deployed in the framework of the EGI-InSPIRE project. Using the same tool at both sides, infrastructure and middleware, simplifies the interface between them. GGUS provides EMI with sophisticated search functionality, report generation, interfaces to bug tracking systems used by different middleware components, and automatic ticket reminder including escalation indication.

EMI support is organized in Support Units (SUs), one for each product or group of components plus a generic EMI SU. Supporters involved in a SU are notified when a ticket gets assigned to their SU, so they can process it immediately. Priorities indicate the urgency for a solution to an incident and service level agreements with the EMI customers specify the time frame in which tickets have to be dealt with.

Purpose

EMI is developing Grid middleware services which are taken by Grid infrastructures and deployed and maintained on the infrastructure for their users. While the Grid infrastructures are supporting the end users EMI is supporting the infrastructures.

The EMI support team is collaborating with the user support channels of the infrastructure providers: EMI is doing 3rd level support from the end-user's perspective. Here the experts of the different services provide guidance and software enhancements or fixes for their services.

Who Are the "Users"?

Having infrastructures as customers the users of the EMI support are primarily the supporters of the infrastructures. They escalate tickets which are proven incidents of EMI components to the EMI tracking system.

Services

EMI provides a set of services related to the development, maintenance and support of its distributed computing middleware. The services are mainly targeted at infrastructure managers and site administrators, but end users are encouraged to contribute with comments and requests. EMI currently provides the following services:

EMI Service Catalogue

Service name

Description
Software releases EMI provides releases of its distributed computing middleware to infrastructure administrators and individual users based on its standard release policies and the requirements received by users
Requirements Analysis EMI in collaboration with infrastructure managers, application and software developers and end users performs analysis and prioritization of the user requirements as the first step of the provision of targeted middleware components bringing value to the users
Requirements and software testing reports As part of the specific agreement with each individual customer, EMI provides reports on the implementation of agreed requirements and the execution of agreed acceptance tests provided by the customer on its major releases
Web-based Support EMI provides support to site administrators and end users through a web-based support system called GGUS and managed by EGI 

 

The described services are provided according to the Policies described in the nest section.

The service levels for the provision of the services to Infrastructure Managers is regulated by specific Service Level Agreements signed with each EMI customer. The provision of requirement analysis and support services to end users is not in general regulated by SLAs, but provided by EMI with standard service levels that depend on the available effort and existing priorities at any give time.

Policies

Software Release Policy

The EMI release policy aims at striking a good balance between the conflicting requirements of stability and innovation. 

 
All EMI products are grouped in  a distribution. The distribution is released in periodic major releases, tentatively delivered once a year in April 2011 (Kebnekaise), April 2012 (Matterhorn) and February 2013 (Monte Bianco).
Each major release is characterized by well-defined interfaces, behavior and dependencies for all included products, available on a predefined set of platforms. 
 
Within an EMI major release, each middleware component follows an independent release cycle, but must preserve backward compatibility both at build- and at run-time. Backwards-incompatible changes can only introduced as part of a new EMI major release. 
 
Any proposed change (both bug fixes and new features) to the middleware components in a distribution, even if they are backward compatible, are released only if their priority is high enough, otherwise are postponed to the next suitbale opportunity. The priority of a change is evaluated by EMI together with its customers based on its severity, impact, urgency and cost. 
 
The individual releases of middleware components wihin an EMI major release are released according to an agreed scheduled that takes into account the need to release in timely way, but not so often to disrupt regular operations of the infrastructure. However, patches to fix critical issues or serious security vulnerability are handled with a special emergency procedure and can be delivered in a matter of hours. 

Software Maintenance Policy

The software released by EMI is maintained and supported for a fixed period of time. EMI supports all components of two major release of the EMI distribution, that is all the components included in the current major release and those included in the previous major release on all supported platforms of each release. A certain version of a component can of course be part of both EMI major releases, in which case the support policy of the current release apply. The following support and end-of-life policies are provided for each major release of a component in an EMI distribution release: 

Type: Full support
Duration: 12 months since the first release date
Description: full support means that the component is maintained and actively developed and may receive both fixes and new backward-compatible functional changes within the current EMI major release. The changes are prioritized according to their severity, impact and cost and scheduled to be released according to their priority.
 
Type: Standard support
Duration: 6 months since the end of the full support period
Description: standard support means that the component has been replaced by a new major version and it is maintained but not actively developed. It may receive fixes and functional changesof high priority according to their severity, impact and cost.
 
Type: Critical support
Duration: 6 months since the end of the standard support period
Description: critical support means that the component has been replaced by a new major version and it is not maintained nor actively developed. It may only receive fixes addressing security vulnerabilities with a target date 
falling within the six month period (see https://wiki.egi.eu/wiki/SVG:RAT_Issue_Handling_Instructions 
for more information). 
 
User Support Policy

EMI is committed to provide adequate support to all the users of its software products. EMI provides expert technical support to infrastructure administrators and users in case issues are found that require changes in the code. The preferred channel to do submit a bug report is the GGUS system maintained by EGI (https://gus.fzk.de/). Issues related to the middleware services are first analysed by EGI support teams and escalated to EMI in case of need. 

When submitting a ticket, provide as much information as possible on the issue and how to reproduce it and follow the guidelines specified in the documentation available in GGUS. An important field in the GGUS submission form is the "Priority", which helps us in assessing the ticket and plan the mainteance work. Please note that the field that GGUS calls "Priority" is actually the "Severity" of issue as assessed by the person submitting the request. Four values are possible, with the following meanings: 
 
Top priority:   service interrupted; needs to be addressed as soon as possible 
Very urgent:  service degraded; no work-around available 
Urgent:           service degraded; work-around available 
Less urgent: wishes and enhancements that are "nice to have" 
 
(see https://gus.fzk.de/pages/help/help_sub_prio.php for more information) 
 
Our target response time for each of the levels is typically 1 day for Top priority, 3 days for Very urgent, one 
week for Urgent and two weeks for Less urgent. The response is the first direct ackowledgement that the ticket has been assigned to an EMI developer and it is not an indication that a solution is available. The time needed 
for the solution cannot generally be predicted, since it depends on the complexity of the issue and on the priority assigned to it. The priority depends on the severity assigned by the user in GGUS, but takes also into account the scope and complexity of the required changes, the impact the infrastructure, the cost to provide a solution in terms of effort. The actual target response times are specified for each EMI customer as part of a SLA and may vary from the above depending on the agreement. 
 
If the investigation of an issue leads to the identification of a defect in the software, the fix will be provided at the next best opportunity depending on the priority and as specified in the software release policy. 
 
Service Level Agreements

The actual service levels for the services provided by EMI are negotiated with each customer and described in a Service Level Agreement (SLA) signed by EMI and the customer. The SLA contains detailed information on items such as the agreed definitions of the priority and severity values, the expected reaction times, the estimated time to solution for different types of issues, etc. The standard EMI SLA can be found here.

Contributed by: Mathilde Romberg and others.