Als eigenaar van Simple Analytics denk ik dat het super belangrijk is om het vertrouwen van gebruikers op te bouwen. Het is bijna onmogelijk om geen fouten te maken, dus als een bedrijf nooit zijn fouten deelt, vertellen ze je waarschijnlijk niet de waarheid. Vandaar, hier zijn de mijne.
Wanneer je een nieuwe functie bouwt, wil je die waarschijnlijk zo snel mogelijk implementeren omdat je te enthousiast bent om ze aan je klanten te laten zien. Of soms voeg je een nieuwe dienst toe aan je server en weet je niet wat voor gevolgen dat kan hebben. Dat laatste overkwam mij.
In de afgelopen weken implementeerde ik een nieuwe functie genaamd Custom domain. Met deze functie konden gebruikers van Simple Analytics ad-blockers en tracking blockers omzeilen. Ik vind dat mensen tracking moeten kunnen blokkeren, dus Simple Analytics respecteert de "Do Not Track" instelling van de browser. Helaas is Simple Analytics toegevoegd aan sommige privacy-blokkadelijsten - wat ik niet eerlijk vind omdat we privacy zeer serieus nemen (de servers zijn verhuisd naar een zeer privacy-vriendelijk land: IJsland; versleuteld onze database server; Het verwijdert gegevens uit de database wanneer een gebruiker iets verwijdert; waardoor mensen hun gegevens kunnen downloaden). Dus de nieuwe functie was zeer welkom. Toen het eenmaal was uitgerold, begonnen een paar gebruikers het te gebruiken.
Vandaag vond ik een bug (gelukkig door mijzelf) bij het gebruik van de Custom domain-functie waar de JavaScript werd geladen, maar de API-aanroep om een wachtwoord vroeg. Ik zocht de websites van een van mijn klanten op ([excuseme.wtf](https://excuseme.wtf/?ref={{ site.hostname }})) van wie ik weet dat hij de Custom domain-functie gebruikte. Ik controleerde zijn statistieken en was geschokt te ontdekken dat er geen bezoeken waren in de afgelopen week. Meteen begon ik in mijn servers te graven, op zoek naar aanwijzingen.
Huidige setup
Simple Analytics gebruikt 4 servers om alles zo soepel mogelijk te laten verlopen. We hebben de Queue-server, dat is de server voor het verzamelen van de bezoeken van onze JavaScripts. Dit is een andere server dan de Main-server, omdat de Main-server versleuteld is. Als een server versleuteld is, mag hij alleen opstarten na het invoeren van een wachtwoord (anders is de versleuteling nutteloos). In het onwaarschijnlijke geval dat een reboot nodig is, wil ik garanderen dat er geen gegevens verloren gaan. Alle gegevens worden naar de Queue-server gestuurd, die ze naar de Main-server stuurt. Als de Main-server het verzoek niet accepteert, zal de Queue-server het verzoek "in de wachtrij zetten" (opslaan) wanneer de Main-server een back-up maakt.
Naast deze servers heb ik een Testing-server en een External-server. De Testing-server draait acceptatietests om belangrijke flows en eindpunten in de gaten te houden. De External-server is nodig voor de Custom domain-feature. Vanwege de scheiding der belangen wil ik om veiligheidsredenen geen SSL-certificaten van klanten op dezelfde server als de Main-server hebben.
Wat ging er mis?
Ik besloot om een nieuwe monitoring app te installeren op de Queue-server, zodat ik op afstand kon controleren of er problemen waren in de server. Het gaf me ook inzicht in CPU en geheugen gebruik. Ik voegde een NGINX configuratiebestand toe voor deze app zodat ik er van buitenaf bij kon. Bij het toevoegen van een nieuwe app test ik altijd de NGINX configuratie en herlaad deze als dat gelukt is sudo nginx -t && sudo nginx -s reload. NGINX gaf geen fout daarom kon ik toegang krijgen tot mijn nieuw geïnstalleerde monitoring app; ik ben blij.
Gelukkig heb ik een directory/records van NGINX logs, waaruit ik de meeste van de verloren request terug kan halen. Deze logs bevatten destijds minder informatie en registreerden alleen de tijd, URL en user agent.
Wat heb ik gedaan om te voorkomen dat dit opnieuw gebeurt?
Hoewel deze bug niet veel klanten trof en er geen significante hoeveelheid gegevens verloren ging, wil ik er alles aan doen om dit in de toekomst te voorkomen. De bug is ontstaan door het toevoegen van een andere app aan dezelfde server die geen enkele server richtlijn had gedefinieerd als de standaard server. NGINX doet dan zijn best om een server als standaard server te selecteren en stuurt de verzoeken naar de app die in die server is gedefinieerd.
Ten eerste heb ik de standaard server toegevoegd aan de luister richtlijn voor poort 80 en 443 in de hoofd app(nginx docs). De hoofdapp op die server was de externe app die de certificaten beheert voor de Custom domain-feature en antwoordt met een script en API-eindpunt gebruikt geen Simple Analytics URL's waardoor het moeilijk te blokkeren is.
Ten tweede heb ik de loggeschiedenis verhoogd tot 90 dagen, zodat ik bezoeken kan herstellen voor toekomstige problemen. De Queue-server en de Main-server logt nu elk mislukt verzoek van wie dan ook. Dit betekent dat elk verzoek dat een HTTP-code 5xx of 4xx retourneert, wordt opgeslagen in de logs en daaruit kan worden hersteld. Het vergt nogal wat werk om het voor elkaar te krijgen als het nodig is, maar het betekent geen gegevensverlies.
Ik heb acceptatietesten toegevoegd voor de Custom domain-feature die controleert of beide eindpunten nog steeds werken zoals verwacht. Als ze niet voldoen, zou ik een telefoontje en een Telegram-bericht krijgen.
Ten slotte ga ik nieuwe functies taggen als "Beta-versie", zodat klanten zich ervan bewust zijn of verwachtten dat het fouten zou hebben, omdat het niet zou zijn voltooid voor definitieve relsease. Het is dus aan de klanten om het risico te nemen en de functie op eigen risico te gebruiken.
Ik heb contact opgenomen met de klanten die door deze bug werden getroffen en hen hun geld voor die maand terug aangeboden. Ze vonden dat niet nodig en zeiden dat ik me er geen zorgen over moest maken. Ik heb mijn best gedaan om de meeste van hun gegevens te herstellen en met alle bovenstaande acties ben ik er vrij zeker van dat dit niet meer zal gebeuren.
Laten we de transparantie rond fouten veranderen en ik denk dat mensen je bedrijf serieuzer zullen nemen. Je laat zien wat je eraan gedaan hebt en hoe capabel je bent. Sommige mensen zullen betwisten of het slim is, maar ik zie dit als een kans om transparantie te tonen.