📊 Business KPIs – Các chỉ số hiệu suất kinh doanh

Những câu hỏi mà ban giám đốc quan tâm thường là:

• Người dùng có sử dụng được sản phẩm không?
• Công ty có đang kiếm được tiền không?
• Có tăng trưởng không?
• Khách hàng có hài lòng không?

🧩 Một số KPI quan trọng:

• MRR (Doanh thu định kỳ hàng tháng) – Dùng phổ biến trong SaaS.
• Revenue per Customer / LTV / CAC – Hiệu quả tài chính và chi phí khách hàng.
• Churn Rate / Active Users / NPS – Đo sự hài lòng và giữ chân người dùng.
• Burn Rate / Run Rate / Gross Margin / TAM – Khả năng sống còn và mở rộng thị trường.

⛔ Một số dữ liệu có thể không dễ thu thập, nhưng vẫn cần hiểu rõ các KPI này để đồng bộ tư duy với ban lãnh đạo.

🏢 Ví dụ thực tế – Yelp & Reddit

• Các công ty như Yelp và Reddit có thể theo dõi các hoạt động như: số tìm kiếm, bài viết, lượt vote, số tài khoản đăng nhập, lượt mua hàng… để phát hiện sớm các bất thường trong hệ thống.
• Những chỉ số người dùng này rất dễ theo dõi, trực quan, có thể hiển thị công khai trong văn phòng để ai cũng biết “hệ thống có khỏe không”.

🔗 Kết nối KPI kinh doanh với chỉ số kỹ thuật

Ví dụ:
KPI: “User login” → cần theo dõi thêm login latency, login failures.
KPI: “Votes cast” → cần thêm vote latency, vote failures.

👉 Những chỉ số như thời gian phản hồi và tỷ lệ lỗi mới cho biết hệ thống hoạt động tốt hay không, ngay cả khi số lượng vẫn ổn.

⚠️ Nếu app chưa có các chỉ số này thì sao?

• Không thể “bolt-on” giám sát sau khi app đã xong – phải thiết kế ngay từ đầu như xe hơi cần đồng hồ đo xăng.
• May mắn là ta không làm xe hơi – có thể cập nhật code bất kỳ lúc nào để bổ sung đo lường!

🔍 Làm sao tìm KPI cho app mình?

Cách chắc ăn nhất:

🗣 “Nói chuyện với người khác ngoài Engineering”

• Bắt đầu từ Product Manager → Tech Lead → Senior Devs
• Hỏi họ: “Làm sao biết app đang hoạt động?”, “Chỉ số nào quan trọng nhất?”

Ngoài ra, hãy vẽ sơ đồ luồng hoạt động cao cấp của app để xác định các điểm cần đo lường (đăng nhập, tìm kiếm, gửi phản hồi…).

Frontend Monitoring

• Giám sát frontend (client-side) thường bị bỏ qua do vai trò này mặc định là của team Ops.
• Trong thời đại SPA (Single Page Applications), việc giám sát phía trình duyệt trở nên thiết yếu vì nhiều lỗi xảy ra ở client không được phản ánh qua lỗi HTTP truyền thống.

🧱 Hiểu về frontend monitoring

• Frontend = HTML, CSS, JS, images,… được xử lý trên trình duyệt.
• Backend = xử lý dữ liệu, logic, API,…
• Với SPA, các lỗi JavaScript có thể xảy ra mà không có lỗi server nào → cần công cụ chuyên biệt để phát hiện.

🐢 Tác động của tốc độ tải chậm

• Nghiên cứu chỉ ra: chỉ cần 1 giây trễ → mất 11% page views, 7% chuyển đổi, 16% sự hài lòng.
• Ví dụ:
  • Shopzilla giảm thời gian tải từ 6s → 1.2s → tăng 12% doanh thu, 25% pageviews.
  • Amazon: mỗi 100ms giảm thời gian tải → tăng 1% doanh thu.
  • Pinterest: cải thiện load → tăng 40% perceived speed, 15% SEO traffic, 15% signup.

👉 Mục tiêu: dưới 4 giây (Amazon Prime Day vẫn giữ được 2.4s).

🧭 2 cách tiếp cận monitoring

1. RUM (Real User Monitoring) – Theo dõi từ người dùng thật

