Pag-verify ng Prod, Mga Diskarte sa Pagpapalabas at End-to-End AI Workflow

Mga nadagdag:

Pag-unawa sa mga diskarte sa pagpapalabas na nagbabawas ng panganib (asul-berde, canary, feature flag) at disiplina sa pag-verify ng produkto (health check, smoke test, golden signal monitoring)
Kakayahang ipatupad ang ugali ng paghahanda ng isang malinaw na plano ng rollback bago ang pag-deploy at pag-verify ng mga kritikal na landas ng negosyo pagkatapos ng pag-deploy
Kakayahang pagsamahin ang lahat ng bahaging natutunan sa buong module sa isang end-to-end na AI-supported workflow at ilapat ang prinsipyo ng 'AI produces, humans verify and vouch for' sa bawat hakbang

Ang buong module na ito ay dumaloy patungo sa isang punto: ang ligtas na paghahatid ng code at imprastraktura sa produksyon (ang live na kapaligiran na ginagamit ng mga tunay na customer). Ngayon ay nasa pinaka-kritikal at nakaka-stress na link sa chain: pagkuha ng pagbabago nang live at pag-verify na talagang gumagana ito doon. Ang isang pagkakamali dito ay hindi abstract — direkta itong tumama sa customer, kita, at reputasyon. Iyon ang dahilan kung bakit ang mga mature na koponan ay pumupunta sa produksyon hindi sa pamamagitan ng "pag-asa" ngunit may mga kontroladong diskarte sa pagpapalabas at sistematikong pag-verify.

Sa panghuling yunit na ito pinagsasama namin ang dalawang bagay: (1) mga paraan ng pagpapalabas na nagpapababa ng panganib (canary, blue-green, feature flag) at ang disiplina ng prod verification; (2) kung paano ang bawat piraso na natutunan namin sa buong module—CI/CD, IaC, container, pagsubaybay, insidente, gastos, script, seguridad—ay nagsasama-sama sa isang end-to-end na workflow na pinapagana ng AI. Ulitin natin ang unang quote sa huling pagkakataon: Ang AI ay bumubuo at nagpapabilis ng mga draft sa bawat hakbang; Ngunit ikaw ang pinindot ang "I'm taking this live" na buton at tinitiyak ang resulta.

Maglabas ng mga diskarte na nagpapababa ng panganib

Ang pagtulak ng pagbabago sa lahat ng user nang sabay ay ang pinakamapanganib na paraan. Mga mature na pamamaraan:

Blue-Green Deployment: Dalawang magkaparehong kapaligiran ang pinananatili — "asul" (live) at "berde" (bagong bersyon). Ang bagong bersyon ay inihanda at sinubukan sa berde, pagkatapos ay ang trapiko ay biglang inililipat sa berde. Kung may problema, babalik agad sa asul ang trapiko. Ang mabilis na rollback ay ang pinakamalaking bentahe nito.
Canary Deployment: Ang bagong bersyon ay unang inilabas sa isang maliit na porsyento ng mga user (hal. 5%); Kung maganda ang mga sukatan, unti-unting tumaas sa 100%. Nakakaapekto ang isang isyu sa isang maliit na bahagi ng user, hindi sa buong user.
Feature Flag: Ang bagong feature ay pumapasok sa code ngunit hinarangan ng isang flag; Binubuksan ito sa ilang partikular na user kapag hiniling. May pagkakaiba sa pagitan ng deployment at "release"; Kung may problema, naka-off ang flag nang hindi ibinabalik ang code.

Tip: Ang pinakamabilis na safety net ay ang pagkakaroon ng rollback na handa bago ang bawat deployment. "Kung may mali, paano ako makakabalik sa lumang bersyon sa loob ng 60 segundo?" Kung walang malinaw na sagot sa tanong, hindi ka handang gawin ang deployment na iyon.

Pag-verify ng prod: hindi matatapos ang trabaho kapag natapos na ang deployment

Dahil lang sa mukhang "berde" ang isang deployment ay hindi nangangahulugang ito ay gumagana. Systematic na pag-verify:

