Хмарна інфраструктура Selectel: де ламається
Хмарна інфраструктура Selectel влаштована так, що нею легко керувати вручну: сервери, мережі, балансувальники та сховища піднімаються з панелі за хвилини.
Проблема починається пізніше — частина середовищ описана в регламенті, частина живе в голові інженера, а частина правилася вночі в терміналі, коли горіло.
Так з'являється дрейф конфігурації: фактичний стан перестає збігатися з описаним, і ніхто не може назвати точку, де вони розійшлися.
Ціна розходження проявляється в найневдаліший момент. Планова зміна — зміна розміру сервера, перенесення підмережі, правка правил доступу — роняє прод, бо залежності між сервісами ніде не зафіксовані.
Непередбачувана мережа добиває: маршрути та групи безпеки правляться точково, і кожен такий дотик перетворюється на окремий ризик простою через зміни.
Звідси ж — відтворюваність. Тестовий контур не повторює продуктивний, тому перевірка перед релізом нічого не доводить, а відкат після невдалого оновлення робиться вручну і по пам'яті.
Чим більше середовищ, тим дорожче дається ручне керування серверами: інженери витрачають час не на розвиток продукту, а на відновлення того, що вже працювало.
Розбираємо, як це закривається: який стан інфраструктури вважається еталонним, як перевіряється розходження з ним і що дає опис середовища замість набору ручних дій.
Що змінюється після переведення сервісів у керовану хмару
Переїзд у керовану хмару змінює не склад сервісів, а спосіб роботи з інфраструктурою. Конфігурація перестає бути набором ручних дій у панелі й описується як код: файли живуть у репозиторії, проходять перевірку та застосовуються однаково для стенда й робочого контуру.
У Selectel це лягає на нативні ресурси провайдера — мережі, балансувальники, кластери описуються тими самими файлами, що й застосунок.
Перший вимірюваний ефект — швидкість випуску змін. Середовище розгортається однією командою, розходження середовищ видно на етапі перевірки, а не в момент релізу, і кожна зміна відкочується до попереднього опису. Частота випусків зростає без зростання кількості відкатів.
Час відновлення сервісу перестає залежати від швидкості чергового інженера.
Вузол, що впав, перестворюється з опису, трафік іде на живі екземпляри, стан підтягується з реплік — типовий збій закривається без ручного втручання, і в простої залишаються хвилини замість годин діагностики.
Зникає й цілий клас відмов, породжених ручними правками: налаштування оновили не на всіх серверах, доступ видали лише одному стенду, порядок дій розійшовся з документацією.
Декларативний опис знімає саму можливість такого розходження, а частка ручних операцій падає до правок самих описів.
Відмовостійкість при цьому перестає бути властивістю окремих машин: вона закладається схемою розміщення за зонами й перевіряється навчаннями з відключення вузла.
Варіанти розгортання: хмарна інфраструктура чи свої сервери
Розгортання в хмарі — не вибір із двох полюсів, а шкала між контролем і обсягом обслуговування. Керовані сервіси закривають бази даних, черги та об'єктне сховище: провайдер відповідає за відмовостійкість та оновлення, команда — за схему й запити.
Власні віртуальні машини дають повний доступ до операційної системи та мережі, але оновлення, резервне копіювання та моніторинг залишаються на вашому боці.
Між ними — гібридна схема та виділені потужності. Гібрид залишає дані у своєму контурі, а веб-шар і обробку виносить у хмару; виділені потужності беруть там, де навантаження передбачуване й важлива ізоляція.
Обмеження кожного режиму проявляються на конкретному профілі навантаження, тому дивимося на нього, а не на модність підходу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Керовані сервіси | Навантаження змінюється, потрібен швидкий старт, команда невелика | Частина налаштувань недоступна, прив'язка до API провайдера |
| Власні віртуальні машини | Потрібні свої версії, агенти, нестандартна топологія мережі | Оновлення, резервні копії та моніторинг — на вашому боці |
| Гібридна схема | Дані мають залишитися у своєму контурі | Два контури: складніша мережа та єдина спостережуваність |
| Виділені потужності | Передбачуване високе навантаження, вимоги до ізоляції | Довше введення, ресурс простоює при спаді |
Кожен варіант описуємо конфігураціями в репозиторії: один набір описів розгортає і керовані сервіси, і машини, і гібрид, тому зміна режиму не означає переписування проєкту.
У хмарній інфраструктурі Selectel ми збирали всі чотири схеми й знаємо, де починаються обмеження провайдера.
Порядок робіт: від аудиту до передачі в експлуатацію
Роботи йдуть фіксованими етапами, і кожен закривається артефактом: конфігурацією, схемою або звітом про перевірку. Замовник у будь-який момент бачить, на якому кроці перебуває хмарна інфраструктура Selectel і що вже прийнято в роботу — без очікування фінальної презентації.
- Аудит інфраструктури. Інвентаризуємо, що де запущено, які сервіси пов'язані між собою, де залишилися ручні операції та єдині точки відмови. На виході — карта поточного стану з переліком ризиків і пріоритетами.
- Схема мережі та цільового середовища. Фіксуємо сегментацію, правила доступу, маршрутизацію між підмережами та резервні копії. Схема погоджується до початку налаштування, щоб не переробляти середовище по ходу.
- Опис середовища як коду. Конфігурація зберігається в репозиторії, а не в чек-листах: середовище піднімається з опису й відтворюється один в один — тестове повторює продуктивне.
- Перевірка під навантаженням. Проганяємо сценарії на піковому профілі, дивимося час відгуку та поведінку при відмові окремого вузла. Знайдені вузькі місця усуваємо до перенесення, а не після.
- Міграція сервісів. Переносимо групами, починаючи з некритичних, із зворотним перемиканням на колишній майданчик. Дані переносяться з перевіркою цілісності та звіркою контрольних сум.
- Документування. Регламенти відновлення, схеми, інструкції для чергової команди та порядок внесення змін — те, за чим середовище живе без нас.
- Передача в експлуатацію. Віддаємо доступи, проводимо навчання команди, фіксуємо відповідальних за зміни. Далі залишаємося на зв'язку щодо планових доопрацювань.
Такий порядок прибирає головний ризик інфраструктурних проєктів — коли середовище працює, але ніхто не розуміє, як його лагодити й змінювати.
Комплект передачі: схеми, політики доступу, регламенти
Комплект збирається по ходу робіт, а не після здачі: кожен крок фіксується в документації та в описі конфігурації, тому середовище можна розгорнути заново, не відновлюючи логіку по пам'яті. Нижче — що саме замовник отримує на руки разом із працюючою інфраструктурою в хмарі Selectel.
- Схема інфраструктури — мережі та підмережі, точки виходу назовні, розподіл ролей між серверами, зв'язки між сервісами та те, яка зона відмовляє ізольовано. Схема відображає реальний стан, а не проєкт.
- Опис конфігурації як коду — репозиторій, з якого середовище піднімається повторно. Зміни проходять перевірку перед застосуванням, однотипні середовища перестають розходитися між собою.
- Політики доступу, ролі та права — що доступно людині, що сервісу, які облікові записи окремі, а де спільний доступ неприпустимий. Відкликання прав при звільненні співробітника виконується однією дією.
- Порядок резервного копіювання — що копіюється, з якою частотою, яка глибина зберігання і де лежать копії. Окремо фіксується, як перевіряється відновлення і скільки часу займає відкат.
- Регламенти експлуатації — оновлення образів, планові роботи, порядок внесення змін, реакція на відмову та точки, де потрібне підтвердження власника сервісу.
- Інструкції для чергового — що дивитися при перших ознаках збою, куди ескалювати, які дії безпечні без погодження.
- Передача команді — розбір устрою на дзвінку, видача доступів і відповіді на питання щодо документації, поки ваші інженери не почнуть вести середовище самі.
Кейс: переїзд сервісів без зупинки роботи
Вихідний стан: десятки віртуальних машин, налаштованих вручну. Конфігурація кожного середовища відрізнялася, зміни вносилися вручну на живих серверах і ніде не фіксувалися — відновити логіку стенда після звільнення інженера було нічим.
Відкат після невдалого релізу означав розгортання знімка та ручне доналагодження, тобто години простою в найгірший момент.
Перенесли навантаження в описане середовище на Selectel: інфраструктура перестала бути набором живих серверів і стала описом у репозиторії.
Середовища піднімаються з одного набору файлів із параметрами, стан звіряється з описом автоматично, а розходження видно до викатки, а не після.
Метрики до та після
| Показник | До | Після |
|---|---|---|
| Розгортання середовища під задачу | два дні ручної роботи | 25 хвилин |
| Відкат релізу | відновлення знімка, години | перемикання трафіку, хвилини |
| Розходження налаштувань між середовищами | шукали вручну | ловиться автоматично |
Переїзд ішов без простою: дані реплікувалися на нове середовище, трафік перемикався у вікно мінімального навантаження, стара схема залишалася робочою до підтвердження метрик.
План відкату був прописаний заздалегідь — зворотне перемикання за один крок, без відновлення з архівів і повторного налаштування серверів.
Що робити, якщо частина сервісів уже на своїх потужностях?
Гібридна інфраструктура — робочий стан, а не перехідний костиль: частина сервісів залишається на своїх потужностях, частина йде в хмару.
На своїх зазвичай тримають те, що прив'язане до даних, ліцензій або вже купленого обладнання, а в хмару виносять зростаюче навантаження та сервіси з частими релізами. Перевозити все відразу не потрібно — достатньо пов'язати майданчики так, щоб вони працювали як одна система.
Зв'язок між майданчиками будуємо на приватному сегменті: шифровані тунелі поверх публічних каналів або виділена лінія, якщо є вимоги до затримки.
Адресні простори плануємо без перетинів, маршрути прописуємо явно, а трафік між сервісами йде за приватними адресами й не виходить в інтернет. Канали резервуємо: при обриві одного маршруту другий підхоплює трафік автоматично.
Єдина точка входу прибирає головну складність гібрида: застосунку не потрібно знати, на якому майданчику живе його частина.
На вході ставимо балансувальник із перевірками доступності, за ним — сервіси обох майданчиків; короткий TTL у DNS переводить трафік на новий майданчик за хвилини. Внутрішні системи та користувачі звертаються до однієї адреси, тому перенесення не потребує правок на їхньому боці.
Поступова міграція йде хвилями за класом сервісу. Спочатку переносимо сервіси без локального стану: зібрати образ, описати конфігурацію кодом, погасити старий вузол.
Потім сервіси з даними: вмикаємо реплікацію, читаємо з копії, звіряємо розходження й перемикаємо запис у коротке вікно. Кожен крок оборотний — старі потужності залишаються в строю й приймають навантаження назад, якщо метрики пішли не туди. Так гібрид збирається за кілька ітерацій, без зупинки продукту.
Часті технічні питання: доступ, безпека, відкат
Доступи, резервні копії та межі відповідальності перевіряють до старту, а не після першого збою.
Нижче — відповіді на те, що найчастіше спливає на погодженні: як розмежовано доступ до хмарної інфраструктури Selectel, що залишиться у вашої команди після проєкту і як відновлюється контур.
Як розмежовується доступ до інфраструктури?
За принципом найменших привілеїв: кожен інженер працює під своїм обліковим записом, автоматизація — під окремими сервісними ключами з обмеженим набором прав. Доступ до продуктивного контуру є тільки в чергових, усі дії потрапляють до журналу аудиту. Ключі не передаються в листуванні й змінюються при зміні складу команди.
Що буде з нашими обліковими записами після проєкту?
Власником акаунта залишаєтеся ви — ми працюємо як запрошені учасники зі своїми ролями. Під час передачі ми відкликаємо свої доступи, ротуємо ключі автоматизації та віддаємо список активних облікових записів з описом прав. Окремо фіксуємо, які сервісні ключі потрібно перевипустити.
Як влаштовані резервні копії та чи перевіряється відновлення?
Копії знімаються за розкладом, зберігаються окремо від основного контуру, щоб збій майданчика не забрав і дані. Ключове — не наявність копій, а регулярна перевірка: розгортаємо контур з копії та заміряємо час до робочого стану. Без такої перевірки резервна копія вважається неготовою.
Який план відновлення після збою?
Уся інфраструктура описана кодом у репозиторії, тому контур відтворюється з нуля, а не збирається вручну. Є регламент реагування з пріоритетами сервісів і порядком дій чергового. Такий підхід прибирає клас відмов, де відновлення залежить від пам'яті конкретного інженера.
Де межа відповідальності підрядника?
Ми відповідаємо за інфраструктурний код, конфігурацію, автоматизацію та відновлення контуру. На вашому боці — бізнес-логіка застосунку, дані та володіння хмарним акаунтом. Межу фіксуємо письмово до старту, щоб при збої не з'ясовувати, чия це ділянка.
Обговоримо задачу і повернемося з оцінкою та планом
Чим конкретніші вхідні дані, тим менше уточнюючих кіл і тим точніша оцінка проєкту. Надсилайте не «хочемо в хмару», а зріз поточного стану: що вже працює у провайдера, що залишилося на власних машинах, як сервіси спілкуються між собою.
- Схема сервісів і зв'язків між ними — навіть начерк від руки або список без деталей краще, ніж нічого.
- Профіль навантаження: пікові періоди, сезонність, вимоги до доступності та часу відновлення.
- Скільки потрібно середовищ (розробка, тест, продуктив) і чим вони відрізняються за складом.
- Обмеження: вимоги безпеки, внутрішні нормативи, чинні договори з постачальниками.
- Порядок видачі доступів: хто погоджує, чи потрібен окремий обліковий запис для автоматизації.
- Больові точки: де зараз ручні операції, що найчастіше ламається, які задачі забирають час.
- Бажані терміни: дата запуску та вікна, у які допустимо проводити міграцію.
У відповідь ви отримуєте план впровадження з розбивкою на етапи: інвентаризація та цільова схема, опис інфраструктури як коду в репозиторії, пілот на одному контурі, перенесення решти, передача супроводу. До кожного етапу — склад робіт, терміни та те, що потрібно від вашого боку.
Окремо погоджуємо схему взаємодії: один канал зв'язку, відповідальні з обох боків, регулярна звірка статусу.
Опишіть задачу у вільній формі — повернемося з оцінкою та планом.
