Tìm kiếm
40 kết quả cho “test mode traffic”. 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
…model, thời gian nạp dữ liệu, phân phối điểm. - Hai chế độ: Test (đóng gói, deploy, audit lặp lại) và Release; model đã audit và đạt SLA thì "tốt nghiệp" lên production bằng chính…
- Production testing with dark canaries Bài tóm tắt · LinkedIn · 2020
…gốc](https://engineering.linkedin.com/blog/2020/production-testing-with-dark-canaries) Bối cảnh - Code ở LinkedIn có thể lên production trong vòng một giờ, nhiều lần mỗi ngày; cod…
- Load test và kiểm chứng capacity Chủ đề Thành viên
Trước một mốc tải chưa từng gặp (ra mắt game, tính năng mới gửi push toàn quốc, mùa giải, tăng trưởng nhanh), cần biết hệ chịu được bao nhiêu, cái gì gãy trước, và cần bao nhiêu máy. Test từng service riêng không đủ vì…
- Evolving Reddit's ML Model Deployment and Serving Architecture Bài tóm tắt · Reddit · 2021
Hệ ML của Reddit (2021) phục vụ hàng nghìn request inference mỗi giây cho feed, video, push, email. Inference nằm trong Minsky, một service Thrift Python (baseplate.py) vốn phục vụ dữ liệu relevance (độ giống giữa…
- Multilingual message content moderation at scale (part 1) Bài tóm tắt · Bumble · 2021
Bumble Inc. (vận hành Badoo và Bumble) có mặt ở 150 nước, 50 ngôn ngữ. Cần một bộ phát hiện tin nhắn độc hại (Rude Message Detector trên Badoo) chạy được mọi ngôn ngữ mà không cần biết trước ngôn ngữ của tin nhắn, để…
- Serving Machine Learning Models Efficiently at Scale at Zillow Bài tóm tắt · Zillow · 2022
…trường), hoặc ép đóng gói model theo định dạng riêng; load test của Zillow cho thấy p90/p95 của chúng kém vì đặc điểm riêng của ML serving. Thay đổi chính - Lớp người dùng: "servi…
- Scaling your API with rate limiters Bài tóm tắt · Stripe · 2017
…ất, chặn hàng triệu request mỗi tháng (nhiều nhất là script test mode chạy quá tay); hành vi giống nhau ở test và live; cho phép burst ngắn cho sự kiện real-time (flash sale). 2. C…
- Beyond synthetic testing: Capturing and replaying real database workloads at Airbnb Bài tóm tắt · Airbnb · 2026
…ài gốc](https://airbnb.tech/infrastructure/beyond-synthetic-testing-capturing-and-replaying-real-database-workloads-at-airbnb/) Bối cảnh - Fleet MySQL-compatible của Airbnb (2026):…
- 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:
- How we rebuilt Next.js with AI in one week Bài tóm tắt · Cloudflare · 2026
…ode dùng API riêng của nền tảng (Durable Objects, KV) không test được lúc dev. Thay đổi chính - Viết lại bề mặt API của Next.js trên Vite (vinext), không bọc output của Next.js: ro…
- グローバルなメルカリの検索バックエンド設計と検索基盤拡充 (Search backend for the Global App and extending the search platform) Bài tóm tắt · Mercari · 2025
…i , và dùng thời gian đó chuẩn bị phía Elasticsearch. - A/B test cho thấy với dữ liệu sản phẩm và event người dùng của Mercari (phải chuyển từ hệ event riêng sang schema GA4), kết…
- Slack's Outage on January 4th 2021 Bài tóm tắt · Slack · 2021
…d chạy cùng VPC với DB của nó để bỏ phụ thuộc vào TGW; load test provision-service thường xuyên; xem lại cấu hình health check và autoscale để không đè provision-service. Vì sao -…
- 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.
- Community-focused Feed optimization Bài tóm tắt · LinkedIn · 2019
…Recall tăng gấp đôi. Thử khoảng 100 biến thể model qua A/B test. Bài học cho SWE - Ở hệ nhiều tầng, tầng đầu nên tối ưu cho recall với chi phí thấp; độ chính xác là việc của tầng…
- Engineering the agentic SDLC Bài tóm tắt · Optiver · 2026
…. Họ chia khung làm ba tầng: workflow (phát triển, review, test, rollout, vận hành), primitive của agent (context, harness), và nền chung (đo lường, thực thi, điều phối, governanc…
- Scaling Reliable Experimentation in a Two-Sided AdTech Marketplace: ZMS Budget Split Bài tóm tắt · Zalando · 2026
…trên một tài nguyên hữu hạn là ngân sách chiến dịch . - A/B test thông thường dựa trên giả định SUTVA: biến thể của người này không ảnh hưởng kết quả của người khác. Ở đây giả định…
- A deeper dive into our May 2019 security incident Bài tóm tắt · Stack Overflow · 2021
…kiểm tra access key. Tầng dev cho phép giả danh mọi user để test, nên leo lên quyền Community Manager; dùng một route trên dev hiển thị nội dung email để lấy magic link khôi phục t…
- 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.
- 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…
- Coding agent trong engineering (migrate, viết lại, chạy song song, quyền hạn) Chủ đề Thành viên
Từ 2026 các công ty bắt đầu giao cho coding agent những việc trước đây là dự án nhiều tuần: migrate hàng trăm module hay dataset, dọn feature flag, viết lại cả framework hay app. Agent viết nhanh, nhưng ba thứ không tự…
- 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…
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- 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:
- 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:
- 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ể…
- Độ 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.
- 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…
- 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…
- 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:
- 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…
- 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…
- Đổ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.
- Kiến trúc frontend Chủ đề Thành viên
Frontend bắt đầu là vài trang render ở server; lớn lên thành ứng dụng có trạng thái, nhiều team cùng sửa, và mỗi tính năng thêm vào là thêm byte phải tải. Ba trục lặp lại trong các nguồn: render ở đâu (server, client,…
- Mã hoá đầu cuối và hệ thống mà server không được đọc Chủ đề Thành viên
Một hệ thống bình thường giả định server thấy hết dữ liệu: server fan-out tin nhắn, lưu bản sao lưu, đồng bộ thiết bị, thu log để vận hành, chạy model, chống lạm dụng. Khi sản phẩm hứa chính nhà vận hành cũng không đọc…
- 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:
- 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…
- 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…
- Hạ tầng tìm kiếm Chủ đề Thành viên
Lúc đầu, tìm kiếm là LIKE trên database hoặc một thư viện (Lucene) nhúng trong app. Khi dữ liệu và tính năng tăng, search thành một hệ có trạng thái riêng, khác database ở mấy điểm:
- 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".
- 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…