Ražošanas gatavības kontrolsaraksts

Raksta tulkojums sagatavots īpaši kursa studentiem «DevOps prakse un rīki», kas sākas jau šodien!

Vai jūs kādreiz esat ieviesuši jaunu pakalpojumu ražošanā? Vai varbūt esat strādājuši pie esošu pakalpojumu uzturēšanas? Ja jā, tad kas jums bija par pamatu? Kas ir labi ražošanā, bet kas slikti? Kā jūs apmācāt jaunus komandas dalībniekus par laidienu vai esošu pakalpojumu atbalstu?

Lielākā daļa uzņēmumu attiecībā uz ražošanas praksi galu galā nonāk pie 'Savvaļas Rietumu' pieejas. Katrs komanda, izmantojot izmēģinājumus un kļūdas, patstāvīgi nosaka rīkus un labākās prakses. Bet tas bieži ietekmē ne tikai projektu veiksmi, bet arī inženierus.

Izmēģinājumu un kļūdu metode rada vidi, kurā ir izplatīts meklēšana vainīgajiem un atbildības pārlikšana. Šādas uzvedības dēļ kļūst arvien grūtāk mācīties no kļūdām un tās neatkārtot.

Veiksmīgas organizācijas:

• apzinās vadlīniju nepieciešamību ražošanai,
• izpēta labākās prakses,
• uzsāk diskusiju par gatavību ražošanai, izstrādājot jaunas sistēmas vai komponentus,
• nodrošina noteikumu ievērošanu sagatavošanas procesā ražošanai.

Sagatavošanās ražošanai ietver 'pārskata' procesu. Pārskats var būt checklista vai jautājumu komplekts. Pārskatu var veikt manuāli, automātiski vai abos veidos. Vietējās prasības var aizvietot ar veidnēm, kuras pielāgo konkrētajām vajadzībām. Tādējādi inženieriem tiek nodrošināta iespēja mācīties un pietiekama elastība, kad tas nepieciešams.

Kad pārbaudīt pakalpojumu gatavību ražošanai?

Pārbaude par gatavību ražošanā ir noderīga ne tikai tieši pirms laidiena, bet arī nododot to citai uzturēšanas komandai vai jaunam darbiniekam.

Veiciet pārbaudi, kad:

• Ieviešat jaunu pakalpojumu ražošanā.
• Nodevat ražošanas pakalpojumu uzturēšanu citai komandai, piemēram, SRE.
• Nodevat ražošanas pakalpojumu uzturēšanu jauniem darbiniekiem.
• Organizējat tehnisko atbalstu.

Ražošanas gatavības pārbaudes checklists

Pirms kāda laika, piemēram, es ir publicējis pārbaudes checklists ražošanas gatavībai. Neskatoties uz to, ka šis saraksts radās strādājot ar Google Cloud klientiem, tas būs noderīgs un piemērojams arī ārpus Google Cloud.

Projektēšana un izstrāde

• Izstrādājiet reproducējamu būvniecības procesu, kas neprasa piekļuvi ārējiem pakalpojumiem un nav atkarīgs no ārējo sistēmu kļūdām.
• Projektēšanas un attīstības posmā noteikt un izveidot SLO saviem pakalpojumiem.
• Dokumentējiet gaidītos pieejamības līmeņus ārējiem pakalpojumiem, no kuriem jūs atkarīgs.
• Izvairieties no vienota atteices punkta, novēršot atkarības no viena globālā resursa. Replikējiet resursu vai izmantojiet rezerves variantu, ja resurss nav pieejams (piemēram, cieti kodēta vērtība).

Konfigurācijas vadība

