Уведомления Linear, GitHub и Slack – с 200 до 5 в день
Уведомления Linear, GitHub и Slack перегружают вашу команду? Разбор архитектурной проблемы и 5 сигналов, которые действительно важны.
By Ellis Keane · 2026-03-13
Проблема не в том, что вы получаете слишком много уведомлений. Проблема в том, что вы получаете ровно столько – от трёх разных инструментов, об одном и том же событии, одновременно.
Каждый вебхук срабатывает правильно. Каждая интеграция доставляет именно то, что обещала. GitHub уведомляет вас о PR. Linear уведомляет вас о задаче, которую этот PR закрывает. Slack уведомляет вас потому, что кто-то в какой-то момент (вероятно, вы, три месяца назад, в порыве беспочвенного оптимизма насчёт «прозрачности») подключил бота к каналу проекта. Три инструмента, три уведомления, одно событие – и все работают именно так, как задумано. Инженерная часть безупречна. Опыт ужасен.
Ваши уведомления из Linear, GitHub и Slack не перегружают вас потому, что что-то сломано. Они перегружают вас потому, что ничто не сломано. Каждый инструмент верно исполняет свой контракт уведомлений, совершенно не зная о существовании других. Нет общей шины событий. Нет слоя дедупликации. Нигде в стеке нет концепции «этот человек уже знает об этом». Вы страдаете не от неправильной конфигурации. Вы страдаете от логичного результата подключения шести инструментов к одному рабочему процессу и разрешения каждому из них независимо кричать в пустоту.
«Система уведомлений не даёт сбоев. Она работает настолько хорошо, что засыпает вас.» – Chris Calo
Прогресс.
Анатомия одного слияния – вскрытие дублирования
Давайте пройдёмся по одному событию – единственному слиянию PR – и проследим, что происходит в слое уведомлений. Не потому что это редкость, а потому что это удручающе обычное дело.
Коллега делает слияние PR на GitHub. Вот каскад:
- GitHub отправляет вебхук в вашу папку уведомлений. Вы написали ревью к этому PR, поэтому являетесь подписчиком. Это первое уведомление.
- Интеграция GitHub в Linear обнаруживает связанную задачу и автоматически переводит её статус из «В работе» в «Готово». Linear генерирует уведомление для всех, кто следит за задачей – в том числе для вас, потому что вы в одной команде. Это второе уведомление.
- Бот Slack (тот, что вы подключили в том припадке оптимизма) публикует краткое изложение слияния в #frontend. Если кто-то отреагирует на это сообщение эмодзи или комментарием, Slack генерирует уведомление о треде. Это третье уведомление, потенциально четвёртое.
- CI запускается на коммите слияния. GitHub отправляет ещё один вебхук. Если CI проходит, вам, вероятно, всё равно – но уведомление вы всё равно получите, потому что модель подписки GitHub бинарна: вы либо следите, либо нет. Это пятое уведомление.
Пять уведомлений. Одно событие. И вы были на звонке, где обсуждалось слияние, так что узнали об этом ещё до того, как пришло хоть одно уведомление.
Умножьте это на каждый PR, каждый переход задачи и каждый запуск CI для команды из шести человек – и вы получите от 30 до 40 дублирующихся событий на человека в день ещё до того, как начнёте считать действительно новые сигналы. Система уведомлений не даёт сбоев. Она работает настолько хорошо, что засыпает вас.
Почему заглушение – это пластырь на артериальное кровотечение
Стандартный совет – агрессивное заглушение. Отключить email-уведомления GitHub. Настроить Slack так, чтобы он уведомлял только о прямых упоминаниях. Отписаться от всех задач Linear, кроме назначенных вам. Это как лечить перелом запястья, сняв часы – технически вы снизили сложность связанную с запястьем, но заодно утратили возможность узнать время.
Я пробовал подход с заглушением (конечно пробовал – все это делают, это первое, что пробует каждый, сразу перед вторым – цепочкой в Zapier, которая почему-то делает всё хуже). Я был агрессивен: полностью отключил email от GitHub, заглушил все каналы Slack кроме рабочего канала команды, отписался от всего в Linear кроме своих задач. Дня три это было блаженством.
Потом я пропустил два блокирующих ревью PR, потому что обсуждения велись в каналах, которые я заглушил. Инженеры, которым нужно было моё ревью, в итоге написали мне в личку – что по сути то же уведомление, только с дополнительными шагами и примесью пассивно-агрессивного «эй, ты видел моё сообщение?». Через неделю в тред комментариев Figma упало дизайн-решение, полностью менявшее компонент, который я как раз строил, – и я узнал об этом, только когда мой PR был отклонён. Было весело.
Фундаментальная проблема заглушения в том, что оно применяет статические правила к динамическому контексту. Ваши настройки уведомлений от прошлого вторника ничего не знают о срочном баге, пришедшем этим утром. И чем агрессивнее вы заглушаете, тем шире становятся пробелы в вашей осведомлённости – пробелы, которые коллеги заполняют сообщениями «просто проверяю, видел ли ты...». Что, если считать очки, означает: агрессивное заглушение не сокращает уведомления. Оно просто переносит их от ботов (которые вас не осуждают) к людям (которые точно осуждают).
Пять сигналов, которые действительно оправдывают прерывание
После нескольких недель записи уведомлений (в обычном текстовом файле, ведь именно таким человеком и ожидаешь встретить автора статьи об архитектуре уведомлений) обнаружился паттерн. Из примерно 200 ежедневных пингов, те, которые действительно требовали действия в течение часа, попадали в пять категорий:
- Кто-то заблокирован из-за вас. Запрос на ревью PR в коде, которым вы владеете, вопрос, на который можете ответить только вы, решение, ожидающее вашего участия. Это единственная категория, где задержка имеет накопленную стоимость – каждый час без ответа – это час, когда кто-то другой не может работать.
- Что-то задеплоенное вами сломалось. Сбои CI на вашей ветке, всплески ошибок после вашего слияния, запрос на откат. Категория «ваш код горит».
- Принято решение, затрагивающее вашу текущую работу. Изменение дизайна, обновление API-контракта, сдвиг приоритетов со стороны продукта. Редко, но дорого упускать (см.: мой отклонённый PR выше).
- Изменился дедлайн. Изменился объём спринта, демо перенесено раньше, зависимость сдвинулась. События, меняющие календарь.
- Кому-то нужна помощь, и вы – подходящий человек. Не каждый @channel. Не каждый @here. Конкретные случаи, где ваша экспертиза действительно релевантна – и то только если никто другой не может ответить.
Всё остальное – переходы статусов, автоматические сообщения ботов, эмодзи-реакции «звучит хорошо», успешные CI на ветках, за которыми вы не следите – это информация, которая может оказаться полезной когда-нибудь, но не обязана прерывать функцию, которую вы пишете. Промышленный комплекс уведомлений убедил нас, что всё это заслуживает одинакового приоритета. Это не так.
Из 200 ежедневных уведомлений примерно пять категорий действительно оправдывают то, чтобы отвлечься от текущей работы. Остальные – это информация, которая может оказаться полезной когда-нибудь. Но инструменты обрабатывают всё как одинаково срочное, а значит ничто не является срочным.
Фреймворк триажа для тех, кого предала архитектура
Вот фреймворк, который вы можете начать применять сегодня – без инструментов, просто дисциплина и около 20 минут настройки. Он не решит архитектурную проблему (ничто, кроме слоя дедупликации, этого не сделает), но остановит кровотечение, пока вы оцениваете долгосрочные решения.
Двукратный просмотр в день: Вместо непрерывной проверки уведомлений соберите их в два просмотра – один в середине утра, один в середине дня. Во время каждого просмотра изучайте уведомления GitHub, папку входящих Linear и непрочитанные в Slack, сортируя каждое в одну из трёх корзин:
| Корзина | Правило | Действие | |--------|------|--------| | Действовать сейчас | Кто-то заблокирован, что-то сломано или требуется решение | Обработать немедленно | | Batch | Важно, но не критично по времени | Добавить в список «ответить позже», обработать к концу дня | | Архив | Болтовня ботов, обновления статусов, закрытые треды, дубликаты | Отметить прочитанным, двигаться дальше |
Установите настройки каналов по умолчанию в Slack: Для каждого канала решите: это канал «действовать сейчас» (рабочий канал команды, каналы инцидентов) или канал «batch» (общие объявления, обновления между командами)? Заглушите batch-каналы и проверяйте их только во время просмотров. Да, это технически заглушение, которое я только что два абзаца высмеивал – разница в том, что вы всё равно проверяете их по расписанию, а не делаете вид, что их не существует.
Используйте фильтры уведомлений GitHub: Добавьте в закладки github.com/notifications?query=reason:review-requested – этот URL показывает только ревью PR, явно назначенные вам, полностью отсекая шум от подписок и CI. Для email GitHub включает заголовок reason (review_requested, mention, subscribed, ci_activity), по которому можно фильтровать: автоматически архивируйте «subscribed» и «ci_activity», и вы ничего не потеряете. Тот факт, что GitHub закапывает эти полезные метаданные в заголовки email, а не выносит в интерфейс уведомлений, говорит о том, сколько мысли вложено в сторону потребления этих систем.
Этот подход не поймает контекстуальные сигналы (помните комментарий в Figma, который убил мой PR? Двукратный просмотр его тоже не поймал бы). Но он сократит шум на 60–70 процентов – а этого достаточно, чтобы остановить компульсивное переключение вкладок, пока вы разбираетесь, требует ли проблема настоящего решения.
Что на самом деле должен делать слой дедупликации
Вот где становится архитектурно интересно – и где я перестал воспринимать это как проблему настроек уведомлений и начал думать о ней как о задаче классификации.
Наивный подход – сопоставление ключевых слов и обнаружение упоминаний. Если появляется ваше имя – показать. Если это запрос на ревью, назначенный вам – показать. Это ловит очевидные случаи, но полностью упускает контекстуальные – дизайн-решение в треде, где вас никто не @упомянул, потому что не поняли, что вы строите компонент, который это затрагивает. (Это будет долго меня преследовать.)
То, что вам на самом деле нужно, – это граф отношений: какие задачи ваши, какие PR связаны с какими задачами, какие треды Slack касаются каких функций, кто склонен нуждаться в вашем участии по каким темам. Когда приходит новый сигнал – сообщение в Slack, событие GitHub, переход в Linear – вы классифицируете его относительно этого графа знаний. Не «упоминает ли это Криса?», а «затрагивает ли это что-то, над чем Крис активно работает, чего ждёт или за что отвечает?»
Классификация должна разбиваться примерно так:
| Классификация | Что означает | Действие | |---------------|---------------|--------| | Срочное | Вы блокируете кого-то или что-то сломано | Показать немедленно | | Важное | Влияет на текущую работу, но не критично по времени | Собрать в ежедневный дайджест | | Информационное | Полезно знать, действий не требует | Доступно, если найдёте сами | | Шум | Дубликаты, болтовня ботов, закрытые треды | Отфильтровано полностью |
Сложная часть в том, что уверенность классификации не бинарна. Сообщение Slack в канале, который вы никогда не посещаете, может всё равно быть срочным, если оно ссылается на задачу, назначенную вам. Уведомление GitHub о репозитории, к которому вы не прикасались несколько месяцев, может оказаться важным, если кто-то только что снова открыл баг, который вы считали исправленным. Вам нужны два слоя, работающих совместно: слой нормализации событий, хэширующий каждый входящий вебхук по составному ключу – репозиторий, ID задачи, актор, тип события – и проверяющий его в окне дедупликации с TTL (по сути скользящее окно недавних отпечатков событий), а за ним – живой граф отношений, отображающий владение задачами, связи PR, участников тредов и паттерны недавней активности. Вы фактически строите модель чтения всего рабочего состояния команды, обновляемую в режиме близком к реальному времени, и запрашиваете её при каждом входящем сигнале. Слой дедупликации ловит очевидные дубликаты. Граф знаний отвечает на более сложный вопрос: «актуально ли это именно для вас прямо сейчас?»
Основной цикл классификации хорошо справляется с очевидными случаями, и это само по себе существенно сокращает шум – но по-настоящему неоднозначные сигналы (когда вы недостаточно уверены, чтобы подавить, но и недостаточно уверены, чтобы показать) остаются открытой проблемой. Мы экспериментируем с объединением их в дайджест «может быть», но не буду делать вид, что мы это решили.
Что меняется, когда пожарный шланг перестаёт бить
Чего я не ожидал – я искренне думал, что выгода будет просто «меньше пингов» – это насколько глубоко меняется ваше отношение к инструментам, когда они перестают кричать на вас.
Когда каждое уведомление может быть важным, у вас развивается эта фоновая тревога по поводу числа непрочитанных. Боковая панель Slack с жирными именами каналов. Колокольчик GitHub. Папка входящих Linear. Вы компульсивно проверяете – не потому что ожидаете чего-то срочного, а потому что стоимость пропустить что-то кажется выше, чем стоимость проверить 50 вещей, которые окажутся шумом. Я делал alt-tab в Slack между написанием сигнатуры функции и её тела. Не осознанное решение – просто рефлекс, как проверять зеркала на красном свете.
Превентивное самопрерывание, пожалуй, хуже самих уведомлений, потому что вы разрушаете собственную концентрацию ещё до того, как придёт хоть один пинг. Вы живёте в состоянии постоянного частичного внимания, и это ощущается в коде, который вы пишете – поверхностные ревью, более безопасные архитектурные решения, путь наименьшего сопротивления вместо действительно правильного подхода, потому что вы не доверяете, что у вас будет 45 непрерывных минут для размышлений.
Когда пожарный шланг перестаёт бить – когда вы доверяете, что важные сигналы вас найдут, а шум – нет – этот рефлекс угасает. Не сразу, потому что старые привычки упрямы. Но через пару недель замечаешь, что проводишь в редакторе более длинные отрезки без компульсивного alt-tab. Начинаешь заканчивать мысли. Пишешь лучший код – не потому что внезапно поумнел, а потому что перестал добровольно выполнять 30 переключений контекста в час от имени системы уведомлений, которая никогда об этом не просила.
Перестаньте тонуть в уведомлениях. Sugarbug классифицирует каждый сигнал из Linear, GitHub и Slack по релевантности – и показывает только то, что действительно нуждается в вас.
Q: Снижает ли Sugarbug перегрузку уведомлениями из Linear, GitHub и Slack? A: Да. Sugarbug подключается к Linear, GitHub и Slack через API и классифицирует каждый сигнал по срочности и релевантности. Вместо того чтобы пересылать каждое уведомление, он отображает только те, которые требуют вашего внимания – как правило, сокращая сотни ежедневных пингов до тех, которые действительно нуждаются в вас.
Q: Может ли Sugarbug расставлять приоритеты для уведомлений о PR на GitHub на основе того, над чем я работаю? A: Sugarbug строит граф знаний ваших задач, PR и разговоров. Он знает, какие PR связаны с вашей текущей работой, и в первую очередь показывает запросы на ревью, конфликты слияния и сбои CI для них – тихо откладывая остальное.
Q: Чем Sugarbug отличается от встроенных настроек уведомлений Slack? A: Настройки Slack позволяют заглушать каналы или задавать ключевые слова, но не могут понимать контекст между инструментами. Sugarbug читает данные из Linear, GitHub и Slack вместе, поэтому он знает, что тред Slack о PR, который вы создали, является срочным, даже если он находится в заглушённом канале.
Q: Какова реальная стоимость перегрузки уведомлениями для команд разработчиков? A: Исследование Глории Марк из UC Irvine показывает, что после прерывания требуется около 23 минут, чтобы восстановить глубокую концентрацию. Помимо самих пингов, компульсивное проверочное поведение, которое они порождают, фрагментирует устойчивую концентрацию, необходимую для сложной инженерной работы.
Если уведомления вашей команды разработчиков пересекли черту от «оставаться в курсе» до «оставаться в тревоге» – это, вероятно, сигнал, что нужно исправлять архитектуру, а не настройки уведомлений.