Hi Vtitans,
Đây có thể là một câu hỏi phỏng vấn hay đấy! Do giảm thiểu chi phí, nhiều ổ cứng trên server chỉ có size minimum. Cỡ 10GB là đủ cho Linux EC2 và Google VM chạy web app rồi, nhưng với điều kiện là đã có ý thức và biện pháp phòng tránh lỗi đầy ổ. Và trong thực tế thì hai thứ này (ý thức và biện pháp) không miễn phí đâu, nên mình nghĩ là câu hỏi này fair enough nếu đang tìm một ứng viên biết chuyện dưới lòng đất. (Đừng đem ra hỏi một anh SA dumper, anh ấy phản đam thì lại mất vui)

Dấu hiệu, cũng là hậu quả

Làm sao biết nó đầy ổ cứng? Nếu trả lời gõ lệnh df thì không sai, nhưng đó là khi bạn có thể SSH vào nó cơ.
Vì Connect trực tiếp trên web console là tiện lợi và phổ biến, nên tốt nếu như ta biết rằng phương pháp này lại trục trặc khi server đầy ổ cứng.
Trong trường hợp của Google, khi bạn connect từ web, G phải ghi một key tạm vào file authorized_keys của một user cũng có thể là tạm. Việc ghi không tiến hành được, G fail. SSM của Zôn thì không báo lỗi rõ ràng như G, nên mình chỉ biết qua kinh nghiệm là khi bạn ấy trục trặc, thì nguyên nhân đầu tiên là đầy ổ cứng, chứ không phải đoán già đoán non gì đâu.
Với Zôn, không SSH được thì sẽ hơi phức tạp, mình xin anh phỏng vấn next cho nhanh. Kinh nghiệm là đừng rely tất vào SSM, vẫn nên để permanent key dự phòng để có thể SSH qua bastion.

SSH được thì làm gì?

Vâng có vài tips để share:

1. Gõ lệnh không được thì đừng dùng tab (auto-complete)
2. File mà hay bị mình xoá là log của journald, sau một hồi giả vờ kiểm tra là không có nhà phân tích nào cần nó cả. Biết tỏng là ông mà pờ rồ thì tôi đã chả phải chui vào đây, xời.
3. Xoá bớt rồi mới có thể configure log rotate, vì khi đã đầy thì ghi một dòng config cũng không được.
4. Cũng đừng vội xoá file, hãy xem có thằng nào đang tiếp tục ăn ổ không để tránh tình trạng xoá xong nó lại đầy luôn. Chú ý các app java với đặc sản file hprof và exception stack trace dài như sông Mê kông.

Extend ổ - chạy lệnh hay không, restart hay không?

Với Zôn, nhìn guide gai quá nên mình toàn nhờ đệ làm. Xong hỏi đệ là có phải restart không xong quên nó trả lời gì rồi. Bảo blog thì nó lười, thằng Tuấn râu á, nên mình chỉ để link đây và không nói gì: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
Với G, G khoe feature online resizing ở đây: https://cloud.google.com/blog/products/gcp/introducing-google-cloud-persistent-disks-with-non-disruptive-online-resizing . Nhưng đừng nhầm, bản chất của G cũng vậy thôi và nó thể hiện ở câu này:

After you resize a disk that's already mounted on a VM instance, resize the file system. Usually it's as simple as running resize2fs on Linux or resizing partitions in Windows Disk Manager.

Có nghĩa là không SSH được thì vẫn là không được. Tuy nhiên, cơ hội lớn là bạn resize rồi reboot là OK.

Reboot thì có vấn đề gì?

Nói chung đầy ổ thì service cũng down rồi, không nói chuyện downtime nữa, trừ khi service không ghi ổ cứng, hay gặp với docker.
Vấn đề thực tế hơn là khi tiếp quản một con server chả biết nó cài đặt ra sao và chạy thế nào. Đây là gợi ý một số thứ nên tìm hiểu trước khi quyết định reboot - chỉ là gợi ý:

• Các service có được configure auto start không? Docker-compose là thứ dễ bị misconfig, phải start bằng tay.
• Có cái job nào đang chạy và nên chờ cho nó chạy xong không?
• Có cái user data nào lẽ ra phải chạy cả khi reboot, nhưng lại bị misconfig chỉ chạy khi launch, hoặc ngược lại không?
• Server có nằm trong auto scaling group không? vv..

Câu trả lời rõ ràng

Đến đây mình thấy là mông lung rồi, và câu hỏi này đúng là đi vào lòng đất. Nhưng có một thứ rõ ràng mà bạn nên trình bày, thể hiện là bạn đã từng chui cống nhưng vẫn có lý tưởng cao đẹp:
Có 3 điều em sẽ làm:

1. Configure log rotate
2. Đặt alert khi ổ cứng đầy khoảng 90%. Em có kinh nghiệm về mảng monitoring đấy ạ
3. Viết document ngắn gọn mô tả con server mà em quản lý

Anh đừng hỏi khoai nữa được không ạ -)))
Thân, from Châu D9