Software die uit een handvol diensten bestaat, laat zich niet meer debuggen door in de logs te kijken. Wij richten meetwaarden, logregels en traces zo in dat u een verzoek van begin tot eind kunt volgen, en zetten de alarmering op wat uw gebruikers merken in plaats van op wat een machine toevallig meldt.
Er wordt in de meeste organisaties niet te weinig gemeten, maar te veel en te los. Drie dashboards die elkaar tegenspreken, twee alarmkanalen waarvan er een op stil staat, en een logbestand dat zo groot is geworden dat niemand er meer in zoekt. De vraag die op het moment van een storing telt — waar in de keten gaat dit mis — is dan nog steeds niet te beantwoorden zonder drie mensen erbij te halen.
Voor het gereedschap zelf bestaan goede producten: Grafana met Prometheus, Loki en Tempo, Datadog, Elastic, New Relic, Honeycomb, Sentry, en de ingebouwde diensten van Azure, AWS en GCP. Draait daar bij u al iets en past het, dan adviseren we u dat te houden. Wij vervangen zelden een platform als losstaande oplossing; een tweede leverancier ernaast maakt het beeld meestal juist verder versnipperd.
Wat wij wel doen is de laag ertussen: instrumentatie in uw software zodat er iets te meten valt, een traceerspoor dat over systeemgrenzen heen blijft lopen, en alarmering die aan een dienst hangt in plaats van aan een server. Dat doen we vaak als onderdeel van een moderniseringstraject, naast het inrichten van DevSecOps in de pijplijn, of los wanneer de storingen zich opstapelen en niemand kan aanwijzen waarom.
De meeste trajecten beginnen bij een van deze drie en groeien door zodra het eerste beeld er is. In het eerste gesprek zeggen we welke variant bij uw landschap het meeste oplevert, en welke u beter kunt uitstellen.
Doorlooptijd, foutpercentage, verkeer en verzadiging — per dienst, met de spreiding erbij en niet alleen het gemiddelde. Een gemiddelde van tweehonderd milliseconde kan betekenen dat iedereen tweehonderd wacht, of dat een op de honderd acht seconden wacht; dat laatste is waar uw klachten vandaan komen. Wij leggen die meting vast in de software, brengen ze samen op een dashboard dat over uw dienstverlening gaat, en halen de alarmen weg die over losse technische waarden gaan.
Een verzoek dat door vier diensten gaat, krijgt bij binnenkomst een spoor dat het overal mee naartoe neemt. In uw eigen code, in de wachtrijen ertussen en in de aanroepen naar externe partijen. Wij bouwen dat met OpenTelemetry, zodat u niet aan een leverancier vastzit, en zorgen dat logregels en meetwaarden hetzelfde spoor dragen. Vanaf dat moment is de vraag “waar bleef dit verzoek hangen” een klik in plaats van een middag.
Een doelwaarde per dienst — hoeveel verzoeken mogen falen of te lang duren voordat het een probleem is — en een budget dat daaruit volgt. Dat maakt van “het is traag” een getal waar een gesprek over te voeren is, en het geeft uw team een eerlijke grens tussen nieuwe functies bouwen en stabiliteit repareren. Inclusief rapportage richting uw opdrachtgever of, wanneer u zelf levert, richting uw klanten.
Een werkende opstelling die op uw eigen platform draait, met de kennis in uw team om hem uit te breiden zonder ons erbij te halen.
Vier situaties die wij telkens terugzien bij organisaties die ons hiervoor benaderen. Herkent u er een, dan is er waarschijnlijk iets te winnen.
Er gaat iets stuk en er zitten drie mensen in drie systemen te kijken, zonder te weten of ze het over hetzelfde verzoek hebben. De hersteltijd wordt niet bepaald door de reparatie maar door het vinden. Dat is precies wat een doorlopend traceerspoor wegneemt.
Er komen zoveel waarschuwingen binnen dat het kanaal is gedempt. Op het moment dat er echt iets is, valt dat niet meer op tussen de ruis. Het probleem is bijna nooit de hoeveelheid maar de aard: er wordt gealarmeerd op machines in plaats van op dienstverlening.
U wilt onderbouwen dat een investering in stabiliteit iets heeft opgeleverd, maar er is geen meting van voor die tijd. Zonder cijfers wordt elke verbetering een mening, en een mening houdt geen stand in een gesprek over waar het budget heen gaat.
Wat begon als een applicatie is uitgegroeid tot een handvol diensten met wachtrijen en externe koppelingen ertussen. Het gereedschap dat bij een applicatie werkte, geeft nu een beeld per onderdeel en niet van het geheel.
Een gesprek over wat er nu draait, wat er al gemeten wordt en waar de laatste paar storingen vandaan kwamen. We vragen naar de systemen ertussen — wachtrijen, externe koppelingen, geplande taken — want daar zitten de blinde vlekken meestal. Ook brengen we in kaart welke koppelingen onderdeel worden van het spoor.
We meten wat er vandaag is: welke diensten leveren al signalen, welke helemaal niet, en wat kost de huidige opslag. Daarnaast lopen we de laatste storingen na en vragen per storing wat iemand had willen zien. Aan het einde ligt er een scope die begint bij de dienst waar de meeste tijd verloren gaat, niet bij de dienst die het makkelijkst te instrumenteren is.
We werken in tweewekelijkse sprints en leveren per sprint een dienst op die volledig is aangesloten: meetwaarden, logregels met spoor, en traces die doorlopen naar wat erachter zit. Uw eigen ontwikkelaars werken mee, want instrumentatie die door een ander is aangebracht, wordt zelden onderhouden.
Pas als er genoeg gemeten wordt, richten we de alarmering in. Per alarm leggen we vast wie hem krijgt, wat de eerste handeling is en wanneer er wordt geescaleerd. Tegelijk ruimen we de bestaande alarmen op; dat levert in de praktijk vaker rust op dan het toevoegen van nieuwe.
Twee werksessies met uw team, een korte periode waarin wij meekijken bij echte storingen, en daarna een evaluatie waarin we de hersteltijd afzetten tegen de nulmeting. Als u daarna onderhoud bij ons wilt beleggen kan dat, maar het is geen voorwaarde.
Wat ontwikkelteams, IT-managers en verantwoordelijken voor beschikbaarheid ons meestal vragen voordat zo’n traject begint.
Een kennismaking van een half uur, vrijblijvend. Vertel wat er de laatste keer misging en hoe lang het duurde voordat iemand wist waar het zat — dan zeggen we waar wij zouden beginnen, ook als we uiteindelijk niet samenwerken.
Appfront gebruikt cookies en vergelijkbare technieken voor een goede werking van de website, voor analyse en voor marketing. Je kiest zelf wat je toestaat. Lees meer in ons privacybeleid.
