Налаштування Azure: чому інфраструктура ламається на піках
Збій під піковим навантаженням рідко виглядає як сервер, що впав. Частіше це ланцюжок: трафік зріс — і вузьке місце контуру виявилося не в застосунку, а в хмарній інфраструктурі навколо нього.
Автоматичне масштабування не піднімає нові вузли, бо квоту підписки вичерпано ще під час ручних експериментів, а ліміти з’єднань балансувальника ніхто не переглядав.
Першопричина зазвичай одна — середовище, зібране вручну через портал. Налаштування живуть в інтерфейсі, а не в описі інфраструктури, правки «на хвилинку» перед релізом не потрапляють ні до сховища конфігурацій, ні до резервної копії.
За місяць ніхто не пам’ятає, навіщо відкрито правило брандмауера і чому тестове середовище розходиться з продуктивним.
Відсутність резервування додає другу точку відмови: одна зона доступності, база без репліки, секрети продубльовані у змінних збірки. У разі відмови майданчика відновлення починається з нуля і розтягується на години.
Розмиті права завершують картину: у підрядників і стажерів ролі адміністратора підписки, ключі доступу не ротуються, журнали дій ніхто не читає до інциденту. Аудит середовища майже завжди виявляє десятки зайвих дозволів і облікових записів від закритих задач.
Налаштування Azure тому починається не з увімкнення сервісів, а з аудиту середовища: що реально тримає навантаження, де конфігурація розходиться з описом і що станеться в разі відмови майданчика. Далі розбираємо, як це закривається.
Що дає лад у мережі, доступі та резервуванні
Мережу розбиваємо на ізольовані сегменти: застосунки, дані, контур керування. Правила за замовчуванням забороняють трафік, дозволи відкриваємо точково — під конкретний сервіс і порт.
Компрометація одного вузла більше не відкриває шлях до інших, і клас відмов «через периметр дісталися бази» зникає з моделі загроз.
Доступ видаємо не людям, а групам, за мінімально необхідним набором прав, а сервіси автентифікуються керованими ідентичностями замість ключів у конфігурації. Ключ нікому вкрасти й нікому забути ротувати — зникає окремий клас збоїв через розбіжні налаштування між стендами.
Резервування будуємо через зони доступності та репліку сховища в другому регіоні.
Відмова зони або регіону перестає означати зупинку сервісу: трафік переводиться на живий майданчик, застосунок продовжує працювати в режимі зниженої функціональності, а не віддає помилку всім поспіль.
Це і є передбачувана деградація замість падіння: черги згладжують пік, кеш тримає читання, обмежувачі навантаження не дають одному споживачу обвалити решту. Цільовий час відновлення вимірюється хвилинами, і ми фіксуємо його на навчаннях, а не в презентації.
На Microsoft Azure уся конфігурація описана декларативно й лежить у системі контролю версій, тому середовище відтворюється один в один на будь-якому стенді.
Раз на квартал вимикаємо зону повністю й дивимося фактичний час відновлення: цифра після кожного такого прогону або підтверджується, або стає задачею на наступний спринт.
Варіанти розміщення навантаження: машини, контейнери, сервіси
Вибір режиму розміщення визначає не лише вартість експлуатації, а й те, які задачі розв’язуються без переписування застосунку.
Перенесення навантаження між варіантами майже ніколи не буває простим переїздом: змінюються модель відмов, спосіб масштабування і те, хто відповідає за оновлення середовища.
Тому режими порівнюємо за придатністю та обмеженнями — під конкретний профіль навантаження, а не за звичкою.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Віртуальні машини | Потрібен повний контроль над середовищем, власні системні бібліотеки або ліцензоване ПО на конкретному ядрі | Масштабування вручну або напівавтоматично, оновлення ОС на нашій стороні, простій під час перестворення |
| Контейнери в керованому кластері | Сервіс із кількох компонентів, часті релізи, передбачуване горизонтальне масштабування | Потребує зрілої збірки образів і спостережуваності, навантаження зі збереженням стану дорожчі в супроводі |
| Керовані сервіси | Черги, кеш, бази, балансування — там, де платформа сама дає відмовостійкість і резервні копії | Менше контролю над налаштуваннями, прив’язка до платформи, зворотний переїзд дорожчий |
| Гібридний контур | Частина даних зобов’язана залишатися на своєму майданчику, частина виноситься в хмару | Канал між контурами стає критичним шляхом, ускладнюються маршрутизація та єдина автентифікація |
Обмеження важливіші за переваги. Віртуальні машини дають контроль, але разом із ним — рутинні оновлення та повільну реакцію на піки. Керовані сервіси знімають експлуатаційне навантаження, зате звужують простір налаштувань.
Гібридний контур закриває вимоги до місця зберігання даних, але затримки в каналі відчує кожен сервіс.
Починаємо з вимірювань: профіль звернень, добові та сезонні піки, вимоги до зберігання й відновлення, чутливість до затримок.
Потім розкладаємо компоненти за варіантами — частина переходить у керовані сервіси, частина залишається на машинах або в кластері, — і фіксуємо, що саме зміниться при зростанні навантаження.
Порядок робіт: від аудиту до передачі в експлуатацію
Порядок робіт диктує не зручність підрядника, а черговість появи ризиків: поки не зібрано інвентар, будь-яка схема — здогад, а налаштування Azure без перевірок не вважається виконаним.
Тому середовища збираються після узгодження схеми, а передача в експлуатацію — лише після перевірки відновлення.
- Аудит контуру. Інвентаризація підписок, мережевих сегментів і сервісів: що працює, хто власник, де ручні зміни й де немає резервних копій. На виході — карта залежностей і список ризиків із пріоритетом.
- Схема інфраструктури. Цільовий стан: межі підписок і груп ресурсів, сегментація мережі, точки виходу, ролі доступу та розділення середовищ. Узгоджуємо до налаштування — правка схеми дешевша за правку працюючого контуру.
- Налаштування середовищ. Розробка, тест і продуктив створюються з декларативних описів за одним шаблоном. Параметри та секрети зберігаються окремо, ручні правки в консолі виключені.
- Моніторинг і оповіщення. Збираємо метрики та журнали, задаємо пороги й маршрути сповіщень. Експлуатація починається з готовими правилами реакції, а не навпомацки.
- Перевірка відновлення. Проганяємо сценарії відмови: втрата вузла, недоступність сегмента, відновлення з копії в чисте середовище. Фіксуємо фактичний час відновлення.
- Передача експлуатації. Віддаємо доступи, документацію та регламенти, навчаємо команду: типові інциденти, порядок ескалації, точки контролю.
Що залишається у вас: схеми, політики, регламенти
Контур, який тримається на усних домовленостях, живе до відходу автора. Тому до закриття робіт ми збираємо комплект артефактів, за яким ваша команда або сторонній підрядник піднімає середовище, розбирає інцидент і змінює конфігурацію без нас. Усе зберігається у вашому репозиторії та під вашими обліковими записами в Microsoft Azure.
- Документація інфраструктури — схема підписок, груп ресурсів і мережі з адресацією підмереж і точками зв’язку з локальним контуром.
- Конфігурації як код — модулі опису обчислювальних ресурсів, сховищ і балансування з переліком вхідних значень і порядком застосування.
- Схеми резервування — зони доступності, цільові показники відновлення, розклад резервних копій і перевірений сценарій відкату.
- Регламенти доступу — ролі та їхні області дії, найменші привілеї, порядок видачі й перегляду прав, окремі сервісні облікові записи замість особистих.
- Опис ролей — власник контуру, черговий, той, хто затверджує зміни в продуктивному середовищі, і межі відповідальності підтримки.
- Інструкції для підтримки — діагностика типових відмов, де дивитися журнали й метрики, порядок дій при деградації та ескалація.
- Спостережуваність і журнал рішень — перевірки доступності з порогами оповіщень, ухвалені рішення та свідомо відкладені задачі.
Документація не пишеться «під папку»: передачу ми проводимо як приймання — середовище піднімають за нею без наших підказок.
Кейс: переїзд сервісу в хмару без зупинки роботи
Сервіс із добовим трафіком жив на ручних випусках: збірки запускалися з робочої станції інженера, доступ до середовища видавався через спільний акаунт, відкат робився вручну за внутрішньою інструкцією.
Відновлення після збою займало години: порядок дій тримався в голові однієї людини, а копія конфігурації не оновлювалася.
Що було до переїзду
Випуск займав 40–60 хвилин і вимагав нічного вікна — сервіс на цей час зупиняли. Спільний доступ дозволяв непомітно змінити бойове середовище: після інциденту ніхто не міг сказати, хто і що змінював останнім. Відмову бази відновлювали за 4–6 годин і втрачали дані за останню добу.
Як перенесли і що стало
Середовище розгорнули в Microsoft Azure за підходом «інфраструктура як код»: середовища піднімаються з опису, ручні правки в панелі керування заборонені.
Доступ роздали за ролями — збирач, відповідальний за випуск, черговий; кожна зміна проходить перевірку й залишає слід у журналі.
Переїзд ішов паралельно з роботою: трафік перемикали поступово, частки зростали за метриками, старий контур тримали готовим до підтвердження стабільності. Копії та репліку винесли в окрему зону, відновлення відпрацювали на навчаннях.
За підсумками: випуск — 6 хвилин без зупинки сервісу, відкат — одна команда, відновлення після відмови — 20–25 хвилин, втрата даних — не більше 5 хвилин, частка змін під автоматичними перевірками зросла з 20% до 95%.
Налаштування Azure з нуля або перенесення готової системи
Підхід обирають за станом системи, а не за смаком: чистий контур будують, коли навантаження ще немає; перенесення готової системи — коли працює продукт і простій неприпустимий; гібридний режим — коли частина даних зобов’язана залишитися на своєму майданчику. Далі — чим сценарії відрізняються на рівні робіт і де кожен упирається в обмеження.
У чистому контурі спочатку проєктують мережу й права, а не машини: ізольовані сегменти, єдиний вхід, окремі підписки під середовища, щоб стенд розробки не діставав до продуктивних даних.
Якщо цей шар задано відразу, ресурси додаються без перезбирання, а розмежування доступу залишається керованим.
Перенесення готової системи починається з інвентаризації та пробної реплікації в ізоляції: звіряємо поведінку, потім перемикаємо трафік.
Обмеження перенесення — прив’язка до конкретного обладнання, ліцензії під майданчик, застарілі операційні системи та служби, які тримають стан у пам’яті й не переживають коректного вимкнення. Такі вузли переносять із переробкою, а не копіюванням.
Гібридний режим означає, що частина навантаження залишається на своєму майданчику; тоді критичний сполучний канал — єдиний каталог користувачів, розв’язання імен, передбачувана маршрутизація й однакові політики доступу з обох сторін. Затримка між контурами задає, які сервіси має сенс розділяти.
Налаштування Microsoft Azure у будь-якому з трьох сценаріїв іде за одним принципом: спочатку межі, потім навантаження. Вибір підходу визначає строки й те, який клас відмов залишиться — повний простій або збій одного сегмента.
Часті технічні сумніви: доступ, мережа, резервування
Сумніви інженера до старту зазвичай ті самі: хто і як отримує доступ, як обмежити мережу, чим розділені середовища і що буде при відмові. Якщо поточної схеми немає, починаємо з інвентаризації — але базові відповіді краще зафіксувати відразу.
Як влаштовано керування доступами за десятків людей?
Права видаємо групам, а не людям: співробітник входить у групу — отримує роль, виходить — втрачає. Для сервісів використовуємо керовані ідентичності, тому ключі не лежать у конфігурації. Відкликання доступу займає хвилини, а всі дії потрапляють у журнал.
Наскільки жорстко можна обмежити мережу?
Бази та внутрішні сервіси розміщуємо в приватних підмережах — назовні вони не дивляться зовсім. Публічні точки залишаємо лише під зовнішній трафік і закриваємо правилами та списками адрес. Гібридний контур з’єднуємо захищеним тунелем до офісної мережі, без виходу у відкритий інтернет.
Як розділяються середовища, щоб тест не зачепив прод?
Тестовий контур відокремлений від промислового: свої групи ресурсів, політики й ліміти. На промисловому немає прямого ручного доступу — зміни проходять автоматизовані випуски з перевірками. Це прибирає клас відмов, коли експеримент обвалює бойовий сервіс.
Як перевіряється резервне копіювання та відновлення даних?
Політика задає частоту копій і строк зберігання для баз, дисків і конфігурацій. Головне — не наявність копій, а підтверджене відновлення на окремому стенді: фіксуємо цільовий час і точку втрати даних і перевіряємо їх навчальним відкатом.
Обговоримо задачу і повернемося з оцінкою та планом
Розмова по суті починається з вихідних даних, а не з брифу на сорок сторінок. Для налаштування середовища в хмарі достатньо того, що у вас уже є під рукою, — решту наші інженери зберуть самі й уточнять під час обговорення задачі.
- Схема поточного контуру: які сервіси працюють, де розміщені, що вже перенесено в хмару, а що залишилося на власних потужностях.
- Вимоги до середовищ: чи потрібні окремі контури під розробку, тести й промислову експлуатацію і чи мають вони бути ідентичними за конфігурацією.
- Профіль навантаження: пікові значення, сезонні сплески, вимоги до часу відгуку й цільовий режим доступності.
- Правила доступу та розмежування ролей: хто і за якою моделлю отримує доступ до ресурсів, чи є вимоги до журналювання дій і зберігання логів.
- Обмеження та рамки: жорсткі дати, вікна обслуговування, вимоги регуляторів, чинні зобов’язання перед постачальниками.
- Відповідальний інженер з вашого боку, який підтверджує рішення й приймає результат етапів.
У відповідь ви отримуєте оцінку обсягу робіт із розбивкою за етапами, план впровадження з послідовністю та залежностями, склад робіт — що закриваємо ми, а що залишається на вашому боці, — і перелік перевірок, що підтверджують готовність кожного етапу.
Якщо даних поки мало, почнемо з інвентаризації: опишіть задачу, і ми повернемося з оцінкою та планом.