Mga pagsusuri sa kalusugan: Nakataas ba ang serbisyo, tumutugon ba ang /healthz?
Mga pagsubok sa usok: Gumagana ba talaga ang ilang pinakamahalagang path ng user (pag-login, pagbabayad, paghahanap)? Awtomatiko at mabilis.
Mag-ingat para sa mga ginintuang signal: Post-deploy na error rate, latency, normal ba ang trapiko? (Apat na signal sa unit 6.)
Unti-unting lumawak: Tumingin sa mga sukatan sa bawat hakbang habang tinataas mo ang porsyento ng Canary.
Window ng pagmamasid: Subaybayan nang mabuti para sa isang yugto ng panahon (hal. 30 min) pagkatapos ng deployment; Ang mga mapanlinlang na problema ay hindi agad nakikita.

Babala: Maaaring gumawa ang AI ng listahan ng mga smoke test o verification, ngunit trabaho mo na tukuyin kung aling mga user path ang "kritikal". Nagbibigay ang AI ng pangkalahatang listahan; Ikaw lang ang nakakaalam na ang iyong daloy ng pagbabayad, ang iyong pinakamaraming kita na landas, ay dapat na masuri.

Paghahambing ng mga diskarte sa paglabas

Diskarte

Pangunahing bentahe

Gastos/kumplikado

pinaka-angkop

Asul-Berde

Instant rollback

Dalawang kapaligiran = 2x na mapagkukunan

Kung ang mabilis na pagkuha ay kritikal

kanaryo

Nililimitahan ang epekto sa maliit na hiwa

Kinakailangan ang pamamahala ng trapiko

Malaking user base

FeatureFlag

Naghihiwalay sa pag-deploy mula sa paglabas

Utang sa pamamahala ng bandila

Unti-unti/naka-target na pagbubukas

Rolling update

Simple, mapagkukunan-friendly

mabagal na rollback

Mga simpleng serbisyo

End-to-end AI-powered workflow

Ngayon, pagsamahin natin ang buong module sa isang daloy. Sabihin nating nagpa-publish ka ng bagong microservice. Gumagawa ang AI ng mga draft sa bawat hakbang; i-verify mo sa bawat hakbang:

Code at container (Unit 4): Gumagawa ang AI ng na-optimize at secure na Dockerfile; I-verify mo ang walang sikreto at ang laki.
CI/CD (Unit 2): Isinulat ang AI test-build-deploy pipeline; Paliitin mo ang mga pahintulot at suriin ang mga lihim na sanggunian.
Infrastructure (Unit 3): Tinutukoy ang mga kinakailangang mapagkukunan gamit ang AI Terraform; Nabasa mo ang output ng plano at hindi naghahanap ng mga hindi inaasahang pagtanggal.
Orkestrasyon (Unit 5): Ang AI ay gumagawa ng mga Kubernetes manifest; i-verify mo ang resource limit, probe, at RBAC.
Seguridad (Unit 10): Inuuna ang mga output ng AI scan; Sunggaban mo muna ang mga mapagsamantalahan.
Pagsubaybay (Unit 6): Bumubuo ang AI ng mga panuntunan sa alarma at dashboard; Sinusubukan mo ang mga limitasyon gamit ang iyong nakaraang data.
Paglabas at pagpapatunay (ang unit na ito): Binabalangkas ang AI smoke test at rollback plan; simulan mo ang canary, panoorin ang mga sukatan, pindutin ang pindutan.
Kung nangyari ang insidente (Unit 7): Ang AI ay bumubuo ng hypothesis at postmortem sketch; I-verify at matutunan mo ang mga aralin.
Gastos (Yunit 8): Sinusubaybayan ng AI ang pag-aaksaya ng mga bagong mapagkukunan; Gumawa ka ng mga desisyon sa tamang sukat.

Sa bawat hakbang, nananatiling pare-pareho ang karaniwang tuntunin: gumagawa at bumibilis ang AI, nagve-verify at nagtitiyak ang tao. Ito ang kakanyahan ng modyul.

tatlong mini case

