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.

Difference between revisions of "EGI Software Component Delivery"

From EGIWiki
Jump to navigation Jump to search
Line 1: Line 1:
<br> <br> DRAFT<br>
{{Template:Op menubar}} {{Template:Tools menubar}}


{{TOC_right}}


EMI SLA: https://documents.egi.eu/secure/ShowDocument?docid=461
= Initial activities  =


https://wiki.egi.eu/wiki/Instructions_for_Operations_Tools_teams
'''Goal: Introducing new Component.''' <br>Every new Component will be introduced concacting TBD_WHO providing following data:


https://wiki.egi.eu/wiki/EGI_Software_Provisioning
#Name of the Component
#Contacts (support email address, web site address)
#Name and contact details of the person Responsible for the Component
#Description of the Component/Purpose
#License<br>


TP UA: https://documents.egi.eu/document/2282
With the help of the EGI URT team, the following steps need to be performed:


UMD  Software  Provisioning Process https://wiki.egi.eu/w/images/c/ca/UMD_Software_Provisioning_Process_summary.pdf
#Registration in GOC&nbsp;DB under EGI.eu NGI
 
#Create category in "Requirements" queue in EGI&nbsp;RT tracker and RT dashboard to receive and handle service requests&nbsp;
= EGI Software Component Delivery  =
#Create GGUS Support Unit to receive and handle incidents (define level of quality of support - default: Medium)
 
#Negotiate and sign Technical Provider Underpinning Agreement (TP UA) https://documents.egi.eu/document/2282 with EGI.eu<br>
== Component roadmap and release plan ==
#Create wiki entry for the tool with relevant information
 
#*Component name
The Provider will publish a roadmap for each component it wishes to release to EGI. The roadmap may be consolidated into one document with the roadmaps for other components if the Provider releases more than one component to EGI. The roadmap must contain:  
#*Category, Short description of the Component  
 
#*URL
*All planned major component releases
#*Contact TBD_needed a EGI.eu contact for each Component and a Provider contact for EGI.eu
*All planned minor component releases
#*GGUS Support Unit
*Planned new features in the component
#*GOC&nbsp;DB entry
*Incompatibilities between releases
#*link to related TP UA
#*link to documentation
#*license
#*provider name
#*link to source code
#*Change management:
#**link to EGI&nbsp;RT dashboard for the tool
#**(if applicable) internal bug/task tracking facilities
#**(if applicable) link to OTAG team<br>
#*Release and Deployment management:&nbsp;
#**Release schedule
#**Release notes
#**(if applicable) Roadmap
#**URL of test instance


<br>  
<br>  


