Единица 11 / 11

Верификација на производи, стратегии за издавање и работен тек на вештачка интелигенција од крај до крај

Добивки:

  • Разбирање на стратегиите за ослободување за намалување на ризикот (сино-зелена, канаринска, карактеристика знаме) и дисциплина за верификација на производот (проверка на здравјето, тест за чад, следење на златен сигнал)
  • Способност да се имплементира навиката за подготовка на јасен план за враќање пред распоредувањето и проверка на критичните деловни патеки по распоредувањето
  • Способност да се комбинираат сите делови научени низ модулот во процес на работа поддржан од крај до крај со вештачка интелигенција и да се примени принципот „ВИ произведува, луѓето потврдуваат и гарантираат“ на секој чекор

Целиот овој модул течеше кон една точка: безбедно доставување на кодот и инфраструктурата до производството (животната средина што ја користат вистинските клиенти). Сега сме на најкритичната и најстресната алка во синџирот: добивање на промена во живо и потврдување дека таа навистина функционира таму. Грешката овде не е апстрактна - таа директно ги погодува клиентите, приходите и репутацијата. Затоа зрелите тимови одат на производство не со „надевање“ туку со контролирани стратегии за ослободување и систематска верификација.

Во оваа завршна единица комбинираме две работи: (1) методи на ослободување кои го намалуваат ризикот (канарски, сино-зелено, знаме на карактеристика) и дисциплина на верификација на производството; (2) како секое парче што го научивме низ модулот - CI/CD, IaC, контејнер, мониторинг, инцидент, цена, скрипта, безбедност - се спојува во еден работен тек од крај до крај напојуван со вештачка интелигенција. Ајде да го повториме првичниот цитат за последен пат: ВИ генерира и забрзува нацрти на секој чекор; Но, вие сте тој што го притиска копчето „Јас го земам ова во живо“ и гарантирате за исходот.

Ослободете ги стратегиите што го намалуваат ризикот

Притискање на промена на сите корисници во исто време е најризичниот начин. Зрели методи:

  • Сино-зелено распоредување: се одржуваат две идентични околини - „сино“ (во живо) и „зелено“ (нова верзија). Новата верзија е подготвена и тестирана во зелено, па сообраќајот наеднаш се префрла во зелено. Ако има проблем, сообраќајот веднаш се враќа во сино. Брзото враќање назад е неговата најголема предност.
  • Распоредување на Канари: Новата верзија најпрво се издава на мал процент од корисници (на пр. 5%); Ако метриката е добра, постепено зголемувајте се на 100%. Проблемот влијае на мал дел од корисникот, а не на целиот корисник.
  • Знаме на функција: Новата функција го внесува кодот, но е блокирана со знаменце; Се отвора за одредени корисници кога ќе се побара. Постои разлика помеѓу распоредување и „ослободување“; Ако има проблем, знамето се исклучува без враќање на кодот.
Совет: Најбрзата безбедносна мрежа е да имате подготвено враќање пред секое распоредување. „Ако нешто тргне наопаку, како можам да се вратам на старата верзија за 60 секунди? Ако нема јасен одговор на прашањето, не сте подготвени да го направите тоа распоредување.

Проверка на производ: работата не завршува кога ќе заврши распоредувањето

Само затоа што распоредувањето изгледа „зелено“ не значи дека работи. Систематска верификација:

  1. Здравствени проверки: Дали услугата е во функција, дали /healthz реагира?
  2. Тестови за чад: Дали неколкуте најкритични кориснички патеки (најава, плаќање, пребарување) навистина функционираат? Автоматски и брз.
  3. Гледајте за златни сигнали: стапка на грешка по распоредувањето, латентност, дали сообраќајот е нормален? (Четири сигнали на единицата 6.)
  4. Проширете постепено: погледнете ги метриките на секој чекор додека го зголемувате процентот на Канари.
  5. Прозорец за набљудување: Внимателно следете одреден временски период (на пр. 30 мин.) по распоредувањето; Подмолните проблеми не се веднаш видливи.
Внимание: вештачката интелигенција може да произведе листа на тестови за чад или проверки, но ваша задача е да одредите кои патеки на корисниците се „критични“. ВИ дава општа листа; Само вие знаете дека вашиот тек на плаќања, вашата патека која најмногу генерира приходи, мора да се тестира.

Споредба на стратегии за ослободување