Kaso 1 — kinulong ng kanaryo ang isang sakuna sa 5%. Isang team ang nagbigay ng bagong bersyon sa 5% na mga user na may canary. Ang dashboard na ginawa ng AI ay agad na nagpakita na ang rate ng error ay tumalon sa 8% sa slice na ito. Binawi ito ng koponan nang hindi ito dinaragdagan sa 100%; Naapektuhan lang ng isyu ang 5% ng mga user, at iyon ay sa loob ng ilang minuto. Kung magkakaroon ng big-bang deployment, maaapektuhan ang lahat ng customer.

Case 2 — nahuli ng smoke test ang nawawalang landas. Nag-alok ang AI ng smoke test set, ngunit wala itong "payment" flow. Idinagdag ito ng inhinyero, alam na ang pinakamahalagang daloy ng kita ay ang pagbabayad. Nasira ang post-deploy test sa mismong hakbang ng pag-checkout — nag-expire na ang isang third-party na key. Ang pag-verify ay nakakuha ng tahimik na pagkawala ng kita sa loob ng ilang minuto.

Case 3 — ready rollback na na-save sa loob ng 90 segundo. Ang isang koponan na nag-install ng asul-berde ay kinuha ang bagong bersyon sa berde; Pagkatapos ng 2 minuto, doble ang pagkaantala. Ginawa nilang asul ang trapiko sa loob ng 90 segundo gamit ang rollback na inihanda nila nang maaga. Natagpuan nila ang ugat na sanhi (isang mabagal na query sa bagong bersyon) na hindi nasa ilalim ng presyon, pagkatapos ay mahinahon. Dahil sa handa na rollback path, halos hindi makita ang pagkaantala.

Apat na maaaring kopyahin na mga template

1) Pagpili ng diskarte sa paglabas:

Isusulong ko ang sumusunod na serbisyo: [SERVICE/CONTEXT: number of users, outage tolerance, infrastructure]. Alin ang inirerekomenda mo sa pagitan ng asul-berde, canary at mga feature na flag? Ihambing ang mga pakinabang, gastos at bilis ng pagbabalik ng bawat isa sa kontekstong ito. Magbigay ng mungkahi, ngunit sabihin na gagawin ko ang pangwakas na desisyon.

2) Listahan ng pagsubok sa usok / pag-verify:

Gumawa ng draft na smoke test at listahan ng pag-verify para sa [SERBISYO] na aking tatakbo pagkatapos ng deployment: pagsusuri sa kalusugan, ang pinakamahalagang landas ng user, aling mga sukatan ang dapat kong subaybayan sa loob ng ilang minuto? Ipagpalagay na mamarkahan ko ang pinakamahalagang mga landas ng negosyo at iwanang blangko ang field na iyon.

3) Plano ng rollback:

Gumagamit ako ng [DEPLOY METHOD]. Sumulat sa akin ng isang malinaw na plano ng rollback: sa aling utos/hakbang ako ibabalik sa lumang bersyon, gaano katagal ito, ano ang mga panganib ng rollback mismo (hal. database migration ay hindi maaaring i-rollback), ano ang dapat kong suriin bago mag-rollback?

4) End-to-end na checklist ng release:

Gumawa ng end-to-end na checklist ng paghahanda para sa paglabas sa isang bagong [SERVICE] na proyekto: code/image security, pipeline, infrastructure plan, monitoring at alarming, security scanning, release strategy, rollback at verification. Suriin ang bawat item na may tanong na "Handa na ba ako?" Gawing tanong.

Mahinang prompt / Malakas na prompt

Mahina: "Paano ko ito mapapasali sa prod?"

Resulta: walang konteksto; Inililista ng AI ang mga pangkalahatang hakbang sa pag-deploy, hindi nito tinutugunan ang iyong pagpapaubaya sa panganib, sukat ng user at pangangailangan ng rollback.

