Nguồn: PagerDuty Blog
Tóm tắt
Khi một incident xảy ra lúc 2 giờ sáng, câu hỏi đầu tiên thường là: “Team nào sở hữu service này?” Không có service architecture rõ ràng, câu trả lời mất hàng phút hoặc hàng giờ, kéo theo nhiều team không cần thiết vào incident và làm chậm quá trình giải quyết. Bài viết của Débora Cambé trên PagerDuty Blog lập luận rằng service architecture không chỉ là tài liệu tổ chức — nó là nền tảng để operations có khả năng scale.
Service architecture bao gồm hai tầng: business services (các khả năng mà khách hàng sử dụng, như “Wire Transfer Experience”) và technical services (các component kỹ thuật bên dưới, như Transaction Authorization Service, Fraud Detection API). Mỗi technical service phải có một team sở hữu duy nhất, escalation policy riêng, và integrations để dẫn monitoring signals vào đúng nơi.
Khi service architecture được thiết lập, Service Graph của PagerDuty cho phép xem ngay “blast radius” của một incident — business service nào bị ảnh hưởng khi một technical service gặp sự cố. AIOps sử dụng service context để group related alerts và suppress noise, giúp chỉ page khi thực sự cần thiết. SRE Agent của PagerDuty có thể phân tích event data, logs và lịch sử incidents để gợi ý root cause dựa trên service architecture.
Điểm thực tiễn quan trọng: bắt đầu nhỏ bằng cách chọn một critical business service, map các technical services bên dưới, định nghĩa ownership và kết nối monitoring tools. Với các tổ chức tài chính EU, service mapping còn là yêu cầu bắt buộc của DORA (Digital Operational Resilience Act) để đáp ứng ICT risk management framework.