Raksta tulkojums tika sagatavots speciāli kursa studentiem , kas sākas šodien!
Vai esat kādreiz izlaidis jaunu pakalpojumu ražošanā? Vai varbūt jūs bijāt iesaistīts šādu pakalpojumu atbalstīšanā? Ja jā, kas jūs motivēja? Kas ir labs ražošanai un kas ir slikts? Kā apmācīt jaunus komandas dalībniekus par esošo pakalpojumu izlaišanu vai uzturēšanu.
Lielākā daļa uzņēmumu beidzot pieņem "mežonīgo rietumu" pieeju, kad runa ir par rūpnieciskās darbības praksi. Katra komanda izlemj par saviem rīkiem un labāko praksi, izmantojot izmēģinājumus un kļūdas. Bet tas bieži vien ietekmē ne tikai projektu panākumus, bet arī inženierus.
Mēģinājumi un kļūdas rada vidi, kurā ir izplatīta parādīšana ar pirkstu un vainu maiņa. Ar šādu uzvedību kļūst arvien grūtāk mācīties no kļūdām un tās vairs neatkārtot.
Veiksmīgas organizācijas:
- apzināties nepieciešamību pēc ražošanas vadlīnijām,
- izpētīt labāko praksi,
- uzsākt diskusijas par ražošanas gatavības jautājumiem, izstrādājot jaunas sistēmas vai komponentus,
- nodrošina sagatavošanas ražošanai noteikumu ievērošanu.
Sagatavošanās ražošanai ietver “pārskatīšanas” procesu. Pārskats var būt kontrolsaraksta vai jautājumu kopuma veidā. Pārskatīšanu var veikt manuāli, automātiski vai abos gadījumos. Statisku prasību sarakstu vietā varat izveidot kontrolsarakstu veidnes, kuras var pielāgot konkrētām vajadzībām. Tādā veidā inženieriem var tikt dots veids, kā vajadzības gadījumā mantot zināšanas un pietiekamu elastību.
Kad pārbaudīt servisa gatavību ražošanai?
Ražošanas gatavības pārbaudi ir lietderīgi veikt ne tikai tieši pirms izlaišanas, bet arī nododot to citai operāciju komandai vai jaunam darbiniekam.
Pārbaudiet, kad:
- Jūs izlaižat jaunu pakalpojumu ražošanā.
- Jūs nododat ražošanas pakalpojuma darbību citai komandai, piemēram, SRE.
- Jūs nododat ražošanas pakalpojuma darbību jauniem darbiniekiem.
- Organizēt tehnisko atbalstu.
Ražošanas gatavības kontrolsaraksts
Pirms kāda laika, piemēram, es kontrolsaraksts, lai pārbaudītu gatavību ražošanai. Lai gan šo sarakstu veidoja Google Cloud klienti, tas būs noderīgs un piemērojams ārpus Google Cloud.
Dizains un izstrāde
- Izstrādājiet atkārtojamu veidošanas procesu, kam nav nepieciešama piekļuve ārējiem pakalpojumiem un kas nav atkarīgs no ārējo sistēmu atteices.
- Projektēšanas un izstrādes periodā definējiet un iestatiet saviem pakalpojumiem SLO.
- Dokumentējiet cerības attiecībā uz ārējo pakalpojumu pieejamību, no kuriem esat atkarīgs.
- Izvairieties no viena kļūmes punkta, noņemot atkarības no viena globāla resursa. Replicējiet resursu vai izmantojiet atkāpšanos, ja resurss nav pieejams (piemēram, cietā kodēta vērtība).
Konfigurācijas pārvaldība
- Statisku, mazu un neslepenu konfigurāciju var nodot, izmantojot komandrindas parametrus. Visam pārējam izmantojiet konfigurācijas krātuves pakalpojumus.
- Dinamiskajai konfigurācijai ir jābūt rezerves iestatījumiem, ja konfigurācijas pakalpojums nav pieejams.
- Izstrādes vides konfigurācijai nevajadzētu būt saistītai ar ražošanas konfigurāciju. Pretējā gadījumā tas var novest pie piekļuves no izstrādes vides uz ražošanas pakalpojumiem, kas var izraisīt privātuma problēmas un datu noplūdi.
- Dokumentējiet to, ko var konfigurēt dinamiski, un aprakstiet atkāpšanās darbību, ja konfigurācijas piegādes sistēma nav pieejama.
Izlaidumu pārvaldība
- Detalizēti dokumentējiet izlaišanas procesu. Aprakstiet, kā laidieni ietekmē SLO (piemēram, īslaicīgs latentuma palielinājums kešatmiņas izlaišanas dēļ).
- Dokumentējiet kanārijputniņu izlaidumus.
- Izstrādājiet Kanāriju izlaišanas pārskatīšanas plānu un, ja iespējams, automātiskos atcelšanas mehānismus.
- Pārliecinieties, ka atcelšanai var izmantot tos pašus procesus kā izvietošanai.
Novērojamība
- Nodrošiniet, lai tiktu apkopota SLO nepieciešamā metrikas kopa.
- Pārliecinieties, vai varat atšķirt klienta un servera datus. Tas ir svarīgi, lai noteiktu darbības traucējumu cēloņus.
- Iestatiet brīdinājumus, lai samazinātu darbaspēka izmaksas. Piemēram, noņemiet brīdinājumus, ko izraisa ikdienas darbības.
- Ja izmantojat Stackdriver, savos informācijas paneļos iekļaujiet GCP platformas metriku. Iestatiet brīdinājumus par GSP atkarībām.
- Vienmēr izplatīt ienākošās pēdas. Pat ja jūs neesat iesaistīts izsekošanu, tas ļaus zemāka līmeņa pakalpojumiem atkļūdot problēmas ražošanā.
Aizsardzība un drošība
- Pārliecinieties, vai visi ārējie savienojumi ir šifrēti.
- Pārliecinieties, vai jūsu ražošanas projektos ir pareizi IAM iestatījumi.
- Izmantojiet tīklus, lai izolētu virtuālās mašīnas gadījumu grupas.
- Izmantojiet VPN, lai droši izveidotu savienojumu ar attāliem tīkliem.
- Dokumentējiet un uzraugiet lietotāju piekļuvi datiem. Pārliecinieties, ka visa lietotāja piekļuve datiem tiek pārbaudīta un reģistrēta.
- Pārliecinieties, vai ACL ierobežo atkļūdošanas galapunktus.
- Dezinficējiet lietotāja ievadi. Konfigurējiet lietderīgās kravas lieluma ierobežojumus lietotāja ievadei.
- Pārliecinieties, vai jūsu pakalpojums var selektīvi bloķēt ienākošo trafiku atsevišķiem lietotājiem. Tas bloķēs pārkāpumus, neietekmējot citus lietotājus.
- Izvairieties no ārējiem galapunktiem, kas ierosina daudzas iekšējas darbības.
Jaudas plānošana
- Dokumentējiet, kā jūsu pakalpojumu mērogs. Piemēram: lietotāju skaits, ienākošās kravas lielums, ienākošo ziņojumu skaits.
- Dokumentējiet sava pakalpojuma resursu prasības. Piemēram: speciālo virtuālās mašīnas gadījumu skaits, uzgriežņu uzgriežņu gadījumu skaits, specializēta aparatūra, piemēram, GPU vai TPU.
- Dokumentu resursu ierobežojumi: resursa veids, reģions utt.
- Dokumentējiet kvotu ierobežojumus jaunu resursu veidošanai. Piemēram, ierobežojot GCE API pieprasījumu skaitu, ja izmantojat API jaunu gadījumu izveidei.
- Apsveriet slodzes testu veikšanu, lai analizētu veiktspējas pasliktināšanos.
Tas ir viss. Tiekamies klasē!
Avots: www.habr.com