Рекомендації щодо визначення цільових показників надійності
Стосується цієї 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, перегляньте SLA 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. Microsoft публікує гарантії RTO та RPO лише на деякі товари, як SQL Database.
Визначення реалістичних цілей відновлення ґрунтуються на аналізі режиму відмови та ваших планах, а також на тестуванні безперервності бізнесу та аварійного відновлення. Перш ніж закінчити цю роботу, обговоріть із зацікавленими сторонами амбітні цілі та переконайтеся, що дизайн вашої архітектури відповідає цілям відновлення в міру вашого розуміння. Чітко повідомте зацікавленим сторонам, що будь-які частини робочого навантаження, які не були ретельно протестовані на показники відновлення, не повинні мати гарантованих угод про рівень обслуговування. Переконайтеся, що зацікавлені сторони розуміють, що цілі відновлення можуть змінюватися з часом у міру оновлення робочих навантажень. Робоче навантаження може ускладнюватися в міру впровадження нових технологій для покращення користувацького досвіду. Ці зміни можуть збільшувати або зменшувати показники відновлення.
Нотатка
Середній час напрацювання на відмову може бути складним для визначення та гарантування. Платформи як послуга (PaaS) або програмне забезпечення як послуга (SaaS) можуть вийти з ладу та відновитися без будь-якого повідомлення від постачальника хмарних послуг, і процес може бути повністю прозорим для вас. Якщо ви визначаєте цілі для цього показника, охоплюйте лише ті компоненти, які вам під вашим контролем.
Побудова моделі здоров’я
Використовуйте зібрані дані для цілей надійності, щоб побудувати модель здоров’я для кожного робочого навантаження та пов’язаних із ним критичних потоків. Модель здоров’я визначає здорові, деградовані та нездорові* стани для потоків і робочих навантажень. Держави забезпечують відповідну оперативну пріоритезацію. Ця модель також відома як модель світлофора. Модель призначає зелений колір для здорових, жовтий – для деградованих, а червоний – для нездорових. Модель здоров’я гарантує, що ви знаєте, коли стан потоку змінюється зі здорового на погіршений або нездоровий.
Те, як ви визначаєте здорові, деградовані та нездорові стани, залежить від ваших цілей надійності. Ось кілька прикладів способів визначення станів:
Зелений або здоровий стан вказує на те, що ключові нефункціональні вимоги та цілі повністю задоволені, а ресурси використовуються оптимально.
Жовтий або деградований стан вказує на те, що один або кілька компонентів потоку попереджають про досягнення визначеного порогу, але потік працює. Наприклад, було виявлено дроселювання сховища.
Червоний або нездоровий стан вказує на те, що деградація триває довше, ніж це дозволено вашими цілями надійності, або що потік став недоступним.
Нотатка
Модель охорони здоров’я не повинна ставитися до всіх невдач однаково. Модель здоров’я повинна розрізняти перехідні та неперехідні несправності. Він повинен чітко розрізняти очікувано-швидкоплинні, але відновлювані збої і справжній стан катастрофи.
Ця модель працює за допомогою стратегії моніторингу та оповіщення, яка розроблена та функціонує на принципах постійного вдосконалення. У міру того, як змінюються ваші робочі навантаження, ваші моделі здоров’я повинні розвиватися разом з ними.
Щоб отримати докладні вказівки щодо конфігурацій моніторингу та оповіщення, перегляньте посібник із моніторингу стану здоров’я.
Візуалізація
Щоб інформувати свої операційні команди та зацікавлені сторони про стан у режимі реального часу та загальні тенденції моделі стану робочого навантаження, розгляньте можливість створення інформаційних панелей у своєму рішенні для моніторингу . Обговорюйте із зацікавленими сторонами рішення щодо візуалізації, щоб переконатися, що ви надаєте інформацію, яку вони цінують і яку легко споживати. Вони також можуть захотіти бачити створені звіти щотижня, щомісяця або щокварталу.
Power Platform Сприяння
Power Platform SLA забезпечують зобов’язання Microsoft щодо часу безвідмовної роботи та підключення. Різні сервіси мають різні SLA, і іноді артикули всередині сервісу мають різні SLA. Щоб дізнатися більше, перегляньте статтю Угоди про рівень обслуговування для онлайнових служб.
SLA Power Platform включає процедури отримання кредиту на послуги, якщо SLA не виконується, а також визначення доступності для кожної послуги. Цей аспект SLA діє як політика правозастосування.
Microsoft Business Applications надає можливості безперервності бізнесу та аварійного відновлення (BCDR) для всіх середовищ виробничого типу в додатках Dynamics 365 та Power Platform SaaS. Дізнайтеся, як Microsoft забезпечує стійкість ваших виробничих даних під час регіональних збоїв.
Організаційна узгодженість
Cloud Adoption Framework містить вказівки щодо рекомендацій для SLO та SLI, пов’язаних із моніторингом у всій організації.
Щоб дізнатися більше, перегляньте статтю Протокол SLO для хмарного моніторингу.
Чек-лист надійності
Зверніться до повного зведення рекомендацій.