Güçlü: "Magpo-prod ako ng serbisyo sa pagbabayad na may 10 milyong user, napakababa ng aking tolerance para sa downtime. Inirerekomenda mo ba ang Canary o Blue-Green, bakit? Aling mga kritikal na landas ang dapat kong subukan pagkatapos ng pag-deploy, aling mga sukatan ang dapat kong subaybayan kung ilang minuto, at ano dapat ang 60 segundong rollback na plano? Ako ang gagawa ng panghuling desisyon."

Pagkakaiba: ang pangalawang prompt ay nagbibigay ng sukat, pagpapaubaya at inaasahan ng rollback; Nangangailangan ito ng diskarte + pag-verify + pag-undo at ipinauubaya sa tao ang desisyon.

Mga karaniwang pagkakamali

Nagde-deploy nang walang rollback na plano. Kung walang paraan pabalik, ang bawat pag-deploy ay isang sugal.
Big-bang deployment. Ang pagbibigay nito sa buong user nang sabay-sabay ay nagpapalaki sa panganib.
Ipagpalagay na "berde = gumagana". Ang serbisyong nakapasa sa pagsusuri sa kalusugan ay maaaring masira sa kritikal na landas.
Iniisip na aalis ka sa mga kritikal na landas ng negosyo patungo sa AI. Dapat mong markahan ang mga paraan tulad ng pagbabayad.
Hindi sinusubaybayan pagkatapos ng pag-deploy. Ang mga mapanlinlang na problema ay hindi lilitaw sa unang minuto; kinakailangan ang window ng pagmamasid.
Ang pag-iisip na ang paglipat ng database ay mababaligtad. Ang ilang mga pagbabago ay hindi nagbabalik; ay binalak nang hiwalay.

Sa buod

Ang pagpunta sa prod ay ang pinaka-kritikal na link sa chain at ginagawa hindi sa pamamagitan ng "pag-asa" ngunit sa pamamagitan ng mga kinokontrol na diskarte: ang asul-berde ay nagbibigay ng agarang rollback, nililimitahan ang canary effect sa isang maliit na slice, na naghihiwalay sa feature flag deployment mula sa release. Ang trabaho ay hindi tapos kapag ang deployment ay tapos na; Ang sistematikong pag-verify sa pamamagitan ng mga pagsusuri sa kalusugan, mga pagsusuri sa usok at pagsubaybay sa ginintuang signal ay mahalaga. Bumubuo at nagpapabilis ang AI ng mga draft sa bawat hakbang sa buong module — mula Dockerfile hanggang pipeline, mula Terraform hanggang alarm rule, mula postmortem hanggang cost analysis. Ngunit nananatili ang karampatang tao na nagbe-verify sa bawat hakbang, pinipindot ang go live na button at tinitiyak ang resulta. Ito ang ginintuang panuntunan ng end-to-end na AI-powered DevOps.

Gawain ng aplikasyon

Pumili ng serbisyo (totoo o kathang-isip) kung saan i-publish. (1) Pumili ng diskarte na akma sa iyong konteksto sa template na "Pagpili ng diskarte sa paglabas" at isulat kung bakit. (2) Gumawa ng listahan ng pag-verify gamit ang template na "Smoke test / verification list" at ikaw mismo ang magdagdag ng pinakamahalagang mga landas ng negosyo. (3) Maghanda ng 60-segundong rollback plan na may template na "Rollback plan" at tingnan kung mayroong anumang hindi maibabalik na mga hakbang dito.

checklist

[ ] Pumili ako ng diskarte sa pagpapalabas (canary/blue-green/flag) na nababagay sa aking konteksto.
[ ] Mayroon akong malinaw at mabilis na rollback na plano na handa bago i-deploy.
[ ] Idinagdag ko ang pinakamahalagang landas ng negosyo (hal. pagbabayad) sa aking mga pagsusulit sa Smoke.
[ ] Pagkatapos ng pag-deploy, sinusubaybayan ko ang mga gintong signal sa pamamagitan ng isang window ng pagmamasid.
[ ] Nagplano din ako ng mga hindi maibabalik na hakbang (database migration, atbp.).
[ ] Na-verify ko ang AI blueprint sa bawat hakbang; Nagdesisyon akong mag-live.

Pagsusulit sa Module

