Tìm kiếm
28 kết quả cho “monitoring dependency”. Tìm không phân biệt dấu.
- Monitoring Reliably at Scale Bài tóm tắt · Airbnb · 2026
…: Trung bình — [bài gốc](https://airbnb.tech/infrastructure/monitoring-reliably-at-scale/) Bối cảnh - Airbnb có hơn 1.000 service chạy trên hạ tầng chung (Kubernetes, service mesh…
- Stack Overflow: How We Do Monitoring - 2018 Edition Bài tóm tắt · Stack Overflow · 2018
…s://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: ; bài sau: . Bối cảnh Cuối 2018, Stack Overflow vẫn chạy ASP…
- Slack's Outage on January 4th 2021 Bài tóm tắt · Slack · 2021
…scale-up lớn bất thường là load test mà nó chưa từng qua. - Monitoring phải độc lập khỏi đường mạng của production; phụ thuộc ẩn qua thành phần mạng dùng chung chỉ lộ ra khi cần nó…
- Behind the scenes: Redpanda Cloud's response to the GCP outage Bài tóm tắt · Redpanda · 2025
…heo Redpanda) - TAM của Google báo trước khi có ticket nào. Monitoring suy giảm : dữ liệu observability tự host, nhưng dashboard và cảnh báo dùng bên thứ ba, bên đó bị ảnh hưởng nê…
- Lessons learned in incident management Bài tóm tắt · Dropbox · 2021
Dropbox cam kết SLA 99,9% với một số khách hàng (khoảng 43 phút down/tháng), mục tiêu nội bộ 99,95% (khoảng 21 phút/tháng, 2021). Muốn giữ ngân sách đó thì phải rút ngắn cả ba pha của một sự cố availability: phát hiện,…
- 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…
- 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:
- 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.
- 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.
- 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…
- 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…
- 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…
- 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…
- 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.
- 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…
- Stack Overflow Công ty Thành viên
Phản ví dụ nên đọc sớm cho niềm tin "lớn thì phải scale out". Năm 2009, với 16 triệu page view mỗi tháng, Stack Overflow chạy hai web server và một SQL Server, chạm giới hạn thì nâng RAM; theo Jeff Atwood, phần cứng rẻ…
- Catching bugs on the client-side: how we developed our error tracking system Bài tóm tắt · Bumble · 2020
Bumble và Badoo có web (desktop, mobile) và app Android, iOS với hàng triệu người dùng. Web phát hành 1–2 lần mỗi ngày, app native khoảng một lần mỗi tuần; phân tích lỗi là một bước của mỗi lần phát hành: release…
- 3 Lessons Learned From Implementing Chaos Engineering at Enterprise Bài tóm tắt · CapitalOne · 2020
…ine thì không đọc được kết quả thí nghiệm. Liên quan - · · (monitoring là nơi phán kết quả) -…
- Hudson River Trading Công ty Thành viên
Công ty giao dịch thuật toán (HRT), phần lớn hạ tầng on-premises, nhiều site trên thế giới. Năm 2021 họ scale Prometheus bằng shard chỉ ingest cộng query node đọc remote, vì federation mất khả năng tổng hợp ad-hoc trên…
- How Reliability and Product Teams Collaborate at Booking.com Bài tóm tắt · Booking.com · 2019
…khác nhau; phần lớn kỳ vọng team reliability làm hết (toil, monitoring, sự cố), điều không thực tế. Thay đổi chính - Reliability Collaboration Model (RCM): liệt kê đầy đủ mọi việc…
- 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…
- Structured Logging with slog Bài tóm tắt · Go · 2023
Log là nơi đầu tiên người ta tìm khi debug server, nên log nhiều và phải lọc, tìm nhanh. Log có cấu trúc (cặp key-value) phân tích được tin cậy hơn log chữ.
- Data Mesh at Grab (Part III): Operationalizing data reliability with automated DPIs Bài tóm tắt · Grab · 2026
Grab chuyển từ một đội Data Engineering trung tâm sang data mesh: các team tự publish data product, được chứng nhận (chủ sở hữu, tài liệu, lineage, kiểm chất lượng) qua Hubble (metadata, lineage), Genchi (quan sát chất…
- Real-time Distributed Tracing for Website Performance and Efficiency Optimizations Bài tóm tắt · LinkedIn · 2015
Kiến trúc hướng service của LinkedIn: một lượt xem trang fan-out ra nhiều service ở nhiều tầng, nhiều mức sâu. Dev phụ thuộc service phía sau nhưng không thấy quan hệ và hiệu năng của chúng, nên khó tối ưu và khó tìm…
- Service Architecture at SoundCloud — Part 2: Value-Added Services Bài tóm tắt · SoundCloud · 2021
…được. - Đánh đổi: - thêm một service thì thêm chi phí node, monitoring, on-call; - thêm một round-trip mạng. - Họ cân nhắc làm VAS thành thư viện link vào lúc build (như JVMKit trư…
- Adopting Arm at Scale: Transitioning to a Multi-Architecture Environment Bài tóm tắt · Uber · 2025
…Go cho phép fused floating-point dù làm tròn khác). Công cụ monitoring so sánh latency, lỗi, CPU, throttling theo kiểu A/B giữa hai kiến trúc và giữa các miền lỗi. Dev Pod (môi trư…
- 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…