MTTR, СЕРВІС ТА БУНКЕР: ЯК ЗАБЕЗПЕЧИТИ НАДІЙНІСТЬ IT-ІНФРАСТРУКТУРИ В НАШІ НЕПРОСТІ ЧАСИ

MTTR як складова забезпечення надійності

В попередній статті по темі надійності та відмовостійкості ІТ-інфраструктури («Як запроєктувати надійну та відмовостійку ІТ-інфраструктуру») була розглянута проєктна оцінка надійності в досить теоретичній площині. Основний акцент в ній був зроблений на проєктуванні та впливі архітектурних рішень (зокрема, резервування) на підсумкові показники надійності. Проте архітектура — це лише фундамент.

На реальні показники надійності не менш потужно впливають експлуатаційні фактори: сервісна підтримка виробника, рівень підготовки адміністративного персоналу та наявність актуального складу ЗІП. Кожен із цих елементів безпосередньо формує показник MTTR (Mean Time To Repair — середній час відновлення), а отже, визначає кінцевий коефіцієнт готовності всієї системи.

Але звідки взагалі брати значення MTTR? Як саме вищеперераховані фактори на нього впливають? Як забезпечити надійність ІТ-інфраструктури в наші непрості часи, враховуючи воєнні ризики? Давайте розбиратися.

Нагадаємо базову формулу. Основним показником надійності є коефіцієнт готовності (Кг), який розраховується так (1):

де:

• MTBF – середній час між відмовами для комплексу обладнання;
• MTTR – середній час відновлення після відмови.

Проєктна оцінка надійності: фокус на MTTR

Для наочності знову візьмемо мережеву інфраструктуру ЦОД гіпотетичного банку в Україні (Рис. 1). Методика проєктної оцінки така сама, як і у першій статті. Приймаємо, що бізнес-модель цього банку передбачає наявність системи зберігання та обробки даних (СЗіОД) на дубльованій блейд-системі HPE Synergy 12k (SR1, SR2) та СХД HPE Alletra 6050 (DB1), підключених через два FC-комутатори HPE SN6600B (S3, S4). Кінцеві сервіси, які працюють на цьому обладнанні, в цій статті не розглядаються. Обладнання СЗіОД підключається до ядра мережі виконаного на двох комутаторах Cisco Nexus N9K-C93180YC-FX3 (S1, S2) каналами 100GBASE-SR4. Ядро мережі в свою чергу підключається до обладнання модуля WAN, виконаного на маршрутизаторах Cisco ASR-9902-200G-FC (R1, R2) та міжмережевих екранах Cisco FPR4245-NGFW-K9 (FW1, FW2). Підключення між комутаторами N9K-C93180YC-FX3 (S1, S2), маршрутизаторами ASR-9902-200G-FC (R1, R2) та міжмережевими екранами FPR4245-NGFW-K9 (FW1, FW2) виконуються дубльованими каналами 100GBASE-SR4.

Рис. 1. Приклад ІТ-інфраструктури ЦОД

Згідно з розрахунками (Табл. 1), результуюче значення коефіцієнта готовності (Кг) досягає 99,99996%, а середній час простою на рік (Tm) становить мізерні 12,7 секунди. При цьому показник MTTR у проєктній оцінці закладено на рівні 108 годин. Але наскільки реалістичне це значення?

Табл. 1. Проєктна оцінка надійності мережевої інфраструктури

Анатомія MTTR: з чого складається час відновлення

Ключова відмінність MTTR від MTBF полягає в тому, що його значення не вираховують по даташитам обладнання, а саме встановлюють та забезпечують організаційно. Сам процес MTTR є сумою чотирьох часових відрізків (2).

де:

• MTTDT (Mean Time to Detect) – час від моменту відмови до її виявлення системою моніторингу чи персоналом;
• MTTDG (Mean Time to Diagnose) – час локалізації причини відмови (діагностика);
• MTTL (Mean Time to Logistics) – час доставки заміни на майданчик встановленого обладнання;
• MTTDP (Mean Time to Deploy) – час фізичного розгортання та налаштування обладнання.

Встановлення MTTR напряму залежить від вимог бізнесу, таких як SLA або RTO. Під час проєктування необхідно оцінити вартість однієї години простою цільового сервісу та порівняти її з вартістю сервісного контракту. Наприклад, комутатори рівня ядра можуть бути покриті сервісом 24х7х4, а комутатори рівня доступу – 8х5хNBD (Next Business Day).

Повернемось до нашого прикладу. Припустимо, обладнання покрите базовим сервісом рівня 8x5xNBD. Розглянемо найгірший сценарій, коли відмова сталася ввечері в п'ятницю (Табл. 2).

Табл. 2. Приклад оцінки часу для встановлення MTTR

Враховуючи вихідні дні, затримку на логістику та 10% резерву часу, сумарний MTTR об'єктивно встановлюється на рівні 108 годин (4,5 доби).