1. Alin sa mga sumusunod ang pinakamahusay na pagpoposisyon para sa DevOps at AI sa cloud?

A) Ang artificial intelligence ay isang katulong at tool sa suporta sa desisyon; Responsable ang mga tao para sa mga kritikal na desisyon na nakakaapekto sa produkto ✔
B) Maaaring tapusin ng artificial intelligence ang mga prod deployment at lihim na pag-ikot nang walang pag-apruba ng tao
C) Ang artificial intelligence ay kapaki-pakinabang lamang para sa pagsulat ng dokumentasyon, wala itong kinalaman sa imprastraktura
D) Ang pag-audit ay hindi kailangan dahil ang artificial intelligence ay palaging gumagawa ng mas maaasahang mga utos kaysa sa inhinyero

Paglalarawan: Ito ay isang katulong at tool na sumusuporta sa desisyon na nagpapabilis sa mga gawaing masinsinan sa text gaya ng pipeline ng artificial intelligence, configuration, script at log. Ang responsibilidad para sa mga desisyon na nakakaapekto sa downtime, pera at seguridad, tulad ng pagpapalabas ng produksyon, lihim na pamamahala at panghuling aplikasyon, ay nananatili sa karampatang inhinyero.

2. Alin ang pinakatumpak na expression para sa disiplina sa pag-verify bago ipatupad ang isang DevOps command o configuration na ginawa ng artificial intelligence?

A) Kung ang output ay mukhang makinis at may kumpiyansa na maaari itong patakbuhin nang direkta sa prod
B) Ang output ay ligtas lamang kung walang mga error sa syntax, walang karagdagang pagsusuri ang kinakailangan
C) Ikonekta ang output sa source, plan/dry-run, at i-filter ito sa konteksto ng iyong system; pagkatapos ay mag-apply ✔
D) Ang paggawa ng unang pagsubok nang direkta sa prod at ang panonood ng resulta ay ang pinakamabilis na pag-verify

Paliwanag: Mahalaga ang tatlong-hakbang na pag-verify: pagkonekta sa output sa pinagmulan (ang command/flag ba talaga sa mga opisyal na doc), pagpapatuyo nito (nakikita kung ano ang mangyayari sa plano/--dry-run), at pagpasa nito sa filter ng system (angkop ba ito sa konteksto ng arkitektura at seguridad nito). Ang katatasan ay hindi nangangahulugan ng katumpakan.

3. Ano ang tamang diskarte kapag nagtatanong ng artificial intelligence tungkol sa isang error o isyu sa deployment sa isang .env file na naglalaman ng totoong password ng database?

A) I-mask ang mga totoong lihim gamit ang <PLACEHOLDER>; ibahagi lamang ang masked error at konteksto ✔
B) Ang pag-paste ng buong .env file bilang ay mas mabilis na malulutas ang problema
C) Dahil ang mga lihim ay base64 na, ligtas na idikit ang plain
D) Ligtas ang pag-paste ng password dahil hindi ito iniimbak ng artificial intelligence

Paglalarawan: Walang totoong mga lihim ang na-paste sa AI prompt. Ang mga halaga tulad ng mga password at token ay naka-mask sa <PLACEHOLDER>; tanging ang mensahe ng error at kinakailangang konteksto ang ibinabahagi. Kung ang Lihim ay na-leak na, dapat itong kanselahin at iikot kaagad.

4. Alin sa mga sumusunod ang tamang pamamahala ng mga lihim (password, token) sa isang pipeline ng CI/CD?

A) Ito ay itinatago sa lihim na imbakan ng platform at tinatawag sa pamamagitan ng sanggunian (hal. ${{ secrets.X }}), hindi nakasulat sa plain text ✔
B) Nakasulat sa plaintext sa pipeline na YAML para sa kaginhawahan
C) Ito ay napatunayan sa pamamagitan ng pagpindot sa echo at log sa simula ng bawat trabaho.
D) Kung tinukoy nang may pinakamalawak na pahintulot (isulat-lahat), tataas ang seguridad

