De oersetting fan it artikel waard spesifyk taret foar de learlingen fan 'e kursus , dy't hjoed begjint!
Hawwe jo oait in nije tsjinst yn produksje frijlitten? Of miskien wiene jo belutsen by it stypjen fan sokke tsjinsten? As ja, wat motivearre jo? Wat is goed foar produksje en wat is min? Hoe traine jo nije teamleden op releases of ûnderhâld fan besteande tsjinsten.
De measte bedriuwen nimme úteinlik "Wild West" oanpakken oan as it giet om yndustriële operaasjepraktiken. Elk team beslút oer har eigen ark en bêste praktiken troch probearjen en flater. Mar dit hat faak ynfloed op net allinich it sukses fan projekten, mar ek de yngenieurs.
Trial and error skept in omjouwing dêr't finger-pointing en blame-shifting gewoan binne. Mei dit gedrach wurdt it hieltyd dreger om te learen fan flaters en se net wer te herheljen.
Súksesfolle organisaasjes:
- realisearje de needsaak foar rjochtlinen foar produksje,
- studearje bêste praktiken,
- begjinne diskusjes oer problemen mei produksjereeheid by it ûntwikkeljen fan nije systemen of komponinten,
- soargje foar neilibjen fan de regels fan tarieding foar produksje.
Tarieding foar produksje omfiemet in "resinsje" proses. De resinsje kin wêze yn 'e foarm fan in checklist of in set fan fragen. Resinsjes kinne wurde dien mei de hân, automatysk, of beide. Yn stee fan statyske listen fan easken, kinne jo meitsje checklist sjabloanen dy't kinne wurde oanpast oan spesifike behoeften. Op dizze manier kinne yngenieurs in manier krije om kennis te erven en genôch fleksibiliteit as nedich.
Wannear te kontrolearjen in tsjinst foar reewilligens foar produksje?
It is nuttich om in kontrôle fan 'e reewilligens fan' e produksje net allinich fuort foar frijlitting út te fieren, mar ek by it oerdragen nei in oar operaasjeteam as in nije meiwurker.
Kontrolearje wannear:
- Jo jouwe in nije tsjinst út yn produksje.
- Jo drage de wurking fan 'e produksjetsjinst oer nei in oar team, lykas SRE.
- Jo oerdrage operaasje fan 'e produksjetsjinst oan nije meiwurkers.
- Organisearje technyske stipe.
Produksje reewilligens checklist
In skoft lyn, as foarbyld, I checklist foar testen reewilligens foar produksje. Hoewol dizze list ûntstien is mei Google Cloud-klanten, sil it nuttich en fan tapassing wêze bûten Google Cloud.
Untwerp en ûntwikkeling
- Untwikkelje in werhelle bouproses dat gjin tagong hat ta eksterne tsjinsten en net ôfhinklik is fan it mislearjen fan eksterne systemen.
- Tidens de ûntwerp- en ûntwikkelingsperioade, definiearje en ynstelle SLO's foar jo tsjinsten.
- Dokumintearje ferwachtings foar de beskikberens fan eksterne tsjinsten wêrfan jo ôfhinklik binne.
- Foarkom in inkeld punt fan mislearring troch it fuortheljen fan ôfhinklikens fan ien globale boarne. Replikearje de boarne of brûk in fallback as de boarne net beskikber is (bygelyks in hurdkodearre wearde).
Konfiguraasje behear
- Statyske, lytse en net-geheime konfiguraasje kinne wurde trochjûn fia kommandorigelparameters. Foar al it oare, brûk konfiguraasje opslach tsjinsten.
- In dynamyske konfiguraasje moat fallback-ynstellingen hawwe foar it gefal dat de konfiguraasjetsjinst net beskikber is.
- De konfiguraasje fan ûntwikkelingsomjouwing moat net relatearre wurde oan de produksjekonfiguraasje. Oars kin dit liede ta tagong fan 'e ûntwikkelingsomjouwing ta produksjetsjinsten, wat privacyproblemen en gegevenslekkage kin feroarsaakje.
- Dokumintearje wat dynamysk konfigurearre wurde kin en beskriuw fallbackgedrach as it konfiguraasjeleveringssysteem net beskikber is.
Release behear
- Dokumentearje it frijlittingsproses yn detail. Beskriuw hoe't releases beynfloedzje SLO's (bygelyks tydlike ferheging fan latency troch cache-missings).
- Dokumint canary releases.
- Untwikkelje in kanaryske release review plan en, as it mooglik is, automatyske rollback meganismen.
- Soargje derfoar dat rollbacks deselde prosessen kinne brûke as ynset.
Observabiliteit
- Soargje derfoar dat de set metriken nedich foar de SLO wurdt sammele.
- Soargje derfoar dat jo ûnderskiede kinne tusken client- en servergegevens. Dit is wichtich foar it finen fan de oarsaken fan storingen.
- Stel warskôgings yn om arbeidskosten te ferminderjen. Ferwiderje bygelyks warskôgings feroarsake troch routine operaasjes.
- As jo Stackdriver brûke, befetsje dan GCP-platfoarmmetriken yn jo dashboards. Stel warskôgings yn foar GCP-ôfhinklikens.
- Altyd ynkommende spoaren propagearje. Sels as jo net belutsen binne by tracing, sil dit tsjinsten op leger nivo tastean om problemen yn produksje te debuggen.
Beskerming en feiligens
- Soargje derfoar dat alle eksterne ferbinings binne fersifere.
- Soargje derfoar dat jo produksjeprojekten de juste IAM-opset hawwe.
- Brûk netwurken om groepen fan firtuele masine-eksimplaren te isolearjen.
- Brûk in VPN om feilich te ferbinen mei netwurken op ôfstân.
- Dokumintearje en kontrolearje brûkers tagong ta gegevens. Soargje derfoar dat alle brûker tagong ta gegevens wurdt kontrolearre en oanmeld.
- Soargje derfoar dat debuggen einpunten wurde beheind troch ACL's.
- Sanitize brûkersynput. Konfigurearje grinzen fan payloadgrutte foar brûkersynput.
- Soargje derfoar dat jo tsjinst ynkommende ferkear selektyf kin blokkearje foar yndividuele brûkers. Dit sil oertredings blokkearje sûnder oare brûkers te beynfloedzjen.
- Mije eksterne einpunten dy't in protte ynterne operaasjes begjinne.
Kapasiteit planning
- Dokumintearje hoe't jo tsjinst skalen. Bygelyks: oantal brûkers, grutte fan ynkommende lading, oantal ynkommende berjochten.
- Dokumintearje de boarne easken foar jo tsjinst. Bygelyks: oantal tawijde firtuele masine-eksimplaren, oantal Spanner-eksimplaren, spesjalisearre hardware lykas GPU of TPU.
- Beheinings fan dokumintboarnen: type boarne, regio, ensfh.
- Dokumint kwota beheinings foar it meitsjen fan nije middels. Bygelyks, it beheinen fan it oantal GCE API-oanfragen as jo de API brûke om nije eksimplaren te meitsjen.
- Tink oan it útfieren fan loadtests om prestaasjesdegradaasje te analysearjen.
Da's alles. Oant sjen yn 'e klasse!
Boarne: www.habr.com