Дані цифри можна підтвердити на практиці. Для цього системний інтегратор розробляє «Програму та методику випробувань» і проводить стрес-тестування сценаріїв відновлення.

Сервісна підтримка vs Стандартна гарантія

Головним важелем управління показником MTTR є сервісна підтримка виробника (наприклад, контракти Cisco BAS).

Багато компаній досі плутають сервіс зі стандартною гарантією. Гарантія покриває лише заводський брак заліза, не дає доступу до оновлень ПЗ і має нерегламентований термін заміни (від 10 до 45 днів). Натомість сервісний контракт — це інструмент покриття операційних ризиків, в який входить:

1. Авансова заміна обладнання (RMA) зі складу дистриб’ютора з чітким SLA (у нашому випадку — NBD). При цьому, на відміну від стандартної гарантії, формування складу авансової заміни забезпечується виробником.
2. Цілодобовий доступ до експертів рівня Cisco TAC.
3. Легальний доступ до оновлень ПЗ, патчів безпеки та нових версій ОС.

Що буде, якщо зекономити на сервісі? Без контракту MTTR зростає до 45 днів (1008 годин). Для нашого ЦОД коефіцієнт готовності впаде, але через дублювання обладнання система виживе. Однак, якщо прибрати архітектурне резервування і залишитись без сервісу, Кг рухне до 98,5% (124 години простою на рік). А за відсутності навіть гарантії (пошук, закупівля, доставка нового заліза — до 240 днів) система простоюватиме понад 600 годин на рік. Бачимо, що без сервісного контракту будь-яке архітектурне резервування втрачає сенс, оскільки час простою стає неконтрольованим.

Роль команди та моніторингу

Етапи виявлення (Detect), діагностики (Diagnose) та розгортання (Deploy) повністю залежать від кваліфікації ІТ-персоналу. Для мінімізації цих показників необхідні два компоненти: наявність сучасних систем моніторингу (наприклад, Zabbix, Cisco Catalyst Center, Nexus Dashboard тощо) та відпрацьовані організаційні скрипти (Playbooks) для інженерів під час аварій.

Бункер та воєнні ризики: коли RMA недостатньо

Слід розуміти нашу сувору реальність: сервісна підтримка від виробника не покриває воєнні ризики. Якщо обладнання знищене внаслідок бойових дій або ракетного удару, процедура RMA не діє, оскільки це розцінюється як форс-мажор, а не відмова компонента. Крім того, воєнні ризики поширюються на склади та логістичні ланцюги RMA. Для критичної інфраструктури покладатися виключно на логістику вендора сьогодні небезпечно. Єдиним надійним рішенням є формування власного складу гарячого резерву (ЗІП) для найбільш критичних вузлів.

Цей ЗІП має зберігатися в захищеному приміщенні (бункері або протирадіаційному укритті), фізично віддаленому від основного об'єкта на безпечну відстань (зазвичай 5-10 км). Це виключає залежність від зовнішньої логістики у кризовий момент. Але тут криється небезпечна ілюзія: "Якщо я купив резервне залізо і сховав у бункері, сервісний контракт мені більше не потрібен". Це відома помилка. Обладнання ЗІП також потребує сервісного покриття, адже без нього ви втрачаєте доступ до оновлень ПЗ, патчів вразливостей та технічної експертизи TAC, без яких сучасна мережа стає беззахисною перед кіберзагрозами.

Роль системного інтегратора

Команда Lantec, як системний інтегратор з багаторічним практичним досвідом, готова допомогти перетворити теоретичну надійність на гарантовану безперервність бізнесу. Ми пропонуємо комплексні послуги з управління ІТ-ризиками:

• Проєктна оцінка надійності ІТ-інфраструктури. Проведемо математичний розрахунок коефіцієнта готовності (Кг) та інших показників надійності для Вашої поточної або проєктованої ІТ-інфраструктури, виявивши потенційні «вузькі місця».
• Консалтинг із встановлення MTTR. Допоможемо збалансувати вартість простою ваших критичних сервісів із витратами на ІТ. Підберемо оптимальний мікс сервісних контрактів та сформуємо стратегію гарячого резерву або ЗІП для нівелювання навіть воєнних ризиків.
• Валідація та стрес-тестування MTTR. Розробимо індивідуальну «Програму та методику випробувань» та перевіримо на практиці стійкість інфраструктури. Наші інженери проведуть практичний «бенчмарк» інфраструктури, щоб перевірити готовність систем і Вашого персоналу до реальних відмов та підтвердити встановлений час відновлення.

Надійність — це керований процес, і команда Lantec знає, як його налаштувати. Не чекайте, поки раптова відмова обладнання зупинить критичні бізнес-процеси – зверніться до експертів Lantec вже сьогодні.

Автор статті - Олег Захарченко, головний інженер проєкту компанії Lantec.