Khi làm việc với một trang web nhỏ chạy trên một vài server, việc triển khai các giải pháp logging, metrics, monitoring, notification, automation đôi khi là thừa thãi, không cần thiết.
Tuy nhiên, đối với những dự án lớn thì ngược lại, đây là những công cụ gần như KHÔNG THỂ THIẾU.
Cùng mình tìm hiểu về chúng trong bài viết này nhé!
1. Logging 📝
Định nghĩa: Logging hay thuật ngữ anh em hay gọi là “ghi log”, là việc ghi lại các sự kiện quan trọng trong hệ thống, các hành động của người dùng, các exception xảy ra, … vào file log hoặc hệ thống log tập trung.
Mục đích:
- Hỗ trợ cho việc debug hiệu quả hơn: Giúp xác định vấn đề bằng cách cung cấp log chi tiết về những sự kiện gây ra bug (Với điều kiện trong code của bạn không được phép cố tình hoặc vô tình “giấu bug” bằng việc sử dụng try catch sai cách)
- Auditing: Theo dõi hành động của người dùng để đảm bảo các vấn đề bảo mật và tuân thủ quy tắc khi sử dụng ứng dụng.
- Phân tích log để cải tiến performance: Dựa trên số lượng lớn log đã ghi nhận được trong quá trình người dùng sử dụng phần mềm, chúng ta có thể dễ dàng thống kê được chức năng nào được sử dụng nhiều nhất, chức năng nào được sử dụng ít nhất, … Từ đó có thể lên phương án để cải tiến performance một cách hiệu quả hơn rất nhiều so với việc “Em đoán là …”
Công cụ phổ biến:
- ELK Stack (Elasticsearch, Logstash, Kibana)
- Splunk
Lưu ý:
Tuy nhiên, không phải vì thế mà chúng ta có thể ghi log vô tội vạ, chỗ nào cũng log.
❌ Đây là một trong những lỗi điển hình của những anh em mới tham gia làm việc ở dự án thực tế.
Thói quen này thường được anh em duy trì từ thời sinh viên, khi ứng dụng anh em code ra còn bé.
Nhưng khi tham gia những dự án lớn, việc ghi log vô tội vạ sẽ khiến cho server ghi log có thể bị crash rất nhanh. Vì số lượng người dùng lớn, mỗi người dùng lại sinh ra vô vàn log.
Vậy nên hãy cẩn trọng, đọc kỹ convention ghi log của dự án, hoặc tốt nhất là trao đổi với Dev Lead, Senior hoặc SA trong dự án, để có phương án đặt log ở đâu cho phù hợp.
2. Metrics 📊
Định nghĩa: Metrics là thuật ngữ dùng để chỉ các loại số liệu khác nhau, giúp dự án có được thông tin chi tiết để đo lường hiệu suất, hành vi và tình trạng của hệ thống.
Một số metrics hữu ích:
- Host level metrics: CPU, Memory, disk I/O, …
- Aggregated level metrics: hiệu suất của toàn bộ Database Server, Cache Server, …
- Key business metrics: daily active users, chỉ số NPS đo lường sự hài lòng của người dùng, doanh thu bán phần mềm, …
3. Monitoring 📈
Định nghĩa: Monitoring là quá trình quan sát, giám sát về hiệu suất và tình trạng của hệ thống, dựa trên những số liệu và log đã ghi lại được ở bên trên. Từ đó có thể giúp việc chẩn đoán nguyên nhân gốc rễ và khắc phục sự cố diễn ra nhanh chóng và chính xác hơn.
Nhắc đến monitoring thì hẳn mọi người sẽ biết đến “combo thần thánh” Prometheus và Grafana.
4. Notification 🔔
Định nghĩa: Sau khi đã thiết lập monitoring để giám sát hiệu suất và tình trạng của hệ thống rồi, thì không thể nào chúng ta cứ cả ngày ngồi chăm chăm nhìn vào để quan sát chúng được. Vì vậy, việc triển khai hệ thống cảnh báo cho các bên liên quan về các sự kiện hoặc vấn đề quan trọng, được phát hiện bởi các hệ thống giám sát là VÔ CÙNG CẦN THIẾT.
Dự án của mình trên công ty thường sử dụng Webhook của Slack để tích hợp việc thông báo cho những thành viên được chỉ định trong dự án như Engineering Manager, Dev Lead, SA, DevOps Engineering khi có vấn đề xảy ra với hệ thống.
Một số thiết lập cảnh báo điển hình có thể kể đến như:
- Cảnh báo tài nguyên server đã đạt ngưỡng giới hạn (Ví dụ 85%, 90% CPU)
- Các service bị down.
- Có exception xảy ra.
- …
5. Automation ♾️
Định nghĩa: Khi một hệ thống trở nên lớn và phức tạp, chúng ta cần xây dựng hoặc tận dụng các công cụ automation để cải thiện năng suất làm việc, hạn chế việc thực hiện thủ công của con người.
Thuật ngữ CI/CD ngày nay chắc hẳn đã trở nên quá phổ biến rồi.
5.1. CI (Continuous Integration)
CI là viết tắt của Continuous Integration, dịch ra tiếng Việt nghĩa là Tích hợp Liên tục.
Một kịch bản CI điển hình có thể kể đến là:
1. CI server liên tục theo dõi sự thay đổi trên repo.
2. Dev commit code lên repo Git.
3. Ngay khi commit xảy ra, CI server phát hiện repo có thay đổi, nên nó sẽ get code mới nhất từ repo.
4. Sau đó build và chạy các test đã được viết sẵn.
5. CI server generate các feedback và gửi đến member của dự án.
Quá trình này cứ lặp đi lặp lại như vậy, nên nó được gọi là Tích hợp Liên tục.
5.2. CD (Continuous Delivery)
CD là viết tắt của Continuous Delivery, dịch ra tiếng Việt nghĩa là Chuyển giao Liên tục.
Continuous Delivery sẽ giúp việc triển khai tất cả thay đổi về code (đã được build và test) đến môi trường testing hoặc staging.
Continuous Delivery cho phép developer tự động hóa phần testing bên cạnh việc sử dụng Unit test, kiểm tra phần mềm qua nhiều thước đo trước khi triển khai cho khách hàng (production).
Những bài test này bao gồm UI testing, Load testing, Integration testing, API testing, …
5.3. CD (Continuous Deployment)
Có một khái niệm nữa là Continuous Deployment, cũng viết tắt là CD. Và thường bị nhầm lần với Continuous Delivery.
Nếu Continuous Delivery là triển khai code lên môi trường staging, và deploy thủ công lên môi trường production, thì Continuous Deployment lại là kỹ thuật để triển khai code lên môi trường production một cách tự động, và cũng nên là mục tiêu của hầu hết các công ty.
Về cơ bản thì môi trường staging là môi trường giống với production, nên đã làm Continuous Delivery được thì cũng có thể làm Continuous Deployment được.
Tuy nhiên, THỰC TẾ LẠI KHÔNG DỄ DÀNG NHƯ VẬY.
Chúng ta có thể dễ dàng deploy tự động lên staging, nhưng liệu chúng ta CÓ DÁM deploy tự động với môi trường production đang có rất nhiều khách hàng sử dụng sản phẩm hay không???
Cho dù là mọi cấu hình đều giống nhau, thì trên thực tế staging và production vẫn là hai server riêng biệt. Vì thế không thể đảm bảo mọi thứ chạy đúng trên staging, sẽ chạy đúng trên production.
Thế nên nhiều dự án lựa chọn deploy thủ công lên production, để chắc chắn là các bước build, test được thực hiện chính xác.
Hoặc một giải pháp nữa đó là: deploy cho một tệp khách hàng nhỏ sử dụng thử nghiệm, trước khi release cho toàn bộ khách hàng.
Dù Continuous Deployment có thể không phù hợp với mọi công ty, nhưng Continuous Delivery thì gần như là bắt buộc cho việc thực hiện triết lý DevOps.
Lời nhắn
Bạn có thể tham khảo thêm những bài viết trong series “System Design” của mình trên blog này nhé. Hi vọng kiến thức này hữu ích với bạn.
Follow mình trên Facebook “CLB Lập trình – THPT Ngọc Tảo” hoặc kênh Youtube “Tờ Mờ Sáng học Lập trình” để cùng nhau học tập, chia sẻ những kiến thức công nghệ và lập trình hoàn toàn miễn phí nhé!
Facebook CLB Lập trình – THPT Ngọc Tảo: https://www.facebook.com/clb.it.ngoctao/
Youtube Tờ Mờ Sáng học Lập trình: https://www.youtube.com/@tmsanghoclaptrinh
Hẹn gặp lại 👋
Bạn có thể đọc thêm
Clean Architecture: A Craftsman’s Guide to Software Structure and Design – Robert C. Martin
Designing Data – Insensitive applications – Martin Kleppmann
System Analysis and Design – Alan Dennis, Barbara Haley Wixom, Roberta M. Roth
System Design Interview – Alex Xu
Modern Systems Analysis and Design – Joseph Valacich, Joey George
Head First Design Patterns – Eric Freeman, Elisabeth Robson