Paliwanag: Ang mga lihim ay hindi isinusulat sa YAML sa simpleng teksto; Ito ay itinatago sa lihim na imbakan ng platform at tinatawag na may mga sanggunian tulad ng ${{ secrets.X }}. Bukod pa rito, sa prinsipyo ng hindi bababa sa awtoridad, ang mga pahintulot ng token ay pinaliit at ang lihim na log ay hindi naitala.

5. Sa pamamahala ng imprastraktura sa Terraform, ano ang pinakamahalagang hakbang na dapat gawin bago ipatupad ang isang pagbabago nang live?

A) Direktang tumatakbo ang 'terraform apply'; ang plano ay isang pag-aaksaya ng oras
B) Pag-back up ng State file sa isang pampublikong repositoryo
C) Patakbuhin ang 'terraform plan' at suriin ang sira/palitan ang mga linya sa output, pagkatapos ay ilapat ✔
D) I-uninstall ang bersyon ng Provider at tiyaking awtomatikong darating ang pinakabagong bersyon

Paliwanag: Ang 'terraform plan' ay dapat patakbuhin bago 'terraform apply'. Ipinapakita ng plano kung ano ang idaragdag, kung ano ang babaguhin, at lalo na kung ano ang tatanggalin (sirain), nang walang ginagawa. Kung may nakitang hindi inaasahang pagsira o pagpapalit ng linya, hindi dapat ilapat ang paglalapat.

6. Ano ang ibig sabihin nito at ano ang dapat gawin kung ang linyang '-/+ replace' para sa database ng produksyon ay lilitaw sa isang output ng Terraform plan?

A) Maa-update lang ang source on-site, walang panganib
B) Ang mapagkukunan ay tatanggalin at muling gagawin; May panganib ng pagkawala ng data, dapat itigil ang pag-apply kung hindi inaasahan ✔
C) Pagdaragdag ng isang bagong mapagkukunan, ang umiiral na database ay hindi apektado
D) Ito ay isang babala lamang, maaaring ligtas na hindi papansinin

Paliwanag: '-/+ palitan' ay nangangahulugan na ang mapagkukunan ay tatanggalin at muling gagawin; Para sa isang database, nangangahulugan ito ng pagkawala ng data. Kung hindi inaasahan, ang pag-apply ay dapat ihinto, ang pagbabago ay dapat i-convert sa isang ligtas na paraan, o ang hindi nababagong field ay dapat iwanang hindi nagalaw.

7. Alin sa mga sumusunod ang totoo para sa isang Dockerfile na maging handa sa produksyon sa mga tuntunin ng seguridad at laki nito?

A) Para sa kaginhawahan, i-embed ang sikreto sa larawan gamit ang ENV at patakbuhin ito bilang ugat
B) Palaging gamitin ang tag na ':latest' at panatilihing kasing laki ang batayang larawan hangga't maaari
C) Single-stage build at iniiwan ang lahat ng build tool sa huling larawan
D) Hindi pag-embed ng Secret, pakikipagtulungan sa hindi awtorisadong USER, gamit ang maliit at matatag na base image at multi-stage build ✔

Paglalarawan: Isang production-ready na imahe: hindi nag-e-embed ng sikreto (i-inject ito sa runtime), tumatakbo gamit ang isang hindi awtorisadong USER sa halip na root, gumagamit ng maliit at may bersyon na base na imahe (slim/alpine, hindi :latest), at pinaliit ng isang multi-stage na build. Sinusuri din ito para sa mga kahinaan bago ilathala.

8. Ano ang pinakamahalagang panganib ng hindi pagtukoy sa mga limitasyon ng mapagkukunan para sa isang Deployment sa Kubernetes?

A) Ang Pod ay hindi magsisimula dahil ang limitasyon ay isang kinakailangang field
B) Isang babala lamang ang lalabas sa monitoring board, hindi apektado ang operasyon
C) Awtomatikong ipinapatupad ng Kubernetes ang mga ligtas na default na limitasyon, walang panganib
D) Ang pod ay maaaring lumago nang walang limitasyon at ubusin ang mga mapagkukunan ng node, kaya bumagsak ang mga kalapit na serbisyo ✔