Стратегија

Главна предност

Цена/комплексност

најпогодни

Сино-зелена

Инстант враќање назад

Две средини = 2x ресурси

Ако брзото пронаоѓање е критично

канаринец

Го ограничува влијанието на мали парчиња

Потребно е управување со сообраќајот

Огромна корисничка база

Знаме на карактеристика

Одвојува распоредување од ослободување

Долг за управување со знаме

Постепено/таргетирано отворање

Во тек ажурирање

Едноставно, прифатливо за ресурсите

бавно враќање назад

Едноставни услуги

Работен тек напојуван со вештачка интелигенција од крај до крај

Сега ајде да го комбинираме целиот модул во еден тек. Да речеме дека објавувате нов микросервис. ВИ произведува нацрти на секој чекор; потврдувате на секој чекор:

  1. Код и контејнер (Unit 4): AI произведува оптимизирана, безбедна Dockerfile; Вие ја потврдувате не-тајноста и големината.
  2. CI/CD (Unit 2): Го пишува цевководот за тестирање-изградба-распоредување на AI; Ги стеснувате дозволите и ги проверувате тајните референци.
  3. Инфраструктура (Единица 3): Ги дефинира потребните ресурси со AI Terraform; Го читате излезот од планот и не барате неочекувани бришења.
  4. Оркестрација (Единица 5): вештачката интелигенција произведува Кубернетски манифести; го потврдувате ограничувањето на ресурсите, сондата и RBAC.
  5. Безбедност (Единица 10): дава приоритет на излезите за скенирање со вештачка интелигенција; Прво ги грабнувате експлоатирачките.
  6. Мониторинг (Единица 6): ВИ генерира правила за аларм и контролна табла; Ги тестирате праговите со вашите минати податоци.
  7. Објавување и валидација (оваа единица): Го прикажува тестот за чад со вештачка интелигенција и планот за враќање; почнуваш канаринци, гледај ја метриката, притискаш на копчето.
  8. Ако се случи инцидент (Единица 7): ВИ генерира хипотеза и постмортална скица; Ги проверуваш и учиш лекциите.
  9. Трошоци (Единица 8): ВИ го следи губењето на нови ресурси; Донесувате правилни одлуки за големина.

На секој чекор, заедничкото правило останува константно: ВИ произведува и забрзува, човекот проверува и гарантира. Ова е суштината на модулот.

три мини футроли

Случај 1 - Канарин ја ограничи катастрофата на 5%. Еден тим ја даде новата верзија на 5% корисници со канари. Контролната табла што ја произведе вештачката интелигенција веднаш покажа дека стапката на грешка скокна на 8% во овој дел. Тимот го врати назад без да го зголеми на 100%; Проблемот влијаеше само на 5% од корисниците, и тоа траеше неколку минути. Ако имаше распоредување на голем удар, сите клиенти ќе бидат погодени.

Случај 2 - тест за чад ја фати патеката што недостасуваше. ВИ понуди сет за тестирање на чад, но немаше проток на „плаќање“. Инженерот го додаде, знаејќи дека најкритичен прилив на приходи е плаќањето. Тестот по распоредувањето пропадна веднаш на чекорот за наплата - клучот од трета страна беше истечен. Потврдата откри тивка загуба на приход за неколку минути.

Случај 3 - подготвено враќање зачувано за 90 секунди. Тим кој инсталираше сино-зелена ја презеде новата верзија во зелена; По 2 минути доцнењето се удвои. Сообраќајот го претворија во сино за 90 секунди со враќањето кое однапред го подготвија. Тие ја открија основната причина (бавно барање во новата верзија) не под притисок, а потоа мирно. Подготвената патека за враќање назад го направи прекинот речиси невидлив.

Четири шаблони за копирање

1) Избор на стратегија за издавање:

Ќе ја подготвам следнава услуга: [СЕРВИС/КОНТЕКСТ: број на корисници, толеранција на прекини, инфраструктура]. Кое го препорачувате помеѓу сино-зелените, канаринските и играните знамиња? Споредете ги предностите, трошоците и брзината на враќање на секој во овој контекст. Дајте предлог, но наведете дека јас ќе ја донесам конечната одлука.

2) Список за тест/верификација за чад:

