Автор: Филипе Фрайр (Filipe Freire)
Оригинал статьи
Перевод: Ольга Алифанова

Во втором эпизоде обзора инструментов, а также в моей пародии про нагрузочное тестирование «Как быстро разбогатеть», я упоминал, как активно продавцы коммерческих инструментов нагрузочного тестирования употребляют нагрузочную терминологию, искажая ее, чтобы попытаться обдурить потенциальных покупателей. Крупнейшее искажение – это хищнические и (почти) криминальные схемы, основанные на описании, как «виртуальные пользователи» и схожие концепции продаются и описываются для тех, кто отвечает за затраты на нагрузочное тестирование.

Подготовка

Подготовка к мошенничеству начинается с жертвы: человек, отвечающий за распределение ресурсов на нагрузочное тестирование, убежден, что их непротестированные сервисы должны выдержать «миллионы пользователей» или «миллионы запросов», и верит, что их приложения должны масштабироваться до бесконечности и обрабатывать миллиарды транзакций по запросу.

В большинстве (но не всегда) случаев вышеописанное – не более, чем симптом широкомасштабной неуверенности в бесконечном масштабировании, порожденной тайной мечтой стать новым Нетфликсом и волнением за размер… ммм… цифровых гениталий?

Злоумышленники, то есть продавцы коммерческих инструментов и инструментов с закрытым исходным кодом, знают об этом фетише и эксплуатируют его как слабость – так же, как сделали бы социальные инженеры. Приманка такова: «Знаете, ваше приложение настолько важно для людей, мы верим в вашу миссию, мы хотим вам помочь – давайте добьемся синегрии, нам кажется, вам необходимо вот такое количество виртуальных пользователей…»

То есть они отправляют жертве:

• Буклет о продукте, упоминающий, что их частный инструмент действительно интегрируется с миллионом других инструментов, а также, помимо прочего, благословлен Великим Папой Универсальной Церкви Обеспечения Качества;
• Табличку, приложенную к буклету, с ценами на лицензию облачного решения для этого продукта;
• И/или табличку с ценами на лицензию для серверного решения (скорее всего, там есть какое-то ограничение по объемам).

В худших случаях цены никогда не доступны напрямую/прозрачно/публично, и жертве непременно нужно прорваться через каких-то продажников. Таблица всегда различается для разных клиентов, и зачастую в ней сумасшедшие цены в формате, любимом ответственными за бюджет: все представлено четко и ясно, в одной колонке количество виртуальных пользователей, или запросов в секунду, или еще какое-нибудь большое число без внятного описания, что оно значит – а в другой ценник.

Так как большинство жертв обычно свободно распоряжается бюджетом, а буклет выглядит «симпатичным и корпоративно дружелюбным», и в нем говорится, что инструмент гарантирует тестирование нагрузки для всегалактических триллионов пользователей, жертва выбирает вариант, продает душу продавцу инструмента… и обе стороны становятся профессиональными лучшими друзьями навсегда-навсегда.

Замечу для тех, кто хочет узнать больше о фольклоре этого конкретного мира: вот вам бонус. Низкооплачиваемые интерны и/или потогонные фабрики, которым организация-жертва заплатит за выполнение работ по нагрузочному тестированию, тоже сертифицированы и могут пользоваться этим коммерческим инструментом и… они партнеры провайдера этого инструмента! Кто бы мог подумать?!

Суть мошенничества

Суть этого мошенничества проста и чертовски эффективна: присвой концепции, которая требует глубокого погружения в контекст, вроде концепции виртуальных пользователей или запросов в секунду, ценник; упрости проблему донельзя, и все готово.

Вот что эти недобросовестные провайдеры коммерческих инструментов нагрузочного тестирования не объясняют потенциальным покупателям или пускают это мельчайшим шрифтом:

