Рекомендації щодо визначення цільових показників надійності

Стосується цієї Power Platform рекомендації щодо контрольного списку Well-Architected Reliability:

RE:04	Визначте цілі надійності та відновлення компонентів, потоків і рішення в цілому. Візуалізуйте цілі для переговорів, досягнення консенсусу, встановлення очікувань і спонукання до дій для досягнення ідеального стану. Використовуйте визначені цілі для побудови моделі здоров’я. Модель здоров’я визначає, як виглядають здорові, деградовані та нездорові стани.

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

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

Microsoft Power Platform вирішує більшість питань доступності та надійності на рівні інфраструктури. Однак доступність робочих навантажень, які ви створюєте, є спільною відповідальністю. Важливо розуміти, що навіть з урахуванням прагнення Microsoft до високої доступності, ризик простою системи ніколи не дорівнює нулю.

Розгляньте можливість використання наведених нижче показників для кількісної оцінки вимог бізнесу.

Термін	Визначення
Цільовий рівень обслуговування (SLO)	Цільовий показник у відсотках, який відображає працездатність компонента та рівень надійності. Чим вище ярус, тим надійніше компонент. Композитний SLO являє собою сукупну ціль всього робочого навантаження та враховує компоненти SLO.
Індикатор рівня сервісу (SLI)	Показник, який видає сервіс. Показники SLI агрегуються для кількісної оцінки значення SLO.
Угода про рівень обслуговування (SLA)	Договірна угода між постачальником послуг та замовником послуг. Угода визначає СЛО. Невиконання договору може мати фінансові наслідки для постачальника послуг.
Середній час на відновлення (MTTR)	Час, витрачений на відновлення компонента після виявлення збою.
Середній час напрацювання на відмову (MTBF)	Тривалість, протягом якої робоче навантаження може виконувати очікувану функцію без перерви, поки не вийде з ладу.
Цільовий час відновлення (RTO)	Максимально допустимий час, протягом якого додаток може бути недоступний після інциденту.
Цільова точка відновлення (RPO)	Максимально допустима тривалість втрати даних під час інциденту.

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

Ключові стратегії дизайну

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

Розглянемо приклад того, як зіставити вимоги з вимірюваними числовими значеннями. За оцінками зацікавлених сторін, для критичного потоку користувачів година простою в звичайний робочий час призводить до втрати X доларів щомісячного доходу. Ця сума в доларах порівнюється з оціночною вартістю проектування потоку, доступність якого становить 99,95 відсотка, а не 99,9 відсотка. Особи, які приймають рішення, повинні обговорити, чи переважає ризик втрати доходів додаткові витрати та навантаження на управління, необхідні для захисту від них.

Дотримуйтесь цієї схеми, вивчаючи потоки та складаючи повний список цілей.

Пам’ятайте, що цільові показники надійності відрізняються від цільових показників ефективності. Цілі надійності зосереджені на доступності та відновленні. Щоб встановити цільові показники надійності, почніть із визначення найширших вимог, а потім визначте більш конкретні показники для задоволення вимог високого рівня.

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

Показники доступності

Цільові показники доступності відповідають показникам SLO, SLA та SLI.

SLO та SLA

Показники доступності корелюють із показниками SLO, які використовуються для визначення SLA. SLO робочого навантаження визначає, скільки простоїв допустимо в той чи інший період; Наприклад, менше 1 години на місяць. Щоб переконатися, що ви можете досягти цільового показника SLO, перегляньте угоди про рівень обслуговування Microsoft для кожного компонента.

Щоб встановити свої SLO, подумайте про:

• Нефункціональні вимоги вашого робочого навантаження (наприклад, пікові показники запитів, одночасні користувачі) протягом наступних 1-2 років.

• Доступні показники того, що ви можете виміряти за певний період часу. Ці дані будуть інформувати про те, які СЛІ вказати.

Зібравши SLA для окремих компонентів робочого навантаження, розрахуйте складений SLA. Складений SLA має відповідати цільовому SLO робочого навантаження. Розрахунок композитного SLA включає кілька факторів, залежно від вашого архітектурного дизайну.

Визначення правильних SLO вимагає часу та ретельного обмірковування. Стейкхолдери бізнесу повинні розуміти толерантність до надійності. Цей зворотний зв’язок має бути основою для визначення цілей.

Значення SLA

У наведеній нижче таблиці визначено загальні значення SLA.

SLA	Час простою на тиждень	Час простою на місяць	Час простою на рік
99%	1.68 години	7.2 години	3.65 дні
99.9%	10.1 хвилин	43.2 хвилин	8.76 години
99.95%	5 хвилин	21.6 хвилин	4.38 години
99.99%	1.01 хвилин	4.32 хвилин	52.56 хвилин
99.999%	6 секунд	25.9 секунд	5.26 хвилин

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

СЛІ

