Tìm kiếm
40 kết quả cho “Shadow”. Tìm không phân biệt dấu.
- 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…
- Me and my shadow (link!): Disaster recovery replication made easy Bài tóm tắt · Redpanda · 2026
…ộ khó: Trung bình — [bài gốc](https://www.redpanda.com/blog/shadow-linking-disaster-recovery-replication-made-easy) Bài của nhà cung cấp giới thiệu tính năng của chính họ (Shadowin…
- 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…
- 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…
- How we've evolved on-call Bài tóm tắt · Monzo · 2019
…một gồm primary (kỹ sư kinh nghiệm, biết chỉ huy sự cố) và shadow (người mới học bằng cách quan sát), đều là tình nguyện viên có trả tiền. Khi hệ thống lớn nhanh, primary khó có n…
- How We Replaced Our Data Pipeline With Zero Downtime Bài tóm tắt · Twilio · 2014
…time (với công ty viễn thông, downtime là rớt cuộc gọi): 1. Shadow (công cụ tự viết, mã nguồn mở): proxy gửi cùng request tới bản ổn định và bản mới, báo khác biệt, chỉ trả kết quả…
- How Discord Automates ScyllaDB Clusters at Scale Bài tóm tắt · Discord · 2026
…olling restart sau đổi cấu hình, mở rộng cụm, nâng OS, dựng shadow cluster (bản sao đầy đủ nhận cùng đọc/ghi như production trong thời gian ngắn) để thử bản ScyllaDB mới. Theo Disc…
- Building High Throughput Payment Account Processing Bài tóm tắt · Uber · 2026
…giảm hỏng lô khi một zone sập hay lúc deploy. - Kiểm chứng: shadow traffic production sang hệ mới; kiểm đầy đủ (mọi audit log và giao dịch được ghi, mọi request được xử lý, mọi tác…
- 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:…
- Cross Shard Transactions at 10 Million Requests Per Second Bài tóm tắt · Dropbox · 2018
…, từ lỗi bị nuốt tới lỗ hổng trong giao thức lọc khi đọc. - Shadow trên production: phiên bản "validation" của giao thức: staging ghi shadow rồi xoá ngay trong cùng transaction của…
- 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;…
- From Homegrown to Flink: Migrating a Stateful Ad Event Join at Scale Bài tóm tắt · Zalando · 2026
…ý là sai. Họ tăng pod từ 16 lên 20 GB. - Migration: - dựng shadow pipeline đầy đủ (stream và bảng riêng), chạy 4 tuần; - so tỷ lệ làm giàu event (khớp 99,9%, ngưỡng 99–101%), số l…
- Building a fault-tolerant metrics storage system at Airbnb Bài tóm tắt · Airbnb · 2026
…y và tham số không ai biết chỉnh cái nào. - Kiểm chứng bằng shadow cluster nhận traffic production lộ ra: thành phần ghi/đọc mất ổn định khi series active tăng đột biến và thiếu gu…
- Sitar-agent: Building a reliable dynamic configuration sidecar at scale Bài tóm tắt · Airbnb · 2026
…không cần tune, và đủ nhanh. Chọn SQLite. - Chuyển an toàn: shadow read (vẫn đọc Sparkey, đọc song song SQLite để so) rồi feature flag mở dần từ service ít quan trọng tới Tier 0 cu…
- 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ệ…
- 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.
- 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.
- 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.
- 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…
- 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:
- 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:
- 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…
- 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:
- 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ự…
- Độ 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:
- 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…
- 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:
- 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…
- 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ể…
- 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…
- This Rocket Ain't Stopping - Achieving Zero Downtime for Rails to Golang API Migration Bài tóm tắt · Grab · 2016
…ắc: mỗi endpoint phải qua unit test, load test, QA staging, shadow test trên production ; deploy từng endpoint một, tăng dần, rollback được ngay. - Hướng đi bị bỏ: ban đầu muốn chi…
- 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…
- 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…
- Redpanda Công ty Thành viên
Streaming tương thích Kafka, Redpanda Cloud chạy BYOC trên ba cloud. Trong sự cố GCP 12/6/2025, theo Redpanda, hàng trăm cluster không bị ảnh hưởng vì không có metadata hay dịch vụ quan trọng nằm ngoài cluster…