Tìm kiếm
40 kết quả cho “thông báo khử trùng”. Tìm không phân biệt dấu.
- Bảo mật hạ tầng và quản lý secret Chủ đề Thành viên
Khi hệ thống lớn lên, số credential (mật khẩu DB, API key, SSH key, token, cookie phiên) tăng theo số service, pipeline, nhà cung cấp, và chúng rải vào code, cấu hình, hệ build, log. Các nguồn trong wiki cho thấy kẻ tấn…
- Building Slack's Anomaly Event Response Bài tóm tắt · Slack · 2025
…ponse ) kèm loại anomaly và session id gốc; email cho user, thông báo cho Org Owner/Security Admin theo cấu hình, gộp khi một người giữ nhiều vai trò. Vì sao - Theo Slack, đưa phản…
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- 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…
- 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…
- Infrastructure monitoring with Prometheus Bài tóm tắt · Zerodha · 2020
…orter HTTP nhúng cho metric RED; exporter đọc API AWS (băng thông và sức khoẻ đường P2P, chính sách snapshot EBS). Vì sao - Theo Zerodha: giữ ít phụ thuộc ở ứng dụng quan trọng, và…
- 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…
- 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…
- 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:
- 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:
- 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…
- 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.
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- Xác thực và phân quyền (authn/authz) Chủ đề Thành viên
Ở monolith, mỗi dữ liệu thường chỉ có một đường vào, nên kiểm tra quyền nằm ngay đó: một hàm hasaccess?, một API mỗi resource. Khi hệ thống tách thành nhiều service, nhiều client, nhiều loại token, cả hai nửa đều vỡ:
- Stream processing Chủ đề Thành viên
Khi batch hằng ngày hay hằng giờ không còn đủ tươi (chi tiêu quảng cáo phải dừng đúng lúc chạm ngân sách, dashboard MRR không được trễ 24 giờ, alert phải bắn khi contest sắp đầy), hệ phải tính liên tục trên luồng sự…
- Nền tảng ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng hỏng:
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) Chủ đề Thành viên
Lỗi trong hệ phân tán là chắc chắn (máy chết, zone mất, dependency chậm, cấu hình sai), nhưng phần lớn lỗi nằm ở những tổ hợp hiếm mà test chức năng không chạm tới. Bài toán là chủ động gây lỗi để biết hệ thống phản ứng…
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) Chủ đề Thành viên
Một quỹ định lượng hay công ty market making sống bằng vòng nghiên cứu: đặt giả thuyết → lấy dữ liệu → tạo feature → train model hay dựng tín hiệu → backtest/mô phỏng → đưa vào giao dịch thật → lặp lại. Theo Optiver, độ…
- Batching và khấu hao round-trip Chủ đề Thành viên
Nhiều nút thắt không nằm ở việc mỗi thao tác tốn bao nhiêu công, mà ở chi phí cố định trả cho mỗi thao tác: một round-trip mạng, một lần fsync, một PUT lên object storage, một syscall, một transaction. Khi chi phí cố…
- 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.
- Sharding và tách database Chủ đề Thành viên
Một database quan hệ duy nhất là điểm khởi đầu của hầu hết sản phẩm. Đến một lúc nó không chịu nổi lượng ghi, dữ liệu không còn vừa một máy, hoặc một sự cố ở DB đó làm sập mọi tính năng.
- Giao dịch phân tán và nhất quán xuyên service Chủ đề Thành viên
Với một DB quan hệ, BEGIN … COMMIT lo hết. Khi dữ liệu bị chia (shard, tách service, thêm Redis bên cạnh Postgres), một thao tác nghiệp vụ chạm nhiều nơi, và câu hỏi khó nhất trở thành "timeout rồi, việc đó đã xảy ra…
- Vector search và index ANN Chủ đề Thành viên
Search ngữ nghĩa, gợi ý và RAG quy về tìm các vector (embedding vài trăm tới vài nghìn chiều) gần một vector query. Vector không có thứ tự tự nhiên, nên B-tree hay inverted index không dùng được; ở quy mô lớn phải dùng…
- Uber Công ty Thành viên
Một vòng đủ: monolith → microservices → tổ chức lại microservices. Năm 2012–2013 Uber có hai monolith; khi lên hàng trăm kỹ sư thì tách. Lý do chủ yếu là tổ chức. Năm 2015 họ có 500+ service và phải chuẩn hoá contract…
- LinkedIn Công ty Thành viên
Bài khung là bài nhìn lại năm 2015 . LinkedIn bắt đầu năm 2003 là một monolith tên Leo. Service đầu tiên tách ra là member graph, vì đồ thị kết nối có profile tải khác hẳn; DB profile được đỡ bằng scale dọc rồi replica…
- Training Orchestrator: Unifying Model Training at Yelp Bài tóm tắt · Yelp · 2026
…step sau, log tiến độ và metric vào MLflow ở mỗi step, gửi thông báo Slack nếu cấu hình. - Step = cặp settings + hàm: loại step định nghĩa bằng schema input/output (step ra datase…
- Best Practices for Real-time Machine Learning: Alerting Bài tóm tắt · Nubank · 2022
…hiều năm vận hành model real-time ở Nubank, không kể một hệ thống cụ thể; mọi nhận định là theo Nubank. Bối cảnh - Model real-time chấm điểm theo yêu cầu, nên gặp mọi lỗi của phần…
- The Deceptively Simple Act of Writing to Disk Bài tóm tắt · ScyllaDB · 2026
…vào so với tốc độ dispatch, nên gần 1,0) có gai; tổng băng thông commitlog + memtable + compaction chỉ khoảng 12,5 GB/s trên RAID 4 NVMe khoảng 14,5 GB/s. Gai ở flow ratio nghĩa l…
- How Uber Protects Against Retry Storms Bài tóm tắt · Uber · 2026
Chỉnh cấu hình retry và retry budget giảm được ở mức từng service, nhưng chỉnh tay và không thấy được khuếch đại xuyên service qua chuỗi phụ thuộc sâu và fan-out. Gốc vấn đề: retry không biết ngữ cảnh; kiểm được bao…
- Inside Minerva: building scalable observability for eBay's monetization platform Bài tóm tắt · eBay · 2026
…ợp phí với khuyến mãi để giải thích spike, gán mức độ), gửi thông báo theo kênh (PagerDuty, email, Slack; cấu hình chung rồi ghi đè theo luật hay theo phân đoạn dữ liệu). Vì sao -…
- Rethinking Netflix's Edge Load Balancing Bài tóm tắt · Netflix · 2018
…request đang chờ; warmup tăng dần trong 90 giây đầu; decay thống kê về 0 trong 30 giây để server không bị loại vĩnh viễn. - Load test tổng hợp (Zuul 200 node → origin 20 instance…
- How we scaled reads on the Twitter Users Database Bài tóm tắt · Twitter · 2023
…er Reservation System) , theo Twitter là một trong những hệ thống loại này lớn nhất thế giới, được xây trên Gizzard , chính framework sharding MySQL từng dùng cho tweet năm 2010–20…
- A lesson in creating and using niche business DSLs at scale Bài tóm tắt · Zerodha · 2020
…t spread thành bốn). Biểu thức chỉ trả boolean nên không có thông báo lỗi riêng. Muốn thêm hàm mới phải đóng gói vào engine, tức developer vẫn phải tham gia, mất ý nghĩa của DSL ch…
- A postmortem of three recent issues Bài tóm tắt · Anthropic · 2025
…ất lượng đầu ra giảm chứ không phải lỗi 5xx, metric hạ tầng thông thường không đủ; cần kiểm tra chất lượng chạy liên tục trên production (). - Nhiều lỗi chồng nhau thì triệu chứng…
- Resiliency and Disaster Recovery with Kafka Bài tóm tắt · eBay · 2020
…phát event khi tạo, sửa, xoá; consumer chống gian lận, gửi thông báo, index search, khuyến mãi. Có hai nhóm consumer: - chỉ cần event của region mình, ít nhất một lần; - cần toàn…
- 5-year Evolution of Ele.me's Transaction System - Part 2 Bài tóm tắt · Ele.me · 2020
…so sánh; 3. sửa SQL không tương thích (sắp xếp xuyên shard, thống kê, query không có khoá shard). Team nghiệp vụ mất nhiều thời gian nhất ở bước này; 4. ghi kép, đọc dữ liệu mới; 5…