SLA staat voor Service Level Agreement. Je hebt bedrijfskritische software draaien en deze moet te allen tijde beschikbaar zijn voor je gebruikers, want dat is voor de bedrijfsvoering van groot belang. Reden genoeg dus om dit te willen waarborgen, maar ook om er voor te zorgen dat er maatregelen genomen worden als er zich onverhoopt een productieverstoring voordoet.
Ook voor software engineers/devOps is een SLA met alles wat daarbij komt kijken interessant, want zij ontwikkelen en onderhouden de applicatie én leveren daar support op. Het monitoren van primaire processen en externe koppelingen, het uitvoeren van security checks van de applicatie(s) en het leveren van support horen daar dus ook bij.
Als klant kan je bij DIJ een SLA als dienst afnemen. Hierin worden duidelijke afspraken gemaakt en vastgelegd over wanneer en met welke prioriteit wij productieverstoringen in behandeling nemen en hiermee garanderen wij de vereiste continuïteit. In deze blog leggen wij uit wat er aan vooraf gaat als je een SLA afneemt en wat daar bij komt kijken, als klant én als software engineer/devOps.
Ok, maar hoe werkt dit dan in de praktijk?
Primaire processen en prioriteiten
Allereerst is het van belang om samen af te stemmen wat de primaire processen zijn van de applicatie. Als je bv. een webshop runt moeten gebruikers te allen tijde kunnen bestellen, anders wordt er omzet misgelopen of raak je (potentiële) klanten kwijt. En dat is precies wat je wil voorkomen. Productieverstoringen die het primaire proces raken, scharen wij onder de noemer ‘prioriteit 1’ en deze worden met hoge prioriteit opgepakt. Wij werken met vier verschillende prioriteiten, met elk hun eigen acceptatie-, response- en oplostijd. Problemen of vragen die niet direct beantwoord of opgelost hoeven te worden, kunnen bijvoorbeeld prima onder werktijd met de juiste prioriteit opgepakt worden. Daarom werken wij met verschillende gradaties, waarbij concrete voorbeelden in overleg worden vastgelegd om makkelijker te kunnen bepalen welke prioriteit iets heeft:
- Prioriteit 1 (Hoog): Het verhelpen van storingen in het primaire proces
- Prioriteit 2 (Gemiddeld): Verstoringen in de applicatie waarbij het primaire proces niet is verstoord.
- Prioriteit 3 (Normaal): Contextuele aanpassingen/toevoegingen aan de applicatie
- Prioriteit 4 (Laag): Functionele aanpassingen aan de applicatie
Monitoring en alerting
Om zo snel mogelijk te kunnen handelen bij prio 1 issues, omdat gebruikers er last van hebben, richten wij proactieve monitoring in om problemen in het primaire proces zo snel mogelijk te detecteren. Het meest simpele voorbeeld van dergelijke monitoring is elke minuut controleren of een webapplicatie nog te bereiken is voor gebruikers. Zodra een server een storing heeft, zal deze niet meer te bereiken zijn en wordt er een alert verstuurd zodat de impact bepaald kan worden. Op basis van de bevindingen worden dan de vervolgstappen genomen.
Daarnaast kun je de applicatie ook monitoren door middel van zogenaamde end-to-end tests. Hiermee kun je specifieke scenario’s periodiek controleren op de juiste werking op basis van een vastgelegde verwachting. Als je bijvoorbeeld inlogt in een applicatie, verwacht je op de account pagina uit te komen. Als dat niet zo is, dan wordt er een melding verstuurd zodat dit onderzocht kan worden. Ook kun je bijvoorbeeld op basis van logging metrics verzamelen over de responstijden van je API. Als je namelijk verwacht dat deze altijd een bepaalde waarde heeft, kun je dit periodiek controleren en bij afwijkingen een melding versturen.
Tijdens de ontwikkeling van features wordt er al nagedacht hoe we dit kunnen controleren en meten. Van belang is dan om daar goed op te kunnen monitoren. Ook de foutafhandeling binnen de applicatie wordt gemonitord, dus van elke onverwachte fout die zich voordoet in de code van de applicatie, ontvangen wij een melding zodat hier proactief op gehandeld kan worden.
Dergelijke monitoring gebeurt zowel op applicatie niveau als op server/platform niveau. Op het moment dat deze monitoring signaleert dat er prio 1 issue is, zal er een melding verstuurd worden naar de engineer die storingsdienst heeft, zodat hier binnen de gestelde reactietijd naar gekeken kan worden. Voor het monitoren gebruiken we tools als Grafana/Kibana (check dit blog voor meer hierover), Pingdom, StatsD (lees hierover meer in dit blog) en Bugsnag.
Hierbij wordt overigens onderscheid gemaakt tussen actieve en passieve monitoring, want het is in veel gevallen niet nodig om actief iets te signaleren, maar juist wel om op een later moment data als logging en metrics in te kunnen zien. Om een applicatie goed te kunnen beheren en doorontwikkelen heb je namelijk metrics en logging nodig en daarvoor gebruiken we dus passieve monitoring. En voor de prio 1 issues maken we gebruik van actieve monitoring, waarbij dus direct melding wordt gedaan bij afwijkingen.
Voor alerting gebruiken we on-call management tooling, waarop we de proactieve monitoring kunnen aansluiten. Hierin kunnen we escalatie policies instellen, zoals: bel/app/mail persoon A bij een melding, kunnen we deze niet bereiken na x minuten, bel/app/mail persoon B. etc. Verder leggen we hierin ook schema’s vast voor wie wanneer storingsdienst heeft.
Documentatie
Om tijdens een storingsdienst problemen zo goed mogelijk te kunnen adresseren is het van belang om de documentatie van de applicatie up-to-date te hebben. Jouw documentatie wordt net zo frequent bijgewerkt als de broncode van jouw applicatie. Idealiter. Dit kan bijvoorbeeld een troubleshooting document zijn waarin beschreven staat hoe je services herstart of een technische documentatie over hoe een feature is opgebouwd. Maar ook een document waarin beschreven staat wat de procedures zijn om het probleem te escaleren naar een 3e partij en wie je daarvoor kunt benaderen. Wij hebben namelijk vaak te maken met een externe koppeling waarvan je afhankelijk bent, dus is het een belangrijke zaak om daar ook goed zicht op te hebben.
Veel van de genoemde aspecten zijn al integraal onderdeel van onze werkwijze, waarmee we de uptime en kwaliteit van applicaties zo goed mogelijk waarborgen. Voor elke feature die toegevoegd wordt en elke bug die opgelost wordt, schrijven we tests om de werking te valideren én om te voorkomen dat issues terug kunnen komen (regressie tests). Daarnaast voeren we voor nieuwe features en bij wijzigingen aan bestaande functionaliteit, indien nodig, ook load tests uit. Lees hier meer hierover in dit blog. Met al deze tests valideren wij dat deze functionaliteit in productie doet wat wij verwachten en deze tests worden bij elke verandering aan de applicatie uitgevoerd. Hiervoor richten wij een OTAP-straat [1] (Ontwikkeling, Test, Acceptatie en Productie) in en elke verandering aan de applicatie doorloopt deze straat om te valideren dat alles blijft werken zoals verwacht.
Het ontwikkelen van nieuwe functionaliteit begint bij DIJ aan de ‘tekentafel’, dat doen we dus voordat we daadwerkelijk code gaan schrijven. Zo werken we o.a. flowcharts uit om processen, datastromen of architectuur etc. vast te leggen. Ook de API documentatie werken we uit en we beschrijven hoe troubleshooting toegepast kan worden.
Daarnaast wordt er ook documentatie geschreven in de vorm van tickets in Jira. Hierin staat functioneel beschreven hoe een feature zou moeten functioneren of wat een bug inhoud en hoe je deze kunt reproduceren. Naar deze tickets wordt altijd verwezen bij het ontwikkelen. Dit doen we door de ticketnummers te vermelden wanneer er code wordt toegevoegd in versiebeheer. Hierdoor is snel te herleiden waarom bepaalde code geschreven is, wat van belang kan zijn als er bug opgelost moet worden.
Ook tests zijn een vorm van documentatie en al deze vormen van documentatie dragen bij aan het begrijpen van de functionaliteit en daarmee dus ook het snel kunnen oplossen van problemen, mochten deze zich voordoen.
Niet alle scenario’s zijn altijd volledig gedocumenteerd of worden automatisch getest, maar zodra we dergelijke scenario’s tegenkomen zorgen we ervoor deze achteraf alsnog toegevoegd worden.
Fijn dat in veel zaken al voorzien wordt door de manier waarop jullie werken. Wat heb ik dan eigenlijk aan die SLA?
Het afspreken van een SLA geeft de garantie dat er iemand 24/7 beschikbaar is om problemen met de applicatie te adresseren. In overleg wordt de prioriteit van de melding bepaald en afhankelijk daarvan wordt een issue direct of op een later moment opgepakt.
Alles waarin wij al voorzien door onze werkwijze, draagt bij aan hoge kwaliteit software. Het bijkomende voordeel is dat wij in het geval van calamiteiten heel snel en adequaat kunnen handelen door de goede documentatie en het testen van de applicatie.
In dit geheel is security ook een belangrijk aspect, zodat je applicatie en de benodigde data veilig is. Bij het afspreken van een SLA voorzien wij ook in die behoefte door periodiek een geautomatiseerde security check én een handmatige check door een ethical hacker uit te voeren op de applicatie. De resultaten worden in een rapport verwerkt, welke uiteraard ook gedeeld wordt. Mochten er tijdens die check issues naar boven komen, dan worden deze verholpen en op basis van hoe kritisch het issue is wordt de prioriteit bepaald.
Kortom, als je een SLA met ons afspreekt ben je zeker van al onze toewijding en beschikbaarheid op het moment dat jouw bedrijfskritische applicatie dat nodig heeft. Da's een fijn gevoel toch?
Wil je graag meer weten over onze SLA of heb je nog vragen?