Paliwanag: Ang isang Pod na walang limitasyon sa mapagkukunan ay maaaring lumago nang walang limitasyon, ubusin ang lahat ng mga mapagkukunan ng node kung saan ito tumatakbo, at mag-crash ng mga kalapit na serbisyo, halimbawa, nang may memory leak. Kaya naman ang pagtukoy sa mga kahilingan/limitasyon ang batayan ng katatagan.

9. Paano maiiwasan ang 'pagkapagod sa alerto' sa pagsubaybay at pag-setup ng alarma?

A) Magtakda ng mga alarma sa pinakamaraming sukatan hangga't maaari at bumuo ng mga alerto sa bawat pagbabagu-bago.
B) Itakda ang lahat ng alarma sa pinakamataas na antas ng kalubhaan
C) Pagti-trigger ng mga alarma na may mga agarang halaga nang hindi nagtatakda ng oras (para sa)
D) Panatilihin ang mga alarma na nakatuon sa pagkilos at nasa tamang apurahan, pagsubok ng mga limitasyon gamit ang makasaysayang data, pagsasama-sama ng mga hindi kailangan ✔

Paglalarawan: Ang bawat alarma ay dapat na naaaksyunan at nasa tamang pangangailangan; Ang impormasyon na hindi nangangailangan ng aksyon ay ipinapakita sa board, hindi ito gumising sa sinuman. Sinusubukan ang mga limitasyon ng alarma laban sa makasaysayang data ng system at pinagsama-sama ang mga hindi kailangan/paulit-ulit na alarma. Sa ganitong paraan ang tunay na alarma ay hindi mawawala sa ingay.

10. Ano ang pinakamahusay na priority order sa panahon ng isang insidente ng produksyon?

A) Hanapin muna ang eksaktong ugat na sanhi at bawasan lamang ito kapag malinaw na ang dahilan.
B) Isulat muna ang postmortem report, pagkatapos ay pindutin ang serbisyo
C) Bawasan muna (restore/restore service), iiwan ang root cause analysis para mamaya ✔
D) Hanapin muna ang taong responsable sa insidente at iulat ito

Paliwanag: Ang golden rule ay 'bawasan muna, imbestigahan mamaya'. Ang layunin ay ibalik muna ang serbisyo o i-roll ito pabalik sa isang kilalang-magandang bersyon (magaan); Ang root cause analysis ay ginagawa nang mahinahon pagkatapos bumaba ang pressure. Ang paghihintay upang mahanap ang eksaktong ugat na sanhi ay nagpapataas ng oras ng pagbawi (MTTR).

11. Ano ang pangunahing layunin ng walang kapintasang postmortem na kultura?

A) Pagkilala sa taong nagkamali at paglalagay ng responsibilidad sa kanya
B) Pagtuon sa mga sistema at proseso at paghikayat sa pag-aaral; ✔ Pag-aaral ng mga aralin na pumipigil sa pag-uulit sa halip na paninisi
C) Huwag kailanman iulat ang insidente at tiyaking ito ay nakalimutan
D) Sumulat lamang ng mga teknikal na detalye at hindi nagdaragdag ng mga bagay na naaaksyunan

Paliwanag: Ang walang kapintasang postmortem ay nakatuon sa tanong na 'aling sistema at proseso ang nagpapahintulot sa pagkakamaling ito', hindi 'sino ang gumawa nito'. Ibinabahagi ng mga tao ang pagkakamali nang hayagan kung alam nilang hindi sila mapaparusahan; Nauulit ang nakatagong error. Ang ulat ay hindi isang ulat ng akusasyon, ngunit isang dokumento sa pag-aaral na puno ng mga bagay na nakatuon sa pagkilos.

12. Sa cloud cost optimization (FinOps), ano ang pinakalohikal na hakbang na dapat gawin bago lumipat sa mga nakatuong diskwento (Reserved/Savings Plan)?