• Ví dụ: Google Analytics.
• Cài JS snippet → thu thập thời gian load, tương tác thực tế.
• Ưu điểm: đo theo điều kiện thực tế, hành vi thực.

2. Synthetic Monitoring – Giả lập tương tác

• Ví dụ: WebpageTest.org.
• Giả lập hành vi người dùng → đo tốc độ và phản hồi.
• Phù hợp để kiểm tra trước khi deploy hoặc trong CI/CD.

🧠 Hiểu về DOM và ảnh hưởng của JavaScript

• DOM là mô hình cây HTML mà trình duyệt phân tích để hiển thị trang.
• JS có thể làm thay đổi DOM sau khi tải → dẫn đến sự khác biệt giữa source HTML và nội dung hiển thị.
• JS mặc định tải đồng bộ → chặn tải DOM.
• Thuộc tính async cho phép tải JS không chặn DOM → tăng hiệu năng.

🧪 Trang CNN tải 55 script → mất 8.29s
🟢 Google chỉ tải 5 script → mất 0.89s

📈 Các chỉ số quan trọng

Navigation Timing API (trình duyệt hỗ trợ sẵn):

• navigationStart – Bắt đầu tải
• domLoading – DOM bắt đầu tải
• domInteractive – Trang bắt đầu khả dụng
• domContentLoaded – Tất cả script đã chạy
• domComplete – Trang tải xong hoàn toàn

⏱ Có thể tính toán:

• Tổng thời gian tải = domComplete - navigationStart
• Thời gian đến trạng thái usable = domInteractive - navigationStart

Speed Index (từ WebpageTest)

• Đo thời gian hiển thị trực quan trang bằng video 10fps.
• Thích hợp đánh giá trải nghiệm người dùng nhưng không đủ chi tiết cho debug kỹ thuật.

🛠 Cách gửi dữ liệu

• Sử dụng Google Analytics (analytics.js) để gửi performance.now() dưới dạng timing event.
• Hoặc dùng SaaS chuyên dụng (hầu hết đã có sẵn thư viện JS đơn giản).
• StatsD/Graphite có thể tích hợp qua backend HTTP endpoint, nhưng phức tạp hơn.

📦 Xử lý lỗi JavaScript

• console.log không phù hợp cho production.
• Cần công cụ thu thập exception JS → gửi về backend (nhiều SaaS có sẵn).

🚦 Synthetic Monitoring trong CI/CD

• Dùng WebpageTest.org hoặc phiên bản private → test hiệu năng mỗi pull request.
• Tránh để hiệu năng frontend tụt dần theo thời gian.

Application Monitoring

🔍 Tổng quan

• Rất nhiều công ty có giám sát tốt hạ tầng, mạng, bảo mật… nhưng lại bỏ qua giám sát ứng dụng.
• Thực tế: Ứng dụng thường xuyên thay đổi nhất, cần giám sát nhất.
• ⇒ Monitoring ứng dụng không khó như tưởng tượng.

🎯 1. Instrumenting Apps with Metrics

• Lý do nên làm: App chứa rất nhiều thông tin có giá trị.
• ✔ Dễ dàng bắt đầu: đo thời gian DB query, gọi API bên ngoài, số lần login…
• ✔ Khi có metric, dễ xác định vấn đề “login có chậm không?” thay vì cảm tính.
• ⇒ StatsD là công cụ phổ biến, dễ tích hợp, hiệu quả cao:
  • Dùng UDP → không chặn, hiệu năng cao
  • Tính toán các metrics như: mean, upper_90, sum, count…

Ví dụ đơn giản StatsD:

statsd_client.incr('app.login.successes')
statsd_client.timer('app.login.time')

⚙ 2. Application Performance Monitoring (APM)

• Các công cụ như NewRelic, DataDog, v.v. cung cấp biểu đồ, phân tích hiệu năng.
• Giới hạn: Không biết ngữ cảnh hoặc logic nghiệp vụ.
• ⇒ Nên kết hợp cả APM tool + metrics tự build trong app.

📝 3. Giám sát pipeline build/deploy

• Theo dõi meta: build ID, ai deploy, thời gian deploy…
• Kết hợp với metrics như error rate, latency ⇒ xác định nhanh deploy gây lỗi.

Ví dụ: Overlay event lên đồ thị API error rate.

🔎 4. /health Endpoint Pattern

