Tìm kiếm
40 kết quả cho “Rollback”. Tìm không phân biệt dấu.
- Argo Rollouts at scale: Bringing Automated Rollbacks to 2,100+ services at Monzo Bài tóm tắt · Monzo · 2022
…dài hạn là GitOps (deploy theo merge vào main). Theo Monzo, rollback tự động là điều kiện tiên quyết, vì deploy sẽ bất đồng bộ hơn. Thay đổi chính - Yêu cầu: trong suốt với kỹ sư (…
- Deployment At Scale: Dream11's In-House Blue-Green Deployment Platform "OneClick" Bài tóm tắt · Dream11 · 2022
…cả trong giờ cao điểm. Cần deploy thường xuyên mà ít lỗi và rollback được. - Chọn "seamless blue-green" : stack mới (green) nhận traffic dần dần thay vì chuyển một lần. - Chuyển tr…
- Making Order in CI/CD Mess Bài tóm tắt · Wix · 2020
…n mới nhất ở mỗi bậc, 20 sự kiện production gần nhất (RC/GA/rollback) toàn cục và theo build, biểu đồ hiệu năng; nút Trigger RC và Trigger GA/Rollback. Mọi thao tác production đi q…
- How Slack Rebuilt Notifications Bài tóm tắt · Slack · 2026
…"mentions" ở tầng DB là quá rủi ro cho tương thích ngược và rollback. Thay vào đó: - Thêm preference mới desktop push enabled , là thứ duy nhất quyết định có push trên desktop hay…
- Database Federation: Decentralized and ACL-Compliant Hive Databases Bài tóm tắt · Uber · 2026
…cũ, scale tới hàng chục nghìn dataset với migrate từng cái, rollback và retry. - Đổi con trỏ thay vì đồng bộ dữ liệu liên tục: dataset Hive chỉ là metadata trong Hive Metastore (HM…
- Open Sourcing Screwdriver, Yahoo's Continuous Delivery Build System for Dynamic Infrastructure Bài tóm tắt · Yahoo · 2017
…ời gian sau build để engineer vào xem thay đổi giao diện. - Rollback dễ: chạy lại một phase của pipeline tại trạng thái đã lưu (git SHA + metadata deploy), dựa vào PaaS để deploy.…
- Nebula as a Storage Platform to Build Airbnb's Search Backends Bài tóm tắt · Airbnb · 2016
…ge/compact do từng ứng dụng cấu hình. - Versioning cho phép rollback về snapshot tốt khi dữ liệu hỏng. Thay đổi được phát lại thành stream qua DynamoDB Streams → Kinesis consumer →…
- Safeguarding Dynamic Configuration Changes at Scale Bài tóm tắt · Airbnb · 2026
…rường nào, zone nào, bao nhiêu phần trăm pod, tiến thế nào, rollback thế nào; định tuyến config đang thử tới một lát subscriber), data plane (lưu, là nguồn sự thật của giá trị và v…
- How we deliver mobile app updates faster Bài tóm tắt · Mercari · 2025
…y đổi từ nhánh release tự backmerge vào master; Android nay rollback được bản đã phát hành, iOS thì không. - Kế hoạch: thử Xcode Cloud làm đường dự phòng cho pipeline; thêm đo hiệu…
- The Story of Apollo – Amazon's Deployment Engine Bài tóm tắt · Amazon · 2014
…ợc, trước khi ảnh hưởng availability; lần deploy sau (ví dụ rollback nhanh) cập nhật các máy lỗi trước . - Lịch sử deploy theo từng máy: bản nào lên production lúc nào, máy nào đan…
- A postmortem of three recent issues Bài tóm tắt · Anthropic · 2025
…ví dụ chèn ký tự Thái hay Trung vào câu trả lời tiếng Anh). Rollback ngày 2/9; thêm test phát hiện ký tự bất thường vào quy trình deploy. 3. Lỗi tiềm ẩn trong compiler XLA:TPU (25–…
- Multilingual message content moderation at scale (part 1) Bài tóm tắt · Bumble · 2021
…; "hàng chục nghìn tin nhắn mỗi giây" (2021). - Giám sát và rollback: mọi hệ ML có logging chung, phát hiện bất thường real-time, dashboard tập trung; từ những bản đầu đã có thể ki…
- Canary rollouts: upgrade models in production without downtime Bài tóm tắt · Together AI · 2026
…g thấy, p95 tăng gấp đôi thì biết qua dashboard hoặc khách, rollback về model cũ phải cold start) hoặc tự viết script đẩy dần phần trăm traffic trong khi nhìn Grafana. Thay đổi chí…
- Evolution and Scale of Uber's Delivery Search Platform Bài tóm tắt · Uber · 2026
…ngữ cảnh; lỗi khác 0 trong một khoảng ngắn thì alert và tự rollback model về bản trước (index giữ nguyên). Không thêm latency hay bước mạng trên đường đọc. Vì sao - Model và index…
- Open Sourcing Coinbase's Secure Deployment Pipeline (Odin) Bài tóm tắt · Coinbase · 2018
Theo Coinbase (5/2018): deploy hàng trăm lần mỗi ngày trên hàng trăm project; một tính năng đi từ ý tưởng tới production dưới một giờ.
- 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.
- 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:
- 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:
- 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…
- 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…
- 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…
- 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,…
- 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…
- 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ả…
- 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:
- 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:
- Hệ thống độ trễ thấp (low latency) Chủ đề Thành viên
Ở sàn giao dịch và công ty market making, mỗi giao dịch làm thay đổi thị trường cho giao dịch sau, và ai phản ứng chậm hơn thì thua. Yêu cầu không chỉ là latency trung bình thấp mà latency ổn định ở đuôi, ở thang micro…
- 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…
- 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.
- 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:
- Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) Chủ đề Thành viên
Một quỹ định lượng hay công ty market making sống bằng vòng nghiên cứu: đặt giả thuyết → lấy dữ liệu → tạo feature → train model hay dựng tín hiệu → backtest/mô phỏng → đưa vào giao dịch thật → lặp lại. Theo Optiver, độ…
- 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…
- 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ó…
- 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…
- 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ỡ:
- 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: