Cách kiểm tra khi Server bị sập: Quy trình xác định nguyên nhân và khắc phục

Server bị sập có thể khiến Website ngừng truy cập, ứng dụng gián đoạn hoặc toàn bộ hệ thống rơi vào trạng thái không phản hồi. Tuy nhiên, không phải mọi trường hợp đều xuất phát từ việc Server thực sự Offline, mà có thể liên quan đến Network, DNS, Port hoặc các dịch vụ đang chạy. Vì vậy, kiểm tra đúng trình tự sẽ giúp quản trị viên nhanh chóng khoanh vùng vấn đề và hạn chế Downtime không cần thiết. Vậy cách kiểm tra khi Server bị sập cụ thể ra sao? Cùng Viettel IDC tìm hiểu quy trình kiểm tra và khắc phục trong bài viết dưới đây nhé.

Server bị sập là gì? Dấu hiệu nhận biết Server đang gặp sự cố

Server bị sập thường được hiểu là tình trạng máy chủ không còn đáp ứng các yêu cầu từ người dùng hoặc không thể cung cấp dịch vụ như bình thường. Tuy nhiên, “Server bị sập” không phải lúc nào cũng đồng nghĩa với việc máy chủ đã tắt hoàn toàn.

Trong thực tế, một Server vẫn có thể đang hoạt động nhưng Website, Database, Web Server hoặc một ứng dụng quan trọng đã dừng. Ngược lại, Server có thể vẫn phản hồi Ping nhưng các Port dịch vụ lại không thể kết nối. Vì vậy, cần kiểm tra nhiều lớp trước khi kết luận máy chủ thực sự gặp sự cố.

Một số dấu hiệu thường gặp gồm:

- Không thể kết nối đến Server: Quản trị viên không thể đăng nhập bằng SSH đối với Linux hoặc Remote Desktop đối với Windows Server. 

- Website hoặc ứng dụng không truy cập được: Người dùng nhận lỗi Timeout, Connection Refused, 502, 503 hoặc 504. 

- Server phản hồi chậm: Máy chủ vẫn hoạt động nhưng thời gian phản hồi tăng cao. Tình trạng này có thể liên quan đến CPU, RAM, Disk I/O, Database hoặc lưu lượng truy cập tăng đột biến.

Do đó, khi Website không truy cập được, không nên mặc định rằng Server đã sập. Quy trình troubleshooting nên bắt đầu bằng việc xác định phạm vi sự cố và kiểm tra từng lớp của hệ thống. Các hướng dẫn troubleshooting Website downtime cũng khuyến nghị xác định nơi request bị dừng trước khi đi sâu vào từng thành phần.

Cách kiểm tra khi Server bị sập

Khi Server có dấu hiệu bất thường, bạn nên kiểm tra theo thứ tự từ bên ngoài vào bên trong. Trước tiên cần xác định Server có thực sự Offline hay không, sau đó kiểm tra đường truyền, Port, DNS và dịch vụ liên quan. Cách làm này giúp tránh việc thay đổi cấu hình hoặc khởi động lại máy chủ khi nguyên nhân thực tế chỉ nằm ở DNS hoặc Network.

Kiểm tra trạng thái Server trên hệ thống quản trị

Nếu Server được triển khai trên Cloud, VPS hoặc nền tảng quản trị tập trung, hãy kiểm tra trạng thái máy chủ ngay trên hệ thống quản trị của nhà cung cấp. 

Nếu hệ thống quản trị hiển thị Server đang Running nhưng Website không truy cập được, chưa nên kết luận Server bị sập. Có khả năng hệ điều hành vẫn hoạt động nhưng Network, Firewall hoặc Application đang gặp vấn đề. Ngược lại, nếu Server hiển thị Stopped, Failed hoặc không thể thực hiện các thao tác quản trị thông thường, cần kiểm tra tiếp các sự kiện của hệ thống và hạ tầng cung cấp dịch vụ.

Kiểm tra kết nối bằng Ping

Ping là một trong những bước đơn giản nhất để kiểm tra khả năng kết nối đến địa chỉ IP của Server. Nếu nhận được phản hồi, điều đó cho thấy Server hoặc thiết bị đích đang phản hồi ICMP. Tuy nhiên, Ping thành công không đồng nghĩa Website hoặc ứng dụng đang hoạt động.

