Het inschatten van een prestatieverlies
Hoe een prestatieverlies kunt inschatten: het gaat hierbij vooral om de diagnose, niet om de oplossing. Hoe kunt u de omvang ervan inschatten wanneer de oorzaak onbekend is en een SLO op het spel staat?
p95 is vorige week verdubbeld en de vergadering stemt over de verkeerde kwestie.
Prestatieverlies is meestal moeilijk te diagnosticeren, maar eenvoudig op te lossen. Het team dat de N+1-query al heeft ontdekt, weet dat de oplossing eenvoudig is. Het team dat dit nog niet heeft gedaan, stemt over een story waarvan de feitelijke inhoud luidt: „drie dagen besteden aan het bestuderen van flame graphs.” Dat zijn twee verschillende stories.
Twee vragen zijn bepalend voor de schatting. Ten eerste: is de oorzaak bekend? Zo ja, bepaal dan de omvang van de oplossing. Zo nee, bepaal dan de omvang van het onderzoek. Ten tweede: welke SLO is door de regressie geschonden en wat is de deadline voor het herstel ervan? Een regressie die een klantgerichte SLO schendt, heeft een andere urgentie dan een vertraging van 10% die niemand heeft opgemerkt.
Wat er in de kamer wordt gezegd
SRE: “De p95-waarde is afgelopen woensdag gestegen van 200 ms naar 450 ms.”
Backend: “Is er iets opvallends te zien in de implementaties van die dag?”
Kop: “Drie implementaties. Geen enkele daarvan had betrekking op het trage eindpunt.”
Backend: “Of het leek er niet op dat ze het trage eindpunt hadden geraakt.”
SRE: „Vallen we binnen de SLO? Hebben we tijd om dit grondig te onderzoeken?”
Vragen die u zich het beste kunt stellen voordat u gaat stemmen
- Is de oorzaak bekend, of zijn we bezig met het opzetten van een onderzoek?
- Wat houdt de SLO in, en wordt deze momenteel overschreden?
- Wat is er veranderd tussen de laatste gunstige periode en de eerste ongunstige periode?
- Beschikken wij over flame graphs, traces of alleen dashboards?
- Is het terugdraaien van de wijzigingen een haalbare oplossing terwijl wij het onderzoek uitvoeren?
Als de oorzaak nog steeds slechts een gok is, gaat het hier om een time-boxed spike, niet om een oplossing — en als een SLO wordt overschreden, zorgt een rollback ervoor dat u de tijd krijgt om de spike uit te voeren zonder dat de klok tegen u werkt.
Bepaal de omvang op basis van wat u daadwerkelijk hebt, niet op basis van wat u graag zou willen hebben. Als de oorzaak onbekend is, betekent dit dat u de omvang van de zoekopdracht bepaalt.
Net als bij het inschatten van een bug die niet kan worden gereproduceerd, zit het werk hem in de diagnose. Bekijk de andere voorbeelden van uitgewerkte schattingen, of start een gratis Planning Poker-sessie zodra de oorzaak is vastgesteld.