Некоторое время назад мы в HeadHunter обнаружили «сумеречную зону» при переводе новой версии сайта из тестирования в продакшн.
Недостаточное внимание к разнице между тестовой и производственной инфраструктурой периодически приводило к краху сайта.
Старые стенды по внутреннему устройству заметно отличались от рабочего кластера.
Сценарии инициализации для запуска служб различались, а файлы конфигурации отличались расположением и содержимым.
Взаимодействие служб между собой происходило без учета особенностей боевой обстановки.
Покажу логику нашего решения, которое позволило добиться качественно новых результатов тестирования.
Ээта статья продолжает мою доклад на SQA Days-18 .
Конфигурационные файлы Первое, что мы увидели, — это разные файлы конфигурации на испытательных стендах и в бою.
В нашем случае это были даже файлы с разным расположением.
Если говорить об их содержании, то они были написаны разными людьми и по-разному.
Что это значит? Это означает, что каждый пакет приносил с собой на рабочие серверы файл настроек по умолчанию, который находился в /var/lib/… или /usr/shared/… Это те самые настройки, которые удобны в тестовой среде.
А те из них, которые нужно было заменить, уже были в файле конфигурации в /etc/имя_пакета.
Настройки туда прописали системные администраторы, когда получили соответствующую задачу в Jira. Давала ли такая схема взаимодействия гарантию корректной настройки конфигов в бою? Точно нет. Файлы с настройками, которые использовались в боевой обстановке, не проверялись! И поэтому частыми гостями в работе были тестировщики и разработчики с вопросом: «Мы на прошлой неделе просили изменить эту настройку.
Вы зарегистрировали его? Покажи мне, что произошло».
Почему возникла такая ситуация? Потому что на тестовых стендах, какими мы привыкли их видеть, сервисы живут на одном сервере.
В той же файловой системе.
И если настройки одного из них необходимо изменить в файле /etc/default/jetty, то настройки другого придется изменить каким-то другим способом.
Для этого на тестовом стенде были написаны специальные скрипты инициализации для управления различными сервисами.
А там в самописных инициализаторах были указаны конфиги, расположенные в нестандартных местах.
Чтобы разрешить конфликт Как разрешить этот конфликт? Мы решили, что нужно изолировать сервисы друг от друга на уровне файловой системы.
Ведь в бою каждый сервис работает на отдельном сервере или виртуальной машине.
Возможно, chroot сможет решить проблему изоляции сервисов на тестовом стенде на уровне файловой системы.
Тогда у каждого сервиса будет своя папка /etc и свои файлы конфигурации, которые располагаются там же, где и на рабочих серверах.
И файлы логов будут в тех же папках, что и в бою.
И это решение приближает нас к решению проблемы, как использовать на тестовом стенде одни и те же файлы конфигурации, что и в производственной среде.
Достаточно ли изоляции на уровне файловой системы? На старых тестовых стендах все сервисы слушали localhost, каждый на своем порту.
И они общались друг с другом через локальный хост. Однако на реальном сайте каждый сервис живет на своем сервере.
И причём каждый сервис запускается в 2 и более экземплярах.
Такое решение нужно, в первую очередь, для распределения нагрузки и горизонтальной масштабируемости сервиса.
А, во-вторых, обеспечить надежность сервиса.
В случаях, когда один из серверов необходимо остановить на техническое обслуживание, его часть работы берут на себя другие такого же типа.
Таким образом, чтобы обеспечить распределение запросов между несколькими серверами, обслуживающими один сервер, необходим внутренний балансировщик нагрузки.
Выгодно ли это системным администраторам?! И здесь мы увидели еще один пункт нашего списка задач.
Конфигурацию балансировщика мы никогда раньше не тестировали! Поэтому риск, связанный с созданием конфигурации nginx, выполняющей роль балансировщика, полностью лежит на системных администраторах.
И проверить его корректность работы у них не было возможности нигде, кроме как на живой площадке.
И порой эксперименты заканчивались не очень хорошо.
Интересный.
Получается, что системные администраторы могут получить выгоду от внедрения новой схемы работы тестовых стендов.
Возможно, они смогут принять участие в реализации проекта новых стендов.
Балансир А на новых трибунах будет балансировщик нагрузки.
Затем нам нужно будет прописать IP и порты вышестоящих серверов в конфигурации nginx. Возможно, было бы удобнее выделить для каждой службы сервер, на котором она может работать.
Итак, помимо изоляции серверов по файловой системе, мы добавили изоляцию по IP. Кроме того, вспомогательные сервисы, такие как rsyslog, смогут работать так же, как и на реальном сайте.
Возможно, только если конфиги каждого сервиса такие же, как в бою.
И это третий пункт в нашем списке задач.
Как обеспечить использование одних и тех же файлов конфигурации и содержимого как на тестовых стендах, так и на производственных серверах? Как добиться одинаковых конфигов? Если мы уже решили, что каждый сервис будет запускаться на отдельном сервере, то, возможно, нам стоит воспользоваться скриптами развертывания, которые есть у сисадминов? И с их помощью раздавать на тестовом стенде те же файлы конфигурации, что и на большом сайте? Да, мы можем это сделать.
С учетом того, что пароли к платежным системам или СМС-рассылкам должны оставаться в секрете.
Тогда, наконец, можно будет хранить скрипты верстки и конфиги на GitHub, потому что секретные данные оттуда удалены.
И разработчики, и тестировщики перестанут приходить к системным администраторам с просьбами поделиться настройками по мере их реализации на сайте.
Конфигурации на GitHub Чтобы скрыть пароли в файлах конфигурации, мы используем переменные.
Потому что сами конфигурационные файлы стали шаблонами Jinja2 для Ansible. Мы написали собственную систему компоновки, используя ее.
А Ansible позволяет нам иметь два набора переменных, т.е.
две пары папок group_vars и host_vars, где определяются значения переменных.
Один набор находится в папке playbooks, а другой в папке инвентаря.
И один из этих наборов всегда имеет приоритет над другим.
Таким образом, мы помещаем в GitHub не только скрипты верстки и конфиг-файлы, но и один набор значений переменных, если они не являются секретными.
К ним могут относиться ограничения памяти для приложений, количество потоков или разветвленных процессов, а также тайм-ауты.
Те.
те значения, которые различаются в бою и на испытательном стенде.
Храним секреты Секретные значения, такие как пароли к платежным системам и сервисам SMS-сообщений, а также пароли к базе данных, находятся в приватном хранилище системных администраторов и недоступны тестировщикам.
На тестовом стенде вместо приватного набора переменных из службы операций тестировщики используют собственные значения из своего репозитория.
Там они определяют как пароли, специфичные для тестового стенда, так и значения ограничений памяти, количества потоков и процессов или таймаутов, специфичные для тестовой среды.
Отдельный сервер для каждого стенда — расточительство.
Из написанного выше мы видим, каким требованиям должны отвечать те отдельные серверы для сервисов, которые мы будем запускать на тестовом стенде:
- изоляция файловой системы;
- отдельный IP-адрес;
- init для запуска нашего и связанных с ним пакетов;
- opensshd для запуска Ansible.
Дополнительным преимуществом их использования является то, что они используют общую память, выделяя ее по мере того, как ее запрашивают приложения внутри контейнеров.
И, в отличие от виртуальных машин, они не откусывают сразу большой кусок оперативной памяти.
Благодаря этому мы экономим память.
В чем преимущества нашего решения В результате того, что мы
- выделил на тестовом стенде псевдосервер для каждого сервиса;
- используем те же скрипты раскладки и те же файлы настроек, что и в бою;
- повторил внутренний балансировщик на Linux-контейнере внутри стенда;
- вынуждены сначала собрать пакет из ветки Git, чтобы развернуть его на свой псевдосервер с помощью скриптов развертывания,
Сначала мы перешли от тестирования ветки кода к тестированию пакета для нашего дистрибутива.
Теперь мы можем быть уверены, что в бою пакет сможет установиться на чистый сервер и создать все необходимые папки, с достаточными правами для его работы.
Во-вторых, мы начали тестировать те самые конфиг-файлы, которые будут использоваться на реальном сайте.
А это значит, что мы исключили человеческий фактор при написании конфигов, который мог привести к сбою сайта.
Мы помещаем различия между стендом и производственной средой в переменные.
В-третьих, мы начали тестирование конфигурации балансировщика.
Таким образом, еще на этапе подготовки задания мы проверяем взаимодействие служб друг с другом в той самой инфраструктуре, которая работает в боевых условиях.
И в-четвёртых.
Теперь мы можем запускать два или более экземпляров каждого сервиса.
Мы можем не только отладить работу повторов в nginx, но и протестировать, как ведет себя сайт при выходе новой версии.
Представьте, что теперь вы можете запускать автотесты в тот момент, когда мы моделируем выход новой версии сайта! И добиться стабильной работы стенда в то время, когда один сервер уже работает на новой версии ПО, второй остановлен на обновление, а третий еще отвечает старой версией.
Это достойная задача! Результат Подведем итог.
Реинжиниринг процесса тестирования и рефакторинг тестовых стендов дали отличные результаты.
За 2 года аптайм сайта превысил 99,9%.
Это отличный показатель, если считать его в минутах.
За месяц время простоя сайта составляет менее 43 минут. При этом мы ужесточили определение простоя в 3 раза — с 60 500 ошибок в секунду до 20. А для онлайн-бизнеса, каким и является HeadHunter, увеличение времени безотказной работы означает реальную экономию денег.
Добавьте к этому клиентов, которых hh.ru привлек благодаря более стабильной работе сайта, чем раньше.
Считаете ли вы, что время безотказной работы сайта является ключевым фактором успеха вашего бизнеса? Итак, 4 простых шага:
- закрепите за каждой услугой отдельный сервер на стенде;
- тестируйте пакет, а не ветку кода;
- использовать сценарии макетирования продукции и тестировать файлы конфигурации;
- выполнить итерацию балансировщика и протестировать процесс выпуска (подробнее о том, как это сделать, см.
ирреальность уже сказал ).
-
Линекр, Томас
19 Oct, 24 -
Группа Местных Галактик
19 Oct, 24 -
Adobe Air Alpha 1 Для Linux
19 Oct, 24 -
Простой Парсинг Xml В Qt
19 Oct, 24 -
К Вершине Без Забот™
19 Oct, 24 -
Plastic Logic Reader Поддержали Газетчики
19 Oct, 24
