Tìm kiếm
40 kết quả cho “fail open”. Tìm không phân biệt dấu.
- Accelerating Search and Ingestion with High-Performance gRPC in OpenSearch Bài tóm tắt · Uber · 2026
…10,5 ms; độ trễ index tối đa của M3 −20–35% (quan trọng lúc failover); job Spark nạp index theo lô chạy nhanh hơn 20–35%. Vector search hưởng nhiều nhất vì vector trong JSON được s…
- Open Sourcing Coinbase's Secure Deployment Pipeline (Odin) Bài tóm tắt · Coinbase · 2018
…ate là dừng ngay) → CleanUpSuccess (xoá ASG cũ) hoặc CleanUpFailure (xoá ASG mới). Kết thúc ở Success, FailureClean, hoặc FailureDirty (dọn thất bại, cần alert; theo bài là không n…
- Large-Scale Automated Dependency Analysis Across Uber's Service Mesh Bài tóm tắt · Uber · 2026
…là gián tiếp) vì chúng đổi liên tục. Biết phụ thuộc nào là fail-close (hỏng là kéo service gọi hỏng theo, lan tới gốc) và nào là fail-open cho phép alert theo phụ thuộc, tìm nguyê…
- The Consul outage that never happened Bài tóm tắt · GitLab · 2019
…ck cùng lỗi thì GCP load balancer gửi traffic tới mọi node (fail-open) và có thể làm ngập DB, nên rút node đó khỏi pool; vài node Chef client tự bật lại vì đang giữa một lần chạy;…
- Uber's Rate Limiting System Bài tóm tắt · Uber · 2026
…i hợp toàn cục trong vài giây; control plane mất thì client fail open . - Từ token bucket sang drop theo tỉ lệ: bản đầu dùng token bucket ở mỗi proxy (tốc độ nạp token theo tỉ lệ t…
- Scaling your API with rate limiters Bài tóm tắt · Stripe · 2017
…: - Gắn vào middleware an toàn: lỗi code hay Redis chết thì fail open , API vẫn chạy. - Lỗi rõ ràng cho người dùng (429 hay 503 tuỳ trường hợp), thông điệp hành động được. - Kill s…
- An AKS Performance Journey: Part 2 — Networking It Out Bài tóm tắt · ASOS · 2021
…nt chờ timeout 5 giây rồi thử lại. Kiểm bằng counter insert failed của conntrack -S . SNAT cũng có race tương tự khi cấp cổng; cờ --random-fully cho MASQUERADE vào kube-proxy từ 9/…
- Prefetch Caching of Items at eBay Bài tóm tắt · eBay · 2020
…tới 3 ngày, scale tới TB. Vì có đường quay về, hệ được phép fail-open : không cần bền, chấp nhận nhất quán cuối trong vài trăm ms trước khi user bấm, không cần replica trong cùng d…
- From One Horizontal Scaling Controller to Many: Evolving Uber's Compute Platform Bài tóm tắt · Uber · 2026
…uyết số replica (Up) và một bên áp và báo (UDC). - Từ 2023, failover đổi cách: Uber chạy active-active giữa các region; khi failover, region còn lại phải có đủ compute rảnh. Cách c…
- Analysis of recent downtime & what we're doing to prevent future incidents Bài tóm tắt · Asana · 2019
…1/8), 34 phút (13/8). Kỳ vọng thường lệ: phần cứng hỏng thì failover sang hot spare mất vài phút, ứng dụng retry. - Có cơ chế chống phản hồi dương/sụp dây chuyền do quá tải ở nơi k…
- Scaling Kubernetes to 2,500 nodes Bài tóm tắt · OpenAI · 2018
…ưu trữ etcd (mặc định 2 GB): etcd ngừng nhận ghi → mọi node fail health check → autoscaler quyết định xoá toàn bộ worker . Họ tăng giới hạn kích thước. - Scheduler: chính sách mặc…
- Etsy's Journey to TypeScript Bài tóm tắt · Etsy · 2021
…kiểu mà không phải sửa; đổi API gây vỡ client thì kiểm kiểu fail trước production. - Hiệu năng kiểm kiểu: editor mất gần nửa phút để hiện kiểu; kiểm toàn codebase (cả file chưa chu…
- Lessons in resilience at SoundCloud Bài tóm tắt · SoundCloud · 2016
…ác module có sẵn của Finagle thành chính sách cho client: - Failure accrual : chính sách thành công theo cửa sổ (thời gian hoặc số request), tỉ lệ thành công tối thiểu, thời gian đ…
- Stack Overflow: How We Do Monitoring - 2018 Edition Bài tóm tắt · Stack Overflow · 2018
…cuối tag engine nạp dữ liệu từ DB; - Fastly health check để failover lần lượt: ISP chính NY → ISP phụ NY → ISP chính Colorado → ISP phụ Colorado. Pingdom kiểm tra từ bên ngoài. - M…
- 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…
- 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…
- 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…
- 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:
- 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 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…
- 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:
- 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…
- 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…
- 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ự…
- 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:
- 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:
- Tracing phân tán và log theo request Chủ đề
Khi một request đi qua hàng chục service, metric của từng service cho biết có chậm, log của từng service cho biết từng mảnh; không cái nào trả lời "request này chậm vì đâu" hay "trang này tốn bao nhiêu". Tracing phân…
- 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:
- 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.
- 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ố…
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.
- 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ả…
- 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ỡ:
- 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…
- Atlassian Công ty Thành viên
Atlassian lên AWS năm 2016. Tenant Context Service (ánh xạ tenant → vị trí, gọi nhiều lần trong mỗi request) được tối ưu qua bốn bài học "không có phép màu": DynamoDB, load balancer, cache, client . Cùng năm 2019, nền…
- The Chubby lock service for loosely-coupled distributed systems Bài tóm tắt · Google · 2006
…đã thôi dùng. Lease giữ cache hợp lệ chỉ bằng keep-alive. - Failover có grace period: master mới bầu xong thì client tiếp tục session nếu kịp trước khi lease cục bộ hết; bầu lâu th…
- WhatsApp Công ty Thành viên
WhatsApp là ca hiếm: blog kỹ thuật gần như chỉ kể hai giai đoạn, và hai giai đoạn ấy giải hai bài khác hẳn nhau. Giai đoạn Erlang (2011–2014) là câu chuyện tối ưu một hệ nhỏ người: năm 2012, một server FreeBSD + Erlang…