The Provider will update the roadmap(s) every half year (six calendar months) at least one calendar month before EGI publishes the UMD Roadmap on its scheduled dates [Błąd: Nie znaleziono źródła odwołania: https://documents.egi.eu/public/ShowDocument?docid=100 - UMD Roadmap 2010, https://documents.egi.eu/public/ShowDocument?docid=272 - UMD roadmap 2011, https://documents.egi.eu/public/ShowDocument?docid=612 - UMD roadmap 2012]
= Ongoing activities<br> =
 
<br>
 
The Provider will make available a release plan for each component published in the Provider’s software repository. The Provider may consolidate release plans of more than one component into a consolidated series of one or more documents, for a better overview. The release plan must provide the planned release dates for all maintained software components for at least one year into the future and must include the release dates for
 
*All major releases
*All minor releases
 
Technology Provider agrees to inform EGI whenever the release plan is changed.
 
<br>  


Release delivery and format
== Change management <br>  ==


The Provider agrees to deliver releases on a regular basis and provides electronic access to the release contents as described in [Błąd: Nie znaleziono źródła odwołania]. The new release must be delivered by creating a tracker artefact in GGUS containing XML based technical description of the release [Błąd: Nie znaleziono źródła odwołania]. <br>
'''Goal:&nbsp;To ensure changes are planned, approved, implemented and reviewed in a controlled manner to avoid adverse impact of changes to services or the customers receiving services. '''


== Quality Assurance  ==
[[Image:CM.png|600px|CM.png]]


The Provider understands and accepts the Software Provisioning Process as described in EGI-InSPIRE Milestone MS503 [Błąd: Nie znaleziono źródła odwołania - https://documents.egi.eu/public/ShowDocument?docid=68] and its designated successors.
=== Record  ===


=== Acceptance Criteria ===
#'''EGI recording system''' is [http://rt.egi.eu EGI RT]&nbsp;
#'''EGI&nbsp;user''' are instructed to submit changes requests in EGI&nbsp;RT.
#If the Component has '''other customers than EGI,''' the Provider will inform EGI about submitted change requests from other customers.
#Minimum set of statuses of entry
#*New - newly recorded in system
#*Accepted - accepted by AG/OMB
#*Rejected - rejected by AG/OMB
#*In progress/Open - TP is working on the request<br>
#*Resolved - released
#*Stalled - on hold


The evolution of acceptance criteria is a normal process considering the settings within which EGI and the Provider operate. <br> Through active participation in the TCB the Provider advises EGI on the effort required to implement any changes to generic or specific acceptance criteria that may affect any of the maintained software components that are part of, or considered to be part of, the UMD.
=== Classify<br> ===


=== Test plans  ===
#All change requests should be '''classified in consistent manner'''. Classification in EGI RT is based on the Component the request is related to. <br>
#TP should define list of '''standard change '''requests (a Change that is recurrent, well known, has been proceduralized to follow a pre-defined, relatively risk-free path, and is the accepted response to a specific requirement or set of circumstances, where authority is effectively given in advance of implementation.). Standard change request '''doesn't need approval''' to be implemented.
#'''Emergency change''' for the Component are the highest priority change related to '''security vulnerability '''and can be implemented '''without approval '''but will be '''subject of post-review'''.


The Provider agrees to formally provide or make available to EGI the complete test plans and results of continuous testing and integration of each maintained software component.
=== Assess and Approve<br>  ===


The test plan for a given release of one particular component must include:  
#Each change request should be commented by the TP with assessment of work needed to implement change.
#'''Every change''' which is not a standard change or emergency change '''should be assessed '''(prioritized)'''and approved '''internally, in the URT and with OMB.
#Where needed dedicated [[AG|Advisory Group]] can be set up. The AG mandate is to help the TP in requirement prioritization and releasing process of the Component. AG provide forums to discuss the tools evolution that meet the expressed needs of the EGI community. It has representation from the all end users groups depending on the tool.<br>
#Minimum set of value for prioritization:  
#*None (in RT - 0)
#*Low (in RT - 1)
#*Normal (in RT - 2)
#*High (in RT - 3)
#*Immediate/emergency (in RT - 4)


*All tests available, or at least an executive overview of all tests available
=== Implement, release and deploy<br> ===
*The complete, detailed list of all tests executed for the given release of given component
*The complete, detailed result of each executed test
*References to and descriptions of any required 3<sup>rd</sup> party software necessary to execute the test plans.


<br>  
Phase which take place in Release and Deployment process (see below).<br>  


The test plan as described above must be made available to EGI prior to the planned release date for review:
=== Review<br>  ===


*Major release: At least 20 working days
#Every release is subject to '''post-implementation review'''. Within one week customers are providing feedback answering to following questions:  
*Minor release: At least 15 working days
#*Were release notes and documentation sufficient?
*Revision release: At least 10 working days
#*Is the tool working as expected?<br>
*Emergency release: N/A


<br>
== Release and deployment management  ==


Prior to entering EGI’s Software Provisioning Process [Błąd: Nie znaleziono źródła odwołania] and upon request of EGI’s appropriate management unit, the Provider, in collaboration with EGI, agrees to the best of their ability to:
'''Goal: To bundle changes to release, so that these changes can be tested and deployed to the production environment together.'''


*Rerun the complete test plan for major releases
[[Image:RnDM.png|700px|RnDM.png]]
*Run a subset of the tests of the test plan (chosen by EGI) for minor releases


<br>
=== Plan Release  ===


== Issue management ==
#Release schedules should be defined - the frequency of releases (eg. every 1-2 month).<br>
#Scope of every release should be defined.
#Release should be planned in a away that OMB can be informed in at least one week time in advance.
#*all planned releases should be presented during the monthly OMB meeting prior to their release to production
#*emergency releases should be presented at the first available OMB meeting, post-release.


The Provider has appointed personnel for technical issues concerning the maintained software components. Those technical contacts must be fully authorised to act as the Provider’s representative in collaboration with EGI DMSU [Błąd: Nie znaleziono źródła odwołania] regarding the triaging, assessment and resolution of any technical issues concerning the software components developed and maintained by the Provider. <br>  
=== Build Release<br> ===


=== Issue management infrastructure ===
#Due to the open-source nature of the developed software, each Component should have/use a '''publicly available code repository,''' like SVN, CVS, GIT
#*preferred Software Versioning Control system - GITHUB (https://github.com/)
#All new releases should correspond to a new '''tag''' in the SVC
#*the Component should be packaged in an OS native format (e.g. rpm, deb)
#**packaging standards and policies should be followed (ex: [http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard FHS], [https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies EPEL-GuidelinesAndPolicies], [https://www.debian.org/doc/debian-policy/ Debian Policies])
#Distribution
#**new releases should be distributed as binaries through the UMD repository


EGI uses GGUS for 2<sup>nd</sup> level (DMSU) support. For 3<sup>rd</sup>-level support, EGI provides the Technology Provider with a provider-specific Support Unit (SU) in GGUS as 3<sup>rd</sup> level support interface. Monitoring and reporting of provider performance is implemented through this SU.
=== Test Release  ===


<br>  
#Testing of the software, prior to its release, is a '''responsibility of the Provider.'''
#Where dedicated '''AG''' exists it can be involved in the testing activity.
#'''Major or particularly important releases''' should pass acceptance testing performed by customer representatives
#When the development phase of a new release is completed an announced it should be shared in the URT and to all the actors that should be involved in the release testing (AGs). The announcement should contain:
#*release notes, containing changelog, installation &amp; configuration steps to apply the update, any known issues
#*documentation links
#*detailed test plan<br>  
#*all the information needed by the [https://wiki.egi.eu/wiki/EGI_Quality_Criteria_Dissemination conformance criteria] set by the SA2 activity for the software providers.
#*the expected release date and the kind of testing will depend on each specific release and on its importance.
#'''If a test fails''' a report will be produced and the release sent back to development to restart the cycle. Tests will include a documentation review and a documentation update if needed. The test phase can be performed internally to the development team if no other components or services are affected.


=== Issue Resolution ===
=== Document ===


The Provider constructively works in close collaboration with EGI DMSU on jointly investigating issues raised against software components maintained by the Provider. The investigation includes triaging the issue or incident, the problem and any known impacts. The details of the process of collaboration with the DMSU are outlined in [Błąd: Nie znaleziono źródła odwołania].  
#'''The Provider is responsible for creation and maintenance of documentations''', instructions and manuals related to the Component in collaboration with EGI Operations team.  
#Before each release documentation should be checked and updated when/where needed.<br>


<br>
=== Inform  ===


In case the triage resolves to the production of a new release of the affected software component DMSU and the service provider jointly agree on an Estimated Time of Availability (ETA) of the necessary new release of that software component.<br>
#'''Information about next release '''should be communicated
#*'''during OMB&nbsp;meeting''' (at least one week before release).  
#**One slide information should be sent to urt-discuss@egi.eu


The Provider agrees to prioritise the effort to resolve and fix reported issues according to their priority as set in GGUS, in the following order, while respecting the constraint of the agreed ETA:
=== Deploy Release  ===


#Top priority<br>
#For '''changes of high impact and high risk''', the steps required to reverse an unsuccessful change or remedy any negative effects shall be defined.
#Very urgent<br>
#Urgent<br>
#Less Urgent<br>


== Vulnerability management ==
=== Review Release  ===


The Provider has appointed personnel for vulnerability issues concerning the maintained software components. Those security contacts must be fully authorised to act as the Provider’s representative in collaboration with EGI SVG [Błąd: Nie znaleziono źródła odwołania] and related boards regarding the triaging, assessment and resolution of any vulnerability issues concerning the software components developed and maintained by the Provider.  
#'''Each release should be monitored for success or failure''' and the results shall be analysed internally. <br>


<br>
== Incident and Problem management  ==


Any appointed security contact for any delivered software component must respond to any request by the EGI SVG and associated groups (e.g. RAT). The response must be as soon as possible, or at least within 2 working days.  
'''Goal: To restore normal/agreed service operations within the agreed time after the occurrence of an incident, and to investigate the root causes of (recurring) incidents in order to avoid future recurrence of incidents by resolving the underlying problem, or to ensure workarounds are available. '''


<br>
=== Incident and requests management  ===


=== Vulnerability Resolution ===
Support should be provided:


The Provider agrees that any software vulnerability found in their delivered software while running on EGI production infrastructure must be handled using the SVG process [Błąd: Nie znaleziono źródła odwołania].  
*via the GGUS portal, which is the single point of contact for infrastructure users to access the EGI Service Desk.
*(for incidents) According to declared level of [[FAQ GGUS-QoS-Levels|quality of support ]](default:&nbsp;Medium)&nbsp;
*Support is provided in '''English'''<br>
*'''Support is available'''
**from Monday to Friday
**8 h per day<br>
*All incidents and requests should be'''(assign to proper Support Unit) and [[FAQ GGUS-Ticket-Priority|prioritized]]''' according to suitable scheme.<br>


<br>
=== Problems management  ===


The Provider agrees that any software vulnerability in their delivered software found otherwise must be reported to the EGI SVG. If the vulnerability is reported before a fix is available, the vulnerability must be treated and resolved as if found on EGI production infrastructure, i.e. it must be handled using the SVG process. If the vulnerability is reported after a fix is available, the Provider coordinates with SVG to make available the new release including an appropriate advisory for SW release on EGI production infrastructure.  
#In case of '''recurring incidents '''which cannot be solved by the Provider a GGUS ticket should be created to "Operations" &nbsp;Support Unit. EGI Operations team will coordinate investigation of&nbsp; the root causes of (recurring) incidents in order to avoid future recurrence of incidents.&nbsp;
#*Any existing GGUS tickets which may help investigation should be marked as a child to the created ticket.


<br>
=== Planned maintenance windows or interruptions  ===


The Provider agrees to prioritise vulnerability resolution according to their risk assessment, in the following order:
'''Planned maintenance''' should be


#Critical
*declared in GOC&nbsp;DB in a timely manner i.e. '''24 hours before'''
#High
*with typical duration up to 24 hours otherwise needs to be justified
#Moderate
#Low


<br>
'''Unscheduled interruptions '''should be managed according to [[MAN04 Tool Intervention Management|MAN04]] TBD_NOT_CLEAR


For any vulnerability found in any software component delivered by the Provider, the Provider agrees to the best of their ability that no information about the vulnerability shall be disclosed to the public without consent of the SVG. Other Software Vulnerability groups may be informed without prior consent of the EGI SVG, provided they have a non-disclosure policy, which is compatible with that of the EGI SVG. Also, IGE and any other vulnerability groups informed must ensure that a fix is available in the UMD prior to public or other widespread disclosure of the vulnerability.
=== Security incidents  ===


<br>
All security incidents should be registered according to [[EGI CSIRT:Incident reporting|EGI_CSIRT:Incident_reporting]]


== Metrics ==
=== Monitoring ===


Each metric is a positive integer number, including 0 (zero). “Secondary” metrics (i.e. metrics with an ID counter larger than 1) are constrained in that they cannot reach numbers greater than the pertinent “main” metrics (i.e. M.*.1).  
Provider is '''responsible''' for development, maintenance and support of the Component '''monitoring probes.'''


All metrics are collected on a monthly basis, starting on the first calendar day of the month, and ending on the respective last day of the month.  
Availability and reliability threshold should be defined with EGI Operations team depending on criticality of the service.  


{| width="635" cellspacing="0" cellpadding="7"
== Information Security management  ==
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#'''Metric ID'''


| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
'''Goal: to manage information security effectively through all activities performed to deliver and manage services, so that confidentiality, integrity and accessibility of relevant assets are preserved<br>'''  
#'''Metric'''


| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
The following rules for information security and data protection apply:<br>•&nbsp;&nbsp;&nbsp; The Provider must define and abide by an information security and data protection policy related to the service being provided. <br>•&nbsp;&nbsp;&nbsp; This must meet all requirements of any relevant [http://www.egi.eu/about/policy/policies_procedures.html EGI policies or procedures] and also must be compliant with the relevant national legislation.<br><br>
#'''Explanation'''


|- valign="top"
== Customer relationship management'''<br>'''  ==
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.1


| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
'''Goal:''' '''Establish and maintain a good relationship with customers receiving service'''
#Number of confirmed new vulnerabilities per month


| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |  
The Provider interacts with EGI.eu, primarily with [[OMB|OMB]], the main customer of the operational tools.  
#The total number of vulnerabilities discovered in all maintained software components, whether within EGI activities or outside, are collected and published.
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.2
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of fixes delivered within TD
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#<span lang="en-US">All fixes that are delivered within TD </span><span lang="en-US">''and''</span><span lang="en-US">
</span>


'''Interactions between EGI.eu TPs''' are guaranteed through periodic phone conferences and face to face meetings (URT). A dedicated mailing list is available as well: urt-discuss@egi.eu <br>


'''Interactions with customers '''are guaranteed through periodic OMB&nbsp;meetings and (if needed) dedicated Advisory Groups. The AG mandate is to help the Provider in requirement prioritization and releasing process of the Component. AG can provide forums to discuss the Component evolution that meets the expressed needs of the EGI community. It has representation from the all end users groups depending on the Component.<br>


<br>  
<br>  
Line 182: Line 208:
<br>  
<br>  


have passed the SW Rollout process are counted.
<br>
 
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.3
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of fixes delivered after TD
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#<span lang="en-US">All fixes that are delivered </span><span lang="en-US">''after''</span><span lang="en-US">
</span>
 
 
 
<br>
 
<br>
 
TD <span lang="en-US">''and''</span><span lang="en-US">
have passed the SW Rollout process are counted. </span>
 
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.4
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of confirmed open vulnerabilities which have exceeded the TD
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#Number of confirmed vulnerabilities, which have not been fixed and have passed the TD at the time of calculating.
#Current value taken at the end of the reporting month on the last working at 18:00 CE(S)T.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.5
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Total number of open vulnerabilities
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#Current value taken at the end of the reporting month on the last working day at 18:00 CE(S)T.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.6
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of requests to the Provider
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#The total number of requests for information and/or participation in investigation of issues to IGE concerning vulnerabilities.
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.7
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of contact responses below 2 day target
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#Each request made by the SVG or associated boards that were not reacted upon within 2 working days are counted.
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.DMSU.1
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of issues assigned to the Provider
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#The total numbers of confirmed issues that require the Provider’s effort to produce a new release are counted.
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.DMSU.2
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of issues with revised ETA
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#The total number of issues for which the Provider changed the ETA are counted.
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.DMSU.3
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of fixes delivered within ETA
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#<span lang="en-US">All fixes that are delivered within ETA </span><span lang="en-US">''and''</span><span lang="en-US">
</span>
 
 
 
<br>
 
<br>
 
have passed the SW Rollout process are counted.
 
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.DMSU.4
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of fixes delivered within ETA + 1 week
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#<span lang="en-US">All fixes that are delivered within ETA + 1
</span>
 
 
 
<br>
 
<br>
 
calendar week <span lang="en-US">''and''</span><span lang="en-US">
have passed the SW Rollout process are counted.</span>
 
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.DMSU.5
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of fixes delivered within ETA + 1 month
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#<span lang="en-US">All fixes that are delivered within ETA (+ 1
</span>
 
 
 
<br>
 
<br>
 
calendar month) <span lang="en-US">''and''</span><span lang="en-US">
have passed the SW Rollout process are counted.</span>
 
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.REPO.1
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of releases delivered to EGI
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#The total number of releases made available to EGI through the SW Rollout process is counted.
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.REPO.2
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of releases that passed the quality criteria verification.
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#All releases that passed the quality criteria verification process are counted. Release submissions that result in changes of quality criteria applicable to the pertinent component are not counted in this metric.
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.REPO.3
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of releases that passed StageRollout verification
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#All releases that passed the StageRollout phase of the SW rollout process hence are accepted for production use, are counted.
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.MISC.1
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of violations of service request response times
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#<span lang="en-US">Every occurrence of a violation of the service
</span>
 
 
 
<br>
 
<br>
 
request response times agreed to in section Błąd: Nie znaleziono źródła odwołania is counted.
 
#Aggregated during the reporting month.
 
|- valign="top"
| width="70" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.MISC.2
 
| width="183" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Number of releases that failed any mandatory Generic Documentation Quality Criterion
 
| width="337" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#Documentation quality is a critical software quality criterion, but not part of the decision to accept or reject software based on technical failures.
#Aggregated during the reporting month.<br>
 
|}
 
<br><br>
 
== Objectives  ==
 
Objectives are decimal numbers with a precision of 2 decimals rounded. In case of any main metric, at the point of collection, has the value 0 (zero) the related objective shall have the value “0.00%”
 
Objectives are calculated using monthly metering of the metrics defined in section .
 
{| width="635" cellspacing="0" cellpadding="7"
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#'''Objective ID'''
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#'''Objective '''
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#'''Calculation'''
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#'''Target'''
 
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.SVG.1
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Proportion of issues fixed within TD
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#100 * M.SVG.2 /
#(M.SVG.2 + M.SVG.3 + M.SVG.4)
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
 
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.SVG.2
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Proportion of open issues beyond TD
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.SVG.4 / M.SVG.5 * 100
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
 
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.SVG.3
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Responsiveness of security contacts to vulnerability issues
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#(M.SVG.7 / M.SVG.6) * 100
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
 
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.DMSU.1
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Success rate of timely delivery within ETA
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#(M.DMSU.3 / M.DMSU.1) * 100
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
 
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.DMSU.2
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Success rate of timely delivery within ETA + 1 week
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#(M.DMSU.4 / M.DMSU.1) * 100
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
 
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.DMSU.3
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Success rate of timely delivery within ETA + 1 month
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#(M.DMSU.5 / M.DMSU.1) * 100
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
 
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.REPO.1
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Formal quality of component releases
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#(M.REPO.2 / M.REPO.1) * 100
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
 
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.REPO.2
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Functional quality of component releases
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#(M.REPO.3 / M.REPO.1) * 100
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#n/a
 
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.MISC.1
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Service response time violation
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.MISC.1
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#0
 
|- valign="top"
| width="89" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#O.MISC.2
 
| width="194" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#Documentation quality failure
 
| width="232" style="border-top: 1px solid #000000; border-bottom: 1px solid #000000; border-left: 1px solid #000000; border-right: none; padding-top: 0cm; padding-bottom: 0cm; padding-left: 0.19cm; padding-right: 0cm" |
#M.MISC.2
 
| width="62" style="border: 1px solid #000000; padding: 0cm 0.19cm" |
#0
 
|}
 
<br> <br><br>
 
Due to the expected small number of software Products contributed by IGE a sensible relation-based metering of objective targets is not possible. Instead, IGE and EGI agree that objectives undergo quarterly review collecting input across EGI management bodies and activities (SVG, RAT, DMSU, TCB, etc.) and a formal overall ratification that collected metrics are within reason.The performance of IGE in said activities will be individually reviewed and assessed on the following scale:
 
*Performance above expectations
*Performance as expected
*Performance below expectation
 
The review will include assessment of the past period, and expectations for the subsequent period.
 
<br>  
 
[[Category:Infrastructure_Oversight]]

Revision as of 14:12, 20 March 2015

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


Tools menu: • Main page • Instructions for developers • AAI Proxy • Accounting Portal • Accounting Repository • AppDB • ARGO • GGUS • GOCDB
• Message brokers • Licenses • OTAGs • Operations Portal • Perun • EGI Collaboration tools • LToS • EGI Workload Manager




Initial activities

Goal: Introducing new Component.
Every new Component will be introduced concacting TBD_WHO providing following data:

  1. Name of the Component
  2. Contacts (support email address, web site address)
  3. Name and contact details of the person Responsible for the Component
  4. Description of the Component/Purpose
  5. License

With the help of the EGI URT team, the following steps need to be performed:

  1. Registration in GOC DB under EGI.eu NGI
  2. Create category in "Requirements" queue in EGI RT tracker and RT dashboard to receive and handle service requests 
  3. Create GGUS Support Unit to receive and handle incidents (define level of quality of support - default: Medium)
  4. Negotiate and sign Technical Provider Underpinning Agreement (TP UA) https://documents.egi.eu/document/2282 with EGI.eu
  5. Create wiki entry for the tool with relevant information
    • Component name
    • Category, Short description of the Component
    • URL
    • Contact TBD_needed a EGI.eu contact for each Component and a Provider contact for EGI.eu
    • GGUS Support Unit
    • GOC DB entry
    • link to related TP UA
    • link to documentation
    • license
    • provider name
    • link to source code
    • Change management:
      • link to EGI RT dashboard for the tool
      • (if applicable) internal bug/task tracking facilities
      • (if applicable) link to OTAG team
    • Release and Deployment management: 
      • Release schedule
      • Release notes
      • (if applicable) Roadmap
      • URL of test instance


Ongoing activities

Change management

Goal: To ensure changes are planned, approved, implemented and reviewed in a controlled manner to avoid adverse impact of changes to services or the customers receiving services.

CM.png

Record

  1. EGI recording system is EGI RT 
  2. EGI user are instructed to submit changes requests in EGI RT.
  3. If the Component has other customers than EGI, the Provider will inform EGI about submitted change requests from other customers.
  4. Minimum set of statuses of entry
    • New - newly recorded in system
    • Accepted - accepted by AG/OMB
    • Rejected - rejected by AG/OMB
    • In progress/Open - TP is working on the request
    • Resolved - released
    • Stalled - on hold

Classify

  1. All change requests should be classified in consistent manner. Classification in EGI RT is based on the Component the request is related to.
  2. TP should define list of standard change requests (a Change that is recurrent, well known, has been proceduralized to follow a pre-defined, relatively risk-free path, and is the accepted response to a specific requirement or set of circumstances, where authority is effectively given in advance of implementation.). Standard change request doesn't need approval to be implemented.
  3. Emergency change for the Component are the highest priority change related to security vulnerability and can be implemented without approval but will be subject of post-review.

Assess and Approve

  1. Each change request should be commented by the TP with assessment of work needed to implement change.
  2. Every change which is not a standard change or emergency change should be assessed (prioritized)and approved internally, in the URT and with OMB.
  3. Where needed dedicated Advisory Group can be set up. The AG mandate is to help the TP in requirement prioritization and releasing process of the Component. AG provide forums to discuss the tools evolution that meet the expressed needs of the EGI community. It has representation from the all end users groups depending on the tool.
  4. Minimum set of value for prioritization:
    • None (in RT - 0)
    • Low (in RT - 1)
    • Normal (in RT - 2)
    • High (in RT - 3)
    • Immediate/emergency (in RT - 4)

Implement, release and deploy

Phase which take place in Release and Deployment process (see below).

Review

  1. Every release is subject to post-implementation review. Within one week customers are providing feedback answering to following questions:
    • Were release notes and documentation sufficient?
    • Is the tool working as expected?

Release and deployment management

Goal: To bundle changes to release, so that these changes can be tested and deployed to the production environment together.

RnDM.png

Plan Release

  1. Release schedules should be defined - the frequency of releases (eg. every 1-2 month).
  2. Scope of every release should be defined.
  3. Release should be planned in a away that OMB can be informed in at least one week time in advance.
    • all planned releases should be presented during the monthly OMB meeting prior to their release to production
    • emergency releases should be presented at the first available OMB meeting, post-release.

Build Release

  1. Due to the open-source nature of the developed software, each Component should have/use a publicly available code repository, like SVN, CVS, GIT
  2. All new releases should correspond to a new tag in the SVC
  3. Distribution
      • new releases should be distributed as binaries through the UMD repository

Test Release

  1. Testing of the software, prior to its release, is a responsibility of the Provider.
  2. Where dedicated AG exists it can be involved in the testing activity.
  3. Major or particularly important releases should pass acceptance testing performed by customer representatives
  4. When the development phase of a new release is completed an announced it should be shared in the URT and to all the actors that should be involved in the release testing (AGs). The announcement should contain:
    • release notes, containing changelog, installation & configuration steps to apply the update, any known issues
    • documentation links
    • detailed test plan
    • all the information needed by the conformance criteria set by the SA2 activity for the software providers.
    • the expected release date and the kind of testing will depend on each specific release and on its importance.
  5. If a test fails a report will be produced and the release sent back to development to restart the cycle. Tests will include a documentation review and a documentation update if needed. The test phase can be performed internally to the development team if no other components or services are affected.

Document

  1. The Provider is responsible for creation and maintenance of documentations, instructions and manuals related to the Component in collaboration with EGI Operations team.
  2. Before each release documentation should be checked and updated when/where needed.

Inform

  1. Information about next release should be communicated
    • during OMB meeting (at least one week before release).
      • One slide information should be sent to urt-discuss@egi.eu

Deploy Release

  1. For changes of high impact and high risk, the steps required to reverse an unsuccessful change or remedy any negative effects shall be defined.

Review Release

  1. Each release should be monitored for success or failure and the results shall be analysed internally.

Incident and Problem management

Goal: To restore normal/agreed service operations within the agreed time after the occurrence of an incident, and to investigate the root causes of (recurring) incidents in order to avoid future recurrence of incidents by resolving the underlying problem, or to ensure workarounds are available.

Incident and requests management

Support should be provided:

  • via the GGUS portal, which is the single point of contact for infrastructure users to access the EGI Service Desk.
  • (for incidents) According to declared level of quality of support (default: Medium) 
  • Support is provided in English
  • Support is available
    • from Monday to Friday
    • 8 h per day
  • All incidents and requests should be(assign to proper Support Unit) and prioritized according to suitable scheme.

Problems management

  1. In case of recurring incidents which cannot be solved by the Provider a GGUS ticket should be created to "Operations"  Support Unit. EGI Operations team will coordinate investigation of  the root causes of (recurring) incidents in order to avoid future recurrence of incidents. 
    • Any existing GGUS tickets which may help investigation should be marked as a child to the created ticket.

Planned maintenance windows or interruptions

Planned maintenance should be

  • declared in GOC DB in a timely manner i.e. 24 hours before
  • with typical duration up to 24 hours otherwise needs to be justified

Unscheduled interruptions should be managed according to MAN04 TBD_NOT_CLEAR

Security incidents

All security incidents should be registered according to EGI_CSIRT:Incident_reporting

Monitoring

Provider is responsible for development, maintenance and support of the Component monitoring probes.

Availability and reliability threshold should be defined with EGI Operations team depending on criticality of the service.

Information Security management

Goal: to manage information security effectively through all activities performed to deliver and manage services, so that confidentiality, integrity and accessibility of relevant assets are preserved

The following rules for information security and data protection apply:
•    The Provider must define and abide by an information security and data protection policy related to the service being provided.
•    This must meet all requirements of any relevant EGI policies or procedures and also must be compliant with the relevant national legislation.

Customer relationship management

Goal: Establish and maintain a good relationship with customers receiving service

The Provider interacts with EGI.eu, primarily with OMB, the main customer of the operational tools.

Interactions between EGI.eu TPs are guaranteed through periodic phone conferences and face to face meetings (URT). A dedicated mailing list is available as well: urt-discuss@egi.eu

Interactions with customers are guaranteed through periodic OMB meetings and (if needed) dedicated Advisory Groups. The AG mandate is to help the Provider in requirement prioritization and releasing process of the Component. AG can provide forums to discuss the Component evolution that meets the expressed needs of the EGI community. It has representation from the all end users groups depending on the Component.




Retrieved from "https://wiki.egi.eu/w/index.php?title=EGI_Software_Component_Delivery&oldid=77910"