Я до сих пор помню проекты, где установка новой версии на сервер была ритуалом. В назначенный вечер, когда клиентов поменьше, самый опытный разработчик подключался к серверу, копировал файлы, вручную запускал команды из текстового файла с названием вроде «инструкция_деплой_ФИНАЛ_2», перезапускал сервисы и с замиранием сердца открывал сайт. Если что-то шло не так, начиналась ночь. А если этот разработчик увольнялся, компания обнаруживала, что никто, кроме него, толком не знает, как вообще устроен сервер. Это не страшилка из прошлого. Я и сейчас регулярно встречаю такие системы, когда к нам приходят на аудит.
Сервер как рецепт, а не как поделка
Главная идея автоматизации установки звучит просто: настройка сервера должна быть не последовательностью действий, которые кто-то помнит, а записанным рецептом, который может выполнить машина. В индустрии это называют «инфраструктура как код». Все шаги: какое программное обеспечение поставить, какие настройки применить, какие папки создать, какие права выдать, записаны в файлах, хранятся рядом с кодом проекта и выполняются автоматически.
Разница примерно как между бабушкиным борщом и борщом по рецепту. Бабушкин борщ прекрасен, но воспроизвести его без бабушки невозможно: «соли по вкусу, свёклы сколько надо, вари, пока не будет готово». Рецепт может быть менее душевным, но по нему любой человек на любой кухне получит одинаковый результат. Для ресторана, который хочет открыть второй филиал, это вопрос выживания. Для системы, которой нужен второй сервер, тоже.
Что даёт автоматическая установка
Первое и главное: повторяемость. Сервер разработки, тестовый сервер и боевой сервер собираются по одному рецепту и поэтому одинаковы. Исчезает вечная фраза «а у меня локально всё работает». Если работает на тестовом, будет работать и на боевом, потому что это одна и та же конфигурация.
Второе: скорость и безопасность обновлений. Когда установка автоматизирована, новая версия уходит на сервер нажатием кнопки или вообще сама после того, как прошли тесты. Это называется непрерывная интеграция и доставка. Обновление занимает минуты, а не вечер, и если что-то пошло не так, откат на предыдущую версию так же автоматичен. Мы у себя в Ingello живём именно так: изменение попадает в основную ветку репозитория, и через минуту оно уже на сервере. Никаких ночных ритуалов.
Третье, о котором вспоминают только в момент катастрофы: восстановление. Сервер сгорел, провайдер закрылся, взломали. Если инфраструктура описана кодом, новый сервер поднимается по тому же рецепту за часы. Если нет, компания неделями восстанавливает то, что когда-то настраивали вручную разные люди в разные годы.
Сервер, который нельзя пересобрать с нуля по записанному рецепту, это не инфраструктура. Это реликвия, и молиться на неё придётся всем.
Масштабирование: когда трафика становится много
Отдельная история это масштабирование. Представьте интернет-магазин, у которого девяносто процентов года спокойная нагрузка, а потом наступает распродажа, и посетителей становится в десять раз больше. Можно круглый год держать сервер, рассчитанный на пик, и платить за мощность, которая простаивает большую часть времени. Можно держать сервер под обычную нагрузку и ложиться в самый прибыльный день. Оба варианта плохие.
Автомасштабирование решает это элегантно: система сама следит за нагрузкой, при росте трафика добавляет ресурсы, а когда пик проходит, отключает их. Платите Вы за то, что реально используется. Но тут важно понимать одну вещь: автоматически масштабироваться может только система, которая к этому готова архитектурно. Если приложение хранит данные пользователя в памяти конкретного сервера, или все запросы упираются в одну базу, никакая облачная магия не поможет. Масштабируемость закладывается в архитектуре, а автоматизация только раскрывает её.
Где не стоит перебарщивать
Справедливости ради: я видел и обратную крайность. Небольшой внутренний сервис на двадцать пользователей, для которого построили сложнейшую систему оркестрации контейнеров, автомасштабирования и мониторинга, обслуживание которой стоит дороже, чем сам сервис. Это как купить грузовой самолёт, чтобы возить продукты с рынка. Инфраструктура должна соответствовать задаче. Для маленького проекта достаточно простого записанного рецепта установки и автоматической доставки обновлений. Сложные механизмы масштабирования нужны тогда, когда нагрузка действительно этого требует, и не раньше.
С чего начать
Задайте своей команде три вопроса. Сколько времени занимает выпуск новой версии? Можно ли пересобрать боевой сервер с нуля, если он завтра исчезнет, и сколько это займёт? Сколько людей в компании знают, как он устроен? Если ответы звучат как «вечер», «не знаем» и «один», то автоматизация установки должна стоять в плане раньше любых новых функций.
В Systems мы закладываем автоматическую установку и доставку обновлений в проекты с самого начала, а Fractal генерирует вместе с кодом и инфраструктурную часть, поэтому сервер у нас описан так же, как и всё остальное. Можно ли автоматизировать установку и масштабирование? Не просто можно. Сегодня неавтоматизированная установка это технический долг, который однажды придётся вернуть, и обычно в самый неудобный вечер.
