Добици:
- Разумевање стратегија ослобађања за смањење ризика (плаво-зелена, канаринац, обележје обележја) и дисциплина верификације производа (провера здравља, тест дима, праћење златног сигнала)
- Способност имплементације навике припреме јасног плана враћања пре примене и верификације критичних пословних путања након примене
- Способност комбиновања свих делова научених кроз модул у свеобухватном току рада који подржава вештачка интелигенција и примена принципа „АИ производи, људи верифицирају и јамче за“ на сваком кораку
Цео овај модул текао је ка једној тачки: безбедна испорука кода и инфраструктуре у производњу (живо окружење које користе стварни купци). Сада смо на најкритичнијој и најстреснијој карици у ланцу: добијање промене уживо и провера да ли тамо заиста функционише. Грешка овде није апстрактна – она директно погађа купца, приход и репутацију. Због тога зрели тимови не иду у производњу „надајући се“, већ са контролисаним стратегијама ослобађања и систематском верификацијом.
У овој последњој јединици комбинујемо две ствари: (1) методе ослобађања које смањују ризик (канаринац, плаво-зелена, обележје обележја) и дисциплину верификације производа; (2) како се сваки део који смо научили кроз модул – ЦИ/ЦД, ИаЦ, контејнер, надгледање, инцидент, цена, скрипта, безбедност – спаја у један свеобухватни радни ток који покреће вештачка интелигенција. Хајде да последњи пут поновимо почетни цитат: АИ генерише и убрзава нацрте на сваком кораку; Али ви сте тај који притисне дугме „Снимам ово уживо“ и гарантује за исход.
Ослободите стратегије које смањују ризик
Гурање промене свим корисницима у исто време је најризичнији начин. Зреле методе:
- Плаво-зелена примена: Одржавају се два идентична окружења — „плаво“ (уживо) и „зелено“ (нова верзија). Нова верзија је припремљена и тестирана у зеленој боји, а затим се саобраћај одједном пребацује на зелено. Ако дође до проблема, саобраћај се одмах враћа у плаво. Брз повратак је његова највећа предност.
- Цанари имплементација: Нова верзија је прво објављена за мали проценат корисника (нпр. 5%); Ако су показатељи добри, постепено повећавајте на 100%. Проблем утиче на мали део корисника, а не на целог корисника.
- Ознака функције: Нова функција уноси код, али је блокирана заставицом; Отвара се одређеним корисницима када се то затражи. Постоји разлика између постављања и „пуштања“; Ако постоји проблем, заставица се искључује без враћања кода.
Савет: Најбржа сигурносна мрежа је да имате спреман враћање пре сваке примене. „Ако нешто пође наопако, како да се вратим на стару верзију за 60 секунди?“ Ако нема јасног одговора на питање, нисте спремни за то распоређивање.
Верификација производа: рад се не завршава када се заврши имплементација
Само зато што имплементација изгледа „зелено“ не значи да функционише. Систематска верификација:
- Здравствени прегледи: Да ли је услуга активна, да ли /хеалтхз реагује?
- Тестови дима: Да ли неколико најкритичнијих корисничких путања (пријава, плаћање, претрага) заиста функционише? Аутоматски и брзи.
- Пазите на златне сигнале: стопа грешака након имплементације, кашњење, да ли је саобраћај нормалан? (Четири сигнала на јединици 6.)
- Проширујте постепено: Гледајте метрику на сваком кораку док повећавате проценат Канара.
- Прозор за посматрање: пажљиво пратите одређени временски период (нпр. 30 мин) након постављања; Подмукли проблеми нису одмах видљиви.
Опрез: АИ може произвести листу тестова или верификација дима, али ваш је посао да одредите које су путање корисника „критичне“. АИ даје општу листу; Само ви знате да ваш ток плаћања, ваш пут који највише генерира приход, мора бити тестиран.
Поређење стратегија издавања
Стратегија
Главна предност
Цена/сложеност
најпогоднији
Плаво-зелена
Инстант роллбацк
Два окружења = 2к ресурса
Ако је брзо проналажење критично
канаринац
Ограничава утицај на мали комад
Потребно је управљање саобраћајем
Огромна база корисника
ФеатуреФлаг
Одваја примену од издања
Дуг управљања заставом
Постепено/циљано отварање
Роллинг упдате
Једноставан, приступачан ресурсима
споро враћање уназад
Једноставне услуге
Свеобухватни ток рада који покреће АИ
Хајде сада да комбинујемо цео модул у један ток. Рецимо да објављујете нову микроуслугу. АИ производи нацрте у сваком кораку; потврђујете на сваком кораку:
- Код и контејнер (Јединица 4): АИ производи оптимизован, сигуран Доцкерфиле; Ви проверавате не-тајну и величину.
- ЦИ/ЦД (Јединица 2): Пише АИ тест-буилд-деплои цевовод; Сужавате дозволе и проверавате тајне референце.
- Инфраструктура (Јединица 3): Дефинише потребне ресурсе са АИ Терраформом; Читате излаз плана и не тражите неочекивана брисања.
- Оркестрација (Јединица 5): АИ производи Кубернетес манифесте; ви верификујете ограничење ресурса, сонду и РБАЦ.
- Безбедност (Јединица 10): даје приоритет излазима АИ скенирања; Прво зграбите оне који се могу искористити.
- Мониторинг (Јединица 6): АИ генерише правила аларма и контролну таблу; Прагове тестирате својим прошлим подацима.
- Ослобађање и валидација (ова јединица): описује АИ тест дима и план враћања; покренеш канаринац, гледаш метрику, притиснеш дугме.
- Ако дође до инцидента (Јединица 7): АИ генерише хипотезу и постмортем скицу; Ви верификујете и научите лекције.
- Трошкови (Јединица 8): АИ прати расипање нових ресурса; Ви доносите праве одлуке о величини.
На сваком кораку, опште правило остаје константно: АИ производи и убрзава, човек верификује и гарантује. Ово је суштина модула.
три мини кофера
Случај 1 — канаринац је ограничио катастрофу на 5%. Тим је дао нову верзију за 5% корисника са канаринцем. Контролна табла коју је АИ произвела одмах је показала да је стопа грешке скочила на 8% у овом одсеку. Тим га је вратио без повећања на 100%; Проблем је захватио само 5% корисника, и то на неколико минута. Ако би дошло до великог праска, сви купци би били погођени.
Случај 2 — тест дима је ухватио путању која недостаје. АИ је понудио сет за тестирање дима, али није имао ток "плаћања". Инжењер је то додао, знајући да је најкритичнији ток прихода плаћање. Тест након имплементације се покварио одмах на кораку плаћања — кључ треће стране је истекао. Верификација је открила тихи губитак прихода за неколико минута.
Случај 3 — спреман повратак сачуван за 90 секунди. Тим који је инсталирао плаво-зелену узео је нову верзију у зелену; После 2 минута кашњење се удвостручило. Саобраћај су претворили у плаво за 90 секунди унапред припремљеним враћањем уназад. Открили су основни узрок (спор упит у новој верзији) не под притиском, а онда мирно. Спремна путања повратка учинила је прекид готово невидљивим.
Четири шаблона за копирање
1) Избор стратегије објављивања:
Продаћу следећу услугу: [СЕРВИС/КОНТЕКСТ: број корисника, толеранција прекида, инфраструктура]. Коју препоручујете између плаво-зелене, канаринца и обележја? Упоредите предности, трошкове и брзину враћања сваког од њих у овом контексту. Дајте предлог, али реците да ћу ја донети коначну одлуку.
2) Димни тест / листа верификације:
Направите нацрт теста дима и верификационе листе за [СЕРВИЦЕ] који ћу покренути након постављања: провера здравља, најкритичније путање корисника, које метрике треба да пратим колико минута? Претпоставимо да ћу означити најкритичније пословне путеве и оставити то поље празним.
3) План повратка:
Користим [МЕТОДУ РАЗВОЈА]. Напишите ми јасан план враћања: са којом командом/кораком да се вратим на стару верзију, колико дуго траје, који су ризици самог враћања (нпр. миграција базе података не може да се врати), шта треба да проверим пре враћања?
4) Контролна листа издања од краја до краја:
Направите комплетну припремну контролну листу за објављивање за нови [СЕРВИЦЕ] пројекат: безбедност кода/слике, цевовод, инфраструктурни план, надгледање и алармирање, безбедносно скенирање, стратегија објављивања, враћање и верификација. Означите сваку ставку питањем „Да ли сам спреман?“ Претворите то у питање.
Слаби промпт / Јаки промпт
Слабо: "Како да ово убацим у прод?"
Резултат: нема контекста; АИ наводи опште кораке имплементације, не бави се вашом толеранцијом ризика, обимом корисника и потребама за враћањем.
Гуцлу: „Покренућу услугу плаћања са 10 милиона корисника, моја толеранција застоја је веома ниска. Да ли препоручујете Цанари или Блуе-Греен, зашто? Које критичне путање да тестирам након имплементације, које метрике треба да пратим колико минута и какав треба да буде план враћања од 60 секунди? Ја ћу донети коначну одлуку.“
Разлика: други промпт даје скалу, толеранцију и очекивање враћања; Захтева стратегију + проверу + поништавање и препушта одлуку човеку.
Уобичајене грешке
- Примена без плана враћања. Ако нема повратка, свако распоређивање је коцка.
- Примена великог праска. Давање целом кориснику одједном повећава ризик.
- Под претпоставком „зелено = радно“. Сервис који је прошао здравствену проверу може бити покварен на критичном путу.
- Мислите да препуштате критичне пословне путеве АИ. Морате означити методе као што је плаћање.
- Не прати се након распоређивања. Подмукли проблеми се не појављују у првом минуту; прозор за посматрање је обавезан.
- Мислите да је миграција базе података реверзибилна. Неке промене се не враћају уназад; планирају се посебно.
Укратко
Прелазак на продукцију је најкритичнија карика у ланцу и не врши се „надом“ већ контролисаним стратегијама: плаво-зелена омогућава тренутно враћање уназад, ограничавајући ефекат канаринца на мали део, одвајајући примену заставице функције од објављивања. Посао није завршен када се заврши распоређивање; Систематска верификација кроз здравствене провере, тестове дима и праћење златног сигнала је од суштинског значаја. АИ генерише и убрзава нацрте на сваком кораку кроз читав модул — од Доцкерфиле-а до цевовода, од Терраформа до правила аларма, од постмортем до анализе трошкова. Али остаје компетентна особа која верификује сваки корак, притисне дугме за емитовање и гарантује за исход. Ово је златно правило енд-то-енд ДевОпс-а који покреће АИ.
Задатак апликације
Изаберите услугу (стварну или измишљену) за објављивање. (1) Изаберите стратегију која одговара вашем контексту са шаблоном „Избор стратегије за ослобађање“ и напишите зашто. (2) Направите верификациону листу помоћу шаблона „Смоке тест/верифицатион лист“ и сами додајте најкритичније пословне путање. (3) Припремите план враћања од 60 секунди са шаблоном „План враћања“ и проверите да ли у њему постоје неки неповратни кораци.
контролна листа
- [ ] Изабрао сам стратегију ослобађања (канаринац/плаво-зелена/застава) која одговара мом контексту.
- [ ] Имам јасан и брз план враћања спреман пре примене.
- [ ] Лично сам додао најкритичније пословне путање (нпр. плаћање) у своје Смоке тестове.
- [ ] Након постављања, пратим златне сигнале кроз прозор за посматрање.
- [ ] Такође сам планирао неповратне кораке (миграцију базе података, итд.).
- [ ] Проверио сам АИ план на сваком кораку; Одлучио сам да идем уживо.
Модул Екам
1. Шта од следећег је најбоље позиционирање за ДевОпс и АИ у облаку?
- А) Вештачка интелигенција је помоћник и алат за подршку одлучивању; Људи су одговорни за критичне одлуке које утичу на производ ✔
- Б) Вештачка интелигенција може да финализује распоређивање производа и тајну ротацију без људског одобрења
- В) Вештачка интелигенција је корисна само за писање документације, нема везе са инфраструктуром
- Д) Ревизија је непотребна јер вештачка интелигенција увек производи поузданије команде од инжењера
Опис: То је помоћни алат и алат за подршку одлучивању који убрзава задатке који захтевају пуно текста, као што су цевовод вештачке интелигенције, конфигурација, скрипта и дневник. Одговорност за одлуке које утичу на време застоја, новац и безбедност, као што су издавање производње, тајно управљање и коначна примена, остаје на надлежном инжењеру.
2. Који је најтачнији израз за дисциплину верификације пре имплементације ДевОпс команде или конфигурације коју производи вештачка интелигенција?
- А) Ако излаз изгледа глатко и поуздано, може се покренути директно у продукцији
- Б) Излаз је безбедан само ако нема синтаксичких грешака, нису потребне даље провере
- Ц) Повежите излаз са извором, планирајте/покрените на суво и филтрирајте га са контекстом вашег система; затим примените ✔
- Д) Први покушај директно у производу и гледање резултата је најбржа верификација
Објашњење: Верификација у три корака је неопходна: повезивање излаза са извором (да ли је команда/заставица заправо у званичним документима), покретање на суво (видети шта се дешава са планом/--дри-рун) и пролазак кроз системски филтер (да ли се уклапа у његов архитектонски и безбедносни контекст). Течност не значи тачност.
3. Који је исправан приступ када се вештачкој интелигенцији поставља питање о грешци или проблему са применом са .енв датотеком која садржи праву лозинку базе података?
- А) Маскирајте праве тајне са <ПЛАЦЕХОЛДЕР>; делите само маскирану грешку и контекст ✔
- Б) Налепљивање целе .енв датотеке онако како јесте решава проблем брже
- Ц) Пошто су тајне већ басе64, безбедно је залепити обичан
- Д) Лепљење лозинке је безбедно јер је вештачка интелигенција никада не чува
Опис: Ниједна стварна тајна се не лепи у АИ промпт. Вредности као што су лозинке и токени су маскиране са <ПЛАЦЕХОЛДЕР>; деле се само порука о грешци и неопходни контекст. Ако је Тајна већ процурила, треба је одмах отказати и ротирати.
4. Шта од следећег је исправно управљање тајнама (лозинком, токеном) у ЦИ/ЦД цевоводу?
- А) Чува се у тајном репозиторијуму платформе и позива се референцом (нпр. ${{ сецретс.Кс }}), није написан у обичном тексту ✔
- Б) Написано у отвореном тексту за цевовод ИАМЛ ради погодности
- Ц) Проверава се притиском на ецхо и лог на почетку сваког посла.
- Д) Ако се дефинише са најширом дозволом (врите-алл), безбедност се повећава
Објашњење: Тајне се не пишу у ИАМЛ у обичном тексту; Чува се у тајном спремишту платформе и позива се са референцама као што је ${{ сецретс.Кс }}. Поред тога, са принципом најмањег овлашћења, дозволе токена су сужене и тајни дневник се не бележи.
5. У управљању инфраструктуром са Терраформом, који је најкритичнији корак који треба предузети пре него што се промена спроведе уживо?
- А) Директно покретање 'терраформ аппли'; план је губљење времена
- Б) Прављење резервне копије датотеке стања у јавном спремишту
- Ц) Покрените 'терраформ план' и проверите линије уништења/замени у излазу, а затим примените ✔
- Д) Деинсталирајте верзију добављача и уверите се да најновија верзија долази аутоматски
Објашњење: 'терраформ план' се мора покренути пре 'терраформ аппли'. План показује шта треба додати, шта променити, а посебно шта обрисати (уништити), а да ништа не радите. Ако се види неочекивана линија уништења или замене, примена не треба да се примењује.
6. Шта то значи и шта треба урадити ако се линија '-/+ замени' за производну базу података појави у излазу Терраформ плана?
- А) Извор ће се само ажурирати на лицу места, нема ризика
- Б) Ресурс ће бити обрисан и поново креиран; Постоји ризик од губитка података, примену треба прекинути ако се не очекује ✔
- Ц) Додавање новог ресурса не утиче на постојећу базу података
- Д) Ово је само упозорење, може се безбедно занемарити
Објашњење: '-/+ замени' значи да ће ресурс бити обрисан и поново креиран; За базу података то значи губитак података. Ако се не очекује, примену треба зауставити, промену треба претворити у безбедан метод или непроменљиво поље треба оставити нетакнуто.
7. Шта је од следећег тачно да Доцкерфиле буде спреман за производњу у смислу његове безбедности и величине?
- А) Ради практичности, уградите тајну у слику помоћу ЕНВ-а и покренете је као роот
- Б) Увек користите ознаку ':латест' и нека основна слика буде што већа
- Ц) Једностепена израда и остављање свих алата за прављење у коначној слици
- Д) Не уграђује тајну, ради са неовлашћеним КОРИСНИКОМ, користећи малу и стабилну основну слику и вишестепену изградњу ✔
Опис: Слика спремна за производњу: не уграђује тајну (убацује је у време извођења), ради са неовлашћеним КОРИСНИКОМ уместо роот-а, користи малу и верзионисану основну слику (слим/алпине, а не :латест) и смањује се са вишестепеном градњом. Такође се скенира у потрази за рањивостима пре објављивања.
8. Који је најважнији ризик недефинисања ограничења ресурса за примену у Кубернетес-у?
- А) Под никада не почиње јер је ограничење обавезно поље
- Б) На табли за надзор се појављује само упозорење, то не утиче на рад
- Ц) Кубернетес аутоматски примењује безбедне подразумеване границе, без ризика
- Д) Под може неограничено да расте и троши ресурсе чвора, чиме се руши суседне услуге ✔
Објашњење: Под који нема ограничење ресурса може неограничено расти, трошити све ресурсе чвора на којем ради и срушити суседне услуге, на пример, са цурењем меморије. Зато је дефинисање захтева/ограничења основа робусности.
9. Како избећи 'замор од упозорења' у праћењу и постављању аларма?
- А) Подесите аларме на што више метрика и генеришите упозорења са сваком флуктуацијом.
- Б) Поставите све аларме на највиши ниво озбиљности
- Ц) Активирање аларма са тренутним вредностима без подешавања времена (за)
- Д) Одржавање аларма оријентисаних на акцију иу правој хитности, тестирање прагова са историјским подацима, спајање непотребних ✔
Опис: Сваки аларм мора бити подесив и хитан; Информације које не захтевају акцију су приказане на табли, никог не буди. Прагови аларма се тестирају на основу историјских података система, а непотребни/понављајући аларми се консолидују. На овај начин се прави аларм неће изгубити у буци.
10. Који је најбољи приоритет током инцидента у производњи?
- А) Прво пронађите тачан основни узрок и смањите га тек када је узрок јасан.
- Б) Прво напишите обдукцију, а затим додирните услугу
- Ц) Прво смањите (ресторе/ресторе сервице), остављајући анализу основног узрока за касније ✔
- Д) Прво пронађите особу одговорну за инцидент и пријавите га
Објашњење: Златно правило је 'прво смањи, а касније истражи'. Циљ је прво вратити услугу или је вратити на познату добру верзију (ублажити); Анализа основног узрока се ради мирно након што притисак попусти. Чекање да се пронађе тачан основни узрок повећава време опоравка (МТТР).
11. Која је главна сврха беспрекорне постмортем културе?
- А) Идентификовање особе која је направила грешку и стављање одговорности на њега/њу
- Б) Фокусирање на системе и процесе и подстицање учења; ✔ Научите лекције које спречавају понављање, а не окривљавање
- Ц) Никада немојте пријавити инцидент и побрините се да буде заборављен
- Д) Писање само техничких детаља и без додавања активних ствари
Објашњење: Беспрекорна обдукција се фокусира на питање 'који систем и процес су дозволили ову грешку', а не 'ко је то урадио'. Људи отворено деле грешку ако знају да неће бити кажњени; Скривена грешка се понавља. Извештај није извештај оптужбе, већ документ учења пун ставки усмерених на акцију.
12. У оптимизацији трошкова у облаку (ФинОпс), који је најлогичнији корак да се предузме пре него што пређете на обавезне попусте (План резервисаних/штедних средстава)?
- А) Прво узмите најдужу могућу обавезу, а касније размислите о отпаду
- Б) Прво очистите отпад (затварање у празном ходу, право димензионисање), а затим се посветите посвећеној употреби ✔
- Ц) Одмах преместите све ресурсе у Спот капацитет
- Г) Брисање најскупље ставке без прегледа података на фактури
Објашњење: Отпад се прво мора очистити (затварање неактивних ресурса, смањење превеликих ресурса). У супротном, закључаћете изгубљену употребу по сниженој цени на 1-3 године. Права величина и чишћење у празном ходу не захтевају никакву посвећеност и готово су без ризика.
13. Која је најважнија мера безбедности ако скрипта коју предлаже вештачка интелигенција има линију 'рм -рф "$ДИР"/'?
- А) Покретање скрипте директно у прод без читања ће се убрзати
- Б) Додајте сет -еуо пипефаил и празну променљиву контролу и покушајте прво са сувим радом ✔
- Ц) Довољно је скратити име променљиве
- Д) Коришћење рм -рф --форце уместо рм решава проблем
Објашњење: Ако је $ДИР празан, овај израз може покушати да избрише основни директоријум. Заустављање на недефинисаној променљивој са 'сет -у' и провера да променљива није празна пре него што је обришете (нпр. [ -н "$ДИР" ] || излаз 1) избегава катастрофу. Поред тога, деструктивне операције треба прво испробати са радом на суво.
14. Шта прво треба учинити ако кључ за приступ облаку случајно процури у јавно спремиште?
- А) Одмах поништите и обновите (ротирајте) кључ; Само брисање није довољно ✔
- Б) Само избришите датотеку из складишта и кључ је сигуран
- Ц) Не радећи ништа јер то нико није видео
- Д) Омогућавање приватног складиштења елиминише потребу за ротирањем кључа
Објашњење: Тајна која је процурила мора се одмах поништити и ротирати. Само брисање датотеке није довољно јер тајна остаје у Гит историји и јавна спремишта скенирају ботови у року од неколико секунди. Након отказивања/враћања, утицај се процењује и додаје се тајни скенер како би се спречило понављање.
15. Који од следећих приступа минимизира ризик при издавању нове верзије Прода?
- А) Давање нове верзије свим корисницима у исто време (биг-банг) и не припремање плана за враћање
- Б) Узимајући у обзир да је имплементација завршена чим се појави „зелено“, без вршења додатне верификације
- Ц) Коришћење контролисане стратегије као што је канаринац/плаво-зелена/функција, готов план враћања и тест дима + метричко праћење након постављања ✔
- Г) Препустити тестирање критичних пословних путева у потпуности вештачкој интелигенцији и уопште их не одређивати.
Објашњење: Стратегије контролисаног ослобађања (почевши од малог процента са канаринцем, тренутног враћања са плаво-зеленом, одвајајући примену од издања са заставицом функције) ограничавају ризик. Поред тога, од суштинског је значаја јасан план враћања пре примене и праћење златног сигнала са тестирањем дима након примене; 'изгледати зелено' не значи да функционише.