Я досі памʼятаю проєкти, де встановлення нової версії на сервер було ритуалом. Призначеного вечора, коли клієнтів менше, найдосвідченіший розробник підключався до сервера, копіював файли, вручну запускав команди з текстового файлу з назвою на кшталт «інструкція_деплой_ФІНАЛ_2», перезапускав сервіси й із завмиранням серця відкривав сайт. Якщо щось ішло не так, починалася ніч. А якщо цей розробник звільнявся, компанія виявляла, що ніхто, крім нього, до пуття не знає, як узагалі влаштований сервер. Це не страшилка з минулого. Я й зараз регулярно зустрічаю такі системи, коли до нас приходять на аудит.
Сервер як рецепт, а не як саморобка
Головна ідея автоматизації встановлення звучить просто: налаштування сервера має бути не послідовністю дій, які хтось памʼятає, а записаним рецептом, який може виконати машина. В індустрії це називають «інфраструктура як код». Усі кроки: яке програмне забезпечення поставити, які налаштування застосувати, які теки створити, які права видати, записані у файлах, зберігаються поруч із кодом проєкту й виконуються автоматично.
Різниця приблизно як між бабусиним борщем і борщем за рецептом. Бабусин борщ чудовий, але відтворити його без бабусі неможливо: «солі до смаку, буряка скільки треба, вари, поки не буде готово». Рецепт може бути менш душевним, але за ним будь-яка людина на будь-якій кухні отримає однаковий результат. Для ресторану, який хоче відкрити другу філію, це питання виживання. Для системи, якій потрібен другий сервер, теж.
Що дає автоматичне встановлення
Перше й головне: повторюваність. Сервер розробки, тестовий сервер і бойовий сервер збираються за одним рецептом і тому однакові. Зникає вічна фраза «а в мене локально все працює». Якщо працює на тестовому, працюватиме й на бойовому, бо це та сама конфігурація.
Друге: швидкість і безпека оновлень. Коли встановлення автоматизоване, нова версія йде на сервер натисканням кнопки або взагалі сама після того, як пройшли тести. Це називається безперервна інтеграція й доставка. Оновлення займає хвилини, а не вечір, і якщо щось пішло не так, відкат на попередню версію так само автоматичний. Ми в Ingello живемо саме так: зміна потрапляє в основну гілку репозиторію, і за хвилину вона вже на сервері. Жодних нічних ритуалів.
Третє, про яке згадують лише в момент катастрофи: відновлення. Сервер згорів, провайдер закрився, зламали. Якщо інфраструктуру описано кодом, новий сервер піднімається за тим самим рецептом за години. Якщо ні, компанія тижнями відновлює те, що колись налаштовували вручну різні люди в різні роки.
Сервер, який не можна перезібрати з нуля за записаним рецептом, не інфраструктура. Це реліквія, і молитися на неї доведеться всім.
Масштабування: коли трафіку стає багато
Окрема історія це масштабування. Уявіть інтернет-магазин, у якого девʼяносто відсотків року спокійне навантаження, а потім настає розпродаж, і відвідувачів стає вдесятеро більше. Можна цілий рік тримати сервер, розрахований на пік, і платити за потужність, яка простоює більшість часу. Можна тримати сервер під звичайне навантаження й лягати в найприбутковіший день. Обидва варіанти погані.
Автомасштабування розвʼязує це елегантно: система сама стежить за навантаженням, у разі зростання трафіку додає ресурси, а коли пік минає, вимикає їх. Платите Ви за те, що реально використовується. Але тут важливо розуміти одну річ: автоматично масштабуватися може лише система, яка до цього готова архітектурно. Якщо застосунок зберігає дані користувача в памʼяті конкретного сервера або всі запити впираються в одну базу, жодна хмарна магія не допоможе. Масштабованість закладається в архітектурі, а автоматизація лише розкриває її.
Де не варто перегравати
Задля справедливості: я бачив і протилежну крайність. Невеликий внутрішній сервіс на двадцять користувачів, для якого збудували найскладнішу систему оркестрації контейнерів, автомасштабування й моніторингу, обслуговування якої коштує дорожче, ніж сам сервіс. Це як купити вантажний літак, щоб возити продукти з ринку. Інфраструктура має відповідати задачі. Для маленького проєкту достатньо простого записаного рецепта встановлення й автоматичної доставки оновлень. Складні механізми масштабування потрібні тоді, коли навантаження справді цього вимагає, і не раніше.
З чого почати
Поставте своїй команді три запитання. Скільки часу займає випуск нової версії? Чи можна перезібрати бойовий сервер з нуля, якщо він завтра зникне, і скільки це займе? Скільки людей у компанії знають, як він влаштований? Якщо відповіді звучать як «вечір», «не знаємо» і «одна», то автоматизація встановлення має стояти в плані раніше за будь-які нові функції.
У Systems ми закладаємо автоматичне встановлення й доставку оновлень у проєкти від самого початку, а Fractal генерує разом із кодом і інфраструктурну частину, тому сервер у нас описаний так само, як і все інше. Чи можна автоматизувати встановлення й масштабування? Не просто можна. Сьогодні неавтоматизоване встановлення це технічний борг, який одного дня доведеться повернути, і зазвичай найнезручнішого вечора.