Ngược lại, Ping không nhận được phản hồi cũng chưa đủ để kết luận Server đã sập. Firewall có thể được cấu hình để chặn hoặc bỏ qua ICMP trong khi các dịch vụ TCP như HTTPS hoặc SSH vẫn hoạt động. Microsoft cũng lưu ý rằng Ping chỉ là một phép kiểm tra kết nối cơ bản và không nên được sử dụng như bằng chứng duy nhất để kết luận toàn bộ kết nối đến Server.

Kiểm tra đường truyền bằng Traceroute hoặc Tracert

Nếu Ping không ổn định hoặc Server có độ trễ cao, bước tiếp theo là kiểm tra đường đi của gói tin. Traceroute giúp hiển thị các Hop mà lưu lượng đi qua từ thiết bị nguồn đến Server. Qua đó, quản trị viên có thể quan sát nơi độ trễ tăng bất thường hoặc nơi đường truyền không tiếp tục đến đích.

Tuy nhiên, không nên kết luận rằng một Hop không phản hồi chính là điểm lỗi. Một số Router có thể giới hạn hoặc ưu tiên thấp các gói tin phục vụ Traceroute nhưng vẫn chuyển tiếp lưu lượng bình thường.

Kiểm tra Port và dịch vụ đang lắng nghe

Một Server có thể Ping được nhưng Website vẫn không truy cập được vì Port dịch vụ đã bị đóng hoặc Service không còn lắng nghe. Bạn có thể kiểm tra Port từ một máy khác bằng các công cụ phù hợp. Trên Linux, một số quản trị viên sử dụng nc để kiểm tra kết nối TCP: nc -zv 192.168.1.10 443

Nếu Port kết nối thành công, có thể xác định rằng đường kết nối TCP đến Port đó đang hoạt động. Nếu nhận Connection refused, có khả năng không có Service lắng nghe trên Port hoặc hệ thống chủ động từ chối kết nối. Nếu bị Timeout, nguyên nhân có thể liên quan đến Firewall, Network hoặc Service không phản hồi.

Kiểm tra DNS khi không truy cập được Website

Nếu người dùng không thể truy cập Website bằng tên miền nhưng Server vẫn hoạt động, DNS là một thành phần cần được kiểm tra. Trước tiên, cần kiểm tra tên miền có phân giải đúng địa chỉ IP hay không. Kết quả cần được đối chiếu với IP thực tế của Server hoặc Load Balancer đang phục vụ Website.

Nếu DNS trả về IP cũ sau khi Website vừa chuyển Server, người dùng có thể tiếp tục kết nối đến hệ thống cũ. Nguyên nhân có thể liên quan đến DNS Cache và TTL. Ngoài ra, cần kiểm tra cả bản ghi A, AAAA hoặc CNAME nếu Website sử dụng các loại bản ghi này.

Nguyên nhân thường khiến Server bị sập

Server có thể gặp sự cố vì nhiều nguyên nhân khác nhau như: 

- Server quá tải tài nguyên: Khi CPU bị sử dụng quá cao, RAM gần cạn hoặc Disk I/O liên tục ở mức cao, hệ thống có thể phản hồi chậm, Timeout hoặc không thể xử lý thêm request.

- Service hoặc Application bị Crash: Điều này có thể khiến Website hoặc hệ thống ngừng hoạt động dù Server vẫn đang bật. Ví dụ, Nginx vẫn còn hoạt động nhưng Application phía sau đã dừng; hoặc Database gặp lỗi khiến toàn bộ Website không thể xử lý request.

- Disk đầy hoặc Storage gặp lỗi: Khi phân vùng chứa Log, Database hoặc dữ liệu ứng dụng không còn dung lượng, Service có thể không ghi được dữ liệu mới hoặc không thể khởi động. Với Storage gặp lỗi phần cứng hoặc I/O bất thường, hiệu năng Server cũng có thể suy giảm mạnh.

- Network hoặc Firewall gặp sự cố: Firewall có thể chặn Port, Route có thể bị gián đoạn hoặc Interface mạng có thể gặp lỗi.

