Managed application support en onderhoud
Software die al live is aan de praat houden, binnen uw SLA en uw ticketwachtrij: triage, oplossingen bij de oorzaak, patchreleases, upgrades van afhankelijkheden en platformen, securityrespons en incidentafhandeling. Tweede en derde lijn, door engineers die ook bouwen, zodat een terugkerende storing wordt opgelost in plaats van herstart.
Waarom dit een partnerprobleem is
Support is het deel van een managed service dat gemakkelijk te verkopen en moeilijk te bemannen is. Het komt ongelijkmatig binnen, vraagt mensen die onder tijdsdruk onbekende code kunnen lezen, en zodra u uw beste engineers erop zet, zijn ze niet meer beschikbaar voor het werk dat beter betaalt. Het gebruikelijke antwoord is een apart, goedkoper niveau dat tickets sluit zonder ooit iets te herstellen, en de klant merkt dat binnen een kwartaal.
Ons antwoord is dat de mensen op support engineers zijn. Zij kunnen het systeem wijzigen, niet alleen beschrijven, en dat is de enige manier waarop een terugkerend incident ooit ophoudt terug te keren.
Wat wij dragen
Triage en diagnose
Oppakken wat de eerste lijn niet kan beantwoorden, het reproduceren, en zeggen wat er werkelijk mis is in plaats van het te sluiten als niet reproduceerbaar.
Oplossingen die standhouden
Defecten opgelost bij de oorzaak, met een regressietest die tegen de hele klasse van bugs is geschreven in plaats van tegen het ene ticket, zodat hetzelfde incident volgend kwartaal niet terugkomt.
Releases en patching
Patchreleases uitgebracht via uw pipeline en uw wijzigingsproces, met afhankelijkheden, frameworkversies en platformruntimes actueel gehouden in plaats van weg te drijven naar een upgradecrisis.
Securityrespons
Een gepubliceerd advies over iets waarvan u afhankelijk bent, is een onvoorwaardelijke reden om te upgraden, geen backlogitem. Wij volgen het, patchen het en vertellen u wat de blootstelling was.
Monitoring en incidenten
De alerts bekijken die er al zijn, de alerts toevoegen die er moeten zijn, en incidenten afhandelen met achteraf een schriftelijke weergave van wat er gebeurde en wat voorkomt dat het terugkeert.
Kleine wijzigingen
De gestage stroom kleine verbeteringen die een klant tevreden houdt en nooit een project rechtvaardigt: afgehandeld binnen dezelfde capaciteit, onder dezelfde voorwaarden.
Uw SLA, eerlijk beoordeeld
Wij publiceren geen respons- en oplossingsdoelen, omdat een getal dat is verzonnen voordat iemand uw systeem heeft gezien niets waard is voor u en niets voor uw klant. In plaats daarvan lezen we de SLA die u al verschuldigd bent, vertellen we welke delen we echt kunnen dragen en welke bezetting dat vraagt, en leggen we ons daar schriftelijk aan vast.
Hetzelfde geldt voor dekking buiten kantooruren. Waar een opdracht dat nodig heeft en we het vooraf hebben afgesproken, wordt het bemand door mensen die voor die uren zijn geworven of toegewezen, en niet door iemand wakker te maken en te hopen. We draaien al op Europese, Australische en Amerikaanse westkusturen bij andere opdrachten, dus de vraag is welk venster u nodig hebt, niet of het mogelijk is.
Een systeem overnemen dat wij niet bouwden
Wat het normale geval is. Tot nu toe negen overnames, de oudste geschreven in 2008.
Eerst een review in leesmodus
We krijgen toegang tot de code, de infrastructuur en de tickethistorie voordat we voor iets ervan verantwoordelijk zijn, en we kijken in plaats van te wijzigen.
Een schriftelijke lijst met risico’s
Wat kwetsbaar is, wat niet is gepatcht, wat niet is gedocumenteerd en wat iemand ’s nachts wakker maakt, gerangschikt naar impact op productie. Van u om te houden, of we nu verdergaan of niet.
Het dekkingsgesprek
We lezen de SLA die u uw klant verschuldigd bent en vertellen eerlijk welke delen we kunnen dragen, welke uren dat vraagt en wat het kost, voordat een van beide partijen iets tekent.
Overdracht, daarna live
Een afgebakende meeloopperiode met wie de kennis nu heeft, daarna nemen wij de wachtrij over. Heeft niemand de kennis nog, dan begint het bij de risicoreview.
Onder uw naam, als dat de afspraak is
Support is meestal het meest zichtbare deel van een managed service, dus is het ook waar white-label het zwaarst weegt. Onze engineers kunnen werken vanuit mailboxen en accounts die u uitgeeft, antwoorden in uw ticketsysteem en incidentrapporten schrijven die u ongewijzigd doorstuurt; uw klant heeft de hele tijd met u te maken. White-label ontwikkeling behandelt hoe dat wordt ingericht, en het geldt voor support op precies dezelfde manier.
Hoe support wordt geprijsd
Per persoon, per maand, zodat uw eigen kosten voorspelbaar zijn en u er een supportcontract voor uw klant tegenover kunt prijzen. Iedereen registreert tijd in ons eigen portaal, u ziet de uren de hele maand, en dezelfde cijfers leveren de factuur op, dus er is één administratie waartegen beide kanten afstemmen.
Waar support naast nieuwe ontwikkeling zit, zijn die twee meestal één delivery pod in plaats van twee contracten, zodat rustige weken aan de ene kant de drukke weken aan de andere kant betalen.
Vragen over supportafspraken
Wat omvat beheerde applicatieondersteuning?
Software die al live in productie staat laten blijven werken: de binnenkomende tickets beoordelen, defecten reproduceren en verhelpen, de technische vragen beantwoorden die de eerstelijns niet kan beantwoorden, patchreleases uitbrengen, afhankelijkheden en platformversies actueel houden, de meldingen bewaken en incidenten afhandelen wanneer er iets stukgaat. Het is tweede- en derdelijnswerk; uw eerstelijns blijft waar die is.
Werkt u volgens onze SLA?
Ja. Wij publiceren geen reactie- en oplostijden, omdat een getal dat is verzonnen voordat wij uw systeem kennen, niets waard is. Wij lezen de SLA die u uw eigen klant al verschuldigd bent, vertellen u eerlijk welke delen wij kunnen dragen en welke dekking daarvoor nodig is, en leggen ons daar vervolgens schriftelijk aan vast.
Kunt u ondersteuning buiten kantooruren of bereikbaarheidsdiensten bieden?
Ja. Ondersteuning buiten kantooruren en bereikbaarheidsdiensten worden vooraf afgesproken, vastgelegd in de ondersteuningsvoorwaarden en bemand door mensen wier werktijden daarbij passen, zodat een incident ’s nachts iemand bereikt die dienst heeft en niet iemand die uit zijn slaap wordt gehaald.
Kunt u een systeem ondersteunen dat u niet zelf hebt gebouwd?
Dat is het gewone geval. Tot nu toe negen overnames, de oudste geschreven in 2008. Ondersteuning van een overgenomen systeem begint met een review met alleen leestoegang en een schriftelijke lijst van risico’s, geordend naar impact op productie, zodat de eerste weken worden besteed aan begrijpen waarvoor u werkelijk verantwoordelijk bent en niet aan gokken onder druk.
Zijn de mensen die het systeem ondersteunen ook degenen die het wijzigen?
Ja, en dat is juist de bedoeling. De engineers in ondersteuning zijn engineers en geen aparte laag die tickets sluit, zodat een terugkerend incident bij de oorzaak kan worden opgelost en niet elke maandag opnieuw wordt gestart. Als u bij ons zowel een bouwstroom als een ondersteuningsstroom hebt, delen die twee codereview en architectuurbeslissingen.
Hoe wordt ondersteuning geprijsd?
Per persoon, per maand, zodat uw eigen kosten voorspelbaar zijn en u een ondersteuningscontract aan uw klant daartegen kunt afzetten. Uren worden vastgelegd in ons portaal en zijn de hele maand voor u zichtbaar, en dezelfde cijfers leveren de factuur op, zodat er voor beide partijen één bron is.
Hebt u systemen die moeten blijven draaien?
Vertel ons wat de systemen zijn, wat uw SLA belooft en waar support nu pijn doet. We lezen het en vertellen u welke delen we kunnen dragen, inclusief de delen die we niet kunnen.