Направете нацрт-тест за чад и листа за верификација за [SERVICE] што ќе ја извршувам по распоредувањето: здравствена проверка, најкритичните патеки на корисниците, кои метрики треба да ги следам за колку минути? Претпоставете дека ќе ги обележам најкритичните деловни патеки и ќе го оставам тоа поле празно.

3) План за враќање:

Јас користам [МЕТОД НА РАСПОДЕЛУВАЊЕ]. Напиши ми јасен план за враќање назад: со која команда/чекор да се вратам на старата верзија, колку време е потребно, кои се ризиците од самото враќање (на пр., миграцијата на базата на податоци не може да се врати назад), што треба да проверам пред враќање назад?

4) Список за проверка од крај до крај:

Направете листа за проверка од крај до крај за подготовка за пуштање во нов проект [СЕРВИС]: безбедност на код/слика, цевковод, инфраструктурен план, следење и алармирање, безбедносно скенирање, стратегија за ослободување, враќање и верификација. Проверете ја секоја ставка со прашањето „Дали сум подготвен? Претворете го во прашање.

Слаб промпт / Силен промпт

Слаб: "Како да го внесам ова во прод?"

Резултат: нема контекст; Вештачката интелигенција наведува општи чекори за распоредување, таа не се однесува на вашата толеранција на ризик, скала на корисникот и потреба за враќање назад.

Güçlü: "Ќе поттикнам услуга за плаќање со 10 милиони корисници, мојата толеранција за застој е многу мала. Дали препорачувате Canary или Blue-Green, зошто? Кои критични патеки треба да ги тестирам по распоредувањето, кои метрики треба да ги набљудувам колку минути и каков треба да биде планот за враќање од 60 секунди? Јас ќе ја донесам конечната одлука."

Разлика: вториот промпт ја дава скалата, толеранцијата и очекувањата за враќање назад; Потребна е стратегија + верификација + поништување и одлуката ја остава на човекот.

Вообичаени грешки

  • Распоредување без план за враќање. Ако нема враќање, секое распоредување е коцкање.
  • Распоредување на голем удар. Давањето на целиот корисник одеднаш го максимизира ризикот.
  • Претпоставувајќи „зелено = работа“. Службата што ја поминала здравствената проверка може да биде пробиена на критичната патека.
  • Мислејќи дека оставате критични деловни патишта на вештачката интелигенција. Мора да ги означите методите како плаќање.
  • Не се следи по распоредувањето. Подмолните проблеми не се појавуваат во првата минута; потребен е прозорец за набљудување.
  • Мислам дека миграцијата на базата на податоци е реверзибилна. Некои промени не се враќаат назад; се планираат посебно.

Сумирано

Одењето на прод е најкритичната алка во синџирот и се прави не со „надевање“ туку со контролирани стратегии: сино-зелената обезбедува итно враќање назад, ограничувајќи го ефектот на канари на мало парче, одвојувајќи го распоредувањето на знамето на функцијата од ослободувањето. Работата не е завршена кога ќе заврши распоредувањето; Систематска верификација преку здравствени проверки, тестови за чад и следење на златниот сигнал е од суштинско значење. Вештачката интелигенција генерира и забрзува нацрти на секој чекор низ целиот модул - од Dockerfile до нафтоводот, од Terraform до правилото за аларм, од постмортам до анализа на трошоците. Но, останува компетентното лице кое го потврдува секој чекор, го притиска копчето оди во живо и гарантира за исходот. Ова е златното правило на DevOps со вештачка интелигенција од крај до крај.

Задача за апликација

Изберете услуга (вистинска или измислена) за објавување. (1) Изберете стратегија што одговара на вашиот контекст со шаблонот „Избор на стратегија за ослободување“ и напишете зошто. (2) Имајте генерирана листа за верификација со шаблонот „Тест за чад / листа за верификација“ и сами додајте ги најкритичните деловни патеки. (3) Подгответе план за враќање од 60 секунди со шаблонот „План за враќање“ и проверете дали има некои неповратни чекори во него.

листа за проверка

  • [ ] Избрав стратегија за ослободување (канари/сино-зелена/знаме) која одговара на мојот контекст.
  • [ ] Имам јасен и брз план за враќање подготвен пред распоредувањето.
  • [ ] Сам ги додадов најкритичните деловни патишта (на пр. плаќање) на моите тестови за чад.
  • [ ] По распоредувањето, ги надгледувам златните сигнали преку прозорец за набљудување.
  • [ ] Планирав и неповратни чекори (миграција на базата на податоци итн.).
  • [ ] Го потврдив планот за вештачка интелигенција на секој чекор; Донесов одлука да одам во живо.

