Size: a a a

DevOps Jobs - работа и аналитика

2020 October 16

D

DevOps Help Bot in DevOps Jobs - работа и аналитика
@nkritsky here it is.
User commands:
- /man - send list of commands to chat
- /coc - send code of conduct to user
- /jobs - send rules of publishing job opportunities and cv
- /ad - send rules of publishing advertising
- /chats - send list of friendly chats
- /events - send list of events to user
- /starter - send starter kit to user
- /middle - send middle kit to user
- /tasks - send user pack of DevOps tasks
- /course - send to user list list of courses
- /cert - send user list of certification tips & tricks
- /relocate - send user list of relocate chats and channels
- /report - forward replied message to admin chat and send link of replied message for fast-navigation
- /summon - summon HR to DevOps Jobs chat (works on replied message)
источник

GG

George Gaál in DevOps Jobs - работа и аналитика
George
Для сла метрики стандартные - сколько не работал сервис с точки зрения клиентов. Там самые простые (если не погружатся в тонкости). То есть подсчёт по времени 50х ошибок (грубо говоря).

Так внутри конечно метрик больше. RPS по базам, по REST/HTTP запросам. Сколько каждый сервис тратил времени на запрос к базе, сколько и какой размер пакетов передавался, сколько и каких пкетов в итоге передано/получено от клиентов. Ну и базовые загруженность сетевых интерфейсов (дропы, pps, bw), диски (iops и т.п), ОЗУ, CPU. Стандартно довольно. Всё сведено на борду для саппорта 1/2 линии.
Если инциденты уровня "ой отвалился в 5 утра сервер от кластера немного поштормило (+n к времени запроса к базе например), но всё перебалансилось и стало хорошо" - решаются в штатное время. Уровня "АААА!!! ТУТ НИЧЕГО НЕ РАБОТАЕ ААААА!!!" - тогда уже могут текущего дежурного "дёвопса" поднять. Класска опять же.

По самим метрикам проблем нет совершенно. Объясняешь лиду нужной команды почему она нужна, какие значения должны выдаватся и частота. Дальше они делают, мы проверяем удовлетворила ли (потому что тут QA уже мало помогут и через них дольше).

Постмортеры довольно скучные так-то. Померло железо, но софт нормально не обработал это и "завис" продолжая отвечать на лайвнесс пробу. Из-за этого шедуллер не переназначил такой под на другую ноду. Что привео к n% деградации сервиса (те самы 50х-и по сути). Решение - правильная проба и баг в разработку.

Так что ничего прям уровня "мы проебали базу гитлаба" поведать не могу.
тут нюанс
источник

GG

George Gaál in DevOps Jobs - работа и аналитика
технические метрики НИЧЕГО НЕ ГОВОРЯТ о том страдают ли реально пользователи
источник

D

DevOps Help Bot in DevOps Jobs - работа и аналитика
@nkritsky here is your starter kit.
источник

GG

George Gaál in DevOps Jobs - работа и аналитика
скажем, у тебя отвалился бекенд, но он отвечает 200ками
источник

ДА

Дмитрий Андреев... in DevOps Jobs - работа и аналитика
George Gaál
I speak from my heart and it is good enough
I don't understand your barbarian language
источник

GG

George Gaál in DevOps Jobs - работа и аналитика
или отвалилась интеграция с внешним подрядчиком
источник

ДА

Дмитрий Андреев... in DevOps Jobs - работа и аналитика
Английский уровне C -100 (у меня)
источник

GG

George Gaál in DevOps Jobs - работа и аналитика
или перемена АПИ
источник

GG

George Gaál in DevOps Jobs - работа и аналитика
бизнес процесс не фурыкен
источник

СХ

Старый Хрыч... in DevOps Jobs - работа и аналитика
George Gaál
технические метрики НИЧЕГО НЕ ГОВОРЯТ о том страдают ли реально пользователи
на пользователей чаще всего всем плевать увы, п ока платежи проходят
источник

G

George in DevOps Jobs - работа и аналитика
George Gaál
скажем, у тебя отвалился бекенд, но он отвечает 200ками
Всё так и есть да. В реальности метрика "хорошо ли пользователям" выясняется по чатикам/звонкам.
Ситуация "ну мы тут и нахерачили, это же вообще не работает" клентами может даже не быть замечена. А какая-нибудь несчастная 50х из-за таймаута сетевого раздута до "ААА!!! НИЧЕГОНЕРАБОТАЕТ!!!".

Но мы страемся всё же рабоать по техническим метрикам. То есть дашбордик для саппорта выводит "среднее по больнице" состояние сервисов. И если они видят что поехали куча 503/504 или вырасли задержки в базам до секунд, то не ждут звонков гневных, а эскалируют до 2-х (те согласно инструкциям смотрят и что могут делают), а те до нас в случае фейла. Благо СЛА довольно мягкие у нас. Всё же не высокочастотный трейдинг там.
источник

GG

George Gaál in DevOps Jobs - работа и аналитика
ну да
источник

ИК

Иван Коломиец... in DevOps Jobs - работа и аналитика
George
Для сла метрики стандартные - сколько не работал сервис с точки зрения клиентов. Там самые простые (если не погружатся в тонкости). То есть подсчёт по времени 50х ошибок (грубо говоря).

Так внутри конечно метрик больше. RPS по базам, по REST/HTTP запросам. Сколько каждый сервис тратил времени на запрос к базе, сколько и какой размер пакетов передавался, сколько и каких пкетов в итоге передано/получено от клиентов. Ну и базовые загруженность сетевых интерфейсов (дропы, pps, bw), диски (iops и т.п), ОЗУ, CPU. Стандартно довольно. Всё сведено на борду для саппорта 1/2 линии.
Если инциденты уровня "ой отвалился в 5 утра сервер от кластера немного поштормило (+n к времени запроса к базе например), но всё перебалансилось и стало хорошо" - решаются в штатное время. Уровня "АААА!!! ТУТ НИЧЕГО НЕ РАБОТАЕ ААААА!!!" - тогда уже могут текущего дежурного "дёвопса" поднять. Класска опять же.

По самим метрикам проблем нет совершенно. Объясняешь лиду нужной команды почему она нужна, какие значения должны выдаватся и частота. Дальше они делают, мы проверяем удовлетворила ли (потому что тут QA уже мало помогут и через них дольше).

Постмортеры довольно скучные так-то. Померло железо, но софт нормально не обработал это и "завис" продолжая отвечать на лайвнесс пробу. Из-за этого шедуллер не переназначил такой под на другую ноду. Что привео к n% деградации сервиса (те самы 50х-и по сути). Решение - правильная проба и баг в разработку.

Так что ничего прям уровня "мы проебали базу гитлаба" поведать не могу.
ты описал стандартный мониторинг, у вас есть механизмы контроля надежности сервиса? к примеру если было в месяце больше ста 500к в логах - работа над фичами останавливается, занимаемся только ими?
источник

GG

George Gaál in DevOps Jobs - работа и аналитика
т.е. здоровье технический метрик - это НЕОБХОДИМОЕ, но НЕДОСТАТОЧНОЕ условие для того, чтобы КЛИЕНТ не страдал
источник

GG

George Gaál in DevOps Jobs - работа и аналитика
на самом деле интереснее даже то, что трешхолды для тех же 500-к у вас могут быть неверные
источник

G

George in DevOps Jobs - работа и аналитика
Старый Хрыч
на пользователей чаще всего всем плевать увы, п ока платежи проходят
Ну это ты совсем сгустил краски. Не плевать конечно. Компания коммерческая и рынок конкурентен. Но да, работа с клиентами слабое место к сожалению. Пробовали всякие метрики собирать на их стороне, но практика показывает что они удобны SEO каким-нибудь, но нам не упёрлись чаще всего.
источник

GG

George Gaál in DevOps Jobs - работа и аналитика
т.е. вы тратите силы на борьбу за то, чтобы технические метрики были идеальны, хотя усилия надо было бы направить в другое место
источник

GG

George Gaál in DevOps Jobs - работа и аналитика
это как с кубокластерами
источник

GG

George Gaál in DevOps Jobs - работа и аналитика
половина нод не работает - кластер дальше работает и сервит запросы. Нужно чинить ? Ну, э, да, но не с первым приоритетом
источник