Ieguvumi:
- Spēja atšķirt, kur DevOps ķēdē (konveijers, konfigurācija, skripts, žurnāls) mākslīgais intelekts ietaupa reālo laiku un kur ražošanu ietekmējošie lēmumi tiek atstāti cilvēku ziņā atkarībā no uzdevuma riska līmeņa.
- Spēja piemērot disciplīnu, kas pārbauda katru AI izvadi, savienojot to ar avotu, palaižot to sausā stāvoklī un izlaižot to caur sistēmas filtru.
- Spēja iegūt ieradumu nekad neielīmēt noslēpumus pieprasījumos, tos maskēt un strādāt aizsardzības nolūkos tikai autorizētās sistēmās.
Kādu nakti pulksten 3:14 jūsu tālrunis zvana: maksājumu pakalpojums nedarbojas, nauda un reputācija tiek zaudēta katru minūti. Citu dienu viena nepareiza komanda pārstartē tūkstošiem serveru. Šī ir DevOps profesionāļa pasaule — atbildība par visiem cauruļvadiem, automatizāciju un dežūrām, ko programmatūra iziet no kodu krātuves (kur tiek glabāts programmatūras avots), līdz tā nonāk klienta rokās. DevOps ir vārdu "izstrāde" un "operācijas" kombinācija: tā ir kultūra un prakšu kopums, kas apvieno programmatūras izstrādi un darbību vienā ātrā, uzticamā plūsmā. Katrs šīs plūsmas solis rada komandu, konfigurācijas failu, skriptu. Mākslīgais intelekts (AI — programmatūra, kas iegūst modeļus no vēsturiskajiem datiem un veido tekstu, kodu un prognozes) ietaupa daudz laika šajā teksta pārpilnībā.
Bet pats šī moduļa sākums ir skaidrs: AI ir palīgs, melnrakstu ģenerators un lēmumu atbalsta rīks; Jūs esat atbildīgs par to, kas nonāk dzīvajā vidē (ražošana, reālu klientu izmantotā sistēma), kad un kuru pogu nospiest nakts vidū. Programmā DevOps kļūdas izmaksas nav minūtes, bet gan dīkstāve, datu zudums un drošības pārkāpums. Tāpēc šajā pirmajā nodaļā mēs koncentrēsimies uz disciplīnu, nevis instrumentu.
Kur DevOps ķēdē AI noder?
Sadalīsim DevOps darbus divās lielās kopās. Pirmā kopa: atkārtoti, teksta un strukturēšanas darbi. CI/CD (Continuous Integration / Continuous Delivery — konveijera, kas automātiski pārbauda un izlaiž kodu) apraksta rakstīšana, Dockerfile (receptes faila, kas iesaiņo lietojumprogrammu konteinerā) uzmetums, kompleksa Terraform (rīks, kas definē infrastruktūru kā kodu) bloka izskaidrošana, žurnālu steku apkopošana (notikumu ierakstu skriptu veidošana, ko rada sistēmas) un karodziņu. Veicot šos uzdevumus, mākslīgais intelekts samazina minūtes līdz sekundēm un nenogurst.
Otrā grupa: lēmumi, kas rada traucējumus, naudu vai drošību. Vai laidiens nonāks prod, kurš pakalpojums tiks restartēts nakts vidū, kā saglabāt noslēpumu, kurš resurss tiks slēgts izmaksu samazinājuma dēļ. Šie lēmumi prasa kontekstu, sistēmas zināšanas un atbildību. Šeit AI padara iespējas un riskus redzamus, taču jūs nospiežat pogu “Lietot”.
Noskaidrosim atšķirību vienā teikumā: AI ir spēcīgs uz jautājumiem "ko šī konfigurācija dara un kā to uzrakstīt"; Lēmums ir jūsu ziņā, ja runa ir par tādiem jautājumiem kā "Vai man tas ir jāpiemēro produktam un kas par to galvos?"
Padoms. Pirms darba ārpakalpojuma AI pajautājiet: "Ko es zaudēšu, ja šī izvade ir nepareiza?" Ja atbilde ir "dažas minūtes", nekautrējieties deleģēt. Ja atbilde ir "ražošanas pārtraukums, datu zudums vai noplūde", ļaujiet AI sagatavot melnrakstu, un jūs pārbaudāt lēmumu un īstenošanu.
Soli pa solim: kā darbojas ar AI darbināms DevOps bizness?
- Apkopojiet kontekstu. Kurš mākonis (AWS, Azure, GCP), kura rīka versija, kādi ierobežojumi? Ja AI sniedzat nepilnīgu kontekstu, jūs iegūsit nepilnīgu un bīstamu rezultātu.
- Definējiet skaidrus uzdevumus. Nevis "rakstīt cauruļvadu"; Sakiet: "Izmantojot GitHub Actions, rakstiet darbplūsmu galvenajā filiālē, kas darbojas ar push, veic testus, veido Docker attēlu, bet neizvieto to."
- Izveidojiet melnrakstu. Ļaujiet AI uzrakstīt pirmo versiju.
- Pārbaudīt. Pārbaudiet sintaksi, pārbaudiet, vai nav noplūdusi konfidenciāla informācija, pārbaudiet ar sauso darbību (režīms, kas faktiski parāda lietojumprogrammai, kas jādara).
- Izmēģiniet to smilškastē. Nekad nemēģiniet pirmo reizi prod; palaist testēšanas/iestudēšanas vidē.
- Uzklājiet pakāpeniski un uzraugiet. Iegūstiet to tiešsaistē, pārraugot metriku un žurnālus.
Pārbaudes disciplīna: trīs soļi
AI runā tekoši un pārliecinoši; Tas nenozīmē, ka tā ir patiesība. AI laiku pa laikam rada halucinācijas — veido neesošu komandas karogu, mākoņpakalpojuma nosaukumu vai konfigurācijas atslēgu kā reālu. Programmā DevOps viltus force karodziņš var dzēst datus, savukārt viltus IAM (identitātes un piekļuves pārvaldības) atļauja rada drošības ievainojamību. Reflekss:
- Pievienojiet to avotam. Vai katra AI dotā komanda un karogs patiešām ir oficiālajā dokumentācijā? Jautājiet "Pastāstiet man, kurā versijā šis karogs ir pieejams un tā nosaukums oficiālajā dokumentā"; Ja neesat pārliecināts, neticiet tam.
- Palaidiet sausu. Skatiet, kas notiek, to faktiski neizmantojot, izmantojot modifikācijas, piemēram, terraform plan, kubectl --dry-run, --check.
- Izlaidiet to caur sistēmas filtru. Vai izvade atbilst jūsu arhitektūrai, drošības politikai un pieejamo resursu nosaukumiem? Jūsu domēna zināšanas ir pēdējais filtrs.
Uzmanību: "AI rakstīja tā" nav attaisnojums. Prod pārtraukuma gadījumā atbildība nav AI, bet gan personai, kura izpilda šo komandu, to nepārbaudot. Nepārbaudīta AI komanda ir tikpat riskanta kā rm -rf, kas tiek izpildīta bez nolasīšanas.
Drošība un noslēpumi: nekad nenoplūst
Vissvarīgākais DevOps privātuma noteikums attiecas uz noslēpumiem. Noslēpums; Tā ir konfidenciāla informācija, piemēram, parole, API atslēga, datu bāzes savienojuma virkne, privātais sertifikāts, kas var atvērt visu jūsu sistēmu, ja tā tiek apdraudēta. Neielīmējiet AI uzvednē īstus noslēpumus. Ja koda blokā ir ietverta faktiskā AWS piekļuves atslēga, .env faila saturs vai ražošanas datu bāzes parole, maskējiet tos ar vietturiem, piemēram, <AWS_ACCESS_KEY>, nevis AKIA..., pirms nododat tos AI.
Pārbaudiet arī kodu, ko rada AI: AI dažkārt rada piemērus, kas ērtībai iekodē noslēpumu tieši kodā. Šī ir drošības ievainojamība. Faktiski noslēpumi tiek glabāti slepenajā glabātuvē (Vault, AWS Secrets Manager, Azure Key Vault) un izpildes laikā tiek ievadīti kā vides mainīgie.
Vēl viens ētisks un juridisks ierobežojums šajā jomā: izmantošana aizsardzībai. Izmantojiet AI, lai nostiprinātu savas sistēmas, skenētu ievainojamības un no žurnāliem iegūtu uzbrukumu pēdas. Neatļauta piekļuve citas personas sistēmai, neatļauta skenēšana vai uzbrukuma rīka izveide ir nelikumīga un ārpus šīs platformas darbības jomas. Vienmēr strādājiet sistēmās, par kurām jums ir tiesības un kuras esat saņēmis rakstisku atļauju ar līguma palīdzību.
Kādi dati tiek ievadīti kādā transportlīdzeklī?
Datu tips
piemērs
piemērots transportlīdzeklis
atvērtie dati
Oficiālais dokuments, atvērtā pirmkoda kods
Katrs transportlīdzeklis
Iekšējie dati (nav noslēpums)
Vispārējās arhitektūras diagramma, vispārējs cauruļvads
Iestādes apstiprināts transportlīdzeklis
konfidenciāls/sensitīvs
Noslēpums, prod IP/topoloģija, klientu dati
Tikai institūcijas nolīgts transportlīdzeklis, kura dati nenonāk apmācībās; maskējot
trīs mini futrāļi
1. gadījums — laiks tika iegūts īstajā vietā. DevOps inženieris pavadīja 6 stundas, pārvietojot veco 300 līniju Jenkins cauruļvadu uz GitHub Actions. Viņš samazināja darbu līdz 90 minūtēm, liekot AI soli pa solim izskaidrot un sagatavot melnrakstu. Ietaupīto laiku viņš pavadīja, pārbaudot katru AI veikto posmu pa vienam. AI veica mehānisko tulkojumu; Validācija palika cilvēka ziņā.
2. gadījums — pārbaude novērš katastrofu. Komanda lūdza AI Terraform tīrīšanas skriptu. AI deva brīvu kodu; Bet, kad inženieris izpildīja terraformas plānu, viņš atklāja, ka skripts plāno arī dzēst izmantoto ražošanas datu bāzi — AI bija nepareizi ierakstījis resursu filtru. Sausā darbība neļāva stundām ilgi zaudēt datus.
3. gadījums — atgriešanās no slepenās noplūdes. Uzdodot jautājumu “kāpēc šī izvietošanas kļūda”, praktikants ielīmēja visu .env failu publiskā rīkā ar faktisko ražošanas datu bāzes paroli. Vecākais inženieris nekavējoties pagrieza un atjaunoja atslēgas. Pareizais veids bija maskēt paroli ar <DB_PASSWORD> un kopīgot tikai kļūdas ziņojumu.
Četras kopējamas veidnes
1) Darba piemērotības novērtējums:
Jūsu loma: vecākais DevOps/SRE konsultants. Es aprakstīšu jums lomu. Pastāstiet man (1), vai tas ir izstrādes/analīzes uzdevums, ko var droši deleģēt AI, vai arī svarīgs lēmums, kas ietekmē produktu; (2) pastāstiet sliktāko rezultātu, ja tas noiet greizi; (3) norādiet verifikācijas darbības, kas jāveic pirms ieviešanas.Uzdevums: [ŠEIT]
2) Droša konteksta piešķiršana (slepenā maskēšana):
Tālāk analizējiet kļūdu. Es maskēju visus noslēpumus ar <PLACEHOLDER>; Jūs arī iesakāt NEKAD risinājumā neizveidot īstu noslēpumu, izmantot vietturi un iegult noslēpumu kodā, nolasīt no slepenās glabātuves. Kļūda/žurnāls: [MASKED CONTENT]
3) Komandas pārbaude:
Izskaidrojiet man šo komandu: pierakstiet, ko katrs karodziņš dara, uz kuru rīka versiju tas attiecas, un tā bīstamāko blakusefektu. Visbeidzot, uzskaitiet 3 pārbaudes, kas jāveic pirms šīs darbības palaišanas prod. Komanda: [ŠEIT]
4) Mācību/koncepcijas vaicājums:
Es [JĒDZIENS: piem. Izskaidrojiet [zili-zaļās izvietošanas] jēdzienu tā, it kā jūs to izskaidrotu DevOps inženierim: ko tas dara, kad to izmantot, kad to neizmantot, 2 tipiskas kļūdas. Esiet īsi un konkrēti.
Vāja uzvedne / spēcīga uzvedne
Vāji: "Uzrakstiet man izvietošanas skriptu."
Secinājums: nav skaidrs, kurš mākonis, kurš rīks, kura vide; AI rada vispārīgu skriptu, kas, iespējams, nav ražots, kas iegulst noslēpumu kodā.
Strong: "Uzrakstiet bash skripta melnrakstu, kas tiek izvietots AWS ECS (Elastīgā konteinera pakalpojumā). Reģions ir eu-central-1, attēls nāk no ECR. Nekad neieguliet noslēpumus kodā, lasiet tos no AWS Secrets Manager. Ja katrā solī ir kļūda, pārtrauciet (iestatiet -euo pipefail). Ierakstiet visas 3 verifikācijas darbības."
Atšķirība: otrā uzvedne sniedz mākoni, rīku, vidi, drošības noteikumu un apstiprinājuma cerības — izvade ir tieši noderīga un droša.
Biežas kļūdas
- Faktiskā noslēpuma ielīmēšana uzvednē. Visizplatītākā un bīstamākā kļūda. Vienmēr maska.
- Bezkonteksta uzvedne. Nenorādot mākoni, versiju, vidi, vēlamā izvade bieži vien pieder nepareizai versijai vai nepareizai arhitektūrai.
- Izlaižot sauso skriešanu. Ieviešana bez plānošanas/--dry-run ir visdārgākā DevOps saīsne.
- Pirmais mēģinājums prod. Katra jauna AI izvade vispirms ir jāpalaiž testēšanas/uzstādīšanas laikā.
- Atbildības deleģēšana ar “AI teica”. Atbildība vienmēr paliek realizētājam inženierim.
- Uzticoties halucinācijas karogam. Neesoša komandas karoga izpilde bez vaicājuma.
Rezumējot
DevOps un mākoņa AI; Tas ir palīgs, kas nodrošina lielu ātrumu teksta ietilpīgos uzdevumos, piemēram, konveijerā, konfigurācijā, skriptā un žurnālā. Bet atbildība par lēmumiem, kas ietekmē produktu, slepeno pārvaldību un galīgo ieviešanu, paliek kompetentajam inženierim. Šī moduļa pamatprincipi ir trīspakāpju verifikācija (savienojums ar avotu, iztukšošana, izlaišana caur sistēmas filtru), noslēpumu nenoplūde un aizsardzība tikai autorizētās sistēmās.
Lietojumprogrammas uzdevums
Atlasiet nesen veiktu DevOps uzdevumu no sava darba (vai projekta parauga). (1) Aprakstiet šo uzdevumu AI, izmantojot iepriekš norādīto “darba piemērotības novērtējuma” veidni, un izlasiet tā klasifikāciju. (2) Ja tajā ir noslēpums, sagatavojiet konteksta tekstu, maskējot to. (3) Pārbaudiet AI izvadi ar trīspakāpju verifikāciju un vienā teikumā atzīmējiet, ko esat labojis katrā solī.
kontrolsaraksts
- [ ] Es klasificēju savu uzdevumu kā "deleģējams darbs" vai "kritisks lēmums".
- [ ] Es neielīmēju uzvednē nekādus aktuālus noslēpumus; Es tos visus nomaskēju ar vietturi.
- [ ] Uzvednei pievienoju kontekstu par mākoni, rīka versiju un vidi.
- [ ] Es pārbaudīju mākslīgā intelekta izvadi ar sauso darbību/plānu pirms tās piemērošanas.
- [ ] Pirmo mēģinājumu veicu testa/iestudēšanas vidē, nevis prod.
- [ ] Aizsardzības nolūkos strādāju tikai sistēmās, kurās man bija autoritāte.