Коротка відповідь: Моніторинг ІТ-інфраструктури має охоплювати робочі станції, сервери, мережу, резервні копії, корпоративні служби та події безпеки. Недостатньо збирати зелені графіки: кожне сповіщення має пояснювати, що перестало працювати, кого це стосується і хто повинен реагувати.
Моніторинг має відповідати на чотири запитання
Чи працюють у співробітників інструменти, необхідні для роботи? Чи має компанія дані, які можна відновити? Чи наближається проблема з місткістю, підтримкою обладнання або строком дії сертифіката? І хто опрацює сповіщення, коли щось вийде з ладу?
Практичний моніторинг, наприклад, повідомить, що:
- резервне копіювання не виконалося протягом кількох запланованих запусків;
- системний диск швидко заповнюється;
- антивірус або EDR перестав передавати дані про стан;
- дисковий масив NAS перебуває в деградованому стані;
- філія втрачає зв’язок із центральним офісом;
- вебсайт відповідає, але вхід до застосунку не працює;
- TLS-сертифікат не оновився;
- створено новий обліковий запис із правами адміністратора.
Перш ніж установлювати засоби моніторингу, компанія має знати свої пристрої, служби та залежності між ними. Виявити прогалини в інвентаризації допоможе ІТ-аудит малої компанії. Без нього легко контролювати сервер у технічному приміщенні, залишивши поза увагою ключову базу даних, хмарний обліковий запис або сховище резервних копій.
Що контролювати на робочих станціях, серверах і в мережі
Кожна перевірка має бути пов’язана з реальною роботою систем. Короткочасний пік завантаження процесора не обов’язково свідчить про проблему, а відповідь на ping не доводить, що застосунок приймає вхід користувачів або записує дані до бази.
| Сфера | Що контролювати | Що має спричинити реакцію |
|---|---|---|
| Робочі станції та ноутбуки | доступність агента адміністрування, версію системи, оновлення, антивірус або EDR, шифрування та вільне місце | вимкнений захист, пристрій, який тривалий час не виходить на зв’язок, помилки оновлення, непідтримувану систему або нестачу місця |
| Сервери | служби, використання процесора й пам’яті в динаміці, швидкість відгуку дисків, місткість, журнали, RAID, UPS і віртуальні машини | зупинену службу, збільшення часу відгуку, деградований масив, неочікуване перезавантаження або несправне резервне живлення |
| Мережа | підключення до інтернету, firewall, VPN, комутатори, точки доступу, втрати пакетів, помилки портів і зміни конфігурації | недоступну філію, повторні розриви VPN, несправний канал, перебій живлення або незаплановану зміну |
| Корпоративні служби | DNS, вебсайт, електронну пошту, базу даних, бухгалтерську чи ERP-систему та спільні файли | помилкову відповідь, несправний вхід, відхилене з’єднання, зупинення обробки або перехід сховища в режим лише для читання |
| Ідентифікаційні дані | стан синхронізації, багатофакторну автентифікацію, привілейовані облікові записи та ризикові входи | помилку синхронізації, нового адміністратора, вимкнення захисту або підозріле використання привілейованого облікового запису |
Фіксоване сповіщення, засноване лише на миттєвому значенні, зазвичай створює багато шуму. Важливі тривалість проблеми, її розвиток у часі та зв’язок із роботою систем. Короткочасне навантаження під час оновлення слід оцінювати інакше, ніж навантаження, яке щоранку зростає, уповільнює застосунок і тимчасово зникає після перезавантаження.
Для моніторингу можна використовувати, наприклад, Zabbix, Checkmk або PRTG. Простіші перевірки HTTP, TCP і строку дії сертифікатів також підтримує Uptime Kuma. Однак вибір інструмента — це лише другий крок. Спочатку потрібно визначити, які несправності він має виявляти та хто опрацьовуватиме його сповіщення.
Інвентаризація має виявляти непідтримувані пристрої
Моніторинг має фіксувати не лише те, чи ввімкнений комп’ютер. Він повинен розрізняти підтримувану систему, пристрій у режимі розширеної підтримки та комп’ютер без стандартних оновлень безпеки.
Основна підтримка більшості редакцій Windows 10 завершилася 14 жовтня 2025 року. Винятком можуть бути, наприклад, редакції з іншим життєвим циклом або пристрої, підключені до програми Extended Security Updates. Тому визначальними є конкретна редакція, версія та спосіб керування, а не лише напис «Windows 10». Актуальні строки наведено в огляді випусків Windows від Microsoft.
Так само потрібно обліковувати прошивки firewall, NAS, комутаторів, точок доступу та UPS. Доступний пристрій може становити операційний ризик, якщо виробник більше не випускає виправлень безпеки або компанія не має плану його заміни.
Місткість дисків: не чекайте повного заповнення
Заповнений диск може не лише перешкодити збереженню документа. Він здатен зупинити базу даних, оновлення, запис журналів, створення snapshot або завдання резервного копіювання.
Тому моніторинг має відстежувати:
- поточний обсяг вільного місця;
- швидкість, із якою витрачається простір;
- місце, необхідне для оновлень, тимчасових файлів і snapshot;
- незвично швидке зростання журналів або бази даних;
- файлові системи, переведені в режим лише для читання;
- стан storage pool, тому та групи RAID.
Сповіщення доцільно налаштовувати відповідно до способу використання. Однаковий обсяг вільного місця означає різні ситуації на системному диску сервера бази даних і на архівному томі, вміст якого змінюється повільно.
У Synology DSM і QNAP QTS недостатньо перевіряти лише доступність вебінтерфейсу адміністрування. Моніторинг має розрізняти стан storage pool, групи RAID, тому, окремих дисків, кешу SSD, snapshot і підключеного UPS. NAS може відповідати через мережу, навіть якщо масив уже деградований або том перейшов в обмежений режим.
Обліковуйте точну модель і серійний номер диска
Позначення «WD Red», «Seagate» або «диск на вісім терабайтів» недостатньо для діагностики. Потрібні точна модель, серійний номер, прошивка, розташування у відсіку та історія замін.
Причина — відмінності навіть у межах однієї комерційної серії. Позначення моделі може вказувати на різну місткість, технологію запису, прошивку та призначення диска. Наприклад, моделі WD40EFAX і ST8000DM004 використовують запис SMR. Під час тривалого довільного запису та відновлення масиву внутрішнє перевпорядкування перекривних доріжок може значно збільшити час відгуку. Через це контролер може визнати повільний диск таким, що не відповідає, і від’єднати його від масиву. Докладніше проблему пояснює стаття про те, чому SMR-диск може випасти з NAS.
SMART є корисним джерелом даних, але не підтверджує, що диск не вийде з ладу. Також відстежуйте динаміку помилок читання, пошкоджених або нестабільних секторів, помилки інтерфейсу, температуру, стан носія SSD і зміни часу відгуку. Крім того, значення окремих атрибутів SMART різняться залежно від виробника; нормалізовані показники не можна механічно порівнювати між різними серіями дисків без урахування контексту.
Різке збільшення кількості помилок інтерфейсу може вказувати на кабель, backplane або живлення, тоді як зростання кількості нестабільних секторів спрямовує увагу на сам носій. Один узагальнений статус «Good» приховає ці відмінності.
Як визначити, чи справді працює резервне копіювання
Зелений результат завдання резервного копіювання підтверджує лише те, що програма завершила запланований крок. Він не доводить, що було вибрано правильні дані, копія залишилася неушкодженою або компанія зможе відновити її за потрібний час.
Моніторинг резервних копій має перевіряти щонайменше:
- результат останнього запланованого запуску;
- вік останньої успішної копії;
- незвичну зміну обсягу резервованих даних;
- доступність і вільну місткість цільового сховища;
- дотримання політики зберігання;
- стан відокремленої або незмінної копії;
- результат останньої перевірки відновлення.
Раптове зменшення резервної копії може означати видалення даних, зміну вибраного набору або недоступність джерела. Стрімке зростання може бути спричинене зміною даних, помилкою дедуплікації, новим обсягом резервування або масовим перезаписом файлів. Сповіщення не повинно автоматично визначати причину, але має передати інформацію про зміну відповідальній людині з достатнім контекстом.
Невиконане резервне копіювання виявить автоматична перевірка. Неможливість відновити резервну копію надійно виявляється лише під час відновлення. Тому поряд зі щоденним моніторингом потрібно запланувати тест відновлення резервної копії із документально зафіксованим результатом.
Перевіряйте вебсайт і служби також ззовні
Монітор, розташований лише в тому самому офісі, що й контрольований маршрутизатор, має сліпу зону. У разі перебою електропостачання або інтернет-з’єднання він може втратити зв’язок одночасно з усією філією. Тому принаймні частина перевірок має надходити з незалежної мережі.
Для вебсайту недостатньо ping. Залежно від важливості служби перевірка має охоплювати:
- розв’язання DNS;
- установлення TLS-з’єднання;
- правильне ім’я в сертифікаті та надійний ланцюжок довіри;
- очікуваний код відповіді;
- наявність конкретного вмісту;
- за потреби — вхід або відповідь вибраного API.
Тестовий обліковий запис повинен мати лише права, необхідні для відповідної перевірки. Його дані для входу не можна зберігати у відкритому скрипті або звичайному текстовому конфігураційному файлі.
Із 15 березня 2026 року нові загальнодовірені TLS-сертифікати можуть мати максимальний строк дії 200 днів. Затверджений графік CA/Browser Forum передбачає подальше скорочення, тому ручне нагадування в календарі не є довгостроковим рішенням. Моніторинг має перевіряти не лише строк дії, а й те, чи справді система автоматичного оновлення розгорнула новий сертифікат. Строки визначає Ballot SC-081v3 CA/Browser Forum.
Події безпеки, які потребують реагування
Збирання всіх доступних журналів без правил оцінювання створює шум і додаткові витрати. Для малої компанії найбільшу цінність мають події, які можна пов’язати з конкретним пристроєм, користувачем і порядком дій:
- вимкнення антивірусу або EDR;
- тривале від’єднання агента безпеки;
- створення облікового запису адміністратора або підвищення прав;
- зміна firewall, VPN або конфігурації резервного копіювання;
- повторні невдалі спроби входу;
- незвичне використання привілейованого облікового запису;
- масове перейменування, змінення або видалення файлів;
- припинення збирання журналів;
- виведення з роботи відокремленої резервної копії або зміна строку її зберігання.
Джерелом може бути Microsoft Defender for Business, Wazuh, централізований syslog або інструменти безпосередньо від виробника firewall і системи резервного копіювання. Проте кожен із них бачить лише належним чином підключені пристрої та служби. Особистий ноутбук, новий хмарний застосунок або пристрій із видаленим агентом можуть залишитися поза контролем.
Моніторинг не замінює багатофакторну автентифікацію, оновлення, сегментацію мережі або відокремлені резервні копії. Крім того, у зашифрованому трафіку він часто відстежує з’єднання та метадані, а не вміст комунікації. Обсяг збирання, доступ до записів і строк їх зберігання потрібно документувати.
Карта моніторингу відповідно до реальної роботи систем
Кількість працівників сама собою не визначає складність. Невелике проєктне бюро з локальним сервером, великими обсягами даних і віддаленим доступом може потребувати ширшого моніторингу, ніж більша компанія, яка працює майже виключно з кількома хмарними службами.
| Тип середовища | Мінімальна карта моніторингу |
|---|---|
| Переважно хмарна компанія | робочі станції, агенти адміністрування, ідентифікаційні дані, багатофакторна автентифікація, firewall, Wi-Fi, інтернет, резервні копії хмарних даних, вебсайт, домен і TLS-сертифікати |
| Компанія з NAS або локальним сервером | попередній обсяг плюс storage pool, RAID, томи, диски, UPS, віртуальні машини, бази даних, DNS, DHCP і сховища резервних копій |
| Кілька філій | попередній обсяг плюс окремі підключення, VPN, VLAN, комутатори, точки доступу, залежності між локаціями та окремі контакти для ескалації |
| Середовище з критично важливим застосунком | попередній обсяг плюс перевірка застосунку, тест входу, підключення до бази даних, черги завдань, інтеграції та доступність залежних служб |
Для кожного елемента запишіть:
- власника пристрою або служби;
- операційну важливість;
- джерело даних моніторингу;
- порогове значення для попередження та інциденту;
- час, у який сповіщення приймаються;
- людину або команду, яка реагує;
- перший діагностичний крок;
- порядок ескалації.
Карта також має містити залежності. Якщо зникає інтернет-з’єднання філії, система не повинна завалювати адміністратора окремими інцидентами щодо кожного недоступного комутатора, NAS і точки доступу. Сповіщення про основну причину має групувати або тимчасово приглушувати пов’язані події.
Сповіщення без отримувача — це не моніторинг
Безперервне вимірювання — не те саме, що цілодобово доступна підтримка. Інструмент може постійно перевіряти службу, але людина може приймати сповіщення лише в погоджений час.
Тому для кожного типу події потрібно чітко визначити:
- хто отримає сповіщення;
- як підтверджується його прийняття;
- коли воно передається наступній відповідальній особі;
- що можна виконати автоматично;
- що потребує погодження;
- як розрізняються час реагування та час усунення;
- як працюють сервісні вікна.
Сервісне вікно має приглушувати очікувані сповіщення під час запланованих робіт, а не приховувати їхній результат. Після оновлення потрібно знову перевірити, що служба працює, приймає з’єднання та виконує свою функцію.
Якщо в компанії немає людини, яка відповідатиме за інвентаризацію, моніторинг і реагування, ми виконуємо ці завдання в межах щомісячного адміністрування корпоративної ІТ-інфраструктури. Однак у завданні потрібно визначити конкретний обсяг і режим реагування; сама лише інсталяція сервера моніторингу проблему не розв’яже.
Як розпізнати якісний моніторинг
Розглядаючи пропозицію, запитуйте не лише про перелік контрольованих пристроїв. Також з’ясуйте:
- чи перевіряється фактична робота служби, а не лише її доступність;
- хто оцінюватиме сповіщення та в якому режимі;
- як усуваються хибні спрацьовування;
- хто володіє конфігурацією, документацією та історією подій;
- як обліковуються винятки та пристрої поза моніторингом;
- чи показує звіт невирішені ризики;
- як часто карта моніторингу порівнюється з реальним середовищем;
- чи контролюється сама система моніторингу.
Ціна залежить від кількості та різноманітності пристроїв, ліцензій, способу підключення, режиму приймання сповіщень і погодженого реагування. У пропозиції варто окремо зазначити початкову інвентаризацію та налаштування, регулярний моніторинг і роботу під час самого втручання.
Щомісячний звіт має допомагати ухвалювати рішення. Він повинен показувати невирішені ризики, стан резервних копій і тестів відновлення, непідтримувані пристрої, тенденції використання місткості, значущі інциденти та рекомендовані пріоритетні кроки. Перелік тисяч успішних перевірок цієї функції не виконує.
Найпоширеніші помилки під час упровадження моніторингу
- Контролюються лише сервери, але не ідентифікаційні дані, резервні копії та мережеві пристрої.
- Доступність помилково вважається підтвердженням належної роботи застосунку.
- Сповіщення надходять до поштової скриньки, яку ніхто регулярно не перевіряє.
- Кожен короткочасний пік створює інцидент.
- Не враховуються сервісне вікно та залежності між системами.
- Компанія не виявляє пристрої з від’єднаним агентом.
- Резервна копія має зелений статус, але її ніхто не відновлював.
- Сертифікат оновлюється на диску, але вебсайт і далі використовує старий.
- Система моніторингу має права адміністратора, які їй не потрібні для читання стану.
- Після зміни інфраструктури карта моніторингу не оновлюється.
FAQ
Чи потрібен моніторинг компанії без власного сервера?
Так. Потрібно контролювати робочі станції, інтернет, firewall, Wi-Fi, хмарні ідентифікаційні дані, резервні копії, домени, сертифікати та ключові SaaS-служби. Хмара переносить частину інфраструктури до постачальника, але не відповідальність за облікові записи, конфігурацію, дані та зв’язки між службами.
Чи безперервний моніторинг — це те саме, що підтримка 24/7?
Ні. Система може виконувати вимірювання безперервно, тоді як людина реагує лише в погоджені години. Моніторинг, прийняття сповіщень і режим втручання потрібно описувати окремо.
Як часто потрібно запускати перевірки?
Це залежить від наслідків і швидкості розвитку проблеми. Доступність критично важливої служби потрібно перевіряти частіше, ніж довгострокову тенденцію використання місткості. Результат резервного копіювання слід оцінювати після запланованого запуску, а не з тим самим інтервалом, що й вебсайт.
Чи може моніторинг запобігти програмам-вимагачам?
Сам по собі — ні. Він може попередити про вимкнений захист, незвичний вхід, масові зміни файлів або збій резервного копіювання. Захист забезпечує поєднання профілактики, обмежених прав, багатофакторної автентифікації, сегментації, EDR і резервних копій, які можна відновити.
Що компанія має отримувати в щомісячному звіті?
Передусім огляд невирішених ризиків, стан резервних копій і тестів відновлення, перелік непідтримуваних пристроїв, тенденції використання місткості, значущі інциденти та рекомендовані пріоритетні кроки. Звіт має допомагати ухвалювати рішення, а не демонструвати обсяг зібраних даних.
Де нас знайти
ITHOPE — компанія з Брно, Чехія: ми робимо відновлення даних з дисків, RAID і NAS, сервіс ПК та ноутбуків та IT для бізнесу, усе у власній лабораторії за адресою Viniční 3587/216, 615 00 Brno.
Телефон +420 775 556 063 (цілодобово). Пристрій можна привезти особисто або надіслати курʼєром (Zásilkovna, PPL).