Привет! Меня зовут Ксения Якиль. Я пишу core-сервисы на C и Go в бэкенд-отделе Badoo и Bumble. Наш бэкенд это высоконагруженная распределённая система, обслуживающая пользователей по всему миру. Она оперирует большими массивами данных и делает всю ту магию, благодаря которой люди находят друг друга.

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

Знакомьтесь, сервис М!

В нашем ведении находился один из очень важных сервисов M. Он был первоисточником информации о пользователях и их симпатиях друг к другу. М был самодостаточным, большим, надёжным и даже был покрыт юнит- и функциональными тестами.

Сервис состоит из фронта (Front) и нескольких шардов (S1SN):

Но с увеличением количества задач в одиночку М перестал справляться так хорошо, как раньше. Поэтому у него появились товарищи другие сервисы: мы выделили отдельные логические части M и обернули их в сервисы на Go (Search и Supervisor), добавили Kafka и Consul.

И стало так:

За короткий промежуток времени из простого сервиса на С выросла довольно сложная структура, состоящая уже из пяти компонентов и ещё большего числа инстансов. В итоге мы получили распределённую систему и ряд вопросов в подарок:

• Работает ли функционал, в котором участвуют несколько сервисов?

• Поднимается ли система в заданной конфигурации?

• Что будет, если один из сервисов вернёт некорректный ответ?

• Что сделает наша система, если один из сервисов будет недоступен: вернёт ожидаемые ошибки, повторит отправку, выберет другой инстанс и отправит запрос туда или вернет закешированные данные?

Мы знаем, как должна вести себя система. Но совпадают ли ожидания и реальность?

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

Появилось и другое узкое место: мы начали параллельно разрабатывать компоненты и очень сильно загрузили отдел тестирования. Это привело к увеличению сроков доставки новых фич на продакшен.

Поэтому мы решили создать автоматизированные интеграционные тесты для сервисов М и Ко и убить одним выстрелом двух зайцев: автоматически выявлять ошибки интеграции до продакшена и сократить сроки доставки фич на прод за счёт совместного с отделом тестирования написания интеграционных тестов.

Мы понимали, что наряду со всеми очевидными плюсами у интеграционных тестов есть не менее очевидные минусы: увеличение времени прогона тестов, нестабильность, сложность написания. Но этого было недостаточно, чтобы остановить нас.

Требования к фреймворку

Какие требования мы предъявляли к интеграционному фреймворку?

• Легковесность: минимум абстракций и простота добавления новых тестов.

• Обозримое (по возможности небольшое) время прохождения тестов. Требовались быстро поднять инфраструктуру и осуществить прогон тестов.

• Запуск разных конфигураций системы. Фреймворк должен позволять настраивать каждый сервис, запускать разные наборы сервисов (подсистемы) и на них отдельно прогонять тесты. Путь от простого к сложному: сначала убеждаемся, что работает небольшая подсистема, потом усложняем её, проверяем и так далее.

• Реализация на языке Go, поскольку наш отдел разработки пишет на нём. Нам Go очень нравится, а тестировщики быстро его освоили и тоже пишут на нем фреймворк и интеграционные тесты.

С высоты МКС (схематичный план)

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

Модули нашего фреймворка предоставляют всё необходимое для генерации данных, ожидания выполнения запросов, проверки ответов, работы с инфраструктурой и многое другое. Поскольку фреймворк написан на Go, мы решили использовать go testing, а сами тесты поместили в отдельные файлы.

Для настройки и очистки окружения мы используем модуль Testify. Он позволяет создать suite, в котором определены функции:

• SetupSuite. Вызывается до прохождения всех тестов для данного suite. Именно здесь мы будем осуществлять подготовку окружения.

• TearDownSuite. Вызывается после прохождения всех тестов для suite. Тут мы почистим за собой инфраструктуру.

• SetupTest. Вызывается перед каждым тестом для suite. Здесь мы можем осуществлять какую-то локальную подготовку к тесту.

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

Собираем инфраструктуру

Инфраструктура должна предоставлять много возможностей:

1. Настраивать разную конфигурацию наших сервисов.

2. Поднимать сторонние сервисы (наподобие Kafka и Consul). Если использовать инстансы внешних сервисов на devel, то проведение интеграционного тестирования может влиять на его состояние. Это приведёт к нестабильному и неожиданному для наших коллег поведению системы. Кроме того, на результаты наших интеграционных тестов смогут влиять действия других отделов придётся тратить больше времени на расследование падений. Повысить стабильность и воспроизводимость тестов можно с помощью изоляции двух сред. Поэтому мы хотели использовать отдельные запущенные инстансы в своей тестовой среде. В качестве бонуса это даёт возможность использовать сервисы любой версии и конфигурации, быстрее проверять гипотезы и не согласовывать изменения с другими отделами.

3. Работать с этой инфраструктурой: остановить Kafka/Consul/свои сервисы, исключить их из сети или включить в сеть. Нужна большая вариативность.

4. Запускать на разных машинах, например на машинах разработчиков, QA-инженеров и CI.

5. Воспроизводить падения тестов. Если тестировщик увидел на своей машине, что тест не прошёл, разработчик должен с минимальными усилиями получить эту ошибку на своей машине. Мы хотели избежать различий в библиотеках и зависимостях на разных машинах (в том числе и на серверах для CI).

Мы решили использовать Docker и обернули сервисы в контейнеры: тесты будут создавать свою сеть (Docker network) для каждого прогона и включать контейнеры в неё. Это хорошая изоляция для тестов из коробки.

Запуск в контейнере

Во фреймворке мы запускаем сервис в контейнере с помощью модуля testcontainers-go, который по факту представляет собой прослойку между Docker и нашими тестами на Go.

Отправляем запрос в этот модуль с характеристикой нашего сервиса. Получаем структуру контейнера и полный спектр возможностей: запускать и останавливать контейнер, узнавать его статус, включать в сеть, исключать из сети и так далее. Вся эта реализация под капотом у testcontainers-go.

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

Рабочее окружение

Недостаточно просто поднять сервис в контейнере. Нужно подготовить для него тестовое окружение.

• Создаём иерархию каталогов на хосте.

• Копируем все необходимые данные для нашего сервиса (скрипты, файлы, снепшоты и т.д.) в соответствующие директории.

• Создаём дефолтный файл конфигурации и тоже помещаем его в эту иерархию.

• Монтируем корень этой иерархии на хосте в Docker-контейнер.

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

Конфигурация

Здесь мы использовали простое решение.

Через Entrypoint задаём переменные окружения, аргументы запуска и подготовленный файл конфигурации. Когда контейнер поднимется, он выполнит всё, что указано в Entrypoint.

После этого сервис можно считать сконфигурированным. Пример:

Адрес сервиса

Итак, сервис поднялся в контейнере. У него есть рабочее окружение и определённая конфигурация для теста. Как найти другие сервисы?

Внутри Docker network всё просто.

• При создании контейнера мы генерируем ему уникальное имя и к этому имени обращаемся как к адресу: используем имя контейнера как hostname.

• Порты мы знаем заранее, так как на предыдущем этапе подготавливали файлы конфигурации и указывали порты для наших сервисов.

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

Если тесты запускаются на локальной машине, они не могут обращаться к сервису по имени его контейнера, так как адресация по имени контейнера внутри Docker network это абстракция самого Docker. Нам нужно найти номер порта на локальном хосте, который соответствует порту сервиса в Docker network. После поднятия контейнера мы получим соответствие внутреннего порта сервиса (inner port) порту на локальном хосте (external port). Последний и будем использовать в тестах.

Внешние сервисы

Наверняка в вашей инфраструктуре присутствуют сторонние сервисы, например базы данных и service discovery. Их конфигурация в идеале должна совпадать с той, что на продакшене. Если сервис простой (например, Consul в конфигурации одного процесса) мы его тоже можем запустить с помощью testcontainers-go. Но если сервис многокомпонентный (например, Kafka из нескольких брокеров, где требуется ZooKeeper), то можно не страдать и использовать для этого Docker Compose.

Как правило, в процессе интеграционного тестирования не требуется обширный доступ к работе с внешними сервисами, так что Docker Compose хорошо подходит для наших целей.

Фаза загрузки

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

Что делать?

1. Самое простое решение использовать sleep. После запуска контейнера ждём некоторое время. Как только оно прошло, считаем, что сервисы готовы к работе. Это плохое решение, поскольку запуск тестов происходит на разных машинах, а скорость загрузки сервисов может изменяться как в большую, так и в меньшую сторону.

2. Открывать порты сервиса по мере готовности. Как только сервис прошёл фазу загрузки и готов принимать запросы клиентов, он открывает порты. Для тестового окружения это знак разрешения на запуск тестов. Однако есть нюанс: при создании контейнера Docker сразу открывает external port для сервиса, даже если последний ещё не начал слушать соответствующий internal port в контейнере. Поэтому в тестах сразу будет установлено соединение и попытка чтения из соединения приведёт к EOF. Когда сервис откроет internal port, тестовый фреймворк сможет отправить запрос. Только после этого мы будем считать, что сервис готов к работе.

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

4. Регистрировать в стороннем сервисе или базе данных. Мы регистрируем сервисы в Consul. Можно использовать:

   1. Факт появления сервиса в Consul как сигнал о готовности. Состояние сервиса можно отслеживать с помощью блокирующего запроса с тайм-аутом. Как только сервис зарегистрируется, Consul пришлет ответ на запрос с информацией об изменении статуса сервиса.

   2. Анализ состояния сервиса с помощью проверки его checka. Фреймворк для интеграционного тестирования получает информацию о новом сервисе из пункта 1 и начинает отслеживать изменения его статуса. Когда статусы всех сервисов будут passing, считаем, что они готовы к работе.

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

Во всех подходах время ожидания готовности сервиса ограничено максимально разрешённым временем запуска сервиса в любой среде.

Поднятие всех сервисов

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

В какой последовательности осуществлять запуск? Идеальный вариант не иметь строгой последовательности. Это позволяет запускать сервисы параллельно и значительно сократить время создания инфраструктуры (время запуска контейнера + время загрузки сервиса). Чем меньше связей, тем проще добавлять новый сервис в инфраструктуру.

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

Инфраструктура во время тестирования

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

Изменение конфигурации сервиса

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

Добавление нового сервиса

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

Работа с сетью

Включение контейнеров в сеть и их исключение из неё, приостановка (pause/unpause) работы контейнеров, iptables позволяют нам эмулировать сетевые ошибки и проверять реакцию системы на них.

Инфраструктура после тестирования

Если в рамках одного теста мы добавили новый сервис, не нужно передавать его по наследству следующему тесту: нужно быть вежливыми и убрать за собой. Это касается и данных. Тесты могут запускаться в произвольном порядке и не должны влиять друг на друга, прогоны должны быть воспроизводимыми.

• Если было изменение конфигурации сервиса, делаем откат на предыдущую (дефолтную) конфигурацию.

• Если было добавление нового сервиса, удаляем его.

• Если были любые изменения в сети (iptables, приостановка контейнеров и т. д.), отменяем их.

• Если были добавлены или изменены данные, запускаем очистку. Тут важно иметь механизм определения её завершения, чтобы обязательно его дождаться. Например, в случае очистки данных в стороннем сервисе базы данных недостаточно просто отправить запрос на удаление нужно удостовериться, что он отработан (а не застрял в очереди, в то время как мы уже новый тест запустили и он успел обратиться к данным, которые вот-вот будут удалены).

После завершения test suite работа всех сервисов в инфраструктуре тоже завершается, контейнеры убиваются, тестовая сеть опускается. Если test suite не успел завершиться по истечении тайм-аута или в результате ошибки, действуем точно так же. Только в случае явного указания фреймворку оставить контейнеры после прогона (например, для отладки), инфраструктура остаётся.

Ускорение тестов

Ждать вечность, пока пройдут интеграционные тесты, как правило, никому не хочется. Хотя в это время можно выпить кофе и сделать ещё много чего интересного.

Что мы можем сделать для ускорения тестов?

• Группировать read-only-тесты и запускать их параллельно в рамках одного теста (в Go при помощи горутин это делается максимально просто). Эти тесты должны работать на изолированном множестве данных.

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

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

• Запускать несколько тестовых инфраструктур параллельно (если позволяют ресурсы). По сути, это параллельный прогон test suite.

• Переиспользовать контейнеры.

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

В тестах мы запускаем мок на определённом адресе. Этот адрес уже поднятые сервисы в текущей инфраструктуре узнают через конфиг или service discovery (Consul в нашем случае) и могут отправлять на него запросы.

Мок получает запрос и вызывает handler, который мы указали. На Go в тесте это выглядит примерно так:

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

Контроль над действиями сервера, будь то завершение соединения или медленная отправка, даёт дополнительную возможность проверить реакцию тестируемых сервисов на сбои в работе сети. Сервер выполняет запрошенные действия, пакует ответ от handler и отправляет его клиенту. Мок (сервер) уничтожается в defer по окончании теста.

Мы используем моки для всех наших сервисов это помогает выиграть много времени при тестировании.

Реализация

Наш фреймворк располагается в том же репозитории, что и тестируемые сервисы, лежит в отдельной директории autotests. Внутри неё есть несколько модулей:

Service позволяет настроить всё необходимое для каждого сервиса, чтобы его запустить и остановить, сконфигурировать, получить информацию о его данных.

Mock содержит реализацию мока-сервера для каждого нестороннего сервиса.

В suite находится общая реализация. Он умеет работать с сервисами, ожидать их загрузки, проверять работоспособность и многое другое.Environment хранит информацию о текущем тестовом окружении (какие сервисы запущены), отвечает за сеть.

Также есть вспомогательные модули и те, что оказывают помощь в генерации данных.

Помимо модулей самого фреймворка, на момент написания статьи у нас были созданы 21 test suites, в том числе и smoke test suite. Каждый создаёт свою инфраструктуру с необходимым набором сервисов. Тесты находятся в файлах внутри test suite.

Запуск конкретного test suite выглядит примерно так:

go test -count=1 -race -v ./testsuite $(TESTSFLAGS) -autotests.timeout=15m

Поскольку сервисы коллег из других отделов мы хотели тоже перевести на наш фреймворк, core-функционал фреймворка был вынесен в общий core-репозиторий.

Отладка

Ура! Мы научились подготавливать инфраструктуру и прогонять тесты. Приятно видеть зелёный результат интеграции. Но так бывает не всегда, поэтому начинаем разбираться с падениями. Первое, что приходит на ум, изучить логи сервисов.

Предположим, suite содержит огромное количеством тестов, и один из них не получил от сервиса ожидаемого ответа. Где-то в недрах лога сервиса нам нужно найти кусочек, который соответствует времени прохождения упавшего теста. В этом помогает простой и удобный инструмент маркеры.

• Добавляем в сервис команду log_notice, при получении которой он записывает в свой лог сообщение из запроса.

• Перед началом теста отправляем log_notice с названием теста во все поднятые сервисы. По окончании теста делаем то же самое.

Теперь у нас есть маркеры внутри лога можно легко восстановить ход событий и воспроизвести поведение сервиса при необходимости.

Как быть, если сервис не смог подняться и не успел сделать запись в лог? Скорее всего, он записал в stderr/stdout дополнительную информацию. Команда docker logs позволяет получать данные из стандартных потоков ввода-вывода это поможет нам понять, что случилось.

А теперь предположим, что данных из логов не достаточно для локализации ошибки. Время обратиться к более серьёзным методам!

Указываем в конфигурации фреймворка необходимость оставлять инфраструктуру после прогона всех тестов в suite. Благодаря этому мы получаем полный доступ к системе. Можно узнать статус сервиса, получить данные из него, отправлять различные запросы, анализировать файлы сервиса на диске, а так же использовать gdb/strace/tcpdump и профилирование. Дальше мы строим гипотезу, пересобираем образ, запускаем тесты и итеративно находим корень проблемы.

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

QA

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

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

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

Чтобы ускорить работу, сначала наши разработчики пишут positive-тесты, а затем тестировщики проверяют более сложные кейсы. Совместная разработка тестов и фреймворка в действии.

CI

Оказалось, что встроить интеграционные тесты в CI очень просто. Мы используем TeamCity. Код фреймворка находится в репозитории с кодом сервисов. Сначала собираются сервисы, создаются образы, далее происходят сборка фреймворка и наконец его запуск.

Мы научили TeamCity понимать по выводу тестового фреймворка, какие тесты прошли, а какие нет. После окончания прогона отображается, сколько и каких тестов не прошло. Данные всех сервисов после прогона каждого suite сохраняются и публикуются в TeamCity в качестве артефактов для конкретной сборки и прогона.

Итоги

Ниже результаты проделанной работы.

• Жить стало спокойнее. Меньше проблем с интеграцией просачивается на продакшен. Как следствие более стабильный прод.

• Мы научились поднимать разную инфраструктуру и покрывать больше сценариев за меньшее время.

• Мы работаем с инфраструктурой во время прохождения тестов. Это даёт больше возможностей для реализации разных тест-кейсов.

• Мы ловим больше багов на этапе разработки. Positive-сценарии пишут сами разработчики, отлавливая часть ошибок и сразу их решая. Уменьшается round-trip бага.

• Мы избавили тестировщиков от написания positive-кейсов. QA-инженеры могут сосредоточиться на более сложных сценариях.

• Перестали блокироваться на этапе тестирования, когда параллельно разрабатываются задачи для разных сервисов и переводятся на QA-инженеров примерно в одно время.

• Мы написали MVP фреймворка для интеграционного тестирования довольно быстро за пару недель. Задача оказалась не слишком трудоёмкой.

• Мы используем фреймворк уже больше года.

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

Однако интеграционное тестирование имеет ряд минусов, которые стоит учитывать.

• Увеличение времени прогона тестов. Системы сложные, запросы выполняются в нескольких сервисах.

• Нестабильность, так как система состоит из асинхронных компонентов. С этим можно и нужно бороться. Мы тоже это делаем: доля нестабильных тестов у нас близка к нулю.

• Сложность написания тестов. Нужно понимать, как работает система в целом, каково её ожидаемое поведение и как её можно сломать.

• Возможность расхождения инфраструктуры в тестах и на продакшене. Если не все сервисы на проде в контейнерах, то тестовое окружение не на 100% совпадает с продакшеном. У нас как раз часть сервисов на проде не в контейнерах, но мы пока не сталкивались с проблемами из-за их тестирования в контейнерах.

И, наконец, главный вопрос, на который нужно ответить: необходим ли вам фреймворк для интеграционных тестов?

Если в вашем проекте увеличивается (или уже заметно увеличилось) количество сервисов, множатся связи между ними и требуется автоматизация тестирования, значит, стоит попробовать реализовать интеграционные тесты.

Надеюсь, что эта статья дала вам представление о тех задачах, которые предстоит решать на этом пути, и о методах их решения.

Успехов и удачи!

К 2020 году вы не могли не заметить, что миром правят данные. И, как только речь заходит о работе с ощутимыми объёмами, появляется необходимость в сложном многоэтапном конвейере обработки данных.

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

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

Я поделюсь несколькими простыми правилами, которые помогают нам в работе с преобразованием данных и, надеюсь, помогут и вам.

Правило наименьшего шага

Первое правило сформулировать легко: каждое отдельное взятое преобразование должно быть как можно проще и меньше.

Допустим, данные поступают на машину с POSIX-совместимой операционной системой. Каждая единица данных это JSON-объект, и эти объекты собираются в большие файлы-пакеты, содержащие по одному JSON-объекту на строку. Пускай каждый такой пакет весит около 10 Гб.

Над пакетом надо произвести три преобразования:

1. Проверить ключи и значения каждого объекта.

2. Применить к каждому объекту первую трансформацию (скажем, изменить схему объекта).

3. Применить вторую трансформацию (внести новые данные).

Совершенно естественно всё это делать с помощью единственного скрипта на Python:

python transform.py < /input/batch.json > /output/batch.json

Блок-схема такого конвейера не выглядит сложной:

Проверка объектов в transform.py занимает около 10% времени, первое преобразование 70%, на остальное уходит 20% времени.

Теперь представим, что ваш стартап вырос и вам уже приходится обрабатывать сотни, а то и тысячи пакетов. И тут вы обнаружили, что в финальный этап логики обработки данных (занимающий 20% времени) закралась ошибка, и вам нужно всё выполнить заново.

В такой ситуации рекомендуется собирать конвейеры из как можно более мелких этапов:

python validate.py < /input/batch.json > /tmp/validated.jsonpython transform1.py < /input/batch.json > /tmp/transformed1.jsonpython transform2.py < /input/transformed1.json > /output/batch.json

Блок-схема превращается в симпатичный паровозик:

Выгоды очевидны:

• конкретные преобразования проще понять;

• каждый этап можно протестировать отдельно;

• промежуточные результаты отлично кешируются;

• систему легко дополнить механизмами обработки ошибок;

• преобразования можно использовать и в других конвейерах.

Правило атомарности

К правилу наименьшего шага прилагается второе правило атомарности. Оно звучит так: каждый шаг-преобразование либо должен случиться, либо нет. Никаких промежуточных состояний данных быть не должно.

Давайте вернёмся к первому примеру. Есть входные данные, над которыми мы проводим преобразование:

python transform.py < /input/batch.json > /output/batch.json

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

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

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

В POSIX-совместимых файловых системах всегда есть атомарные операции (скажем, mv или ln), с помощью которых можно имитировать транзакции:

python transform.py < /input/batch.json > /output/batch.json.tmpmv /output/batch.json.tmp /output/batch.json

В этом примере испорченные промежуточные данные окажутся в файле *.tmp, который можно изучить позднее при проведении отладки или просто удалить.

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

Правило идемпотентности

В императивном программировании подпрограмма с побочными эффектами является идемпотентной, если состояние системы не меняется после одного или нескольких вызовов.

Википедия

Наше третье правило более тонкое: применение преобразования к одним и тем же данным один или несколько раз должно давать одинаковый результат.

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

python transform.py < /input/batch.json > /output/batch1.jsonpython transform.py < /input/batch.json > /output/batch2.jsondiff /input/batch1.json /output/batch2.json# файлы те жеpython transform.py < /input/batch.json > /output/batch3.jsondiff /input/batch2.json /output/batch3.json# никаких изменений

На входе у нас /input/batch.json, а на выходе /output/batch.json. И вне зависимости от того, сколько раз мы применим преобразование, мы должны получить одни и те же данные:

