ProHoster > Blog > Administrim > Si kalova një javë si praktikant i SRE-inxhinierit. Ndërrimi me sytë e një inxhinieri të softuerit.

Si kalova një javë si praktikant i SRE-inxhinierit. Ndërrimi me sytë e një inxhinieri të softuerit.

Si kalova një javë si praktikant i SRE-inxhinierit. Ndërrimi me sytë e një inxhinieri të softuerit.

Inxhinier SRE - stazhier

Për të filluar, lejoni të prezantohem. Unë jam @tristan.read, inxhinier frontend në grupin Monitor::Health të GitLab. Javën e kaluar pata nderin të jem stazhier pranë njërit prej inxhinierëve tanë SRE. Qëllimi ishte vëzhgimi i përditshëm se si reagojnë dezhurnet ndaj incidenteve dhe marrja e përvojës reale të punës. Ne dëshirojmë që inxhinierët tanë të kuptojnë më mirë nevojat e përdoruesve funksione Monitor::Health.

Më duhej të ndihesha pas inxhinierit SRE për një javë. Do të thotë se isha prezent në kalimin e dezhurnet, vëzhgova kanalet e paralajmërimit dhe reagova ndaj incidenteve, nëse dhe kur ndodhnin.

Incidente

Në javë ndodhi 2 incidente.

1. Minatori i kriptomonedhave

TĂ« mĂ«rkurĂ«n, nĂ« GitLab.com u regjistrua njĂ« rritje nĂ« pĂ«rdorim GitLab RunnertĂ« tij, e krijuar nga pĂ«rpjekjet pĂ«r tĂ« pĂ«rdorur minutat e runner pĂ«r minimin e kriptovalutave. Çështja u zgjidh me ndihmĂ«n e njĂ« mjeti tĂ« brendshĂ«m pĂ«r neutralizimin e shkeljeve, i cili ndalon detyrat e runner dhe fshin projektin dhe llogarinĂ« e lidhura.

Po të mos e vinin re këtë ngjarje, një mjet automatizimi do ta kishte kapur atë, por në këtë rast inxhinieri SRE e vuri re shkeljen i pari. U krijua një detyrë për incidentin, megjithatë informacioni rreth tij është i mbyllur.

2. Dëmtimi i performancës së aplikacioneve Canary dhe Main

Incidenti u shkaktua nga ngadalësimet dhe rritja e frekuencës së gabimeve në aplikacionet web canary dhe main në Gitlab.com. U shkaktuan disa vlera të shkeljes së Apdex.

Detyrë e hapur për incidentin: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

Pikat kryesore

Ja disa pika që kam kuptuar gjatë javës së dezhurnet.

1. Paralajmërimet janë më të dobishme kur kapin devijime nga norma.

Paralajmërimet mund të ndahen në disa lloje:

  • ParalajmĂ«rimet qĂ« bazohen nĂ« njĂ« prag tĂ« caktuar, si 'ndodhi 10 gabime 5xx nĂ« sekondĂ«'.
  • ParalajmĂ«rimet, ku pragu Ă«shtĂ« njĂ« vlerĂ« pĂ«rqindjeje si 'frekuenca e gabimeve 5xx nĂ« 10% tĂ« numrit total tĂ« kĂ«rkesave nĂ« njĂ« kohĂ« tĂ« caktuar'.
  • ParalajmĂ«rimet qĂ« bazohen nĂ« mesataren historike si 'gabime 5xx nĂ« percentilin e 90-tĂ«'.

Në përgjithësi, tipi 2 dhe 3 janë më të dobishme për SRE-të e dezhurnet, pasi zbulojnë devijimet nga norma gjatë procesit.

2. Shumë paralajmërime nuk e arrijnë nivelin e incidentit

Inxhinierët SRE përballen me një rrjedhë të vazhdueshme njoftimesh, shumë prej të cilave në të vërtetë nuk janë kritike.

Pse të mos i kufizoni njoftimet vetëm në ato që janë me të vërtetë të rëndësishme? Megjithatë, me një qasje të tillë, mund të mos identifikoni simptomat e hershme që do të rriten si një borë, duke u bërë një problem real që paraqet rrezik të madh.

Detyra e dezhurnit SRE është të përcaktojë se cilat njoftime flasin me të vërtetë për diçka serioze dhe nëse ato duhet të eskalohen dhe të fillojë një hetim. Dyshoj se kjo është shkaktuar nga infleksibiliteti i njoftimeve: do të ishte më mirë nëse do të përdoreshin disa nivele ose mënyra "inteligjente" për të vendosur njoftimet në përputhje me situatën e përshkruar më lart.

