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

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

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

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

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

Оқиғалар

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Шақыру бойынша СРЕ көптеген құралдарды пайдаланады

Ішкі:

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

Сыртқы:

  • PagerDuty: ескертулер
  • Slack: Бұл жерде 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

DDoS қорғауы бар сайттар үшін сенімді хостинг, VPS VDS серверлерін сатып алыңыз 🔥 DDoS қорғанысы, VPS VDS серверлері бар сенімді веб-сайт хостингін сатып алыңыз | ProHoster