Так что если только transform.py не зависит от каких-то неявных входных данных, этап transform.py является идемпотентным (своего рода перезапускаемым).

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

Чем важна идемпотентность? В первую очередь это свойство упрощает обслуживание конвейера. Оно позволяет легко перезагружать подмножества данных после изменений в transform.py или входных данных в /input/batch.json. Информация будет идти по тем же маршрутам, попадёт в те же таблицы базы данных, окажется в тех же файлах и т. д.

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

Правило избыточности

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

Пример:

python transform1.py < /input/batch.json > /tmp/batch-1.jsonpython transform2.py < /tmp/batch-1.json > /tmp/batch-2.jsonpython transform3.py < /tmp/batch-2.json > /tmp/batch-3.jsoncp /tmp/batch-3.json /output/batch.json.tmp # не атомарно!mv /output/batch.json.tmp /output/batch.json # атомарно

Сохраняйте сырые (input/batch.json) и промежуточные (/tmp/batch-1.json, /tmp/batch-2.json, /tmp/batch-3.json) данные как можно дольше по меньшей мере до завершения цикла работы конвейера.

Вы скажете мне спасибо, когда аналитики решат поменять алгоритм вычисления какой-то метрики в transform3.py и вам придётся исправлять данные за несколько месяцев.

Другими словами: избыточность избыточных данных ваш лучший избыточный друг.

Заключение

Давайте подведём итоги:

• разбивайте конвейер на изолированные маленькие этапы;

• стремитесь делать этапы атомарными и идемпотентными;

• сохраняйте избыточность данных (в разумных пределах).

Так обрабатываем данные и мы в Badoo и Bumble: они приходят через сотни тщательно подготовленных этапов преобразований, 99% из которых атомарные, небольшие и идемпотентные. Мы можем позволить себе изрядную избыточность, поэтому держим данные в больших холодном и горячем хранилищах, а между отдельными ключевыми преобразованиями имеем и сверхгорячий промежуточный кеш.

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

А у вас есть свои правила обработки данных?

Файлы конфигурации (конфиги) неотъемлемая часть большинства приложений, но, как показывает практика, это не самая популярная тема для обсуждения. Чаще всего разговоры о конфигах ограничиваются обсуждением работы с ними непосредственно в коде: как их структурировать, использовать переменные окружения или нет, где хранить пароли и т. п.

На мой взгляд, есть и другая сторона работы с конфигами, которая заслуживает внимания, развёртывание (деплой). За свою карьеру я видел довольно много способов деплоя конфигов и уверен, что каждый может узнать об этом что-то новое.

Несколько лет назад я работал над системой, которая позволила нам ускорить процесс деплоя конфигов на 1000+ серверов с минуты до нескольких секунд.

Если вам интересно узнать, как устроен процесс деплоя конфигов в Badoo и какие инструменты мы для этого используем, добро пожаловать под кат.

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

Случай из жизни

За прошедшие годы в Badoo было написано более ста различных сервисов, и их количество продолжает расти. При этом у каждого сервиса может быть от двух-трёх до нескольких сотен инстансов, а значит, в нашем коде должна быть возможность оперативно убирать запросы с определённого инстанса. Ведь как гласит закон Мёрфи, если что-то может пойти не так, оно пойдёт не так.

Самый простой пример один из инстансов сервиса начал тупить, следовательно, нам нужно временно убрать с него трафик, чтобы избежать эффекта снежного кома (когда время выполнения запроса увеличивается, запросы начинают копиться в очереди, что также влияет на время выполнения запроса, и т. д.).

Другой пример плановые работы, например обновление сервиса. В этом случае мы заранее знаем, что сервис будет недоступен некоторое время и нет смысла отправлять запросы к нему.

Для отключения сервисов мы используем свою систему с говорящим названием Выключалка хостов (disable hosts). Принцип её работы довольно прост:

• выбираем в веб-интерфейсе сервисы, которые нужно отключить (или, наоборот, включить);

• нажимаем на кнопку Deploy;

• изменения сохраняются в базе данных и затем доставляются на все машины, на которых выполняется PHP-код.

В коде при подключении к сервису стоит проверка вида:

if (\DownChecker\Host::isDisabled($host)) {   $this->errcode = self::ERROR_CONNECT_FAILED;   return false;}

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

Процесс деплоя разбит на несколько шагов:

• упаковываем конфиги в tar-архив;

• копируем архив на сервер через rsync или scp;

• распаковываем архив в отдельную директорию;

• переключаем симлинк на новую директорию.

Особенность mcode в том, что она ждёт завершения выполнения текущего шага на каждом сервере, прежде чем перейти к следующему. С одной стороны, это даёт больше контроля на каждом этапе и гарантирует, что на 99% серверов изменения доедут примерно в один момент времени (псевдоатомарность). С другой проблемы с одним из серверов приводят к тому, что процесс деплоя зависает, ожидая завершения выполнения текущей команды по тайм-ауту. Если на каком-то сервере несколько раз подряд не удалось выполнить команду, то он временно исключается из раскладки. Это позволяет уменьшить влияние проблемных серверов на общую продолжительность деплоя.

Таким образом, mcode не даёт никаких гарантий высокой скорости доставки изменений. Можно лишь спрогнозировать её максимальную продолжительность, как сумму таймаутов всех шагов.

Теперь представим, что у нас начались проблемы с каким-либо сервисом. Мы добавили его в список отключённых хостов, но в процессе раскладки конфига один из серверов стал временно недоступен (например, возникли проблемы с сетью). Пока система ждёт завершения текущей команды по тайм-ауту, мы теряем драгоценное время.

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

В поисках альтернативного транспорта

Тут может возникнуть резонный вопрос: зачем изобретать велосипед, если можно использовать классическую схему с базой данных (БД) и кешированием?

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

• использование БД и кеша это дополнительная завязка на внешний сервис, а значит, ещё одна потенциальная точка отказа;

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

• ещё одним плюсом чтения из файла является то, что весь конфиг по сути является статическим массивом, а значит, после первого исполнения он осядет в OPCache, что даст небольшой прирост производительности.

Но схему с базой данных можно немного доработать, использовав вместо непосредственного чтения из первоисточника (базы данных) скрипт, который запускается на каждом сервере с заданной периодичностью (например, через cron), считывает нужные данные из базы данных и обновляет конфиг. Думаю, многие из вас использовали такой подход, например, для прогрева кеша.

Но в этой схеме нам не понравилась идея с запросами в цикле. У нас около 2000 серверов, на которых может выполняться PHP-код. Если мы будем делать запрос в базу/кеш хотя бы один раз в секунду, то это будет создавать довольно большой фон запросов (2k rps), а сами данные при этом обновляются не так часто. На этот случай есть решение событийная модель, например шаблон проектирования Publisher-Subscriber (PubSub). Из популярных решений можно было использовать Redis, но у нас он не прижился (для кеширования мы используем Memcache, а для очередей у нас есть своя отдельная система).

Зато прижился Consul, у которого есть механизм отслеживания изменений (watches) на базе блокирующих запросов. Это в целом похоже на PubSub и вписывается в нашу схему с обновлением конфига по событию. Мы решили сделать прототип нового транспорта на базе Consul, который со временем эволюционировал в отдельную систему под названием AutoConfig.

Как работает AutoConfig

Общая схема работы выглядит следующим образом:

• разработчик вызывает специальный метод, который обновляет значение ключа в базе данных и добавляет ключ в очередь на деплой;

• в облаке работает скрипт, который исключает пачку ключей из очереди и записывает их в Consul; помимо самих ключей, в Consul хранится специальная индексная карта со списком всех ключей (о ней я расскажу чуть позже);

• на каждом сервере запущен Consul watch, который отслеживает изменения индексной карты и вызывает специальный скрипт-обработчик, когда она обновляется;

• обработчик записывает изменения в файл.

Со стороны кода работа с системой выглядит довольно просто:

Обновление ключа

$record = \AutoConfig\AutoConfigRecord::initByKeyData('myKey', 'Hello, Habr!', 'Eugene Tupikov');$storage = new \AutoConfig\AutoConfigStorage();$storage->deployRecord($record);

Чтение ключа

$reader = new \AutoConfig\AutoConfigReader();$config = $reader->getFromCurrentSpace('myKey');

Удаление ключа

$storage = new \AutoConfig\AutoConfigStorage();$storage->removeKey('example');

Подробнее про Consul watch

Consul watch реализован с использованием блокирующих запросов в HTTP API, работу которых лучше продемонстрировать на примере отслеживания изменений ключа.

Первым делом необходимо создать новый ключ. Для этого открываем терминал и выполняем следующую команду

curl -X PUT --data 'hello, harb!' http://127.0.0.1:8500/v1/kv/habr-key

Затем отправляем запрос на чтение нашего ключа

curl -v http://127.0.0.1:8500/v1/kv/habr-key

API обрабатывает запрос и возвращает ответ, содержащий HTTP-заголовок X-Consul-Index с уникальным идентификатором, который соответствует текущему состоянию нашего ключа.

......< X-Consul-Index: 266834870< X-Consul-Knownleader: true......<[  {    "LockIndex": 0,    "Key": "habr-key",    "Flags": 0,    "Value": "dXBkYXRlZCAy",    "CreateIndex": 266833109,    "ModifyIndex": 266834870  }]

Мы отправляем новый запрос на чтение и дополнительно передаем значение из заголовка X-Consul-Index в параметре запроса index

curl http://127.0.0.1:8500/v1/kv/habr-key?index=266834870Ждем изменений ключа...

При виде параметра index API начинает ждать изменений нашего ключа и ждёт до тех пор, пока время ожидания не превысит заданного тайм-аута.

Затем открываем новую вкладку терминала и отправляем запрос на обновление ключа

curl -X PUT --data 'updated value' http://127.0.0.1:8500/v1/kv/habr-key

Возвращаемся на первую вкладку и видим, что запрос на чтение вернул обновленное значение (изменились ключи Value и ModifyIndex):

[  {    "LockIndex": 0,    "Key": "habr-key",    "Flags": 0,    "Value": "dXBkYXRlZA==",    "CreateIndex": 266833109,    "ModifyIndex": 266835734  }]

При вызове команды

consul watch -type=key -key=habr_key <handler>

Consul watch автоматически выполнит указанную выше последовательность запросов и вызовет обработчик в случае изменения значения ключа.

Зачем нужна индексная карта

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

consul watch -type=keyprefix -prefix=auto_config/ <handler>

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

По этому поводу на GitHub уже довольно давно открыт Issue и, судя по комментариям, лёд тронулся. Разработчики Consul начали работу над улучшением подсистемы блокирующих запросов, что должно решить описанную выше проблему.

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

Она имеет следующий формат:

return [    'value' => [        'version' => 437036,        'keys' => [            'my/awesome/key' => '80003ff43027c2cc5862385fdf608a45',            ...            ...        ],        'created_at' => 1612687434    ]]

В случае если карта обновилась, обработчик:

• считывает текущее состояние карты с диска;

• находит изменившиеся ключи (для этого и нужен хеш значения);

• вычитывает через HTTP API актуальные значения изменившихся ключей и обновляет нужные файлы на диске;

• сохраняет новую индексную карту на диск.

И ещё немного про Consul

Consul отличная система, но за годы её использования в качестве транспорта для AutoConfig мы обнаружили ряд ограничений, под которые пришлось адаптировать нашу систему.

Ограничение размера значения ключа (и не только)

Consul это распределённая система, и для достижения согласованности используется протокол Raft. Для стабильной работы протокола в Consul установлен максимальный размер значения одного ключа 512 Кб. Его можно изменить, воспользовавшись специальной опцией, но делать это крайне не рекомендуется, так как изменение может привести к непредсказуемому поведению всей системы.

Для атомарной записи изменённых ключей и индексной карты мы используем механизм транзакций. Аналогичное ограничение в 512 Кб установлено и на размер одной транзакции. А, помимо него, есть ограничение на количество операций в рамках одной транзакции 64.

Чтобы обойти эти ограничения, мы сделали следующее:

• разбили индексную карту на несколько частей (по 1000 ключей в каждой) и обновляем только части, содержащие изменённые ключи;

• ограничили максимальный размер одного ключа AutoConfig 450 Кб, чтобы оставить место для шардов индексной карты (значение выбрано опытным путём);

• доработали скрипт, обрабатывающий очередь на деплой таким образом, что он

  • сначала вычитывает N ключей из очереди и проверяет их суммарный размер;

  • если размер не превышает заданный предел, то деплоит все ключи разом, а в противном случае деплоит ключи по одному.

Отсутствие встроенной репликации

У Consul из коробки отсутствует репликация между дата-центрами. У нас их несколько, поэтому мы вынуждены записывать изменения в каждый дата-центр последовательно. Периодически возникают ситуации, когда в один дата-центр данные записались, а в другой нет, что приводит к неконсистентности. Если произошла временная ошибка, мы используем механизм повторного выполнения запросов (Retry), но это не решает проблему полностью.

Для исправления неконсистентности у нас есть отдельный скрипт. Он вычитывает актуальное состояние всех ключей из базы данных, сравнивает его с тем, что хранится в Consul, и актуализирует данные в случае их расхождения.

В качестве заключения

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

Если какой то сервер временно недоступен, система автоматически восстанавливает актуальное состояние конфига, как только он приходит в норму.

За последние пару лет система стала популярна у наших разработчиков и сегодня фактически является стандартом при работе с конфигами, для которых не требуется атомарная раскладка. Например, через AutoConfig у нас деплоятся параметры A/B-тестов, настройки промокампаний, на его базе реализован функционал Service Discovery и многое другое.

Общее количество ключей на данный момент порядка 16 000, а их суммарный размер примерно 120 Мб.

Спасибо за внимание!

Расскажите в комментариях, как вы деплоите конфиги в своих проектах.

Меня зовут Дмитрий Макаренко, я Mobile QA Engineer в Badoo и Bumble: занимаюсь тестированием новой функциональности в наших приложениях вручную и покрытием её автотестами.

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

В таких условиях нам очень важно разрабатывать тесты настолько быстро, насколько это возможно. И делать их при этом стабильными чтобы поддержка не отнимала у нас много времени. Мы решили поделиться практиками, которые помогают нам ускорять разработку тестов и повышать их стабильность.

В подготовке текста мне помогал мой коллега Виктор Короневич: с этой темой мы вместе выступали на конференции Heisenbug.

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

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

Практика 4. Верификация изменения состояния элементов

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

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

Таким образом, прежде чем начать проверять элементы, нам необходимо дождаться их появления на экране. Естественно, эта проблема не нова и существуют стандартные решения. Например, в Selenium это различные типы методов wait, а в Calabash метод wait_for.

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

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

После того как мы добавили логи и проанализировали их, оказалось, что эти зависания были связаны с реализацией метода wait_for, входящего в состав фреймворка Calabash. wait_for использует метод timeout модуля Ruby Timeout, который реализован на глобальном потоке. А тесты зависали, когда этот метод timeout использовался вложено в других методах: наших и фреймворка Calabash.

Например, рассмотрим прокрутку страницы профиля до кнопки блокировки пользователя.

def scroll_to_block_button  wait_for(timeout: 30) do    ui.scroll_down    ui.wait_until_no_animation    ui.element_displayed?(BLOCK_BUTTON)  endend

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

Рассмотрим реализацию метода wait_until_no_animation.

def wait_until_no_animation  wait_for(timeout: 10) do    !ui.any_element_animating?  endend

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

Сначала мы создали модуль Poll с одним методом for, который повторял стандартный метод wait_for. Со временем собственная реализация позволила нам расширять функциональность модуля по мере того, как у нас появлялась такая необходимость. Мы добавили методы, ожидающие конкретные значения заданных условий. Например, Poll.for_true и Poll.for_false явно ожидают, что исполняемый код вернёт true либо false. В примерах ниже я покажу использование разных методов из модуля Poll.

Также мы добавили разные параметры методов. Рассмотрим подробнее параметр return_on_timeout. Его суть в том, что при использовании этого параметра наш метод Poll.for перестаёт выбрасывать ошибку, даже если заданное условие не выполняется, а просто возвращает результат выполнения проверки.

Предвижу вопросы Как это работает? и Зачем это нужно?. Начнём с первого. Если в методе Poll.for мы будем ждать, пока 2 станет больше, чем 3, то мы всегда будем получать ошибку по тайм-ауту.

Poll.for { 2 > 3 }> WaitError

Но если мы добавим наш параметр return_on_timeout и всё так же будем ждать, пока 2 станет больше, чем 3, то после окончания тайм-аута, 2 всё ещё не станет больше, чем 3, но наш тест не упадёт, а метод Poll.for вернёт результат этой проверки.

Poll.for(return_on_timeout: true) { 2 > 3 }> false

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

Варианты изменения состояния элементов

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

Он умеет всего две вещи: появляться на экране и пропадать с экрана.

Первый вариант изменения состояния называется Должен появиться. Он происходит в том случае, когда состояние 1 на экране нет нашего объекта тестирования, а состояние 2 он должен появиться.

Если он появляется, то проверка проходит успешно.

Второй вариант изменения состояния называется Должен пропасть. Происходит он тогда, когда в состоянии 1 отображается наш объект тестирования, а в состоянии 2 его быть не должно.

Третий вариант не такой очевидный, как первые два, потому что в нём, по сути, мы проверяем неизменность состояния. Называется он Не должен появиться. Это происходит, когда в состоянии 1 наш объект тестирования не отображается на экране и спустя какое-то время в состоянии 2 он всё ещё не должен появиться.

Вы, наверное, догадались, какой вариант четвёртый. Он называется Не должен пропасть. Происходит это, когда в состоянии 1 объект отображается на экране, и спустя какое-то время в состоянии 2 он всё ещё находится там.

Реализация проверок разных вариантов

Мы зафиксировали все возможные варианты изменения состояния элементов. Как же их проверить? Разобьём реализацию на проверки первых двух вариантов и проверки третьего и четвёртого.

В случае с первыми двумя вариантами всё довольно просто. Для проверки первого нам просто нужно подождать, пока элемент появится, используя наш метод Poll:

# вариант "Должен появиться"Poll.for_true { ui.elements_displayed?(locator) }

Для проверки второго подождать, пока элемент пропадёт:

# вариант "Должен пропасть"Poll.for_false { ui.elements_displayed?(locator) }

Но в случае с третьим и четвёртым вариантами всё не так просто.

Рассмотрим вариант Не должен появиться:

# вариант "Не должен появиться"ui.wait_for_elements_not_displayed(locator)actual_state = Poll.for(return_on_timeout: true) { ui.elements_displayed?(locator) }Assertions.assert_false(actual_state, "Element #{locator} should not appear")

Здесь мы, во-первых, фиксируем состояние отсутствия элемента на экране.

Далее, используя Poll.for с параметром return_on_timeout, мы ждём появления элемента. При этом метод Poll.for не выбросит ошибку, а вернёт false, если элемент не появится. Значение, полученное из Poll.for, сохраняется в переменной actual_state.

После этого происходит проверка неизменности состояния элемента с использованием метода assert.

Для проверки варианта Не должен пропасть мы используем похожую логику, ожидая пропажи элемента с экрана вместо его появления:

# вариант "Не должен пропасть"ui.wait_for_elements_displayed(locator)actual_state = Poll.for(return_on_timeout: true) { !ui.elements_displayed?(locator) }Assertions.assert_false(actual_state, "Element #{locator} should not disappear")

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

def verify_dynamic_state(state:, timeout: 10, error_message:)  options = {    return_on_timeout: true,    timeout:           timeout,  }  case state    when 'should appear'      actual_state = Poll.for(options) { yield }      Assertions.assert_true(actual_state, error_message)    when 'should disappear'      actual_state = Poll.for(options) { !yield }      Assertions.assert_true(actual_state, error_message)    when 'should not appear'      actual_state = Poll.for(options) { yield }      Assertions.assert_false(actual_state, error_message)    when 'should not disappear'      actual_state = Poll.for(options) { !yield }      Assertions.assert_false(actual_state, error_message)    else      raise("Undefined state: #{state}")  endend

yield это код блока, переданного в данный метод. На примерах выше это был метод elements_displayed?. Но это может быть любой другой метод, результат выполнения которого отражает состояние необходимого нам элемента. Документация Ruby.

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

Выводы:

• важно не забывать про все четыре варианта изменения состояния при проверках UI-элементов;

• полезно вынести эти проверки в общий метод.

Мы рекомендуем использовать полную систему проверок всех вариантов изменения состояния. Что мы имеем в виду? Представьте, что когда элемент есть это состояние true, а когда его нет false.

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

Практика 5. Надёжная настройка предусловий тестов

Как можно догадаться из заголовка, задача этого раздела разобраться, как настраивать предусловия перед началом выполнения теста.

Рассмотрим два примера. Первый отключение сервиса локации на iOS в настройках. Второй создание истории чата.

В первом примере реализация метода отключения сервиса локации на iOS выглядит следующим образом:

def switch_off_location_service  ui.wait_for_elements_displayed(SWITCH)  if ui.element_value(SWITCH) == ON    ui.tap_element(SWITCH)    ui.tap_element(TURN_OFF)  endend

Мы ждём, пока переключатель (элемент switch) появится на экране. Потом проверяем его состояние. Если оно не соответствует ожидаемому, мы его изменяем.

После этого мы закрываем настройки и запускаем приложение. И иногда внезапно сталкиваемся с проблемой: почему-то сервис локации остаётся включённым. Как это получается? Мы же сделали всё, чтобы его отключить. Кажется, что это проблема работы системных настроек в iOS системе. При быстром выходе из настроек (а тест делает это моментально после нажатия на переключатель) их новое состояние не сохраняется. Но проблемы могут возникнуть и при настройке предусловий в нашем приложении.

Давайте обратимся ко второму примеру созданию истории чата перед началом выполнения теста. Реализация метода выглядит следующим образом:

def send_message(from:, to:, message:, count:)  count.times do    QaApi.chat_send_message(user_id: from, contact_user_id: to, message: message)  endend

Мы используем QAAPI для отправки сообщений по user_id. В цикле мы отправляем необходимое количество сообщений.

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

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

Как же решить эту проблему? Мы можем добавить гарантию выполнения действия в методы установки предусловий.

Тогда наш метод отключения сервиса локации будет выглядеть следующим образом:

def ensure_location_services_switch_in_state_off  ui.wait_for_elements_displayed(SWITCH)  if ui.element_value(SWITCH) == ON    ui.tap_element(SWITCH)    ui.tap_element(TURN_OFF)    Poll.for(timeout_message: 'Location Services should be disabled') do      ui.element_value(SWITCH) == OFF    end  endend

