Три джерела і три складові частини доступності

Доступність: введення в предмет

Найправильніший спосіб зрозуміти, що таке доступ-ність, - розібратися, навіщо вона потрібна. До-злочинності - це характеристика того, що хоче отримати бізнес від ІТ # 8209; служби. На жаль, деякі представники бізнесу на питання про бажану доступності ІТ-послуги відповідають приблизно наступне: «Хочу, щоб все завжди працювало». В цьому випадку писати технічне завдання на послугу доводиться ІТ-менеджеру, в тому числі визначаючи параметри доступності. Отже, доступність - це параметр ІТ-послуги, яку споживає бізнес і яку надає ІТ # 8209; служба. Формула розрахунку доступності така:

Availability = (AST - DT) / AST × 100 = Servise or Component Availability (%)

де
AST (agreed service time) - узгоджений час надання послуги;
DT (actual downtime during agreed service time) - фактичний час, коли послуга була недоступна протягом узгодженого часу її надання.

Особливості розрахунку доступності простіше зрозуміти на конкретному прикладі. Спробуємо визначити доступність ІТ-послуги «інтернет-магазин» для компанії ААА, розташованої в Москві, яка продає книги. При цьому книги і їх доставку в будь-яке місто можна оплатити, наприклад, за допомогою кредитної картки. Очевидно, що замовлення на доставку будуть оброблятися тільки в робочі дні з 9 до 18.

Але яким буде AST - узгоджений час надання послуги? Для відповіді на це питання необхідно врахувати, що люди можуть розміщувати замовлення в неробочий час, і обов'язково взяти до уваги те, що в Росії 11 часових поясів. Отже, надавати послугу треба 24 години на добу 7 днів на тиждень.

Тепер потрібно розібратися з DT - часом, коли послуга може бути недоступна. Тут без переговорів з бізнесом не обійтися. Цілком можливо, що чотири години недоступності послуги один раз на місяць може бути цілком адекватним вибором для даного прикладу. Однак треба врахувати один нюанс - період часу, протягом якого проводиться оцінка параметра DT, тобто власне узгоджений час надання послуги (AST). Вибір періоду AST - особиста справа сторін: бізнесу та ІТ # 8209; служби. В якості такого періоду краще взяти тиждень або кілька тижнів, так як місяць або рік - величини непостійні (включають різну кількість днів). Однак потрібно звертати увагу і на психологію: більш короткі періоди часу можуть бути негативно сприйняті бізнесом. У нашому прикладі те ж саме значення доступності відповідає простою приблизно годину в тиждень. Однак бізнесу може не сподобатися, що інтернет-магазин буде недоступний протягом години щотижня, хоча на чотири години простою в місяць він може погодитися. З іншого боку, іноді неможливо експлуатувати ІТ # 8209; систему без того, щоб не зупинити її на кілька годин для планових робіт з обслуговування. Такі планові простої теж повинні бути враховані при виборі DT, що, в свою чергу, може привести до перегляду параметра AST.

Виходячи з вищевикладеного ми вибираємо 4 години недоступності послуги один раз протягом чотирьох тижнів. Тобто AST = 4 тижні, DT = 4 години. Тоді доступність така:

Availability = (24 × 7 × 4-4) / (24 × 7 × 4) × 100% = 99,40%

Цілком можливо, що бізнес буде не згоден. В цьому випадку потрібно з'ясувати, на який варіант він погодиться. Надалі можна прорахувати два варіанти апаратно-програмних комплексів з різною доступністю і переговори з бізнесом вести, грунтуючись на порівнянні вартості обох варіантів. Взагалі переговори з бізнесом і бюджетування ІТ # 8209; служби - це окрема тема, для розкриття якої, мабуть, по-потрібно не одна книга. Тому припустимо, що в нашому прикладі доступність порахована і узгоджена і можна переходити до створення системи.

Три складові доступності

Найперше, що потрібно усвідомити при виборі рішення, - це з чого складається доступність ІТ-послуги. Безліч розчарувань під час експлуатації пояснив-ється тим, що доступність послуги, яку хоче отримати бізнес, безпосередньо пов'язують з доступністю обладнання. Однак доступність ІТ-послуги являє собою сукупність трьох складових:
1) Reliability - зазвичай перекладається як надійність;
2) Maintainability - перекладається як «обслужіваемость»;
3) Serviceability - ремонтопридатність.
Розберемо кожен з цих пунктів.

Reliability

Reliability - це доступність інфраструктури або апаратно-програмного комплексу в цілому, включаючи комунікації. Наприклад, для інтернет-магазину нам потрібен веб # 8209; сервер, сервер додатків, СУБД, дисковий сховище і доступ в Інтернет. Для простоти будемо вважати, що програмне забезпечення «сервер додатків» включає в себе веб # 8209; сервер і буде встановлено на одному апаратній сервері, СУБД - на другому, а дисковий сховище являє собою зовнішній дисковий масив.

