Thông báo Linear, GitHub, Slack quá tải – Từ 200 còn 5
Thông báo Linear, GitHub và Slack làm đội ngũ kỹ thuật của bạn quá tải? Phân tích lý do kiến trúc thất bại – và 5 tín hiệu đáng giữ lại.
By Ellis Keane · 2026-03-13
Vấn đề không phải là bạn nhận được quá nhiều thông báo. Vấn đề là bạn nhận được đúng số lượng – từ ba công cụ khác nhau, về cùng một sự kiện, cùng một lúc.
Mọi webhook đều kích hoạt chính xác. Mọi tích hợp đều cung cấp chính xác những gì đã hứa. GitHub thông báo cho bạn về PR. Linear thông báo cho bạn về issue mà PR đó đóng. Slack thông báo cho bạn vì ai đó, vào một thời điểm nào đó (có thể là bạn, ba tháng trước, trong một cơn bùng phát lạc quan sai chỗ về "tính hiển thị"), đã kết nối một bot vào kênh dự án. Ba công cụ, ba thông báo, một sự kiện – và tất cả đều hoạt động đúng như thiết kế. Kỹ thuật hoàn hảo. Trải nghiệm kinh khủng.
Thông báo Linear, GitHub và Slack của bạn không quá tải vì có điều gì đó hỏng. Chúng quá tải vì không có gì hỏng cả. Mỗi công cụ đang trung thực thực hiện hợp đồng thông báo của mình, hoàn toàn không biết đến sự tồn tại của các công cụ khác. Không có event bus chung. Không có lớp khử trùng lặp. Không có khái niệm nào ở bất kỳ đâu trong stack về "con người này đã biết điều này rồi". Bạn không đau khổ vì cấu hình sai. Bạn đau khổ vì hậu quả logic của việc cắm sáu công cụ vào cùng một quy trình và để mỗi công cụ hét vào khoảng trống một cách độc lập.
"Hệ thống thông báo không đang thất bại. Nó đang thành công đến mức chôn vùi bạn." – Chris Calo
Tiến bộ vậy.
Giải phẫu một lần merge – khám nghiệm tử thi về trùng lặp
Hãy để tôi dẫn bạn qua một sự kiện – một lần merge PR duy nhất – và theo dõi những gì xảy ra ở lớp thông báo. Không phải vì nó bất thường, mà vì nó bình thường đến mức ảm đạm.
Một người đồng đội merge một PR trên GitHub. Đây là chuỗi phản ứng:
- GitHub kích hoạt webhook vào hộp thư thông báo của bạn. Bạn đã viết review cho PR này, vì vậy bạn đang theo dõi. Đó là thông báo thứ nhất.
- Tích hợp GitHub của Linear phát hiện issue được liên kết và tự động chuyển trạng thái của nó từ "Đang thực hiện" sang "Hoàn thành". Linear tạo thông báo cho tất cả mọi người đang theo dõi issue – bao gồm bạn, vì bạn cùng nhóm. Đó là thông báo thứ hai.
- Bot Slack (cái bạn đã kết nối trong cơn bùng phát lạc quan đó) đăng tóm tắt merge lên #frontend. Nếu ai đó phản ứng với tin nhắn đó bằng emoji hoặc bình luận, Slack tạo thông báo thread. Đó là thông báo thứ ba, có thể là thứ tư.
- CI chạy trên commit merge. GitHub kích hoạt thêm một webhook nữa. Nếu CI qua, bạn có thể không quan tâm, nhưng bạn vẫn nhận thông báo vì mô hình đăng ký của GitHub là nhị phân – bạn hoặc đang theo dõi hoặc không. Đó là thông báo thứ năm.
Năm thông báo. Một sự kiện. Và bạn đã ở trong cuộc gọi nơi việc merge được thảo luận, vì vậy bạn đã biết về nó trước khi bất kỳ thông báo nào đến.
Nhân điều này với mỗi PR, mỗi chuyển đổi trạng thái issue và mỗi lần chạy CI cho nhóm sáu người, và bạn đang nhìn vào 30 đến 40 sự kiện trùng lặp mỗi người mỗi ngày – trước khi bạn thậm chí tính đến các tín hiệu thực sự mới. Hệ thống thông báo không đang thất bại. Nó đang thành công đến mức chôn vùi bạn.
Tại sao tắt tiếng chỉ là miếng dán trên vết thương hở
Lời khuyên tiêu chuẩn là tắt tiếng tích cực. Tắt thông báo email GitHub. Đặt Slack chỉ thông báo khi được đề cập trực tiếp. Hủy theo dõi tất cả các issue trong Linear ngoại trừ những issue được giao cho bạn. Đây là tương đương thông báo của việc điều trị cổ tay gãy bằng cách tháo đồng hồ – về mặt kỹ thuật bạn đã giảm độ phức tạp liên quan đến cổ tay, nhưng bạn cũng mất khả năng biết giờ.
Tôi đã thử phương pháp tắt tiếng (tất nhiên rồi – tất cả chúng ta đều thử, đó là điều đầu tiên mọi người thử, trước điều thứ hai mọi người thử, là chuỗi Zapier bằng cách nào đó khiến mọi thứ tệ hơn). Tôi đã làm quyết liệt: tắt hoàn toàn email GitHub, tắt tiếng mọi kênh Slack ngoại trừ kênh làm việc của nhóm, hủy theo dõi mọi thứ trong Linear ngoại trừ issue của chính mình. Ba ngày hạnh phúc.
Rồi tôi đã bỏ lỡ hai PR review bị chặn vì các cuộc thảo luận diễn ra trong các kênh tôi đã tắt tiếng. Các kỹ sư cần review của tôi cuối cùng đã nhắn tin riêng cho tôi – thứ chỉ là một thông báo với các bước bổ sung và kèm theo năng lượng passive-aggressive "này, bạn có thấy tin nhắn của tôi không?". Một tuần sau, một quyết định thiết kế xuất hiện trong thread bình luận Figma đã thay đổi hoàn toàn component tôi đang xây dựng đến giữa chừng, và tôi không biết cho đến khi PR của tôi bị từ chối. Thật vui vẻ.
Vấn đề cơ bản với tắt tiếng là nó áp dụng các quy tắc tĩnh cho ngữ cảnh động. Cài đặt thông báo của bạn từ thứ Ba tuần trước không biết về lỗi khẩn cấp xuất hiện sáng nay. Và bạn tắt tiếng càng tích cực, khoảng cách trong sự nhận thức của bạn càng rộng – những khoảng cách mà các đồng đội lấp đầy bằng tin nhắn riêng "chỉ kiểm tra xem bạn đã thấy...". Nếu bạn đang ghi điểm, điều đó có nghĩa là tắt tiếng tích cực không làm giảm thông báo của bạn. Nó chỉ dịch chuyển chúng từ bot (không phán xét bạn) sang người (chắc chắn sẽ phán xét).
Năm tín hiệu thực sự đáng bị gián đoạn
Sau vài tuần ghi nhật ký thông báo (trong file văn bản thuần túy, vì tôi chính xác là kiểu người bạn mong đợi sẽ viết bài về kiến trúc thông báo), một mô hình xuất hiện. Trong số khoảng 200 thông báo hàng ngày, những thông báo thực sự cần hành động trong vòng một giờ rơi vào năm danh mục:
- Có người bị chặn bởi bạn. Yêu cầu review PR trên code bạn sở hữu, câu hỏi chỉ bạn mới có thể trả lời, quyết định đang chờ ý kiến của bạn. Đây là danh mục duy nhất mà sự chậm trễ có chi phí kép – mỗi giờ bạn không phản hồi là một giờ người khác không thể làm việc.
- Thứ gì đó bạn đã deploy bị hỏng. Lỗi CI trên nhánh của bạn, tăng đột biến lỗi sau merge của bạn, yêu cầu revert. Danh mục "code của bạn đang cháy".
- Một quyết định đã được đưa ra ảnh hưởng đến công việc hiện tại của bạn. Thay đổi thiết kế, cập nhật hợp đồng API, thay đổi ưu tiên từ phía sản phẩm. Những điều này hiếm gặp nhưng tốn kém nếu bỏ lỡ (xem: PR bị từ chối của tôi, ở trên).
- Deadline đã thay đổi. Phạm vi Sprint thay đổi, demo được đẩy sớm lên, một dependency bị trễ. Các sự kiện thay đổi lịch.
- Có người cần giúp đỡ và bạn là người phù hợp. Không phải mọi @channel. Không phải mọi @here. Những trường hợp cụ thể mà chuyên môn của bạn thực sự có liên quan – và ngay cả khi đó, chỉ khi không ai khác có thể trả lời.
Mọi thứ khác – chuyển đổi trạng thái, tin nhắn bot tự động, phản ứng emoji "nghe hay đấy", CI qua trên các nhánh bạn không theo dõi – là thông tin có thể hữu ích vào lúc nào đó nhưng không cần gián đoạn hàm bạn đang viết. Tổ hợp công nghiệp thông báo đã thuyết phục chúng ta rằng tất cả những điều này đều xứng đáng với mức độ khẩn cấp như nhau. Chúng không phải vậy.
Trong số 200 thông báo hàng ngày, chỉ có khoảng năm danh mục thực sự đáng gián đoạn những gì bạn đang làm. Phần còn lại là thông tin có thể hữu ích vào lúc nào đó – nhưng các công cụ coi mọi thứ đều khẩn cấp như nhau, có nghĩa là không có gì khẩn cấp cả.
Khung phân loại cho những người bị kiến trúc phản bội
Đây là khung bạn có thể bắt đầu sử dụng ngay hôm nay – không cần công cụ, chỉ cần kỷ luật và khoảng 20 phút thiết lập. Nó sẽ không khắc phục vấn đề kiến trúc (không có gì ngoài lớp khử trùng lặp có thể làm điều đó), nhưng nó sẽ ngăn chảy máu trong khi bạn đánh giá các giải pháp dài hạn.
Quét hai lần mỗi ngày: Thay vì kiểm tra thông báo liên tục, hãy gộp chúng thành hai lần quét – một lần vào giữa buổi sáng, một lần vào giữa buổi chiều. Trong mỗi lần quét, hãy xem thông báo GitHub, hộp thư Linear và tin nhắn chưa đọc Slack, và sắp xếp mỗi cái vào một trong ba nhóm:
| Nhóm | Quy tắc | Hành động | |--------|------|--------| | Hành động ngay | Có người bị chặn, có thứ gì đó hỏng, hoặc quyết định cần bạn | Xử lý ngay | | Gộp lại | Quan trọng nhưng không nhạy cảm về thời gian | Thêm vào danh sách "trả lời sau", xử lý vào cuối ngày | | Lưu trữ | Chat bot, cập nhật trạng thái, thread đã giải quyết, trùng lặp | Đánh dấu đã đọc, tiếp tục cuộc sống |
Đặt mặc định cấp kênh trong Slack: Đối với mỗi kênh, hãy quyết định: đây có phải là kênh "hành động ngay" (kênh làm việc của nhóm, kênh sự cố) hay kênh "gộp lại" (thông báo chung, cập nhật xuyên nhóm)? Tắt tiếng các kênh gộp lại và chỉ kiểm tra chúng trong các lần quét. Vâng, về mặt kỹ thuật đây là tắt tiếng, thứ mà tôi vừa dành hai đoạn để chế nhạo – sự khác biệt là bạn vẫn kiểm tra chúng theo lịch trình thay vì giả vờ chúng không tồn tại.
Sử dụng bộ lọc thông báo GitHub: Đánh dấu trang github.com/notifications?query=reason:review-requested – URL đó chỉ hiển thị các PR review được giao cho bạn một cách rõ ràng, loại bỏ hoàn toàn tiếng ồn từ đăng ký/CI. Đối với email, GitHub bao gồm reason header (review_requested, mention, subscribed, ci_activity) mà bạn có thể lọc: tự động lưu trữ "subscribed" và "ci_activity" và bạn sẽ không mất thứ gì bạn thực sự cần. Thực tế là GitHub chôn metadata hữu ích này trong các header email thay vì hiển thị nó trong giao diện thông báo cho bạn biết tất cả về mức độ suy nghĩ được đầu tư vào phía tiêu thụ của các hệ thống này.
Phương pháp này sẽ không bắt được các tín hiệu theo ngữ cảnh (nhớ bình luận Figma đó đã phá hủy PR của tôi không? Quét hai lần mỗi ngày cũng sẽ không bắt được nó). Nhưng nó sẽ cắt giảm tiếng ồn 60 đến 70 phần trăm, đủ để ngăn chặn alt-tab liên tục trong khi bạn đánh giá liệu vấn đề có đáng để giải quyết thật sự không.
Lớp khử trùng lặp thực sự cần làm gì
Đây là nơi mọi thứ trở nên thú vị về mặt kiến trúc – và nơi tôi ngừng nghĩ về điều này như một vấn đề cài đặt thông báo và bắt đầu nghĩ về nó như một vấn đề phân loại.
Phương pháp đơn giản là khớp từ khóa và phát hiện đề cập. Nếu tên bạn xuất hiện, hãy hiển thị nó. Nếu đó là yêu cầu review được giao cho bạn, hãy hiển thị nó. Điều này bắt được các trường hợp rõ ràng nhưng hoàn toàn bỏ lỡ những trường hợp theo ngữ cảnh – quyết định thiết kế trong một thread không ai @-đề cập bạn vì họ không nhận ra bạn đang xây dựng component mà nó ảnh hưởng. (Cái đó sẽ ám ảnh tôi một lúc.)
Những gì bạn thực sự cần là đồ thị tri thức về các mối quan hệ: nhiệm vụ nào là của bạn, PR nào liên quan đến issue nào, thread Slack nào nói về tính năng nào, người nào thường cần ý kiến của bạn về chủ đề gì. Khi một tín hiệu mới đến – tin nhắn Slack, sự kiện GitHub, chuyển đổi Linear – bạn phân loại nó theo đồ thị đó. Không phải "điều này có đề cập đến Chris không?" mà là "điều này có ảnh hưởng đến thứ gì đó Chris đang tích cực làm việc, đang chờ đợi, hoặc chịu trách nhiệm không?"
Phân loại cần phân chia thành điều gì đó như:
| Phân loại | Ý nghĩa | Hành động | |---------------|---------------|--------| | Khẩn cấp | Bạn đang chặn ai đó, hoặc thứ gì đó bị hỏng | Hiển thị ngay lập tức | | Quan trọng | Ảnh hưởng đến công việc hiện tại của bạn, nhưng không nhạy cảm về thời gian | Gộp vào bản tóm tắt hàng ngày | | Thông tin | Tốt khi biết, không cần hành động | Có thể truy cập nếu bạn tìm kiếm | | Tiếng ồn | Trùng lặp, chat bot, thread đã giải quyết | Lọc ra hoàn toàn |
Phần khó là độ tin cậy phân loại không phải nhị phân. Tin nhắn Slack trong kênh bạn chưa bao giờ ghé thăm vẫn có thể khẩn cấp nếu nó tham chiếu một issue được giao cho bạn. Thông báo GitHub về repo bạn chưa chạm đến trong nhiều tháng có thể quan trọng nếu ai đó vừa mở lại một lỗi bạn nghĩ đã được sửa. Bạn cần hai lớp hoạt động phối hợp: lớp chuẩn hóa sự kiện băm mỗi webhook đến theo khóa tổng hợp – repo, ID issue, actor, loại sự kiện – và kiểm tra nó với cửa sổ khử trùng lặp TTL (về cơ bản là cửa sổ trượt của các dấu vân tay sự kiện gần đây), và phía sau đó là đồ thị tri thức quan hệ trực tiếp ánh xạ quyền sở hữu nhiệm vụ, liên kết PR, người tham gia thread và các mô hình hoạt động gần đây. Về cơ bản bạn đang xây dựng mô hình đọc của toàn bộ trạng thái làm việc của nhóm, được cập nhật gần thời gian thực, và truy vấn trên mỗi tín hiệu đến. Lớp khử trùng lặp bắt các trùng lặp rõ ràng. Đồ thị tri thức trả lời câu hỏi khó hơn: "điều này có liên quan đến bạn cụ thể, ngay bây giờ không?"
Vòng lặp phân loại cốt lõi xử lý tốt các trường hợp rõ ràng, và điều đó một mình đã cắt giảm đáng kể tiếng ồn – nhưng các tín hiệu thực sự mơ hồ (nơi bạn không đủ tự tin để chặn nhưng cũng không đủ tự tin để hiển thị) vẫn là vấn đề còn mở. Chúng tôi đang thử nghiệm gộp những cái đó vào bản tóm tắt "có thể", nhưng tôi sẽ không giả vờ rằng chúng tôi đã giải quyết được.
Điều gì thay đổi khi vòi nước ngừng phun
Điều tôi không mong đợi – tôi thực sự nghĩ lợi ích chỉ là "ít thông báo hơn" – là mối quan hệ của bạn với các công cụ của bạn thay đổi sâu sắc như thế nào khi chúng ngừng la hét vào mặt bạn.
Khi mỗi thông báo có thể quan trọng, bạn phát triển sự lo lắng mức thấp về số lượng chưa đọc. Thanh bên Slack với tên kênh in đậm. Chuông GitHub. Hộp thư Linear. Bạn kiểm tra liên tục, không phải vì bạn mong đợi điều gì khẩn cấp, mà vì chi phí bỏ lỡ điều gì đó cảm thấy cao hơn chi phí kiểm tra 50 thứ hóa ra là tiếng ồn. Tôi đã từng alt-tab sang Slack giữa việc viết chữ ký hàm và thân của nó. Không phải quyết định có ý thức – chỉ là phản xạ, giống như bạn kiểm tra gương ở đèn đỏ.
Tự gián đoạn phòng ngừa thực sự còn tệ hơn bản thân các thông báo, vì bạn đang phá vỡ sự tập trung của chính mình trước khi bất kỳ thông báo nào đến. Bạn đang sống trong trạng thái chú ý một phần vĩnh viễn, và bạn có thể cảm nhận điều đó trong code bạn viết – review nông cạn hơn, lựa chọn kiến trúc an toàn hơn, con đường ít kháng cự nhất thay vì phương pháp thực sự đúng, vì bạn không tin rằng bạn sẽ có 45 phút không bị gián đoạn để suy nghĩ về nó.
Khi vòi nước ngừng phun – khi bạn tin tưởng rằng các tín hiệu quan trọng sẽ tìm thấy bạn và tiếng ồn sẽ không – phản xạ đó mờ dần. Không ngay lập tức, vì thói quen cũ ngoan cố. Nhưng trong vài tuần bạn nhận thấy rằng bạn đang dành nhiều thời gian hơn trong trình soạn thảo mà không có alt-tab liên tục. Bạn bắt đầu hoàn thành những suy nghĩ. Bạn viết code tốt hơn, không phải vì bạn đột nhiên trở nên thông minh hơn, mà vì bạn đã ngừng tình nguyện chuyển đổi ngữ cảnh 30 lần mỗi giờ thay mặt cho hệ thống thông báo chưa bao giờ yêu cầu bạn làm vậy.
Ngừng chết đuối trong thông báo. Sugarbug phân loại mỗi tín hiệu từ Linear, GitHub và Slack theo mức độ liên quan – và chỉ hiển thị những gì thực sự cần bạn.
Q: Sugarbug có giảm thiểu thông báo quá tải từ Linear, GitHub và Slack không? A: Có. Sugarbug kết nối với Linear, GitHub và Slack qua API và phân loại mỗi tín hiệu theo mức độ khẩn cấp và mức độ liên quan. Thay vì chuyển tiếp mọi thông báo, nó chỉ hiển thị những thông báo cần sự chú ý của bạn – thường giảm hàng trăm thông báo hàng ngày xuống còn một số ít thực sự cần bạn.
Q: Sugarbug có thể ưu tiên thông báo PR của GitHub dựa trên những gì tôi đang làm không? A: Sugarbug xây dựng đồ thị tri thức về các nhiệm vụ, PR và cuộc trò chuyện của bạn. Nó biết PR nào liên quan đến công việc hiện tại của bạn và hiển thị các yêu cầu review, xung đột merge và lỗi CI cho những PR đó trước – trong khi lặng lẽ lưu trữ phần còn lại.
Q: Sugarbug khác gì so với cài đặt thông báo tích hợp sẵn của Slack? A: Cài đặt của Slack cho phép bạn tắt tiếng kênh hoặc đặt từ khóa, nhưng không thể hiểu ngữ cảnh trên nhiều công cụ. Sugarbug đọc Linear, GitHub và Slack cùng nhau, vì vậy nó biết rằng một thread Slack về PR bạn đã viết là khẩn cấp – ngay cả khi nó ở trong kênh bạn đã tắt tiếng.
Q: Chi phí thực sự của việc quá tải thông báo đối với đội ngũ kỹ thuật là gì? A: Nghiên cứu của Gloria Mark tại UC Irvine cho thấy cần khoảng 23 phút để lấy lại sự tập trung sâu sau khi bị gián đoạn. Ngoài các thông báo bản thân, hành vi kiểm tra liên tục mà chúng tạo ra làm phân mảnh sự tập trung liên tục mà công việc kỹ thuật phức tạp đòi hỏi.
Nếu thông báo của đội ngũ kỹ thuật của bạn đã vượt qua ranh giới từ "được thông báo" sang "lo lắng", đó có lẽ là dấu hiệu kiến trúc cần sửa chữa, không phải tùy chọn thông báo của bạn.