• Khái niệm: HTTP endpoint (VD: /health) để báo cáo trạng thái ứng dụng.
• Công dụng:
  • Cho load balancer / service discovery kiểm tra
  • Hiển thị version, check dependency (DB, Redis…)
  • App tự nhận biết “sức khỏe” của chính mình

Mở rộng:

• Check MySQL, Redis, external API
• Có thể kiểm tra ghi & đọc dữ liệu test
• Kết quả trả về JSON (200 hoặc 503)

Lưu ý:

• Đừng làm endpoint quá phức tạp ⇒ khó debug
• Nên đặt trong app chính, không tách riêng
• Hãy giới hạn truy cập (IP allowlist…)

🔊 5. Application Logging

• Structured Logs > Unstructured logs
• ✔ Ghi log dưới dạng JSON (dễ parse, dễ tích hợp BI)
• ✔ So với metric: log cung cấp ngữ cảnh đầy đủ hơn

So sánh:

• Metric: app.login_latency = 5
• Log: {"latency": 5, "user": "admin", "success": false}

Vậy chọn log hay metric?

• Dựa vào:
  • Nhóm dễ nghĩ bằng metric hay log?
  • Tình huống cần log hay cần biểu đồ?

⚡ 6. Log levels

• DEBUG, INFO, WARN, ERROR từ RFC 5424
• Vấn đề: Khi lỗi xảy ra, DEBUG chưa bật → không có dữ liệu!
• ⇒ Cân nhắc kỹ khi đặt log level

Chiến lược:

• Nghĩ kỹ về hành vi của app, rồi quyết định nên log gì
• Log những thông tin hay hỏi khi có lỗi: request ID, context, retry…

💾 7. Ghi log: Disk vs Network

• Tốt hơn: ghi log ra disk rồi dùng agent chuyển đi
• Viết trực tiếp tới network server (SaaS) dễ gây bottleneck

🚀 8. Serverless Monitoring

• Serverless function sống ngắn ngủi → polling không hiệu quả
• ✔ StatsD + platform logs (AWS S3, SNS…) là giải pháp phù hợp

🔗 9. Microservices Monitoring

• ✔ Số lượng microservice tăng ⇒ giám sát tương tác càng quan trọng
• ✔ ✔ Distributed Tracing (Zipkin, OpenTelemetry…)
  • Dùng request ID để “gắn thẻ” mọi bước
  • Hiển thị các request chạy qua bao nhiêu service, tốn bao nhiêu thời gian

Chú ý: Tracing khó triển khai, nhưng xứng đáng nếu microservices phức tạp

Server Monitoring

🧠 Tư duy cốt lõi

• ❌ Đừng bắt đầu giám sát với CPU, RAM, Disk – chúng chỉ phù hợp chẩn đoán, không dùng để phát hiện sớm vấn đề ứng dụng.
• ✅ Hãy thu thập mọi chỉ số hệ điều hành (OS metrics) nhưng đừng đặt cảnh báo trừ khi có lý do rõ ràng.
• ✅ Trọng tâm vẫn là ứng dụng có hoạt động tốt không, không phải CPU có đang “mệt” không.

📦 Các chỉ số hệ điều hành cần nắm rõ

🧰 Giám sát các dịch vụ thường gặp

📜 Logging

• Chia làm 3 phần: Thu thập, Lưu trữ, Phân tích.
• Ưu tiên dùng log theo cấu trúc (JSON) để dễ lọc, phân tích.
• Nếu log không dùng syslog, hãy đẩy vào syslog hoặc dùng log collector riêng.
• Nên lưu logs local rồi đẩy đi → giảm chi phí kết nối mạng.

⏰ Giám sát Scheduled Jobs

• ✨ Sử dụng “dead man’s switch” → nếu không thấy tín hiệu (touch file) sau khoảng thời gian nhất định → cảnh báo.
• Gợi ý script shell đơn giản + cron job để phát hiện job bị chết trong im lặng.

Network Monitoring

Giám sát mạng là một trong những kĩ năng bỏ quên nhưng cực kỳ quan trọng. Tác giả nhắc lại từ câu chuyện cá nhân để nhấn mạnh: “một lỗi mạng nhỏ cũng có thể dẫn đến sự ngắt quãng toàn bộ hệ thống”.

🔍 Các khái niệm chính

⚙️ Giao thức SNMP – Những điều cần lưu ý