• Если нагрузка, которую вы исследуете, идет мелкими краткими скачками, - к примеру, запросы, которые (почти) всегда занимают лишь несколько миллисекунд, то конкретное количество виртуальных пользователей приведет к большему количеству запросов в секунду. Если, с другой стороны, запросы занимают секунды, потому что сервис ждет, пока что-то произойдет под капотом, то то же самое количество виртуальных пользователей выразится в меньшем количестве запросов в секунду: виртуальные пользователи и запросы в секунду сильно зависят от контекста тестируемой системы.
• Если для коммерческого инструмента, которыми люди надеются воспользоваться в 21 веке, нет правдивых и воспроизводимых, публично доступных реперных точек, а также отсутствует прозрачная информация об инфраструктуре облака, то вы по-дурацки заплатите лишнее за положительные эмоции и ободрение, а не за надежный инструментарий. Честные продавцы инструментов предупредят об ограничениях своего инструментария. Злоумышленники (как правило, продающие частные инструменты) спрячут любую информацию, невыгодно выставляющую их продукт.
• Сложные, относящиеся к реальной жизни профили нагрузки и настройки никогда не демонстрируются провайдерами коммерческих инструментов на демо в ходе продаж. На это есть причина: проектируя профиль нагрузки, всегда учитываются пределы мощности как генератора нагрузки, так и нагружаемой системы. Ограничения также относятся к сложности проектируемого профиля. Не принимайте решений по бюджету или инструментарию, если лично вы не попробовали воспользоваться инструментом для реальной значимой задачи.
• Для большинства людей «стрелка компаса» сдвигается просто благодаря попытке провести любое (эффективное/значимое) тестирование нагрузки, даже в крошечном масштабе. Это касается всего, что может прийти вам в голову: ограничения сохранности, зависимости от внешних сервисов, баги кода, баги инфраструктуры и сети, плохая конфигурация балансировщика нагрузки, баги прокси, проблемы DNS, общая нестабильность и странность… Любую из этих проблем можно выявить, проведя нагрузочное тестирование даже в небольшом объеме, хоть в это и трудно поверить. Так можно найти любую проблему, кроме проблем, касающихся непосредственно людей, работающих с нагрузочным тестированием.
• Пункт, связанный с предыдущим: вы не можете заставить генератор нагрузки сделать больше, чем он способен, и вы не можете (и не должны) ожидать, что целевая система будет линейно или предсказуемо отвечать на определенную нагрузку. В (крайне вероятном) случае, когда целевая система «тонет» и инфраструктура частично или полностью помирает, фиксированное количество виртуальных пользователей не приведет к фиксированному количеству запросов в секунду: виртуальные пользователи «застрянут». Учитывая это – если вы впервые приступаете к нагрузочному тестированию, то все еще действуете, как первооткрыватель, пытаясь разобраться, как реагирует система на разные виды нагрузки. Нет смысла заранее оплачивать конфигурацию нагрузки, которая вам «пока» не нужна.
• Кто угодно может «бомбардировать» сервис, используя бесплатные инструменты для нагрузочного тестирования, и выявить те же (или даже более интересные) проблемы, которые выявит дорогостоящий коммерческий инструмент. Но ни один чудесный инструмент нагрузки не исправит предыдущие проблемы с возможностью наблюдать за системой и отслеживать ее целевую нагрузку.
• …

Заключение

Итак, жестокая реальность такова: компании-жертвы заплатят за

• Свежую новость – о да, от большого трафика мы помрем! Но при этом никакой подробной информации, чтобы инженеры действительно разобрались в проблеме, не будет.
• Потенциально чужое облачное решение за двойной тариф.
• Ложное чувство гордости и комфорта: «Глядите, топ-менеджмент, мы потратили наш бюджет в Х миллионов на нагрузочное тестирование, чтобы получить инструмент промышленного уровня; мы выполнили эти KPI, убедились в качестве, провели нагрузочное тестирование, успешный успех, дайте пять, все круто». А баги, плавающие на мелководье значимого нагрузочного тестирования, процветают и живут себе спокойно.
• …

В итоге люди получают разрыв между своим контекстом и реальными нуждами в нагрузочном тестировании, и инструментом, который может подходить или не подходить к этому контексту и нуждам. Это необязательно конец света, но это нечестно и неправильно, и лично я считаю это аморальным. У меня нет рецепта, как все исправить, разве что ряд рекомендаций:

• Всегда старайтесь получить информацию и требовать подкрепления заявлений продавца о его инструменте.
• Принимайте информированные решения об инструменте, основанные на понимании вашего контекста, а не на рекламной кампании, под которую вы пытаетесь подогнать ваш контекст.
• Никогда не забывайте, что не все связанные с финансами решения об инструментарии нагрузочного тестирования имеют преимущество перед другими решениями – особенно перед решением о трате времени. Дорогостоящий коммерческий инструмент может рекламироваться, как сберегающий ваше время, но на практике это может быть лишь дымовой завесой, о чем вы узнаете, начав применять этот инструмент в вашем конкретном контексте.
• Если вы можете выбирать, сначала воспользуйтесь инструментами с открытым исходным кодом (k6, locust, для мазохистов можно и jmeter), нырните с ними глубоко, и только потом, если вы не удовлетворены, исследуйте рынок в поиске других вариантов.