Kontrollisto de preteco de produktado

La traduko de la artikolo estis preparita specife por la kursanoj "DevOps-praktikoj kaj iloj", kiu komenciĝas hodiaŭ!

Kontrollisto de preteco de produktado

Ĉu vi iam publikigis novan servon en produktadon? Aŭ eble vi okupiĝis pri subteno de tiaj servoj? Se jes, kio instigis vin? Kio estas bona por produktado kaj kio estas malbona? Kiel vi trejnas novajn teamanojn pri eldonoj aŭ prizorgado de ekzistantaj servoj.

Plej multaj kompanioj finas adopti "Sovaĝan Okcidenton" alirojn kiam temas pri industriaj operaciopraktikoj. Ĉiu teamo decidas pri siaj propraj iloj kaj plej bonaj praktikoj per provo kaj eraro. Sed ĉi tio ofte influas ne nur la sukceson de projektoj, sed ankaŭ la inĝenierojn.

Provo kaj eraro kreas medion, kie fingromontrado kaj kulpigo estas oftaj. Kun ĉi tiu konduto, fariĝas ĉiam pli malfacile lerni de eraroj kaj ne ripeti ilin denove.

Sukcesaj organizoj:

  • konscii la bezonon de gvidlinioj por produktado,
  • studi plej bonajn praktikojn,
  • komenci diskutojn pri produktadpretemaj aferoj dum evoluigado de novaj sistemoj aŭ komponentoj,
  • certigi la plenumon de la reguloj de preparado por produktado.

Preparo por produktado inkluzivas "revizian" procezon. La revizio povas esti en la formo de kontrola listo aŭ aro de demandoj. Recenzoj povas esti faritaj permane, aŭtomate aŭ ambaŭ. Anstataŭ senmovaj listoj de postuloj, vi povas fari kontrollistŝablonojn kiuj povas esti adaptitaj al specifaj bezonoj. Tiel, inĝenieroj povas ricevi manieron heredi scion kaj sufiĉe da fleksebleco kiam necese.

Kiam kontroli servon por preteco por produktado?

Estas utile fari kontrolon de preteco de produktado ne nur tuj antaŭ liberigo, sed ankaŭ transdonante ĝin al alia operacia teamo aŭ nova dungito.

Kontrolu kiam:

  • Vi publikigas novan servon en produktadon.
  • Vi transdonas la funkciadon de la produktadservo al alia teamo, kiel SRE.
  • Vi transdonas funkciadon de la produktadservo al novaj dungitoj.
  • Organizi teknikan subtenon.

Kontrollisto de preteco de produktado

Antaŭ iom da tempo, kiel ekzemplo, mi eldonita Kontrollisto por testado de preteco por produktado. Kvankam ĉi tiu listo estiĝis ĉe klientoj de Google Cloud, ĝi estos utila kaj aplikebla ekster Google Cloud.

Dezajno kaj evoluo

  • Disvolvu ripeteblan konstruprocezon, kiu ne postulas aliron al eksteraj servoj kaj ne dependas de la fiasko de eksteraj sistemoj.
  • Dum la periodo de dezajno kaj disvolviĝo, difinu kaj agordu SLO-ojn por viaj servoj.
  • Dokumentu atendojn pri la havebleco de eksteraj servoj, de kiuj vi dependas.
  • Evitu ununuran punkton de fiasko forigante dependecojn de ununura tutmonda rimedo. Repliku la rimedon aŭ uzu rezervilon kiam la rimedo estas neatingebla (ekzemple, malmola kodita valoro).

Administrado de agordo

  • Senmova, malgranda, kaj ne-sekreta agordo povas esti pasita per komandliniaj parametroj. Por ĉio alia, uzu agordajn stokadservojn.
  • Dinamika agordo devas havi rezervajn agordojn, se la agorda servo ne estas disponebla.
  • La agordo de disvolva medio ne estu rilata al la agordo de produktado. Alie, ĉi tio povas konduki al aliro de la evolumedio al produktadservoj, kiuj povas kaŭzi privatecajn problemojn kaj datumfluadon.
  • Dokumentu tion, kio povas esti agordita dinamike kaj priskribu faligan konduton se la agorda liversistemo estas neatingebla.

Eldonadministrado

  • Dokumentu la eldonprocezon detale. Priskribu kiel eldonoj influas SLOojn (ekzemple, provizoraj pliiĝoj en latencia pro kaŝmemoro misfunkciadoj).
  • Dokumentu kanariajn eldonojn.
  • Disvolvu planon pri revizio de kanaria eldono kaj, se eble, aŭtomatajn regajnajn mekanismojn.
  • Certigu, ke retrovojoj povas uzi la samajn procezojn kiel deplojoj.

Observeblo

  • Certigu, ke la aro de mezuroj necesaj por la SLO estas kolektita.
  • Certiĝu, ke vi povas diferenci inter kliento kaj servilo datumoj. Ĉi tio gravas por trovi la kaŭzojn de misfunkciado.
  • Agordu atentigojn por redukti laborkostojn. Ekzemple, forigu atentigojn kaŭzitajn de rutinaj operacioj.
  • Se vi uzas Stackdriver, tiam inkludu GCP-platform-metrikon en viajn instrumentpanelojn. Agordu atentigojn pri GCP-dependecoj.
  • Ĉiam propagandu envenantajn spurojn. Eĉ se vi ne okupiĝas pri spurado, ĉi tio permesos al malaltnivelaj servoj sencimigi problemojn en produktado.

Protekto kaj sekureco

  • Certigu, ke ĉiuj eksteraj konektoj estas ĉifritaj.
  • Certigu, ke viaj produktadprojektoj havas la ĝustan agordon de IAM.
  • Uzu retojn por izoli grupojn de virtualaj maŝinoj.
  • Uzu VPN por sekure konektiĝi al foraj retoj.
  • Dokumentu kaj monitoru uzantan aliron al datumoj. Certigu, ke ĉiuj uzantoj aliro al datumoj estas kontrolitaj kaj registritaj.
  • Certigu, ke sencimigaj finpunktoj estas limigitaj de ACLoj.
  • Sanigi uzantan enigon. Agordu limojn de utilŝarĝo por enigo de la uzanto.
  • Certigu, ke via servo povas selekteme bloki envenantan trafikon por individuaj uzantoj. Ĉi tio blokos malobservojn sen tuŝi aliajn uzantojn.
  • Evitu eksterajn finpunktojn, kiuj iniciatas multajn internajn operaciojn.

Kapacitplanado

  • Dokumentu kiel via servo skalas. Ekzemple: nombro da uzantoj, grandeco de envenanta utila ŝarĝo, nombro da envenantaj mesaĝoj.
  • Dokumentu la rimedpostulojn por via servo. Ekzemple: nombro da diligentaj virtualaj maŝinaj petskriboj, nombro da Spanner-okazoj, specialeca aparataro kiel GPU aŭ TPU.
  • Dokumentaj rimedlimoj: rimeda tipo, regiono, ktp.
  • Dokumentu kvotlimigojn por krei novajn rimedojn. Ekzemple, limigi la nombron da GCE-API-petoj se vi uzas la API por krei novajn okazojn.
  • Konsideru fari provojn pri ŝarĝo por analizi rendimentan degeneron.

Tio estas ĉio. Ĝis revido en klaso!

fonto: www.habr.com

Aldoni komenton