Існують фахівці, що зводять будівлі, а існують ті, хто приходить, коли споруда вже лежить у руїнах.
Друга спеціальність зветься рятувальною інженерією — дисципліна на межі будівельної та геотехнічної галузей. Такі фахівці визначають, скільки навантаження здатна витримати зруйнована конструкція, встановлюють тимчасові підпори та постійно стежать за рухом стін, аби рятувальна команда могла працювати всередині без ризику стати наступною жертвою. У Сполучених Штатах цей напрям інтегрований у систему FEMA Urban Search and Rescue, а на глобальному рівні координується через INSARAG.
Сам я до цієї професії стосунку не маю — моя компанія займається хмарною інфраструктурою: DevOps, міграціями, Kubernetes, питаннями надійності та відновлення після аварій. Проте переважна більшість наших проєктів стартує не з чистого аркуша, а з уже пошкодженої чужої конструкції. Це прод, що валиться щотижня. Міграція, застигла на половині шляху. Кластер, у який ніхто не наважується щось вносити. Хмарний рахунок, що потроївся за квартал без жодного пояснення всередині компанії.
У кожному такому випадку наша логіка повторює дії rescue-інженерів: спочатку з’ясовуємо, що система витримує прямо зараз, монтуємо тимчасові опори, запускаємо моніторинг — і тільки потім шукаємо причину поломки.
Що довше я працюю в цій сфері, то більше переконуюсь: модель рятувальної інженерії описує бізнес-реальність точніше, ніж більшість управлінських фреймворків, яким нас навчали.
Дві інженерні культури
Традиційна інженерія орієнтована на стабільність — статична рівновага, довговічність, запас міцності, розрахунковий термін експлуатації. В основі лежить припущення, що умови відомі, навантаження прогнозовані, а часу достатньо.
Рятувальна інженерія діє у протилежних умовах: конструкція вже не та, що була на кресленні, навантаження перерозподілилося невідомо як, дані неповні, а час обмежений.
Останні тридцять років менеджмент прищеплював нам саме першу культуру — ефективність, оптимізацію, lean-підходи, мінімізацію запасів і максимальне завантаження ресурсів. Для стабільного світу це була логічна відповідь. Але світ почав регулярно створювати умови, для яких ця культура не пристосована: пандемія, зриви ланцюгів постачання, повномасштабна війна, енергетична криза, багатогодинні падіння глобальних хмарних провайдерів, кібератаки, що паралізують логістику цілих держав.
Ми й досі керуємо бізнесом як проєктувальники, хоча умови вимагають мислення рятувальників.
- Що витримає система після відмови вузла, регіону чи провайдера
- Скільки бізнес протримається без найбільшого клієнта або ключового фахівця
- Класифікація критичності інциденту та перелік заборонених дій під час збою
- Відкат, перемикання чи зниження навантаження до завершення діагностики
- Чи дізнаємося ми про проблему раніше за клієнта
- Резервні копії, репліки, мультирегіональність, перевірені процедури відновлення
- Вартість альтернативного шляху і хто уповноважений його затверджувати
Залишкова несуча здатність
Перше, що робить інженер на місці завалу, — оцінює не те, якою будівля була раніше, а те, що вона витримує зараз.
У бізнесу аналогічного показника немає. Ми відстежуємо виручку, EBITDA, число клієнтів, завантаженість команди — усе це метрики справної системи. Жодна з них не відповідає на питання: скільки витримає компанія, якщо завтра зникне найбільший клієнт, ключовий інженер, регіон чи провайдер.
В інфраструктурі на це питання є конкретні відповіді, які ми шукаємо під час кожного технічного аудиту: скільки вузлів може відмовити до того, як кластер перестане обробляти трафік; що відбудеться, якщо зона доступності зникне на дві години; чи підніметься система після видалення половини середовища і за який термін; скільки людей у компанії взагалі здатні це зробити.
Відповідь майже завжди гірша, ніж очікує керівництво, і причина зазвичай не технічна. Компанія з бездоганним P&L може мати нульовий запас стійкості, якщо вся маржа тримається на одному контракті, вся експертиза — на трьох людях, уся інфраструктура — в одному регіоні одного провайдера, а всі процеси існують лише в голові операційного директора.
Запас — це не марнотратство
У рятувальному шорингу дерев'яні підпори мають значно менший запас міцності, ніж капітальні конструкції, бо їх монтують за лічені хвилини з підручних матеріалів. Компенсують це інженери закладанням бічних навантажень: кожна вертикальна опора мусить витримати не лише вагу згори, а й бічний поштовх — той самий, якого немає в розрахунках, але який створює афтершок.
Бізнес, навпаки, систематично зрізає саме цей запас. Кожен раунд оптимізації забирає те, що видається зайвим: другого фахівця в напрямку, документацію, резервний майданчик, час на навчання, тестування відновлення. У квартальному звіті це виглядає як чиста економія, а з погляду стійкості — як демонтаж бічних розпірок.
Тут варто уточнити одну річ, бо оптимізація хмарних витрат — один із наших основних напрямів роботи, і я щодня раджу клієнтам витрачати менше.
Різниця між оптимізацією і демонтажем запасу залежить від того, чи розумієте ви, де насправді проходить навантаження.
Наведу приклад із власної практики. У одного клієнта левову частку рахунку в Azure з'їдав балансувальник навантаження та мережевий трафік. Ми не урізали ресурси й не прибирали резервування — натомість винесли файловий ресурс на приватний ендпоінт у тій самій віртуальній мережі, де працювали вузли AKS, і трафік перестав проходити через балансувальник. Мережеві витрати впали на 90%, що дало економію до 400 доларів на день. Система при цьому не стала вразливішою, бо прибрали не запас, а помилковий маршрут навантаження.
Зустрічаємо ми й зворотний сценарій: команда «оптимізує» витрати, вимикаючи staging-середовище, репліку в другому регіоні та зберігання логів. Рахунок справді зменшується, але справжня ціна цього рішення проявляється під час першого ж серйозного збою — і вона на порядок перевищує отриману економію.
Стійкість коштує грошей. Це окрема стаття витрат, яку слід свідомо закладати в бюджет. Компанії, що уникають цього рішення, зрештою платять ту саму суму — тільки пізніше, раптово і за значно гіршим курсом.
Тріаж: мистецтво вирішувати, що не рятувати
Найскладніше в рятувальній інженерії — не розрахунки, а тріаж.
На обстеження однієї зруйнованої будівлі фахівцю відводять не більш як п'ятнадцять хвилин, на весь сектор — дві години. За цей час треба визначити, де ймовірність знайти живих вища і де конструкція взагалі дозволяє увійти. Будівлю, яка загрожує обвалом і не піддається стабілізації наявними засобами, позначають як «No Go» — вхід заборонено, доки не прибуде спеціальне обладнання.
Це рішення стосується не технологій, а розподілу обмеженого ресурсу в ситуації, коли врятувати все неможливо.
У роботі з інцидентами ми застосовуємо майже те саме правило. Перші десять хвилин присвячуємо не пошуку причини, а трьом питанням: наскільки все серйозно, кого зачепило і хто зараз приймає рішення. Далі йде власний перелік заборонених дій — наш «No Go»: не проводимо міграцій схеми, не перезапускаємо primary з відставанням реплікації, не редагуємо вручну те, чим керує Terraform. Цей перелік складають заздалегідь, а не під час самого падіння (Backup and Disaster Recovery).
Більшість бізнес-криз — це теж кризи тріажу, а не компетенції. Коли падає ринок або зривається великий контракт, команда зазвичай розуміє, що робити технічно. Чого бракує — так це рішення керівництва про пріоритети: який продукт зараз не рятуємо, який сегмент відпускаємо, які зобов'язання переглядаємо в першу чергу.
Замість тріажу керівники часто обирають рівномірне ослаблення: урізати всім по 20%, заморозити все, працювати трохи менш інтенсивно над усіма напрямами одразу. Виглядає справедливо, але це найгірший із можливих варіантів. Рятувальник, який розподілить зусилля порівну між усіма завалами сектору, не врятує нікого.
Спершу стабілізувати, потім розбиратися
У траншейних рятувальних роботах є непорушне правило: ніхто не спускається в траншею, доки стінки не закріплені зовнішніми розпірками. Ґрунт, що вже рухався, зрушить знову, і другий обвал накриє саме тих, хто прийшов рятувати.
В інфраструктурі це правило порушують постійно. Інженери діагностують живу систему, поки вона падає: читають логи під час зростання кількості помилок, профілюють под, який щохвилини прибиває OOM killer. Керівництво тим часом скликає наради про причини, поки ситуація ще розвивається.
Порядок дій має бути зворотним: спочатку стабілізація, потім аналіз. Відкотити останній реліз, перемкнутися на репліку або інший регіон, обмежити навантаження, вимкнути функціонал через feature flag. Пошук першопричини — завдання постмортему, а не перших хвилин.
Є ще одна деталь, яку рятувальники знають краще за нас: конструкцію документують до того, як її змінюють. Перезапуск усуває збій і водночас стирає його сліди. Тому знімки стану, логи й вікно метрик фіксують до рестарту. В управлінні діє та сама логіка: факти, цифри й хронологію подій треба зафіксувати до того, як почнеться природний процес переписування історії.
Спільна мова важливіша за героїзм
Рятувальні команди з різних країн передають одна одній об'єкт без довгих пояснень, бо існує стандартизована система маркування: ідентифікатор об'єкта, команда, рівень обстеження, дата, виявлені небезпеки, категорія тріажу, стрілка до входу. Японська команда приїжджає після турецької — і зчитує ситуацію за десять секунд.
Це не бюрократія, а інфраструктура довіри, що дозволяє працювати разом людям, які ніколи раніше не зустрічалися.
У компаніях цю роль мають виконувати документація, runbook'и, чітке розмежування зон відповідальності та регламенти ескалації. Саме ці елементи програють боротьбу за увагу, бо в спокійні періоди не створюють видимої цінності.
Натомість формується культура, де стійкість тримається на конкретних особах: «Олег знає, як це піднімати». Поки Олег на місці, усе виглядає гаразд. Компанія просто не помічає, що її несуча конструкція — це одна людина.
Скажу прямо: героїзм і незамінність окремих фахівців у команді майже завжди свідчать про відсутність нормальної інженерії. Тому в наших проєктах документація та передача знань команді клієнта виділена в окремий етап — не формальність наприкінці, а частина результату. Проєкт, після якого систему може підтримувати лише підрядник, я вважаю невдалим.
Кілька свердловин одночасно
У 2010 році в Чилі під завалом на глибині приблизно 700 метрів опинилися 33 шахтарі. Рятувальна операція велась одразу за трьома незалежними бурильними планами. Спрацював план «B». Два інших не були витраченими даремно зусиллями — саме завдяки їм одна невдача не могла зупинити весь порятунок.
У корпоративній логіці паралельні плани здаються нераціональними: навіщо фінансувати три шляхи, якщо потрібен лише один. Відповідь проста — заздалегідь невідомо, який саме спрацює.
Український бізнес засвоїв це не з підручників. З 2022 року компанії тут живуть із дубльованими офісами, розподіленими командами, генераторами, супутниковим зв'язком, планами релокації, які не знадобилися, і планами, які знадобилися вже наступного дня.
Один із наших проєктів — інфраструктура для медичної ініціативи національного масштабу: спільна база медичних історій, рецептів і страхової інформації для медичних центрів по всій країні. Ми розгортали її на обладнанні локального провайдера з використанням VMware ESXi та Terraform, інтегрували з державною платформою eHealth і застосовували маскування даних у середовищах розробки й тестування для відповідності вимогам GDPR та HIPAA. У такій системі питання «а що, якщо майданчик стане недоступним» не є теоретичним — його потрібно вирішити на етапі проєктування, бо в момент збою вирішувати вже нічим.
Здатність працювати в умовах постійної нестабільності — це не історія про витривалість українців, а набута інженерна компетенція, якої в більшості ринків немає й не буде, поки їм це не доведеться пройти самим. Але активом вона стає лише тоді, коли задокументована й перевірена: політики безперервності, плани відновлення, стандарти на кшталт ISO 27001 та 22301, регулярні навчання. Інакше вона залишається гарною історією для зустрічі з клієнтом, а не пунктом у контракті.
План, який ніколи не перевіряли, — це лише припущення
Капсула, якою піднімали чилійських шахтарів, мала люк у днищі на випадок, якщо вона застрягне у стовбурі й людині доведеться спускатися назад. Інженери заздалегідь припускали, що основний план може не спрацювати.
Це, напевно, найкорисніша управлінська звичка з усіх перелічених: проєктувати шлях відступу для кожного рішення. Не тому, що чекаєте на провал, а тому, що вартість цього шляху під час планування мізерна, а під час кризи — недосяжна.
У більшості аудитів, які ми проводимо, плани відновлення ніколи не перевірялися на практиці. Резервні копії існують, але хто і за скільки годин підніме з них систему — невідомо. Перше ж навчальне відновлення зазвичай виявляє відсутній ключ, недокументовану залежність або термін відновлення, що втричі перевищує обіцяний бізнесу.
Те саме стосується не лише даних. План заміни ключового фахівця, план виходу з-під залежності від одного великого клієнта, план зміни провайдера — або вже перевірені, або їх фактично не існує.
Що це означає для керівника
Декілька простих, але незручних тез.
- Стійкість — це стаття витрат, а не риса характеру. Її треба затверджувати бюджетом, а не очікувати від команди.
- Ефективність і стійкість конфліктують між собою. Оптимізувати варто маршрут навантаження, а не запас міцності. Різницю між цими двома діями визначає наявність аудиту, що показує, де навантаження проходить насправді.
- Тріаж — компетенція керівника, а не кризовий рефлекс. Її напрацьовують заздалегідь: критичні бізнес-процеси, допустимий час простою для кожного з них, порядок пріоритетів під час кризи.
- Порядок дій у кризі незмінний: спочатку стабілізація, потім аналіз. Пошук винних у момент падіння — це другий обвал, що накриває тих, хто прийшов рятувати.
- І насамкінець: перевіряйте. План, який ніколи не випробовували в навчальному режимі, — це сподівання, оформлене як документ.
До нас клієнти приходять у двох станах: або інфраструктура вже горить, або хтось із керівництва поставив собі запитання, що станеться, коли вона загориться. Технічно робота однакова. Різниця лише в грошах.
Рятувальна інженерія існує, бо будівлі падають. Вона не робить їх незруйновними — вона робить наслідки керованими. Для бізнесу, що працює в країні, де слово «стійкість» має буквальне значення, це правильна модель мислення: не сподіватися, що нічого не впаде, а заздалегідь знати, що і в якому порядку ви триматимете.
Автор — Федір Компанієць, CEO та співзасновник Gart Solutions. Компанія спеціалізується на DevOps, хмарних рішеннях та інфраструктурі: міграціях, Kubernetes, надійності, оптимізації витрат і відновленні після збоїв. У портфелі команди — понад 50 реалізованих проєктів, середній досвід інженерів становить 8,2 року.
Джерело: IT Ukraine Association