Починаємо творити - будуємо проект інфраструктури. Під кожним компонентом напишемо параметри його доступності. Доступність кожного компонента - далі будемо користуватися терміном «надійність» - повинна бути отримана від постачальника компонента (обладнання, програмного забезпечення або послуги). Якщо це з якихось # 8209; небудь причин неможливо (наприклад, для програмних компонентів значення надійності, як правило, невідомо) - шукану величину доведеться самостійно оцінити і призначити. Кожен компонент є єдиною точкою відмови, тому на робочій схемі для розрахунку надійності вони з'єднані послідовно (рис. 1). Зауважимо, що це не схема з'єднання компонентів інфраструктури, а лише схема розрахунку надійності.

Отже, розраховуємо надійність. Оскільки у нас послідовне з'єднання компонентів, то величини надійності перемножуються:

Reliability = (0,985 × 0,97 × 0,975 × 0,98 × 0,99 × 0,9999 × 0,99) × 100% = 89,47%

Це явно недостатньо в порівнянні з необхідним значенням 99,40%. Тоді змінимо рішення - включимо в систему альтернативного постачальника послуг доступу в Інтернет (рис. 2) і розрахуємо його надійність. Оскільки щодо інтернет-доступу ми маємо паралельне з'єднання, загальна надійність визначається наступним чином:

Загальна надійність = [1- (1-надійність компонента №1) × (1-надійність компонента №2)]

Reliability = [1- (1-0,985) × (1-0,98) × 0,97 × 0,975 × 0,98 × 0,99 × 0,9999] × 100% = 91,72%

Думаю, що принцип «роботи з надійністю» майбутньої системи продемонстрований. Слід звернути увагу, що в розглянутому прикладі не фігурували компоненти мережевої інфраструктури і надійність з'єднань (наприклад, між сервером бази даних і дисковим сховищем), а також компоненти технічної інфраструктури (електроживлення, кондиціонування і т. п.), які також є точками відмови і повинні бути включені в розрахунок. На окрему увагу заслуговує оцінка надійності програмних компонентів. Тут основна порада полягає в розумному консерватизмі: використовувати програмні компоненти, які експлуатуються в подібних рішеннях тривалий час і добре себе зарекомендували.

За допомогою прийомів, які були коротко розглянуті вище, можна вибрати рішення з необхідною доступністю.

Maintainability і Serviceability

Переходимо до інших складових до-ступ-ніс-ти - maintainability і serviceability. Зауважу, що переклади «обслужіваемость» і «ремонтопридатність» невдалі, оскільки з них малозрозумілою, що це означає. Краще використовувати більш зрозумілі переклади: maintainability - діяльність внутрішньої ІТ # 8209; служби організації; serviceability - послуги, що надаються зовнішніми постачальниками.