- Lỗi hệ điều hành hoặc cấu hình: Một thay đổi tưởng như nhỏ cũng có thể khiến Service không khởi động hoặc Server không thể kết nối mạng.

Cách khắc phục khi Server bị sập

Sau khi xác định được nguyên nhân, bước khắc phục cần ưu tiên khôi phục dịch vụ nhưng đồng thời phải hạn chế làm mất thêm dữ liệu hoặc che mất dấu vết của sự cố.

Nếu Server vẫn truy cập được và nguyên nhân đến từ một Process sử dụng quá nhiều CPU hoặc RAM, có thể dừng Process hoặc Service gây quá tải sau khi xác định rõ tác động của nó. Với Application quan trọng, cần kiểm tra Logs trước khi Kill Process để tránh bỏ qua nguyên nhân gốc.

Nếu Service bị dừng, có thể khởi động lại Service sau khi kiểm tra trạng thái và Logs. Trên Linux sử dụng systemctl là một cách phổ biến để quản lý Service, ví dụ:

systemctl status nginx

hoặc:

systemctl restart nginx

Tuy nhiên, không nên liên tục Restart Service mà không kiểm tra nguyên nhân. Nếu Application liên tục Crash, việc Restart chỉ khôi phục tạm thời và sự cố có thể nhanh chóng lặp lại.

Trong trường hợp Disk đầy, cần xác định phân vùng hoặc thư mục chiếm nhiều dung lượng trước khi xóa dữ liệu. Không nên xóa Log, Database hoặc File hệ thống một cách tùy tiện. Với hệ thống Production, việc giải phóng dung lượng cần đi kèm kiểm tra chính sách lưu trữ và Backup.

Nếu Server không thể truy cập bằng SSH hoặc Remote Desktop, nhưng vẫn có quyền quản trị qua Cloud Console hoặc hệ thống quản lý Out-of-Band, có thể sử dụng kênh này để kiểm tra hệ điều hành và khôi phục dịch vụ.

Khởi động lại Server chỉ nên được xem là một biện pháp phù hợp khi hệ thống thực sự bị treo, không thể xử lý qua các phương án an toàn hơn hoặc nhà cung cấp khuyến nghị thực hiện. Việc Restart có thể khiến các thông tin phục vụ điều tra bị mất hoặc làm gián đoạn thêm những dịch vụ đang hoạt động.

Nếu sự cố liên quan đến hạ tầng vật lý, Network của Data Center, Cloud Platform hoặc không thể xác định nguyên nhân từ bên trong Server, nên liên hệ nhà cung cấp hạ tầng. Khi gửi yêu cầu hỗ trợ, nên cung cấp thời điểm bắt đầu sự cố, IP hoặc hostname, triệu chứng, kết quả Ping/Traceroute, Port, Logs và những thay đổi vừa thực hiện. Thông tin càng đầy đủ, quá trình khoanh vùng càng nhanh.

Với Windows Server, Event Viewer là nguồn dữ liệu quan trọng để kiểm tra các sự kiện liên quan đến hệ thống và Network. Microsoft cũng khuyến nghị thu thập Event Logs và Network Trace trong nhiều tình huống troubleshooting để phân tích chính xác điểm lỗi.

Một nguyên tắc quan trọng là không thay đổi quá nhiều thành phần cùng lúc. Nếu vừa sửa Firewall, đổi DNS, Restart Server và cập nhật Application trong cùng một thời điểm, rất khó xác định thao tác nào thực sự giải quyết vấn đề. Hãy ưu tiên từng bước, ghi nhận kết quả và tiếp tục kiểm tra dựa trên bằng chứng thu được.

Kết luận

Kiểm tra khi Server bị sập đúng cách sẽ giúp nhanh chóng khoanh vùng sự cố và hạn chế thời gian Downtime. Sau khi xác định được nguyên nhân, doanh nghiệp cần xử lý đúng thành phần gây lỗi và tránh khởi động lại Server khi chưa cần thiết. Monitoring, Backup và phương án dự phòng giúp tăng khả năng phục hồi, duy trì hệ thống ổn định. Lựa chọn hạ tầng Server phù hợp cùng giải pháp giám sát và hỗ trợ kịp thời sẽ giúp doanh nghiệp vận hành an toàn, liên tục.