SRE-інжынер - стажор
Для пачатку дазвольце прадставіцца. Я - , фронтэнд-інжынер у групе GitLab'а. На мінулым тыдні мне выпаў гонар пабыць стажорам у аднаго з нашых дзяжурных SRE-інжынераў. Мэтай было штодзённае назіранне за тым, як дзяжурны рэагуе на інцыдэнты, і атрыманне рэальнага досведу працы. Нам бы жадалася, каб нашы інжынеры лепш разумелі запатрабаванні карыстачоў Monitor::Health.
Мне трэба было тыдзень усюды ісці за SRE-інжынерам. Гэта значыць, я прысутнічаў на перадачы дзяжурства, назіраў за тымі ж каналамі абвестак і рэагаваў на інцыдэнты, калі і калі такія мелі месца.
Інцыдэнты
За тыдзень адбыліся 2 інцыдэнты.
1. Крыптамайнер
У сераду на GitLab.com зафіксавалі скачок у выкарыстанні 'а, выкліканы спробамі выкарыстаць хвіліны runner'а для майнінгу криптовалюты. З інцыдэнтам разабраліся з дапамогай уласнай прылады нейтралізацыі парушэнняў, які спыняе задачы runner'а і выдаляе злучаныя з ім праект і акаўнт.
Калі б гэтую падзею не заўважылі, яе адлавіла б аўтаматызаваная прылада, але ў гэтым выпадку SRE-інжынер заўважыў парушэнне першым. Была створана задача па інцыдэнце, аднак інфармацыя па ёй зачынена.
2. Дэградацыя прадукцыйнасці прыкладанняў Canary і Main
Інцыдэнт справакавалі запаволенні і ўзрослая частата памылак у canary і main вэб-прыкладаннях на Gitlab.com. Было парушана некалькі значэнняў Apdex.
Адкрытая задача па інцыдэнце:
ключавыя высновы
Вось некалькі момантаў, якія я ўразумеў за тыдзень дзяжурства.
1. Абвесткі найбольш карысныя, калі засякаюць адхіленні ад нормы.
Абвесткі можна падзяліць на некалькі тыпаў:
- Абвесткі, заснаваныя на вызначаным парогавым значэнні, тыпу «адбылося 10 5хх памылак у секунду».
- Абвесткі, у якіх парог - гэта працэнтнае значэнне тыпу "частата 5хх памылак на 10% агульнага аб'ёму запытаў у зададзены час".
- Абвесткі, заснаваныя на гістарычным сярэднім значэнні тыпу "5хх памылак у 90-й працэнты".
Калі казаць увогуле, то 2-й і 3-й тыпы карысней для дзяжурных SRE, паколькі выкрываюць адхіленні ад нормы ў працэсе.
2. Многія абвесткі так і не эскалююцца да інцыдэнтаў
SR-інжынеры маюць справу з пастаянным патокам абвестак, многія з якіх на самой справе не крытычныя.
Дык чаму б не абмежаваць абвесткі толькі сапраўды важнымі? З такім падыходам, аднак, можна не распазнаць раннія сімптомы таго, што вырасце, як снежны ком, у рэальную праблему, якая пагражае буйным уронам.
Задача дзяжурнага SRE у тым і складаецца, каб вызначаць, якія абвесткі сапраўды кажуць пра нешта сур'ёзнае, і ці трэба іх эскалаваць і пачынаць разбірацца. Падазраю, гэта выклікана яшчэ і нягнуткасцю абвестак: было б лепш, калі б увялі некалькі ўзроўняў ці "разумныя" спосабы налады абвестак у адпаведнасці з апісанай вышэй сітуацыяй.
Прапанова па функцыі:
3. Нашы дзяжурныя SRE выкарыстоўваюць шмат інструментаў
унутраныя:
- GitLab infra project: тут жывуць Runbook'і, перадачы дзяжурства на змену/тыдзень, задачы па адказах на інцыдэнты.
- GitLab issues: расследаванне, разборы і абслугоўванне таксама адсочваюцца ў задачах.
- GitLab labels: задачы аўтаматызацыі запускаюцца па вызначаных пазнаках, па якіх робаты адсочваюць актыўнасць задач.
Вонкавыя:
- PagerDuty: абвесткі
- Slack: сюды накіроўваецца паток паведамленняў PagerDuty/AlertManager. Інтэграцыя са слэш-камандамі для выканання разнастайных задач, як то: закрыць апавяшчэнне або эскалаваць да інцыдэнту.
- Grafana: візуалізацыя метрык з фокусам на доўгатэрміновых трэндах.
- Kibana: дае візуалізацыю / пошук у часопісе, магчымасць капаць глыбей у пэўных падзеях.
- Zoom: ёсць пастаянна працуючая "пакой абмеркавання" у Zoom. Гэта дазваляе SRE-інжынерам хутка абмяркоўваць падзеі, не марнуючы каштоўны час на стварэнне пакоя і спасылкі ўдзельнікам.
І шматлікае, шматлікае іншае.
4. Маніторынг GitLab.com пры дапамозе GitLab - гэта адзіная кропка адмовы
Калі на GitLab.com адбудзецца буйная адмова сэрвісаў, нам бы не жадалася, каб гэта паўплывала на нашу здольнасць вырашыць праблему. Яе можна купіраваць, запусціўшы другі інстанс GitLab для ўпарўлення GitLab.com. Насамрэч гэта ўжо працуе ў нас: .
5. Некалькі функцый, якія варта разгледзець да дадання ў GitLab
- , аналагічнае Google Docs. Гэта дапамагло б у задачах па інцыдэнтах падчас падзеі, а таксама ў задачах па разборах. У абодвух выпадках адразу некалькім удзельнікам можа спатрэбіцца дадаць што-небудзь у рэальным часе.
- Больш вэбхукоў для задач. Магчымасць запускаць розныя крокі працоўнага працэсу GitLab знутры дапаможа зменшыць залежнасць ад інтэграцый Slack. Напрыклад, магчымасць дазволіць апавяшчэнне ў PagerDuty праз слэш-каманду ў задачы GitLab.
Заключэнне
SRE-інжынерам даводзіцца нялёгка са мноствам складанасцяў. Было б выдатна ўбачыць больш прадуктаў GitLab у вырашэнні гэтых праблем. Мы ўжо працуем над некаторымі даданнямі да прадукта, якія палегчаць згаданыя вышэй працоўныя працэсы. Дэталі даступныя ў .
У 2020 годзе мы пашыраем каманду, каб сабраць усе гэтыя цудоўныя функцыі. Калі цікава, азнаёмцеся, калі ласка, з , і не саромейцеся звязвацца з кім-небудзь з нашай каманды па любых пытаннях.
Крыніца: habr.com