Примітка
Доступ до цієї сторінки потребує авторизації. Можна спробувати ввійти або змінити каталоги.
Доступ до цієї сторінки потребує авторизації. Можна спробувати змінити каталоги.
Стосується цієї Power Platform рекомендації щодо контрольного списку Well-Architected Reliability:
| RE:06 | Перевіряйте сценарії стійкості та доступності, застосовуючи принципи хаос-інжинірингу у своїх тестових та виробничих середовищах. Використовуйте тестування, щоб переконатися, що ваші витончені стратегії реалізації деградації ефективні, виконуючи активне тестування на несправності та імітацію навантаження. |
|---|
У цьому посібнику описано рекомендації щодо розробки стратегії тестування надійності для перевірки та оптимізації надійності вашого робочого навантаження. Тестування надійності зосереджується на стійкості та доступності вашого робочого навантаження, зокрема на критичних потоках, які ви визначаєте під час розробки свого рішення. Цей посібник містить загальні вказівки та вказівки щодо тестування, які стосуються впровадження несправностей та інженерії хаосу.
Визначення
| Термін | Визначення |
|---|---|
| Доступність. | Кількість часу, протягом якого робоче навантаження програми виконується в здоровому стані без значних простоїв. |
| Інженерія хаосу | Практика піддання додатків і послуг реальним навантаженням і збоям. Метою хаос-інжинірингу є створення та перевірка стійкості до ненадійних умов та відсутніх залежностей. |
| Уприскування несправностей | Акт внесення помилки в систему для перевірки стійкості системи. |
| Відновлюваність | Синонім до слова стійкість. |
| Відмовостійкість | Здатність робочого навантаження програми витримувати режими відмови та відновлюватися з них. |
Ключові стратегії дизайну
Тестування необхідне для того, щоб переконатися, що ваше робоче навантаження відповідає цільовим показникам надійності та може витончено справлятися з помилками. Ін’єкція несправностей — це тип тестування, який навмисно вводить несправності або стрес у вашу систему для моделювання реальних сценаріїв. Використовуючи методи впровадження несправностей та інженерії хаосу, ви можете завчасно виявляти та усувати проблеми, перш ніж вони вплинуть на ваше виробниче середовище. Цей розділ містить загальні вказівки щодо тестування, впровадження несправностей та інженерії хаосу для вашого робочого навантаження.
Загальні вказівки з тестування
Регулярно виконуйте тестування, щоб перевірити існуючі порогові значення, цілі та припущення. Коли у вашому робочому навантаженні відбуваються серйозні зміни, проводьте регулярне тестування. Виконуйте більшість тестувань у тестових та проміжних середовищах. Також корисно проводити підмножину тестів проти виробничої системи.
Автоматизуйте тестування, щоб забезпечити стабільне покриття тестів і відтворюваність. Автоматизуйте поширені завдання тестування та інтегруйте їх у свої процеси збірки. Ручне тестування програмного забезпечення є виснажливим і вразливим до помилок, але ви можете проводити ручне дослідницьке тестування. Для випадків, коли потрібно розробити автоматизоване тестування, використовуйте ручне тестування, щоб визначити обсяг тестів, які потрібно розробити.
Застосовуйте підхід тестування зі зсувом вліво, щоб виконувати тестування відмовостійкості та доступності на ранніх етапах циклу розробки.
Адаптуйте простий формат документації, щоб кожен міг легко зрозуміти процес і результати кожного регулярного тестування.
Діліться задокументованими результатами з відповідними командами, такими як операційні команди, технологічне керівництво, зацікавлені сторони бізнесу та зацікавлені сторони аварійного відновлення. Результати повинні враховувати уточнення цільових показників надійності, таких як цілі на рівні обслуговування (SLO), угоди на рівні обслуговування (SLA), цілі часу відновлення (RTO) та цілі точок відновлення (RPO).
Створіть регулярну тестову каденцію для своїх резервних копій. Відновлюйте дані в ізольованих системах, щоб переконатися, що резервні копії дійсні та що відновлення функціонує.
Документуйте показники часу відновлення та діліться ними зі своїми зацікавленими сторонами, щоб переконатися, що очікування щодо відновлення відповідають дійсності.
Використовуйте стандартні процедури тестування розгортання, щоб забезпечити автоматизований, передбачуваний і ефективний процес розгортання.
Перевірте здатність вашого робочого навантаження витримувати перехідні збої. Для отримання додаткової інформації дивіться Рекомендації щодо поводження з перехідними несправностями.
Перевірте, як ваше робоче навантаження справляється зі збоями в залежних службах або іншими залежностями, використовуючи ін’єкцію помилок.
Перевірте свій план аварійного відновлення, щоб реагувати на катастрофічні збої та інші серйозні інциденти.
Перевірте здатність вашого робочого навантаження до витонченої деградації та мінімізуйте радіус вибуху несправності компонентів за допомогою впорскування несправностей.
Скористайтеся перевагами планових та позапланових відключень
Коли ваше робоче навантаження відключене через планове технічне обслуговування або незаплановане відключення, у вас є унікальна можливість провести тестування та покращити розуміння свого робочого навантаження. У наступних розділах наведено рекомендації для кожного сценарію.
Заплановане технічне обслуговування
Коли у вас заплановані вікна обслуговування для оновлень або виправлень, ви можете протестувати компоненти та потоки, які не беруть участі в роботі з обслуговування. Виконуйте тести без потенційного ризику несподівано погіршити робоче навантаження або взагалі перевести його в автономний режим. Якщо у вас достатньо часу під час періоду технічного обслуговування, ви також можете перевірити компоненти та потоки, які беруть участь у технічному обслуговуванні, після завершення робіт з технічного обслуговування.
Позапланове відключення електроенергії
Використовуйте кожен інцидент відключення як можливість дізнатися більше про своє робоче навантаження та підвищити його стійкість, дотримуючись цих кроків, упорядкованих за пріоритетом:
Поверніть робоче навантаження в онлайн для своїх користувачів. Можливо, вам доведеться обійти проблему, вирішити її або ініціювати процеси відновлення.
Визначте першопричину відключення та усуньте її. Якщо ви можете усунути основну причину в рамках розслідування, задокументуйте основну причину та заходи, які ви вжили для її усунення. Якщо проблема вимагатиме повторного періоду технічного обслуговування пізніше, переконайтеся, що ваші заходи щодо пом’якшення наслідків можуть впоратися з очікуваним навантаженням, ретельно перевіривши їх. Переконайтеся, що ви встановили достатній моніторинг для охоплення ваших заходів щодо пом’якшення наслідків.
Якщо застосовно, шукайте ту саму проблему або слабкі місця конфігурації, на які можуть вплинути подібні проблеми, у всіх компонентах вашого робочого навантаження. Використовуйте цю можливість, щоб активно працювати над цими компонентами. Перегляньте історію інцидентів, щоб виявити закономірності подібних проблем у вашому робочому навантаженні.
Використовуйте отримані результати для вдосконалення стратегії тестування. Переконайтеся, що ви успішно усунули першопричину та подібні проблеми, безпосередньо перевіривши ту саму несправність.
Інжинірингові вказівки щодо впровадження несправностей і хаосу
Тестування на впровадження несправностей слідує принципам інженерії хаосу, підкреслюючи здатність робочого навантаження реагувати на збої компонентів. Виконуйте випробування на несправжнє впорскування в передвиробничому та виробничому середовищах. Застосуйте інформацію, отриману під час аналізу режиму відмови, щоб переконатися, що ви тестуєте лише ті несправності, які вам до вподоби, і що у вас є стратегії пом’якшення наслідків, які усувають несправності.
Ключовими принципами хаос-інжинірингу є:
Дійте на випередження. Не чекайте, поки трапляться невдачі. Намагайтеся передбачати збої, проводячи експерименти з хаосом, щоб виявити та усунути проблеми, перш ніж вони вплинуть на ваше виробниче середовище.
Прийміть невдачу. Приймайте збої, які відбуваються у вашій системі, і вчіться на них. Сприймайте збої як природну частину складних систем і використовуйте їх як можливість вчитися та підвищувати надійність вашої системи.
Зламати систему. Навмисно вводьте несправності або стрес у свою систему, щоб перевірити її стійкість. Моделюйте реальні збої або збої, щоб перевірити та покращити можливості відновлення робочого навантаження.
Формувати імунітет. Використовуйте експерименти з хаос-інженерії, щоб покращити здатність вашого робочого навантаження запобігати збоям і відновлюватися після них.
Хаос-інжиніринг є невід’ємною частиною командної культури робочого навантаження та постійною практикою, а не короткостроковими тактичними зусиллями у відповідь на один збій. Дотримуйтесь цього стандартного методу під час розробки експериментів із хаосом:
Почніть з гіпотези. Кожен експеримент повинен мати чітку мету, наприклад, перевірити здатність потоку витримувати втрату певного компонента.
Виміряйте базову поведінку. Переконайтеся, що під час проведення експерименту ви маєте стабільні показники надійності та продуктивності потоку та компонентів, які беруть участь у експерименті, і порівнюйте їх із погіршеним станом.
Ін’єкція несправності або несправностей. Експеримент повинен навмисно бути спрямований на конкретні компоненти, які можна швидко відновити, і ви повинні мати обґрунтоване очікування ефекту, який викличе ін’єкція несправності, щоб допомогти контролювати радіус вибуху експерименту.
Слідкуйте за результуючим поведінкою. Зберіть телеметричні дані про окремі компоненти потоку та наскрізну поведінку потоку, на яку спрямований експеримент, щоб правильно зрозуміти наслідки несправності. Порівняйте зібрані показники з базовими, щоб отримати повну картину результатів ін’єкції несправностей.
Задокументуйте процес і спостереження. Ведення детальних записів ваших експериментів допоможе вам прийняти майбутні рішення щодо структури робочого навантаження, гарантуючи, що ви усунете прогалини, які були виявлені з часом.
Визначте результат і дійте відповідно до нього. Плануйте кроки виправлення, які можна додати до списку невиконаного робочого навантаження як покращення. Переконайтеся, що плани вдосконалення дизайну переглядаються та тестуються в невиробничих середовищах за тими самими процесами, що й інші розгортання.
Періодично перевіряйте свої процеси, вибір архітектури та коду, щоб швидко виявляти технічні заборгованості, інтегрувати нові технології та адаптуватися до мінливих вимог.
Коли ви проводите експерименти з ін’єкцією несправностей, ви:
Переконайтеся, що моніторинг на місці та сповіщення налаштовано.
Перевірте процес призначення безпосередньо відповідальної особи (DRI) для взяття на себе відповідальності за інцидент.
Переконайтеся, що ваша документація та процеси розслідування актуальні.
Інтегруйте наступні рекомендації та міркування, щоб оптимізувати свою стратегію тестування хаосу:
Припущення системи викликів. За допомогою тестування ви намагаєтеся підвищити стійкість свого робочого навантаження та стратегії проектування робочого навантаження. Шукайте можливості вносити несправності в компоненти та потоки, які, на вашу думку, є надійними, виходячи з минулого досвіду. Вони можуть бути ненадійними у вашому новому робочому навантаженні.
Підтвердьте зміни. Без ретельного тестування, включаючи тестування на виявлення несправностей, ви можете мати неповну картину свого робочого навантаження після внесення змін. Наприклад, ви можете вводити нові залежності, які не відразу помітні.
Використовуйте буфери SLA. Обмежте тестування хаосу, щоб залишатися в межах своїх угод про рівень обслуговування та уникнути потенційних несприятливих наслідків збоїв. Цілі відновлення потоку та компонентів допомагають визначити обсяг вашого тестування.
Встановіть бюджет помилок як інвестицію в хаос і ін’єкцію помилок. Ваш бюджет помилок – це різниця між досягненням 100% SLO та досягненням узгодженого SLO.
Припиніть експеримент, якщо він виходить за рамки. Невідомі результати є очікуваним результатом експериментів з хаосом. Прагніть досягти балансу між збором суттєвих даних про результати та впливом на якомога меншу кількість користувачів виробництва.
Тісно співпрацюйте з командами розробників, щоб забезпечити актуальність впроваджених збоїв. Використовуйте минулі інциденти або проблеми як орієнтир. Вивчіть залежності та оцініть результати, коли ви їх видалите.
Виявляйте та документуйте раніше невиявлені залежності між різними компонентами у вашому робочому навантаженні, які виявляються за допомогою тестування хаосу.
За потреби коригуйте плани відновлення, щоб врахувати залежності, які виявляються під час тестування хаосу.
Використовуйте результати своїх експериментів і тестів як основу для нових експериментів і тестів. Коли виникає неочікувана поведінка, нові тести можуть бути націлені безпосередньо на цю поведінку та дати вам можливість розробити стратегії виправлення ситуації.
Компроміс: випробування на наявність несправностей у виробництві може бути руйнівним і потенційно спричинити простої. Будьте прозорими із зацікавленими сторонами щодо цієї можливості та переконайтеся, що у вас є гарантії для припинення експериментів і планів відкату, щоб швидко скасувати запроваджені вами збої.
Power Platform Сприяння
Ви можете використовувати статичні результати Power Automate , щоб повернути фіксований результат для перевірки вашого робочого навантаження.
Power Apps Test Engine (попередній перегляд) – це Power Platform компонент CLI, який можна використовувати для тестування автономних програм на полотні Power Apps.
Azure Test Plans – це просте у використанні рішення для керування тестами на основі браузера, яке надає всі можливості, необхідні для планового ручного тестування, приймального тестування користувачами, дослідницького тестування та збору відгуків від зацікавлених сторін.
Якщо ваше робоче навантаження включає ресурси Azure, ви можете використовувати Azure Chaos Studio – керовану службу, яка використовує хаос-інженерію, щоб допомогти вам вимірювати, розуміти та покращувати стійкість хмарних програм і служб.
Якщо ваше робоче навантаження включає агента Microsoft Copilot Studio , ви можете використовувати Power CAT Copilot Studio Kit для налаштування агентів і тестів. Виконуючи окремі тести Copilot Studio для API (Direct Line), відповіді агентів оцінюються за очікуваними результатами.
Чек-лист надійності
Зверніться до повного зведення рекомендацій.