Tìm kiếm
40 kết quả cho “Chat”. Tìm không phân biệt dấu.
- Chat Service Architecture: Persistence Bài tóm tắt · Riot Games · 2015
…rung bình — [bài gốc](http://engineering.riotgames.com/news/chat-service-architecture-persistence) Phần 3/3 của series chat League of Legends. Phần 2 (server): . Bối cảnh - Chat dự…
- Chat Service Architecture: Servers Bài tóm tắt · Riot Games · 2015
…Nâng cao — [bài gốc](http://engineering.riotgames.com/news/chat-service-architecture-servers) Phần 2/3 của series chat League of Legends. Phần 1 (giao thức XMPP) wiki bỏ qua vì ch…
- Implementing ChatOps into our Incident Management Procedure Bài tóm tắt · Shopify · 2018
…hó: Dễ — [bài gốc](https://shopify.engineering/implementing-chatops-into-our-incident-management-procedure) Bối cảnh - Production engineer (PE) của Shopify được coi là chuyên gia x…
- March 20 ChatGPT outage: Here's what happened Bài tóm tắt · OpenAI · 2023
…ó: Trung bình — [bài gốc](https://openai.com/index/march-20-chatgpt-outage/) Bối cảnh - OpenAI phải tắt ChatGPT vì một bug khiến một số user thấy tiêu đề lịch sử chat của user khác…
- Federated GraphQL Server at Scale: Zillow Rental Manager Real-time Chat Application Bài tóm tắt · Zillow · 2019
…đó trao đổi qua email. Thay đổi chính - Project Satellite: chat trong app cho hai module Rental Manager (chủ nhà) và Renter Hub (người thuê). - Satellite API cung cấp dữ liệu và c…
- API, ChatGPT & Sora Facing Issues (incident write-up) Bài tóm tắt · OpenAI · 2024
…024, từ 15:16 tới 19:38 (PST), mọi dịch vụ của OpenAI (API, ChatGPT, Sora) suy giảm nặng hoặc ngừng hẳn. - OpenAI chạy hàng trăm cụm Kubernetes. Lúc 15:12 họ deploy một service tel…
- Reducing Image File Size in the Photos Infrastructure Bài tóm tắt · Etsy · 2017
…đắt CDN hơn và làm trang chậm. - Gần như suốt lịch sử Etsy, chất lượng JPEG cố định ở 85, coi là "cân bằng tốt" cho mọi ảnh. Thay đổi chính - Chất lượng theo từng ảnh: dùng dssim (…
- Improving how we deploy GitHub Bài tóm tắt · GitHub · 2021
…ôi , và công cụ deploy cũ không còn theo kịp. - Deploy bằng chatops trong một kênh Slack ( dotcom-ops ) theo mô hình branch deploy (deploy branch rồi mới merge). Một kênh vừa quản…
- Automated Incident Management Through Slack Bài tóm tắt · Airbnb · 2022
…bot Slack (Go) làm "phễu duy nhất" cho mọi sự cố. Dùng lệnh chat thường thay cho slash command để mọi người trong kênh đều thấy lệnh đã gõ. - Bốn lệnh ứng với bốn pha mà Airbnb địn…
- How WhatsApp is enabling end-to-end encrypted backups Bài tóm tắt · WhatsApp · 2021
…nh - Tin nhắn đã mã hoá đầu cuối, nhưng bản sao lưu lịch sử chat lên Google Drive hay iCloud thì chỉ được bảo vệ bởi chính nhà cung cấp lưu trữ. Đó là lỗ hổng lớn nhất còn lại của…
- 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:
- 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:
- 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:
- 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:
- 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.
- 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…
- 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…
- Realtime và fan-out Chủ đề Thành viên
Một sự kiện (tin nhắn, ảnh, tweet, vote) phải tới rất nhiều người, rất nhanh, qua rất nhiều kết nối mở cùng lú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…
- 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…
- 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…
- 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,…
- 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ó…
- 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…
- 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:
- 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".
- 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.
- Vector search và index ANN Chủ đề Thành viên
Search ngữ nghĩa, gợi ý và RAG quy về tìm các vector (embedding vài trăm tới vài nghìn chiều) gần một vector query. Vector không có thứ tự tự nhiên, nên B-tree hay inverted index không dùng được; ở quy mô lớn phải dù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…
- 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ự…
- Độ 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.
- Đổ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.
- 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…
- 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.
- 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:
- 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 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, độ…