Gemeente Den Haag Service Level Agreement

Transcriptie

1 Gemeente Den Haag Service Level Agreement Beschrijving van de service ten behoeve van de Aanbestedingsleidraad Europese aanbesteding volgens de openbare procedure Technisch Beheer EBS IDC Gemeente Den Haag 1

2 Inhoudsopgave 1. Introductie Opbouw Overlegstructuren SLA algemeen Het doel van de SLA Controle over de SLA Voorbereiding Accorderen van de SLA Onderhoud van de SLA Looptijd van de SLA Verantwoordelijkheden Verantwoordelijkheden van de opdrachtnemer en opdrachtgever Beschrijving van de diensten Doelen van de dienst en kritieke succes factoren Contractueel op te leveren meldingen systeem en documenten Definities van prioriteiten Escalatie model Beveiliging Dienstverleningsniveaus Support Windows Overeengekomen diensten niveaus Response tijden Uptime Performance Klonen Schaalbaarheid omgevingen Jaarlijkse test: back up restore Diensten rapportage Overzicht Toelichting op de rapporten Maatregelen

3 1. Introductie 1.1. Opbouw Dit document is als volgt opgebouwd: -het eerste hoofdstuk bevat de introductie. -het tweede hoofdstuk beschrijft het doel van de SLA en de bewaking van de SLA. -het derde hoofdstuk beschrijft de verantwoordelijkheden van de partijen. -het vierde hoofdstuk beschrijft de te leveren diensten. -het vijfde hoofdstuk beschrijft de te leveren dienstverleningsniveaus -het zesde hoofdstuk beschrijft de op te leveren rapportages. -hoofdstuk 7 bevat een begrippenkader 1.2. Overlegstructuren Er worden twee overlegstructuren voorgesteld: Eens per kwartaal SLM (Service Level Management) overleg; Twee maal per jaar technisch overleg, of wanneer hiertoe aanleiding voor is. Het eerste overleg is bedoeld om de dienstverlening te bespreken. Aan de orde komen onder meer de rapportage, wijzigingen op de SLA en de algehele voortgang. In het technisch overleg wordt met name aandacht besteed aan de openstaande issues en de eventuele technische knelpunten. 3

4 2. SLA algemeen 2.1. Het doel van de SLA In deze SLA worden de diensten beschreven welke door opdrachtnemer zullen worden geleverd aan opdrachtgever Controle over de SLA Voorbereiding De voorbereiding van de SLA wordt in eerste instantie gedaan door opdrachtnemer. Vervolgens wordt de SLA in onderling overleg verder vormgegeven Accorderen van de SLA Op het voorblad wordt een lijst opgenomen van personen die van de partijen de SLA dienen goed te keuren. Na formele ondertekening van de SLA worden wijzigingen aan de SLA alleen nog doorgevoerd conform de procedure als omgeschreven in de volgende paragraaf Onderhoud van de SLA De procedure met betrekking tot het onderhoud van de SLA is als volgt: In het maandelijks SLM overleg wordt een wijziging doorgenomen opdrachtnemer onderzoekt de consequenties met betrekking tot de aanpassing op de SLA en de eventuele financiële consequenties voor opdrachtgever opdrachtnemer doet een voorstel met betrekking tot de wijziging In het SLM overleg wordt het voorstel doorgenomen en wordt de uiteindelijke wijziging voorgelegd aan de projectmanager van de Gemeente den Haag. Het getekende addendum wordt gedistribueerd aan de personen als genoemd in de volgende paragraaf Looptijd van de SLA Deze SLA heeft een looptijd overeenkomstig de looptijd van de overeenkomst die is aangegaan tussen opdrachtgever en opdrachtnemer. Indien de overeenkomst wordt verlengd en/of inhoudelijk wordt aangepast, zal moeten worden gekeken in hoeverre de SLA dient te worden aangepast. 4

5 3. Verantwoordelijkheden 3.1. Verantwoordelijkheden van de opdrachtnemer en opdrachtgever De basis voor de dienstverlening is een onderlinge samenwerking op basis van heldere afspraken. Opdrachtnemer is verantwoordelijk voor het uitvoeren van technische beheeractiviteiten die horen bij het ondersteunen van Oracle E-Business Suite, Datawarehouse en OBIEE omgevingen. Opdrachtnemer deelt bepaalde rechten met het team Integratiecoordinatie van opdrachtgever (apps password e.d.). Database kopieën, migraties, het toepassen van patches en wijzigingen e.d. wordt alleen in opdracht van opdrachtgever uitgevoerd. Opdrachtnemer brengt periodiek advies uit omtrent het benodigde patch level ten behoeve van support en beveiliging. Bij opdrachtnemer zal de waarborging van de continuïteit te vinden zijn in het feit dat er binnen het tijdsvenster 07:00 18:00 uur - altijd een operator op stand-by is voor de helpdesk werkzaamheden.. 5

6 4. Beschrijving van de diensten 4.1. Doelen van de dienst en kritieke succes factoren De diensten zoals deze worden geleverd hebben tot doel de productie omgeving en overige omgevingen van de Oracle E-Business Suite en de Datawarehouse en OBIEE omgevingen te ondersteunen en de technische beheerwerkzaamheden die daarbij horen uit te voeren. Het streven daarbij is, door het vroegtijdig oplossen en voorkomen van technische problemen, de productie niet te verstoren en deelimplementaties niet te vertragen. De volgende domeinen zijn daarbij van belang: Computerruimte beheer Netwerk en storage Server beheer Operating system beheer (file system, kernel, printen, mail verkeer) Database beheer Fall Back (Back-up, Restore, Uitwijk) Oracle EBS, BI en OBIEE beheer (database kopieën, migraties, patches e.d.) 4.2. Contractueel op te leveren meldingen systeem en documenten De opdrachtnemer stelt een electronisch meldingensysteem ter beschikking waarin opdrachtgever de meldingen (zoals vragen, incidenten en wijzigingen) kan registreren en kan zien wat de status en voortgang is van de activiteiten van de opdrachtnemer op de betreffende melding. De volgende documenten zullen vanuit de SLA worden opgeleverd: Bij einde van de overeenkomst een overdrachtsdocument met daarin een omschrijving van de status van de verschillende omgevingen en de procedures voor het starten en stoppen van omgevingen Van elke omgeving zal, bij beëindiging van de SLA, een lijst met patches en de openstaande problemen worden overgedragen Het Dossier Afspraken en Procedures. Dit document zal in samenwerking met de gemeente worden opgesteld. Dit document zal minimaal tweemaal per jaar worden gecontroleerd op volledigheid. Tevens kan een procedure worden aangepast wat een wijziging op het DAP tot gevolg heeft Definities van prioriteiten Voor het aanmelden van incidenten worden drie prioriteiten onderscheiden: Prioriteit 1, hoge prioriteit: een probleem vereist een directe actie. Het incident veroorzaakt een grote verstoring van de werking van de applicatie en dient direct te worden opgelost Prioriteit 2, standaard prioriteit: een probleem vereist op korte termijn actie. Dit betreft reguliere beheer activiteiten die op korte termijn in overleg tussen beide partijen worden ingepland Prioriteit 3, lage prioriteit: dit betreft acties die niet direct dienen te worden opgepakt maar op een langere termijn (enkele dagen/weken) dienen te worden uitgevoerd. Bij het aanmelden van een incidenten wordt door de partijen afgestemd welke prioriteit dient te worden gehanteerd en zal ook een einddatum worden vastgesteld. 6

7 4.4. Escalatie model Normaal zal de escalatie van problemen worden gedaan volgens de prioriteiten die zijn overeengekomen. In overleg kan de prioriteit van een problemen worden opgehoogd om de voortgang te bespoedigen. In de onderstaande tabellen is een overzicht gegeven van de escalatie niveaus en acties: Escalatie niveau Verantwoordelijke opdrachtnemer Verantwoordelijke opdrachtgever Niveau 1 Medewerkers helpdesk Functioneel beheer Niveau 2 Manager helpdesk Integratie coördinatoren (IC) Niveau 3 Sales manager Service Manager KC BVS Niveau 4 Sales manager Hoofd KC BVS / IC Niveau 5 Algemeen directeur Systeemeigenaar Een koppeling van de prioriteiten aan de escalatie niveaus leidt tot de volgende acties: Prioriteit Escalatie niveau Escalatie condities 1 Niveau 1 Meteen bij geen reactie support Niveau 2 Wanneer geen reactie binnen 2 uur Niveau 3 Wanneer geen reactie binnen 4 uur Niveau 4 Wanneer geen reactie binnen 24 uur 2 Niveau 1 Binnen 4 uur geen reactie Niveau 2 Wanneer geen dagelijkse terugkoppeling Niveau 3 Wanneer niet opgelost binnen 3 dagen 3 Niveau 1 Binnen 1 dag geen reactie Niveau 2 Wanneer geen wekelijkse terugkoppeling 4.5. Beveiliging De database passwords (waaronder apps) worden op verzoek van opdrachtgever (KC/IC) ingesteld en worden niet vrijgegeven aan eindgebruikers en beheerders anders dan KC/IC. Deze passwords worden op verzoek van opdrachtgever op reguliere basis gewijzigd. 7

