Повне налаштування хмарної інфраструктури на DigitalOcean

Інфраструктура на DigitalOcean: де ламається і чому

Типовий сценарій виглядає однаково: сервіс стартує на одному вузлі, до нього вручну дописують другий, потім третій — база, кеш, балансувальник, резервні копії. Кожен налаштований руками, частина параметрів живе тільки в голові інженера, який його піднімав.

Поки навантаження рівне, схема тримається. Вузьке місце хмарної інфраструктури проявляється на зростанні: застосунок упирається в кількість з'єднань до бази, кеш витісняє гарячі ключі, а горизонтальне масштабування не дає ефекту, бо сесії зберігаються локально на інстансі.

Відмова сервісу при зростанні навантаження приходить не в момент піку, а через десять-п'ятнадцять хвилин після — коли черга запитів уже розрослася і деградація пішла лавиною.

Ручне налаштування серверів додає другий клас проблем: конфігурації розходяться між середовищами, оновлення ставляться по-різному, а відкат після невдалого релізу перетворюється на окрему операцію з невідомим результатом.

Непередбачувані падіння продакшену майже завжди мають одну причину — немає меж за ресурсами і немає автоматичної заміни вузла, що впав.

Тому інфраструктура на DigitalOcean проєктується не як набір серверів, а як описана конфігурація: межі за пам'яттю і з'єднаннями, перевірки живучості, автозаміна інстансів, міграції з можливістю відкату. Розбираємо, як це закривається.

Що змінюється після налаштування: ефект у строках і частках

Ефект від налаштування інфраструктури на DigitalOcean вимірюється не відчуттями, а показниками, які звіряються до і після: час відновлення, частка автоматизованих операцій, зниклі класи відмов, частота випуску оновлень.

Час відновлення сервісу

Розгортання з копії стає однією операцією: конфігурація описана файлами, копії знімаються за розкладом, стенд піднімається зі знімка стану без ручних правок. Цільовий час відновлення задається заздалегідь і перевіряється навчальним запуском, а не з'ясовується в момент аварії.

Усунений клас відмов

Правки в панелі керування, налаштування, що розійшлися, і «тимчасові» винятки — найчастіше джерело аварій. Коли конфігурація живе в сховищі і проходить перевірку до робочого контуру, цей клас відмов зникає, а розбіжності видно заздалегідь.

Автоматизація викату і швидкість випуску

Викат перестає бути подією: збірка, перевірки і доставка виконуються однією дією, повернення на попередню версію — теж. Релізи більше не прив'язані до вікна і чергового, тому оновлення виходять частіше і дрібніше — такі зміни простіше перевіряти.

Чергування без нічних підйомів

Оповіщення надходять за значущими подіями, а типові збої — процес, що впав, заповнений диск, недоступний вузол — закриваються самі. Черговий підключається тільки там, де потрібне рішення людини, і несправність не перетворюється на простій до ранку.

Варіанти розгортання на DigitalOcean та їх обмеження

На DigitalOcean схема розгортання визначає, що залишається на нашій стороні, а що забирає платформа.

Одна машина з ручним налаштуванням, керований кластер, контейнерна платформа і гібрид із власним залізом закривають різні завдання — і в кожного режиму свої обмеження, які проявляються не на старті, а при зростанні навантаження або відмові вузла.

Обмеження вибраної схеми дешевше прийняти заздалегідь, ніж розбирати їх під час аварії.

До розгортання фіксуємо профіль навантаження і допустимий час простою, а середовище описуємо декларативно — тоді перехід між режимами, наприклад з одиночної машини на керований кластер, залишається керованим завданням, а не переписуванням інфраструктури з нуля.

Порядок робіт: від аудиту інфраструктури до передачі

Інфраструктура рідко ламається на старті — вона деградує через ручні правки в панелі, середовища, що роз'їхалися, і копії, які ніхто не перевіряв відновленням.

Тому етапи впровадження йдуть від фактичного стану до відтворюваного, і кожен крок закінчується артефактом, який можна перевірити.

