СРЕ инженер - приправник
Прво, да се претставам. јас - , преден инженер во групата GitLab. Минатата недела имав чест да се стажирам кај еден од нашите инженери на SRE на повик. Целта беше да се набљудува како дежурниот службеник реагирал на инциденти на дневна основа и да се стекне со реално искуство на работното место. Ние би сакале нашите инженери подобро да ги разберат потребите на корисниците Монитор::Здравје.
Морав да го следам инженерот SRE насекаде една недела. Односно, јас бев присутен на примопредавањето, ги следев истите канали за алармирање и реагирав на инциденти доколку и кога се случат.
Инциденти
Во рок од една недела имаше 2 инциденти.
1. Криптоминер
GitLab.com забележа скок во користењето во средата 'а, предизвикана од обиди да се искористат минутите на тркачот за рудирање на криптовалути. Инцидентот беше решен со користење на нашата сопствена алатка за неутрализација на прекршоци, која ги запира задачите на тркачот и ги брише проектот и сметката поврзани со него.
Доколку овој настан не беше забележан, автоматизирана алатка ќе го фатеше, но во овој случај, инженерот на SRE прв го забележа прекршувањето. Создадена е задача за инцидент, но информациите за неа се затворени.
2. Деградација на перформансите на Канарските и Главните апликации
Инцидентот беше предизвикан од забавување и зголемена фреквенција на грешки во канаринските и главните веб-апликации на Gitlab.com. Беа прекршени неколку вредности на Apdex.
Задача за отворен инцидент:
Клучни наоди
Еве неколку работи што ги научив во текот на мојата недела на должност.
1. Алармите се најкорисни кога се откриваат отстапувања од нормата.
Предупредувањата можат да се поделат на неколку видови:
- Предупредувања засновани на одредена праг вредност, како што е „се појавија 10 5xx грешки во секунда“.
- Предупредувања во кои прагот е процентуална вредност како „фреквенција на 5xx грешки на 10% од вкупниот обем на барања во дадено време“.
- Предупредувања засновани на историски просек, како што се „5xx грешки на 90 перцентил“.
Општо земено, типовите 2 и 3 се покорисни за СРЕ на должност, бидејќи тие откриваат отстапувања од нормата во процесот.
2. Многу предупредувања никогаш не ескалираат до инциденти.
SR инженерите се справуваат со постојан прилив на предупредувања, од кои многу не се всушност критични.
Па зошто да не ги ограничите вашите предупредувања само на навистина важните? Меѓутоа, со овој пристап, можеби нема да ги препознаете раните симптоми на тоа што снежните топки ќе станат вистински проблем што се заканува голема штета.
Работата на SRE на повик е да утврди кои предупредувања всушност укажуваат на нешто сериозно и дали треба да се ескалираат и да почнат да се средуваат. Се сомневам дека ова се должи и на нефлексибилноста на предупредувањата: би било подобро да има неколку нивоа или „паметни“ начини за конфигурирање на предупредувањата во согласност со ситуацијата опишана погоре.
Предлог одлика:
3. Нашите дежурни SRE користат многу алатки.
Внатрешна:
- Инфра проект на GitLab: тековните книги живеат овде, задачи за смена/недела, задачи за одговор на инциденти.
- Проблеми со GitLab: Истрагите, прегледите и одржувањето исто така се следат во проблеми.
- Етикети на GitLab: задачите за автоматизација се стартуваат врз основа на специфични ознаки, кои ботови ги користат за следење на активноста на задачите.
Надворешен:
- PagerDuty: Известувања
- Slack: Протокот на пораки на PagerDuty/AlertManager оди овде. Интеграција со команди со коса црта за извршување на различни задачи, како што е затворање на предупредување или ескалирање на инцидент.
- Графана: визуелизација на метрика со фокус на долгорочните трендови.
- Kibana: Дава визуелизација/пребарување на дневници, способност да се копа подлабоко во конкретни настани.
- Зумирање: Во Зумирање има постојано работи „соба за налет“. Ова им овозможува на инженерите на SRE брзо да разговараат за настаните без да губат драгоцено време за создавање просторија и поврзување на учесниците.
И многу многу други.
4. Следењето на GitLab.com со GitLab е единствена точка на неуспех
Ако GitLab.com доживее голем прекин на услугата, не сакаме тоа да влијае на нашата способност да го решиме проблемот. Може да се запре со лансирање на втор пример на GitLab за управување со GitLab.com. Всушност, ова веќе функционира за нас: .
5. Неколку функции што треба да се разгледаат да се додадат во GitLab
- , слично на Google Docs. Ова би помогнало со задачи за инциденти за време на настан, како и за задачи за дебрифинг. Во двата случаи, неколку учесници можеби ќе треба да додадат нешто во реално време.
- Повеќе веб-куки за задачи. Способноста да се извршуваат различни чекори на работниот тек на GitLab одвнатре ќе ви помогне да ја намалите зависноста од интеграциите на Slack. На пример, можноста да се дозволи предупредување во PagerDuty преку команда со коса црта во проблем со GitLab.
Заклучок
Инженерите на SRE имаат тешко време со многу сложености. Би било одлично да видите повеќе производи на GitLab кои ги решаваат овие проблеми. Веќе работиме на некои додатоци на производот што ќе ги олеснат работните текови споменати погоре. Детали достапни на .
Го прошируваме тимот во 2020 година за да ги собереме сите овие одлични карактеристики. Доколку сте заинтересирани, проверете , и слободно контактирајте со кој било од нашиот тим со какви било прашања.
Извор: www.habr.com