A) Kunin muna ang pinakamahabang posibleng pangako, isipin ang pag-aaksaya sa ibang pagkakataon
B) Una, linisin ang basura (idle closure, right-sizing), pagkatapos ay italaga sa nakatuong paggamit ✔
C) Ilipat kaagad ang lahat ng mapagkukunan sa Spot capacity
D) Pagtanggal ng pinakamahal na item nang hindi sinusuri ang data ng invoice

Paliwanag: Dapat linisin muna ang basura (pagsasara ng mga walang ginagawang mapagkukunan, pagbabawas ng malalaking mapagkukunan). Kung hindi, i-lock mo ang nasayang na paggamit sa may diskwentong presyo sa loob ng 1-3 taon. Ang tamang sukat at idle na paglilinis ay hindi nangangailangan ng pangako at malapit sa panganib.

13. Ano ang pinakamahalagang hakbang sa seguridad kung ang isang script na iminungkahi ng AI ay may linyang 'rm -rf "$DIR"/'?

A) Ang pagpapatakbo ng script nang direkta sa prod nang hindi ito binabasa ay bibilis
B) Magdagdag ng set -euo pipefail at walang laman na variable control at subukan muna gamit ang dry-run ✔
C) Ang paikliin ang variable na pangalan ay sapat na
D) Ang paggamit ng rm -rf --force sa halip na rm ay malulutas ang problema

Paliwanag: Kung walang laman ang $DIR, maaaring subukan ng pahayag na ito na tanggalin ang root directory. Ang paghinto sa hindi natukoy na variable na may 'set -u' at pagsuri na ang variable ay walang laman bago ito tanggalin (hal. [ -n "$DIR" ] || exit 1) ay maiiwasan ang sakuna. Bukod pa rito, ang mga mapanirang operasyon ay dapat subukan muna sa dry-run.

14. Ano ang unang bagay na dapat gawin kung ang isang cloud access key ay hindi sinasadyang tumagas sa isang pampublikong imbakan?

A) Kaagad na kanselahin at i-renew (iikot) ang susi; Hindi sapat ang pagtanggal ng mag-isa ✔
B) Tanggalin lamang ang file mula sa imbakan at ligtas ang susi
C) Walang ginagawa dahil walang nakakita
D) Ang paggawa ng imbakan na pribado ay nag-aalis ng pangangailangan na paikutin ang susi

Paliwanag: Kailangang kanselahin at paikutin kaagad ang na-leak na sikreto. Ang pagtanggal lang ng file ay hindi sapat dahil ang lihim ay nananatili sa kasaysayan ng Git at ang mga pampublikong repositoryo ay ini-scan ng mga bot sa loob ng ilang segundo. Pagkatapos ng pagkansela/pagbabalik, susuriin ang epekto at idinagdag ang isang lihim na scanner upang maiwasan ang pag-ulit.

15. Alin sa mga sumusunod na diskarte ang nagpapaliit ng panganib kapag naglalabas ng bagong bersyon ng Prod?

A) Pagbibigay ng bagong bersyon sa lahat ng user nang sabay-sabay (big-bang) at hindi naghahanda ng rollback plan
B) Isinasaalang-alang na ang deployment ay tapos na sa sandaling lumitaw itong 'berde', hindi nagsasagawa ng karagdagang pag-verify
C) Paggamit ng kinokontrol na diskarte gaya ng canary/blue-green/feature flag, ready-made rollback plan at smoke test + metric monitoring pagkatapos ng deployment ✔
D) Ang ganap na pag-iwan sa pagsubok ng mga kritikal na landas ng negosyo sa artificial intelligence at hindi pagtukoy sa mga ito.

Paliwanag: Mga kinokontrol na diskarte sa pagpapalabas (nagsisimula sa maliit na porsyento na may canary, agarang rollback na may asul-berde, na naghihiwalay sa deployment mula sa release na may feature na flag) na limitahan ang panganib. Bilang karagdagan, ang isang malinaw na plano ng rollback bago ang pag-deploy at ang pagsubaybay sa ginintuang signal na may pagsubok sa usok pagkatapos ng pag-deploy ay mahalaga; 'Mukhang berde' ay hindi nangangahulugan na ito ay gumagana.