Propozimi për funksionin: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. Dezhurnit tanë SRE përdorin shumë mjete

TĂ« brendshme:

  • Projekti infra GitLab: kĂ«tu jetojnĂ« Runbook-at, kalimet e dezhurnit pĂ«r ndĂ«rrime/javĂ«, detyrat pĂ«r pĂ«rgjigjen ndaj incidenteve.
  • Çështjet e GitLab: hetimet, analizat dhe menaxhimi gjithashtu ndiqen nĂ« detyra.
  • Etiketat e GitLab: detyrat e automatizimit fillojnĂ« sipas etiketimeve tĂ« caktuara, pĂ«r tĂ« cilat robotĂ«t ndjekin aktivitetin e detyrave.

TĂ« jashtme:

  • PagerDuty: njoftime
  • Slack: kĂ«tu dĂ«rgohet rrjedha e mesazheve tĂ« PagerDuty/AlertManager. Integrimi me komanda slah pĂ«r tĂ« kryer njĂ« gamĂ« tĂ« gjerĂ« detyrash, siç janĂ«: mbyllja e njoftimit ose eskalimi nĂ« njĂ« incident.
  • Grafana: vizualizimi i mĂ©trikave me fokus nĂ« tendencat afatgjata.
  • Kibana: ofron vizualizim/kĂ«rkim nĂ« log, mundĂ«sinĂ« pĂ«r tĂ« thelluar nĂ« ngjarje tĂ« caktuara.
  • Zoom: ka njĂ« "dhomĂ« diskutimi" qĂ« funksionon vazhdimisht nĂ« Zoom. Kjo lejon inxhinierĂ«t SRE tĂ« diskutojnĂ« shpejt ngjarjet, pa humbur kohĂ« nĂ« krijimin e njĂ« dhome dhe dĂ«rgimin e linkeve pjesmarrĂ«sve.

Dhe shumë, shumë më tepër.

4. Monitorimi i GitLab.com me GitLab është një pikë e vetme dështimi

Nëse ndodh një dështim i madh shërbimesh në GitLab.com, ne nuk do të dëshironim që kjo të ndikonte në aftësinë tonë për të zgjidhur problemin. Ajo mund të menaxhohet duke nisur një instancë të dytë të GitLab për të menaxhuar GitLab.com. Në të vërtetë, kjo tashmë funksionon për ne: https://ops.gitlab.net/.

5. Disa funksione që duhet marrë në konsideratë për tu shtuar në GitLab

  • Redaktimi i shumĂ« pĂ«rdoruesve tĂ« detyrave, e ngjashĂ«m me Google Docs. Kjo do tĂ« ndihmonte nĂ« detyrat pĂ«r incidentet gjatĂ« ngjarjeve, si dhe nĂ« detyrat e analizĂ«s. NĂ« tĂ« dyja rastet, disa pjesĂ«marrĂ«sve do t'u nevojitej tĂ« shtonin diçka nĂ« kohĂ« reale.
  • MĂ« shumĂ« webhooks pĂ«r detyra. MundĂ«sia pĂ«r tĂ« nisur hapa tĂ« ndryshĂ«m tĂ« punĂ«s nĂ« GitLab nga brenda do tĂ« ndihmonte nĂ« zvogĂ«limin e varĂ«sisĂ« nga integrimet e Slack. PĂ«r shembull, mundĂ«sia pĂ«r tĂ« aktivizuar njoftimin nĂ« PagerDuty pĂ«rmes komandĂ«s me slash nĂ« detyrĂ«n GitLab.
    PĂ«rfundim

Inxhinierët SRE përballen me shumë vështirësi. Do të ishte e shkëlqyer të shihnim më shumë produkte të GitLab që adresojnë këto probleme. Ne already po punojmë në disa shtesa në produktin që do të lehtësojnë proceset e punës të përmendura më parë. Detajet janë të disponueshme në seksionin Ops Product Vision.

Në vitin 2020 ne po zgjeronim ekipin për të mbledhur të gjitha këto funksionalitete të shkëlqyera. Nëse jeni të interesuar, ju lutemi shikoni vakancat, dhe mos hezitoni të kontaktoni ndonjë nga ekipi ynë për çdo pyetje.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster