Tìm kiếm
37 kết quả cho “AWS outage”. Tìm không phân biệt dấu.
- Lessons Netflix Learned from the AWS Outage Bài tóm tắt · Netflix · 2011
…ttps://netflixtechblog.com/lessons-netflix-learned-from-the-aws-outage-deefe5fd0c04) Bối cảnh - 21/4/2011: sự cố lớn ở AWS US-East làm sập hoặc làm chậm nhiều website lớn. - Với Ne…
- AWS CNI lessons from a Production Outage Bài tóm tắt · Neon · 2025
…mô lớn · Độ khó: Nâng cao — [bài gốc](https://neon.com/blog/aws-cni-lessons-from-a-production-outage) Bài cuối trong series postmortem về sự cố 16/5 và 19/5/2025 ở region us-east-1…
- How Render Services Stayed Up During the AWS October Outage Bài tóm tắt · Render · 2025
…://render.com/blog/how-render-services-stayed-up-during-the-aws-october-outage) Bối cảnh - 20/10/2025: AWS us-east-1 gặp sự cố gần 15 giờ . Theo một bên giám sát mà bài dẫn, khoảng…
- A Closer Look at the Christmas Eve Outage Bài tóm tắt · Netflix · 2012
…Bài ngoài sheet. Netflix kể lại sự cố của chính một dịch vụ AWS mà họ phụ thuộc; nguyên nhân gốc trích từ postmortem của AWS. Phần tiếp: . Bối cảnh - Cuối 2012, Netflix dùng hàng t…
- Report on our investigation of the 2025-10-20 incident in AWS us-east-1 Bài tóm tắt · PlanetScale · 2025
…· Độ khó: Nâng cao — [bài gốc](https://planetscale.com/blog/aws-us-east-1-incident-2025-10-20) Bối cảnh - 20/10/2025, AWS us-east-1 gặp sự cố lớn bắt đầu từ cấu hình DNS sai ở một…
- When The Cloud Gets Dark — How Amazon's Outage Affected Airbnb Bài tóm tắt · Airbnb · 2011
…eaf8c0f162) Bối cảnh - Toàn bộ hạ tầng Airbnb năm 2011 trên AWS. Sự cố us-east tháng 4/2011: mạng ở hai AZ mất kết nối, EBS tự re-mirror nhưng không đủ capacity dự phòng, volume EB…
- Slack's Outage on January 4th 2021 Bài tóm tắt · Slack · 2021
…ủa khách khắp thế giới). - Slack đã chuyển từ một tài khoản AWS sang nhiều tài khoản và VPC riêng theo service, nối bằng AWS Transit Gateway (TGW) , dịch vụ do AWS quản lý và lẽ ra…
- A postmortem of our May 7, 2026 outage Bài tóm tắt · Coinbase · 2026
…): nhiều máy làm lạnh hỏng cùng lúc trong một data hall của AWS us-east-1 (AZ use1-az4 ). Rack tự tắt vì nhiệt, kéo theo EC2 và EBS trong toà nhà đó. Nhiều công ty khác cũng bị ảnh…
- The First ziglang.org Outage Bài tóm tắt · Zig Software Foundation · 2025
Ngày 2025-09-01, cộng đồng báo ziglang.org chậm và trả HTTP 500. Dashboard cho thấy lượng truyền dữ liệu tăng vọt trong 24 giờ trước.
- Incident review: API and Dashboard outage on 10 October 2017 Bài tóm tắt · GoCardless · 2017
Dữ liệu quan trọng nhất nằm trên Postgres 3 node: primary + 1 replica đồng bộ + 1 replica bất đồng bộ (mỗi lần ghi thành công đều có ít nhất 2 bản).
- No record left behind: How WarpStream can withstand cloud provider regional outages Bài tóm tắt · WarpStream · 2025
…. - Control plane: trạng thái chính vốn nằm trong DynamoDB (AWS) hoặc Spanner (GCP). Chuyển sang DynamoDB Global Tables nhất quán mạnh đa region hoặc Spanner đa region là gần như đ…
- How WhatsApp Grew to Nearly 500 Million Users, 11,000 cores, and 70 Million Messages a Second Bài tóm tắt · WhatsApp · 2014
…Stack: Erlang R16B01 có patch riêng, FreeBSD 9.2, Mnesia, Yaws; bare metal thuê ở SoftLayer, cấu hình hai data center. - Khoảng 550 server cộng máy dự phòng: ~150 chat server (mỗ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…
- Độ 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.
- 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…
- 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…
- 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…
- 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ỡ:
- 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…
- 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.
- 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…
- 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…
- 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:
- Netflix Công ty Thành viên
Sự cố hỏng DB năm 2008 dẫn tới 7 năm lên AWS theo hướng cloud-native . Bài kiểm tra lớn đầu tiên là sự cố AWS US-East năm 2011: kiến trúc stateless, nhiều zone, fallback chịu được, nhưng rút khỏi zone phải làm tay. Từ…
- 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…
- Neon Công ty Thành viên
Postgres serverless tách storage và compute, mỗi compute một pod Kubernetes. Sự cố 5/2025 ở us-east-1: compute rảnh không được tắt, subnet (cỡ nhỏ vì là region đời đầu) hết IP do hành vi giữ dư IP của AWS CNI; đổi cấu…
- Zig Software Foundation Công ty Thành viên
Chiều ngược với câu chuyện quen thuộc: năm 2024 ziglang.org rời S3 + CloudFront về một máy Hetzner 36 €/tháng, chấp nhận 99% uptime và dựa vào chữ ký + mirror cộng đồng . Năm 2025, sự cố đầu tiên (một bot crawl điên…
- Migrating from GitHub to Codeberg Bài tóm tắt · Zig Software Foundation · 2025
Zig ở GitHub từ git init khoảng mười năm trước. Theo Zig, chất lượng GitHub đi xuống; quan trọng nhất là GitHub Actions có lỗi lập lịch (chọn job gần như ngẫu nhiên) và không cho can thiệp tay, làm CI tắc đến mức commit…
- Active-Active for Multi-Regional Resiliency Bài tóm tắt · Netflix · 2013
…song với nhiều dự án khác) còn khó hơn, và họ dựa vào việc AWS cấp thêm capacity ở us-west-2 nhanh. Còn lại (theo Netflix) - Phase 2: tự động hoá các bước thủ công, rút ngắn thời…
- An AKS Performance Journey: Part 2 — Networking It Out Bài tóm tắt · ASOS · 2021
Sau phần 1, PLP trên AKS vẫn chậm hơn Cloud Services khoảng 100 ms ở percentile cao. Log có nhiều timeout gọi API, kèm lỗi getaddrinfo EAIAGAIN từ NodeJS và các lần chờ đúng 5 giây.
- Using Fault Injection Testing to Improve DoorDash Reliability Bài tóm tắt · DoorDash · 2022
DoorDash viết backend theo microservice; một request từ app có thể đi qua hàng chục tới hàng trăm service, nên phải xử lý lỗi một phần (một dependency chậm, lỗi, hay vừa deploy kèm bug).
- How our security team handle secrets Bài tóm tắt · Monzo · 2019
…(2019): Vault cấp credential ngắn hạn cho Cassandra và cho AWS thay vì secret tĩnh, và scale Vault theo tải. Bài học cho SWE - Phân quyền theo hành động: thêm secret mới không ngu…
- Database-per-User Architecture With Isolated Application Environments Bài tóm tắt · Neon · 2024
Bài trước trong loạt: database-per-user với môi trường ứng dụng dùng chung (một bản ứng dụng nói chuyện với DB riêng của từng khách). Bài này: môi trường ứng dụng cô lập, mỗi khách một bản sao toàn bộ hệ thống.
- How we systematically improved our reliability Bài tóm tắt · Neon · 2026
Lakebase Postgres (Neon) chạy một fleet rất lớn trên hai bề mặt (Neon và Databricks), ba cloud, hơn 30 region; mỗi region tới 15 cell (bản triển khai cô lập để scale ngang và thu nhỏ blast radius), tổng hơn 70 môi…
- Inside branch-based restores in Lakebase Postgres Bài tóm tắt · Neon · 2026
Theo Neon, restore ở Postgres managed truyền thống chậm và càng chậm khi DB càng lớn. Failover sang replica giúp khi máy chết, nhưng không giúp khi lệnh ghi sai hay DROP TABLE đã sang cả standby: lúc đó vẫn phải restore.
- Keeping Customers Streaming — The Centralized Site Reliability Practice at Netflix Bài tóm tắt · Netflix · 2020
Netflix theo mô hình service ownership ("full cycle developer"): team vận hành cái mình xây; phần lớn lỗi được team sở hữu bắt trước khi khách thấy.