12 điểm bởi GN⁺ 2025-12-02 | 2 bình luận | Chia sẻ qua WhatsApp
  • Lịch mùa Vọng 2025 dành cho quản trị viên hệ thốngchuỗ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

 
roxie 2025-12-03

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.

 
GN⁺ 2025-12-02
Ý 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 scp
    5. 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ẻ!

    • Về mục 6 là GitHub Actions, có vấn đề là worker đã xác thực nếu không hoạt động khoảng 5 ngày thì sẽ biến mất khỏi pool
      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
    • Bước đầu tiên của các vấn đề kiểu này là giải thích một cách cụ thể và có tài liệu vì sao nó quan trọng
      Phần lớn là rõ ràng, nhưng không phải ai cũng thấy hiển nhiên
    • Bảo chuyển từ Jenkins sang GitHub Actions thì… tôi thật sự không hiểu tại sao phải làm vậy
    • Có người đùa rằng họ đã báo cơ quan chức năng vì câu “Sysadmin/DevOps giờ là từ đồng nghĩa”
    • Mục 5 và 6 là vấn đề sở thích và đánh đổi, còn lại thì tôi hoàn toàn đồng cảm
  • 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

    • Nghe vậy thấy vui thật, và tôi cũng định bắt đầu thử thách hằng ngày của Sad Servers từ hôm nay
      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

    • Trước đây tôi từng dùng gotty để mở terminal trong trình duyệt, và cả team đã remap Ctrl+w thành Ctrl+`
      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
    • Nên mới càng thấy biết ơn thiết kế tách biệt phím Command của macOS
    • Dù sao thì bạn vẫn có thể mở lại tab vừa đóng gần đây bằng Ctrl+Shift+T
    • (Tác giả) Xin lỗi nhé. Chỉ cần bấm lại nút “Open the Server Terminal in a New Window” là được
    • Tôi hiểu cảm giác đó. Tôi cũng hay dính khi dùng KVM
  • 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

    • Định nghĩa tôi thích là: SRE là “coi vận hành như một bài toán phần mềm
    • Tôi cũng ghét buzzword, nhưng SRE đúng là một vai trò khác
    • SRE là người đảm bảo ứng dụng tiếp tục chạy được trên nền tảng
      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ác giả) Hãy kiểm tra dashboard, nếu vẫn không được thì liên hệ qua email hoặc form trên website
  • Tôi thật sự rất thích Sad Servers, đang chờ có bản cho Windows

    • (Tác giả) Cảm ơn, và nói rằng trong tương lai có thể sẽ cân nhắc bản 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

    • (Tác giả SadServers) Đã có các kịch bản dựa trên k8s rồi
      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
    curl hoạ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

    • (Tác giả) Cảm ơn phản hồi, giờ đã deploy image mới chỉ kiểm tra mục tiêu cuối cùng
      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)

    • Có người nhắc rằng Advent of Code cũng yêu cầu tài khoản
    • (Tác giả) Trên nền tảng này, từ trang chủ chỉ cần bấm “give me a server” hai lần là có VM ngay
      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
    • Cũng có phản hồi đùa nửa thật kiểu “Vậy rốt cuộc bạn muốn nó hoạt động thế nào, bạn có đúng là sysadmin không đấy?”