Здравствуйте, меня зовут Леша, я работаю в SEMrush в команде SRE, которая обеспечивает бесперебойную работу нашего сервиса.
Эта история о том, как мы ускорили развертывание в 6 раз и сократили затраты на мониторинг в 3 раза.
И все это посредством приручения канареек и самодельных инструментов.
Я расскажу вам, как мы улучшили конвейер выпуска с помощью канареечного развертывания.
Итак, за пару лет мы перешли от «надо попробовать» к самостоятельному тулингу.
ТЛ;ДР
- Если вы еще не используете canary-развертывание, я настоятельно рекомендую это сделать! Это правильная идея, не очень сложная в реализации.
- Система мониторинга — хороший кандидат на роль первой канарейки.
- Чтобы мониторинг делал все необходимое для канареечных целей, мы сделали собственную настройку.
Он доступен в формате Open Source, ссылка в конце статьи.
- Части этой истории я рассказал на Гейзенбаг 2019 Питер И DevOops 2019 Питер .
Я должен попробовать это
До описанной здесь истории наша дислокация была организована так:
наш конвейер выпуска перед реализацией канареечного развертывания Есть ветка, в которой разрабатывается новая функция.
В какой-то момент разработчик решает, что код готов к доставке пользователю.
Затем код загружается на тестовый стенд, запускаются автоматические тесты, QA и PO проводят ревью.
Если все ок, происходит автоматическое выкатывание в производственную среду.
Классика.
Вопрос, который мы постоянно задаем себе в команде SRE: «Насколько быстр и надежен этот процессЭ» Было также несколько вещей, которые мы хотели улучшить.
Мы хотим улучшить: простоту развертывания
В SEMrush тесты пишутся командами разработчиков.Тесты в основном направлены на покрытие функций и бизнес-требований.
Тестов очень много, и следить за порядком не всегда было легко.
Бывали ситуации, когда фича могла быть уже неактуальна, но тесты еще не были удалены.
Были трудности с проваленными тестами.
Есть несколько команд разработчиков, у каждого теста есть свой владелец.
Когда во время выполнения всего набора тестов что-то давало сбой, нам приходилось искать владельца теста и выяснять, что могло пойти не так.
Все это приводило к тому, что решение о слиянии и развертывании принималось вручную, а прохождение инкремента по всему конвейеру выпуска могло занимать до 60 минут. Мы хотели сделать развертывание более удобным для всех .
Мы хотим улучшить: тестовое покрытие
Структурно тестовая среда аналогична производственной среде, но есть отличия:- другое оборудование
- другая сеть
- другая база данных
- другие конфигурации
Мы используем разные платежные системы, отправку почты, поставщиков данных и так далее.
Есть много сторонних сервисов, но не у всех есть песочницы.
Мы хотели сократить количество инцидентов после развертывания , что произошло из-за различий в тестовой среде и рабочей среде.
Вызов канарейки на помощь
Чтобы преодолеть эти проблемы, мы решили добавить еще один узел в пул производственных серверов.План был такой: мы выкатим туда бета-сборку с новой функцией и приведем туда несколько пользователей, чтобы они увидели, что все работает правильно.
Итак, у нас появилась канарейка 
концепция развертывания канарейки Вики-минута: несколько столетий шахтеры брали с собой под землю канарейку.
Птица чувствительна к газам, и если бы в шахте произошла утечка, канарейка бы погибла.
Печально, но именно так шахтеры получили сигнал о том, что пора эвакуировать шахту.
Канарейка спасла человеческие жизни.
По плану, канареечное развертывание должно было принести с собой важное улучшение: принятие решения о выпуске функции в производство на основе предварительно собранных метрик.
по задумке канареечный трубопровод должен был выглядеть вот так
Мы проводим кастинг на канарейку
Хорошо, давайте попробуем настроить канареечное развертывание.Самый первый вопрос: на ком мы будем экспериментировать и собирать заветные метрики? Здесь, навскидку, было три варианта.
Первый вариант (простое решение) — направьте некоторых реальных пользователей на новый узел.
Это не сработало по нескольким причинам.
Во-первых, обратная связь от пользователей может быть довольно медленной.
Каждый раз вам нужно будет ждать, пока будет собрана достаточная статистика.
Во-вторых, в нашей системе есть важные сценарии, которые случаются не так уж и часто.
Нам придется подождать, пока они появятся, чтобы проверить.
В-третьих, мы не хотели портить пользовательский опыт даже небольшой части пользователей.
Мы отбрасываем этот вариант. Второй вариант (отклонено) - используйте наши тесты.
У нас их много.
Но это тоже не подходит. Трудно проверить на производственных данных.
Кроме того, нужно постоянно следить за тем, чтобы тесты для продакшена не включали в себя проверки, которые там невозможно запустить.
Мы отбрасываем этот вариант. Третий вариант (работник) - система мониторинга производственных услуг.
Она работает на производстве.
Всегда в курсе событий и подает сигналы, когда что-то сломалось.
Уровень доверия к нему высокий: дежурные администраторы по сигналу системы мониторинга начинают устранять проблему даже ночью.
Возьмем этот вариант. Возможно, это сработает быстро и надежно, давайте проверим.
Доказательство концепции
В качестве системы мониторинга мы взяли Pingdom, который тогда использовали, на роль канарейки.Это сработало! Концепция канарейки реализуется, ничего не нарушено.
Но вопросы остаются.
- Это быстрее, но все равно занимает много времени .
Проверка браузера Pingdom выполняется раз в 5 минут. Если мы хотим посмотреть два результата подряд, то получим 10 минут. Я хотел быстрее.
- Дополнительные расходы .
Теперь нам пришлось платить за проверки, которые также проверяют окружение canary.
- Неудобная отладка .
Pingdom — это всё-таки не деплой, а инструмент мониторинга.
Не очень хорошо вписывался в наш GitLab CI.
Canary VS тестирует VS мониторинг
С приходом канарейки наш конвейер развертывания стал выглядеть так:
выпуск конвейера после реализации канареечного развертывания Для каждой среды у нас был свой набор инструментов.
Каждую нужно поддерживать, но все они работают по-разному.
Неудобно по нескольким причинам.
Была проблема «фейковый» браузер .
Pingdom использует эмуляции, которые могут отличаться от реального браузера.
Такую картину можно было наблюдать даже в ситуациях, когда у пользователей всё работало корректно.
Было также проблема с рассинхронизацией тестов и мониторинга .
В команде SRE мы прежде всего доверяем мониторингу.
Ребята из QA ориентированы на тестирование.
Получается следующее: в каждой среде соответствующие инструменты работают по-разному и непонятно, за кем последнее слово.
И еще было сложно отлаживать неудачные тесты .
Pingdom — внешний инструмент. Оттуда вы можете получить ограниченную информацию об инцидентах.
Этого не всегда было достаточно, чтобы понять проблему.
Разработчикам часто приходилось пожимать плечами, когда их спрашивали.
Чтобы преодолеть эти проблемы, мы решили создать свой собственный инструмент.
Представляем SEMrush PURR
Нужен настоящий браузер, единые скрипты тестирования и мониторинга, удобная отладка.Для интеграции с нашим GitLab CI мы хотели иметь возможность запуска из CLI. А, раз это так, то при этом есть возможность запуска по расписанию.
Таковы были требования к новому инструменту.
Решение: мы взяли Puppeteer, сделали фреймворк из NodeJS и добавили Redis для очередей.
Инструмент назывался SEMrush PURR (от Puppeteer Runner).
Кукловод – инструмент от Google; выполняет ту же команду, что и Chrome. Это реализация протокола DevTools для консоли Chrome, которую мы используем каждый день.
На тот момент поддерживались Chrome, Firefox (бета), Edge (альфа).
Puppeteer помог нам решить проблему «поддельного» браузера.
Запуск из CLI позволил интегрировать запуск SEMrush PURR в конвейер GitLab CI. 
запуск SEMrush PURR – финальный этап конвейера; если PURR падает, расчет не происходит
Чтобы упростить отладку, мы смогли делать снимки экрана, записывать видео, а также собирать логи и трассировки.
Если проверка не пройдена, вы можете посмотреть картинку прямо в GitLab и посмотреть, что произошло.
отладка неудачных тестов 
Единые сценарии тестирования и мониторинга стали описываться в YAML-файле.
YAML-файл со сценариями тестирования и мониторинга.
Там можно указать разные параметры (например, домен, который мы тестируем).
Здесь на скриншоте указано, что мы работаем с куками и авторизацией.
Для работы по расписанию запускаем наше NodeJS-приложение в Kubernetes. Настройка расписания сканирования с помощью Redis (библиотека Bull).
Результаты теста отправляются в «Прометей».
Оттуда мы берем оповещения, если что-то упадет. Параметры запланированного запуска не ограничиваются этим стеком.
Вы можете использовать cron, Google Cloud Functions или AWS Lambda. Или разместите его на своей виртуальной машине.
Объединение конвейера с SEMrush PURR
В результате SEMrush PURR дал нам то, что мы хотели: один и тот же инструмент и скрипты для всех трех сред.
выпуск конвейера после реализации SEMrush PURR Основным результатом внедрения SEMrush PURR стало сокращение количества инцидентов после развертывания, когда код с ошибками попадал в продакшн.
С canary, но без ограничений Pingdom, время доставки фичи в продакшн сократилось с 60 до 10 минут. Не нужно ждать появления испытательного стенда; нет необходимости обращаться к другим командам, чтобы узнать, что происходит с их тестами.
Мы стали тратить меньше денег на мониторинг.
Один миллион транзакций на Pingdom обошелся нам в 625 долларов.
С SEMrush PURR сумма была уменьшена до 225 долларов.
Отдельным положительным моментом работы с SEMrush PURR лично для нас является то, что настройкой проверок занимается наша команда.
То есть у нас есть возможность внести часть проверок в те вещи, которые, на наш взгляд, важны для производственной системы.
Дружить с канарейками
Развертывание Canary помогло нам улучшить конвейер выпуска.Мне хотелось бы верить, что со временем эта практика может стать отраслевым стандартом, как когда-то это сделали тесты в целом.
Я бы хотел, чтобы больше людей и компаний имели доступ к преимуществам канарейки.
Если вы уже используете канареечное развертывание (или собираетесь начать), взгляните на Puppeteer. Он помог нам получить среду мониторинга, максимально приближенную к реальному браузеру пользователя.
Если вы ищете инструменты, обратите внимание на SEMrush PURR. Он доступен по адресу GitHub .
Мы будем рады, если наш инструмент поможет вам сделать развертывание canary более удобным.
Теги: #открытый код #разработка веб-сайтов #DevOps #qa #тестирование ИТ-систем #мониторинг #развертывание #Pingdom #PURR
-
Linux/Unix: Базовая Конфигурация Ntp
19 Oct, 24 -
Страсть — Ключ К Успеху В Ведении Блога
19 Oct, 24 -
Яндекс.афиша. Xss
19 Oct, 24 -
Хакатон От Abbyy
19 Oct, 24 -
Смысл, Смысл, Смысл, Смысл, Смысл, Смысл
19 Oct, 24