1. Аудит інфраструктури. Збираємо інвентаризацію: що розгорнуто, які домени і записи вказують на живі вузли, де залишилися ручні правила, як зберігаються ключі. Окремо перевіряємо резервні копії — розгортаємо копію на ізольованому стенді й отримуємо реальний час відновлення замість заявленого.
2. Схема розгортання. Описуємо цільову топологію: приватна мережа, розділення публічного і внутрішнього контуру, балансувальник, керована база, об'єктне сховище. Топологія фіксується як код — на DigitalOcean середовище піднімається однією командою, а не набором кліків у панелі.
3. Налаштування середовищ. Dev, staging і production збираються з одних модулів і відрізняються змінними: розмір вузлів, число реплік, політика копій. Секрети виносимо в сховище і видаємо за ролями, а не через змінні в репозиторії.
4. Перевірка поведінки при відмовах. Гасимо вузол застосунку, відключаємо базу, дивимося, чи спрацювали перевірки здоров'я, заміна вузла і оповіщення. Відновлення з копії проганяємо на чистому стенді й фіксуємо час до робочого стану.
5. Спостережуваність. Налаштовуємо метрики, логи і оповіщення так, щоб деградацію бачила ваша команда, а не клієнти. У кожного оповіщення є конкретна дія в інструкції.
6. Передача інфраструктури команді. Доступи за ролями замість спільних облікових записів, схеми, порядок випуску релізу, відкат і відновлення. Процедури проганяємо разом з вашими інженерами, щоб передача була не папкою документів, а робочим навиком.

Комплект передачі: схеми, доступи, регламенти, документація

Пакет передачі — не архів файлів і не доступи в листуванні, а комплект, за яким ваш інженер розгортає та обслуговує середовище без питань до нас. Що саме залишається у вас після здачі:

• Передавані конфігурації — описи сервісів, мереж і середовищ у репозиторії: розгортання повторюється з коду, а не з пам'яті інженера.
• Схеми середовищ — карта тестового, передпродуктивного і продуктивного контурів: зв'язки сервісів, зовнішні точки входу, приватні підмережі.
• Політики доступу та ролі — матриця «роль → дозволи», порядок видачі та відкликання ключів, правила зберігання секретів і строки їх ротації.
• Регламент резервного копіювання — що копіюється, з якою періодичністю, скільки зберігається, де лежать копії і як перевіряється відновлення.
• Документація з інфраструктури — топологія, відповідальні, порядок типових операцій: викат версії, відкат, масштабування, планові роботи.
• Регламент чергування — кому надходять повідомлення про збій, які кроки виконуються першими, на якому етапі підключається ескалація.
• Доступи та службові облікові записи — консоль DigitalOcean переоформлюється на вашу організацію, ключі автоматизації ротуються, старі відкликаються.

Приймання йде за фактом: ваш інженер розгортає середовище і відновлює дані з копії за інструкціями, без підказок з нашого боку. Якщо на якомусь кроці знадобилася наша допомога — документація неповна, і ми її доопрацьовуємо.

Кейс: час відновлення сервісу скоротився в рази

До: відмови йшли за одним сценарієм

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

Про падіння команда дізнавалася від користувачів, а не від системи моніторингу, а відновлення займало від 40 до 60 хвилин — стільки йшло на пошук останньої правки та її повторення на живій машині.

Що змінили

Інфраструктуру перенесли в DigitalOcean і описали декларативно: стан середовища зберігається в конфігурації, а не в головах інженерів, тому будь-який вузол піднімається з опису заново.

Базу винесли на керований кластер з реплікою і автоматичним переходом на неї, застосунок поставили за балансувальник, додали перевірки живучості — вузол, що впав, замінюється без ручного втручання.

Резервні копії та знімки стану знімаються за розкладом, а раз на тиждень відновлення перевіряється на окремому середовищі. Це ключовий момент: неперевірена копія — не резерв, а надія, і ми прибрали цю невизначеність.

Що стало

Час простою скоротився з 40–60 хвилин до 3–5, а частина інцидентів закривається автоматикою до того, як їх помітить користувач. Повторювані відмови зникли з 6–8 у квартал до 1–2, і це вже різні причини, а не один і той самий збій.

Окремий результат впровадження — зміна режиму роботи команди: чергування перестало бути ручним розбором, реліз виконується щодня, відкат на попередню версію — однією операцією.

Керовані сервіси проти машин, налаштованих вручну

Межа проходить за одним питанням: хто експлуатує компонент — провайдер чи ваша команда. Керовані сервіси забирають рутину: оновлення, реплікацію, резервні копії, заміну вузла, що відмовив.

Машини під ручним керуванням залишають це всередині вашої зони, зате дають повний контроль над середовищем.

