Сповіщення Linear, GitHub, Slack – від 200 до 5 на день
Сповіщення Linear, GitHub і Slack перевантажують вашу команду? Розбір того, чому архітектура ламається – і 5 сигналів, які варто залишити.
By Ellis Keane · 2026-03-13
Проблема не в тому, що ви отримуєте надто багато сповіщень. Проблема в тому, що ви отримуєте рівно правильну кількість – від трьох різних інструментів, про ту саму подію, одночасно.
Кожен webhook спрацьовує правильно. Кожна інтеграція доставляє саме те, що обіцяла. GitHub сповіщає вас про PR. Linear сповіщає вас про issue, який PR закриває. Slack сповіщає вас, бо хтось колись (мабуть, ви, три місяці тому, у пориві помилково спрямованого оптимізму щодо «видимості») підключив бота до каналу проєкту. Три інструменти, три сповіщення, одна подія – і всі вони працюють рівно так, як задумано. Інженерія бездоганна. Досвід жахливий.
Ваші сповіщення з Linear, GitHub і Slack перевантажують не тому, що щось зламалося. Вони перевантажують тому, що нічого не зламалося. Кожен інструмент сумлінно виконує свій контракт на сповіщення, жодним чином не усвідомлюючи існування інших. Немає спільної шини подій. Немає шару дедуплікації. Ніде в стеку немає концепції «ця людина вже знає про це». Ви страждаєте не від неправильної конфігурації. Ви страждаєте від логічного кінця підключення шести інструментів до одного робочого процесу та дозволу кожному незалежно горлати у порожнечу.
"Система сповіщень не зазнає збою. Вона настільки успішна, що поховала вас." – Chris Calo
Прогрес.
Анатомія одного злиття – розтин дублювання
Дозвольте провести вас через одну подію – одне злиття PR – і простежити, що відбувається на рівні сповіщень. Не тому що це незвично, а тому що це пригнічено звично.
Колега зливає PR на GitHub. Ось каскад:
- GitHub надсилає webhook у ваш інбокс сповіщень. Ви написали рев'ю на цей PR, тому підписані. Це перше сповіщення.
- Інтеграція Linear з GitHub виявляє пов'язаний issue й автоматично змінює його статус із «У роботі» на «Готово». Linear генерує сповіщення для всіх, хто стежить за issue, – включно з вами, бо ви в одній команді. Це друге сповіщення.
- Бот Slack (той, що ви підключили у тому пориві оптимізму) публікує зведення про злиття у #frontend. Якщо хтось відреагує на повідомлення емодзі або коментарем, Slack генерує сповіщення про гілку. Це третє – потенційно четверте сповіщення.
- CI запускається на коміті злиття. GitHub надсилає ще один webhook. Якщо CI проходить, вам, мабуть, байдуже, але сповіщення ви все одно отримуєте, бо модель підписки GitHub бінарна – ви або стежите, або ні. Це п'яте сповіщення.
П'ять сповіщень. Одна подія. І ви були на дзвінку, де обговорювалося злиття, тому знали про нього ще до того, як будь-яке з них надійшло.
Помножте це на кожен PR, кожен перехід issue та кожен запуск CI для команди з шести – і ви дивитесь на 30–40 дублюючих подій на людину на день, навіть не рахуючи справді нових сигналів. Система сповіщень не зазнає збою. Вона настільки успішна, що поховала вас.
Чому вимкнення звуку – це лейкопластир на відкритій рані
Стандартна порада – агресивне вимкнення звуку. Вимкнути email-сповіщення GitHub. Налаштувати Slack на сповіщення лише про прямі згадки. Відписатися від усіх issues у Linear, крім тих, що призначені вам. Це нотифікаційний еквівалент лікування перелому зап'ястка через зняття годинника – технічно ви зменшили складнощі навколо зап'ястка, але й втратили здатність дізнатися час.
Я пробував підхід із вимкненням звуку (звичайно, пробував – ми всі пробуємо, це перша річ, яку всі пробують, перш ніж другу річ, яку всі пробують, – ланцюжок Zapier, що чомусь робить усе гірше). Я вчинив агресивно: повністю відключив email-сповіщення GitHub, вимкнув звук у кожному каналі Slack, крім робочого каналу команди, відписався від усього у Linear, крім власних issues. Три дні блаженства.
Потім я пропустив два блокуючих PR-рев'ю, бо обговорення відбувалися в каналах, де я вимкнув звук. Інженери, яким потрібне було моє рев'ю, зрештою написали мені в особисті – що є просто сповіщенням із додатковими кроками й домішкою пасивно-агресивного «гей, ти бачив моє повідомлення?». Тиждень потому рішення щодо дизайну з'явилося в гілці коментарів Figma і повністю змінило компонент, який я будував на половину шляху, – і я не дізнався про це, доки мій PR не відхилили. Весело.
Фундаментальна проблема вимкнення звуку в тому, що воно застосовує статичні правила до динамічного контексту. Ваші налаштування сповіщень із минулого вівторка не знають про термінову помилку, яка з'явилася сьогодні вранці. І що агресивніше ви вимикаєте звук, то ширшими стають прогалини у вашій поінформованості – прогалини, які колеги заповнюють DM-повідомленнями «просто перевіряю, що ти бачив...». Якщо рахувати очки – агресивне вимкнення звуку не зменшує ваші сповіщення. Воно просто переміщає їх від ботів (які вас не судять) до людей (які точно судять).
П'ять сигналів, що справді виправдовують переривання
Після кількох тижнів ведення журналу сповіщень (у простому текстовому файлі, бо я саме той тип людини, якого ви очікуєте побачити за написанням статті про архітектуру сповіщень) виявився патерн. Зі ~200 щоденних повідомлень ті, що справді потребували дій упродовж години, розподілялися за п'ятьма категоріями:
- Хтось заблокований через вас. Запит на рев'ю PR на код, яким ви володієте; питання, на яке можете відповісти тільки ви; рішення, що очікує на вашу думку. Це єдина категорія, де затримка має складний ефект – кожна година без відповіді – це година, коли інший не може працювати.
- Щось задеплоєне вами зламалося. Помилки CI у вашій гілці, сплески помилок після вашого злиття, запит на відкат. Категорія «ваш код горить».
- Прийнято рішення, що впливає на вашу поточну роботу. Зміна дизайну, оновлення API-контракту, зміна пріоритету з боку продукту. Трапляється рідко, але дорого обходиться, якщо пропустити (пор.: мій відхилений PR, вище).
- Дедлайн змінився. Обсяг спринту змінився, демо перенесли вперед, залежність запізнюється. Події, що змінюють календар.
- Комусь потрібна допомога, і ви – правильна людина. Не кожен @channel. Не кожен @here. Конкретні випадки, де ваша експертиза справді актуальна – і навіть тоді лише якщо ніхто інший не може відповісти.
Решта – переходи статусів, автоматизовані повідомлення ботів, реакції «звучить добре», пропуски CI на гілках, за якими ви не стежите – це інформація, яка може колись стати в нагоді, але не потребує переривати функцію, яку ви пишете. Нотифікаційний індустріальний комплекс переконав нас, що все це заслуговує на однакову терміновість. Ні.
Зі 200 щоденних сповіщень лише близько п'яти категорій справді виправдовують переривання вашої роботи. Решта – інформація, яка може колись стати в нагоді, але інструменти ставляться до всього як до однаково термінового, що означає: ніщо не є терміновим.
Фреймворк сортування для зрадженого архітектурою
Ось фреймворк, який можна почати використовувати вже сьогодні – жодних інструментів не потрібно, лише дисципліна та ~20 хвилин на налаштування. Він не вирішить архітектурну проблему (лише шар дедуплікації може це зробити), але зупинить кровотечу, поки ви оцінюєте довгострокові рішення.
Дворазове сканування на день: Замість безперервної перевірки сповіщень згрупуйте їх у два сеанси – раз у середині ранку, раз у середині після обіду. Під час кожного сеансу переглядайте сповіщення GitHub, інбокс Linear і непрочитані в Slack і сортуйте кожне у одну з трьох корзин:
| Корзина | Правило | Дія | |--------|------|--------| | Діяти зараз | Хтось заблокований, щось зламано або рішення потребує вас | Впорайтеся негайно | | Батч | Важливо, але не термінове | Додайте до списку «відповісти пізніше», впорайтеся в кінці дня | | Архів | Балачки ботів, оновлення статусів, вирішені гілки, дублікати | Позначте як прочитане, живіть далі |
Встановіть типові налаштування на рівні каналу в Slack: Для кожного каналу вирішіть: це канал «діяти зараз» (робочий канал команди, канали для інцидентів) чи канал «батч» (загальні оголошення, міжкомандні оновлення)? Вимкніть звук у батч-каналах і перевіряйте їх лише під час сеансів сканування. Так, технічно це вимкнення звуку, над яким я щойно насміхався два абзаци – різниця в тому, що ви все одно перевіряєте їх за розкладом, а не вдаєте, що вони не існують.
Використовуйте фільтри сповіщень GitHub: Зробіть закладку github.com/notifications?query=reason:review-requested – той URL показує лише PR-рев'ю, явно призначені вам, повністю відсікаючи шум підписок/CI. Для email GitHub включає reason header (review_requested, mention, subscribed, ci_activity), за яким можна фільтрувати: автоархівуйте «subscribed» і «ci_activity» – і ви нічого справді потрібного не пропустите. Те, що GitHub ховає ці корисні метадані в заголовках email замість того, щоб відображати в інтерфейсі сповіщень, говорить про все, що потрібно знати про глибину опрацювання споживацької сторони цих систем.
Цей підхід не зловить контекстуальні сигнали (пам'ятаєте той коментар у Figma, що торпедував мій PR? Дворазове сканування теж би його не зловило). Але він скоротить шум на 60–70%, чого достатньо, щоб зупинити нав'язливий alt-tab, поки ви вирішуєте, чи варта проблема справжнього рішення.
Що насправді має робити шар дедуплікації
Тут усе стає архітектурно цікавим – і саме тут я перестав думати про це як про проблему налаштувань сповіщень і почав думати про це як про проблему класифікації.
Наївний підхід – це пошук за ключовими словами й виявлення згадок. Якщо ваше ім'я з'явилося – виведіть. Якщо це запит на рев'ю, призначений вам – виведіть. Це ловить очевидні випадки, але повністю пропускає контекстуальні – на кшталт рішення щодо дизайну в гілці, де ніхто не згадав вас у @, бо не усвідомлював, що ви будуєте компонент, якого воно стосується. (Це переслідуватиме мене ще якийсь час.)
Те, що вам справді потрібно, – це граф знань відносин: які завдання ваші, які PR пов'язані з якими issues, які гілки Slack стосуються яких функцій, хто зазвичай потребує вашої думки з яких тем. Коли надходить новий сигнал – повідомлення Slack, подія GitHub, перехід у Linear – ви класифікуєте його за цим графом. Не «чи згадує це Кріса?», а «чи впливає це на щось, над чим Кріс зараз активно працює, чого очікує або за що відповідає?»
Класифікація мала б розбиватися приблизно так:
| Класифікація | Що це означає | Дія | |---------------|---------------|--------| | Термінове | Ви блокуєте когось, або щось зламано | Вивести негайно | | Важливе | Впливає на вашу поточну роботу, але не критично за часом | Зібрати у щоденний дайджест | | Інформаційне | Добре знати, дій не потрібно | Доступне, якщо підете шукати | | Шум | Дублікати, балачки ботів, вирішені гілки | Відфільтровано повністю |
Складність у тому, що впевненість у класифікації не є бінарною. Повідомлення Slack у каналі, який ви ніколи не відвідуєте, може все одно бути терміновим, якщо воно посилається на issue, призначений вам. Сповіщення GitHub про репозиторій, якого ви не торкалися місяцями, може мати значення, якщо хтось щойно перевідкрив баг, який ви вважали виправленим. Потрібні два шари, що працюють разом: шар нормалізації подій, який хешує кожен вхідний webhook за складеним ключем – репозиторій, ID issue, актор, тип події – і перевіряє його проти вікна дедуплікації з TTL (по суті ковзаюче вікно нещодавніх відбитків подій), а за ним – живий граф знань відносин, що відображає власність на завдання, прив'язки PR, учасників гілок і патерни нещодавньої активності. Ви фактично будуєте read-модель усього робочого стану команди, що оновлюється в режимі близького до реального часу й запитується на кожному вхідному сигналі. Шар дедуплікації ловить очевидні дублікати. Граф відповідає на складніше питання: «Чи стосується це саме вас прямо зараз?»
Основний цикл класифікації добре справляється з очевидними випадками, і одне це суттєво скорочує шум – але справді неоднозначні сигнали (де ви недостатньо впевнені, щоб придушити, але й недостатньо впевнені, щоб вивести) залишаються відкритою проблемою. Ми експериментуємо з накопиченням їх у дайджесті «можливо», але не буду вдавати, що ми це вирішили.
Що змінюється, коли шланг припиняє хлюпати
Те, чого я не очікував – я справді думав, що перевага буде просто «менше повідомлень» – це те, наскільки глибоко змінюється ваше ставлення до інструментів, коли вони перестають на вас кричати.
Коли кожне сповіщення може бути важливим, у вас розвивається низькорівнева тривога щодо кількості непрочитаних. Бічна панель Slack із жирними назвами каналів. Дзвіночок GitHub. Інбокс Linear. Ви перевіряєте нав'язливо – не тому що очікуєте чогось термінового, а тому що ціна пропустити щось здається вищою за ціну перевірити 50 речей, що виявляться шумом. Раніше я переходив до Slack alt-tab між написанням сигнатури функції та її тіла. Не свідоме рішення – просто рефлекс, як перевіряєте дзеркала на червоне світло.
Превентивне самопереривання, мабуть, гірше за самі сповіщення, бо ви ламаєте власну концентрацію ще до того, як прийшло будь-яке повідомлення. Ви живете у стані постійної часткової уваги, і це відчувається у коді, що ви пишете – поверхневіші рев'ю, безпечніші архітектурні рішення, шлях найменшого опору замість підходу, що насправді правильний, бо ви не вірите, що отримаєте 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 хвилин, щоб відновити глибоку зосередженість. Окрім самих сповіщень, нав'язливе перевіряння, яке вони породжують, фрагментує стійку концентрацію, необхідну для складної інженерної роботи.
Якщо сповіщення вашої інженерної команди перетнули межу від «бути поінформованим» до «бути стривоженим» – це, мабуть, знак того, що архітектура потребує виправлення, а не ваші налаштування сповіщень.