Правда «п’яти дев’яток»
Чергові новини про збої ІТ-систем на фінансовій біржі, що спричинили багатогодинні простої та колосальні збитки, викликають подив. У таких компаніях встановлюють відмовостійкі системи з рівнем готовності щонайменше «п'яти дев'яток», допустимий час простою для них – 5 хвилин на рік, але відновлення працездатності затягується іноді на всю торгову сесію. Тож скільки реальних «дев'яток» у 99,999%?
Не важливо як голосують, важливо як вважають
Оцінюючи надійності устаткування як базового параметра прийнято «час напрацювання відмови» – MTBF (mean time between failures). Тому скажемо кілька слів про легітимність заявленого доробку на відмову окремих компонентів. Наприклад, для жорстких дисків деякі відомі виробники вказують значення MTBF понад мільйон годин! Не скромничають у своїх оцінках і виробники інших компонентів ЦОДів, як ІТ-обладнання, так іінженерної складової. Часто питання про цю величину ставить вендора в глухий кут, не кажучи вже підтвердженні заявлених значень. Не будемо тут сперечатися з виробниками серверних платформ, СГД, інфраструктурних компонентів ЦОДів про вірність значень MTBF, що декларуються; Відзначимо лише, що дані для об'єктивних розрахунків надійності слід брати не у виробника, а у незалежних випробувальних лабораторій, оскільки об'єктивну оцінку може дати лише зовнішній аудит. Тому зосередимося на наступних розрахунках.
Як обґрунтовуються «п'ять дев'яток»? Вендори часто посилаються на статистику відмов, але при цьому, вказавши п'ять чи шість «дев'яток», часом заявляють, що цифра взята «за аналогією» з попередніми системами, які тестувалися десятиліттями та показали «чудову» надійність. Таким чином, чергова модель «у спадок», що нещодавно вийшла на ринок, отримує накопичений досвід у частині надійності. А вихідну статистику та робочі журнали вендори не відкривають.
Відсутність нормуючих і керівних документів або хоча б моделей, що обговорюються, призводить до наступного. При обґрунтуванні необхідної надійності зліва кладеться ТЗ із заявленими замовником вимогами до надійності проектованої системи. Справа – стос довідників з формулами розрахунку надійності (довідники, як правило, 70-х та 80-х рр. видання, оскільки сьогодні оцінка надійності перестала бути «популярною темою»). У середині проектувальник розкладає «зручні» моделі, що забезпечують стикування правої та лівої частини. Причому вибір моделі нічим не регламентований, тому що ні ITIL, ні TIA-942, ні інші визнані посібники та правила не дають вказівок і роз'яснень, як вважати, моделі якого класу використовувати, що необхідно враховувати, а чим можна знехтувати. Продемонструємо типову схемуотримання необхідних результатів з прикладу.
Традиційний розрахунок надійності
Для доказу високої проектної оцінки надійності часто застосовують наступний "зручний" розрахунок дубльованої групи серверів. Використовується марківський ланцюг, наведений на малюнку. Як параметри моделі задаються інтенсивності відмов λ і відновлення µ. Відмовою вважається вихід із ладу обох вузлів: стан «2».
При розрахунку такої моделі виходять явно завищені значення показників надійності, що не відображають реальної надійності системи. При вихідних значеннях інтенсивності відмов ? 99999992 (сім дев'яток). Підкреслимо, що взяте напрацювання в 20 тис. год – це нижня планка MTBF серверних платформ, зазвичай для серверів вказують значення 50–100 тис. год і, отже, результати виходять навіть «добрішими». Звідси виникає резонне питання: що краще – підтверджені три «дев'ятки» чи маркетингові шість? Крім того, п'ять дев'яток декларуються, як правило, тільки для платформи; для кінцевої системи значення готовності будуть зовсім іншими, а про значення RTO (Recovery Time Objective, цільовий час відновлення).
За наведеною вище моделлю ведеться розрахунок і інших систем ЦОД, що резервуються: від телекомунікаційного обладнання до систем безперебійного живлення.
Людський фактор
Працездатність ЦОД залежить від безлічі факторів. Не будемо тут розглядати зовнішні чинники, такі як природні катаклізми та техногенні катастрофи, а також атаки хакерів. Зосередимося лише на внутрішніх. Очевидно,що розглянута вище модель дубльованої групи є надто спрощеною та неадекватною процесам, які реально відбуваються в обчислювальних системах, чи то мережевих кластерах, чи відмовостійких системах. Більше того, в матеріалах Uptime Institute підкреслюється, що оцінювати надійність ЦОД лише на основі MTBF недостатньо, оскільки істотний внесок у доступність ЦОД вносить людський фактор. Дослідження, окрім статистичного аналізу відмов обладнання, повинні також враховувати людські вчинки та рішення. Тому, незважаючи на більш ніж дворазове резервування (подвоєне N+1), значення готовності для максимального рівня ЦОДу (Tier IV) становить лише 99,995.
Спірним є і питання про те, що віддати перевагу: більш надійне обладнання або якісніші плани відновлення після аварії (DRP, disaster recovery plan) та сценарії попередження аварійних ситуацій, включаючи оптимізацію RPO (Recovery Point Objective, часовий інтервал до збою, дані за який будуть втрачені). Існують і графічні форми уявлення, що відображають інформацію про надійність систем, наприклад блок-схема надійності (Reliability Block Diagram, RBD), аналіз дерева подій (Event Tree Analysis) або схема дерева відмов (Fault Tree diagram). Якість опрацювання таких заходів також визначає час простою та кінцеву надійність системи.
У цій статті ми лише швидко, штрихом позначили частину проблемних питань оцінки надійності, включаючи надійність ІТ-обладнання та інфраструктури ЦОДу. За дужками залишилися питання надійності ПЗ, живучості за умов на систему зовнішніх чинників, включаючи катастрофостійкість. Але, як показано вище, забезпечити в реальній системі «п'ять дев'яток», принаймні в рамках одного ЦОДу,є малоймовірним.
Можливо, і не потрібно точних оцінок надійності, чи достатньо загальних слів про її достатність? Однак якщо безперервність бізнесу визначається надійністю ІТ і бізнес вважає збитки від простою, причому з високою точністю, чому комплексна кількісна оцінка надійності не затребувана? Очевидно, згодом прийде розуміння того, що потрібно правильно оцінювати надійність систем ще на етапі проектування, з урахуванням ІТ-обладнання, ПЗ та інфраструктури ЦОДу, а також низку зовнішніх факторів. Що дешевше: спочатку провести адекватну оцінку надійності системи та розуміти, на що можна розраховувати і які SLA гарантувати, чи потім рахувати збитки від простою?
Ще недавно питанням практичної оцінки надійності проектованих систем та розвитку самої теорії надійності приділялося підвищену увагу. Як відомо, нове – це добре забуте старе, тому питання забезпечення надійності, реальної кількісної її оцінки, безумовно, будуть знову затребувані та адаптовані під сучасні вимоги. ікс