- Lịch mùa Vọng 2025 dành cho quản trị viên hệ thống là chuỗi thử thách Linux và DevOps kéo dài 12 ngày diễn ra từ ngày 1 đến ngày 12 tháng 12
- Mỗi ngày sẽ mở một bài tập theo tình huống mới với độ khó khác nhau
- Người tham gia có thể theo dõi tiến độ của mình thông qua đăng ký tài khoản miễn phí (cần có tài khoản để quản lý điểm số và thứ hạng)
- Có một tình huống có thể trải nghiệm mà không cần đăng ký, nên ai cũng có thể bắt đầu ngay
- Tập trung vào nâng cao năng lực quản trị hệ thống và giải quyết sự cố trong môi trường DevOps thực tế
Ví dụ tình huống: “Auderghem: containers miscommunication”
- Tên tình huống: “Auderghem: containers miscommunication”
- Độ khó: Easy
- Loại: Fix
- Cách truy cập: Cần xác thực email
- Giới hạn thời gian: 30 phút
- Mô tả vấn đề:
- Container Docker nginx phải nhận lưu lượng ở cổng 80 và chuyển hướng đến hai container khác nhau (statichtml1, statichtml2), nhưng hiện không hoạt động
- Người tham gia phải sửa lỗi này
- Tất cả container được phép khởi động lại nhưng không được dừng hoặc xóa
- Điều kiện kiểm tra:
Thông tin về nền tảng SadServers
- SadServers, đơn vị cung cấp, là nền tảng cung cấp các tình huống phỏng vấn và thực hành giải quyết sự cố trong môi trường Linux và DevOps
2 bình luận
Thì ra là câu chuyện về một server buồn! Đây thực sự là một nền tảng rất tuyệt.
Ý kiến trên Hacker News
Bài viết tổng hợp 12 thách thức Sysadmin/DevOps thực tế thường gặp trong công việc
1. Ngăn người dùng đăng nhập bằng root
2. Chấm dứt việc mọi người dùng chung một tài khoản và mật khẩu trên mọi máy chủ
3. Buộc ai đó cập nhật dependency của ứng dụng lên phiên bản sau năm 2010
4. Khiến mọi người dùng công cụ quản lý cấu hình thay vì ném file cấu hình từ laptop lên server bằng
scp5. Khiến mọi người dùng immutable image chứa sẵn cấu hình thay cho quản lý cấu hình
6. Khiến mọi người bỏ Jenkins và chuyển sang GitHub Actions
7. Chấm dứt tình trạng toàn bộ secret production bị nhét vào một file trên S3, và chuyển sang dùng hệ thống quản lý secret
8. Thuyết phục ban lãnh đạo và người dùng kiểu “mấy năm nay có sao đâu, sao phải mua server mới”, để
cuối cùng được duyệt mua server mới khi thực tế toàn bộ thiết bị đều sắp hỏng nguồn, đĩa, NIC, RAM và cũng không còn linh kiện thay thế
9. Xin được từ ban lãnh đạo quyền bắt buộc xoay vòng AWS access key đã không đổi suốt 8 năm
10. Chấm dứt tình trạng điên rồ là ứng dụng dùng access key của tài khoản root AWS
11. Khiến người dùng build ứng dụng dưới dạng container
12. Khiến người dùng tự deploy mà không cần bạn hỗ trợ
Cứ hoàn thành mỗi nhiệm vụ thì uống một ly scotch. Chúc kỳ nghỉ vui vẻ!
Có thiết lập workflow PR khá phức tạp, nhưng chỉ cần vài ngày không có PR là nó đột nhiên hỏng
GitHub cũng không đưa ra hướng dẫn hay phương án thay thế cho chuyện này. Với CI thì tôi thấy nhiều giải pháp khác tốt hơn hẳn
Phần lớn là rõ ràng, nhưng không phải ai cũng thấy hiển nhiên
Công ty chúng tôi dùng Sad Servers để đánh giá ứng viên DevOps/SRE
Trong lúc phỏng vấn thì có phản hồi là hơi căng thẳng, nhưng sau đó ai cũng nói đây là trải nghiệm tốt
Chỉ cần gửi link qua chat Zoom và chia sẻ màn hình là chạy được ngay, nên hiệu quả phỏng vấn rất cao
Tôi có kinh nghiệm làm tech lead ở homelab và công ty nhỏ, nhưng chưa từng làm ở môi trường quy mô lớn
Hiện tôi đang tập trung vào lấp khoảng trống kiến thức và chuẩn bị chứng chỉ
Những lúc chán nản và không biết làm gì với cuộc đời, chắc ngồi giải mấy bài Sad Server như hack thử cũng vui
Hãy tưởng tượng bạn bấm Ctrl+w để xóa một từ trong terminal, nhưng hóa ra lại đang ở cửa sổ trình duyệt nên tab đóng luôn… đúng là nỗi buồn thuần khiết
Sau một năm rưỡi phát triển trong môi trường đó, đến giờ mỗi lần nhấn Ctrl+w tôi vẫn sợ terminal thật sẽ bị đóng
Có vẻ giờ người ta gọi việc này là SRE
Tôi ghét kiểu chỉ đổi tên để tạo ra buzzword
Họ xử lý nhiều công cụ như thu thập metric, tự động hóa triển khai, v.v.
Ở công ty nhỏ thì Sysadmin thường kiêm luôn vai trò SRE, nhưng khi quy mô lớn lên thì sẽ tách bạch rõ ràng
Có vẻ tiến độ không được lưu
Tôi thật sự rất thích Sad Servers, đang chờ có bản cho Windows
Tôi nghĩ sẽ rất hay nếu có nền tảng kiểu này cho hệ sinh thái container như k8s hay Docker
Có cả bản chạy trên một VM đơn, và cũng đang thử nghiệm chạy theo pod trong cụm k8s cho mục đích PoC
Sắp tới cũng sẽ thêm các kịch bản podman
Không spoil chi tiết, nhưng tôi đã giải được bài mà script kiểm tra vẫn không pass
curlhoạt động tốt, nhưng script lại ép phải cấu hình theo một cách cụ thểTôi nghĩ kiểu này nên kiểm tra kết quả đầu ra như CTF thì tốt hơn
Việc kiểm tra hoàn hảo là rất khó, nhưng chúng tôi đang tiếp tục cải thiện để giảm false negative đến mức thấp nhất
(Trao đổi về một bình luận đã bị xóa)
Tôi nghĩ gần như không có SaaS nào cấp VM mà không cần đăng ký
Cảm ơn phản hồi, và nói rằng đã thêm nút rõ ràng hơn trên trang
/advent