Valmiduse kontrollnimekiri tootmisse

Artikli tõlge on ette valmistatud spetsiaalselt kursuse üliõpilastele «DevOps praktikad ja tööriistad», mis algab juba täna!

Kas olete kunagi lansseerinud uut teenust tootmisse? Või olete võib-olla hooldanud selliseid teenuseid? Kui jah, siis millega te juhindusite? Mis on tootmisse sobiv, mis mitte? Kuidas õpetate uusi meeskonnaliikmeid väljaannete või olemasolevate teenuste haldamise üle?

Enamik ettevõtteid jõuab tööstuslike praktikate osas lõpuks „Lääne“ lähenemist. Iga meeskond määratleb ise oma tööriistad ja parimad praktikad katsetamise ja eksimise teel. Kuid see mõjutab sageli mitte ainult projektide edu, vaid ka insenere.

Katsetamise ja eksimise meetod loob keskkonna, kus süüdistamine ja vastutuse veeretamine on levinud. Sellise käitumise korral muutub üha raskem õppida oma vigadest ja mitte korrata neid uuesti.

Edukaid organisatsioone iseloomustavad:

• teadvustavad, et tootmise juhiseid on vajalikud,
• uurivad parimaid tavasid,
• arutage tootmisvalmiduse küsimusi uute süsteemide või komponentide arendamisel,
• tagavad tootmise ettevalmistuse reeglite järgimise.

Tootmisettevalmistus hõlmab „ülevaatuse“ protsessi. Ülevaatus võib olla kas kontrollnimekirja või küsimuste kogumina. Ülevaatust saab teha käsitsi, automaatselt või kummalgi viisil. Statiliste nõudmiste loendite asemel on võimalik koostada kontrollnimekirjade malli, mida saab kohandada spetsiifiliste vajadustega. Nii saavad insenerid viisi teadmiste pärimise ja piisava paindlikkuse tagamiseks, kui seda on vaja.

Millal kontrollida teenust tootmissevalmiduse osas?

Tootmisvalmiduse kontrollimist on kasulik teha mitte ainult vahetult enne väljaandmist, vaid ka teenuse edasiandmisel teisele haldustiimile või uuele töötajale.

Tehke kontroll, kui:

• Lansseerite uue teenuse tootmisse.
• Edastate tootmisteenuse haldamise teisele meeskonnale, näiteks SRE-le.
• Edastate tootmisteenuse haldamise uutele töötajatele.
• Korraldate tehnilist tuge.

Tootmisvalmiduse kontrollnimekiri

Mõni aeg tagasi, näiteks, ma avalikustas tootmisvalmiduse kontrollimise kontrollnimekirja. Kuigi see nimekiri ilmus Google Cloud'i klientidega töötamise käigus, on see kasulik ja kohaldatav ka väljaspool Google Cloud'i.

Projekteerimine ja arendamine

• Arendage korratav ehitusprotsess, mis ei nõua juurdepääsu välistele teenustele ja ei sõltu välistest süsteemide tõrgetest.
• Projekteerimise ja arendamise käigus määrake ja seadistage oma teenuste SLO-d.
• Dokumenteerige ootused sõltuvate välistest teenuste kättesaadavuse osas.
• Vältige ühte rikkepunkti, kaotades sõltuvused ühest globaalsetest allikatest. Korrake allikat või kasutage varuvõimalust, kui allikas pole saadaval (nt kõvasti kodeeritud väärtus).

Konfiguratsiooni haldamine

• Väikese, staatilise ja mitte-ära-oleva konfiguratsiooni saab edastada käskluste argumentide kaudu. Ülejäänud jaoks kasutage konfiguratsiooni salvestamise teenuseid.
• Dünaamilisel konfiguratsioonil peab olema varu seaded, kui konfiguratsiooniteenus pole saadaval.
• Arenduskeskkonna konfiguratsioon ei tohi olla seotud tootmisliigu konfiguratsiooniga. Vastasel korral võib see põhjustada arenduskeskkonnast juurdepääsu tootmisteenustele, mis võib tekitada privaatsusprobleeme ja andmeleke.
• Dokumenteerige, mida saab dünaamiliselt seadistada, ja kirjeldage varude käitumist, kui konfiguratsiooni edastamise süsteem ei ole saadaval.

Väljaandmise haldamine

• Dokumenteerige väljaandmisprotsess üksikasjalikult. Kirjeldage, kuidas väljaanded mõjutavad SLO-d (nt ajutine viivitus, mis on seotud vahemälu tõrgetega).
• Dokumenteerige kanarud väljalaskmised.
• Välja töötada plaan kanarud väljalaskmise analüsiks ja kui võimalik, mehhanismide automaatseks tagasivõtmiseks.
• Veenduge, et tagasivõtud saavad kasutada samu protsesse, mis ka juurutamine.

Jälgimise sobivus (Observability)

• Veenduge, et kogutakse vajalikud mõõdikud SLO jaoks.
• Veenduge, et kliendi ja serveri andmed on selgelt eristatavad. See on oluline tõrgete põhjuste leidmiseks.
• Seadista märguanded, et vähendada tööjõu kulusid. Näiteks eemaldage märguanded, mis on põhjustatud rutiinsetest toimingutest.
• Kui kasutate Stackdriverit, siis kaasake GCP platvormi mõõdikud oma juhtpaneelidesse. Seadista märguanded GCP sõltuvuste jaoks.
• Jagage alati sissetulevat jälgimisteavet. Isegi kui te ei osale jälgimises, aitab see teenustel madalamal tasandil tootmisprobleeme tõrkeotsingul.

Kaitse ja turvalisus

• Veenduge, et kõik välised ühendused on krüpteeritud.
• Veenduge, et teie tootmisprojektidel on õiged IAM seaded.
• Kasutage võrgustikke virtuaalmasinate rühmade isoleerimiseks.
• Kasutage VPN-i turvaliseks ühendamiseks kaugvõrkudega.
• Dokumenteerige ja jälgige kasutajate juurdepääsu andmetele. Veenduge, et kogu kasutajate juurdepääs andmetele on kontrollitud ja logitud.
• Veenduge, et silumise lõpp-punktid on piiratud ACL-iga.
• Sanitiseerige kasutaja sisend. Seadke piirangud kasutaja sisendi koormuse suurusele.
• Veenduge, et teie teenus suudab sihikindlalt blokeerida sissetulevat liiklust üksikutele kasutajatele. See võimaldab blokeerida rikkumisi, mõjutamata teisi kasutajaid.
• Vältige väliseid lõpp-punkte, mis käivitavad suures koguses sisemisi toiminguid.

Ressursside planeerimine

• Dokumenteerige, kuidas teie teenus skaleerub. Näiteks: kasutajate arv, sissetuleva koormuse suurus, saabuvate sõnumite arv.
• Dokumenteerige teie teenuse ressursivõimekuse nõuded. Näiteks: eraldatud virtuaalmasinate arv, Spanneri instantside arv, spetsiaalne riistvara, nagu GPU või TPU.
• Dokumenteerige ressursipiirangud: ressursi tüüp, piirkond jne.
• Dokumenteerige uute ressursside loomise kvotipiirangud. Näiteks GCE API päringute arv, kui kasutate API-d uute instantside loomiseks.
• Kaaluge koormustestide läbiviimist jõudluse analüüsimiseks.

See ongi kõik. Kohtume tundides!

Allikas: habr.com