• Version 2c là phổ biến nhất, nhưng không mã hóa.
• Version 3 có mã hóa và xác thực nhưng ít phổ biến hơn.
• Nên giới hạn SNMP trong mạng quản lý nội bộ, tránh để lộ ra mạng công cộng.

📈 Giám sát các chỉ số quan trọng của giao diện mạng

🧪 Công cụ và cách đo

• Dùng SNMP lấy số liệu IF-MIB::if* như ifInOctets, ifOutOctets.
• Dùng iperf2, smokeping để đo latency/throughtput thực tế.
• Chỉ giám sát uplink và server ports, bỏ qua access port để giảm nhiễu.

📦 Giám sát các thành phần hệ thống mạng

📊 Flow Monitoring (NetFlow, sFlow, IPFIX, jFlow)

• Cho phép phân tích luồng dữ liệu chi tiết theo IP, protocol, port.
• Flow gồm: IP nguồn/đích, cổng, protocol, giao diện vào ra, TOS.
• Dùng để tìm node tiêu thụ băng thông nhiều nhất hoặc phát hiện bất thường.

🧩 Lưu ý khi triển khai giám sát mạng

• SNMP không chính xác khi thiết bị quá tải do bị ưu tiên thấp.
• SNMP có thể bị lộ thông tin (community string gửi rõ ràng).
• Cần theo dõi sự thay đổi cấu hình bằng công cụ như RANCID, hoặc Git + script.

📈 Capacity Planning – Lập kế hoạch mở rộng năng lực

• Dùng dữ liệu giám sát 6 tháng gần nhất để dự đoán xu hướng.
• Hoặc làm ngược lại: từ yêu cầu kinh doanh → tính toán dung lượng cần.

✅ Tổng kết chương

• SNMP là giao thức phức tạp nhưng không thể tránh khỏi trong giám sát thiết bị mạng.
• Hiểu và giám sát đúng các chỉ số giao diện mạng giúp phát hiện sớm vấn đề vật lý.
• Giám sát lưu lượng bằng các flow tools giúp phân tích chi tiết.
• Voice, video cần giám sát riêng biệt vì nhạy cảm với jitter và latency.
• Đừng quên giám sát phần chassis, cấu hình, bộ định tuyến và các dịch vụ QoS.

Giám sát Hệ thống Mạng (Network Monitoring)

📌 Tóm tắt ngắn gọn

Giám sát mạng là một trong những kĩ năng bỏ quên nhưng cực kỳ quan trọng. Tác giả nhắc lại từ câu chuyện cá nhân để nhấn mạnh: “một lỗi mạng nhỏ cũng có thể dẫn đến sự ngắt quãng toàn bộ hệ thống”.

🔍 Các khái niệm chính

⚙️ Giao thức SNMP – Những điều cần lưu ý

• Version 2c là phổ biến nhất, nhưng không mã hóa.
• Version 3 có mã hóa và xác thực nhưng ít phổ biến hơn.
• Nên giới hạn SNMP trong mạng quản lý nội bộ, tránh để lộ ra mạng công cộng.

📈 Giám sát các chỉ số quan trọng của giao diện mạng

🧪 Công cụ và cách đo

• Dùng SNMP lấy số liệu IF-MIB::if* như ifInOctets, ifOutOctets.
• Dùng iperf2, smokeping để đo latency/throughtput thực tế.
• Chỉ giám sát uplink và server ports, bỏ qua access port để giảm nhiễu.

📦 Giám sát các thành phần hệ thống mạng

📊 Flow Monitoring (NetFlow, sFlow, IPFIX, jFlow)

• Cho phép phân tích luồng dữ liệu chi tiết theo IP, protocol, port.
• Flow gồm: IP nguồn/đích, cổng, protocol, giao diện vào ra, TOS.
• Dùng để tìm node tiêu thụ băng thông nhiều nhất hoặc phát hiện bất thường.

🧩 Lưu ý khi triển khai giám sát mạng

• SNMP không chính xác khi thiết bị quá tải do bị ưu tiên thấp.
• SNMP có thể bị lộ thông tin (community string gửi rõ ràng).
• Cần theo dõi sự thay đổi cấu hình bằng công cụ như RANCID, hoặc Git + script.

📈 Capacity Planning – Lập kế hoạch mở rộng năng lực

