Comments 16
Эх алерты ненавижу всей душой. Самое страшное в них, Фиш пойми что они значат и куда эскалировать, как настраивать ( потому что разрабы тоже не понимают что им надо часто) но приходится терпеть, тк разрабатываем систему мониторинга((((
Классно что тут получилось такое победить
Ох, знакомая боль 😅 У меня раньше тоже каждый алерт был как загадка на «угадай сервис по намёку». В итоге понял, что без runbook-ов и нормальной фильтрации это чисто игра в рулетку.
решение с дежурствами и ранбуками правильные и подходящие в маленьких компаниях-командах. начинайте думать о построении команды поддержки с ровнями L1-L3 в долгосрок и ростом без этого никуда. Дежурства линейных работников на длинной дистанции - плохой путь, начнется рано или поздно проблема с тем чтобы найти ответственного
Полностью согласен. Я и писал скорее из перспективы небольшой команды, где приходится совмещать роли DevOps/SRE и первой линии. Runbook-и и грамотный on-call сильно спасают, пока не выросли до масштаба с полноценной поддержкой.
А дальше уже логично строить отдельный саппорт и разгружать инженеров, иначе, как вы и сказали, дежурства линейных специалистов начинают работать в минус.
Дочитал до спасительного ранбука и.. сразу приходит в голову следующий этап - автоматизировать его самого. Или уже? Тогда вообще "спи спокойно, дорогой товарищ, мы (авто-скрипты по фиксу проблем) за тебя отомстим!" 😎
Я не совсем понял, вы дежурите за спасибо, или за отдельную денежку, или это часть вашего контракта?
У нас была такая практика, что дежурство это почетная обязанность, к которой допускали только самых опытных разработчиков, при этом никак не мотивируя деньгами. Желающие были, но не очень много. Но вот когда внедрили оплату, то ситуация поменялась в лучшую сторону.
Раньше дежурства у нас действительно были «за спасибо» просто часть обязанностей, без всякой компенсации. Сейчас подход поменяли: ночные срочные подъёмы всё ещё остаются обязанностью инженеров, но за это дают полноценный отгул (как оплачиваемый выходной) на следующий день. Это сильно сглаживает нагрузку: можно спокойно выспаться и восстановиться.
Если на работе могут позвонить ночью - то нужно увольняться с такой работы. Это лишнее напряжение для нервов и неспокойный сон. Что в следствии может привести к хронической бессонницы и тогда будет вообще ад. Сон не должен ассоциироваться со стрессом и решением проблем средь ночи. Если без этого нельзя - менять профессию. Хотя те кто давно в ИТ тех оно вымораживает по другим причинам.
Есть знакомый, отказался от оффера +30% к доходу на текущем месте, потому что предполагалось, что могут быть ночные звонки, а на текущем месте такого нет .Конечно респект работодателю, что явно осветили это момент при обсуждении условий , но спокойный сон - дорогое удовольствие, премия должна быть больше
Видимо я что-то желаю не так.
4-5к девайсов в пртг. 20к сенсоров. 0 ночного флуда/алертов. Разделяем инфру на: внутреннюю сеть, внешнюю сеть (город), винду, никсы, веб. Назначаем ответственных от каждой команды. Все. Дальше мне трава не расти, если у сетевиков что-то отвалилось, я алертов не получаю. Максимум могу зайти глянуть все дерево, чтобы понимать ситуацию, например, если один из гейтов рестартят или он упал.
Далее разделяем свою инфру на критично-некритично. Некритично - придет в 8 утра как факт. Все что не относится к моей инфре - мне не интересно получать.
В командах: Кто как сконфигал себе, то и получил. Хотите через хер, получайте флуд алертов свой сами и отвечайте за него сами.
А у вас какая-то проблема с бюрократией, а не мониторингом. Искать еще кого-то зачем-то и куда-то. Если не указано, кто за что отвечает, звоним своему лиду, кидаем эту палку ему, пусть сношается в десна сам. Не найдет, утром будут его проблемы, если какой-то сервис будет и дальше лежать. Понапридумывали сами себе головной боли какой-то.
Я уже промолчу, что если дежурства не описаны нормально, кто и что должен делать, до скольки дежурит и еще и за спасибо это делает, включается ДНД и спится дальше. В моем кодексе указано: +20% от месячной ЗП за каждую неделю дежурства, плюс оплата по факту за проделанную работу (1.5-2.5х множитель или то, на сколько сами договоритесь. Я например за некоторые поломки могу запросить и 3х, и 5х в час)
Ситуации разные и подходы разные. Если я правильно осознал мысль автора, то пару лет назад он, как и вся его команда, были в начале пути. Разработка написала, девопсы как всегда в условиях экономии времени выкатили все в прод. А дальше оказалось, что сервис ещё и поддерживать надо (внезапно). Выглядит как типичная проблема маленьких команд, в которых нет разделения девопс и sre. По тексту меня смутило, что sre позиционирует себя первой линией поддержки, так точно не должно быть. Первая линия - это про перезагрузите сервис, или там ребутните сервак. Если не помогло, то вторая линия, ноды, поды, накинуть ресурсов и так далее. Дальше третья линия, где максимально скиловый инженер от девопс и разработка идут смотреть, почему при рабочей инфраструктуре разваливается сервис. Опять же, по описанию автора, команда вроде плюс-минус большая, если по инциденту поднимают толпу людей. В целом описание про становление нормальной поддержки, взросление и наконец использование best practices
Сколько не собеседовался в принципе на SRE - ни одна компания не могла внятно обьяснить, что за роль и что делать. Обычно сопли по стенам мазались только и пространный обьяснения были. Я бы подумал, что со мной что-то не так, но общался со знакомым - такая же петрушка. (Не самая релевантная выборка, понимаю. Вполне себе систематическая ошибка выжившего)
И да. Обычно все имели он-кол и как раз чуть ли не Л1. Но с громким названием. (Ну как и девопс - в 99% просто админ)
Л1 не обязательно даже дергать что-то будет, но как минимум будет понимать, кому звонить, зачем и почему. Если этого нет, получим, что бюрократический адок может твой же тикет вернуть по цепочке тебе же. И начнется все заново.
Когда еще кто-то отвечает за крайне минимальный стек. Возьмем пример админство. Если бэкапами занимается одна команда, стораджами другая, виндой третья, серваками четвертая, бэкап стораджами пятая - блджаж, удачи по быстрому найти, почему бэкап не прошел. А если это случилось во время ченджа ночного, когда тебе нужен срочный бэкап.. Начинаем опять заново, неделю-две планирования окна, поиск свободного времени у работников (а то ишь чаво придумали, трахаются там небось с женщинами после работы). Каждый успешно будет показывать пальцем, как в мемасе по чек-пуков (человеков-пауков). Столько пространства нихрена не делать, ходить с busy man look между кабтнетами и опенспейсами и абьюзить систему делегации. А если в команды добавить всяких сидящих по 10-20 лет на одной позиции.. то субъективно начнется пииииии...
...Ложусь спать дальше ? У вас дежурный спать может ? Прикольно...
Как я перестал бояться алертов и полюбил дежурства