Народ в продакшене⁠⁠

Чем дольше смотришь на происходящее, тем сильнее кажется, что это уже не политика и не управление, а вполне профессиональное тестирование. Просто тестируют не приложение, не сервис и даже не отдельный модуль, а терпение населения.

Причем, что особенно впечатляет, тестирование идет сразу в проде. Без тестового стенда, без пилотной группы, без staging-среды и, судя по всему, без плана отката.

Сначала, как и положено, запускают smoke test. Чуть поднимают цены, чуть добавляют сборов, чуть режут привычные сервисы, слегка ухудшают пользовательский опыт. Смотрят: система жива? Пользователь еще функционирует? Ворчит, но не отваливается? Отлично, базовая сборка считается стабильной, можно катить дальше.

Потом начинается нагрузочное тестирование. На одного и того же пользователя одновременно вешают рост тарифов, новые ограничения, ухудшение связи, странные инициативы, поломку привычных маршрутов и общее ощущение, что UI жизни кто-то обновил без согласования и явно не в ту сторону. Если после этого пользователь не падает в отказ, а просто матерится и ищет обходной путь, значит запас прочности у системы еще есть.

Следом идет стресс-тест. Это уже когда решения выглядят не просто неприятными, а откровенно абсурдными даже по меркам давно деградирующего интерфейса. Но именно в этом и смысл. Надо же определить предельные значения. После какого именно уровня неудобства пользователь перестанет адаптироваться и начнет воспринимать происходящее не как временный сбой, а как системную неисправность. Пока, судя по результатам мониторинга, пользователь все еще адаптируется. Значит тест признан успешным.

Отдельно, похоже, проводится регрессионное тестирование. Берут старые раздражители, на которые уже была негативная реакция, и запускают заново. Потому что надо проверить, считается ли это до сих пор багом или пользователь уже привык и переклассифицировал дефект в разряд штатного поведения системы. Если привык, можно закрывать тикет со статусом "не воспроизводится".

Есть и полноценное тестирование на отказоустойчивость. Насколько гражданин способен жить, когда привычные инструменты работают хуже, медленнее, нестабильнее или только через костыли. И тут результаты надо признать выдающимися. Пользователь не просто не умирает, он еще и сам себе пишет workaround. VPN поставит, маршрут поменяет, наличку снимет, приложение заменит, новую схему поведения освоит и даже не спросит, с какой стати именно он должен заниматься поддержкой этой разваливающейся инфраструктуры. Мечта любой команды, которая давно перестала чинить корневые причины и сосредоточилась на том, чтобы пользователи сами как-нибудь адаптировались.

Очень похоже, что параллельно идет и A/B-тестирование объяснений. Одним говорят, что это ради безопасности. Другим, что ради борьбы с мошенниками. Третьим, что это временные меры. Четвертым, что так и должно быть, а раньше просто была слишком щадящая эксплуатация. Потом аналитика, видимо, смотрит, какая формулировка лучше снижает уровень раздражения и дольше удерживает пользователя в состоянии пассивной совместимости с деградирующей средой.

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

И вот в этот момент происходящее внезапно перестает казаться нелогичным. Если исходить из того, что задача не в том, чтобы сделать удобно, а в том, чтобы постепенно сдвигать границу допустимого, то все выглядит удивительно последовательно. Сегодня ухудшили одно. Завтра другое. Послезавтра замерили реакцию. Если пользователь все еще не ушел в жесткий отказ, а просто бурчит и продолжает жать "принять", значит релиз можно считать условно успешным.

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

Пока что, как видно, терпит.

С матом. С костылями. Но терпит.

Хотя с тестированием отказоустойчивости в проде лучше не увлекаться. По накопленным логам видно, что проваленный тест иногда заканчивается не только сменой команды разработки, но и полной сменой архитектуры системы.