У невеликому офісі зникає електроенергія. Ноутбуки ще працюють від акумуляторів, але Wi-Fi пропав, мережева папка не відкривається, CRM видає помилку з’єднання, а Telegram-бот перестав відповідати. Водночас сайт компанії спокійно відкривається зі смартфона через мобільну мережу.
У цьому немає суперечності. Різні сервіси можуть працювати на різному обладнанні й у різних місцях. Сайт, розміщений у дата-центрі, не залежить від розетки в офісі, а CRM на локальному mini-PC залежить. Тому справжній цифровий план B починається не з купівлі UPS, а з простого запитання: від яких фізичних і мережевих ланок залежить кожний критичний сервіс?
Світло зникло на дві години: що насправді перестає працювати
Акумулятор ноутбука живить лише сам ноутбук. Інтернет при цьому може зникнути за секунду, якщо без живлення залишилися ONU, медіаконвертер, маршрутизатор або комутатор. Типовий ланцюжок виглядає приблизно так: 220 В → ONU або медіаконвертер → маршрутизатор → комутатор → NAS чи локальний сервер → робочий комп’ютер. Для збою достатньо однієї критичної ланки.
Тому симптом «ноутбук працює, але CRM недоступна» ще нічого не говорить про саму CRM. Спершу потрібно знайти, яка саме ланка випала. Якщо зникла навіть локальна Wi-Fi-мережа, варто перевірити живлення маршрутизатора або точки доступу. Якщо Wi-Fi є, але Інтернету немає, дивимося стан WAN, ONU та зовнішнього каналу. Якщо Інтернет працює, а не відкривається лише CRM, тоді вже перевіряємо сервер, на якому вона запущена.
У невеликій мережі для первинної діагностики вистачає простих інструментів: ping, tracert або traceroute, вебінтерфейс маршрутизатора, індикатори ONU, перевірка локальної IP-адреси й доступності NAS. Не треба одразу перезавантажувати все підряд. Корисніше йти від ближньої ланки до дальньої та фіксувати, на якому етапі зв’язок зникає.
Окремо варто намалювати свою схему залежностей на одному аркуші. Не «комп’ютери та Інтернет», а конкретно: де стоїть ONU, що живить маршрутизатор, де розміщений NAS, на якому пристрої працює CRM, через що співробітники під’єднуються до неї з дому. Така проста схема часто швидше показує єдину точку відмови, ніж список обладнання.
Чому сайт може працювати, коли весь офіс вимкнений
Якщо сайт розміщений у дата-центрі, відключення електроенергії в офісі саме по собі не зупиняє вебсервер. Співробітники можуть втратити доступ до своїх робочих місць, але клієнт зі смартфона й далі відкриватиме сайт, тому що запит іде через Інтернет до зовнішнього сервера, а не до офісної розетки.
Тут важливо розділяти дві речі: звідки людина керує сервісом і де сервіс реально виконується. Адміністратор може сидіти в офісі, а сайт працювати на зовнішньому хостингу. CRM може відкриватися в браузері, але бути SaaS-сервісом або працювати на VPS. Telegram-бот може керуватися з офісного ноутбука, хоча сам процес запущений на сервері в дата-центрі.
Є й зворотний сценарій. Сайт зовні доступний, але частина його функцій ламається, тому що він звертається до API, бази даних чи внутрішньої системи, яка залишилася в знеструмленому офісі. Тому перевіряти треба не лише місце розміщення фронтенду, а й залежності за ним.
Найпростіша перевірка — відкрити сервіс через мобільний Інтернет з пристрою, який не підключений до офісної мережі. Для уточнення маршруту можна використати DNS lookup, traceroute або IP lookup. ping теж корисний, але відсутність відповіді не завжди означає, що сервер недоступний: ICMP може бути вимкнений правилами безпеки.
CRM, бот, Git, NAS: що небезпечно залишати тільки всередині офісу
Ризик створює не саме локальне розміщення, а залежність критичних даних і процесів від одного приміщення або одного фізичного сервера. Локальний NAS може бути зручним і швидким, але якщо на ньому лежить єдина копія робочих файлів, відмова офісу автоматично стає відмовою сховища.
CRM
Локальна CRM перестане бути доступною, якщо вимкнувся сервер або офіс утратив зовнішній канал. Навіть співробітник, який працює з дому через VPN, не під’єднається до системи, якщо точка входу в офіс недоступна. Для CRM варто окремо знати, де лежить база, де працює застосунок і чи є спосіб доступу ззовні без офісного Інтернету.
Telegram- і Discord-боти
Месенджер може працювати без жодних проблем, а корпоративний бот — мовчати. Причина проста: Telegram або Discord доступні, але код бота запущений на офісному ПК, mini-PC чи локальному сервері, який вимкнувся. Тут перевіряти треба не месенджер, а процес або контейнер, де крутиться бот: Task Manager, systemctl, docker ps, журнали контейнера.
Робочі документи та NAS
NAS не обов’язково переносити назовні. Він цілком може залишатися основним робочим сховищем, якщо є незалежна друга копія важливих даних. Ключове слово — незалежна. Якщо основний сервер і backup підключені до однієї електромережі, стоять поруч і зникають одночасно, це дві копії, але не два незалежні рівні захисту.
Git та внутрішні вебсервіси
Локальний Git, wiki, внутрішня панель або система обліку часто здаються другорядними, поки не зникають у середині робочого дня. Варто чесно відповісти: що станеться, якщо офіс буде недоступний до вечора? Якщо команда без такого сервісу фактично зупиняється, його треба включити до аварійного плану.
Резервні копії
Статус «backup completed» ще не доводить, що дані можна відновити. Потрібно знати, де саме лежить копія, хто має до неї доступ, чи є вона поза офісом і чи проходило тестове відновлення. Корисно періодично відновлювати хоча б окремий файл або тестову копію бази: неперевірений backup — це лише припущення про можливість відновлення.
UPS допомагає, але не робить офіс автономним
UPS захищає тільки те обладнання, яке реально до нього підключене. Якщо маршрутизатор працює від акумулятора, а ONU залишився без живлення, Інтернету не буде. Якщо живі і маршрутизатор, і ONU, але обладнання провайдера в будинку знеструмлене, результат той самий.
Тому резервне живлення і доступність сервісу — різні речі. UPS може відсунути момент вимкнення NAS або mini-PC, але не створює другого каналу зв’язку і не виправляє завислий сервер. До того ж фактичний час автономної роботи залежить від навантаження, стану батареї та її віку. Цифра з коробки мало що гарантує в реальній мережі.
Правильна перевірка — контрольовано вимкнути мережеве живлення й зафіксувати, що відбувається далі. Чи залишається активним ONU? Чи бачить маршрутизатор WAN? Коли вимикається NAS? Скільки реально тримається mini-PC? Чи не перевантажений UPS? Якщо є панель моніторингу, варто записати навантаження, заряд і час роботи.
По суті, UPS не створює резервування — він лише дає час. І цей час має сенс тільки тоді, коли протягом нього продовжує працювати весь потрібний ланцюжок.
Два провайдери ще не означають, що резервний Інтернет справді незалежний
Два договори з різними операторами не гарантують двох незалежних шляхів до Інтернету. Кабелі можуть проходити однією трасою, заходити через той самий вузол у будинку або залежати від спільного живлення. На схемі це два WAN, а під час реальної аварії вони можуть зникнути одночасно.
Другий дротовий канал і мобільний резерв
Для малого офісу мобільний 4G/5G-резерв часто корисний саме тим, що фізично відрізняється від дротового каналу. Але це не робить мобільний канал безвідмовним: базова станція теж може втратити живлення або перевантажитися під час масового відключення. Після перемикання варто пройти реальний робочий сценарій: під’єднати VPN, відкрити CRM, перевірити інтеграції та віддалений доступ.
CGNAT і публічна IP-адреса
Мобільний канал може працювати через CGNAT. Для звичайного виходу в Інтернет це часто не проблема, але вхідні підключення можуть стати недоступними. Якщо корпоративний VPN, whitelist або API прив’язані до фіксованої зовнішньої IP-адреси, після переходу на мобільний канал система може перестати пускати користувачів, хоча Інтернет формально є.
DNS і VPN
DNS не замінює резервний канал. Зміна DNS-запису не допоможе офісу, який фізично втратив зв’язок. VPN теж треба тестувати окремо: після перемикання WAN може змінитися зовнішня IP-адреса, маршрут або доступність потрібного порту.
Перевірити це нескладно: фізично вимкнути основний WAN і пройти весь робочий сценарій через резервний. Треба відкрити сайти, під’єднати VPN, зайти в CRM, перевірити IP whitelist, вихід бота до API та віддалений доступ. Зелений статус другого WAN у панелі маршрутизатора ще не означає, що через нього пройде весь робочий трафік. Якщо браузер працює, а VPN — ні, failover є лише наполовину.
Симптом | Що перевіряти спочатку |
|---|---|
Wi-Fi повністю зник | Живлення маршрутизатора або точки доступу |
Wi-Fi є, Інтернету немає | WAN, ONU, зовнішній канал провайдера |
Сайт працює, CRM ні | Де розміщена CRM і від чого вона залежить |
Telegram працює, бот не відповідає | Сервер, контейнер або процес бота |
Після переходу на 4G не працює VPN | CGNAT, зовнішня IP-адреса, правила VPN |
NAS доступний, зовнішні сервіси ні | LAN працює, проблему треба шукати вище рівня локальної мережі |
Що залишити в офісі, а що краще зробити незалежним від офісу
Виносити назовні потрібно не все, а те, що має працювати без офісу. Робочі ПК і принтер природно залишаються локальними. NAS теж може залишатися в офісі. А от сайт, бот, який приймає заявки цілодобово, або CRM, потрібна віддаленим співробітникам, не повинні критично залежати від одного офісного mini-PC.
Коли критичний сервіс працює за межами офісу, хостинг-провайдер стає ще однією ланкою в схемі залежностей: варто заздалегідь з’ясувати, де розташований майданчик, чи доступне резервне копіювання та які умови відновлення після збою. Це не скасовує власного плану резервування, але допомагає зрозуміти, де саме закінчується ваша зона відповідальності й починається зовнішня інфраструктура.
Сервіс | Локально в офісі | Зовнішня інфраструктура | Раціональна схема |
|---|---|---|---|
Робочі ПК | Так | Ні | Залишити локально |
Принтер | Так | Ні | Локально |
Сайт | Можливо, але з високою залежністю від офісу | Так | Зазвичай зовнішній сервер |
Telegram-бот | Можливо | Так | Зовні, якщо потрібна робота 24/7 |
CRM | Можливо | Так | Залежить від сценарію доступу |
Спільні документи | Можливо | Так | Локальна, хмарна або гібридна схема |
NAS | Так | Не обов’язково | Основне сховище плюс зовнішня копія |
Backup | Одна копія можлива | Бажано | Щонайменше дві незалежні копії |
Критерій вибору простий: якщо сервіс має залишатися доступним, коли офіс повністю знеструмлений і відрізаний від Інтернету, він не повинен мати єдину критичну залежність усередині цього офісу.
Мінімальна схема плану B для малого офісу без enterprise-інфраструктури
Для невеликої компанії не потрібні два дата-центри, BGP або складний кластер. Мінімальна практична схема — резервне живлення критичного мережевого обладнання, альтернативний канал Інтернету та винесення тих сервісів, які мають працювати 24/7, за межі офісу.
В офісі
- ноутбуки або ПК;
- маршрутизатор;
- ONU або медіаконвертер;
- за потреби NAS;
- UPS для критичного мережевого обладнання.
Для доступу в Інтернет
- основний дротовий канал;
- мобільний резерв;
- перевірений dual-WAN або зрозуміла ручна процедура перемикання.
Поза офісом
- сайт;
- CRM, якщо вона потрібна під час відключення;
- Telegram-бот, якщо він повинен приймати заявки постійно;
- друга резервна копія критичних даних.
Потім корисно подумки «викреслити» весь офіс. Чи відкриється сайт для клієнта? Чи отримає бот повідомлення? Чи зайде співробітник у CRM через мобільний Інтернет? Чи залишиться доступ до останньої резервної копії? Якщо на ці запитання є чіткі відповіді, схема вже набагато корисніша за набір обладнання без перевіреного сценарію.
План B варто оцінювати не за кількістю UPS, роутерів або модемів, а за тим, які бізнес-функції залишаються доступними після втрати офісу. Локальний принтер у цей момент цілком може не працювати — це нормально. А от збереження нових заявок або доступ до критичної CRM може бути принциповим.
Тест «офіс зник»: як перевірити план B до справжнього відключення
Неперевірений резерв — це поки що лише припущення. Можна окремо переконатися, що UPS заряджений, 4G працює, backup створюється, а VPN під’єднується. Але справжня аварія перевіряє все одночасно. Саме тому разовий контрольований тест дає більше користі, ніж десять зелених індикаторів у різних панелях.
Проводити такий тест краще у спокійний час, коли коротка недоступність не створить проблем клієнтам. Завдання не в тому, щоб штучно «покласти» офіс, а в тому, щоб пройти реальний сценарій і побачити приховані залежності.
- Запишіть усі критичні сервіси.
- Визначте, де фізично працює кожен із них.
- Перевірте, що відбудеться після вимкнення 220 В.
- Перевірте автономність ONU та маршрутизатора.
- Вимкніть основний WAN.
- Дочекайтеся автоматичного failover або виконайте ручне перемикання.
- Перевірте зовнішню IP-адресу.
- Перевірте VPN.
- Відкрийте CRM.
- Надішліть тестове повідомлення Telegram-боту.
- Відкрийте сайт через мобільну мережу, а не через офісний Wi-Fi.
- Перевірте доступність робочих документів.
- Знайдіть останню успішну резервну копію.
- Переконайтеся, що відома процедура її відновлення.
- Запишіть фактичний час автономної роботи.
- Зафіксуйте, хто відповідає за кожний тип збою.
Хороший результат тесту — не обов’язково «усе працює». Набагато корисніше знайти конкретну залежність до реальної аварії. Наприклад, після вимкнення основного WAN маршрутизатор успішно перейшов на 4G, браузер відкриває сайти, але CRM не пускає користувачів, бо доступ дозволений лише з колишньої зовнішньої IP-адреси. Це вже не абстрактний ризик, а задача, яку можна виправити до реального відключення.
План B можна вважати робочим, якщо під час тесту заздалегідь визначений набір бізнес-функцій залишається доступним. Не обов’язково рятувати кожен пристрій у приміщенні. Потрібно знати, що саме має пережити втрату офісу, через які канали воно працюватиме і як команда перевірить це без здогадок.
