Tìm kiếm
40 kết quả cho “Canary”. Tìm không phân biệt dấu.
- Canary rollouts: upgrade models in production without downtime Bài tóm tắt · Together AI · 2026
…Độ khó: Trung bình — [bài gốc](https://www.together.ai/blog/canary-rollouts-upgrade-models-in-production-without-downtime) Bài của nhà cung cấp, mô tả tính năng rollout của nền tản…
- Scaling Production Globally: Solving observability problems for developers (Part-2) Bài tóm tắt · Achievers · 2022
…iệu nội bộ: mọi người sở hữu độ tin cậy, không riêng SRE. - Canary có phân tích: Argo Rollouts truy vấn New Relic để quyết định canary có gây lỗi không, tự rollback; developer chọn…
- Improving how we deploy GitHub Bài tóm tắt · GitHub · 2021
…in nhắn, developer không theo dõi được thay đổi của mình. - Canary chỉ có một tầng 2% traffic , nên nhiều lỗi lọt qua tới 100% rồi mới phải mở sự cố và rollback. - Mỗi bước phải gõ…
- Atlas: Our journey from a Python monolith to a managed platform Bài tóm tắt · Dropbox · 2021
…úc chuyển. - Vận hành tự động: mỗi service có ba deployment canary/control/production; control khởi động lại bản cũ cùng lúc với canary để so công bằng (giống Kayenta), tự dừng và…
- Production testing with dark canaries Bài tóm tắt · LinkedIn · 2020
…cần input feature khác nhau mỗi ngày. Thay đổi chính - Dark canary: instance nhận bản sao traffic của instance thật, response bị bỏ, nên người dùng không bị ảnh hưởng dù dark canar…
- Auditing content features in FollowFeed Bài tóm tắt · LinkedIn · 2019
…DFS (Gobblin). Response kèm feature được lấy từ broker dark canary (không phục vụ traffic thật) để không thêm tải lên node thật, và chỉ lấy mẫu 0,1% vì có hàng triệu response mỗi g…
- Argo Rollouts at scale: Bringing Automated Rollbacks to 2,100+ services at Monzo Bài tóm tắt · Monzo · 2022
…Argo Rollouts (controller Kubernetes). Chiến lược ban đầu: canary cơ bản , lên hết pod nhanh rồi phân tích metric và rollback tự động nếu cần. - Luật toàn cục dùng chung ngưỡng vớ…
- Scaling Slack's Job Queue Bài tóm tắt · Slack · 2017
…ng (đọc rồi bỏ); đếm và so số job qua từng chặng; heartbeat canary mỗi phút cho mọi partition (50 cụm Redis, 1.600 partition) có alert theo luồng và thời gian; bật nội bộ vài tuần…
- Advancing Our Chef Infrastructure: Safety Without Disruption Bài tóm tắt · Slack · 2025
…mote: đầu giờ đẩy lên sandbox và dev; từ phút 30, prod-1 là canary nhận phiên bản mới nhất mỗi giờ (để lỗi lộ ra gần lúc được đưa vào, với thay đổi nhỏ); prod-2 → prod-6 đi theo re…
- How We Improved Our Performance Using ElasticSearch Plugins: Part 1 Bài tóm tắt · Tinder · 2019
…y trình phát hành script: (1) staging thử thủ công; (2) cụm canary chép dữ liệu production để bắt dữ liệu lệch schema lịch sử (trường ngày khi là chuỗi ISO, khi là UNIX timestamp);…
- How we achieved independent deployments in a micro-frontend architecture Bài tóm tắt · Allegro · 2026
…g ở đó). - opbox-web tự deploy ba lần mỗi ngày làm việc qua canary 0% → 1% → 10% (mỗi bước 10 phút) → 100%, dừng tự động khi có lỗi hay sự cố đang diễn ra; lỗi render được alert th…
- A postmortem of three recent issues Bài tóm tắt · Anthropic · 2025
…ùng benchmark, safety eval, metric hiệu năng, spot check và canary; nhưng eval không bắt được suy giảm người dùng thấy, một phần vì model thường tự gỡ được lỗi lẻ. - Ba lỗi cho tri…
- Meet Bandaid, the Dropbox service proxy Bài tóm tắt · Dropbox · 2018
…hàng có weight, kích thước, rate limit, priority: dùng cho canary theo tỉ lệ (90/10, đổi trong vài giây nhờ hot reload) và cô lập route quan trọng với route phụ trên cùng host. De…
- GitHub Enterprise Cloud with data residency: How we built the next evolution of GitHub Enterprise using GitHub Bài tóm tắt · GitHub · 2024
…t môi trường data residency nội bộ) → test tự động và tay → canary (load balancer chuyển dần phần trăm traffic github.com) → toàn bộ github.com → deploy và kiểm tra data residency…
- Rethinking Netflix's Edge Load Balancing Bài tóm tắt · Netflix · 2018
…WE - Tác động vận hành: phân phối request không còn đều nên canary phải so RPS kèm CPU; nhóm deploy mới có regression nhận dưới 50% traffic; phát hiện server lạc loài khó hơn vì ch…
- 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:
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…
- 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:
- 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…
- 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…
- Quản lý fleet và migrate code hàng loạt Chủ đề Thành viên
Khi số component (repo, service, pipeline, thư viện) tăng nhanh hơn số kỹ sư, chi phí của mỗi thay đổi xuyên suốt (nâng thư viện, vá bảo mật, đổi API nội bộ, khai tử dataset) tỉ lệ với số component chứ không với độ khó…
- 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:
- Độ 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.
- 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:
- 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,…
- 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.
- 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.
- 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:
- 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:
- 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…
- 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…
- Together AI Công ty Thành viên
Nhà cung cấp hạ tầng chạy model mở. Hai nguồn trong wiki (2026) đều là bài mô tả tính năng của chính họ cho Dedicated Model Inference: autoscaling theo metric của engine, với thí nghiệm cho thấy trên cùng tải chỉ tín…
- Building an Effective Test Pipeline in a Service Oriented World Bài tóm tắt · Airbnb · 2020
…chạy deep integration test (số lượng ít hơn), rồi Automatic Canary Analysis sau khi lên canary. Có pipeline khẩn cấp đi thẳng production, chỉ cho bản vá gấp. - Hai quy tắc: test cấ…
- Canva incident report: API Gateway outage Bài tóm tắt · Canva · 2024
…hơn 270.000 request của user Đông Nam Á cùng chờ một luồng. Canary không phát hiện gì, vì request chưa xong thì không tính là lỗi . 3. 9:07: asset tải xong, 270.000 request hoàn tấ…
- Dropbox Công ty Thành viên
Dropbox luôn là hybrid: metadata ở data center riêng, nội dung file trên S3. Ở ~500 PB họ tự xây Magic Pocket, theo Dropbox vì hiệu năng và unit economics . Cái giá kèm theo là phải tự dựng cả backbone và edge network .…
- Achievers Công ty Thành viên
Để mở rộng sang nhiều region với data residency và có failover giữa các cụm GKE, Achievers chuyển từ Kong sang Istio làm cả gateway lẫn service mesh (migration xong cuối 2020) và gặp một loạt vấn đề do sidecar . Phần 2…
- 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…