Используя метод Poll.for, мы убеждаемся, что состояние переключателя изменилось, прежде чем переходить к следующим действиям теста. Это позволяет избежать проблем, вызванных тем, что сервис локации время от времени был включён.

Во втором примере нам снова помогут наши методы QAAPI.

def send_message(from:, to:, message:, count:)  actual_messages_count = QaApi.received_messages_count(to, from)  expected_messages_count = actual_messages_count + count  count.times do    QaApi.chat_send_message(user_id: from, contact_user_id: to, message: message)  end  QaApi.wait_for_user_received_messages(from, to, expected_messages_count)end

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

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

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

Более подробно о проблемах, описанных в этом разделе, можно прочитать в статье Мартина Фаулера.

Практика 6. Простые и сложные действия, или Независимость шагов в тестах

Простые действия

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

Начнём с теста поиска и отправки GIF-сообщений.

Сначала нам нужно открыть чат с пользователем, которому мы хотим отправить сообщение:

When  primary_user opens Chat with chat_user

Потом открыть поле ввода GIF-сообщений:

And   primary_user switches to GIF input source

Далее нам нужно ввести поисковый запрос для GIF-изображений, убедиться, что список обновился, отправить понравившееся изображение из списка и убедиться, что оно было отправлено.

And   primary_user searches for "bee" GIFsAnd   primary_user sends 7th GIF in the listThen  primary_user verifies that the selected GIF has been sent

Целиком сценарий выглядит так:

Scenario: Searching and sending GIF in Chat  Given users with following parameters    | role         | name |    | primary_user | Dima |    | chat_user    | Lera |  And   primary_user logs in  When  primary_user opens Chat with chat_user  And   primary_user switches to GIF input source  And   primary_user searches for "bee" GIFs  And   primary_user sends 7th GIF in the list  Then  primary_user verifies that the selected GIF has been sent

Обратим внимание на шаг, который отвечает за поиск гифки:

And(/^primary_user searches for "(.+)" GIFs$/) do |keyword|  chat_page = Pages::ChatPage.new.await  TestData.gif_list = chat_page.gif_list  chat_page.search_for_gifs(keyword)  Poll.for_true(timeout_message: 'Gif list is not updated') do    (TestData.gif_list & chat_page.gif_list).empty?  endend

Здесь, как и почти во всех остальных шагах, мы делаем следующее:

1. сначала ожидаем открытия нужной страницы (ChatPage);

2. потом сохраняем список всех доступных GIF-изображений;

3. далее вводим ключевое слово для поиска;

4. затем ждём изменения состояния обновления списка (ведь мы говорили о том, что полезно добавлять в тесты проверку выполнения действий).

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

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

Как же нам этого избежать? Как вы, возможно, заметили, наш шаг поиска GIF-изображений на самом деле включал в себя три действия:

1. сохранение текущего списка;

2. поиск;

3. проверку обновления списка.

Решением проблемы переиспользования будет разделение этого шага на три простых и независимых.

Первый шаг сохраняет текущий список изображений:

And(/^primary_user stores the current list of GIFs$/) do  TestData.gif_list = Pages::ChatPage.new.await.gif_listend

Второй шаг поиск гифки позволяет напечатать ключевое слово для поиска:

And(/^primary_user searches for "(.+)" GIFs$/) do |keyword|  Pages::ChatPage.new.await.search_for_gifs(keyword)end

На третьем шаге мы ждём обновления списка:

And(/^primary_user verifies that list of GIFs is updated$/) do  chat_page = Pages::ChatPage.new.await  Poll.for_true(timeout_message: 'Gif list is not updated') do    (TestData.gif_list & chat_page.gif_list).empty?  endend

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

Scenario: Searching and sending GIF in Chat  Given users with following parameters    | role         | name |    | primary_user | Dima |    | chat_user    | Lera |  And   primary_user logs in  When  primary_user opens Chat with chat_user  And   primary_user switches to GIF input source  And   primary_user stores the current list of GIFs  And   primary_user searches for "bee" GIFs  Then  primary_user verifies that list of GIFs is updated  When  primary_user sends 7th GIF in the list  Then  primary_user verifies that the selected GIF has been sent

Таким образом, мы можем использовать первые два шага даже в том случае, если в тесте список не обновляется. Это помогает нам экономить время на разработку, так как мы можем переиспользовать простые шаги в разных тестах.

Но и здесь есть нюансы. Шаги не всегда можно сделать простыми и независимыми. В таких случаях мы будем называть их сложными.

Сложные действия

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

Мини-игра это экран, на котором пользователю предлагаются профили других людей, которые ему написали. Можно либо отвечать на сообщения, либо пропускать этих пользователей. Действие пропуска назовём Голосовать нет.

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

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

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

When(/^primary_user votes No in Messenger mini game (\d+) times$/) do |count|  page = Pages::MessengerMiniGamePage.new.await  count.to_i.times do    page.vote_no  endend

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

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

When(/^primary_user votes No in Messenger mini game (\d+) times$/) do |count|  page = Pages::MessengerMiniGamePage.new.await  count.to_i.times do    progress_before = page.progress    page.vote_no    Poll.for_true do      page.progress > progress_before       end  endend

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

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

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

Практика 7. Верификация необязательных элементов

Под необязательными элементами мы понимаем такие элементы, которые могут либо отображаться, либо не отображаться на одном и том же экране в зависимости от каких-либо условий. Здесь мы рассмотрим пример диалогов о подтверждении действий пользователя, или алёртов (alerts).

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

Проанализируем скриншоты выше.

• Скриншот 1: заголовок, описание и две кнопки.

• Скриншот 2: заголовок, описание и одна кнопка.

• Скриншот 3: описание и две кнопки.

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

Начнём с того, как выглядит вызов метода для верификации каждого из диалогов:

class ClearAccountAlert < AppAlertAndroid  def verify_alert_lexemes    verify_alert(title:        ClearAccount::TITLE,                 description:  ClearAccount::MESSAGE,                 first_button: ClearAccount::OK_BUTTON,                 last_button:  ClearAccount::CANCEL_BUTTON)  endend

class WaitForReplyAlert < AppAlertAndroid  def verify_alert_lexemes    verify_alert(title:        WaitForReply::TITLE,                 description:  WaitForReply::MESSAGE,                 first_button: WaitForReply::CLOSE_BUTTON)  endend

class SpecialOffersAlert < AppAlertAndroid  def verify_alert_lexemes    verify_alert(description:  SpecialOffers::MESSAGE,                 first_button: SpecialOffers::SURE_BUTTON,                 last_button:  SpecialOffers::NO_THANKS_BUTTON)  endend

Во всех примерах мы вызываем метод verify_alert, передавая ему лексемы для проверки необходимых элементов. При этом, как вы можете заметить, WaitForReplyAlert мы не передаём лексему для второй кнопки, так как её не должно быть, а SpecialOffersAlert лексему для заголовка.

Рассмотрим реализацию метода verify_alert:

def verify_alert(title: nil, description:, first_button:, last_button: nil)  ui.wait_for_elements_displayed([MESSAGE, FIRST_ALERT_BUTTON])  ui.wait_for_element_text(expected_lexeme: title, locator: ALERT_TITLE) if title  ui.wait_for_element_text(expected_lexeme: description, locator: MESSAGE)  ui.wait_for_element_text(expected_lexeme: first_button, locator: FIRST_ALERT_BUTTON) ui.wait_for_element_text(expected_lexeme: last_button, locator: LAST_ALERT_BUTTON) if last_buttonend

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

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

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

Для этого в тестах мы меняем проверку

ui.wait_for_element_text(expected_lexeme: title, locator: ALERT_TITLE) if title

на

if title.nil?  Assertions.assert_false(ui.elements_displayed?(ALERT_TITLE), "Alert title should not be displayed")else  ui.wait_for_element_text(expected_lexeme: title, locator: ALERT_TITLE)end

Мы изменили условие if и добавили проверку второго состояния. Если мы не передаём лексему для необязательного элемента, значит, этого элемента не должно быть на экране, что мы и проверяем. Если же в title есть какой-то текст, мы понимаем, что элемент с этим текстом должен быть, и проверяем его. Мы решили выделить эту логику в общий метод, который назвали wait_for_optional_element_text. Этот метод мы можем применять не только для диалогов из этого примера, но и для любых других экранов приложения, на которых есть необязательные элементы. Видим, что if-условие из примера выше полностью находится внутри нового метода:

def wait_for_optional_element_text(expected_lexeme:, locator:)  GuardChecks.not_nil(locator, 'Locator should be specified')  if expected_lexeme.nil?    Assertions.assert_false(elements_displayed?(locator), "Element with locator #{locator} should not be displayed")  else    wait_for_element_text(expected_lexeme: expected_lexeme, locator: locator)  endend

Реализация метода verify_alert тоже изменилась:

def verify_alert(title: nil, description:, first_button:, last_button: nil)  ui.wait_for_elements_displayed([MESSAGE, FIRST_ALERT_BUTTON])  ui.wait_for_optional_element_text(expected_lexeme: title, locator: ALERT_TITLE)  ui.wait_for_element_text(expected_lexeme: description, locator: MESSAGE)  ui.wait_for_element_text(expected_lexeme: first_button, locator: FIRST_ALERT_BUTTON)  ui.wait_for_optional_element_text(expected_lexeme: last_button, locator: LAST_ALERT_BUTTON)end

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

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

Резюме: мы советуем использовать полную систему проверок всех состояний нужных элементов, а также выделять общие методы для однотипных действий.

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

Общие рекомендации

Выделим основные рекомендации по автоматизации тестирования мобильных приложений из семи практик, которые мы описали:

• так как проверки это то, ради чего мы пишем тесты, всегда используйте полную систему проверок;

• не забывайте добавлять проверку предустановки для асинхронных действий;

• выделяйте общие методы для переиспользования однотипного кода как в шагах, так и в методах на страницах;

• делайте объект тестирования простым;

• выделяйте независимые методы для простых действий в тестах.

Возможно, эти советы кому-то покажутся очевидными. Но мы хотим обратить ваше внимание на то, что применять их можно (и нужно) в разных ситуациях. Если вы хотите дополнить список другими полезными рекомендациями, добро пожаловать в комментарии!

Бонус

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

Mobile Automation Sample Project

В этом году должен выйти PHPUnit 10 (релиз планировался на 2 апреля 2021 года, но был отложен). Если посмотреть на список изменений, то бросается в глаза большое количество удалений устаревшего кода. Одним из таких изменений является удаление метода MockBuilder::setMethods(), который активно использовался при работе с частичными моками. Этот метод не рекомендуется использовать с версии 8.0, но тем не менее он описан в документации без каких-либо альтернатив и упоминания о его нежелательности. Если почитать исходники PHPUnit, issues и пул-реквесты на GitHub, то станет понятно, почему так и какие есть альтернативы.

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

Что такое частичные моки?

У программного кода, который мы пишем, чаще всего есть какие-то зависимости.

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

Суть мока заключается в том, что вместо объекта-зависимости вы используете специальный объект, в котором заменены все методы оригинального класса. Для такого объекта можно сконфигурировать результаты, возвращаемые методами, а также добавить проверки на наличие вызовов методов.

PHPUnit содержит встроенный механизм для работы с моками. Одной из его возможностей является создание так называемых частичных моков (partial mocks), когда исходное поведение класса заменяется не полностью, а только для отдельных методов. Такие моки очень удобно использовать, когда вам нужно написать тест, который будет проверять работу конкретного метода и в процессе своей работы вызывать другие методы (которые вы проверять не хотите).

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

Вот код базового класса, реализующий паттерн команда:

