Tìm kiếm
27 kết quả cho “Slack bot”. Tìm không phân biệt dấu.
- Maximum Warp: Building Migrations for Slack Enterprise Grid Bài tóm tắt · Slack · 2017
…7 · 2. Tăng trưởng · Độ khó: Trung bình — [bài gốc](https://slack.engineering/maximum-warp-building-migrations-for-slack-enterprise-grid/) Bối cảnh - Mô hình dữ liệu Slack: mọi dữ…
- Automated Incident Management Through Slack Bài tóm tắt · Airbnb · 2022
…e ai. - Người xử lý mất nhiều thời gian chuyển qua lại giữa Slack, PagerDuty và Jira để mở sự cố, gọi người và cung cấp bối cảnh. Thay đổi chính - Tự viết một bot Slack (Go) làm "p…
- Slack's Incident on 2-22-22 Bài tóm tắt · Slack · 2022
· 2022 · 3. Quy mô lớn · Độ khó: Khó — [bài gốc](https://slack.engineering/slacks-incident-on-2-22-22/) Postmortem do Incident Commander của sự cố viết. Bối cảnh - Client Slack ph…
- Flannel: An Application-Level Edge Cache to Make Slack Scale Bài tóm tắt · Slack · 2017
…7 · 2. Tăng trưởng · Độ khó: Trung bình — [bài gốc](https://slack.engineering/flannel-an-application-level-edge-cache-to-make-slack-scale/) Bối cảnh - Slack thiết kế cho team vài t…
- Implementing ChatOps into our Incident Management Procedure Bài tóm tắt · Shopify · 2018
…i thực sự kết thúc. - Bot Spy (dựa trên Lita, Ruby; nối với Slack, PagerDuty, StatusPage, GitHub qua webhook): - spy page , spy pager ack để gọi và nhận page ngay trong chat. - spy…
- Automating Code Migrations at Scale Bài tóm tắt · Allegro · 2024
Allegro có hơn 2.000 service (mỗi cái một repo). Khi thư viện nội bộ dùng chung (ví dụ Spring Boot starter của Allegro) ra bản có breaking change, mỗi team phải đọc hướng dẫn migrate rồi sửa tay: tốn thời gian, dễ sai,…
- Auditing AWS IAM for better security practices Bài tóm tắt · Postman · 2019
…IAM REST API, chạy định kỳ bằng Monitor và đẩy kết quả vào Slack. Vì sao - Quyền gắn với thực thể IAM thay đổi liên tục, nên audit phải chạy thường xuyên; làm tay 3 ngày mỗi lần t…
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Xử lý sự cố và on-call Chủ đề Thành viên
Khi hệ còn nhỏ, vài người biết hết mọi thứ; có lỗi thì người thấy đầu tiên sửa luôn. Khi có hàng trăm service và hàng trăm engineer, câu hỏi đổi khác:
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- Load shedding, rate limit và backpressure Chủ đề Thành viên
Mọi hệ đều có lúc nhận nhiều việc hơn sức làm: spike của người dùng, client nội bộ có bug, dependency chậm đi, retry dồn lại. Theo Discord, khi chạm giới hạn năng lực thì đó là bài toán kinh tế: hoặc tăng cung (thêm…
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- Chọn database theo workload Chủ đề Thành viên
Không có database tốt nhất, chỉ có database hợp với mẫu đọc/ghi ở một quy mô cụ thể. Mẫu đó thay đổi khi sản phẩm lớn lên. Ngoài ra, chuyên môn vận hành của đội cũng là một phần của "workload".
- Đổi ngôn ngữ và runtime Chủ đề Thành viên
Ngôn ngữ ban đầu được chọn để làm nhanh. Khi lớn lên, nó có thể thành nút thắt về hiệu năng, latency, hoặc tổ chức code. Có ba hướng: tối ưu runtime đang dùng, cải tiến dần, hoặc viết lại có phạm vi.
- Airbnb Công ty Thành viên
Airbnb chuyển từ một ứng dụng Rails khổng lồ sang SOA, và lộ ra chi phí test: deep integration test cho mọi service không scale, nên họ chuyển sang tháp test + CD có canary analysis . Năm 2025 với ba trụ sản phẩm, data…
- From Monitoring to Observability: Our Ultra-Marathon to a Cloud-Native Platform Bài tóm tắt · Uber · 2026
…thêm ngữ cảnh, đăng một lần rồi sửa tin khi trạng thái đổi (Slack/PagerDuty không bị trùng); mọi alert (đang bắn và đã đóng) vào một index Elasticsearch để lần lại một sự cố từ đầu…
- Macaroons Escalated Quickly Bài tóm tắt · Fly.io · 2024
…eo từng Organization (prod hai lớp, dev không cần); một bot Slack có thể duyệt request mà nền tảng không biết gì về Slack. Theo Fly.io, đó là một hệ plugin cho token bảo mật . - Tr…
- Building a fault-tolerant metrics storage system at Airbnb Bài tóm tắt · Airbnb · 2026
…- Cùng đợt chuyển observability: · - Cell và blast radius ở Slack:…
- Lessons learned in incident management Bài tóm tắt · Dropbox · 2021
…Công cụ tự xây DropSEV : ai cũng khai báo được, tự tạo kênh Slack, email, ticket Jira và khung postmortem. Thay đổi chính Phát hiện - Hệ metric Vortex (thiết kế lại 2018): trễ inge…
- Postmortem: Removing all users from github.com/trivago Bài tóm tắt · trivago · 2021
…group → 16:17 email "bạn đã bị gỡ" tới, người dùng báo trên Slack → 16:23 phát hiện group mất → 16:33 tạo lại group → 17:32 mọi người được mời lại. Sự cố 1 giờ 19 phút ; mỗi người…
- How we evolved our code: Notion's ratcheting system using custom ESLint rules Bài tóm tắt · Notion · 2025
Codebase lớn dần thì pattern cũ tích lại. Cách thường làm là vài người chạy một đợt migrate lớn trên cả codebase, dễ gây lỗi và lấy người khỏi việc sản phẩm. Notion muốn đi tới trạng thái lý tưởng (ví dụ "không còn…
- Scalability and Load Testing for VALORANT Bài tóm tắt · Riot Games · 2020
…test chỉ "qua" khi mọi metric (New Relic, Grafana, alert về Slack) nằm trong ngưỡng suốt thời gian chạy (test 2 triệu người kéo dài 3 giờ). - Các thay đổi kiến trúc mà load test đò…