Комментарии 13
То есть сообщения без указания дежурного в общий чат игнорируются? Даже теми же дежурными? Какая-то странная схема.
Да и в чём проблема самих DevOps смотреть в свою табличку в начале рабочего дня и дежурить по ней? Без всяких интеграций и лишних, со стороны остальных участников процесса, тегов.
Сообщения без тега не игнорируются, но могут доходить до адресата с большим опозданием
Любая наша команда работает в режиме многозадачности, водрузить человека на трон дежурного, который будет в течение всего дня только отслеживать запросы на поддержку - не лучшее решение.
И вот представьте ситуацию, когда дежурный инженер сидит и занимается, к примеру репликацией большого массива данных, а у коллеги разработчика билд продового приложения упал. Разработчик оповестил о проблеме безадресно, дежурный в это время кропотливо проверяет, что ничего не пропустил, сообщения не видит. Начинается излишний переполох.
Плюс командные каналы не ограничиваются вопросами поддержки, там может быть много разных тем. Выискивать среди десятков сообщений то самое, адресованное дежурному, тоже крадет лишнее время инженера. Гораздо проще именно в нашей ситуации оказалось автоматизировать процесс.
Эта схема в нашей компании удобно внедряется в любую специфику дежурств.
Будь то сами разработчики, или QA или системные аналитики.
Что мы получили? Нуждающийся в помощи коллега знает один тег, а дежурный не мониторит чат на протяжении всего дня, оперативно получая алерт.
А кто что использует для календаря дежурств? Чтоб действительно удобно было.
пару месяцев как используем betterstack (ну как используем, настроили и забыли :)
по сравнению с pagerduty действительно удобно :)
У нас устроено проще, чем описано в статье, но вариант рабочий.
Планируется график дежурств на месяц, график в общем доступе как у нас, так и у смежных отделов.
То есть, начав рабочий день, ты знаешь что ты дежурный и тебе нужно реагировать на какие то события и коллеги также об этом в курсе. Также в дежурные дни дежурный не занимается продуктовой разработкой.
Система отлажена как часы :)
Мы сами написали. Интеграции можем приделывать любые, из, например удобного - при создании инцидента сотрудник поддержки может выбрать, какие команды ему нужны для решения и им автоматом во все нужные места оповещения отправляются.
На самом деле вообще не страшно, основной функционал в свободном режиме сделали недели за три.
Вся статья - это отличный пример over engineering'а, когда для забивания гвоздя вместо простого молотка используется целая орбитальная пушка.
Зачем вообще использовать чат в качестве баг-трекера? Чат - это место, для обычного ненапряжного общения, например, обсудить с коллегами, что будем заказывать себе на обед или обсудить какие-то технические новинки.
Для информации о проблемах давно придумали баг-трекеры и тикетные системы. Есть проблема, создавай тикет, в котором эта проблема будет подробно описана. После всех согласований этот тикет попадёт тому инженеру, который сможет помочь с решением проблемы. Всё максимально просто и было придумано ещё 30 лет назад.
У вас же получается, что одно тело, которому кажется, что он нашёл баг, пишет в чат, где находится 10-15 человек, в результате, все эти люди отвлекаются от своей работы, чтобы прочитать сообщение, которое может быть им даже не адресовано. Трата времени и внимания людей на пустом месте, только потому что в компании нет нормального процесса для репорта багов или запроса помощи.
Просто человек пытается решить проблему. Но у него на данный момент нет знаний о том, что есть ITIL, ITSM и что он вообще-то работает в области деятельности, которая должна жить по этой парадигме (иначе получается то, что в посте).
Он не виноват, мы все такие - всего не знаем. Разница только в оценках собственного уровня незнания. Автору (возможно) кажется, что он нашел изящное решение проблемы и поделился этим с миром, вроде как "смотрите, я нашел! Эврика!" А все опытные покрутили пальцем у виска. Я именно по этому ничего не пишу и никогда писать не буду, я (смею надеяться) вполне адекватно оцениваю свой ужасающе высокий уровень незнания. И с этим уровнем кричать как минимум на весь рунет нахожу не очень хорошей затеей.
Баг трекеры и тикет системы у нас есть и используются по прямому назначению.
Но заводить тикет в ситуации, когда у разработчика сервис смежной команды отдает 503 ошибку в стейдже, мешая продолжать отладку, не самый оперативный подход.
Или поддержка пользователей завела тикет о проблеме на проде, и в процессе локализации проблемы одной команде требуется консультация с другой? Можно это сделать в рамках тикета и подождать, когда вторая команда увидит комментарии.
Или написать в чат команды, отвечающей за сервис.
Кто начнет смотреть проблему? Или самый быстрый или несколько человек или все будут ждать того самого, кто публично отреагирует на вопрос. Это как раз к вашим словам о том, что кто-то пишет сообщение и отвлекает всю команду.
Решить такого рода ситуации можно по-разному, мы выбрали и успешно обкатали путь, при котором зона ответственности сотрудника четко определена и автоматизирована и не обязывает его бесперерывно отсматривать рабочие сообщения. А остальные члены команды сосредоточены на своих задачах и не отвлекаются
В это же время коллеги, столкнувшиеся с проблемой не чувствуют себя частью бюрократической машины, где на каждый технический вопрос или проблему нужно создавать подробный тикет.
Или поддержка пользователей завела тикет о проблеме на проде, и в процессе локализации проблемы одной команде требуется консультация с другой? Можно это сделать в рамках тикета и подождать, когда вторая команда увидит комментарии.
У нас для этого от каждой команды есть blender/дежурный, который и решает подобные задачи, в том числе
Согласен с первой частью ответа, тут действительно загнули лишнего, но со второй частью не соглашусь. Мы в компании договорились, что некоторые типы задач вроде накинуть прав тестировщику или любая мелочь до 30 минут падает на дежурного DevOps, т.к. у команд нет своих.
Что по содержанию статьи, то т.к. я непосредственно составляю и поддерживаю похожее расписание дежурств, ранее в Slack, а теперь в Mattermost, сразу появляется вопрос насколько удобно поменять расписание, если один из инженеров приболел или сорвался в середине дня, ситуаций может быть много, так же при появлении джуна нужно ставить в дежурство уже двух людей. В моем случае как раз победил Excel, с помощью нехитрых формул создается матрица дежурств, которая превращается в команду для бота Reminder, каждое утро он назначает нового дежурного в канал #devops, сообщений не так много, поэтому разработчики редко ошибаются и тегают другого человека, а сменить дежурного можно новым сообщением.
А могли бы просто раздать ножи и домашние адреса ответственных
Excel vs Grafana: Автоматизация дежурств