Истината на "петте деветки"
Последните новини за повреди на ИТ системите на финансовата борса, които доведоха до много часове прекъсване и огромни загуби, са объркващи. Такива компании инсталират устойчиви на грешки системи с ниво на готовност най-малко „пет деветки“, допустимото време за престой за тях е 5 минути годишно, но възстановяването на работоспособността понякога се забавя за цялата търговска сесия. И така, колко реални деветки има в 99,999%?
Няма значение как гласуват, важно е как мислят
При оценката на надеждността на оборудването като основен параметър се приема „времето между отказите“ - MTBF (средно време между отказите). Затова нека кажем няколко думи за легитимността на декларирания MTBF на отделните компоненти. Например, за твърди дискове някои известни производители отчитат стойности на MTBF над един милион часа! Производители на други компоненти на центрове за данни, както ИТ оборудване, така иинженерен компонент. Често въпросът за тази стойност обърква продавача, да не говорим за потвърждаването на декларираните стойности. Тук няма да спорим с производителите на сървърни платформи, системи за съхранение, инфраструктурни компоненти на центрове за данни относно правилността на декларираните стойности на MTBF; само отбелязваме, че данните за обективни изчисления на надеждността трябва да се вземат не от производителя, а от независими лаборатории за изпитване, тъй като само външен одит може да даде обективна оценка. Затова ще се съсредоточим върху следните изчисления.
Как се оправдават "пет деветки"? Доставчиците често се позовават на статистически данни за неуспехите, но в същото време, посочвайки пет или шест "деветки", понякога твърдят, че цифрата е взета "по аналогия" с предишни системи, които са тествани от десетилетия и показват "отлична" надеждност. Така следващият модел, който наскоро излезе на пазара „по наследство“, получава натрупания опит по отношение на надеждността. И доставчиците не отварят първоначалната статистика и работни дневници.
Липсата на нормативни и ръководни документи или поне обсъждани модели води до следното. При обосноваване на необходимата надеждност отляво се поставя ТЗ с декларираните от клиента изисквания за надеждност на проектираната система. Вдясно има купчина справочници с формули за изчисляване на надеждността (справочници, като правило, от 70-те и 80-те години на публикуване, тъй като оценката на надеждността днес е престанала да бъде „популярна тема“). В средата дизайнерът излага „удобни“ модели, които осигуряват докинг на дясната и лявата част. Освен това изборът на модел не е регламентиран по никакъв начин, тъй като нито ITIL, нито TIA-942, нито други признати насоки и правила дават инструкции и обяснения как да се брои, какъв клас модели да се използват, какво трябва да се вземе предвид и какво може да се пренебрегне. Нека демонстрираме типична схемаполучите желаните резултати с пример.
Традиционно изчисление на надеждността
За да се докаже висока оценка на надеждността на дизайна, често се използва следното „удобно“ изчисление на дублирана група сървъри. Използва се веригата на Марков, показана на фигурата. Процентите на отказ λ и процентите на възстановяване µ са дадени като параметри на модела. Повреда е повреда и на двата възела: състояние "2".
При изчисляване на такъв модел се получават очевидно надценени стойности на показателите за надеждност, които не отразяват реалната надеждност на системата. С началните стойности на честотата на повреда λ = 0,00005 1/h (времето между повредите е 20 000 h) и скоростта на възстановяване µ = 0,25 1/h (4 часа за възстановяване), получаваме от изчислението на графиката стойността на коефициента на наличност Kg = 0,99999992 (седем деветки). Подчертаваме, че взетото време за работа от 20 хиляди часа е долната лента за MTBF на сървърните платформи, обикновено се посочват 50–100 хиляди часа за сървъри и следователно резултатите са още по-„добри“. Това повдига разумен въпрос: кое е по-добро - потвърдени три "деветки" или маркетингови шест? В допълнение, "пет деветки" се декларират, като правило, само за платформата; за целевата система стойностите на готовност ще бъдат напълно различни, да не говорим за стойностите на RTO (обективно време за възстановяване).
Съгласно горния модел се изчисляват и други резервни системи за центрове за данни: от телекомуникационно оборудване до системи за непрекъсваемо захранване.
Човешки фактор
Ефективността на центъра за данни зависи от много фактори. Тук няма да разглеждаме външни фактори, като природни бедствия и причинени от човека бедствия, както и хакерски атаки. Нека се съсредоточим върху вътрешността. очевидно,че моделът на дублираната група, обсъден по-горе, е твърде опростен и неадекватен за процесите, които действително се случват в изчислителните системи, независимо дали са мрежови клъстери или системи, устойчиви на грешки. Освен това материалите на Uptime Institute подчертават, че не е достатъчно да се оцени надеждността на центъра за данни само въз основа на MTBF, тъй като значителен принос за наличността на център за данни има човешкият фактор. Изследванията, в допълнение към статистическия анализ на отказите на оборудването, трябва да вземат предвид и човешките действия и решения. Следователно, въпреки повече от 2 пъти излишък (двойно "N+1"), стойността на наличност за максималното ниво на центъра за данни (Ниво IV) е само 99,995.
Въпросът какво да предпочетем също е спорен: по-надежден хардуер или по-добри планове за възстановяване при бедствия (DRP, план за възстановяване при бедствия) и сценарии за предотвратяване на бедствия, включително RPO оптимизация (Recovery Point Objective, интервалът от време преди отказ, данните за който ще бъдат загубени). Има и графични форми на представяне, които отразяват информация за надеждността на системите, например блокова диаграма на надеждността (RBD), анализ на дървото на събитията или диаграма на дървото на грешките. Качеството на разработването на такива мерки също определя времето на престой и крайната надеждност на системата.
В тази статия ние само накратко очертахме някои от проблемните въпроси на оценката на надеждността, включително надеждността на ИТ оборудването и инфраструктурата на центъра за данни. Въпросите за надеждността на софтуера, оцеляването под въздействието на външни фактори върху системата, включително толерантността към бедствия, останаха извън скобите. Но, както е показано по-горе, за да осигурим „пет деветки“ в реална система, във всеки случай, в рамките на същия център за данни,изглежда малко вероятно.
Може би не се нуждаем от точни оценки на надеждността, а само общи думи за нейната достатъчност? Въпреки това, ако непрекъснатостта на бизнеса се определя от надеждността на ИТ и бизнесът изчислява загубите от престой и то с висока точност, тогава защо не е необходима цялостна количествена оценка на надеждността? Очевидно с течение на времето ще дойде разбирането, че е необходимо правилно да се оцени надеждността на системите на етапа на проектиране, като се вземат предвид ИТ оборудването, софтуерът и инфраструктурата на центъра за данни, както и редица външни фактори. Какво е по-евтино: първо да извършите адекватна оценка на надеждността на системата и да разберете на какво можете да разчитате и какви SLA да гарантирате, или след това да изчислите загубите от престой?
Не толкова отдавна беше обърнато повишено внимание на въпросите за практическата оценка на надеждността на проектираните системи и развитието на самата теория за надеждността. Както знаете, новото е добре забравеното старо, така че въпросите за осигуряване на надеждност, нейната реална количествена оценка със сигурност ще бъдат отново търсени и адаптирани към съвременните изисквания. х