Tootmisvalmiduse kontrollnimekiri

Artikli tõlge koostati spetsiaalselt kursuse üliõpilastele "DevOpsi tavad ja tööriistad", mis algab täna!

Kas olete kunagi uue teenuse tootmisse andnud? Või äkki osalesite selliste teenuste toetamisel? Kui jah, siis mis sind motiveeris? Mis on tootmiseks hea ja mis halb? Kuidas koolitate uusi meeskonnaliikmeid olemasolevate teenuste väljalaske või hoolduse osas?

Enamik ettevõtteid võtab tööstusliku tegevuse puhul kasutusele metsiku lääne lähenemisviisi. Iga meeskond otsustab katse-eksituse meetodil oma tööriistade ja parimate tavade üle ise. Kuid see ei mõjuta sageli mitte ainult projektide edu, vaid ka insenere.

Katse-eksituse meetodid loovad keskkonna, kus näpuga näitamine ja süüdistamine on levinud. Sellise käitumisega on üha raskem vigadest õppida ja neid mitte korrata.

Edukad organisatsioonid:

• mõistavad tootmisjuhiste vajadust,
• õppida parimaid tavasid,
• alustada arutelusid tootmisvalmiduse küsimuste üle uute süsteemide või komponentide väljatöötamisel,
• tagama tootmiseks ettevalmistamise reeglite järgimise.

Tootmiseks ettevalmistamine hõlmab "ülevaatamise" protsessi. Ülevaade võib olla kontrollnimekirja või küsimuste komplektina. Ülevaateid saab teha käsitsi, automaatselt või mõlemat. Staatiliste nõuete loendite asemel saate teha kontrollnimekirjade malle, mida saab kohandada vastavalt konkreetsetele vajadustele. Nii saab inseneridele anda võimaluse pärida teadmisi ja vajadusel piisavalt paindlikkust.

Millal kontrollida teenuse tootmisvalmidust?

Tootmisvalmiduse kontrolli on kasulik läbi viia mitte ainult vahetult enne vabastamist, vaid ka selle üleviimisel teise operatiivmeeskonda või uuele töötajale.

Kontrollige, millal:

• Annate tootmisse uue teenuse.
• Annate tootmisteenuse juhtimise üle teisele meeskonnale, näiteks SRE-le.
• Annate tootmisteenuse juhtimise üle uutele töötajatele.
• Korraldage tehniline tugi.

Tootmisvalmiduse kontrollnimekiri

Mõni aeg tagasi näiteks ma опубликовала kontrollnimekiri tootmisvalmiduse testimiseks. Kuigi see loend pärineb Google Cloudi klientidelt, on see kasulik ja rakendatav väljaspool Google Cloudi.

Disain ja arendus

• Töötage välja korratav ehitusprotsess, mis ei nõua juurdepääsu välistele teenustele ja ei sõltu väliste süsteemide tõrgetest.
• Disaini- ja arendusperioodil määratlege ja määrake oma teenuste jaoks SLO-d.
• Dokumenteerige ootused välisteenuste kättesaadavusele, millest sõltute.
• Vältige ühte tõrkepunkti, eemaldades sõltuvused ühest globaalsest ressursist. Kopeerige ressurssi või kasutage varuvarianti, kui ressurss pole saadaval (nt kõvakoodiga väärtus).

Konfiguratsiooni juhtimine

• Staatilist, väikest ja mittesalajast konfiguratsiooni saab edastada käsurea parameetrite kaudu. Kõige muu jaoks kasutage konfiguratsioonisalvestusteenuseid.
• Dünaamilisel konfiguratsioonil peavad olema varuseaded juhuks, kui konfiguratsiooniteenus pole saadaval.
• Arenduskeskkonna konfiguratsioon ei tohiks olla seotud tootmiskonfiguratsiooniga. Vastasel juhul võib see kaasa tuua juurdepääsu arenduskeskkonnast tootmisteenustele, mis võib põhjustada privaatsusprobleeme ja andmete lekkimist.
• Dokumenteerige, mida saab dünaamiliselt konfigureerida, ja kirjeldage varukäitumist, kui konfiguratsiooni edastamise süsteem pole saadaval.

Väljalaske haldamine

• Dokumenteerige vabastamisprotsess üksikasjalikult. Kirjeldage, kuidas väljalasked mõjutavad SLO-sid (nt ajutine latentsusaja pikenemine vahemälu vahelejäämise tõttu).
• Kanaari väljalasked dokumenteerida.
• Töötage välja kanaari vabastamise ülevaatamise plaan ja võimalusel automaatsed tagasipööramismehhanismid.
• Veenduge, et tagasipööramine saaks kasutada samu protsesse kui juurutamine.

Vaadeldavus

• Veenduge, et kogutakse SLO jaoks vajalik mõõdikute kogum.
• Veenduge, et suudate kliendi- ja serveriandmetel vahet teha. See on oluline rikete põhjuste leidmiseks.
• Tööjõukulude vähendamiseks seadistage märguanded. Näiteks eemaldage rutiinsetest toimingutest põhjustatud hoiatused.
• Kui kasutate Stackdriverit, lisage oma armatuurlauale GCP platvormi mõõdikud. Seadistage GCP-sõltuvuste hoiatused.
• Levitage alati sissetulevaid jälgi. Isegi kui te ei ole jälgimisega seotud, võimaldab see madalama taseme teenustel tootmisprobleeme siluda.

Kaitse ja ohutus

• Veenduge, et kõik välised ühendused oleksid krüptitud.
• Veenduge, et teie tootmisprojektidel oleks õige IAM-seade.
• Kasutage võrke virtuaalse masina eksemplaride rühmade eraldamiseks.
• Kasutage kaugvõrkudega turvalise ühenduse loomiseks VPN-i.
• Dokumenteerige ja jälgige kasutajate juurdepääsu andmetele. Veenduge, et kogu kasutaja juurdepääs andmetele oleks auditeeritud ja logitud.
• Veenduge, et silumise lõpp-punktid oleksid ACL-idega piiratud.
• Desinfitseerige kasutaja sisestus. Konfigureerige kasutaja sisendi jaoks kasuliku koorma suuruse piirangud.
• Veenduge, et teie teenus saaks üksikute kasutajate sissetuleva liikluse valikuliselt blokeerida. See blokeerib rikkumised teisi kasutajaid mõjutamata.
• Vältige väliseid lõpp-punkte, mis käivitavad palju sisemisi toiminguid.

Võimekuse planeerimine

• Dokumenteerige, kuidas teie teenus ulatub. Näiteks: kasutajate arv, sissetuleva kandevõime suurus, sissetulevate sõnumite arv.
• Dokumenteerige oma teenuse ressursinõuded. Näiteks: spetsiaalsete virtuaalse masina eksemplaride arv, mutrivõtme eksemplaride arv, spetsiaalne riistvara (nt GPU või TPU).
• Dokumendi ressursside piirangud: ressursi tüüp, piirkond jne.
• Uute ressursside loomiseks dokumenteerige kvoodipiirangud. Näiteks GCE API päringute arvu piiramine, kui kasutate API-d uute eksemplaride loomiseks.
• Kaaluge jõudluse halvenemise analüüsimiseks koormustestide käivitamist.

See on kõik. Kohtumiseni klassis!

Allikas: www.habr.com