• Dùng dữ liệu giám sát 6 tháng gần nhất để dự đoán xu hướng.
• Hoặc làm ngược lại: từ yêu cầu kinh doanh → tính toán dung lượng cần.

🛡️ Bổ sung từ Chương 10: Giám sát Bảo mật (Security Monitoring)

🔒 Đặc thù của giám sát bảo mật

• Không giống giám sát hệ thống, nhiều thành phần chưa có sẵn điểm chạm (hook).
• Cần chủ động thiết lập thêm công cụ và luồng dữ liệu bảo mật.

⚖️ Nguyên tắc quan trọng

• Bảo mật = sự đánh đổi giữa chi phí, rủi ro và trải nghiệm người dùng.
• Không phải hệ thống nào cũng cần bảo mật cấp “Fort Knox”.

📋 Tuân thủ (Compliance)

👤 auditd – Giám sát hành vi người dùng và hệ thống

• Theo dõi: sudo, truy cập file nhạy cảm, login fail/success
• Ghi log vào /var/log/audit/audit.log
• Cấu hình gửi về server trung tâm qua plugin audisp-remote

🕵️‍♂️ HIDS (Host Intrusion Detection System)

• rkhunter: phát hiện rootkit, thay đổi file, SSH bất thường
• Chạy theo lịch cron, gửi log đến hệ thống phân tích

🌐 NIDS (Network IDS)

• Dùng tap mạng hoặc span port để ghi lại lưu lượng mạng
• Công cụ: Snort, Bro/Zeek kết hợp với SIEM để phân tích

🧠 Kết hợp giám sát bảo mật

✅ Tổng kết chương

• Giám sát mạng & bảo mật là nền tảng để đảm bảo sự ổn định, an toàn của toàn hệ thống.
• SNMP, flow, latency, jitter… vẫn là công cụ cốt lõi.
• auditd, rkhunter, NIDS giúp mở rộng khả năng giám sát tới mức độ người dùng và luồng dữ liệu.
• Bảo mật không chỉ là “chặn” – mà còn là “nhìn thấy và phản ứng đúng lúc”.

Đánh giá hệ thống giám sát

Phần này tổng hợp lại toàn bộ kiến thức đã học qua một ví dụ thực tế: tiến hành đánh giá giám sát cho một công ty hư cấu – Tater.ly. Mục tiêu là xác định những gì cần giám sát và lý do tại sao, từ góc độ kinh doanh, frontend, backend, bảo mật và cảnh báo.

🏢 1. Từ mục tiêu kinh doanh đến chỉ số đo lường (Business KPIs)

🖥 2. Giám sát giao diện người dùng (Frontend Monitoring)

• Dùng công cụ RUM (Real User Monitoring) → đo thời gian tải trang từ góc nhìn người dùng thực tế.

⚙️ 3. Giám sát ứng dụng và máy chủ (App & Server Monitoring)

📐 Kiến trúc hệ thống: 2 Load Balancer (HAProxy) → 4 Web Server (chạy Django) → PostgreSQL (primary-replica), Redis (session), CDN (cache layer).

📊 Các metrics cần theo dõi:

📝 Logs quan trọng:

• Đăng nhập người dùng (success/fail + lý do)
• Exceptions trong Django
• Log của Apache, PostgreSQL, Redis, HAProxy
• Công cụ synthetic monitoring → Cảnh báo SSL sắp hết hạn

🔐 4. Giám sát bảo mật (Security Monitoring)

🚨 5. Alerting – Cảnh báo quan trọng

📣 Tập trung alert vào các dịch vụ quan trọng và hành vi người dùng:

• Thời gian tải trang tăng bất thường
• Redis/Apache/HAProxy tăng lỗi hoặc latency
• PostgreSQL query chậm dần
• Hành động người dùng: login, search, submit review có lỗi hoặc phản hồi chậm

📘 Đừng quên: Viết runbook chi tiết để cả team nắm được quy trình khi xảy ra sự cố.

✅ Tổng kết

• Đánh giá hệ thống giám sát bắt đầu từ các KPI kinh doanh → frontend → backend → bảo mật → cảnh báo.
• Luôn giữ góc nhìn “từ người dùng đến máy chủ”.
• Hệ thống luôn thay đổi, vì vậy giám sát là hành trình liên tục.

📘 Tài liệu tham khảo

• Sách: Practical Monitoring: Effective Strategies for the Real World (Mike Julian)