Managed applikationssupport og vedligeholdelse
At holde software, der allerede er live, kørende, inden for jeres SLA og jeres ticketkø: triage, rettelser ved årsagen, patch-releases, opgraderinger af afhængigheder og platforme, sikkerhedsrespons og håndtering af hændelser. Anden og tredje linje, udført af udviklere, der også bygger, så en tilbagevendende fejl bliver rettet og ikke blot genstartet.
Hvorfor det er et partnerproblem
Support er den del af en managed service, der er let at sælge og svær at bemande. Den kommer ujævnt, den kræver folk, der kan læse ukendt kode under tidspres, og i det øjeblik I sætter jeres bedste udviklere på den, er de ikke længere tilgængelige til det arbejde, der betaler bedre. Det sædvanlige svar er et separat, billigere niveau, der lukker tickets uden nogensinde at rette noget, og kunden opdager det inden for et kvartal.
Vores svar er, at de folk, der tager sig af support, er udviklere. De kan ændre systemet og ikke blot beskrive det, og det er den eneste måde, en tilbagevendende hændelse nogensinde holder op med at vende tilbage.
Hvad vi tager på os
Triage og diagnose
At tage det, første linje ikke kan besvare, genskabe det og sige, hvad der faktisk er galt, i stedet for at lukke det som ikke reproducerbart.
Rettelser, der holder
Fejl rettet ved årsagen, med en regressionstest skrevet mod hele fejltypen og ikke kun den ene ticket, så den samme hændelse ikke vender tilbage næste kvartal.
Releases og patching
Patch-releases udgivet gennem jeres pipeline efter jeres change-proces, med afhængigheder, frameworkversioner og platformsruntimes holdt aktuelle i stedet for at drive ind i en opgraderingskrise.
Sikkerhedsrespons
En offentliggjort sikkerhedsadvarsel i noget, I afhænger af, er en ubetinget grund til at opgradere og ikke et punkt på en backlog. Vi følger den, patcher og fortæller jer, hvad eksponeringen var.
Overvågning og hændelser
At holde øje med de alarmer, der allerede findes, tilføje dem, der burde være der, og håndtere hændelser med en skriftlig redegørelse bagefter for, hvad der skete, og hvad der forhindrer, at det sker igen.
Små ændringer
Den jævne strøm af mindre forbedringer, der holder en kunde tilfreds og aldrig retfærdiggør et projekt: håndteret inden for den samme kapacitet på samme vilkår.
Jeres SLA, ærligt vurderet
Vi offentliggør ikke mål for respons- og løsningstider, fordi et tal, der er opfundet, før nogen har set jeres system, er værdiløst for jer og værdiløst for jeres kunde. I stedet læser vi den SLA, I allerede skylder, fortæller jer, hvilke dele af den vi reelt kan bære, og hvilken dækning det kræver, og forpligter os derefter til det skriftligt.
Det samme gælder for dækning uden for normal arbejdstid. Hvor et samarbejde har brug for det, og vi har aftalt det på forhånd, bemandes det af folk, der er rekrutteret eller tildelt til de timer, og ikke ved at vække nogen og håbe. Vi kører allerede efter europæisk, australsk og amerikansk Stillehavstid på andre samarbejder, så spørgsmålet er, hvilket tidsrum I har brug for, ikke om det er muligt.
At overtage et system, vi ikke selv har bygget
Hvilket er det almindelige tilfælde. Indtil videre ni overtagelser, den ældste skrevet i 2008.
Først en skrivebeskyttet gennemgang
Vi får adgang til koden, infrastrukturen og tickethistorikken, før vi er ansvarlige for noget af det, og vi kigger i stedet for at ændre.
En skriftlig liste over risici
Hvad der er skrøbeligt, hvad der er upatchet, hvad der er udokumenteret, og hvad der vil vække nogen om natten, ordnet efter betydning for produktionen. I beholder den, uanset om vi går videre.
Samtalen om dækning
Vi læser den SLA, I skylder jeres kunde, og fortæller jer ærligt, hvilke dele vi kan tage på os, hvilke timer det kræver, og hvad det koster, før nogen af parterne underskriver noget.
Overdragelse og derefter live
En defineret skyggeperiode sammen med den, der har viden nu, og derefter overtager vi køen. Hvis ingen længere sidder med viden, er risikogennemgangen i stedet der, hvor vi starter.
Under jeres navn, hvis det er aftalen
Support er som regel den mest synlige del af en managed service, så det er også her, det betyder mest at være white-label. Vores udviklere kan arbejde fra postkasser og konti, I udsteder, svare i jeres ticketsystem og skrive hændelsesrapporter, I videresender uændret; jeres kunde har hele vejen igennem med jer at gøre. White-label-udvikling beskriver, hvordan det arrangeres, og det gælder for support på præcis samme måde.
Sådan prissættes support
Pr. person, pr. måned, så jeres egen omkostning er forudsigelig, og I kan prissætte en supportkontrakt til jeres kunde ud fra den. Alle registrerer tid i vores egen portal, I kan se timerne hele måneden, og de samme tal danner fakturaen, så der er én registrering, begge parter afstemmer mod.
Hvor support står ved siden af ny udvikling, er de to som regel én delivery pod og ikke to kontrakter, så stille uger på den ene side betaler for travle uger på den anden.
Spørgsmål om supportordninger
Hvad dækker administreret applikationssupport?
At holde software, der allerede er i drift, kørende: sortere det, der kommer ind i køen, genskabe og rette fejl, besvare de tekniske spørgsmål, som første linje ikke kan, levere patchudgivelser, holde afhængigheder og platformsversioner ajour, holde øje med alarmer og håndtere hændelser, når noget går i stykker. Det er arbejde på anden og tredje linje; jeres første linje bliver, hvor den er.
Arbejder I efter vores SLA?
Ja. Vi offentliggør ikke mål for respons- og løsningstider, for et tal, der er opfundet, før vi kender jeres system, er værdiløst. Vi læser den SLA, I allerede skylder jeres kunde, fortæller ærligt, hvilke dele vi kan bære, og hvilken dækning det kræver, og forpligter os derefter skriftligt til det.
Kan I give dækning uden for arbejdstid eller vagtberedskab?
Ja. Dækning uden for arbejdstid og vagtberedskab aftales på forhånd, skrives ind i supportvilkårene og bemandes af folk, hvis arbejdstid passer til det, så en hændelse om natten når en person, der er på vagt, og ikke en, der bliver vækket.
Kan I supportere et system, I ikke selv har bygget?
Det er det normale. Ni overtagelser hidtil, den ældste skrevet i 2008. Support af et overtaget system starter med en gennemgang uden skriveadgang og en skriftlig liste over risici, rangeret efter betydning for driften, så de første uger går med at forstå, hvad I rent faktisk har ansvaret for, i stedet for at gætte under pres.
Vil de samme folk, der supporterer systemet, også ændre det?
Ja, og det er pointen. Udviklerne på support er udviklere og ikke et separat niveau, der lukker tickets, så en tilbagevendende hændelse kan rettes ved årsagen i stedet for at blive genstartet hver mandag. Hvor I har både et udviklingsspor og et supportspor hos os, deler de to code review og arkitekturbeslutninger.
Hvordan prissættes support?
Pr. person, månedligt, så jeres egne omkostninger er forudsigelige, og I kan prissætte en supportkontrakt over for jeres kunde ud fra dem. Timer registreres i vores portal og er synlige for jer hele måneden, og de samme tal danner fakturaen, så der er én kilde til begge parter.
Har I systemer, der skal holdes kørende?
Fortæl os, hvad systemerne er, hvad jeres SLA lover, og hvor support gør ondt i dag. Vi læser det og fortæller jer, hvilke dele vi kan tage på os, også de dele, vi ikke kan.