Рекомендації щодо розробки стратегії пом’якшення наслідків збоїв розгортання

Застосовується до цієї Power Platform рекомендації контрольного списку Well-Architected Operational Excellence:

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

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

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

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

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

Стратегія пом’якшення наслідків збоїв розгортання складається з п’яти великих етапів:

1. Виявлення: щоб відреагувати на невдале розгортання, спочатку потрібно виявити збій. Виявлення може набувати кількох форм, як-от невдалі тести на дим, звіти користувачів або сповіщення, які генерує ваша платформа моніторингу.
2. Рішення: Ви повинні вирішити, яка найкраща стратегія пом’якшення наслідків для конкретного типу відмови.
3. Пом’якшення: Ви повинні виконати визначені дії щодо пом’якшення наслідків. Пом’якшення може набувати форми запасного варіанту, відкату або перекату вперед.
4. Комунікація: зацікавлені сторони та постраждалі користувачі мають бути поінформовані про статус, коли ви виявляєте проблему та вирішуєте її, як того вимагає ваш план реагування на надзвичайні ситуації.
5. Postmortem: Blameless postmortem надають можливість команді з робочого навантаження визначити сфери, які потребують вдосконалення, і створити плани для застосування отриманих знань.

У наступних розділах наведено детальні рекомендації для цих етапів.

Виявлення

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

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

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

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

Рішення

Прийняття рішення про відповідну стратегію пом’якшення наслідків у зв’язку з проблемою розгортання передбачає врахування таких факторів, як:

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

• Методи, які є у вашому розпорядженні для обходу питання. Приклади включають використання прапорців функцій, змінних середовища або будь-якого іншого типу властивості конфігурації під час виконання, яку ви можете вмикати та вимикати. Іноді проблему можна легко обійти, вимкнувши прапорець функції або перемкнувши параметр. У такому разі ви зможете:

  • Приступайте до розгортання.
  • Уникайте падіння назад.
  • Відкат назад, поки ви виправляєте код, що порушує правила.

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

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

Усунення

Нижче наведено деякі поширені стратегії пом’якшення наслідків:

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

  Важливо, щоб уся команда з робочого навантаження погодилася щодо значення слова «останній відомий товар». Цей вираз стосується останнього стану робочого навантаження, який був здоровим до початку розгортання, який не обов’язково є попередньою версією програми.

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

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

  У випадку з розгортанням canary відступ може бути непростим або навіть можливим, залежно від вашої інфраструктури та дизайну програми. Якщо вам потрібно виконати масштабування, щоб впоратися з навантаженням на системи, які не оновлені, виконайте це масштабування, перш ніж повертатися.

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

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

• Екстрене розгортання (поточне виправлення): якщо ви можете вирішити проблему в середині випуску, поточне виправлення може бути найпрактичнішою стратегією пом’якшення наслідків.

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

Communication

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

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

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

Патологоанатомічне

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

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

Міркування та загальні рекомендації

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

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

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

Виконайте аналіз режиму відмови ваших конвеєрів безперервної інтеграції та безперервної доставки (CI/CD), щоб допомогти виявити проблеми, які можуть ускладнити зусилля з усунення наслідків. Як і у випадку з вашим робочим навантаженням в цілому, ваші конвеєри можна проаналізувати, щоб виявити області, які можуть бути проблематичними, коли ви намагаєтеся застосувати певний тип пом’якшення наслідків.

Використовуйте функцію автоматичного відкату розсудливо:

• Деякі інструменти CI/CD, такі як Azure DevOps , мають вбудовану функцію автоматичного відкату. Розгляньте можливість використання цієї функції, якщо вона приносить вам відчутну цінність.
• Вам слід впроваджувати функцію автоматичного відкату лише після ретельного та регулярного тестування вашого конвеєра. Переконайтеся, що ваш конвеєр достатньо зрілий, щоб виникнути додаткові проблеми у разі спрацьовування автоматичного відкату.
• Ви повинні бути впевнені, що автоматизація розгортає лише необхідні зміни та що вона спрацьовує лише за потреби. Ретельно розробляйте свої тригери, щоб відповідати цим вимогам.

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

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

Power Platform сприяння

Pipelines має на Power Platform меті демократизувати керування життєвим циклом програм (ALM) для Power Platform клієнтів і клієнтів Dynamics 365 шляхом впровадження автоматизації ALM і можливостей безперервної інтеграції та безперервної доставки (CI/CD) у службу.

Microsoft Power Platform Інструменти збірки можна Azure DevOps використовувати для автоматизації поширених завдань збірки та розгортання, пов’язаних із створеними програмами Power Platform.

Дії GitHub дають Power Platform розробникам змогу створювати автоматизовані робочі процеси життєвого циклу розробки програмного забезпечення. За допомогою справ GitHub для Microsoft Power Platform ви можете створювати робочі цикли в своєму репозиторії для розробки, тестування, пакування та розгортання програм; виконувати автоматизацію; та керувати ботами й іншими компонентами, побудованими на Microsoft Power Platform.

ALM Accelerator — це інструмент із відкритим вихідним кодом, який складається з набору програм, сценаріїв і конвеєрів, призначених для автоматизації процесу безперервної інтеграції/безперервної доставки.

Автоматизуйте тести за допомогою Azure Pipelines.

Використовуйте комплект Power CAT для налаштування агентів і тестів. Copilot Studio Виконуючи окремі тести Copilot Studio для API (Direct Line), відповіді агентів оцінюються за очікуваними результатами.

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

Power Platform середовища надають функцію відновлення в певний момент часу, яка може допомогти вам відкотитися.

Power Platform інтегрується з Application Insights екосистемою Azure Monitor , яка є частиною неї. Використовуйте цю інтеграцію для:

• Отримуйте телеметрію про діагностику та продуктивність, зафіксовану платформою Dataverse , в Application Insights. Ви можете оформити передплату й отримувати телеметрію операцій, що виконуються програмами в базі даних Dataverse і в модельних програмах. Ця телеметрія містить відомості, які ви можете використовувати для діагностики, пошуку та виправлення проблем, пов’язаних із помилками та продуктивністю.

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

• Налаштуйте Power Automate телеметрію для flow; Application Insights наприклад, для моніторингу виконання хмарних потоків і створення сповіщень про збої в роботі хмарного потоку.

• Збирайте дані телеметрії від свого Microsoft Copilot Studio агента для використання в Azure Application Insights. Ви можете використовувати цю телеметрію для моніторингу зареєстрованих повідомлень і подій, надісланих вашому агенту та від нього, тем, які будуть активовані під час розмов користувачів, а також користувацьких подій телеметрії, які можна надіслати з ваших тем.

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

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

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