Мен бір аптаны SRE инженері интерн ретінде қалай өткіздім. Міндет инженер-бағдарламашы көзімен

Мен бір аптаны SRE инженері интерн ретінде қалай өткіздім. Міндет инженер-бағдарламашы көзімен

SRE инженері – стажер

Алдымен өзімді таныстырып өтейін. мен - @tristan.read, топтағы инженер Монитор::Денсаулық GitLab. Өткен аптада мен біздің шақыру бойынша SRE инженерлерінің бірімен тәжірибеден өту құрметіне ие болдым. Мақсаты – кезекшінің оқыс оқиғаларға күнделікті қалай әрекет ететінін бақылап, жұмыста шынайы өмірлік тәжірибе жинақтау. Біз инженерлеріміздің пайдаланушы қажеттіліктерін жақсырақ түсінгенін қалаймыз функциялары Монитор::Денсаулық.

Мен бір апта бойы барлық жерде SRE инженерінің соңынан еруге тура келді. Яғни, мен тапсыру кезінде болдым, сол хабарландыру арналарын бақылап отырдым және оқиғалар болған жағдайда және қашан болған жағдайда жауап бердім.

Оқиғалар

Бір апта ішінде 2 оқиға болды.

1. Крипто-минер

Сәрсенбіде GitLab.com қолданудың секірісін көрді GitLab Runner'a, криптовалютаны өндіру үшін жүгірушінің минуттарын пайдалану әрекеттерінен туындаған. Оқиға жүгірушінің тапсырмаларын тоқтататын және онымен байланысты жоба мен есептік жазбаны жоятын бұзушылықтарды бейтараптандыру құралын пайдалану арқылы шешілді.

Егер бұл оқиға байқалмаса, автоматтандырылған құрал оны ұстап алар еді, бірақ бұл жағдайда SRE инженері бұзушылықты бірінші болып байқады. Оқиға тапсырмасы жасалды, бірақ ол туралы ақпарат жабық.

2. Canary және Main қолданбаларының өнімділігінің төмендеуі

Оқиға Gitlab.com сайтындағы канар мен негізгі веб-қосымшалардағы баяулаулар мен қателердің жиілігінің артуына байланысты болды. Бірнеше Apdex мәндері бұзылды.

Ашық оқиға тапсырмасы: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

Негізгі тұжырымдар

Міне, мен бір апта бойы кезекшілік кезінде біраз нәрсені білдім.

1. Ескертулер нормадан ауытқуларды анықтаған кезде өте пайдалы.

Ескертулерді бірнеше түрге бөлуге болады:

  • Белгілі бір шекті мәнге негізделген ескертулер, мысалы, «секундына 10 5xx қате орын алды».
  • «Белгілі бір уақытта сұраулардың жалпы көлемінің 5%-ына 10xx қателерінің жиілігі» сияқты шекті мән пайыздық мән болатын ескертулер.
  • "5-процентильдегі 90xx қателері" сияқты орташа тарихи деректерге негізделген ескертулер.

Жалпы айтқанда, 2 және 3 типтер кезекші ӨҚҚ үшін пайдалырақ, өйткені олар процесте нормадан ауытқуды анықтайды.

2. Көптеген ескертулер ешқашан оқиғаларға ұласпайды.

SR инженерлері ескертулердің тұрақты ағынымен айналысады, олардың көпшілігі шын мәнінде маңызды емес.

Неліктен ескертулеріңізді тек маңызды нәрселермен шектемеске? Дегенмен, бұл тәсілмен сіз үлкен зақымға қауіп төндіретін нақты мәселеге айналатын алғашқы белгілерді танымауыңыз мүмкін.

Шақыру бойынша SRE жұмысы қандай ескертулер шын мәнінде маңызды нәрсені көрсететінін және оларды күшейту және өңдеу қажет пе екенін анықтау болып табылады. Менің ойымша, бұл да ескертулердің икемсіздігіне байланысты: жоғарыда сипатталған жағдайға сәйкес ескертулерді конфигурациялаудың бірнеше деңгейлері немесе «ақылды» жолдары болғаны жақсы болар еді.

Мүмкіндік ұсынысы: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. Біздің кезекші СҚҚ көптеген құралдарды пайдаланады.

Ішкі:

  • GitLab инфражобасы: runbooks осында тұрады, ауысым/апта тапсырмалары, оқиғаға жауап беру тапсырмалары.
  • GitLab мәселелері: зерттеулер, шолулар және техникалық қызмет көрсету мәселелерде де бақыланады.
  • GitLab белгілері: автоматтандыру тапсырмалары боттар тапсырма әрекетін бақылау үшін пайдаланатын арнайы белгілер арқылы іске қосылады.

Сыртқы:

  • PagerDuty: ескертулер
  • Слайк: PagerDuty/AlertManager хабар ағыны осында өтеді. Ескертуді жабу немесе оқиғаға көшу сияқты әртүрлі тапсырмаларды орындау үшін қиғаш сызық пәрмендерімен біріктіру.
  • Графана: ұзақ мерзімді трендтерге назар аудара отырып, метриканың визуализациясы.
  • Кибана: визуализация/журнал іздеу, нақты оқиғаларды тереңірек зерттеу мүмкіндігін береді.
  • Масштабтау: Масштабтауда үнемі жұмыс істейтін «үздік бөлме» бар. Бұл SRE инженерлеріне бөлме жасап, қатысушыларды байланыстырмай құнды уақытты жоғалтпай оқиғаларды жылдам талқылауға мүмкіндік береді.

Және көптеген басқалар.

4. GitLab.com сайтын GitLab көмегімен бақылау бір ғана сәтсіздік нүктесі болып табылады

Егер GitLab.com қызметінде үлкен үзіліс болса, бұл мәселені шешу қабілетімізге әсер еткенін қаламаймыз. Оны GitLab.com сайтын басқару үшін екінші GitLab данасын іске қосу арқылы тоқтатуға болады. Шын мәнінде, бұл біз үшін жұмыс істейді: https://ops.gitlab.net/.

5. GitLab жүйесіне қосуды қарастыратын бірнеше мүмкіндіктер

  • Көп пайдаланушы тапсырмасын өңдеу, Google Docs-қа ұқсас. Бұл оқиға кезіндегі инциденттер бойынша тапсырмаларды орындауға, сондай-ақ есеп беру тапсырмаларына көмектеседі. Екі жағдайда да бірнеше қатысушыға нақты уақытта бірдеңе қосу қажет болуы мүмкін.
  • Тапсырмалар үшін қосымша вебхуктар. GitLab жұмыс үрдісінің әртүрлі қадамдарын ішінен іске қосу мүмкіндігі Slack интеграцияларына деген сеніміңізді азайтуға көмектеседі. Мысалы, GitLab шығарылымындағы қиғаш сызық пәрмені арқылы PagerDuty жүйесінде ескертуге рұқсат беру мүмкіндігі.
    қорытынды

SRE инженерлері көптеген қиындықтармен қиынға соғады. Осы мәселелерді шешетін GitLab өнімдерін көбірек көрсеңіз тамаша болар еді. Біз жоғарыда аталған жұмыс процестерін жеңілдететін өнімге кейбір толықтырулар әзірлеу үстіндеміз. Толық ақпаратты мына жерден алуға болады Ops Product Vision бөлімі.

Біз осы тамаша мүмкіндіктердің барлығын біріктіру үшін 2020 жылы топты кеңейтеміз. Қызық болса, тексеріңіз бос орындар, және кез келген сұрақтар бойынша біздің командадағы кез келген адамға хабарласыңыз.

Ақпарат көзі: www.habr.com

пікір қалдыру