All streams
Search
Write a publication
Pull to refresh

Comments 16

Эх алерты ненавижу всей душой. Самое страшное в них, Фиш пойми что они значат и куда эскалировать, как настраивать ( потому что разрабы тоже не понимают что им надо часто) но приходится терпеть, тк разрабатываем систему мониторинга((((

Классно что тут получилось такое победить

Ох, знакомая боль 😅 У меня раньше тоже каждый алерт был как загадка на «угадай сервис по намёку». В итоге понял, что без runbook-ов и нормальной фильтрации это чисто игра в рулетку.

У меня каждый сервис как раз известен, больше проблема что нужно искать чей это сервис и коммуницировать с человеком, про этом вообще не понимая что это за алерт, что он делает и зачем( а спрашивают так как будто я их и хотел сам настроить)

решение с дежурствами и ранбуками правильные и подходящие в маленьких компаниях-командах. начинайте думать о построении команды поддержки с ровнями L1-L3 в долгосрок и ростом без этого никуда. Дежурства линейных работников на длинной дистанции - плохой путь, начнется рано или поздно проблема с тем чтобы найти ответственного

Полностью согласен. Я и писал скорее из перспективы небольшой команды, где приходится совмещать роли DevOps/SRE и первой линии. Runbook-и и грамотный on-call сильно спасают, пока не выросли до масштаба с полноценной поддержкой.

А дальше уже логично строить отдельный саппорт и разгружать инженеров, иначе, как вы и сказали, дежурства линейных специалистов начинают работать в минус.

Дочитал до спасительного ранбука и.. сразу приходит в голову следующий этап - автоматизировать его самого. Или уже? Тогда вообще "спи спокойно, дорогой товарищ, мы (авто-скрипты по фиксу проблем) за тебя отомстим!" 😎

Точно ранбуки это первый шаг, а второй это превратить его в скрипт/автоматизацию. Мы тоже так пошли часть шагов из ранбука обернули в Ansible-скрипты, кое-где добавили auto-healing в Kubernetes. Теперь часть проблем чинится сама, а дежурный просто получает уведомление

Я не совсем понял, вы дежурите за спасибо, или за отдельную денежку, или это часть вашего контракта?

У нас была такая практика, что дежурство это почетная обязанность, к которой допускали только самых опытных разработчиков, при этом никак не мотивируя деньгами. Желающие были, но не очень много. Но вот когда внедрили оплату, то ситуация поменялась в лучшую сторону.

Раньше дежурства у нас действительно были «за спасибо» просто часть обязанностей, без всякой компенсации. Сейчас подход поменяли: ночные срочные подъёмы всё ещё остаются обязанностью инженеров, но за это дают полноценный отгул (как оплачиваемый выходной) на следующий день. Это сильно сглаживает нагрузку: можно спокойно выспаться и восстановиться.

Если на работе могут позвонить ночью - то нужно увольняться с такой работы. Это лишнее напряжение для нервов и неспокойный сон. Что в следствии может привести к хронической бессонницы и тогда будет вообще ад. Сон не должен ассоциироваться со стрессом и решением проблем средь ночи. Если без этого нельзя - менять профессию. Хотя те кто давно в ИТ тех оно вымораживает по другим причинам.

Есть знакомый, отказался от оффера +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 лет на одной позиции.. то субъективно начнется пииииии...

...Ложусь спать дальше ? У вас дежурный спать может ? Прикольно...

Sign up to leave a comment.

Articles