Модул испит

1. Кое од следново е најдоброто позиционирање за DevOps и AI во облакот?

  • А) Вештачката интелигенција е асистент и алатка за поддршка на одлуки; Луѓето се одговорни за критичните одлуки кои влијаат на производот ✔
  • Б) Вештачката интелигенција може да ги финализира распоредувањата и тајната ротација без човечко одобрение
  • В) Вештачката интелигенција е корисна само за пишување документација, нема врска со инфраструктура
  • Г) Ревизијата е непотребна бидејќи вештачката интелигенција секогаш произведува посигурни команди од инженерот

Опис: Тоа е асистент и алатка за поддршка на одлуки што ги забрзува задачите интензивни на текст, како што се цевководот за вештачка интелигенција, конфигурацијата, скриптата и дневникот. Одговорноста за одлуките кои влијаат на времето на застој, парите и безбедноста, како што се објавувањето на производството, тајното управување и конечната примена, останува на надлежниот инженер.

2. Кој е најточниот израз за дисциплината за верификација пред да се имплементира командата или конфигурацијата DevOps произведена од вештачка интелигенција?

  • А) Ако излезот изгледа мазно и самоуверено, може да се работи директно во прод
  • Б) Излезот е безбеден само ако нема синтаксички грешки, не се потребни дополнителни проверки
  • В) Поврзете го излезот со изворот, испланирајте/суво и филтрирајте го со контекстот на вашиот систем; потоа примени ✔
  • Г) Да се направи првиот обид директно во прод и да се гледа резултатот е најбрзата верификација

Објаснување: Потврдата во три чекори е од суштинско значење: поврзување на излезот со изворот (дали е командата/знамето всушност во официјалните документи), сушење (види што се случува со планот/--dry-run) и поминување низ системскиот филтер (дали се вклопува во неговиот архитектонски и безбедносен контекст). Течноста не значи точност.

3. Кој е правилниот пристап кога се прашува вештачката интелигенција за грешка или проблем со распоредувањето со датотека .env која содржи вистинска лозинка за базата на податоци?

  • А) Маскирај ги вистинските тајни со <PLACEHOLDER>; споделете само маскирана грешка и контекст ✔
  • Б) Вметнувањето на целата датотека .env како што е го решава проблемот побрзо
  • В) Бидејќи тајните се веќе основни64, безбедно е да се залепи обична
  • Г) Вметнувањето на лозинката е безбедно бидејќи вештачката интелигенција никогаш не ја складира

Опис: Нема вистински тајни залепени во известувањето за вештачка интелигенција. Вредностите како лозинки и токени се маскирани со <PLACEHOLDER>; се споделуваат само пораката за грешка и потребниот контекст. Ако Тајната веќе е протечена, таа треба веднаш да се откаже и да се ротира.

4. Кое од наведеното е правилно управување со тајните (лозинка, токен) во CI/CD гасоводот?

  • А) Се чува во тајното складиште на платформата и се повикува со референца (на пр. ${{ secrets.X }}), не напишано во обичен текст ✔
  • Б) Напишано во обичен текст до цевководот YAML за погодност
  • В) Се потврдува со притискање на echo и log на почетокот на секоја работа.
  • Г) Ако е дефинирано со најширока дозвола (запишување-сите), безбедноста се зголемува

Објаснување: Тајните не се напишани на YAML во обичен текст; Се чува во тајното складиште на платформата и се нарекува со референци како ${{ secrets.X }}. Дополнително, со принципот на најмал авторитет, дозволите за токени се стеснуваат и тајниот дневник не се запишува.

5. Во управувањето со инфраструктурата со Terraform, кој е најкритичниот чекор што треба да се преземе пред да се спроведе промена во живо?

  • А) Директно трчање „terraform application“; планот е губење време
  • Б) Правење резервна копија од државната датотека во јавно складиште
  • В) Извршете го 'terraform plan' и проверете ги линиите уништи/замени на излезот, а потоа примени ✔
  • Г) Деинсталирајте ја верзијата на провајдер и уверете се дека најновата верзија доаѓа автоматски