abstract class AbstractCommand{    /**     * @throws \PhpUnitMockDemo\CommandException     * @return void     */    abstract protected function execute(): void;    public function run(): bool    {        $success = true;        try {            $this->execute();        } catch (\Exception $e) {            $success = false;            $this->logException($e);        }        return $success;    }    protected function logException(\Exception $e)    {        // Logging    }} 

Реальное поведение команды задаётся в методе execute классов-наследников, а метод run() добавляет общее для всех команд поведение (в данном случае делает код exception safe и логирует ошибки).

Если мы хотим написать тест для метода run, мы можем воспользоваться частичными моками, функционал которых предоставляет класс PHPUnit\Framework\MockObject\MockBuilder, доступ к которому предоставляется через вспомогательные методы класса TestCase (в примере это getMockBuilder и createPartialMock):

use PHPUnit\Framework\TestCase;class AbstractCommandTest extends TestCase{    public function testRunOnSuccess()    {        // Arrange        $command = $this->getMockBuilder(AbstractCommand::class)            ->setMethods(['execute', 'logException'])            ->getMock();        $command->expects($this->once())->method('execute');        $command->expects($this->never())->method('logException');        // Act        $result = $command->run();        // Assert        $this->assertTrue($result, "True result is expected in the success case");    }    public function testRunOnFailure()    {        // Arrange        $runException = new CommandException();        // It's an analogue of $this->getMockBuilder(...)->setMethods([...])->getMock()        $command = $this->createPartialMock(AbstractCommand::class, ['execute', 'logException']);        $command->expects($this->once())            ->method('execute')            ->will($this->throwException($runException));        $command->expects($this->once())            ->method('logException')            ->with($runException);        // Act        $result = $command->run();        // Assert        $this->assertFalse($result, "False result is expected in the failure case");    }} 

Исходный код, результаты прогона тестов

В методе testRunOnSuccess с помощью MockBuilder::setMethods() мы задаём список методов оригинального класса, которые мы заменяем (вызовы которых хотим проверить или результаты которых нужно зафиксировать). Все остальные методы сохраняют свою реализацию из оригинального класса AbstractCommand (и их логику можно тестировать). В testRunOnFailure через метод createPartialMock мы делаем то же самое, но явно.

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

• подготовка или освобождение каких-то ресурсов (например, соединения с базой данных);

• внешние обращения, которые замедляют тесты и загрязняют окружение (отправка запросов к базе данных, чтение из кеша или запись в него и т. д.);

• отправка какой-то отладочной информации или статистики.

Часто для таких случаев проверок вызова просто нет (поскольку они не всегда нужны и делают тесты хрупкими при изменениях кода).

Кроме переопределения существующих методов, MockBulder::setMethods() позволяет добавлять в класс мока новые методы, которых нет в оригинальном классе. Это может быть полезно при использовании в тестируемом коде магического метода __call.

Возьмём в качестве примера класс \Predis\Client. Он использует метод __call для обработки передаваемых клиенту команд. При этом во внешнем коде это выглядит как вызов конкретного метода и кажется естественным переопределить в создаваемом моке этот вызываемый в коде метод, а не переопределять __call, вдаваясь в детали реализации.

Пример:

   public function testRedisHandle()    {        if (!class_exists('Redis')) {            $this->markTestSkipped('The redis ext is required to run this test');        }        $redis = $this->createPartialMock('Redis', ['rPush']);        // Redis uses rPush        $redis->expects($this->once())            ->method('rPush')            ->with('key', 'test');        $record = $this->getRecord(Logger::WARNING, 'test', ['data' => new \stdClass, 'foo' => 34]);        $handler = new RedisHandler($redis, 'key');        $handler->setFormatter(new LineFormatter("%message%"));        $handler->handle($record);    } 

Источник: тест RedisHandlerTest из monolog 2.2.0

Какие проблемы возникают при использовании setMethods?

Двойственное поведение может приводить к проблемам.

Если в моках есть переопределённые методы без expectations, то при их переименовании или удалении тест продолжает проходить (хотя метода уже нет и в его добавлении к моку нет смысла).

Небольшая демонстрация. Давайте добавим в код нашего класса команды измерение времени, которое потребовалось для её выполнения:

--- a/src/AbstractCommand.php+++ b/src/AbstractCommand.php@@ -13,6 +13,7 @@ abstract class AbstractCommand     public function run(): bool     {+        $this->timerStart();         $success = true;         try {             $this->execute();@@ -21,6 +22,7 @@ abstract class AbstractCommand             $this->logException($e);         }+        $this->timerStop();         return $success;     }@@ -28,4 +30,14 @@ abstract class AbstractCommand     {         // Logging     }++    protected function timerStart()+    {+        // Timer implementation+    }++    protected function timerStop()+    {+        // Timer implementation+    } } 

Исходный код

В код тестов добавим в мок новые методы, но не будем проверять вызовы через expectations:

--- a/tests/AbstractCommandTest.php+++ b/tests/AbstractCommandTest.php@@ -11,7 +11,7 @@ class AbstractCommandTest extends TestCase     {         // Arrange         $command = $this->getMockBuilder(AbstractCommand::class)-            ->setMethods(['execute', 'logException'])+            ->setMethods(['execute', 'logException', 'timerStart', 'timerStopt']) // timerStopt is a typo             ->getMock();         $command->expects($this->once())->method('execute');         $command->expects($this->never())->method('logException');

Исходный код, результаты прогона тестов

Если прогнать этот тест в PHPUnit версий 8.5 или 9.5, то он успешно пройдёт без каких-то предупреждений:

PHPUnit 9.5.0 by Sebastian Bergmann and contributors..                                                                   1 / 1 (100%)Time: 00:00.233, Memory: 6.00 MBOK (1 test, 2 assertions) 

Конечно, это совсем простой пример, в который несложно добавить expectations для новых методов. В реальном коде всё может быть сложнее, и мне не раз приходилось натыкаться на несуществующие методы в моках.

Ещё сложнее отслеживать подобные проблемы при использовании MockBuilder::setMethodsExcept, который переопределяет все методы класса, кроме заданных.

Как эта проблема решена в PHPUnit 10?

Начало решению этой проблемы молчаливого переопределения несуществующих методов было положено в 2019 году в пул-реквесте #3687, который вошёл в релиз PHPUnit 8.

В MockBuilder появились два новых метода onlyMethods() и addMethods() которые делят ответственность setMethods() на части. onlyMethods() может только заменять методы, существующие в оригинальном классе, а addMethods() только добавлять новые (которых в оригинальном классе нет).

В том же PHPUnit 8 setMethods был помечен устаревшим и появилось предупреждение при передаче несуществующих методов в TestCase::createPartialMock().

Если взять предыдущий пример с некорректным названием метода и использовать createPartialMock вместо вызовов getMockBuilder(...)->setMethods(...), то тест пройдёт, но появится предупреждение о будущем изменении этого поведения:

createPartialMock() called with method(s) timerStopt that do not existin PhpUnitMockDemo\AbstractCommand. This will not be allowed in future versions of PHPUnit.

К сожалению, это изменение никак не было отражено в документации там по по-прежнему была описана только работа setMethods(), а всё остальное было скрыто в недрах кода и GitHub.

В PHPUnit 10 проблема setMethods() решена радикально: setMethods и setMethodsExcept окончательно удалены. Это означает, что если вы используете их в своих тестах и хотите перейти на новую версию PHPUnit, то вам нужно убрать все использования этих методов и заменить их на onlyMethods и addMethods.

Как мигрировать частичные моки из старых тестов на PHPUnit 10?

В этой части я дам несколько советов о том, как это можно сделать.

Сразу скажу, что для использования этих советов не обязательно ждать выхода PHPUnit 10 и переходить на него. Всё это можно делать в процессе работы с тестами, которые запускаются в PHPUnit 8 или 9.

Везде, где возможно, замените вызовы MockBuilder::setMethods() на onlyMethods()

Это кажется совсем очевидным, но во многих случаях этого будет достаточно. Я рекомендую заменить все вхождения и разбираться с падениями. Частично они могут быть вызваны проблемами, описанными выше (и тогда нужно либо удалить метод из мока, либо использовать его актуальное название), а частично использованием магии в мокаемом классе.

Используйте MockBuilder::addMethods() для классов с магией

Если метод, который вы хотите переопределить в моке, работает через магический метод __call, то используйте MockBuilder::addMethods().

Если раньше для классов с магией вы использовали TestCase::createPartialMock() и это работало, то в PHPUnit 10 это сломается. Теперь createPartialMock умеет заменять только существующие методы мокаемого класса, и нужно заменить использование createPartialMock на getMockBuilder()->addMethods().

Если вы создаёте моки для внешних библиотек, то изучите их изменения или максимально конкретно задавайте версию

В тестах, использующих моки классов из внешних библиотек, всё может быть сложнее из-за того, что там может меняться версия зависимости. Особенно актуально это, если в CI вы используете lowest версии зависимостей вместе со стабильными.

Приведу пример из библиотеки PhpAmqpLib.

Допустим, вам нужен мок для класса \PhpAmqpLib\Channel\AMQPChannel.

В версии 2.4 там был метод __destruct, который отправлял внешний запрос (и поэтому его стоит замокать).

В версии 2.5 этот метод был удалён и мокать его уже не нужно.

Если в composer.json зависимость прописана подобным образом: "php-amqplib/php-amqplib": "~2.4", то обе версии буду подходить (но моки для них нужны разные) и нужно будет смотреть, какая из них используется.

Решать это можно несколькими способами:

• максимально фиксировать версию библиотеки (например, в приведённом примере можно использовать ~2.4.0 и тогда разница будет только в patch-версиях);

• завязываться на версию библиотеки или наличие метода (но это плохой способ, так как для этого нужно внимательно изучать изменения кода всех используемых библиотек, да и очень похоже это на какой-то хак);

• использовать для классов из внешних библиотек полные моки, а не частичные (но это не всегда возможно).

Заключение

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

См. также

• Раздел Тестовые двойники документации PHPUnit

• Pull request "Add onlyMethods + addMethods and soft deprecate setMethods"

• Pull request "Remove MockBuilder::setMethods() and MockBuilder::setMethodsExcept()"

• Глава Unit-тестирование книги Архитектура сложных веб-приложений. С примерами на Laravel

Меня зовут Владислав Романенко, я старший iOS QA Engineer в Badoo и Bumble. Несколько лет назад мы начали активнее использовать автотесты в разработке, но столкнулись с некоторыми трудностями.

Логичный вопрос: почему мы занялись автоматизацией тестирования? Ответ кроется в еженедельном выпуске новых версий наших мобильных приложений. QA-отделу приходится тестировать новые фичи, их интеграцию в сервисы и заниматься регрессионным тестированием. За неделю комплексное регрессионное тестирование нужно проводить как минимум один раз, что довольно утомительно. Автоматизация помогла нам выпускать новые версии быстрее и без потери качества. Подробнее об автоматизации мобильного тестирования в докладе моих коллег.

В разработке проблемы часто решаются с помощью паттернов обобщённых решений для часто возникающих проблем в заданном контексте. То же и с автоматизацией тестирования, есть даже хорошее wiki-описание. В этой статье мы поговорим о паттернах процессов (Process Patterns). Они помогают организовать и улучшить процесс автоматизации тестирования.

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

Паттерн 1. Просьба о помощи (Ask for Help)

Как это часто бывает, мы все имели разный опыт, знания и навыки. На тот момент не все в команде сталкивались с автоматизацией тестирования некоторым пришлось учиться на ходу. Чтобы помочь коллегам из команды QA справиться со сложностями, мы предложили им обратиться за помощью к команде автоматизации. Идея в том, что если ты застреваешь на какой-то проблеме, то не нужно самостоятельно бороться с ней слишком долго, ведь другие уже могли столкнуться с подобным и найти решение. А чтобы автоматизаторов не завалили вопросами, мы решили формализовать этот подход. Прекрасным решением оказался паттерн ASK FOR HELP:

Просите о помощи, а не теряйте время, пытаясь всё сделать самостоятельно.

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

Но оказалось, что простое следование паттерну может привести к новым проблемам. Команде автоматизации тестирования стали задавать вопросы ещё чаще, чем обычно (например, о настройке окружения). Со временем мы стали замечать, что разные члены команд задают одни и те же вопросы. У автоматизаторов уходило много времени на то, чтобы всем ответить, поскольку даже простой и хорошо сформулированный вопрос требует переключения контекста.

Внутрениий StackOverflow

Стоит отметить, что в нашей вики есть документация и описания решений для большинства распространённых проблем. Возможно, документировать все возможные ошибки и объяснения в вики не лучший подход, но мы считали, что сохранить их в одном месте будет полезно. Так у нас возникла идея создания локального Stack Overflow. Для этого мы воспользовались open source-решением Scoold. Оно предназначено для использования на первой линии обработки запросов и работает как обычная Stack Overflow, только для сотрудников компании. Когда у кого-нибудь возникает проблема, достаточно зайти в наш локальный Stack Overflow, чтобы найти решение или написать вопрос, на который ответит кто-то из специалистов.

Преимущества

• Процесс геймифицируется, поэтому в поиск решений вовлекается больше людей. Мы не стали придумывать разные лычки или звания количество голосов или звёзд ничего не значит и вам не советуем этим увлекаться. Геймификация лишь дополнительный стимул для участников, а не основной фактор.

• Мы тратим меньше времени и сил на решение проблем. Во-первых, они оказываются на виду, поэтому их проще решить. Во-вторых, уменьшается количество перекидываний задачи от одного человека к другому.

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

Недостатки

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

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

• На вопросы могут отвечать недостаточно быстро. На этот случай стоит реализовать уведомления в мессенджерах о появлении новых вопросов. Однако сегодня многие работают из дома и мессенджеры переполнены уведомлениями, что повышает соблазн отключить звук. Каждая команда решает эту проблему по-своему, но для нас появление напоминания в чате автоматизаторов в Slack работает хорошо.

Паттерн 2. Введение стандартов (Set Standards)

По мере возможности мы стараемся переиспользовать код в разных приложениях и на разных платформах, чтобы упростить сопровождение и поддержку. Но, как и в любой другой системе, которую несколько лет разрабатывало много людей, разные части кода могут быть написаны в разных стилях. Наш основной язык для сквозных автотестов это Ruby (об истории автоматизации мобильного тестирования в нашей компании рассказывал agile_seph здесь), потому что он как раз позволяет писать код в разных стилях (автор языка Юкихиро Мацумото хотел, чтобы разработчики использовали его язык так, как им удобно). Однако работать с чужим кодом бывает сложно.

Для решения этой проблемы мы выбрали паттерн SET STANDARDS:

Введите и соблюдайте стандарты для артефактов автоматизации.

Без этого может получиться, что над одним проектом работают несколько человек, и у каждого свой стиль и методы (как если бы все говорили на разных языках). Решать проблему мы начали со сбора мнений тех, кто непосредственно занимается автоматизацией. Мы стремились выработать такие соглашения о стиле, которые будут полезны всем пользователям. И чтобы каждый, кто участвовал в принятии решения, в будущем старался его придерживаться. Так мы создали руководства, которые принимают и соблюдают все участники процесса, что в буквальном смысле помогло нам найти общий язык.

Что мы сделали

• Создали локальную вики с актуальными руководствами и документами (например, как настроить окружение, как запускать и поддерживать тесты), которая помогла сократить циклы ревизии кода. Всю документацию мы храним в Confluence, который разделили на несколько частей. Команды регулярно проверяют актуальность своей документации.

• Добавили в вики межкомандные ретроспективы и соглашения. Ежемесячно мы проводим встречи и по результатам каждой из них делаем какие-то практические выводы.

• Что касается самого кода тестов и ограничений на уровне кода для основных этапов и методов верификации, мы внедрили стандартные инструменты, включая RuboCop (статический анализатор и инструмент форматирования кода для Ruby), защитные проверки (Guard Cheсks) и pre-commit-хуки.

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

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

Преимущества

• На сопровождение тестов и исправление ошибок тратится меньше времени и сил. Руководство по написанию кода очень облегчает понимание того, что и как писать.

• На ревью кода уходит меньше времени. С одной стороны, код становится аккуратнее, с другой всегда есть источник истины для рецензента и рецензируемого.

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

Недостатки

• После создания документации её никто не сопровождает. Это общая проблема для любой документации, особенно для той, что не используется постоянно. Поэтому мы назначили ответственных за сопровождение документов и настроили отправку им на почту уведомлений из Confluence, чтобы ничьи комментарии не оставались без внимания.

• Трудно организовывать ретроспективные встречи и привлекать людей. Непросто найти время, когда все заинтересованные сотрудники не заняты решением своих задач. Поэтому такие встречи приходится планировать сильно заранее.

Паттерн 3. Делимся информацией (Share Information)

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

Этот паттерн называется SHARE INFORMATION:

Просите и давайте информацию начальству, разработчикам и другим тестировщикам.

Для нас это способ улучшить автоматизацию тестирования за счёт более широкого набора знаний. Для реализации этого паттерна мы запустили еженедельные короткие презентации QA Lightning Talks. Любой человек может предложить тему и в течение 10-15 минут выступить с ней. Поскольку у встреч чёткий тайминг, это хорошая возможность узнать что-то новое, не потратив на это много времени. Для тех, кто не смог присутствовать, мы сохраняем видеозаписи встреч во внутренней библиотеке.

Доклады могут быть посвящены не только тестированию и его автоматизации. Например, однажды bayandin рассказывал о своём опыте поддержки проекта Homebrew. А я как-то рассказывал о том, что я диванный картограф в Humanitarian OpenStreetMap. Я создаю карты районов, которые плохо картографированы, и потом ими пользуются в работе сотрудники разных организаций вроде Красного Креста или Врачей без границ. Сокращённая версия этого доклада позднее была представлена на сессии Soapbox конференции EuroSTAR 2020.

Преимущества

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

• Общий объём знаний растёт. А согласно исследованию, обмен знаниями улучшает взаимодействие между департаментами и внутри них.

• Дополнительная мотивация к саморазвитию и росту. Когда видишь, что делают другие и как ты можешь им помочь, это может вдохновить научиться чему-то новому или углубить знания.

Недостатки

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

• Трудно удерживать интерес аудитории и увеличивать ее. Мы каждый раз меняем тему и сосредотачиваемся на актуальных проблемах. Например, один из проектов заключался в том, что мы собирали результаты всех тестовых прогонов тикета в таблицу и интегрировали её в Jira. Об этом на ближайшей встрече и рассказал один из участников команды автоматизации тестирования.

Бонус: паттерн для обучения разделение на пары (Pair Up)

Расскажу ещё о том, к чему привели вышеописанные шаги. Например, QA-инженеры стали готовы брать (и постепенно взяли) ответственность за написание, сопровождение и анализ нестабильных автоматизированных тестов. Поэтому мы решили пойти дальше сделать так, чтобы они взяли на себя ещё и фреймворк автоматизации тестирования и некоторые связанные с инструментарием задачи. Такой шаг был бы невозможен, если бы тестировщики не смогли, помимо своих повседневных задач, ещё и изучать фреймворк и плотно работать с кодовой базой. И хотя регулярные задачи решались качественно, казалось, что выйти за их пределы без помощи будет непросто.

Чтобы достичь цели, мы воспользовались паттерном PAIR UP:

Более опытный сотрудник получает себе в пару менее опытного.

Для QA-инженеров мы запустили внутреннюю программу менторства. Что это такое? QA-инженеры присоединяются к автоматизаторам на короткий промежуток времени (обычно на две недели) и работают над задачами из бэклога этой команды, а не из своего. Помогают им в этом менторы из числа старших инженеров-автоматизаторов. Цель внутреннего менторства заключается в обучении. Мы разработали такой манифест:

• Сосредоточенность на обучении, а не на строгом соблюдении сроков.

• Интерактивные обсуждения, а не работа в бункере.

• Ранняя и регулярная обратная связь, а не ретрообзор в конце менторства.

Хотя утверждения справа ценны, утверждения слева для нас ценнее.

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

Итоги

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

Какие проблемы мы смогли решить

• Нежелание обращаться за помощью к коллегам (решили с помощью паттерна Ask for help). Как отметили в своей книге A Journey through Test Automation Patterns: One teams adventures with the Test Automation Серетта Гамба и Дороти Грэхем, не бойтесь просить о помощи: большинству людей на самом деле нравится помогать.

• Высокая стоимость сопровождения кодовой базы тестирования (решили с помощью паттерна Set Standards). Если вы давно работаете над автоматизацией, то стандарты просто необходимы.

• Информационный бункер (решили с помощью паттерна Share Information). Общайтесь с другими людьми: в процессе обсуждения часто рождаются новые идеи.

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

Расскажите в комментариях, с какими сложностями при автоматизации тестирования столкнулись вы и как их решали.

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

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

Я не буду говорить о себе, а расскажу чужую историю. Все имена в ней выдуманные, а совпадения случайны. Её главный герой человек по имени Савелий. И, по случайному совпадению, он админ, как и я.

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

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

Глава 1, в которой Савелий полагается на систему управления конфигурациями

Наш Савелий жил-поживал и продолжал изучать материалы по Linux даже на работе. И однажды он узнал, что существуют системы управления конфигурациями: Ansible, Puppet, Chef и им подобные. Они избавляют от ручной работы при подготовке сервера ко вводу в эксплуатацию.

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

Со временем инфраструктура проекта усложнилась.

Разрослись серверы с фронтендами. Да и с бэкендами, честно говоря, тоже. Появились связи между компонентами, связи внутри каждого компонента.

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

Сервисы также изменились: их стало больше, появились связи и зависимости.

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

Так Савелий отказался от бэкапов.

Глава 2, в которой появляется карта расположения сервисов

Савелий работал в компании не один, с ним было много программистов. Один из них Аристофан был его добрым другом.

Однажды, работая с базой данных, Аристофан случайно сделал дроп.

Савелий хороший админ. Когда он настраивал репликацию, то следил за отставанием от мастера. Точнее он его не допускал.

Поэтому, как только дроп приехал на мастер, он разъехался по всем репликам. Данных больше не осталось.

Что тут сказать: такое бывает не только в сказках.

После этого Савелий задумался. Нет, не о дружбе с Аристофаном, а о том, что бэкапы всё же нужны. И о том, что такое правильный бэкап.

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

1. Он должен находиться в стороне и не должен быть подвержен изменению.

2. Он обязательно должен восстанавливаться.

3. Всегда нужно знать, сколько времени требуется на восстановление бэкапа.

После того как Савелий сформулировал эти правила, появился другой вопрос. Как правильно поступать: по старинке бэкапить сервер целиком или же делать именно сервисные бэкапы?

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

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

Сложность заключалась в другом: после восстановления бэкапа сервера рядом с нужными данными всегда лежали данные, которые были не нужны. Например, когда Савелию нужно было восстановить все данные сервиса А, но при этом на сервере жили ещё и сервисы Б и В, то в бэкапе сервера оказывались все файлы всех трёх сервисов (А, Б и В).

Процесс восстановления в таком случае мог пойти по двум сценариям:

1. Восстановить весь бэкап сервера и потом взять нужные данные. Минусы:

   1. увеличение нагрузки на сеть;

   2. увеличение нагрузки на устройство хранения;

   3. увеличение времени на выборку нужных данных из общей кучи.

2. Выбрать вручную только те данные, которые нужно восстановить. Минусы:

   1. увеличение времени на выборку нужных данных из общей кучи;

   2. высокая вероятность того, что будут выбраны не все данные и процедуру придётся повторить (опять-таки потраченное время).

Как видно, оба варианта имеют существенные недостатки.

Кроме того, иногда данные с одного сервера мигрировали на другой. В этом случае приходилось копаться, выяснять, куда они делись и какой сервер действительно нужен.

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

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

Вывод, к которому пришёл Савелий, прост: современным бэкапам современную оркестрацию.

Глава 3, в которой Савелий понимает, что серверы созданы не только для того, чтобы их бэкапить (а голова не только для того, чтобы в неё есть)

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

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

Решение пришло быстро. Один из способов уменьшения потребления сети и места в хранилище инкрементальные бэкапы. Наученный опытом Савелий решил не рубить с плеча и сначала разобраться в плюсах и минусах такого подхода.

Минусы:

• формирование инкрементального бэкапа на клиенте в некоторых случаях более затратно с точки зрения ресурсов, так как нужно вычислять разницу было-стало;

• потеря инкрементального бэкапа может привести к невозможности восстановления данных на нужный момент времени.

Плюсы:

• экономия ресурсов сети, так как по ней передаётся не весь объём данных, а лишь те, которые изменились;

• экономия места в хранилище.

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

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

В общем, Савелий молодец.

Глава 4, в которой появляется devel

Жили серверы Савелия долго и счастливо. Но пришла новая беда: стало невозможно выкатывать изменения сразу в боевое окружение. Было создано devel-окружение, которое нужно было поддерживать и бэкапить. Оно было точной копией продакшен-окружения, но располагалось на виртуальных машинах.

Проблема была в том, что devel это территория разработчика, вотчина Аристофана. Но Савелий понимал, что рано или поздно Аристофан придёт к нему с вопросом, а есть ли у него бэкап данных за какой-то день.

Выходит, только Аристофан может знать, что нужно бэкапить, а что можно выкинуть. И несёт за это ответственность.

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

Как Савелий организовал процесс бэкапа виртуальных машин:

1. На момент начала бэкапа виртуальной машины на ней не должно быть снапшотов.

2. Если на виртуальной машине есть снапшот, сделанный вручную Аристофаном, то:

   • не удалять снапшот;

   • не выполнять бэкап;

   • сообщать об этом Аристофану и уточнять, нужен ли ему ещё снапшот, и действовать в зависимости от его ответа.

3. По окончании бэкапа удалять временный снапшот.

Также Савелий придумал оповещалку, которая сообщала Аристофану о том, что машины в инфраструктуре уже нет, а запись о её бэкапе или не-бэкапе присутствует.

Почему Савелий не бэкапил виртуалки с базами данных? На самом деле всё просто: теперь он всегда бэкапит все инстансы с базами данных. По умолчанию. Потому что он помнит прекрасную историю про дроп. А на машинах с базами данных ничего ценного, кроме самих данных в базе (для всего остального есть Puppet!), нет.

Глава 5, в которой появляются отличия бэкапа базы данных от бэкапа сервиса

База данных тоже сервис. Бэкап сервиса тоже бэкап. В общем случае при выполнении бэкапа файлы берутся из локальной файловой системы. Сложность в том, что очень часто на сервере с базой данных датасет настолько большой, что локально положить выгрузку (дамп), а потом поместить её в систему резервного копирования невозможно на это просто не хватает места.

С этим столкнулся и наш герой. Он начал использовать pipe: подключался к базе и на лету сливал данные в удалённое хранилище. Причём даже в тех случаях, когда места на сервере хватало. Савелий принял решение бэкапить везде одинаково, чтобы не было энтропии. Админы довольно быстро понимают плюсы такого подхода, а кто не понимает, тот рано или поздно тонет в костылях (костыль в данном случае это использование разных подходов к решению одной и той же задачи).

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

Поэтому Савелий разрешил Аристофану:

• включать и выключать бэкап;

• менять параметры утилит бэкапа;

• менять расписание бэкапа.

К реализации Савелий подошёл просто: он периодически формировал список со всеми машинами с базами данных и делал приоритизацию. Для чего в данном случае понадобилась приоритизация? Всё просто -- давайте представим себе ситуацию, когда нужно выполнить бэкап большого объема данных в условиях того, что этот большой объем расположен на большом количестве серверов? Очевидные проблемы, которые могут возникнуть при данных условиях:

• устройство хранения может стать узким местом, так как сеть не резиновая (источников много, а устройство хранения -- одно)

• как только возникает ограничение пропускной способности -- происходит увеличение времени бэкапа для тех серверов, которые бэкапятся

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

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

Глава 6, в которой Савелий не может жить без уведомлений

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

Но всё оказалось не так просто.

Савелий решил проверить по метрикам, как ведёт себя сервис. Когда приходит бэкап, не начинает ли он, например, отвечать медленнее?

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

Появляется сразу несколько проблем. Главная в бэкап уезжает мусор, так как данные не записались на диск целиком.

Последствия этого:

• тратится место в хранилище;

• потребляются ресурсы сети;

• расходуются дисковый и остальные ресурсы на машине, откуда снимается бэкап.

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

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

Всё сделано, все бэкапится. Савелий научился выявлять пересечения и составлять расписание.

Однако наш герой не мог спокойно спать, потому что не был уверен в том, что с тем, что он забэкапил, всё нормально: можно это достать и что-то с этим сделать.

Как об этом узнать?

Глава 7, в которой необходимо проверять бэкап

Савелий нашёл простое решение. Он разработал чек-лист из четырёх шагов от простого к сложному. В случае если по какой-то причине нельзя было пройти один из шагов, происходил откат на шаг назад и предпринималась попытка устранить проблему.

Шаг 1

Проверяется статус: бэкап завершился со статусом ОК или произошла ошибка. Если ошибка, то разбираемся почему. Если ОК, переходим к следующему шагу.

Шаг 2

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

Шаг 3

Восстановление. Данные необходимо взять непосредственно из системы хранения, залить их на некий сервер и убедиться в том, что можно достать их из хранилища. Только на этом этапе можно выяснить, сколько данных (мегабайтов/гигабайтов/терабайтов) в час прокачивается при восстановлении из бэкапа.

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

Шаг 4

Запуск сервиса: либо он запускается, либо нет. Если сервис не запустился, это самая большая проблема. Значит, надо копать глубже.

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

Глава 8, в которой появляется реализация бэкапов с помощью Bareos

Как в каждой правильной сказке, в конце Савелий должен был изобрести свою систему бэкапов, которая удовлетворяла бы всем его требованиям. На этом можно было бы закончить историю словами И жили они долго и счастливо!, но не тут-то было. Жизнь не сказка: работа сама себя не сделает, как и система бэкапов по щелчку из воздуха не появится.

На момент выбора решений было не то чтобы очень много:

• коммерческие системы резервного копирования (чаще всего на них не хотят тратиться);

• AMANDA;

• Bacula;

• возможно, было что-то ещё, но про это уже никто не помнит.

Савелий решил действовать по хардкору: начал использовать Bacula, а позже Bareos (форк Bacula). Он никогда не искал лёгких путей.

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

Совет 1

Используйте virtual changer (VC). Это не какой-то конкретный инструмент, а целый класс утилит.

Для примера представьте набор сервисов, который мы бэкапим в два пула. Один пул называется SOMETHING-full, второй SOMETHING-incremental. В этом случае можно бэкапить данные в два пула и не переживать о том, что пачка заданий, ожидающих полного бэкапа, встанет в очередь, пока не закончатся инкрементальные бэкапы. Это довольно часто бывает нужно.

Когда идёт набор бэкап-заданий и есть необходимость сделать восстановление, преимущества VC становятся понятны. Без него пришлось бы останавливать все бэкап-задания, монтировать нужные кассеты для восстановления и пытаться восстановиться. Virtual changer позволяет довольно просто осуществлять удаление и добавление кассет, маркировки, очистки, транкейта и пр.

Совет 2

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

Если вы имеете дело с отдельным блочным устройством, экспериментируйте с параметром read ahead. Конечно, всё зависит от того, хватит ли памяти на машине, но в случае восстановления это достаточно сильно помогало Савелию.

Совет 3

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

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

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

Совет 4

В Bareos много собственных параметров и крутилок. Крутить можно всё что угодно. Основное, на что Савелий обращает внимание:

• параметры, которые относятся к Maximum Volume Jobs и Concurrent Jobs, как раз для настройки количества заданий на кассете;

• параметры, которые касаются block size и file size, влияют на скорость записи бэкапа, если их можно откуда-то линейно быстро читать и быстро писать;

• параметры, которые дадут чуть больше гарантий того, что будет корректная цепочка бэкапов Max Full Interval;

• параметры, которые остановят выполнение задачи, если нет подходящей кассеты Max Wait Time;

• параметры Spool Attributes и Spool Data относятся больше к ленточному бэкапу, чем к файловому, но Савелий считает, что имеет смысл их тоже покрутить.

Всё очень сильно зависит от задачи, которая решается. Поэтому прежде чем изменять параметры, нужно понимать, зачем это делается, и измерять результаты до изменения и после него.

Совет 5

Когда Савелий решил бэкапить все базы по умолчанию, возникла проблема. Раз он бэкапит всё, то правила хранения одинаковые. У Савелия стандартные условия хранения бэкапа баз такие:

• Full: два последних успешных бэкапа (делается один раз в неделю);

• Incremental: всё до самого старого Full (делается один раз в сутки).

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

Если нужно хранить дольше, то с этим нужно что-то делать, например бэкапить базы или сервисы дополнительно в другие пулы. Но более правильным решением будет использование copy job (migration, если не хочется занимать в два раза больше места), которая заберёт то, что уже лежит в системе хранения, положит в другой пул и оно будет там жить столько времени, сколько нужно.

Совет 6

Если необходимо забэкапить кусок файловой системы с кучей директорий, миллионами мелких файлов и т. п., то простой вариант Bareos-бэкапа не подходит. Файловый демон будет тратить всё время на процесс построения дерева того, что необходимо забэкапить, а не заниматься копированием бэкапа в хранилище.

Нужно искать другие варианты решения, например:

• бэкапиться снапшотом;

• делать бэкап через pipe.

Или рассмотреть вариант не бэкапить Bareos по классической схеме File daemon -> Storage daemon, а придумать другую систему, которая будет заливать необходимые файлы в хранилище. Если выбран такой вариант, то его стоит обозначить как задачу с пустым fileset в Bareos. Нужно это для того, чтобы сведения обо всех бэкапах находились в одном месте.

Совет 7

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

Совет 8

Проверяйте базу Bareos: bareos-dbcheck в помощь. Обратите внимание на DB backend: MySQL, PostgreSQL. Как минимум стоит принять во внимание мнение разработчиков по данному вопросу, чтобы потом не удивляться.

Совет 9

Собирайте логи и метрики: в Elasticsearch, InfluxDB, Prometheus на ваш вкус. Они помогут ответить на кучу вопросов, а при построении бэкапа они возникнут абсолютно точно.

Приблизительно такие графики можно строить, собирая различные метрики:

Данный график показывает, как в течение определённого отрезка времени происходит запись в разные пулы.

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

Также будут видны попытки что-то ресторить.

Там, где график идёт вверх и скорость увеличивается, меняли параметр read ahead. В данном случае это изменение стандартного read ahead для блочного устройства.

Можно увидеть, какое количество данных поминутно, по часам сливается в бэкап-систему.

Также важно знать, в какие пулы сливаются данные и когда заканчиваются задания. Это даёт возможность найти окна в расписании, что-то подвинуть, сделать жизнь и работу бэкапа чуть лучше.

Начало работ:

Окончание и результаты работ:

Работы, завершённые с ошибками:

Выводы

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

Как бы ни менялся мир вокруг, какие бы технологии ни появлялись, данные это основная ценность проекта. Поэтому кто бы когда бы и что бы ни говорил, бэкапы нужны всегда. Бэкапы важны!

Савелий умеет расставлять приоритеты и точно знает, что недостаточно сделать бэкап. Тут-то всё очень просто скопировал и забыл. Важно уметь бэкапы восстанавливать. За восстановлением данных не приходят каждый день/неделю/месяц, но, если пришли, необходимо эти данные предоставить. Восстановление данных из бэкапа это очень важная (если не важнейшая) составляющая системы резервного копирования. Пожалуйста, уделяйте этому процессу достаточно внимания!

Не надо бояться экспериментировать. Хотя Bareos по своей сути довольно консервативен, всегда можно прикрутить что-то сбоку, чтобы сделать возможным и эффективным его использование в современных инфраструктурах. Рано или поздно всё точно получится. Савелий смог и вы сможете!

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

Меня зовут Евгений Тупиков, я ведущий PHP-разработчик в Badoo и Bumble. У нас в команде более 200 бэкенд-разработчиков, которые работают над сотнями модулей и отдельных сервисов в наших приложениях. Но поначалу всё было не так масштабно. В 2006 году это был один проект, над которым работала небольшая команда. Каждый разработчик хорошо понимал, как всё устроено: легко ориентировался в коде, знал, какие есть сервисы и как они взаимодействуют между собой. Однако по мере роста проекта всё больше времени занимал поиск хранителей знаний тех, кто отвечает за ту или иную функциональность и к кому можно обратиться с вопросом или предложением.

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

Предыстория

Представим ситуацию: разработчик одной из команд занимается исправлением бага и в процессе дебага дошёл до кода, за который отвечает другая команда. Как понять, кто именно ответственен за данную функциональность и к кому идти с вопросами?

Другими словами, нужен способ легко найти ответственного за ту или иную часть системы. И для этого мы стали использовать два специальных тега в докблоке (DocBlock) файла:

• @team команда, ответственная за данную часть системы;

• @maintainer человек, разрабатывающий данную функциональность (таких сотрудников может быть несколько).

/** * @team Team name <team@example.com> * @maintainer John Smith <john.smith@example.com> * @maintainer .... */

Такой подход очень просто внедрить и использовать. Например, можно настроить шаблон в PhpStorm и нужные теги будут автоматически проставляться при создании нового файла. Мы ещё сделали отдельный Git hook, следящий за тем, чтобы у всех файлов были проставлены нужные теги в требуемом формате.

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

Нам же хотелось иметь возможность обновлять список ответственных в одном месте. И желательно, чтобы все остальные системы автоматически подхватывали изменения.

Так мы пришли к компонентному подходу.

Что такое компонент

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

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

При переходе на компонентный подход мы сформировали ряд правил и ограничений:

• структура компонентов должна быть линейной;

• каждая команда должна иметь свой набор компонентов (один и тот же компонент не может относиться к нескольким командам);

• для каждого компонента должен быть задан список ответственных, при этом оптимальное количество ответственных за один компонент двачетыре человека;

• только менеджер или тимлид команды может добавлять и удалять компоненты;

• у каждого компонента должен быть уникальный идентификатор (alias).

Для управления компонентами у нас есть специальный интерфейс в интранете. Страница компонента выглядит следующим образом:

Мы видим, что у компонента есть:

• уникальный идентификатор;

• email;

• название команды, которая отвечает за данный компонент;

• название проекта, к которому относится компонент, в Jira;

• краткое описание, которое помогает понять, для чего нужен компонент и какая у него зона ответственности;

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

Как мы используем компоненты в коде

Докблок файла

/** * @component component_alias */

Мы доработали Git hook, проверяющий докблок. Он следит за тем, чтобы файлы, в которые были внесены изменения, содержали тег @component и чтобы указанный компонент существовал.

remote: ERROR in SomeClass.php:        remote: * Unknown @component: UnknownComponent. You have to create component before using it in the code   

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

Сервис для работы с компонентами в коде

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

$componentManager = new \Components\ComponentManager();$component = $componentManager->getComponent('component_alias');$recipients = [];foreach ($component->getMaintainers() as maintainer) {    $recipients[] = $maintainer->getEmail();}

или найти дежурного по компоненту:

$componentManager = new \Components\ComponentManager();$component = $componentManager->getComponent('component_alias');foreach ($Component->getMaintainers() as $maintainer) {    if ($maintainer->isDuty()) {        return $maintainer;    }}

Интеграция с PhpStorm

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

Теперь IDE автоматически выводит на экран владельца компонента и дежурного. Также при наведении на идентификатор компонента отображается дополнительный блок со списком всех ответственных за него с возможностью отправки личных сообщений в мессенджер (Slack).

Дежурный по компоненту

Думаю, многие из вас сталкивались с проблемой переключения контекста. На мой взгляд, надо стараться этого избегать. У каждого своя скорость и требуется разное количество времени, чтобы снова погрузиться в задачу (контекст). Кому-то достаточно нескольких минут, а кому-то нужно гораздо больше.

Чтобы минимизировать последствия переключения контекста, мы решили ввести практику дежурств. Теперь у каждого компонента есть дежурный, который является входной точкой для всех вопросов связанных с ним. Когда человек заступает на дежурство, отметка об этом появляется у всех нужных компонентов и отображается в публичной группе в мессенджере.

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

Кроме того, дежурства позволяют делиться знаниями внутри команды, тем самым повышая bus factor.

Интеграция с внутренними системами

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

Система сбора и анализа PHP-ошибок

Исторически для сбора и анализа PHP-ошибок мы используем самописную систему, которая по функциональности похожа на популярные Sentry и Splunk, но адаптирована к нашим внутренним процессам. В неё первую мы добавили поддержку компонентов.

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

Эту информацию можно использовать:

• для поиска ошибок по определённому компоненту;

• для построения отчётов и графиков в разбивке по компонентам.

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

Реестр баз данных

Бэкенд наших приложений Badoo и Bumble состоит из сотен различных модулей, систем и сервисов. Большинство из них для хранения данных использует MySQL.

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

1. Найти в коде, на каком хосте живёт база.

2. Подключиться к хосту через любой удобный инструмент (консольная утилита, phpMyAdmin, Sequel Pro, IDE и т. д.).

3. Найти нужную базу и таблицу.

4. Изучить информацию о таблице.

А если нужно узнать размер таблицы на продакшене?

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

Другой пример: нужно найти список таблиц, которые долгое время не используются и просто занимают место на сервере. Тут уже нужно писать скрипт, который обойдёт все нужные серверы и соберёт статистику.

Чтобы упростить жизнь разработчикам, мы создали систему под названием DBRegistry. Она хранит в себе информацию для всех баз данных, доступную через INFORMATION_SCHEMA.

При внедрении компонентов мы добавили возможность указания, к какому компоненту относится та или иная база данных или таблица.

Информация о компоненте будет полезна в случае, если с каким-то сервером начались проблемы (например, выросла нагрузка на CPU) и администратор баз данных нашёл проблемный запрос и хочет сообщить о проблеме разработчику. Он просто находит нужную таблицу в DBRegistry, смотрит, к какому компоненту она привязана, и пишет о проблеме дежурному.

Заключение

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

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

На этом всё. Спасибо за внимание!

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

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

В этой статье я расскажу:

• как мы не потерялись в сложном графе зависимостей;

• как спасли CI от чрезмерной нагрузки;

• что делать, если с каждым новым модулем приложение запускается всё медленнее;

• мониторинг каких показателей стоит предусмотреть и почему это необходимо.

Сложный граф зависимостей

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

Так выглядел граф зависимостей Badoo к моменту, когда у нас было около 50 модулей:

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

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

2. Сложности визуализации порождают сложности отладки. Найти фундаментальные проблемы в сложном графе зависимостей крайне непросто.

3. Добавление зависимостей, особенно промежуточных (о них мы говорили в первой части), ресурсоёмкая задача, влекущая за собой дополнительную нагрузку на разработчиков и отвлекающая от решения продуктовых задач.

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

Основные характеристики утилиты:

• это консольное Swift-приложение;

• работает с xcodeproj-файлами с помощью фреймворка XcodeProj;

• понимает сторонние зависимости (мы не очень активно и охотно принимаем их в проект, но некоторые всё же используем; загружаются и собираются они через Carthage);

• включена в процессы непрерывной интеграции;

• знает о требованиях к нашему графу зависимостей и работает в соответствии с ними.

Последний пункт объясняет, почему не стоит надеяться на появление подобных утилит с открытым исходным кодом. Сегодня не существует универсальной хорошо описанной структуры проектов и их настроек, которая подойдёт всем. В разных компаниях могут отличаться различные параметры графа:

• статическая или динамическая линковка;

• инструменты поддержки сторонних зависимостей (Carthage, CocoaPods, Swift Package Manager);

• хранение ресурсов в отдельных фреймворках или на уровне приложения;

• и другие.

Поэтому, если вы смотрите в сторону 100+ модулей, на каком-то этапе вам, скорее всего, придётся задуматься о написании подобной утилиты.

Итак, для автоматизации работы с графом зависимостей мы разработали несколько команд:

1. Doctor. Команда проверяет, все ли зависимости корректно связаны и встроены в приложение. После исполнения мы либо получаем список ошибок в графе (например, отсутствие чего-либо в фазе Link with binaries или Embedded frameworks), либо скрипт говорит, что всё хорошо и можно двигаться дальше.

   

2. Fix. Развитие команды doctor. Эта команда в автоматическом режиме исправляет проблемы, найденные командой doctor.

   

3. Add. Добавляет зависимость между модулями. Пока у вас простое небольшое приложение, добавление зависимости между двумя фреймворками кажется простой задачей. Но когда граф сложный и многоуровневый, а вы работаете с включёнными явными зависимостями, добавление нужных зависимостей становится задачей, которую вы не захотите из раза в раз делать руками. Благодаря команде add разработчики могут просто указать два названия фреймворков (зависимый и зависящий) и все фазы сборки заполнятся необходимыми зависимостями в соответствии с графом.

Впоследствии скрипт создания нового модуля по шаблону также стал частью утилиты deps. Что мы получили в итоге?

1. Автоматизированную поддержку графа. Мы находим ошибки прямо в pre-commit hook, сохраняя стабильность и правильность графа и давая возможность разработчику в автоматическом режиме эти ошибки исправлять.

2. Упрощённое редактирование. Добавить новый модуль или связи между модулями можно одной командой, что сильно упрощает их разработку.

Непрерывная интеграция не справлялась

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

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

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

Мы безуспешно попробовали несколько подходов. Расскажу о них подробнее, чтобы вы не повторяли наши ошибки.

Очевидным решением было перестать собирать и проверять всё и всегда. Нужно было, чтобы CI проверял только то, что нужно проверить. Что не сработало:

1. Вычисление изменений по структуре директорий. Мы пробовали положить в репозиторий файл с маппингом директория модуль, чтобы понимать, какие модули нужно проверить, но буквально через неделю из-за увеличившегося количества падений приложения на проде обнаружили, что файл был перенесён в новый модуль и изменён одновременно, а файл маппинга при этом обновлён не был. Контролировать обновление файла с маппингом автоматически не представлялось возможным и мы перешли к поиску иных решений.

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

3. Разработчик указывает, что проверять. Этот эксперимент завершился быстрее всех буквально за пару дней. Благодаря ему мы узнали, что разработчики бывают двух типов:

   1. Те, кто на всякий случай проверяет всё.

   2. Те, кто уверен, что не мог ничего сломать.

Как вы поняли, из-за первых очереди на CI почти не становились меньше, а из-за вторых у нас ломалась основная ветка разработки.

В итоге мы вернулись к идее автоматизации вычисления изменений, но немного с другой стороны. У нас была утилита deps, которая знала про граф зависимостей и файлы проекта. А Git позволяла получить список изменённых файлов. Мы расширили deps командой affected, с помощью которой можно было получить список затронутых модулей, исходя из изменений, отражаемых системой контроля версий. Ещё более важно то, что она учитывала зависимости между модулями (если от затронутого модуля зависят другие модули, их тоже необходимо проверить, чтобы, например, в случае изменения интерфейса более низкого модуля верхний не перестал собираться).

Пример: изменения в блоках Регистрация и Аналитика на нашей схеме указывают на необходимость проверить также модули Чат, Sign In with Apple, Видеостриминг и само приложение.

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

В результате такой модернизации мы получили ряд бонусов:

1. Мы проверяем в CI только то, что действительно было затронуто прямо или косвенно.

2. Продолжительность CI-проверок перестала линейно зависеть от количества модулей.

3. Разработчик понимает, что его изменения могут затронуть и где нужно быть осторожным.

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

Ждём завершения Е2Е-тестов

Для приложения Badoo у нас есть более 2000 сквозных (end-to-end) тестов, которые его запускают и проходят по сценариям использования для проверки ожидаемых результатов. Если запустить все эти тесты на одной машине, то прогон всех сценариев займёт около 60 часов. Поэтому на CI все тесты запускаются параллельно насколько это позволяет количество свободных агентов.

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

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

Для каждого нового модуля отдельный скрипт в CI проверяет наличие модуля в этом маппинге, чтобы разработчики не забывали синхронизироваться с командой тестирования для пометки модуля необходимыми группами тестов.

Подобное решение едва ли можно назвать оптимальным, но всё же преимущества от его внедрения были ощутимы:

1. Нагрузка на CI существенно снизилась. Чтобы не быть голословным, привожу график времени, которое задача на прогон сквозных тестов провела в очереди:

   

2. Уменьшился шум инфраструктурных проблем (меньше запусков тестов меньше падений из-за зависших агентов, сломавшихся симуляторов, недостатка места и т. д.).

3. Карта модулей и их тестов стала точкой синхронизации отделов разработки и тестирования. В рамках разработки программист и тестировщик обсуждают, например, какие из имеющихся групп тестов могут подойти для проверки в том числе нового модуля.

Медленный запуск приложения

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

В середине графика видно резкое снижение времени. Причина переход на статическую линковку. С чем это связано? Инструмент динамической загрузки модулей dyld от Apple выполняет трудоёмкие задачи не совсем оптимальными способами, время исполнения которых линейно зависит от количества модулей. В этом и была основная причина замедления запуска нашего приложения: мы добавляли новые модули dyld работал всё медленнее (на графике синяя линия отражает количество добавляемых модулей).

После перехода на статическое связывание количество модулей перестало влиять на скорость запуска приложения, а с появлением iOS 13 Apple перешла на использование dyld3 для запуска приложений, что тоже поспособствовало ускорению этого процесса.

Стоит сказать, что статическая линковка несёт с собой и ряд ограничений:

1. Одно из наиболее неудобных невозможность хранения ресурсов в статических модулях. Эта проблема частично решается в относительно новых XCFrameworks, но технологию пока что нельзя считать проверенной временем и полноценно готовой к Enterprise. Мы решили эту проблему созданием рядом с модулем отдельных бандлов, которые уже упаковываются в готовое приложение или тестовый бандл для прогона тестов. Обеспечением целостности графа при работе с ресурсами также занимается утилита deps, которая получила несколько новых правил.

2. После перехода на статическую линковку нужно хорошенько протестировать приложение на предмет рантайм-падений. Чтобы исправить многие из них, вам просто придётся использовать не самые оптимальные параметры оптимизаций. Например, почти для всех Objective-C-модулей придётся включить флаг -all-load. Отмечу ещё раз, что решение всех этих проблем с вынесенными xcconfigами (про xcconfig в первой части) не было таким мучительным, каким могло бы быть.

Итак, мы побороли две основные проблемы, вынесли ресурсы в отдельные бандлы, поправили конфигурации сборки. В результате:

• количество модулей в приложении перестало влиять на скорость его запуска;

• размер приложения уменьшился примерно на 30%;

• количество крашей уменьшилось в три раза за счёт ускорения запуска. iOS убивает приложения, если они долго запускаются, а на устройствах старше трёх лет со слабенькими батареями, где процессор давно не работает на максимуме, это реальные случаи, которых стало значительно меньше.

Цифры подскажут, куда двигаться дальше

Мы рассмотрели глобальные изменения, которые нам пришлось сделать, чтобы жить в мире и согласии в процессе модуляризации:

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

• уменьшение нагрузки на CI за счёт фильтрации проверяемых модулей и умных тестов: не попадайтесь в ловушку прямой зависимости продолжительности CI-проверок от количества модулей;

• статическая линковка: скорее всего, вам придётся перейти на статическое связывание, так как уже к 50-60 модулям регресс в скорости запуска приложения станет заметен не только вам, но и вашим менеджерам.

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

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

Поэтому у нас есть график среднего времени сборки наших приложений на компьютерах разработчиков:

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

Ещё один интересный вывод, к которому мы пришли, получив подобную аналитику: медленно собирающиеся модули не всегда повод для оптимизации.

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

Кроме того, мы стали понимать, какое оборудование ещё подходит для работы над нашим проектом, а с каким пришло время прощаться.

Например, видно, что iMac Pro 5K 2017 года выпуска не лучшее железо для сборки Badoo, в то время как MacBook Pro 15 2018 года ещё вполне неплох.

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

Измеряем время сборки

Чтобы получать данные о продолжительности сборки на компьютерах разработчиков, мы создали специальное macOS-приложение Zuck. Оно сидит в статус-баре и следит за всеми xcactivitylog-файлами в DerivedData. xcactivitylog файлы, которые содержат ту же информацию, которую мы видим в билд-логах Xcode в непростом для парсинга формате от Apple. По ним можно понять, когда началась и закончилась сборка отдельного модуля и в какой последовательности они собирались.

В утилите есть white- и black-листы, так что мы отслеживаем только рабочие проекты. Если разработчик скачал демо-проект какой-то библиотеки с GitHub, мы не будем отправлять данные о её сборке куда-либо.

Информацию о сборке наших проектов мы передаем во внутреннюю систему аналитики, где имеется широкий инструментарий для построения графиков и анализа данных. Например, у нас есть инструмент Anomaly Detection, который предсказывает аномалии в виде слишком сильных отклонений от прогнозируемых значений. Если время сборки резко изменяется по сравнению с предыдущим днём, Core-команда получает уведомление и начинает разбираться, где и что пошло не так.

P. S. Мы дорабатываем Zuck, чтобы выпустить его в open source.

В целом измерение локального времени сборки даёт важные результаты:

• мы измеряем влияние изменений на разработчиков;

• имеем возможность сравнивать чистые и инкрементальные сборки;

• знаем, что надо улучшить;

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

Далее я приведу краткую сводку метрик, за которыми нужно следить, если вы начали двигаться в сторону модуляризации:

1. Время запуска приложения. Последние версии Xcode предоставляют эту информацию в разделе Organizer. Метрика быстро укажет на появившиеся проблемы.

   

2. Размер артефактов. Эта метрика поможет быстро обнаружить проблемы линковки. Возможны случаи, когда линковщик не сообщает о том, что, например, какой-то модуль дублировался. Однако об этом скажет увеличившийся размер скомпилированного приложения. Обращайте внимание на этот график. Проще всего подобную информацию получить из CI.

   

3. Инфраструктурные показатели (время сборки, время задач в очереди CI и т. п.). Модуляризация скажется на многих процессах компании, но инфраструктура особенно важна, потому что её придётся масштабировать. Не попадайтесь в ловушку, как мы, когда до мержа в мастер изменениям приходилось находиться в очереди по пять-шесть часов.

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

Если вам кажется, что я сейчас сделаю вот так и по-любому станет лучше, но вы не можете это лучше измерить, стоит подождать с таким экспериментом. У вас ведь наверняка тоже есть менеджер, которому нужно будет как-то презентовать результаты своей работы.

Заключение

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

1. Всего сейчас у нас работают 43 iOS-разработчика.

2. Четыре из них в Core-команде.

3. Сейчас у нас два основных приложения и N экспериментальных.

4. Около 2 миллионов строк кода.

5. Около 78% из них находятся в модулях.

Последняя цифра постепенно растёт: старые фичи и переписанный legacy-код потихоньку перетекают из основного таргета приложений в модули.

В двух статьях я рекламировал вам модуляризацию, но, конечно, у неё есть свои минусы:

• усложнение процессов: вам придётся решить ряд вопросов в процессах как вашего департамента и рядовых iOS-разработчиков, так и во взаимодействии с другими департаментами: QA, CI, менеджерами продуктов и т. д.;

• в процессе перехода на модуляризацию вскроются проблемы, которых вы не ждали, всё не предусмотреть: возможно, потребуются дополнительные ресурсы и других команд;

• всё, что вы построите, будет нуждаться в дополнительной поддержке: процессы, новые внутренние инструменты кто-то должен будет за это отвечать;

• приложения, базирующиеся на модулях, сильнее зависят друг от друга. Например, при изменении чего-то в модуле работы с базой данных для приложения Badoo через несколько минут можно получить от CI сообщение о том, что в приложении Bumble не прошли тесты.

Но хорошая новость заключается в том, что все эти минусы управляемы. Их не стоит бояться, поскольку это не те проблемы, которые невозможно решить. Нужно просто быть к ним готовыми.

О плюсах модуляризации уже было сказано, но я повторюсь:

• гибкое масштабирование iOS-разработки: новые команды начинают работать в своих модулях, подход к созданию и поддержке которых унифицирован;

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

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

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

В первой части статьи мы поговорили о том, что такое ANR (Application Not Responding), и рассмотрели несколько способов сбора информации об этих ошибках. А сегодня я расскажу о проблемах, которые мы обнаружили в нашем приложении, о том, как мы их исправляли и что из этого в итоге получилось.

Время запуска приложения

Первое, что можно сделать, чтобы уменьшить количество ANR-ошибок, попробовать найти самые частые причины их возникновения. Начать можно с консоли Google Play проанализировать самые большие группы ошибок. Наша консоль выглядела примерно так:

Почти каждая группа содержала заголовок Broadcast of Intent { act=com.google.android.c2dm.intent.RECEIVE } , но на первый взгляд все они были разные, так как стек-трейс основного потока каждой группы указывал на разные места в приложении. Мы попытались найти что-то общее между этими группами и в итоге, воспользовавшись локальными отчётами, которые мы получили с помощью скрапера, выяснили, что около 60% ANR-ошибок возникало во время исполнения метода Application.onCreate.

Этот метод является частью критического пути запуска приложения, то есть любые задержки в его исполнении будут влиять на время холодного старта. Мы хотели понять, могут ли эти задержки как-то влиять на ANR.

Мы добавили искусственную задержку в Application.onCreate и поэкспериментировали с несколькими сценариями на последних версиях Android. Вот что мы выяснили:

• когда пользователь вручную запускает приложение через лаунчер, то ANR-диалог не появляется и приложение стартует в нормальном режиме, даже если мы добавляем задержку на несколько минут;

• когда процесс приложения запускается через BroadcastReceiver, то ошибка ANR возникает при задержке от 10 секунд. Это не очень жёсткое ограничение, но в любом случае оно гораздо строже, чем в предыдущем сценарии.

Важное примечание ко второму сценарию: по умолчанию, если приложение находится в фоновом режиме во время появления ANR-ошибки, Android не показывает ANR-диалог (его отображение можно включить с помощью опции Enable background ANR dialogs в настройках для разработчиков). Фактически это означает, что пользователи, скорее всего, ничего не заметят и ошибка не будет заметно влиять на пользовательский опыт.

Поэтому мы пришли к выводу, что основной причиной возникновения наших ANR-ошибок, вероятно, является длительное время выполнения метода Application.onCreate. И судя по информации из консоли Google Play, в большинстве случаев это происходило во время исполнения Firebase Cloud Messaging BroadcastReceiver: иногда мы выходили за 10-секундный лимит, что приводило к фоновым ANR-ошибкам.

Мы изучили нашу внутреннюю аналитику, в которой отслеживаем время, прошедшее с момента создания класса Application до завершения метода Application.onCreate (мы называем это холодным запуском). В нашем приложении эта часть процесса запуска самая большая, она включает в себя инициализацию всех ContentProviderов и, собственно, сам метод onCreate.

Также мы разделили данные на две части: фоновый холодный запуск и не фоновый. Фоновый запуск мы определяли простым путём: проверяли, был включён экран или нет. В Android, к сожалению, нет простых способов определить причину запуска процесса при исполнении метода Application.onCreate, но в любом случае, скорее всего, этот метод определения фонового запуска даёт более или менее правдивую картину. Вот что мы получили:

Можно заметить, что обычный запуск занимал в среднем 2,2 секунды, а фоновый 5 секунд. Около 3% фоновых запусков длилось дольше 10 секунд. Это говорит о том, что вполне вероятно, в этих случаях могли возникать ANR-ошибки. Чтобы подтвердить или опровергнуть эту гипотезу, мы решили попытаться ускорить запуск приложения.

Ускорение запуска приложения

Чтобы найти потенциальные места для оптимизации на критическом пути запуска приложения, проще всего начать с анализа трассировки вызовов методов. Для этого в Android Studio есть неплохие встроенные инструменты.

В профилировщике Android Studio есть кнопки для запуска приложения с профилированием и для запуска/остановки профилирования во время работы приложения. Кроме того, есть специальные методы, вызвав которые можно начинать или прекращать профилирование из кода. Для получения консистентных результатов между запусками нам лучше подходит второй способ. Можно воспользоваться вот этими методами:

• startMethodTracingSampling

• startMethodTracing

• stopMethodTracing

Начать трассировку можно в статическом инициализаторе класса Application (или в конструкторе), а завершить её либо в конце метода Application.onCreate, либо в onResume первого Activity. Например, класс Application может выглядеть как-то так:

class Application {    constructor() {        Debug.startMethodTracingSampling("/sdcard/startup.trace", 64 * 1024 * 1024, 50)    }    override fun onCreate() {        //         Debug.stopMethodTracing()    }} 

После этого файл с трассировкой можно открыть в Android Studio:

При анализе результатов важно помнить о паре важных моментов.

• Разница между sample-based- и method-based-трассировкой. При использовании второго подхода можно столкнуться с достаточно большими искажениями в тех случаях, когда есть большое количество вызовов довольно быстрых методов. Sample-based-трассировка работает точнее, но при её использовании могут теряться некоторые вызовы методов. В обоих случаях нет смысла использовать абсолютные значения времени, но sample-based-трассировка даёт более подходящие результаты для относительного анализа.

• Разница между debug- и release-сборкой приложения. При профайлинге запуска приложения имеет смысл выполнять тестирование в окружении, которое как можно ближе к продакшен-версии. Для этого желательно отключить все отладочные инструменты (такие как Leak Canary) либо собрать релизную сборку приложения.

Проанализировав трассировку, мы нашли несколько участков кода, которые выполнялись довольно долго. У нас не было ресурсов на то, чтобы переписать всё приложение для ускорения его запуска (хотя иногда это бывает необходимо ?), поэтому мы попытались получить максимальный результат, приложив минимум усилий. Мы использовали несколько подходов. Я расскажу о некоторых из них, которые вы тоже можете применять в своих приложениях.

Правильный выбор жизненного цикла для компонентов

Одним из простейших способов уменьшения времени запуска приложения является ленивая инициализация всех компонентов. Довольно часто может возникать соблазн создавать различные компоненты и структуры данных в application scope, так как это удобно в том плане, что они будут доступны в течение всего жизненного цикла приложения. Но по возможности лучше этого избегать. Правильный выбор набора компонентов в application scope может не только ускорить запуск, но и уменьшить потребление памяти, потому что вы не будете хранить ссылки на лишние объекты в течение всего времени работы приложения.

Фоновая инициализация и инициализация с задержкой

Если при запуске приложения вам нужно инициализировать какие-либо структуры или объекты, подумайте, возможно ли это сделать немного позже и не на основном потоке. Если же код обязательно должен быть выполнен на основном потоке, то может помочь обычная задержка в несколько секунд (Handler.postDelayed). Распределение задач по времени также снижает вероятность блокирования главного потока.

Сторонние ContentProviderы

Некоторые сторонние библиотеки могут инициализировать код с использованием ContentProvider. Всегда важно смотреть, что у вас содержится в итоговом AndroidManifest.xml, поскольку по умолчанию инструменты сборки Android будут автоматически добавлять ContentProvider из всех сторонних библиотек, что может повлиять на время запуска приложения.

Если для каких-то библиотек вам не нужна автоматическая инициализация ContentProvider, вы можете отключить её, добавив в AndroidManifest.xml такую запись:

<provider    android:name="some.ContentProvider"    tools:node="remove" /> 

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

Когда мы выпустили обновление с нашими оптимизациями, 95-й перцентиль холодного запуска приложения уменьшился примерно на 50% (с ~10 секунд до ~5 секунд):

А что насчёт количества ANR-ошибок? Вот что мы увидели в консоли Google Play:

Итак, мы выяснили, что в нашем случае скорость запуска приложения напрямую влияет на количество ANR-ошибок. Но порог Bad Behaviour всё равно был превышен, так что мы продолжили искать способы решения этой проблемы.

SharedPreferences и метод apply()

При анализе стек-трейсов в Google Play и изучении внутренних отчётов мы заметили вот такие странные группы:

Это говорит о том, что есть много случаев, когда главный поток блокируется где-то в недрах Android, в месте, связанном с SharedPreferences.

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

Мы проверили свою кодовую базу и не обнаружили использования метода commit, который выполняет запись на диск в блокирующем режиме. Все операции записи в SharedPreferences были сделаны с применением метода apply. Почему же тогда мы столкнулись с этой проблемой, если мы используем неблокирующий API?

Найти причину поможет внимательное изучение исходного кода Android. Стандартная реализация SharedPreferences находится в SharedPreferencesImpl.java. При внесении изменений в SharedPreferences записи о них сохраняются во временную HashMap, которая затем при вызове commit или apply применяется к кешу, хранящемуся в оперативной памяти. Во время обновления кеша также вычисляется, какие ключи были изменены, чтобы потом, когда нам нужно будет записать эти изменения на диск, мы не делали лишнюю работу. Информация об изменениях хранится в MemoryCommitResult.

Если посмотреть на тело метода apply(), то мы увидим, что он просто отправляет лямбду записи на диск в метод enqueueDiskWrite(), что выглядит довольно безобидно и намекает на то, что эта лямбда будет выполнена на фоновом потоке. Вот упрощённая реализация метода apply():

@Overridepublic void apply() {    final MemoryCommitResult mcr = commitToMemory();    final Runnable awaitCommit = () -> mcr.writtenToDiskLatch.await();    QueuedWork.addFinisher(awaitCommit);    Runnable postWriteRunnable = () -> {        awaitCommit.run();        QueuedWork.removeFinisher(awaitCommit);    }    SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);} 

Здесь сначала создаётся объект Runnable лямбда, которая может синхронно выполнить запись. Этот Runnable добавляется в QueuedWork. Если мы посмотрим JavaDoc для QueueWork класса, то увидим примерно следующее:

Internal utility class to keep track of process-global work that's outstanding and hasn't been finished yet.

This was created for writing SharedPreference edits out asynchronously so we'd have a mechanism to wait for the writes in Activity.onPause and similar places, but we may use this mechanism for other things in the future.

Этот класс хранит в себе список всех отложенных асинхронных операций с возможностью исполнить их синхронно в случае наступления таких событий, как Activity.onStop, Service.onStartCommand или Service.onDestroy.

Это означает, что простое использование стандартных компонентов Android может приводить к выполнению всех отложенных дисковых операций на главном потоке. И если любая из этих операций выполняется сразу после вызова метода apply(), то он фактически становится синхронным методом commit().

Мы подозреваем, что это было сделано для снижения риска потери данных, когда процесс приложения убивается по разным причинам. Но насколько вероятна такая ситуация? Обычно мы используем SharedPreferences, когда приложение находится на переднем плане и у него мало шансов быть остановленным системой. Более того, часто мы используем SharedPreferences для кеширования значений, которые можно легко восстановить с сервера, так что потеря таких данных не особо страшна.

Чтобы узнать, как SharedPreferences влияют на количество ANR-ошибок и полезна ли эта синхронная логика apply, мы решили провести A/B-тест, который меняет поведение этого метода. Для этого мы заменили все операции создания SharedPreferences на функцию-фабрику:

fun Context.createPreferences(name: String, mode: Int = Context.MODE_PRIVATE): SharedPreferences = getSharedPreferences(name, mode) 

Теперь мы можем управлять реализацией SharedPreferences в нашем приложении и использовать любую другую альтернативную реализацию вместо системной. Мы создали простой класс-имплементацию SharedPreferences, который делегирует в настоящую реализацию всё, кроме метода apply(): вместо него мы вызываем метод commit() на фоновом потоке. Эта реализация очень похожа на то, что сделано в другой библиотеке-альтернативе SharedPreferences Binary Preferences, только в нашем случае мы не меняем механизм сериализации-десериализации для упрощения обратной миграции в случае возникновения проблем.

В итоге код с новой реализацией в A/B-тесте выглядел примерно так:

fun Context.createPreferences(name: String, mode: Int = Context.MODE_PRIVATE): SharedPreferences =    if (isAsyncCommitAbTestEnabled()) {        getAsyncCommitSharedPrefs(this, name, mode)    } else {        getSharedPreferences(name, mode)    } 

Затем мы начали медленно раскатывать A/B-тест, следя за основными показателями. У нас достаточно хорошее покрытие продуктовыми и техническими метриками и есть инструменты, которые уведомляют разработчиков о значительных отклонениях в любой из них.

В результате мы не обнаружили никаких проблем, а общее количество ANR-ошибок уменьшилось примерно на 4% по сравнению с контрольной группой A/B теста. Неплохо, но это всё ещё выше порогового значения.

Обработка push-уведомлений

Поскольку мы не достигли своей цели, нам требовалось найти способы дальнейшего снижения ANR rate.

До этого мы выяснили, что существует практически линейная корреляция между длительностью запуска приложения и ANR rate. Скорее всего, дело в том, что большинство ANR-ошибок в нашем приложении возникало при обработке BroadcastReceiver, на стадии Application.onCreate. К сожалению, у нас больше не осталось простых способов ускорения запуска всё остальное требовало серьёзного рефакторинга и большого объёма работ.

В ходе анализа репортов мы также заметили, что большинство запусков нашего процесса выполнялось при обработке BroadcastReceiver для push-уведомлений. И у нас возникла идея: может быть, можно обрабатывать все уведомления в отдельном процессе, который не нуждается в инициализации компонентов, необходимых при обычном запуске приложения?

По умолчанию в Android ваше приложение выполняется внутри одного процесса. Когда вы кликаете по иконке, система создаёт для приложения процесс. В случае получения BroadcastReceiver-интента система запустит процесс, только если он ещё не запущен. Каждый раз при запуске процесса приложения Android вызывает метод Application.onCreate:

Но есть способы запустить некоторые части приложения в отдельных процессах. В таких случаях будут создаваться отдельные экземпляры класса Application для каждого процесса. Это может помочь нам в решении задачи, так как даёт возможность убрать практически всё содержимое метода Application.onCreate, перенеся в отдельный процесс только код, связанный с обработкой push-уведомлений. Это должно значительно ускорить обработку BroadcastReceiver и снизить вероятность возникновения ANR-ошибок:

Вы можете контролировать процесс, в котором будет запускаться компонент, с помощью AndroidManifest.xml. Например, для запуска BroadcastReceiver в нестандартном процессе нужно добавить название процесса в тег receiver с помощью атрибута android:process. Но как это сделать, если мы используем внешнюю библиотеку вроде Firebase Cloud Messaging?

Есть специальные теги, которые контролируют процесс объединения манифестов из библиотек. Можно пропатчить исходное объявление манифеста FCM BroadcastReceiver с помощью атрибута tools:node=replace. Помимо FCM BroadcastReceiver, за обработку push-уведомлений отвечает ещё и FirebaseMessagingService, и нам нужно запускать его в том же процессе. В итоге нужно добавить в манифест следующие записи:

<serviceandroid:name="com.google.firebase.messaging.FirebaseMessagingService"android:exported="false"android:process=":light"tools:node="replace">  <intent-filter android:priority="-500">  <action android:name="com.google.firebase.MESSAGING_EVENT" />  </intent-filter></service><receiverandroid:name="com.google.firebase.iid.FirebaseInstanceIdReceiver"android:exported="true"android:permission="com.google.android.c2dm.permission.SEND"android:process=":light"tools:node="replace">  <intent-filter>  <action android:name="com.google.android.c2dm.intent.RECEIVE" />  </intent-filter></receiver> 

Теперь, когда сервисы Google Play отправляют broadcast с новым сообщением, мы можем выключить обычную инициализацию в Application.onCreate, проверив, находимся ли мы в главном процессе:

class Application {override fun onCreate() {if (isMainProcess) {// perform usual initialization}}}

Есть много способов имплементации этой проверки. Один из них можно посмотреть здесь.

Если вы не делаете ничего особенного с push-уведомлениями, то, вероятнее всего, этого будет достаточно и всё будет работать из коробки. Ваш код, отвечающий за отображение уведомлений, будет исполняться в отдельном процессе, а Activity из PendingIntent будут запускаться в основном.

После того как мы это реализовали, уведомления стали отображаться значительно быстрее:

Мы выпустили обновление с этими изменениями и начали постепенно его раскатывать, следя за основными метриками.

Примерно через неделю большинство наших пользователей обновили приложение и вот что мы получили:

• доля ANR-ошибок в Badoo уменьшилась с 0,8% до 0,41% и в конце концов стала ниже, чем у пиров*, достигнув отметки в 0,28%:

*в Google Play имеется возможность выбрать произвольный набор приложений-пиров и выполнять сравнение ваших метрик с медианой пиров.

• абсолютное количество ANR-ошибок в день уменьшилось более чем вдвое.

Хотя в нашем случае эти изменения сильно повлияли на ANR rate, стоит иметь в виду несколько вещей, прежде чем реализовывать что-то похожее в своём приложении:

• Разработчики FCM библиотек могли не предусматривать изменение её поведения с помощью патчинга манифеста и работу в отдельном процессе. Это не описано в официальной документации, так что есть риск, что в любой момент этот функционал может быть сломан, поэтому он требует тщательного тестирования после каждого обновления библиотек.

• Обновлять FCM-библиотеки нужно крайне осторожно, так как при каждом обновлении необходимо проверять, соответствуют ли записи пропатченного XML-манифеста исходным.

• Добавление дополнительного процесса требует больше ресурсов памяти и процессора

Учитывая всё это, я рекомендую использовать этот подход только в качестве крайней меры или временного решения. Если у вас есть возможность ускорить запуск приложения, то лучше сосредоточиться на этом, потому что это поможет не только снизить ANR rate, но и уменьшить длительность холодного запуска.

Общие результаты

В результате всех изменений мы уменьшили ANR rate и общее количество ANR-ошибок примерно в шесть раз:

Надеюсь, наш опыт поможет вам снизить ANR rate и повысить качество вашего приложения.

Кто сталкивался с интересными багами, связанными с ANR? Расскажите о своём опыте в комментариях :)

Ссылки

1. Методы управления трассировщиком

2. Статья Snap Engineering про переписывание приложения

3. Описание внутреннего устройства SharedPreferences

4. Исходный код SharedPreferences

5. Библиотека для выполнения инициализации в разных процессах

Пожалуй, одна из худших проблем, которая может случиться с вашим приложением, ошибка ANR (Application Not Responding), когда приложение не отвечает. Если таких ошибок много, они могут негативно влиять не только на пользовательский опыт, но и на позицию в выдаче Google Play и фичеринг.

В начале прошлого года количество ANRs в приложении Badoo превышало порог Bad Behaviour в Google Play. Поэтому мы собрали команду для решения этой проблемы и потратили несколько месяцев, экспериментируя с разными подходами. В результате мы смогли уменьшить количество таких ошибок более чем в шесть раз.

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

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

Что такое ошибка ANR?

Обычно любое приложение с графическим интерфейсом выполняет все связанные с ним операции и отрисовку в отдельном UI-потоке исполнения. Android не исключение: здесь в главном потоке приложения выполняется цикл, отвечающий за все действия с интерфейсом:

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

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

Когда UI-поток Android-приложения блокируется слишком долго, выдаётся ошибка Application Not Responding (ANR).

ANR выдаётся, когда приложение находится в одном из этих состояний:

на переднем плане находится Activity, приложение в течение пяти секунд не отвечает на входящие события или BroadcastReceiver, например нажатия на кнопки или касания экрана;

на переднем плане нет Activity, ваш BroadcastReceiver не закончил исполнение в течение длительного времени.

Если ANR случается, когда на переднем плане находится Activity вашего приложения, Android показывает диалоговое окно с предложением закрыть приложение или подождать.

Довольно легко принудительно вызвать ANR, написав Thread.sleep() в любом обработчике интерфейса, например обработчик нажатия кнопки. После нажатия на кнопку вы увидите примерно следующее:

Наличие ошибок ANR в вашем приложении не только влияет на опыт его использования, но и, согласно документации Google, может повлиять на позицию в поисковой выдаче и продвижение в Google Play.

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

Давайте посмотрим, какие существуют способы отладки ANR-ошибок и какие инструменты могут быть в этом полезны.

Отслеживание ANR

Локальный анализ

Самый простой случай если у вас есть возможность стабильно воспроизводить ANR-проблему локально. Существует довольно много инструментов, которые могут помочь вам быстро найти источник проблемы.

Первое, что можно сделать, это проверить дамп стек-трейсов для всех потоков (thread dump). Когда приложение перестает отвечать, Android создаёт дамп всех текущих потоков, который может помочь в анализе проблемы. Обычно он находится в директории /data/anr/, точный путь можно найти в Logcat сразу после сообщения об ошибке ANR.

Дамп потоков содержит стек-трейсы: вы увидите, в каком состоянии был каждый поток (например, какая строка выполнялась в конкретный момент времени). По сути, это состояние приложения на момент создания дампа.

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

Отслеживание с помощью Google Play

Google Play автоматически отправляет отчёты об ошибках ANR, если у пользователя включена такая опция. В консоли Google Play есть несколько метрик и инструментов для анализа ANR.

Во-первых, можно увидеть агрегированные графики с общим количеством ANR-ошибок за день. Также есть такая метрика, как ANR rate отношение количества сессий за день, в которых возникала хотя бы одна ANR-ошибка, к общему количеству сессий за сутки. Для этой метрики задан порог в 0,47%, превышение которого считается неудовлетворительным поведением (Bad Behaviour) и может плохо повлиять на позицию приложения в Google Play.

Во-вторых, можно открывать отдельные отчёты об ANR-ошибках, сгруппированные по схожести на основе стек-трейса. Основные группы находятся в разделе Android Vitals. И это, вероятно, наиболее полезный раздел для выявления самых частых причин возникновения ANR-ошибок в вашем приложении.

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

Всё это иногда затрудняет определение основных ошибок и поиск изначальных проблем. Что же можно сделать для улучшения ситуации?

Скачивание данных из Google Play

Для решения проблемы с логикой группировки можно попробовать скачать сырые отчёты об ANR-ошибках из Google Play для последующего ручного анализа. Раньше была возможность выгрузить эти данные из Google Cloud Storage, но несколько лет назад Google перестала поддерживать этот функционал:

Однако всё ещё можно просматривать отдельные отчёты в консоли. Но как нам экспортировать тысячи отчётов, не потратив при этом кучу времени на рутинную работу?

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

Веб-скрапер можно реализовать с помощью популярного инструмента Selenium, который предоставляет простой интерфейс для взаимодействия с веб-страницами. Изначально он предназначался для создания автоматизированных тестов для веб-приложений и доступен на разных языках, включая Java и Kotlin.

Мы реализовали скрапер на Selenium и получили сырые отчёты об ANR-ошибках для одного из релизов. Благодаря этому нам удалось проанализировать их так, как не получилось бы сделать с помощью встроенных в консоль Google Play инструментов. Например, просто поискав в отчётах по ключевым словам Application.onCreate, мы обнаружили, что около 60% ошибок произошло во время выполнения метода Application.onCreate. При этом в консоли Google Play нет возможности получить такую информацию, так как отчёты разбиты по группам.

Внутренняя аналитика

Другой способ сбора дополнительных данных и проведения расширенного анализа заключается в настройке собственного репортинга ANR-ошибок. В прошлом мы уже экспериментировали с решением похожих проблем, настраивая репортинг крашей. Для того чтобы проводить анализ падений приложения, мы создали внутренний инструмент Gelato.

Его функциональность схожа с возможностями других инструментов для краш-репортинга, таких как Firebase Crashlytics и App Center, но ещё и позволяет нам полностью контролировать сохраняемые данные, менять логику группировки и применять сложную фильтрацию:

Мы решили отслеживать в Gelato ещё и ANR-ошибки в надежде, что это поможет нам в поиске их причин. Для этого нам нужно было знать, когда приложение перестаёт отвечать. В Android 11 появился новый API, предоставляющий информацию о недавних причинах завершения процесса, но у большинства наших пользователей установлены более ранние версии ОС, поэтому нам требовалось найти другое решение.

И мы нашли простой способ, который часто используется для отслеживания зависаний главного потока исполнения: запустить watchdog-поток, который периодически будет пытаться выполнить задачу в главном потоке. Если задача не выполняется за определённый промежуток времени, то можно сохранить дамп текущего состояния потоков и отправить его в наш инструмент для анализа отчётов о падениях:

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

Вот пример отчёта в нашей системе:

Полезный совет: собирайте и отправляйте вместе с отчётом лог событий аналитики. Иногда это даёт возможность буквально пошагово воспроизвести проблему.

Если у вас нет своего решения для сбора отчётов о падениях приложения, вы можете настроить репортинг и в сторонние инструменты. Например, можно отправлять ANR-ошибки в App Center или Firebase Crashlytics, так как они предоставляют API для отправки кастомных крашей.

Но помните, что все эти отчёты нельзя считать полной альтернативой ANR-отчётам в Google Play (как мы говорили выше, в Android немного другие правила определения таких ошибок). Но в любом случае это может помочь получить общее представление об основных проблемах. Вполне вероятно, что если генерируется много отчётов о зависании главного потока исполнения в какой-то части вашего приложения, то в ней происходят и ANR-ошибки.

В завершение

Мы обсудили, что представляют собой ANR-ошибки и как их можно отслеживать. Во второй части статьи я расскажу о наших подходах к снижению ANR rate и о том, что из этого получилось.

Ссылки

1. Android Vitals в Google Play: https://developer.android.com/distribute/best-practices/develop/android-vitals

2. Отладка ANR: https://developer.android.com/topic/performance/vitals/anr

3. API для получения причин завершения процесса: https://developer.android.com/reference/kotlin/android/app/ActivityManager#gethistoricalprocessexitreasons

4. Фреймворк для тестирования веб-страниц: https://www.selenium.dev/

5. Библиотека для определения зависаний: https://github.com/SalomonBrys/ANR-WatchDog

Отыщи всему начало, и ты многое поймёшь (Козьма Прутков).

Меня зовут Руслан, я релиз-инженер в Badoo и Bumble. Недавно я столкнулся с необходимостью оптимизировать механизм автомерджа в мобильных проектах. Задача оказалась интересной, поэтому я решил поделиться её решением с вами. В статье я расскажу, как у нас раньше было реализовано автоматическое слияние веток Git и как потом мы увеличили пропускную способность автомерджа и сохранили надёжность процессов на прежнем высоком уровне.

Свой автомердж

Многие программисты ежедневно запускают git merge, разрешают конфликты и проверяют свои действия тестами. Кто-то автоматизирует сборки, чтобы они запускались автоматически на отдельном сервере. Но решать, какие ветки сливать, всё равно приходится человеку. Кто-то идёт дальше и добавляет автоматическое слияние изменений, получая систему непрерывной интеграции (Continuous Integration, или CI).

Например, GitHub предлагает полуручной режим, при котором пользователь с правом делать записи в репозиторий может поставить флажок Allow auto-merge (Разрешить автомердж). При соблюдении условий, заданных в настройках, ветка будет соединена с целевой веткой. Bitbucket поддерживает большую степень автоматизации, накладывая при этом существенные ограничения на модель ветвления, имена веток и на количество мерджей.

Такой автоматизации может быть достаточно для небольших проектов. Но с увеличением количества разработчиков и веток, ограничения, накладываемые сервисами, могут существенно повлиять на производительность CI. Например, раньше у нас была система мерджа, при которой основная ветка всегда находилась в стабильном состоянии благодаря последовательной стратегии слияний. Обязательным условием слияния была успешная сборка при наличии всех коммитов основной ветки в ветке разработчика. Работает эта стратегия надёжно, но у неё есть предел, определяемый временем сборки. И этого предела оказалось недостаточно. При времени сборки в 30 минут на обработку 100 слияний в день потребовалось бы более двух суток. Чтобы исключить ограничения подобного рода и получить максимальную свободу выбора стратегий мерджа и моделей ветвления, мы создали собственный автомердж.

Итак, у нас есть свой автомердж, который мы адаптируем под нужды каждой команды. Давайте рассмотрим реализацию одной из наиболее интересных схем, которую используют наши команды Android и iOS.

Термины

Main. Так я буду ссылаться на основную ветку репозитория Git. И коротко, и безопасно. =)

Сборка. Под этим будем иметь в виду сборку в TeamCity, ассоциированную с веткой Git и тикетом в трекере Jira. В ней выполняются как минимум статический анализ, компиляция и тестирование. Удачная сборка на последней ревизии ветки в сочетании со статусом тикета To Merge это однo из необходимых условий автомерджа.

Пример модели ветвления

Испробовав разные модели ветвления в мобильных проектах, мы пришли к следующему упрощённому варианту:

На основе ветки main разработчик создаёт ветку с названием, включающим идентификатор тикета в трекере, например PRJ-k. По завершении работы над тикетом разработчик переводит его в статус Resolved. При помощи хуков, встроенных в трекер, мы запускаем для ветки тикета сборку. В определённый момент, когда изменения прошли ревью и необходимые проверки автотестами на разных уровнях, тикет получает статус To Merge, его забирает автоматика и отправляет в main.

Раз в неделю на основе main мы создаём ветку релиза release_x.y.z, запускаем на ней финальные сборки, при необходимости исправляем ошибки и наконец выкладываем результат сборки релиза в App Store или Google Play. Все фазы веток отражаются в статусах и дополнительных полях тикетов Jira. В общении с Jira помогает наш клиент REST API.

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

Первая версия: жадная стратегия

Сначала мы шли от простого и очевидного. Брали все тикеты, находящиеся в статусе To Merge, выбирали из них те, для которых есть успешные сборки, и отправляли их в main командой git merge, по одной.

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

Наличие в TeamCity актуальной успешной сборки мы проверяли при помощи метода REST API getAllBuilds примерно следующим образом (псевдокод):

haveFailed = False # Есть ли неудачные сборкиhaveActive = False # Есть ли активные сборки# Получаем сборки типа buildType для коммита commit ветки branchbuilds = teamCity.getAllBuilds(buildType, branch, commit)# Проверяем каждую сборкуfor build in builds:  # Проверяем каждую ревизию в сборке  for revision in build.revisions:    if revision.branch is branch and revision.commit is commit:      # Сборка актуальна      if build.isSuccessful:        # Сборка актуальна и успешна        return True      else if build.isRunning or build.isQueued        haveActive = True      else if build.isFailed:        haveFailed = Trueif haveFailed:  # Исключаем тикет из очереди, переоткрывая его  ticket = Jira.getTicket(branch.ticketKey)  ticket.reopen("Build Failed")  return Falseif not haveActiveBuilds:  # Нет ни активных, ни упавших, ни удачных сборок. Запускаем новую  TriggerBuild(buildType, branch)

Ревизии это коммиты, на основе которых TeamCity выполняет сборку. Они отображаются в виде 16-ричных последовательностей на вкладке Changes (Изменения) страницы сборки в веб-интерфейсе TeamCity. Благодаря ревизиям мы можем легко определить, требуется ли пересборка ветки тикета или тикет готов к слиянию.

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

Так как после перевода тикета в статус готовности (в нашем примере Resolved) соответствующая ветка, как правило, не меняется, то и сборка, ассоциированная с тикетом, чаще всего остаётся актуальной. Кроме того, сам факт нахождения тикета в статусе To Merge говорит о высокой вероятности того, что сборка не упала. Ведь при падении сборки мы сразу переоткрываем тикет.

На первый взгляд, дальнейшие действия кажутся очевидными: взять все готовые тикеты с актуальными сборками и соединять main с ними по одному. В первой версии автомерджа мы так и сделали.

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

Конфликты слияния

Если изменить одну и ту же строку кода в разных ветках и попытаться соединить их в main, то Git попросит разрешить конфликты слияния. Из двух вариантов нужно выбрать один и закоммитить изменения.

Это должно быть знакомо практически каждому пользователю системы контроля версий (VCS). Процессу CI, так же, как и любому пользователю VCS, нужно разрешать конфликты. Правда, делать это приходится немного вслепую, в условиях почти полного непонимания кодовой базы.

Если команда git merge завершилась с ошибкой и для всех файлов в списке git ls-files --unmerged заданы обработчики конфликтов, то для каждого такого файла мы выполняем парсинг содержимого по маркерам конфликтов <<<<<<<, ======= и >>>>>>>. Если конфликты вызваны только изменением версии приложения, то, например, выбираем последнюю версию между локальной и удалённой частями конфликта.

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

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

Логические конфликты

А может ли случиться так, что, несмотря на успешность сборок пары веток в отдельности, после слияния их с main сборка на основной ветке упадёт? Практика показывает, что может. Например, если сумма a и b в каждой из двух веток не превышает 5, то это не гарантирует того, что совокупные изменения a и b в этих ветках не приведут к большей сумме.

Попробуем воспроизвести это на примере Bash-скрипта test.sh:

#!/bin/bashget_a() {    printf '%d\n' 1}get_b() {    printf '%d\n' 2}check_limit() {    local -i value="$1"    local -i limit="$2"    if (( value > limit )); then        printf >&2 '%d > %d%s\n' "$value" "$limit"        exit 1    fi}limit=5a=$(get_a)b=$(get_b)sum=$(( a + b ))check_limit "$a" "$limit"check_limit "$b" "$limit"check_limit "$sum" "$limit"printf 'OK\n'

Закоммитим его и создадим пару веток: a и b.
Пусть в первой ветке функция get_a() вернёт 3, а во второй get_b() вернёт 4:

diff --git a/test.sh b/test.shindex f118d07..39d3b53 100644--- a/test.sh+++ b/test.sh@@ -1,7 +1,7 @@ #!/bin/bash get_a() {-    printf '%d\n' 1+    printf '%d\n' 3 } get_b() {git diff main bdiff --git a/test.sh b/test.shindex f118d07..0bd80bb 100644--- a/test.sh+++ b/test.sh@@ -5,7 +5,7 @@ get_a() { }  get_b() {-    printf '%d\n' 2+    printf '%d\n' 4 }  check_limit() {

В обоих случаях сумма не превышает 5 и наш тест проходит успешно:

git checkout a && bash test.shSwitched to branch 'a'OKgit checkout b && bash test.shSwitched to branch 'b'OK

Но после слияния main с ветками тесты перестают проходить, несмотря на отсутствие явных конфликтов:

git merge a bFast-forwarding to: aTrying simple merge with bSimple merge did not work, trying automatic merge.Auto-merging test.shMerge made by the 'octopus' strategy. test.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)bash test.sh7 > 5

Было бы проще, если бы вместо get_a() и get_b() использовались присваивания: a=1; b=2, заметит внимательный читатель и будет прав. Да, так было бы проще. Но, вероятно, именно поэтому встроенный алгоритм автомерджа Git успешно обнаружил бы конфликтную ситуацию (что не позволило бы продемонстрировать проблему логического конфликта):

git merge a Updating 4d4f90e..8b55df0Fast-forward test.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)git merge b Auto-merging test.shCONFLICT (content): Merge conflict in test.shRecorded preimage for 'test.sh'Automatic merge failed; fix conflicts and then commit the result.

Разумеется, на практике конфликты бывают менее явными. Например, разные ветки могут полагаться на API разных версий какой-нибудь библиотеки зависимости, притом что более новая версия не поддерживает обратной совместимости. Без глубоких знаний кодовой базы (читай: без разработчиков проекта) обойтись вряд ли получится. Но ведь CI как раз и нужен для решения таких проблем.

Конечно, от разрешения конфликта мы никуда не уйдём кто-то должен внести правки. Но чем раньше нам удастся обнаружить проблему, тем меньше людей будет привлечено к её решению. В идеале потребуется озадачить лишь разработчика одной из конфликтующих веток. Если таких веток две, то одна из них вполне может быть соединена с main.

Превентивные меры

Итак, главное не допустить попадания логического конфликта в main. Иначе придётся долго и мучительно искать источник ошибок, а затем программиста, который проблему должен или может решить. Причём делать это нужно максимально быстро и качественно, чтобы, во-первых, не допустить задержки релиза и во-вторых, избежать в новых ветках логических конфликтов, основанных на уже выявленном конфликте. Такие конфликты часто приводят к неработоспособности большой части приложения или вовсе блокируют его запуск.

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

Вторая версия: последовательная стратегия

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

Git, по идее, как раз и является средством синхронизации. Но порядок попадания веток в main и, наоборот, main в ветки определяем мы сами. Чтобы определить точно, какие из веток вызывают проблемы в main, можно попробовать отправлять их туда по одной. Тогда можно выстроить их в очередь, а порядок организовать на основе времени попадания тикета в статус To Merge в стиле первый пришёл первым обслужен.

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

Работает схема надёжно и предсказуемо. Благодаря обязательной синхронизации с main и последующей пересборке конфликты между ветками удаётся выявлять сразу, до попадания их в main. Раньше же нам приходилось разрешать конфликт уже после слияния релиза со множеством веток, большая часть из которых к этому конфликту отношения не имела. Кроме того, предсказуемость алгоритма позволила нам показать очередь тикетов в веб-интерфейсе, чтобы можно было примерно оценить скорость попадания их веток в main.

Но есть у этой схемы существенный недостаток: пропускная способность автомерджа линейно зависит от времени сборки. При среднем времени сборки iOS-приложения в 25 минут мы можем рассчитывать на прохождение максимум 57 тикетов в сутки. В случае же с Android-приложением требуется примерно 45 минут, что ограничивает автомердж 32 тикетами в сутки, а это даже меньше количества Android-разработчиков в нашей компании.

На практике время ожидания тикета в статусе To Merge составляло в среднем 2 часа 40 минут со всплесками, доходящими до 10 часов! Необходимость оптимизации стала очевидной. Нужно было увеличить скорость слияний, сохранив при этом стабильность последовательной стратегии.

Финальная версия: сочетание последовательной и жадной стратегий

Разработчик команды iOS Дамир Давлетов предложил вернуться к идее жадной стратегии, при этом сохранив преимущества последовательной.

Давайте вспомним идею жадной стратегии: мы сливали все ветки готовых тикетов в main. Основной проблемой было отсутствие синхронизации между ветками. Решив её, мы получим быстрый и надёжный автомердж!

Раз нужно оценить общий вклад всех тикетов в статусе To Merge в main, то почему бы не слить все ветки в некоторую промежуточную ветку Main Candidate (MC) и не запустить сборку на ней? Если сборка окажется успешной, то можно смело сливать MC в main. В противном случае придётся исключать часть тикетов из MC и запускать сборку заново.

Как понять, какие тикеты исключить? Допустим, у нас n тикетов. На практике причиной падения сборки чаще всего является один тикет. Где он находится, мы не знаем все позиции от 1 до n являются равноценными. Поэтому для поиска проблемного тикета мы делим n пополам.

Так как место тикета в очереди определяется временем его попадания в статус To Merge, имеет смысл брать ту половину, в которой расположены тикеты с большим временем ожидания.

Следуя этому алгоритму, для k проблемных тикетов в худшем случае нам придётся выполнить O(k*log2(n)) сборок, прежде чем мы обработаем все проблемные тикеты и получим удачную сборку на оставшихся.

Вероятность благоприятного исхода велика. А ещё в то время, пока сборки на ветке MC падают, мы можем продолжать работу при помощи последовательного алгоритма!

Итак, у нас есть две автономные модели автомерджа: последовательная (назовём её Sequential Merge, или SM) и жадная (назовём её Greedy Merge, или GM). Чтобы получить пользу от обеих, нужно дать им возможность работать параллельно. А параллельные процессы требуют синхронизации, которой можно добиться либо средствами межпроцессного взаимодействия, либо неблокирующей синхронизацией, либо сочетанием этих двух методов. Во всяком случае, мне другие методы неизвестны.

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

Остаётся предотвратить все возможные случаи состояний гонки. Их много, но для понимания сути приведу несколько самых важных:

1. SM-SM и GM-GM: между командами одного типа.

2. SM-GM: между SM и GM в рамках одного репозитория.

Первая проблема легко решается при помощи мьютекса по токену, включающему в себя имя команды и название репозитория. Пример: lock_${command}_${repository}.

Поясню, в чём заключается сложность второго случая. Если SM и GM будут действовать несогласованно, то может случиться так, что SM соединит main с первым тикетом из очереди, а GM этого тикета не заметит, то есть соберёт все остальные тикеты без учёта первого. Например, если SM переведёт тикет в статус In Master, а GM будет всегда выбирать тикеты по статусу To Merge, то GM может никогда не обработать тикета, соединённого SM. При этом тот самый первый тикет может конфликтовать как минимум с одним из других.

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

Таким образом, мы получили своего рода неблокирующую синхронизацию.

Немного о TeamCity

В процессе реализации GM нам предстояло обработать много нюансов, которыми я не хочу перегружать статью. Но один из них заслуживает внимания. В ходе разработки я столкнулся с проблемой зацикливания команды GM: процесс постоянно пересобирал ветку MC и создавал новую сборку в TeamCity. Проблема оказалась в том, что TeamCity не успел скачать обновления репозитория, в которых была ветка MC, созданная процессом GM несколько секунд назад. К слову, интервал обновления репозитория в TeamCity у нас составляет примерно 30 секунд.

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

Кто-то посчитает решение очевидным, но я нашёл его не сразу. Оказывается, прикрепить ревизию к сборке при её добавлении в очередь можно при помощи параметра lastChanges метода addBuildToQueue:

<lastChanges>  <change    locator="version:{{revision}},buildType:(id:{{build_type}})"/></lastChanges>

В этом примере {{revision}} заменяется на 16-ричную последовательность коммита, а {{build_type}} на идентификатор конфигурации сборки. Но этого недостаточно, так как TeamCity, не имея информации о новом коммите, может отказать нам в запросе.

Для того чтобы новый коммит дошёл до TeamCity, нужно либо подождать примерно столько, сколько указано в настройках конфигурации корня VCS, либо попросить TeamCity проверить наличие изменений в репозитории (Pending Changes) при помощи метода requestPendingChangesCheck, а затем подождать, пока TeamCity скачает изменения, содержащие наш коммит. Проверка такого рода выполняется посредством метода getChange, где в changeLocator нужно передать как минимум сам коммит в качестве параметра локатора version. Кстати, на момент написания статьи (и кода) на странице ChangeLocator в официальной документации описание параметра version отсутствовало. Быть может, поэтому я не сразу узнал о его существовании и о том, что это 40-символьный 16-ричный хеш коммита.

Псевдокод:

teamCity.requestPendingChanges(buildType)attempt = 1while attempt <= 20:  response = teamCity.getChange(commit, buildType)  if response.commit == commit:    return True # Дождались  sleep(10)return False

О предельно высокой скорости слияний

У жадной стратегии есть недостаток на поиск ветки с ошибкой может потребоваться много времени. Например, 6 сборок для 20 тикетов у нас может занять около трёх часов. Можно ли устранить этот недостаток?

Допустим, в очереди находится 10 тикетов, среди которых только 6-й приводит к падению сборки.

Согласно жадной стратегии, мы пробуем собрать сразу все 10 тикетов, что приводит к падению сборки. Далее собираем левую половину (с 1 по 5) успешно, так как тикет с ошибкой остался в правой половине.

Если бы мы сразу запустили сборку на левой половине очереди, то не потеряли бы времени. А если бы проблемным оказался не 6-й тикет, а 4-й, то было бы выгодно запустить сборку на четверти длины всей очереди, то есть на тикетах с 1 по 3, например.

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

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

Примерно такой же алгоритм реализован в премиум-функции GitLab под названием Merge Trains. Перевода этого названия на русский язык я не нашёл, поэтому назову его Поезда слияний. Поезд представляет собой очередь запросов на слияние с основной веткой (merge requests). Для каждого такого запроса выполняется слияние изменений ветки самого запроса с изменениями всех запросов, расположенных перед ним (то есть запросов, добавленных в поезд ранее). Например, для трёх запросов на слияние A, B и С GitLab создаёт следующие сборки:

1. Изменения из А, соединённые с основной веткой.

2. Изменения из A и B, соединённые с основной веткой.

3. Изменения из A, B и C, соединённые с основной веткой.

Если сборка падает, то соответствующий запрос из очереди удаляется, а сборки всех предыдущих запросов перезапускаются (без учёта удалённого запроса).

GitLab ограничивает количество параллельно работающих сборок двадцатью. Все остальные сборки попадают в очередь ожидания вне поезда. Как только сборка завершает работу, её место занимает очередная сборка из очереди ожидания.

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

Но если преград человеческой мысли нет, то пределы аппаратных ресурсов видны достаточно отчётливо:

1. Каждой сборке нужен свой агент в TeamCity.

2. В нашем случае у сборки мобильного приложения есть порядка 15-100 сборок-зависимостей, каждой из которых нужно выделить по агенту.

3. Сборки автомерджа мобильных приложений в main составляют лишь малую часть от общего количества сборок в TeamCity.

Взвесив все плюсы и минусы, мы решили пока остановиться на алгоритме SM + GM. При текущей скорости роста очереди тикетов алгоритм показывает хорошие результаты. Если в будущем заметим возможные проблемы с пропускной способностью, то, вероятно, пойдём в сторону Merge Trains и добавим пару параллельных сборок GM:

1. Вся очередь.

2. Левая половина очереди.

3. Левая четверть очереди.

Что в итоге получилось

В результате применения комбинированной стратегии автомерджа нам удалось добиться следующего:

• уменьшение среднего размера очереди в 2-3 раза;

• уменьшение среднего времени ожидания в 4-5 раз;

• мердж порядка 50 веток в день в каждом из упомянутых проектов;

• увеличение пропускной способности автомерджа при сохранении высокого уровня надёжности, то есть мы практически сняли ограничение на количество тикетов в сутки.

Примеры графиков слияний за несколько дней:

Количество тикетов в очереди до и после внедрения нового алгоритма:

Среднее количество тикетов в очереди (AVG) уменьшилось в 2,5 раза (3,95/1,55).

Время ожидания тикетов в минутах:

Среднее время ожидания (AVG) уменьшилось в 4,4 раза (155,5/35,07).

У нас в Badoo довольно много клиентских приложений. Помимо основных продуктов Badoo и Bumble, у которых есть как веб-версии (десктопная и мобильная), так и клиенты под нативные платформы (Android и iOS), ещё есть с десяток внутренних инструментов со своими UI. Для сбора клиентских ошибок мы используем собственную разработку под кодовым названием Gelatо. Последние два года я работал над её серверной частью и за это время открыл для себя много нового из мира разработки Error Tracking систем.

Поэтому, если вам интересно узнать, что из себя представляет разработка системы сбора клиентских ошибок и о чём стоит подумать, если вы решите разрабатывать собственную, добро пожаловать под кат.

Что вас ждёт:

• я расскажу, как мы работаем с ошибками, какие инструменты использовали раньше и почему разработали свою систему, а не выбрали готовое решение.

• дам краткий обзор нашей системы, её архитектуры и технологического стека;

• перечислю особенности, которые нужно учитывать, если вы решите разрабатывать свою систему сбора клиентских ошибок.

Как мы используем информацию об ошибках

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

Второе проводим анализ ошибок. Мы в Badoo релизимся довольно часто:

веб-приложения: один-два раза в день, включая серверную часть;

нативные приложения: раз в неделю (хотя многое зависит от того, как быстро билд примут в App Store и Google Play).

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

Третье. Информация об ошибках, собранная в одном месте, значительно упрощает работу разработчиков и QA-инженеров.

Что использовали раньше

Исторически для сбора клиентских ошибок в Badoo использовались две системы: HockeyApp для сбора краш-репортов из нативных приложений и самописная система для сбора JS-ошибок.

HockeyApp

HockeyApp полностью удовлетворяла наши потребности, до тех пор пока в 2014 году её не приобрела Microsoft и не начала менять политику использования, чтобы подтолкнуть людей к переходу на свою систему App Center. App Center на тот момент нашим требованиям не соответствовала: она находилась на стадии активной разработки, и часть необходимой нам функциональности отсутствовала, в частности деобфускация стек-трейсов Android-приложений с использованием DexGuard mapping-файлов, без которой невозможна группировка ошибок. О деобфускации я расскажу ниже; если вы слышите об этом впервые, значит, точно узнаете что-то новое.

Microsoft установила дедлайн 16 октября 2019 года, к этому дню все пользователи HockeyApp должны были мигрировать в App Center. К слову, поддержка DexGuard появилась в App Center лишь в конце декабря 2019 года, спустя несколько месяцев после официального закрытия HockeyApp.

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

Наша система для сбора JS-ошибок

Что касается самописной системы для сбора JS-ошибок, то долгие годы она работала без нареканий, хотя обладала лишь базовой функциональностью.

Архитектура у неё была довольно простой:

• данные хранились в MySQL (мы хранили информацию о последних 1020 релизах);

• для каждой версии приложения была отдельная таблица;

• работал поиск по фиксированному набору полей средствами MySQL, плюс мы использовали Sphinx для полнотекстового поиска.

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

Собрав и проанализировав все требования, мы поняли, что обойтись малой кровью не получится. Система, которая разрабатывалась в 2014 году, морально устарела, и затраты на её рефакторинг превысили бы стоимость внедрения нового решения.

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

Требования к новой системе

• Хранение всех клиентских ошибок в одном месте.

• Хранение событий минимум за полгода без семплирования. При исследовании фантомного бага (бага, у которого нет чёткого сценария воспроизведения) возможность посмотреть ошибки для конкретного пользователя в определённый момент времени может значительно облегчить жизнь инженера. Поэтому чем больше информации мы можем хранить, тем лучше.

• Лёгкое масштабирование. Периодически случаются ошибки, которые порождают миллионы событий. Система должна быть способна обработать такой поток данных.

• Отказоустойчивость чтобы минимизировать риск потери данных.

• Способность давать ответ не только на вопрос Сколько произошло ошибок?, но и на вопрос Сколько пользователей это затронуло?.

• Группировка похожих ошибок с сохранением мета-информации (время первой и последней ошибки в группе, в каком релизе появилась ошибка, статус ошибки и т. п.).

• Гибкий поиск по любой комбинации полей с поддержкой полнотекстового поиска.

• Разнообразная статистика: количество ошибок за период, количество ошибок в разбивке по релизам, по браузерам, по операционным системам и т. п.

• Интеграция с Jira. Наша разработка ведётся с использованием Jira, поэтому нам необходима возможность создавать тикеты для определённых ошибок.

• Self-hosted. Мы хотим, чтобы система работала на нашем железе. Это обеспечит нам полный контроль над данными и возможность в любой момент изменить конфигурацию кластера.

Почему мы не выбрали готовое решение

Конечно, прежде чем писать своё решение, мы проанализировали существующие на рынке системы.

Платные сервисы

Сбором клиентских ошибок занимаются многие SaaS-решения, и это неудивительно: быстрое обнаружение и исправление ошибок один из ключевых аспектов современной разработки. Среди самых популярных решений можно выделить Bugsnag, TrackJS, Raygun, Rollbar и Airbrake. Все они обладают богатым функционалом и в целом соответствуют нашим требованиям, но мы не рассматривали облачные решения: не было уверенности в том, что ценовая политика и политика использования со временем не изменятся, как это случилось с HockeyApp. А миграция на новое решение довольно сложная и длительная процедура.

Open-source-решения

С open-source-системами всё было не так радужно. Большинство из них либо перестали развиваться, либо так и не вышли из стадии разработки и были непригодны для использования в продакшене.

Фактически лишь Sentry продолжал активно развиваться и обладал функциональностью, покрывающей большую часть наших потребностей. Но на тот момент (начало 2018 года) восьмая версия сервиса не подошла нам по следующим причинам:

• вместо хранения всех событий в ней использовалось семплирование;

• в качестве базы данных использовалась PostgreSQL, с которой у нас не было опыта работы;

• были сложности с добавлением новой функциональности, так как система написана на Python, а наши основные языки PHP и Go;

• отсутствие части необходимой нам функциональности (например, интеграции с Jira).

В июле 2018 года вышла девятая версия Sentry, в которой появилась интеграция с issue-трекерами и был заложен фундамент для одного из ключевых, на мой взгляд, улучшений перехода на ClickHouse для хранения событий (рекомендую к прочтению серию статей об этом). Но к сожалению, на момент нашего ресёрча всего этого ещё не было даже в планах. Поэтому мы решили, что оптимальным вариантом в нашем случае будет реализация собственной системы, заточенной под наши процессы, которую легко интегрировать с другими внутренними продуктами.

Так на свет появилась система под кодовым названием Gelato (General Error Logs And The Others), о разработке которой и пойдёт речь дальше.

Краткий обзор системы

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

На главной странице находятся список приложений и общая статистика ошибок по заданному критерию.

Кликнув на то или иное приложение, мы попадём на страницу со статистикой по его релизам.

Кликнув на версию, мы попадём на страницу со списком ошибок.

Здесь можно узнать, какие ошибки произошли, сколько их было, сколько пользователей это затронуло, когда ошибка встретилась впервые и время последнего события. Также есть сортировка по большинству полей и возможность создания тикета в Jira для любой ошибки.

Так эта страница выглядит для нативных приложений:

Кликнув на ошибку, мы попадём на страницу с детальной информацией о ней.

Здесь доступны общая информация об ошибке (1), график общего количества ошибок (2) и различная аналитика (3).

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

Ещё одна интересная возможность, которую я не встречал в аналогичных системах, сравнение версий. Это позволяет довольно легко обнаруживать ошибки, которые появились в новой версии, и те, что были исправлены в прошлых релизах, но начали воспроизводиться снова спустя какое-то время (регресс).

Выбираем версии для сравнения:

И попадаем на страницу со списком ошибок, которые есть в одной версии и которых нет в другой:

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

• интеграция с нашим A/B-фреймворком для отслеживания ошибок, которые появились в том или ином сплит-тесте;

• система уведомлений о новых ошибках;

• расширенная аналитика (больше графиков и диаграмм);

• email-дайджесты со статистикой по приложениям.

Общая схема работы

Теперь поговорим о том, как всё устроено под капотом. Схема довольно стандартная и состоит из трёх этапов:

1. Сбор данных.

2. Обработка данных.

3. Хранение данных.

Схематически это можно изобразить следующим образом:

Давайте для начала разберёмся со сбором данных.

Сбор данных

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

Что входит в задачи API:

• прочитать данные;

• проверить данные на соответствие требуемому формату, чтобы сразу отсечь шум (чаще всего это запросы от мамкиных хакеров, которые натравили сканеры на наше API);

• сохранить всё в промежуточную очередь.

Для чего нужна промежуточная очередь?

Если полагаться на то, что у нас достаточно низкий EPS (errors per second), и на то, что все части нашей системы будут работать стабильно всё время, то можно значительно упростить систему и сделать весь процесс синхронным.

Но мы-то с вами знаем, что в реальном мире так не бывает и на каждом из этапов в самый неподходящий момент может произойти нечто непредвиденное. И к этому наша система должна быть готова. Так, ошибка в одной из внешних зависимостей приложения приведёт к тому, что оно начнёт крашиться, что повлечёт за собой рост EPS (как это было с iOS Facebook SDK 10 июля 2020 года). Как следствие, значительно увеличится нагрузка на всю систему, а вместе с этим и время обработки одного запроса.

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

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

Что можно использовать в качестве очереди?

1. Первое, что приходит в голову, популярные брокеры сообщений, например Redis или RabbitMQ.

2. Также можно использовать Apache Kafka, которая хорошо подходит для случаев, когда требуется хранить хвост входящих данных за определённый период (например, для какой-то внутренней аналитики). Kafka используется в частности в последней (десятой) версии Sentry.

3. Мы остановились на LSD (Live Streaming Daemon). По сути, это очередь на файлах. Система используется в Badoo довольно давно и хорошо себя зарекомендовала, плюс у нас в коде уже есть вся необходимая обвязка для работы с ней.

Хранение данных

Тут нужно ответить на два вопроса: Где хранить? (база данных) и Как хранить? (модель данных).

База данных

При реализации прототипа системы мы остановились на двух претендентах: Elasticsearch и ClickHouse.

Elasticsearch

Из очевидных плюсов данной системы можно выделить следующие:

• горизонтальное масштабирование и репликация из коробки;

• большой набор агрегаций, что удобно при реализации аналитической части нашей системы;

• полнотекстовый поиск;

• поддержка UPDATE по условию (процесс обработки данных у нас асинхронный, и нужна возможность выполнять некоторые шаги пайплайна повторно, а значит, и возможность обновлять определённые поля у конкретных событий);

• поддержка DELETE по условию (мы храним данные за полгода, а значит, нам нужна возможность удалять устаревшие данные);

• гибкая настройка через API, что позволяет разработчикам менять настройки индексов в зависимости от задач.

Конечно, как у любой системы, у Elasticsearch есть и недостатки:

• сложный язык запросов, поэтому документация всегда должна быть под рукой (в последних версиях появилась поддержка синтаксиса SQL, но это доступно только в платной версии (X-Pack) либо при использовании Open Distro от Amazon);

• JVM, которую нужно уметь готовить, в то время как наши основные языки это PHP и Go (например, для оптимизации сборщика мусора под определённый профиль нагрузки требуется глубокое понимание того, как всё работает под капотом; мы столкнулись с этой проблемой при обновлении с версии 6.8 до 7.5, благо тема не нова и есть довольно много статей в интернете (например, тут и тут));

• плохое сжатие строк; мы планируем хранить довольно много данных и, хотя железо с каждым годом дешевеет, хотим использовать ресурсы максимально эффективно (конечно, можно использовать deflate-сжатие вместо LZ4, но это увеличит потребление CPU, что может негативно сказаться на производительности всего кластера).

ClickHouse

Плюсы данной базы:

• отличная производительность на запись;

• хорошее сжатие данных, особенно длинных строк;

• MySQL-совместимый синтаксис запросов, что избавляет от необходимости учить новый язык запросов, как в случае с Elasticsearch;

• горизонтальное масштабирование и репликация из коробки, хоть это и требует больше усилий по сравнению с Elasticsearch.

Но на начало 2018 года в ClickHouse отсутствовала часть необходимых нам функций:

• Поддержка DELETE по условию (мы планировали хранить данные за полгода, поэтому нам была необходима возможность удаления устаревших данных; в ClickHouse удаление данных по произвольному критерию предусмотрено не было, а партиционирование по произвольному полю (в нашем случае по дате) на тот момент находилось на стадии экспериментальной фичи и не рекомендовалось к использованию в продакшене);

• поддержка UPDATE по условию: ClickHouse заточена под неизменяемые данные, поэтому реализация обновления произвольных записей задача не из лёгких (этот вопрос не раз поднимался на GitHub и в конце 2018 года функцию всё же реализовали, но она не подходит для частых обновлений);

• полнотекстовый поиск (была опция поиска по RegExp, но он требует сканирования всей таблицы (full scan), а это довольно медленная операция).

На самом деле, все упомянутые ограничения можно было обойти (и в Сети даже было несколько статей на эту тему (например)). Но мы хотели реализовать прототип нашей системы с минимальными затратами, и для этого нам требовалась более гибкая база данных, поэтому мы остановили свой выбор на Elasticsearch.

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

Модель данных

Теперь немного поговорим о том, как мы храним события.

Все данные у нас разбиты на несколько групп и хранятся в отдельных индексах:

• мета-информация;

• сырые события.

Данные изолированы в рамках конкретного приложения (отдельный индекс) это позволяет кастомизировать настройки индекса в зависимости от нагрузки. Например, для непопулярных приложений можно хранить данные на warm-нодах в кластере (мы используем hot-warm-cold-архитектуру).

Для того чтобы в одной системе можно было хранить и JS-ошибки, и краш-репорты нативных приложений, мы вынесли на верхний уровень всё, что используется для формирования общей статистики (время ошибки, в каком релизе она произошла, информация о пользователе, ключ группировки). А то, что уникально для каждого типа ошибки, хранится во вложенном поле attributes со своим маппингом.

Сама идея была позаимствована из Sentry и незначительно доработана в процессе эксплуатации. В Sentry у события есть базовые поля, есть поле tags для данных, по которым нужна возможность поиска, и поле extra для всех остальных специфических данных.

Обработка данных

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

Начнём со случая попроще.

Обработка краш-репортов из Android-приложений

Чтобы максимально уменьшить размер приложения, в Android-мире принято при сборке билда использовать специальные утилиты, которые:

• удаляют весь неиспользуемый код (code shrinking сокращение);

• оптимизируют всё, что осталось после первого этапа (optimization оптимизация);

• переименовывают классы, методы и поля в соответствии со специальным форматом, что позволяет уменьшить размер кодовой базы, а также усложнить процесс реверс-инжиниринга приложения (obfuscation обфускация).

Подробнее про это можно узнать из официальной документации.

Сегодня есть несколько популярных утилит:

• ProGuard (бесплатная версия);

• DexGuard на базе ProGuard (платная версия с расширенным функционалом);

• R8 от Google.

Если приложение собрано с режимом обфускации, то стек-трейс будет выглядеть примерно так:

o.imc: Error loading resources: Security check requiredat o.mef.b(:77)at o.mef.e(:23)at o.mef$a.d(:61)at o.mef$a.invoke(:23)at o.jij$c.a(:42)at o.jij$c.apply(Unknown Source:0)at o.wgv$c.a_(:81)at o.whb$e.a_(:64)at o.wgs$b$a.a_(:111)at o.wgy$b.run(:81)at o.vxu$e.run(:109)at android.os.Handler.handleCallback(Handler.java:790)at android.os.Handler.dispatchMessage(Handler.java:99)at android.os.Looper.loop(Looper.java:164)at android.app.ActivityThread.main(ActivityThread.java:6626)at java.lang.reflect.Method.invoke(Native Method)at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:811)

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

AllGoalsDialogFragment -> o.a:    java.util.LinkedHashMap goals -> c    kotlin.jvm.functions.Function1 onGoalSelected -> e    java.lang.String selectedId -> d    AllGoalsDialogFragment$Companion Companion -> a    54:73:android.view.View onCreateView(android.view.LayoutInflater,android.view.ViewGroup,android.os.Bundle) -> onCreateView    76:76:int getTheme() -> getTheme    79:85:android.app.Dialog onCreateDialog(android.os.Bundle) -> onCreateDialog    93:97:void onDestroyView() -> onDestroyView

Следовательно, нам нужен сервис, которому мы могли бы скормить обфусцированный стек трейс и mapping-файл и на выходе получить оригинальный стек-трейс.

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

На её базе наши Android-разработчики написали простенький сервис на Kotlin, который:

• принимает на вход стек-трейс и версию приложения;

• скачивает необходимый mapping-файл из Ceph (маппинги заливаются автоматически при сборке релиза в TeamCity);

• деобфусцирует стек-трейс.

Обработка краш-репортов из iOS-приложений

Краш-репорты из iOS-приложения содержат в себе довольно много полезной информации, включая стек-трейсы всех запущенных в момент падения тредов (подробнее про формат краш-репортов можно почитать тут и тут). Но есть одна загвоздка: стек-трейсы содержат лишь информацию об адресах памяти, по которым располагаются классы и методы.

Thread 0:0   libsystem_kernel.dylib              0x00000001bf3468b8 0x1bf321000 + 1537841   libobjc.A.dylib                     0x00000001bf289de0 0x1bf270000 + 1059522   Badoo                               0x0000000105c9c6f4 0x1047ec000 + 216941963   Badoo                               0x000000010657660c 0x1047ec000 + 309755004   Badoo                               0x0000000106524e04 0x1047ec000 + 306416685   Badoo                               0x000000010652b0f8 0x1047ec000 + 306670006   Badoo                               0x0000000105dce27c 0x1047ec000 + 229464287   Badoo                               0x0000000105dce3b4 0x1047ec000 + 229467408   Badoo                               0x0000000104d41340 0x1047ec000 + 5591872

Процесс сопоставления адреса памяти с именем функции называется символикацией. Для того чтобы символицировать краш-репорт, необходимы специальные архивы с дебаг-символами (dSYM), которые генерируются в момент сборки билда, и софт, который с этими архивами умеет работать.

Что можно использовать для символикации?

• Можно написать свой сервис на базе консольных утилит, но, скорее всего, он подойдёт только для ручной символикации и будет доступен только на macOS. У нас же, например, всё работает на Linux.

• Можно взять сервис Symbolicator от Sentry, который недавно был выложен в открытый доступ (рекомендую почитать статью о том, как он разрабатывался). Мы какое-то время экспериментировали с ним и пришли к выводу, что as is этот сервис будет сложно интегрировать в нашу схему: пришлось бы допиливать его под наши нужды, а опыта использования Rust у нас нет.

• Можно написать свой сервис на базе библиотеки Symbolic от Sentry, которая, хоть и написана на Rust, но предоставляет C-ABI её можно использовать в языке с поддержкой FFI.

Мы остановили свой выбор на последнем варианте и написали сервис на Golang с учётом всех наших нюансов, который под капотом обращается к Symbolic через cgo.

Группировка ошибок

И ещё один процесс, которому следует уделить внимание, группировка ошибок. От неё зависит, как быстро вы сможете обнаруживать наиболее критичные ошибки среди всех остальных событий.

Человек, не знакомый с тем, как устроены системы обработки ошибок, может подумать, что в них используются какие-то сложные алгоритмы для определения схожести строк. Но в действительности все популярные системы используют группировку по ключу (fingerprint), потому что это просто в реализации и покрывает большинство кейсов. В самом элементарном случае это может быть хеш от текста ошибки и стек-трейса. Но это подходит не для всех типов ошибок, поэтому некоторые системы позволяют явно указывать, какие ключи вы хотите использовать для подсчёта ключа группировки (либо же вы можете передать ключ явно).

Мы решили не усложнять свою систему и остановились на группировке по хешу:

• JS-ошибки группируются по полям message, type и origin;

• Android краш-репорты группируются по первым трём строчкам стек-трейсов (плюс немного магии);

• iOS краш-репорты группируются по первому несистемному фрейму из упавшего треда (тред, который отмечен как crashed в краш-репорте).

В качестве заключения

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

Однако если сегодня перед вами стоит задача начать собирать и обрабатывать клиентские ошибки, то я рекомендую присмотреться к Sentry, так как этот сервис активно развивается и является одним из лидеров рынка.

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

Если резюмировать, то:

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

• будьте готовы к резкому росту количества ошибок;

• чем больше аналитики вы построите, тем лучше;

• символикация iOS краш-репортов это сложно, присмотритесь к Symbolicator;

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

• запаситесь терпением и приготовьтесь к увлекательному путешествию в мир разработки систем сбора ошибок.