Tìm kiếm
40 kết quả cho “AI agent observability”. Tìm không phân biệt dấu.
- AI Agent Observability: Making Silent Production Failures Visible and Actionable Bài tóm tắt · Salesforce · 2026
· 2026 · 3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://engineering.salesforce.com/ai-agent-observability-making-silent-production-failures-visible-and-actionable/) Bài ph…
- 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:
- 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…
- How Deterministic Controls Turn AI Output Into Reliable Prompt Templates Bài tóm tắt · Salesforce · 2026
· 2026 · 3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://engineering.salesforce.com/how-deterministic-controls-turn-ai-output-into-reliable-prompt-templates/) Bài phỏng vấn…
- From Monitoring to Observability: Our Ultra-Marathon to a Cloud-Native Platform Bài tóm tắt · Uber · 2026
· 2026 · 4. Điều chỉnh · Độ khó: Dễ — [bài gốc](https://www.uber.com/us/en/blog/from-monitoring-to-observability-cloud-native/) Phạm vi là mạng nội bộ công ty (CorpNet: văn phòng,…
- Scaling our Observability platform beyond 100 Petabytes by embracing wide events and replacing OTel Bài tóm tắt · ClickHouse · 2025
· 2025 · 3. Quy mô lớn · Độ khó: Khó — [bài gốc](https://clickhouse.com/blog/scaling-observability-beyond-100pb-wide-events-replacing-otel) Bài của nhà cung cấp về hệ log nội bộ (…
- Safeguarding Dynamic Configuration Changes at Scale Bài tóm tắt · Airbnb · 2026
· 2026 · 3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://airbnb.tech/infrastructure/safeguarding-dynamic-configuration-changes-at-scale/) Bài tổng quan kiến trúc, ít số liệ…
- How Intelligent Load Shedding Prevents Cascading Failures in Tier-0 Systems Bài tóm tắt · Salesforce · 2026
· 2026 · 3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://engineering.salesforce.com/how-intelligent-load-shedding-prevents-cascading-failures-in-tier-0-systems/) Bài phỏng…
- Robinhood Swaps Kafka for WarpStream to Tame Logging Workloads and Costs Bài tóm tắt · WarpStream · 2025
· 2025 · 3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://www.warpstream.com/blog/robinhood-swaps-kafka-for-warpstream-to-tame-logging-workloads-and-costs) Nhà cung cấp viết…
- How we systematically improved our reliability Bài tóm tắt · Neon · 2026
· 2026 · 4. Điều chỉnh · Độ khó: Trung bình — [bài gốc](https://neon.com/blog/how-we-systematically-improved-our-reliability) Bối cảnh - Lakebase Postgres (Neon) chạy một fleet rấ…
- 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…
- 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.
- 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…
- 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…
- 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:
- 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ả…
- 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.
- 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ể…
- 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".
- 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…
- 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…
- 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…
- 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…
- Anthropic Công ty Thành viên
Nguồn đầu tiên của Anthropic trong wiki là một postmortem về hạ tầng phục vụ model: tháng 8–9/2025, ba lỗi hạ tầng độc lập (định tuyến sai pool context, cấu hình sai trên TPU, lỗi compiler XLA bị một workaround cũ che)…
- Salesforce Công ty Thành viên
Cloud Atlas là kho dữ liệu định danh toàn cầu phía sau phần lớn việc xác thực của Salesforce, mục tiêu five nines. Năm 2026 họ bỏ rate limit theo từng instance (sai khi autoscale, không thấy tổng tải của khách) và tránh…
- 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…
- Open sourcing kubenetmon: how we monitor data transfer in ClickHouse Cloud Bài tóm tắt · ClickHouse · 2025
· 2025 · 3. Quy mô lớn · Độ khó: Khó — [bài gốc](https://clickhouse.com/blog/kubenetmon-open-sourced) Bối cảnh - ClickHouse Cloud chạy trên AWS, GCP, Azure, hàng chục region, mỗi…
- Meta Công ty Thành viên
Facebook khởi đầu trên LAMP với mỗi trường đại học một DB; mở rộng bằng Memcache, rồi TAO, rồi data center riêng, edge cạnh ISP và region nhiều toà nhà. Giai đoạn 2010–2020 là các ca góc của hệ phân tán: bất nhất cache…
- Mercari Công ty Thành viên
PaymentService của Merpay (2019) giữ nhất quán thanh toán qua nhiều service bằng cách tự làm ở tầng ứng dụng: chia pha + state machine, idempotency key bắt buộc, bù trừ kiểu TCC, đối soát và fault injection . Ba năm…
- Building visibility into a CI platform Bài tóm tắt · Optiver · 2026
· 2026 · 3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://optiver.com/insights/technology-blog/building-visibility-into-a-ci-platform/) Bối cảnh - Lượng code qua pipeline củ…
- Scaling Production Globally — The service mesh facelift (Part-1) Bài tóm tắt · Achievers · 2022
· 2022 · 3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://achievers.engineering/scaling-production-globally-service-mesh-face-lift-part-1-30ad6d393d04) Site chặn crawler; wi…
- Slack Công ty Thành viên
Slack bắt đầu bằng LAMP và giữ PHP vì môi trường của nó (mỗi request trạng thái sạch, vòng lặp sửa–tải lại). Họ cải tiến dần bằng HHVM và Hack thay vì viết lại . Tầng dữ liệu đi từ MySQL active-active shard theo…
- Stack Overflow: How We Do Monitoring - 2018 Edition Bài tóm tắt · Stack Overflow · 2018
· 2018 · 3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://nickcraver.com/blog/2018/11/29/stack-overflow-how-we-do-monitoring/) Bài 4 trong series của Nick Craver. Bài trước:…
- WarpStream Công ty Thành viên
Kafka "diskless" trên object storage. Năm 2025 ra mắt cụm đa region: agent ghi quorum 3 bucket ở 3 region, control plane trên DynamoDB Global Tables hoặc Spanner đa region với một leader được bầu; mất trọn một region mà…
- Zillow Công ty Thành viên
Zillow cho thấy một công ty dữ liệu đi từ ứng dụng web có cache tự làm sang nền tảng dữ liệu, ML và thí nghiệm dùng chung. Năm 2012 các sản phẩm mới đã chạy trên AWS: nền tảng website cho môi giới trên WordPress dùng…
- DoorDash Công ty Thành viên
Nguồn đầu tiên của DoorDash trong wiki là bài 2022 của một thực tập sinh nghiên cứu (CMU): chaos engineering ở production không hợp với DoorDash vì khách mất đơn, nên thử fault injection có hệ thống ở mức service…
- Engineering Real-Time Mobile Personalization Across iOS, Android, React Native, and Flutter Bài tóm tắt · Salesforce · 2026
· 2026 · 3. Quy mô lớn · Độ khó: Trung bình — [bài gốc](https://engineering.salesforce.com/engineering-real-time-mobile-personalization-across-ios-android-react-native-and-flutter…
- Optiver Công ty Thành viên
Công ty market making (quyền chọn và nhiều loại tài sản khác) trên nhiều sàn. Theo Optiver, độ dài vòng nghiên cứu là chỉ tiêu cốt lõi; nền tảng nghiên cứu chạy hybrid on-prem và cloud với vị trí chạy quyết định trước…