8 5. Dienstverleningsniveaus 5.1. Support Windows Het support window loopt van uur (niet gedurende weekenden). Indien de helpdesk van opdrachtnemer in verband met avond werkzaamheden langer open dient te blijven dan zal daartoe een verzoek worden ingediend. Bij de standaard dienstverlening hoort het regelmatig (1 a 2 x per week gemiddeld) na kantoortijden uitvoeren van acties (na en/of in het weekend ).Hieraan zijn geen kosten verbonden. Het onderhoud aan machines is altijd in overleg met opdrachtnemer. Indien er sprake is van een spoedgeval zal opdrachtnemer haar uiterste best doen de helpdesk verlengd open te laten. In overleg zullen partijen vaststellen hoe deze extra openingstijd zal worden afgerekend Overeengekomen diensten niveaus Response tijden De volgende response tijden zijn overeengekomen: Bij contact opnemen met de helpdesk resulteert 90% van de telefonische aanvragen in een direct contact met een operator. Voor de overige aanvragen geldt dat wanneer een bericht is ingesproken op de voic er binnen één uur binnen het support window contact wordt opgenomen met de aanvrager Bij contact opnemen met de helpdesk via wordt altijd binnen maximaal 2 uur binnen het support window gereageerd op de aanvraag De volgende dienstenniveaus zijn overeengekomen met betrekking tot het afwikkelen van problemen met een bepaalde prioriteit o Prioriteit 1 problemen: deze problemen worden door opdrachtnemer direct opgepakt en voor deze problemen wordt binnen één uur een oplossingsrichting met opdrachtgever besproken o Prioriteit 2 problemen: voor deze problemen wordt binnen 2 uur een oplossingsrichting met opdrachtgever besproken o Prioriteit 3 problemen: voor deze problemen wordt binnen 3 werkdagen een oplossingsrichting met opdrachtgever besproken Het moment waarop een patch wordt geplaatst wordt te allen tijde in overleg met opdrachtgever vastgesteld. Voor de test omgevingen geldt dat de patches binnen een werkdag zullen worden geplaatst. Kritieke patches binnen 2 uren na ontvangst van leverancier. Regulier in overleg met opdrachtgever. Voor het terugzetten van een backup is overeengekomen dat wanneer het een projectomgeving betreft binnen een uur na aanmelding zal starten met de benodigde stappen. Voor de overige omgevingen zal in overleg worden bepaald wat het gewenste tijdstip is voor de recovery. Daarbij worden de normale prioriteiten gehanteerd Uptime Voor de uptime van de productie omgevingen EBS, BI en OBIEE wordt uitgegaan van 99,5%. Dit betekent dat 7 dagen in de week gedurende 24 uur per dag de productieomgeving beschikbaar is in 99,5% van de tijd. Uitzondering hierop vormt onderling overeengekomen downtime voor onderhoud. De tijd voor onderling overeengekomen downtime wordt niet meegerekend als de uptime. 8

9 Performance Voor de performance van het systeem zal opdrachtnemer melding maken van situaties die de performance nadelig beïnvloeden en welke stappen nodig zijn om de eventuele problemen op te lossen. Performance is minimaal gelijk aan die van de huidige omgevingen. De inschrijver zorgt voor een performance meet-methodiek vergelijkbaar met de huidige performancegegevens. Hieronder staan de huidige performancegegevens. Voor het datawarehouse gelden daarnaast de volgende afspraken: De totale laadrun van een DWH-omgeving bestaat uit het laden (na transformatie) van ongeveer objecten in maximaal 16 laadqueues (aparte sessies). Een laadrun moet uitgevoerd worden in maximaal 7 uur. Het streven is om een maximale laadtijd van 6 uur te bereiken. Dit geldt voor de productieomgeving. Het laden van de productieomgeving start om 0:05 uur. Elke nacht tussen 19:00 en 07:00 uur moet voor tenminste 3 van de standaardomgevingen een volledige laadrun moet worden uitgevoerd. Deze runs mogen elkaar niet zo beïnvloeden dat de afzonderlijke runs langer dan 8 uur gaan duren. Overdag tussen 07:30 en 18:00 moet er voldoende capaciteit zijn voor DWHproductieomgeving om tenminste OBIEE rapportage-requests gedurende de dag te kunnen afhandelen, waarbij de gemiddelde responsetijd minder dan 10 seconden moet zijn. De afhandelings capaciteit van rapportages zal op de DWH-productieomgeving per jaar naar verwachting met 25% stijgen. De gemiddelde respons tijd moet onder de 10 seconden blijven. Bij deze stijging is geen rekening gehouden met het eventueel ontsluiten van nieuwe bronnen. Het veiligstellen van de data mag de nachtelijke laadrun en bevragingen overdag niet nadelig beïnvloeden. 9

10 ebs Productie applicatieserver : gdhaspr Processor gebruik 10

11 Memory gebruik 11

12 Disk gebruik 12

13 13

14 14

15 ebs Productie databaseserver : gdhdbpr Processor gebruik 15

16 Memory gebruik 16

17 Disk gebruik 17

18 18

19 Netwerk verkeer 19

20 Datawarehouse productie Netwerk Memory gebruik 20

21 Processor gebruik 21

22 Klonen De volgende tabel bevat een overzicht van de klonen per jaar. Het leveren van deze klonen is onderdeel van de standaard dienstverlening. Er zijn geen extra kosten aan verbonden voor GDH. Omgeving domein frequentie Per jaar ACCT acceptatie 1x per kwartaal 4 RAPP acceptatie 1x per dag 260 PREA acceptatie 1x per week 50 PROJ1 OT op verzoek 10 ONTW OT 1x per kwartaal 4 PROJ3 OT op verzoek 10 EDUC OT op verzoek 10 REFR OT 1x per week 50 PROJ2 OT op verzoek 10 TEST OT 1x per kwartaal 4 PROJ4 OT op verzoek 10 TOTAAL 422 Tabel: Overzicht frequentie van klonen per omgeving per jaar Schaalbaarheid omgevingen Aanpassingen of uitbreidingen aan een omgeving die noodzakelijk zijn om de performance binnen de gestelde performance-eisen te houden zijn onderdeel van de standaard dienstverlening. Er zijn geen extra kosten aan verbonden voor GDH. De intentie bestaat om nieuwe databronnen te ontsluiten in de komende jaren. De omgevingen dienen zodanig schaalbaar te zijn, dat het ontsluiten van nieuwe bronnen geen problemen mag geven. Een schatting van de benodigde capaciteit is op dit moment niet te geven Jaarlijkse test: back up restore Minimaal één keer per jaar vindt in onderling overleg een test plaats voor een restore van de back up. De jaarlijkse test restore is onderdeel van de standaard dienstverlening. Er zijn geen extra kosten aan verbonden voor GDH. 22

23 6. Diensten rapportage 6.1. Overzicht Opdrachtnemer zal periodiek (kwartaal) zorg dragen voor het tijdig verstrekken van de SLA rapportage Toelichting op de rapporten De SLA rapportage wordt gebruikt voor het weergeven van het realiseren van de overeengekomen diensten niveaus zoals: Responsetijden Uptime van de systemen De response tijden hebben betrekking op de in paragraaf genoemde response tijden. Voor de uptime van het systeem zal de actuele uptime worden gemeld en indien deze onder het afgesproken dienstenniveau zit (99,5%) zal worden uitgelegd wat de oorzaak hiervan is Maatregelen Indien uit de verzamelde gegevens blijkt dat actie is vereist in welke vorm dan ook, zal dit in het SLM overleg worden besproken. Indien het acute problemen betreft zullen deze uiteraard direct worden gemeld aan de betrokkenen, waaronder opdrachtgever. 23