Tìm kiếm
37 kết quả cho “shadow mode”. Tìm không phân biệt dấu.
- Deploying Large-scale Fraud Detection Machine Learning Models at PayPal Bài tóm tắt · PayPal · 2021
…s://medium.com/paypal-tech/machine-learning-model-ci-cd-and-shadow-platform-8c4f44998c78) Bài đầu của một series về nền tảng shadow cho model; các phần sau (meta-learning, feature…
- Maintaining Machine Learning Model Accuracy Through Monitoring Bài tóm tắt · DoorDash · 2021
…t. - Log có predictor name ánh xạ tới model mặc định và các shadow model : shadow cũng chấm và được ghi log, đúng kỳ vọng thì được nâng thành mặc định. - Bản thứ hai, sau phản hồi:…
- Shadow Engine Recovery in NVIDIA Dynamo Bài tóm tắt · NVIDIA · 2026
…dia.com/blog/restore-llm-inference-capacity-in-seconds-with-shadow-engine-recovery-in-nvidia-dynamo/) Bài của nhà cung cấp về tính năng đang ở dạng preview; số liệu do NVIDIA tự đo…
- Multilingual message content moderation at scale (part 1) Bài tóm tắt · Bumble · 2021
…đã có. Liên quan - - Cùng công ty: · - Cùng bài toán: (cổng shadow trước khi model tham gia quyết định) · ·…
- 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:
- Production testing with dark canaries Bài tóm tắt · LinkedIn · 2020
…ice đã dùng thì vừa bền vừa quen với dev. Bài học cho SWE - Shadow traffic chỉ an toàn khi kiểm soát được side effect; phải liệt kê mọi chỗ ghi và mọi call xuống dưới. - Tính tỉ lệ…
- Uber's Rate Limiting System Bài tóm tắt · Uber · 2026
…ả hai; phạm vi toàn cầu, region hoặc zone; chế độ deny hoặc shadow (chỉ quan sát). - Kết quả, theo Uber: bỏ limiter Redis ở một service lớn làm request dồn về bucket latency thấp;…
- Scaling Slack's Job Queue Bài tóm tắt · Slack · 2017
Job queue chạy mọi việc không làm kịp trong request web: mỗi tin nhắn, push notification, unfurl URL, nhắc lịch, tính tiền. Ngày bận nhất hơn 1,4 tỉ job, đỉnh 33.000 job/giây.
- Architecting Restaurant Wait Time Predictions Bài tóm tắt · Yelp · 2019
…uan - · - Cùng công ty: - Cùng bài toán lệch train/serve: · shadow model:…
- Migrating Data Ingestion Systems at Meta Scale Bài tóm tắt · Meta · 2026
…thêm tiêu chí riêng do team phụ thuộc đặt ra. - Ba pha: 1. Shadow: job mới đọc cùng nguồn, ghi vào bảng shadow; liên tục so số dòng và checksum, sửa lỗi ở pre-production; đo quota…
- 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.
- Hạ tầng phục vụ LLM inference Chủ đề Thành viên
Phục vụ LLM giống một dịch vụ web ở chỗ cần scale theo tải, deploy phiên bản mới an toàn và phục hồi khi một process chết; nhưng ba đặc điểm làm các công cụ quen thuộc hỏng:
- 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.
- 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…
- 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:
- Thử nghiệm A/B và nền tảng experimentation Chủ đề Thành viên
Khi nhiều team cùng thay đổi một sản phẩm, "ship rồi xem metric" không còn trả lời được thay đổi nào gây ra gì. Thí nghiệm có đối chứng trả lời được, nhưng ở quy mô lớn nó thành một hệ thống: gán người dùng vào biến thể…
- 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:
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- 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…
- Độ 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.
- Đổ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.
- 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…
- 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:
- Mô hình tổ chức SRE Chủ đề
Lúc nhỏ, một team ops hay SRE tập trung trực và vận hành mọi thứ. Khi chuyển sang microservice và "you build it, you run it", team sản phẩm phải tự sở hữu service trên production, nhưng nhiều team chưa có kỹ năng, còn…
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- 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…
- PayPal Công ty Thành viên
Nguồn đầu tiên của PayPal trong wiki là về tổ chức: các team sản phẩm tự chủ cao, không có cơ quan trung tâm quy định quy trình. Từ cuối 2019 một nhóm tình nguyện liên phòng ban định nghĩa thế nào là sự cố, mức nghiêm…
- Meta Công ty Thành viên
Facebook khởi đầu trên LAMP với mỗi trường đại học một DB; mở rộng bằng Memcache, rồi TAO, rồi data center riêng, edge cạnh ISP và region nhiều toà nhà. Giai đoạn 2010–2020 là các ca góc của hệ phân tán: bất nhất cache…
- How PayPal Uses Real-time Graph Database and Graph Analysis to Fight Fraud Bài tóm tắt · PayPal · 2021
2021: hơn 400 triệu người dùng và merchant đang hoạt động, vài nghìn giao dịch thanh toán mỗi giây. Quan hệ giữa tài khoản (cùng IP, cùng thiết bị, cùng hộ gia đình, trả tiền cho nhau) là tín hiệu rủi ro mạnh, nhưng…
- Counter Service: How we rewrote it in Rust Bài tóm tắt · Grab · 2025
…ệ, cho tới khi đổi sang bản non-blocking. - Kiểm chứng bằng shadow traffic cho cả hai service. Kết quả (2025) QPS chuẩn hoá Tài nguyên --- --- --- Bản Go 1.000 20 core Bản Rust 1.0…
- NVIDIA Dynamo Snapshot: Fast Startup for Inference Workloads on Kubernetes Bài tóm tắt · NVIDIA · 2026
Inference cần scale theo tải, nhưng cold start một worker trên Kubernetes mất vài phút; trong lúc đó GPU đã cấp nhưng không sinh token, và hệ không kịp hấp thụ đỉnh tải.
- Wix Inbox Journey: 3 Approaches for Zero Downtime Database Migration Bài tóm tắt · Wix · 2021
…hi kép, lúc đầu ghi DynamoDB trong try/catch chỉ báo lỗi ( "shadow mode" , để DynamoDB "ấm" lên rồi mới đưa vào đường chính); - clone snapshot Cassandra làm nguồn migrate. Thử trên…
- Protecting our platform from spikes in usage by reducing load from the Monzo app Bài tóm tắt · Monzo · 2023
…GET với độ chính xác khoảng 90% . - Rollout an toàn: - chạy shadow mode (ghi lại quyết định nhưng vẫn tính response); - metric lên Prometheus; - chính sách nằm trong framework load…
- Shopify Công ty Thành viên
Năm 2015 không còn mua được DB to hơn nên Shopify shard, rồi phát hiện thao tác lặp mọi shard làm mất cô lập lỗi. Kiến trúc pod (mỗi request chỉ chạm một tập datastore cô lập, Pod Mover dời pod sang DR) ra đời .…
- We replaced Redis with MySQL for inventory reservations, and it scaled Bài tóm tắt · Shopify · 2026
…cy (cấu hình từ nhiều năm trước, chưa xem lại). - Cutover: "shadow mode" ghi kép Redis + MySQL, Redis vẫn là nguồn sự thật. So sánh rồi mới chuyển nguồn sự thật sang MySQL; còn kil…