Tìm kiếm
40 kết quả cho “on-call”. Tìm không phân biệt dấu.
- 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:
- Scaling our on-call process Bài tóm tắt · Monzo · 2022
…ễ — [bài gốc](https://monzo.com/blog/2022-02-24/scaling-our-on-call-process) Bài thứ ba của Monzo về on-call (trước đó 2018 và 2020). Thay đổi bắt đầu đầu năm 2021. Bối cảnh - Mô h…
- Project STAR*: Streamlining Our On-Call Process Bài tóm tắt · LinkedIn · 2018
…ing.linkedin.com/blog/2018/01/project-star-streamlining-our-on-call-process) Bối cảnh - Voyager On-Call : lịch trực cho app flagship (web, Android, iOS, frontend API). Người trực l…
- How we've evolved on-call Bài tóm tắt · Monzo · 2019
…khó: Dễ — [bài gốc](https://monzo.com/blog/how-weve-evolved-on-call-at-monzo) Bài giữa trong chuỗi on-call của Monzo; bài sau là . Bối cảnh - Từ bài 2018, Monzo đã có tuyến một gồm…
- Building a Healthy On-Call Culture Bài tóm tắt · SoundCloud · 2021
…](https://developers.soundcloud.com/blog/building-a-healthy-on-call-culture) Bối cảnh - Ở SoundCloud, không chỉ DevOps/SRE mà nhiều engineer sản phẩm trực on-call. Bài mô tả cách t…
- How we do On-Call Rotations Bài tóm tắt · Nubank · 2019
…hó: Dễ — [bài gốc](https://building.nubank.com.br/how-we-do-on-call-rotations-at-nubank/) Bài khuyến nghị dựa trên kinh nghiệm của tác giả ở Nubank; không có số liệu MTTA/MTTR cụ t…
- Engineering operational excellence, a case of continuous improvement Bài tóm tắt · Nubank · 2023
…- Đặt SLO lúc thiết kế và để vi phạm SLO tự sinh ticket thì on-call có hàng đợi việc đo được, không chỉ alert. - Theo dõi tỉ lệ nguyên nhân gốc tạo mới/đã giải để biết team đang tr…
- How we manage our 1200 incident playbooks Bài tóm tắt · Zalando · 2023
…playbook , cho 850+ application thuộc diện trực, 100+ team on-call (khoảng 1,41 playbook/app, 12/team). Số playbook tăng vọt mỗi quý 3 (chuẩn bị Cyber Week). Thay đổi chính - Play…
- Automated Incident Management Through Slack Bài tóm tắt · Airbnb · 2022
Airbnb chạy hơn một nghìn microservice do hàng trăm team nhỏ quản lý (2022). Khi có sự cố, khó nhất là biết service nào hỏng và phải page ai.
- Lessons learned in incident management Bài tóm tắt · Dropbox · 2021
…ức ảnh hưởng và mở quy trình. Chẩn đoán - Kiểm tra cấu hình on-call bắt buộc, không ngoại lệ: dịch vụ nội bộ đọc API PagerDuty, so cấu hình escalation và kênh thông báo của từng te…
- SecDb Observability Journey Bài tóm tắt · Goldman Sachs · 2023
SecDb: nền tảng giao dịch, định giá, quản trị rủi ro của Goldman Sachs, dùng liên tục hơn 30 năm bởi hơn 3.000 developer: hơn 200 triệu dòng code Slang (ngôn ngữ riêng), hơn 160 triệu job mỗi ngày, hơn 13.000 người dùng…
- Rolling the Heroku Redis Fleet Bài tóm tắt · Heroku · 2018
…, tạo standby mới. Plan hobby thay dần sau. - Chống mệt mỏi on-call: fleet roll sinh nhiều page hơn do gặp edge case chưa tự động hoá; code chỉ lên lịch thay máy trong giờ làm việc…
- DrP: Meta's Root Cause Analysis Platform at Scale Bài tóm tắt · Meta · 2025
Theo Meta, điều tra sự cố bằng tay ở hệ lớn dựa vào playbook cũ và script tự viết, kéo dài downtime và làm người trực mệt.
- Implementing ChatOps into our Incident Management Procedure Bài tóm tắt · Shopify · 2018
Production engineer (PE) của Shopify được coi là chuyên gia xử lý sự cố, nhưng xử lý sự cố vẫn rối và mệt: gặp lỗi mới, bám vào triệu chứng, quên các thói quen tốt khi bị áp lực.
- Lessons Learnt From Consolidating ML Models in a Large Scale Recommendation System Bài tóm tắt · Netflix · 2023
…hơn (mỗi model mới tốn pipeline, nâng framework, sửa lỗi); on-call dễ hơn vì một codebase, ít chuyển ngữ cảnh, ít điểm hỏng; cải tiến cho một use case áp được cho các use case khá…
- 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…
- 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…
- 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…
- 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.
- 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:
- 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…
- 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:
- 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…
- 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ỡ:
- Monzo Công ty Thành viên
Ngân hàng số với hơn 2.100 microservice và hơn 100 deploy/ngày; rollback tự động bằng Argo Rollouts trở thành mặc định cho mọi service . Để chống "stampeding herd" khi hàng triệu người mở app cùng lúc, edge proxy cắt…
- Triggered: Incident #1234 (incident process needs fixing) Bài tóm tắt · PayPal · 2021
…Đồng bộ bằng tài liệu (loại Operational): sự cố là gì, trực on-call, sự cố do người dùng báo, nguyên tắc alert, runbook, trong và sau sự cố, postmortem. Cố ý giữ ở mức cao , để chi…
- SoundCloud Công ty Thành viên
Năm 2013 SoundCloud rời mô hình một Public API cho mọi client, tách monolith thành microservice và khai sinh pattern BFF; đến 2021 có vài chục BFF dùng chung thư viện edge, nhưng logic tích hợp và phân quyền bị nhân bản…
- 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…
- Open Sourcing Iris and Oncall Bài tóm tắt · LinkedIn · 2017
…MS, gọi). Gửi qua nhà cung cấp (Twilio, Slack). Role (team, on-call, manager) tra động từ nguồn khác. - Oncall: lịch trực tách riêng (xoay ca, follow-the-sun, đổi ca), là nguồn sự…
- Keeping Customers Streaming — The Centralized Site Reliability Practice at Netflix Bài tóm tắt · Netflix · 2020
…tion; tư vấn độ tin cậy (kiến trúc, observability, sức khoẻ on-call); cùng các team tìm và sửa rủi ro hệ thống mà sự cố lộ ra; xây công cụ sự cố. Vì sao - Theo Netflix: tập trung r…
- How Reliability and Product Teams Collaborate at Booking.com Bài tóm tắt · Booking.com · 2019
2019: hơn 1,5 triệu đêm phòng/ngày, 50.000+ server vật lý ở 4 data center và 6 PoP. Quy mô đủ để có team reliability riêng cho từng nền tảng lớn.
- Dropbox Công ty Thành viên
Dropbox luôn là hybrid: metadata ở data center riêng, nội dung file trên S3. Ở ~500 PB họ tự xây Magic Pocket, theo Dropbox vì hiệu năng và unit economics . Cái giá kèm theo là phải tự dựng cả backbone và edge network .…
- Dynamic alert routing with Prometheus and Alertmanager Bài tóm tắt · Loveholidays · 2021
Văn hoá "you build it, you run it"; team Platform Infrastructure lo phần dùng chung (CI/CD, IaC, observability). Phần lớn service chạy trên GKE; service hướng khách chạy trên cụm dùng chung. Stack giám sát: Prometheus…
- What it's like to work as an embedded microservices SRE Bài tóm tắt · Mercari · 2022
…(embedded) vào từng team sản phẩm một thời gian, kể cả trực on-call ở team đó. Tác giả vào 5/2021; nhúng vào team Item (7–12/2021) rồi team Mercari API (từ 1/2022). - Item: microse…
- How we systematically improved our reliability Bài tóm tắt · Neon · 2026
…việc cho observability. Đếm cả thiệt hại cho người nội bộ (on-call bị gọi đêm). - AI agent đào log để đếm khách bị ảnh hưởng, nhưng không dán số của nó vào thẳng: bắt nó dựng note…
- Nubank Công ty Thành viên
Năm 2019: thay vì mỗi team nhỏ (2–8 người) tự trực, họ gộp nhiều team vào một lịch trực chung để mỗi người trực ít ngày hơn, với điều kiện mọi alert có runbook thử với người ngoài team và không còn alert chập chờn; team…
- Best Practices for Real-time Machine Learning: Alerting Bài tóm tắt · Nubank · 2022
…tency, scale (CPU, RAM), logging và tracing tập trung, lịch on-call. - Quy tắc viết alert: - Chuẩn hoá kênh, định dạng và loại số liệu (trung bình, percentile, đếm). - Ghi cả giá t…
- Alerting on Service-Level Objectives (SLOs) Bài tóm tắt · SoundCloud · 2019
Theo SoundCloud, alert dựa trên SLO gần như là "viên đạn bạc" cho alert có ý nghĩa: đạt SLO là định nghĩa của việc đáp ứng kỳ vọng của user, còn một mức lỗi nằm trong SLO (error budget) là chấp nhận được. Họ áp dụng…
- How Upstash Monitors Uptime: Every Replica, Every Minute, From Everywhere Bài tóm tắt · Upstash · 2026
…heo không còn vô hại. Luật: mất một replica là sự cố , page on-call dù không ai thấy. - Check đơn giản nhất: Redis của Upstash có HTTP, nên check là HTTPS /ping tới từng replica. D…