Објаснување: „terraform plan“ мора да се изврши пред „terraform application“. Планот покажува што да се додаде, што да се промени, а особено што да се избрише (уништи), без да се направи ништо. Ако се види неочекувана линија за уништување или замена, апликацијата не треба да се применува.

6. Што значи и што треба да се направи ако линијата „-/+ замени“ за производната база на податоци се појави во излез од планот на Terraform?

  • А) Изворот само ќе се ажурира на лице место, нема ризик
  • Б) Ресурсот ќе биде избришан и повторно создаден; Постои ризик од губење на податоци, аплицирањето треба да се прекине доколку не се очекува ✔
  • В) Додавање нов ресурс, постоечката база на податоци не е засегната
  • Г) Ова е само предупредување, може безбедно да се игнорира

Објаснување: „-/+ замени“ значи дека ресурсот ќе биде избришан и повторно создаден; За базата на податоци, ова значи загуба на податоци. Ако не се очекува, аплицирањето треба да се прекине, промената треба да се претвори во безбеден метод или непроменливото поле треба да се остави недопрено.

7. Што од следново е точно за Dockerfile да биде подготвено за производство во однос на неговата безбедност и големина?

  • А) За погодност, вметнете ја тајната во сликата со ENV и стартувајте ја како root
  • Б) Секогаш користете ја ознаката „: најнов“ и одржувајте ја основната слика што е можно поголема
  • В) Изградба во една фаза и оставање на сите алатки за градба во конечната слика
  • Г) Невградување на тајната, работа со неовластен КОРИСНИК, користење мала и стабилна основна слика и повеќестепена градба ✔

Опис: Слика подготвена за производство: не ја вградува тајната (ја вбризгува при извршување), работи со неовластен КОРИСНИК наместо со root, користи мала и верзиирана основна слика (тенка/алпска, не: најнова) и е намалена со повеќестепена градба. Исто така, се скенира за пропусти пред објавувањето.

8. Кој е најважниот ризик од недефинирање на ограничувања на ресурсите за распоредување во Кубернетес?

  • А) Pod никогаш не започнува бидејќи ограничувањето е задолжително поле
  • Б) На таблата за мониторинг се појавува само предупредување, работата не е засегната
  • В) Kubernetes автоматски спроведува безбедни стандардни граници, без ризик
  • Г) Подлогата може неограничено да расте и да ги троши ресурсите на јазолот, со што ќе ги урива соседните услуги ✔

Објаснување: Pod кој нема ограничување на ресурсите може неограничено да расте, да ги троши сите ресурси на јазолот на кој работи и да ги урива соседните услуги, на пример, со истекување на меморијата. Затоа дефинирањето на барањата/ограничувањата е основата на робусноста.

9. Како да се избегне „замор на предупредување“ при мониторингот и поставувањето аларм?

  • А) Поставете аларми на што е можно повеќе метрики и генерирајте предупредувања со секоја флуктуација.
  • Б) Поставете ги сите аларми на највисоко ниво на сериозност
  • В) Активирање аларми со моментални вредности без поставување на време (за)
  • Г) Одржување на аларми ориентирани кон акција и во вистинската итност, тестирање на прагови со историски податоци, спојување на непотребните ✔

Опис: Секој аларм мора да биде активен и со вистинска итност; На таблата се прикажуваат информации за кои не е потребно дејство, никого не буди. Праговите за аларм се тестираат според историските податоци на системот и се консолидираат непотребните/повторливи аларми. На овој начин вистинскиот аларм нема да се изгуби во бучавата.

10. Која е најдобрата приоритетна нарачка за време на производствен инцидент?

  • А) Прво пронајдете ја точната основна причина и намалете ја само кога причината е јасна.
  • Б) Прво напишете го посмртниот извештај, а потоа допрете ја услугата
  • В) Прво намалете (услуга за обновување/обновување), оставајќи ја анализата на основната причина за подоцна ✔
  • Г) Прво пронајдете го одговорното лице за инцидентот и пријавете го

Објаснување: Златното правило е „намали прво, истражи подоцна“. Целта е прво да се врати услугата или да се врати на позната-добра верзија (ублажување); Анализата на коренските причини се прави мирно откако притисокот ќе се смири. Чекањето да се најде точната основна причина го зголемува времето за опоравување (MTTR).

11. Која е главната цел на беспрекорната постмортална култура?

  • А) Идентификување на лицето кое ја направило грешката и префрлање на одговорноста врз него/неа
  • Б) Фокусирање на системи и процеси и поттикнување на учењето; ✔ Учење лекции кои спречуваат повторување наместо обвинување
  • В) Никогаш не пријавувајте го инцидентот и погрижете се тој да биде заборавен
  • Г) Пишување само технички детали и не додавање ставки што можат да се применат

Објаснување: Бесполезната постмортам се фокусира на прашањето „кој систем и процес ја дозволи оваа грешка“, а не „кој го направи тоа“. Луѓето отворено ја споделуваат грешката ако знаат дека нема да бидат казнети; Скриената грешка се повторува. Извештајот не е извештај за обвинение, туку документ за учење полн со ставки ориентирани кон акција.

12. Во оптимизацијата на трошоците во облакот (FinOps), кој е најлогичниот чекор што треба да се преземе пред да се префрлите на посветени попусти (Резервиран/План за заштеда)?

  • А) Прво преземете ја најдолгата можна посветеност, а подоцна размислете за отпадот
  • Б) Прво, исчистете го отпадот (затворање во мирување, соодветна големина), потоа посветете се на посветена употреба ✔
  • В) Веднаш преместете ги сите ресурси во капацитетот на Spot
  • Г) Бришење на најскапата ставка без прегледување на податоците од фактурата

Објаснување: Отпадот мора прво да се исчисти (затворање на неработените ресурси, намалување на преголемите ресурси). Во спротивно, ќе го заклучите залудно користењето по намалена цена за 1-3 години. Правилната големина и чистењето во мирување не бараат посветеност и се блиску до безризични.

13. Која е најважната безбедносна мерка ако скрипта предложена од вештачка интелигенција ја има линијата „rm -rf „$DIR“/“?

  • А) Извршувањето на сценариото директно во прод без да го читате ќе се забрза
  • Б) Додајте set -euo pipefail и празна променлива контрола и обидете се прво со суво ✔
  • В) Доволно е скратување на името на променливата
  • Г) Со користење на rm -rf --force наместо rm се решава проблемот

Објаснување: ако $DIR е празна, оваа изјава може да се обиде да го избрише root директориумот. Застанувањето на недефинираната променлива со „set -u“ и проверката дека променливата не е празна пред да ја избришете (на пр. [ -n „$DIR“ ] || излез 1) избегнува катастрофа. Дополнително, прво треба да се испробаат деструктивни операции со суво.

14. Што е првото нешто што треба да направите ако клучот за пристап во облак случајно протече во јавно складиште?

  • А) Веднаш откажете го и обновите (ротирајте) клучот; Самото бришење не е доволно ✔
  • Б) Само избришете ја датотеката од складиштето и клучот е безбеден
  • В) Не правејќи ништо затоа што никој не го видел
  • Г) Правењето на складиштето приватно ја елиминира потребата да се ротира клучот

Објаснување: Откриената тајна мора веднаш да се откаже и да се ротира. Само бришењето на датотеката не е доволно бидејќи тајната останува во историјата на Git и јавните складишта се скенираат од ботови во рок од неколку секунди. По откажувањето/враќањето, влијанието се оценува и се додава таен скенер за да се спречи повторување.

15. Кој од наведените пристапи го минимизира ризикот при објавување на нова верзија на Prod?

  • А) Давање на новата верзија на сите корисници во исто време (биг-бенг) и не подготвување план за враќање
  • Б) Имајќи предвид дека распоредувањето е завршено веднаш штом ќе се појави „зелено“, не се врши дополнителна проверка
  • В) Користење на контролирана стратегија како што е канаринско/сино-зелено/карактеристичко знаме, готов план за враќање и тест за чад + метрички мониторинг по распоредувањето ✔
  • Г) Тестирањето на критичните деловни патеки целосно да се препушти на вештачката интелигенција и воопшто да не се одредуваат.

Објаснување: Стратегиите за контролирано ослободување (почнувајќи со мал процент со канаринци, итно враќање назад со сино-зелена, одвојување на распоредувањето од ослободувањето со знаменце за карактеристика) го ограничуваат ризикот. Дополнително, од суштинско значење се јасен план за враќање пред распоредувањето и следење на златниот сигнал со тестирање на чад по распоредувањето; „Изгледа зелено“ не значи дека работи.