Думайте про SLI як про показники на рівні компонентів, які сприяють SLO. Найбільш значущі СЛІ – це ті, які впливають на ваші критичні потоки з точки зору ваших клієнтів. Для багатьох потоків SLI включають затримку, пропускну здатність, частоту помилок і доступність. Хороший SLI допомагає визначити, коли існує ризик порушення SLO. Співвідносьте SLI з конкретними клієнтами, коли це можливо.

Щоб уникнути збору непотрібних показників, обмежте кількість SLI для кожного потоку. Прагніть до трьох SLI на потік, якщо це можливо.

Показники відновлення

Цілі відновлення відповідають метрикам RTO, RPO, MTTR та MTBF. На відміну від цільових показників доступності, цілі відновлення для цих показників не залежать значною мірою від угод про рівень обслуговування Microsoft SLA. Корпорація Майкрософт публікує гарантії RTO та RPO лише для деяких продуктів, наприклад SQL Database.

Визначення реалістичних цілей відновлення ґрунтуються на аналізі режиму відмови та ваших планах, а також на тестуванні безперервності бізнесу та аварійного відновлення. Перш ніж закінчити цю роботу, обговоріть із зацікавленими сторонами амбітні цілі та переконайтеся, що дизайн вашої архітектури відповідає цілям відновлення в міру вашого розуміння. Чітко повідомте зацікавленим сторонам, що будь-які частини робочого навантаження, які не були ретельно протестовані на показники відновлення, не повинні мати гарантованих угод про рівень обслуговування. Переконайтеся, що зацікавлені сторони розуміють, що цілі відновлення можуть змінюватися з часом у міру оновлення робочих навантажень. Робоче навантаження може ускладнюватися в міру впровадження нових технологій для покращення користувацького досвіду. Ці зміни можуть збільшувати або зменшувати показники відновлення.

Нотатка

Середній час на відмову від роботи (MTBF) може бути складним для визначення та гарантування. Платформи як послуга (PaaS) або програмне забезпечення як послуга (SaaS) можуть виходити з ладу та відновлюватися без будь-якого повідомлення від постачальника хмарних послуг, і цей процес може бути повністю прозорим для вас. Якщо ви визначаєте цілі для цього показника, охоплюйте лише ті компоненти, які перебувають під вашим контролем.

Побудова моделі здоров’я

Використовуйте зібрані дані для цілей надійності, щоб побудувати модель справності для кожного робочого навантаження та пов’язаних з ним критичних потоків. Модель справності визначає справний, деградований та нездоровий* стани для потоків та робочих навантажень. Штати забезпечують належне визначення пріоритетів операцій. Ця модель також відома як модель світлофора . Модель позначає зелений колір здоровим, жовтий – деградованим, а червоний – нездоровим. Модель справності гарантує, що ви знаєте, коли стан потоку змінюється зі справного на деградований або нездоровий.

Те, як ви визначаєте справний, деградований та нездоровий стани, залежить від ваших цільових показників надійності. Ось кілька прикладів способів визначення станів:

• «Зелений» або «здоровий» стан вказує на те, що ключові нефункціональні вимоги та цілі повністю задоволені, а ресурси використовуються оптимально.

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

• Червоний або нездоровий стан вказує на те, що погіршення роботи триває довше, ніж дозволено вашими цільовими показниками надійності, або що потік став недоступним.

Нотатка

Модель здоров’я не повинна ставитися до всіх невдач однаково. Модель справності повинна розрізняти тимчасові та нетранзиторні несправності. Слід чітко розрізняти очікувані тимчасові, але відновлювані збої та справжній аварійний стан.

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

Докладні інструкції щодо конфігурацій моніторингу та сповіщень див. у посібнику з моніторингу справності .

Візуалізація

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

Power Platform сприяння

Power Platform Угоди про рівень обслуговування (SLA) передбачають зобов’язання Microsoft щодо безперебійної роботи та підключення. Різні сервіси мають різні угоди про рівень обслуговування (SLA), а іноді SKU в межах одного сервісу мають різні угоди про рівень обслуговування. Для отримання додаткової інформації див. Угоди про рівень обслуговування для онлайн-сервісів.

Угода про рівень обслуговування (SLA) містить процедури отримання кредиту на обслуговування, якщо умову SLA не дотримується, а також визначення доступності кожної послуги. Power Platform Цей аспект угоди про рівень обслуговування діє як політика забезпечення виконання.

Microsoft Business Applications надає можливості забезпечення безперервності бізнесу та аварійного відновлення (BCDR) для всіх середовищ виробничого типу в Dynamics 365 та SaaS-додатках. Power Platform Дізнайтеся, як Microsoft забезпечує стійкість ваших виробничих даних під час регіональних збоїв.

Організаційне узгодження

Структура впровадження хмарних технологій надає рекомендації щодо SLO та SLI, пов’язаних з моніторингом в організації.

Для отримання додаткової інформації див. SLO для моніторингу хмари.

Контрольний список надійності

Зверніться до повного зведення рекомендацій.

Контрольний список надійності