Керовані сервіси виграють на стандартному контурі: база даних, балансувальник, об'єктне сховище, кластер контейнерів.

Провайдер відповідає за доступність і своєчасні оновлення, а вікно обслуговування і порядок відновлення закріплені в SLA — черговий інженер не прокидається через плановий патч.

Машини під ручним керуванням виправдані, коли потрібне нестандартне налаштування: свої параметри ядра, спеціалізовані агенти, вимоги до розміщення даних, сервіси, які не можна запакувати в контейнер.

Платформа рівня DigitalOcean тут не обмежує, але й не підстрахує: оновлення, перезавантаження і відкат виконує ваша команда за своїм регламентом.

Хто відповідає за оновлення — головний вододіл вибору. У керованого сервісу пропущений патч залишається зоною провайдера, у машини під ручним керуванням він перетворюється на відкладну відмову і технічний борг.

Зона відповідальності підрядника фіксується схемою, а не обіцянкою: що обслуговує провайдер, що автоматизовано в конфігурації, що потребує ручного втручання.

Передбачуваність поведінки дає описаний кодом стан — інфраструктура відтворюється з нуля, а розходження між середовищами видно до викату.

Технічні сумніви: доступи, відмовостійкість, міграції

Питання перед стартом в інженерних команд майже завжди одні й ті самі: що буде з працюючим сервісом, як розмежувати доступ, чи можна вірити резервним копіям. Нижче — прямі відповіді, без обіцянок і обтічних формулювань.

Наш порядок роботи в тому, що спочатку фіксуємо поточний стан: схему мережі, ролі, розклад копій, точки зростання навантаження. Далі пропонуємо зміни так, щоб кожен крок можна було відкотити окремо, а не «переїхали і подивилися, що вийде».

Як розділяються доступи між командами?

Ролі описуються за принципом мінімально необхідних прав: окремий обліковий запис на кожен сервіс, а не спільний адміністративний ключ на всіх. Розробка отримує доступ до своїх сервісів і логів, але не до мережевих налаштувань і білінгу; експлуатація — навпаки. Усі дії потрапляють у журнал, тому розбір інциденту спирається на факти, а не на спогади.

Як ви перевіряєте, що резервні копії справді відновлюються?

Копія без перевірки — це припущення. Ми регулярно розгортаємо її на ізольованому середовищі, звіряємо цілісність даних і заміряємо фактичний час відновлення. Якщо сервіс не піднімається з копії за прийнятний строк, змінюємо схему зберігання, а не сподіваємося на краще.

Що з відмовостійкістю — чи впаде сервіс разом з одним вузлом?

Вузли розподіляються за незалежними зонами доступності, балансувальник виводить того, що відмовив, з ротації, а сервіси перезапускаються автоматично. Конфігурація і дані не прив'язані до конкретної машини, тому заміна вузла — планова операція, а не аварійна.

Обговоримо завдання: повернемося з планом і оцінкою робіт

Щоб обговорити завдання з інфраструктури предметно, а не на рівні загальних слів, ми починаємо з вступних — вони займають у вашої сторони півгодини і знімають більшість припущень із майбутньої оцінки. Готовий проєкт не потрібен: достатньо того, що вже є під рукою.

• Як улаштовано зараз: які сервіси працюють, де розміщені, що вже перенесено в DigitalOcean, а що залишилося на попередніх майданчиках.
• Профіль навантаження: користувачі, число запитів, пікові періоди, обсяг даних і швидкість його зростання — це вступні для розрахунку розміру машин і порогів автомасштабування.
• Вимоги до відмовостійкості: допустимий час простою, чи потрібен резервний вузол в іншому регіоні, як часто знімати резервні копії і за який час потрібно відновлюватися.
• Доступи та безпека: правила підключення до серверів, мережева ізоляція, зберігання секретів, журналювання дій адміністраторів.
• Обмеження: бажані строки, вікна, в які допустимі перемикання, і зовнішні підрядники, з якими потрібно узгоджувати роботи.
• Відповідальний з вашого боку: людина, яка підтверджує рішення щодо інфраструктури і приймає результат.

Після розбору ми повертаємося з планом робіт і оцінкою: розбивкою на етапи, залежностями між ними і строками налаштування середовища — від мережі та серверів до моніторингу і передачі в експлуатацію.

Порядок початку робіт простий: узгоджуємо план, фіксуємо точки контролю і стартуємо з того контуру, який дає ефект раніше за інших.