Adres
Utrecht, Veenendaal

Werktijden
Maandag tot en met vrijdag: 9.00 tot 17.00 uur
Weekend: 10.00 tot 17.00 uur

Ik leidde de service die corrupte data op het Qfact-platform vindt, terugvoert naar het gedrag dat het veroorzaakte en herstelt. Geen enkele klant hoeft eerst het symptoom te melden.

  • OpdrachtgeverQfact, een SaaS-platform voor complexe analyses
  • Periode2022
  • RolLeidde het project, van onderzoek tot oplevering
  • Draait opDe event driven architectuur van het platform
  • Het platform controleert zijn eigen invarianten en markeert toestanden die het nooit zou mogen bereiken.
  • Gebouwd op de event store, zodat een fout wordt teruggevoerd door de keten van gedrag die hem voortbracht.
  • Terugkerende bugklassen die gebruikers raakten, werden afgesloten en kwamen niet terug.

Context

Op een platform waar dagelijks duizenden mensen werken en services events naar elkaar publiceren, blijft één onbedoelde write niet op één plek. Hij verspreidt zich, duikt dagen later op als iets wat losstaand lijkt, en komt bij support binnen als een verhaal in plaats van een stack trace. Ik leidde het project dat hiervan iets maakte wat het platform zelf kon detecteren.

De uitdaging

Detectie is de helft die makkelijk te beschrijven is en moeilijk goed te krijgen. De service moest toestanden herkennen die onmogelijk zouden moeten zijn, een echte fout onderscheiden van een legitieme edge case, en vervolgens herstellen zonder zelf de volgende bron van corruptie te worden. Hij moest ook binnen een bestaande event driven architectuur passen in plaats van ernaast te staan en te gokken.

Wat ik deed

  • Onderzocht het probleem voordat ik ging bouwen, wat betekende dat ik las hoe de corruptie in de praktijk daadwerkelijk ontstond en wat het platform er al over wist, niet alleen hoe een goede integriteitscheck er in het algemeen uitziet.
  • Sprak de mensen die de kosten droegen, support en de engineers die de tickets bleven krijgen, zodat de regels de echte faalklassen vastlegden en niet de theoretische.
  • Bouwde de service in Python, die invarianten over services heen controleert en toestanden markeert die het platform nooit zou mogen bereiken.
  • Las de event store om de oorzaak te vinden, door de keten van gedrag terug te volgen van een foute toestand naar de actie die hem creëerde, en dat is wat een reparatie veilig te automatiseren maakt.
  • Automatiseerde de reparatie, voor de faalklassen waar de juiste eindtoestand ondubbelzinnig is, en liet de rest zichtbaar in plaats van gegokt.

Het resultaat

  • Datacorruptie die door het platform zelf wordt gedetecteerd en hersteld.
  • Minder belasting voor support, omdat de klasse tickets die dit genereerde bij de bron werd afgesloten.
  • Een platform dat zijn eigen fouten meldt, wat een ander gesprek met een klant oplevert dan een platform dat wacht tot het te horen krijgt.

Gebruikte technologieën

  • Python: De integriteitsservice zelf.
  • Event sourcing: De event store die de service leest om de oorzaak te herleiden.
  • Microservices: De architectuur waarover de service invarianten controleert.
  • GraphQL: De API-laag over het platform.
  • OAuth 2.0: Autorisatie op de platform-API's waarlangs de service benaderd wordt.
  • Docker: Hoe de service wordt verpakt en gedraaid.
  • Jest: Geautomatiseerde tests rond de controles en reparaties.

Als er in je supportqueue steeds hetzelfde type ticket terugkomt, dan is dat meestal een dataprobleem, en dat zeg ik dan ook rechtuit.