• Statisku, mazu un neslepeno konfigurāciju var nodot caur komandrindas parametriem. Visiem pārējiem izmantot konfigurācijas glabāšanas pakalpojumus.
• Dinamikajai konfigurācijai jābūt rezerves iestatījumiem gadījumā, ja konfigurācijas pakalpojums nav pieejams.
• Izstrādes vides konfigurācijai nedrīkst būt saistības ar ražošanas konfigurāciju. Pretējā gadījumā tas var radīt piekļuvi ražošanas pakalpojumiem no izstrādes vides, kas var izraisīt privātuma problēmas un datu noplūdes.
• Dokumentējiet to, kas var tikt dinamiski konfigurēts, un aprakstiet rezervi uzvedību, ja konfigurācijas piegādes sistēma nav pieejama.

Izlaižu pārvaldība

• Detalizēti dokumentējiet izlaišanas procesu. Aprakstiet, kā izlaišanas ietekmē SLO (piemēram, īslaicīgs aizkaves pieaugums rādītāju trūkumu dēļ).
• Dokumentējiet kanāriju izlaišanas.
• Izstrādājiet kanāriju izlaišanas analīzes plānu un, ja iespējams, mehānismus automātiskai atgriešanai.
• Pārliecinieties, ka atgriezšana var izmantot tos pašus procesus kā izvietošana.

Novērošanas spēja

• Pārliecinieties, ka tiek vākti nepieciešamie metri SLO.
• Pārliecinieties, ka varat atšķirt klientu un servera datus. Tas ir svarīgi problēmu cēloņu meklēšanai.
• Iestatiet brīdinājumus, lai samazinātu darbaspēka patēriņu. Piemēram, novērst brīdinājumus, kas izraisa rutīnas darbības.
• Ja izmantojat Stackdriver, iekļaujiet GCP platformas metri savos vadības paneļos. Iestatiet brīdinājumus GCP atkarībām.
• Vienmēr izplatiet ienākošo izsekošanu. Pat ja jūs nepiedalāties izsekošanā, tas ļaus zemāka līmeņa pakalpojumiem diagnosticēt problēmas ražošanā.

Aizsardzība un drošība

• Pārliecinieties, ka visi ārējie savienojumi ir šifrēti.
• Pārliecinieties, ka jūsu ražošanas projektiem ir pareiza IAM konfigurācija.
• Izmantojiet tīklus, lai izolētu virtuālo mašīnu instanču grupas.
• Izmantojiet VPN drošai pieslēgšanai attālajiem tīkliem.
• Dokumentējiet un uzraugiet lietotāju piekļuvi datiem. Pārliecinieties, ka visa lietotāju piekļuve datiem tiek pārbaudīta un reģistrēta.
• Pārliecinieties, ka atkļūdošanas galapunkti ir ierobežoti ar ACL.
• Sanitizējiet lietotāju ievadi. Iestatiet kravas lieluma ierobežojumus lietotāju ievadei.
• Pārliecinieties, ka jūsu pakalpojums var selektīvi bloķēt ienākošo trafiku atsevišķiem lietotājiem. Tas ļaus bloķēt pārkāpumus, neietekmējot citus lietotājus.
• Izvairieties no ārējiem galapunktiem, kas iniciē lielu skaitu iekšējo operāciju.

Jaudu plānošana

• Dokumentējiet, kā jūsu pakalpojums paplašinās. Piemēram: lietotāju skaits, ienākošās kravas lielums, ienākošo ziņojumu skaits.
• Dokumentējiet resursu prasības jūsu pakalpojumam. Piemēram: veltīto virtuālo mašīnu skaits, Spanner instanču skaits, specializēta aparatūra, piemēram, GPU vai TPU.
• Dokumentējiet resursu ierobežojumus: resursa tips, reģions utt.
• Dokumentējiet kvotu ierobežojumus jaunu resursu izveidei. Piemēram, GCE API pieprasījumu ierobežojums, ja izmantojat API jaunu instanču izveidei.
• Apsveriet slodzes testēšanas veikšanu, lai analizētu veiktspējas samazināšanos.

Tas arī viss. Tiksimies nodarbībās!

Avots: habr.com