Мы как саперы — не имеем права на ошибку

За последние пять лет тестированию производительности в Сбербанке стали уделять значительно больше внимания. Отмечу, что внимание и доверие пришли не сразу. Мы приложили значительные усилия для повышения экспертизы, чтобы к нам стали прислушиваться и обращаться за советами. Тогда же был запущен крупный проект повышения надежности критичных автоматизированных систем банка «99,99», который обеспечил соответствующий уровень доступности систем — не более 52 минут простоя за год. Тестирование производительности внесло значительный вклад в успех проекта и обеспечило надежность систем в условиях постоянного роста бизнеса.

Теперь проверкой производительности занимается специальная команда. А само тестирование производительности стало обязательным этапом между разработкой и инсталляцией новых версий продукта. Цель конкретно моей команды проста: сохраняя качество, не становиться узким местом. Мы делаем все, чтобы в нас не упирался поток доработок и чтобы мы успевали протестировать обновления на должном уровне.

C переходом к Agile значительно ускорился Time-to-Market, и этап тестирования релизов был сокращен с полутора месяцев до двух недель. Сокращение сроков стало настоящим вызовом для моей команды.

Об особенностях продукта

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

Для проверки изменений мы вручную кодируем скрипт, который в точности воспроизводит поведение пользователя. Если скрипт работает правильно, то мы запускаем множество его копий на виртуальных машинах. И вот уже платежную систему проверяет не один «робот», а тысячи. Протестировать такие масштабы вручную было бы очень дорого. Фактически — невозможно. Если всех сотрудников нашего здания попросить одновременно зайти в приложение и совершить платеж, то они лишь на небольшую долю повторят то, что делают наши скрипты. В то же время на запуск наших скриптов требуется лишь один сотрудник.

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

Об ошибках

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

Расскажу на примере, сколько человеко-дней может потенциально пропасть из-за одной ошибки тестировщика. Допустим, в пятницу молодой инженер зарегистрировал дефект системы, но не добился его исправления. Это была первая найденная им ошибка, и он неправильно указал степень ее критичности. Также предположим, что в выходные произошла установка релиза и в понедельник платежная система упала на 20 минут. А теперь умножим количество платежей, которые не были оформлены в этот период, на среднее время создания каждого из них. Мы получим количество времени, которое инженеру нужно потратить на пересоздание платежей. Оно равно продолжительности его жизни. У нас в команде даже появился термин «инженеро-человеко-жизнь».

Об инструментах и подходах

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

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

Об автоматизации

У нас полностью автоматизирована подготовка тестового стенда, включающего в себя более 100 серверов и порядка 100 ТБ тестовых данных. Это рутинная работа, которую долго выполнять вручную. Помимо этого, автоматизирован первый этап подготовки — проверка узлов системы. Непосредственно тестирование и сбор результатов происходят также без участия человека.

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

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

Об аутсорсинге и кадрах

Когда я пришел в Сбербанк, в моей команде внешних сотрудников было больше, чем штатных специалистов. Команда компании «Инфосистемы Джет» помогла нам построить процесс регулярного нагрузочного тестирования и справиться с потоком бизнес-задач. Постепенно мы увеличивали долю штатных сотрудников. Когда она превысила 80%, мы отказались от аутсорсинга. И последние два года работаем без подрядчиков.

Я считаю, что на аутсорсинг можно отдавать почти все. Вопрос: в какой момент? Например, при быстром старте. Когда есть ограничения по найму, а рабочих задач много, аутсорсинг является разумным решением. Бесконечно перегружать свою команду нельзя, иначе можно спровоцировать выгорание сотрудников и волну увольнений. Также стороннему исполнителю можно отдавать непрофильные для бизнеса функции и фокусироваться на стратегических задачах.

Последние 10 лет на рынке хронически не хватает специалистов по производительности. А в регионах их нет вообще. Поэтому нам приходится брать разработчиков и учить их писать нагрузочные скрипты, запускать тесты. Я считаю, что ключевым навыком для инженеров по производительности является программирование.

Мы регулярно проводим стажерские программы — предлагаем выпускникам технических вузов попробовать свои силы в Сбербанке. Особенно мы рады студентам из топ-10 вузов России. Чаще всего после стажировки ребята остаются у нас работать.

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

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

О переменах в тестировании производительности

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

Изменились инструменты. Когда-то нам хватало одного Micro Focus LoadRunner Enterprise, но сейчас мы используем множество инструментов — те же Jenkins, InfluxDB + Grafana, которые позволяют мгновенно развернуть окружение, автоматически подготовить стенд, собрать данные и наглядно продемонстрировать результаты. Это можно сравнить с укомплектованностью автомобилей: раньше были только дворники и радио, а теперь кондиционер, круиз-контроль, видеокамеры и автоматическая парковка.

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

Самое важное — повысилась вовлеченность команды. Результат, к которому мы все стремимся, —надежный работающий продукт в проме. Тестирование производительности стало ближе к бизнесу, разработке, сопровождению.