Багато розробників сприймають успішні результати навантажувальних тестів як фінішну пряму перед релізом. Якщо показник p95 залишається в межах норми, ми вважаємо систему готовою до роботи. Однак реальність часто виявляється складнішою, ніж будь-який штучний сценарій. Навантажувальне тестування відповідає на питання, які ми самі задаємо, тоді як продакшн ставить питання, до яких ми не завжди готові.
Типовий приклад — сервіс сповіщень, який успішно проходив тести, але впав через банальне уповільнення зовнішнього API. Коли час відповіді постачальника зріс з 150 до 900 мс, черги почали накопичуватися, а механізми повторних спроб лише погіршили ситуацію. Це доводить, що стабільність системи залежить не лише від її пропускної здатності, а й від стійкості до деградації зовнішніх залежностей.
Різниця між тестуванням та інженерією продуктивності полягає у фокусі. Тестування перевіряє цифри в ідеальних умовах, тоді як інженерія забезпечує надійність у непередбачуваних обставинах. Ми повинні перестати розглядати зелений графік тестів як доказ надійності. Справжня робота починається після релізу, коли система стикається з реальними затримками та несподіваними помилками в мережі.
Наша команда змінила підхід, почавши аналізувати сценарії відмови замість простої пропускної здатності. Ми детально розписуємо поведінку кожного критичного компонента при уповільненні залежностей. Важливо не просто знати, що станеться при повному відключенні, а розуміти, як система поводиться, коли вона просто працює повільно. Це дозволяє вчасно впроваджувати механізми відмовостійкості та fallback-рішення.
Ми також відмовилися від орієнтації на середні показники на користь p99, адже саме там знаходяться наші найнезадоволеніші користувачі. Впровадження бюджетів помилок дозволило зробити стабільність пріоритетом: якщо ліміт вичерпано, розробка нових функцій зупиняється. Це може здаватися бюрократією, але насправді це ефективний інструмент для запобігання технічному боргу та суперечкам всередині команди.
Нарешті, відповідальність за відмовостійкість не повинна лежати на одній людині. Ті, хто пише логіку повторних спроб, мають розуміти, як система буде поводитися при збоях. Регулярні навчання, де ми штучно вводимо затримки в стейджинг, допомагають команді бачити реальні слабкі місця. Пам'ятайте, що реліз — це лише початок, а справжня інженерія відбувається щодня після нього.
🔗 Першоджерело: Читати оригінал