Щоб прояснити ситуацію, розглянемо крайні варіанти. В якому випадку повністю відсутня maintainability (діяльність внутрішньої ІТ # 8209; служби організації)? Це буває, коли компанія власну ІТ # 8209; службу віддає на аутсорсинг. Тут доступність складається тільки з надійності і послуг, що надаються зовнішніми постачальниками.

В якому випадку повністю відсутня serviceability (послуги, що надаються зовнішніми постачальниками)? Це відбувається, наприклад, в ФСБ, яка з міркувань секретності всю діяльність з підтримки системи в робочому стані змушена вести виключно силами свого ІТ-підрозділу, навіть запчастини купуються самостійно, а не поставляються в рамках контракту технічної підтримки. Тоді доступність складається тільки з надійності системи і діяльності внутрішньої ІТ # 8209; служби організації.

Зрозуміло, що вибирати рішення потрібно одночасно з опрацюванням схем забезпечення maintainability і serviceability. В цілому reliability, maintainability і serviceability - це три складові доступності. Зміна однієї з них має бути скомпенсировано змінами двох інших - інакше зміниться стан видимості ІТ-послуги, що може завдати шкоди бізнесу.

Способи маніпулювання складовими доступності

Щоб зрозуміти, яким чином можна маніпулювати всіма складовими доступності, розглянемо інший практичний приклад. Компанія, що має центри обробки даних в двох містах Росії, Зеленограді (місто - супутник Москви) і Іркутську, придбала дві однакові системи «під ключ». Отже, надійність - reliability - у них однакова. Обидві ІТ # 8209; системи були забезпечені однаковими контрактами технічної підтримки на апаратну і програмну частини, значить, послуги, що надаються зовнішніми постачальниками, - serviceability - також були однакові. Однак доступність систем виявилася різна. І компанія стала скаржитися постачальнику на погану доступність системи в Іркутську, стверджуючи, що одне з рішень «браковане», і вимагаючи провести його аудит.

Однак в даному випадку аудит рішення швидше за все не виявить кореневу причину «провалу» доступності, так як буде досліджена тільки одна складова - Reliability, яка повинна бути однаковою у обох систем, а досліджувати треба якраз дві інші складові. Якщо звернути увагу на них, то з'ясується, що можливі два варіанти.

Варіант 1: до втрати доступності привели апаратні збої. Через географічне розташування центрів обробки даних однакові контракти технічної підтримки апаратної частини насправді можуть виявитися різними. Наприклад, сервісний центр зовнішнього постачальника розташований в Москві, а в контракті технічної постач-ки написано, що він діє тільки в робочі дні і інженер прибуває на місце встановлення обладнання «першим доступним залізничним або авіарейсом». Очевидно, що для інженера, який відбуває з Москви, ця величина буде різною для Зеленограда і Іркутська.

Можливі варіанти вирішення проблеми з доступністю в цьому випадку:

змінити надійність ІТ # 8209; системи в Іркутську, наприклад поставити додатковий вузол в кластер;
змінити параметр serviceability - створити склад в Іркутську, отримати можливість для ІТ # 8209; фахівців компанії самостійно змінювати несправні компоненти, якщо це не суперечить правилам виробника.

Крім того, має сенс перевірити умови експлуатації. Приклади типових порушень цих умов:

проведення ремонтних робіт в приміщеннях при включених системах, що призводить до їх запиленості, а пил дуже небезпечна для серверного обладнання;
використання побутових кондиціонерів в серверних кімнатах, хоча у кожного виду обладнання є свої вимоги по вологості і побутові кондиціонери не розраховані на підтримку її заданого рівня, а зовсім сухе повітря згубний для техніки.

Варіант 2: до зниження необхідного рівня доступності привели програмні збої. У цьому випадку швидше за все проблема в ІТ # 8209; службі в Іркутську. Послуги технічної підтримки програмного забезпечення надаються в дистанційному режимі. Отже, різниці в послугах немає за винятком того, що для різних часових поясів існують різні періоди надання послуг по відношенню до місцевим часом, але це, як правило, істотного впливу не робить. Ймовірною при-чиною «провалу» доступності тут є різний рівень професіоналізму ІТ # 8209; департаментів - в Іркутську він напевно нижче, ніж в Зеленограді. Можливі ре-шення:

підтягнути maintainability до потрібного рівня - провести навчання ІТ-персоналу в Іркутську з програмних і апаратних продуктів, що входять до складу ІТ # 8209; системи, організувати семінари з передачі досвіду ІТ-команди з Зеленограда, скопіювати процеси експлуатації і т. # 8201; п. ;
компенсувати maintainability за рахунок serviceabi-lity - придбати розширені послуги технічної постач-ки, послуги ауттаскінга і т. # 8201; п.

Якщо повернутися до нашого прикладу з інтернет-магазином, то яке поєднання reliability, maintainability і serviceability буде оптимальним? Відповідь на це питання залежить від кожного конкретного випадку. Наприклад, можна порекомендувати хостинг замість того, щоб повністю реалізовувати всю інфраструктуру (ІТ і технічну) самостійно. У загальному випадку маємо такі типові способи управління доступністю. 1. Зміна reliability (надійності):

зміна ІТ-рішення в бік високої доступності (High Availability) - використання кластерів, застосування обладнання з підтримкою «гарячої» заміни, неодноразового дублювання потенційних точок відмови і т. # 8201; п .;
оренда всієї інфраструктури або її частини у зовнішніх постачальників (хостинг, collocation).

2. Зміна maintainability (зміни в діяльності ІТ # 8209; служби компанії):

поширення всередині організації власного передового досвіду управління ІТ;
запрошення зовнішніх консультантів для організації процесів в ІТ-підрозділі;
навчання ІТ-персоналу.

3. Зміна serviceability - зміна контрактів ІТ-послуг з зовнішніми постачальниками в сторону підвищення рівня сервісу, збільшення обсягу послуг, розширення зони відповідальності зовнішніх постачальників послуг і т. # 8201; п. Всі прийоми маніпулювання трьома джерелами і трьома складовими частинами доступності викласти в рамках однієї статті неможливо, проте основні підходи до компенсування одних складових доступності іншими були продемонстровані. Для подальшого підвищення майстерності в цій області слід вивчати практичний досвід проектування і експлуатації ІТ # 8209; систем.

Хотів би торкнутися теми використовуваної термінології.
Дуже часто плутають терміни доступності (англійською - Accessibility) і готовність (availability).
Доступність - це поняття якості обслуговування, а готовність - поняття надійності обладнання.

Це все прописано в різних гостей РФ і рекомендаціях ITU-T.

Дивно, що В.Нетес і його студент А.Тюнякін ще не знайомі з термінологією ITIL. Студенту можна пробачити, а професору - немає

Та й по суті, якщо availability - доступність, як тоді перевести accessability?