12 pontos por GN⁺ 2025-12-02 | 2 comentários | Compartilhar no WhatsApp
  • Calendário do Advento para administradores de sistemas 2025 é uma série de desafios de Linux e DevOps durante 12 dias, de 1º a 12 de dezembro
    • A cada dia, é publicado um novo desafio baseado em cenário com nível de dificuldade diferente
  • Os participantes podem acompanhar seu progresso com um cadastro de conta gratuito (é preciso ter conta para gerenciar pontuação e ranking)
  • Há um cenário que pode ser experimentado sem cadastro, permitindo que qualquer pessoa comece imediatamente
  • O foco está em fortalecer habilidades de resolução de problemas e administração de sistemas em um ambiente prático de DevOps

Exemplo de cenário: “Auderghem: containers miscommunication”

  • Nome do cenário: “Auderghem: containers miscommunication”
    • Dificuldade: Easy
    • Tipo: Fix
    • Forma de acesso: requer verificação por e-mail
    • Limite de tempo: 30 minutos
  • Descrição do problema:
    • O contêiner Docker do nginx deve receber tráfego na porta 80 e redirecioná-lo para dois contêineres diferentes (statichtml1, statichtml2), mas isso não está funcionando
    • O participante deve corrigir esse problema
    • Todos os contêineres podem ser reiniciados, mas não podem ser parados nem removidos
  • Condições de teste:

Informações sobre a plataforma SadServers

  • A SadServers, empresa responsável pela oferta, é uma plataforma que fornece cenários práticos e de entrevista para resolução de problemas em ambientes Linux e DevOps

2 comentários

 
roxie 2025-12-03

Então era uma história de servidor triste! É realmente uma plataforma excelente.

 
GN⁺ 2025-12-02
Comentários do Hacker News
  • Foi feita uma lista de 12 desafios reais de Sysadmin/DevOps vividos no trabalho
    1. Fazer com que os usuários não façam login como root
    2. Acabar com a prática de todos os usuários compartilharem uma única conta e senha em todos os servidores
    3. Fazer alguém atualizar as dependências do aplicativo para versões posteriores a 2010
    4. Fazer com que usem uma ferramenta de gerenciamento de configuração em vez de sair jogando arquivos de configuração do notebook para o servidor via scp
    5. Fazer com que usem imagens imutáveis com a configuração embutida em vez de gerenciamento de configuração
    6. Abandonar o Jenkins e migrar para GitHub Actions
    7. Acabar com a situação em que segredos de produção ficam todos reunidos em um arquivo no S3 e fazer com que usem um sistema de gerenciamento de segredos
    8. Convencer a gerência e os usuários que dizem “ficou anos sem dar problema, por que precisamos de um servidor novo?” e conseguir aprovação para comprar servidores novos, explicando que, na verdade, todo o equipamento está prestes a falhar em fonte, disco, NIC e RAM, e não há peças de reposição
    9. Conseguir da diretoria autoridade para forçar a rotação de chaves de acesso da AWS que não mudam há nada menos que 8 anos
    10. Fazer parar a situação insana em que o aplicativo usa chaves de acesso da conta root da AWS
    11. Fazer com que os usuários buildem o aplicativo como container
    12. Fazer com que os usuários façam deploy por conta própria, sem sua ajuda
    A cada desafio concluído, pode tomar um copo de scotch. Boas festas!

    • Sobre o item 6, GitHub Actions, houve um problema em que workers autenticados sumiam do pool depois de uns 5 dias de inatividade
      Foi montado um workflow de PR complexo, mas se passassem alguns dias sem PRs, ele quebrava de repente
      Também não havia orientação nem alternativa por parte do GitHub sobre isso. Como CI, acho outras soluções muito melhores
    • O primeiro passo nesses problemas é explicar de forma concreta e documentada por que isso é importante
      A maioria parece óbvia, mas não é algo evidente para todo mundo
    • Trocar Jenkins por GitHub Actions... realmente não entendo por que isso seria necessário
    • Sobre a frase “Sysadmin/DevOps agora são sinônimos”, disseram em tom de piada que denunciaram às autoridades
    • Os itens 5 e 6 são questão de preferência e trade-offs, mas no resto concordo totalmente
  • Na nossa empresa usamos Sad Servers para avaliar candidatos de DevOps/SRE
    Há feedback de que durante a entrevista dá um pouco de nervosismo, mas depois todo mundo diz que foi uma boa experiência
    Basta mandar o link pelo chat do Zoom e pedir compartilhamento de tela que funciona na hora, então a eficiência da entrevista é muito alta

    • Fiquei feliz de ouvir isso e também quero começar hoje mesmo o desafio diário do Sad Servers
      Tenho experiência com homelab e trabalhando como tech lead em empresas pequenas, mas ainda não em ambientes de grande escala
      No momento estou focando em preencher lacunas de conhecimento e me preparar para certificações
  • Quando bate a deprê e parece que não há nada para fazer no mundo, resolver problemas do Sad Server como se estivesse hackeando parece divertido

  • Imagine apertar Ctrl+w para apagar uma palavra no terminal, mas na verdade estar numa janela do navegador e ela fechar... isso é a própria tristeza

    • Antes eu usava gotty para abrir terminais no navegador, e o time inteiro remapeou Ctrl+w para Ctrl+`
      Depois de desenvolver por um ano e meio nesse ambiente, até hoje toda vez que aperto Ctrl+w fico com medo de fechar um terminal de verdade
    • Isso faz perceber de novo o quanto o design separado da tecla Command no macOS é uma bênção
    • Ainda assim, dá para reabrir a aba fechada recentemente com Ctrl+Shift+T
    • (Criador) Desculpe. É só clicar de novo no botão “Open the Server Terminal in a New Window”
    • Entendo perfeitamente. Isso também acontece comigo às vezes quando uso KVM
  • Hoje em dia acho que chamam isso de SRE
    Não gosto de ficar só trocando nome para criar buzzword

    • Uma definição de que eu gosto é: SRE é tratar operações como um problema de software
    • Eu também odeio buzzwords, mas SRE é claramente uma função diferente
    • SRE é o papel de manter os aplicativos rodando sobre a plataforma
      Lida com várias ferramentas, como coleta de métricas e automação de deploy
      Em empresas pequenas, o Sysadmin também acumula o papel de SRE, mas conforme a escala cresce isso se separa claramente
  • Parece que o progresso não está sendo salvo

    • (Criador) Pediu para verificar o dashboard e, se ainda assim não funcionar, entrar em contato por e-mail ou pelo formulário do site
  • Gosto muito do Sad Servers e estou esperando sair uma versão para Windows

    • (Criador) Agradeceu e disse que está considerando uma versão para Windows algum dia
  • Acho que seria bom ter uma plataforma assim também para ecossistemas de containers como k8s ou Docker

    • (Criador do SadServers) Já existem cenários baseados em k8s
      Há também uma versão executada em uma única VM, e eles estão experimentando rodar em nível de pod em um cluster k8s para PoC
      No futuro também devem adicionar cenários com podman
  • Sem dar spoiler, resolvi o problema, mas o script de checagem não passa
    O curl funcionava bem, mas o script exigia uma forma específica de configuração
    Acho que, nesse tipo de coisa, seria melhor um modelo estilo CTF que verifica só o resultado

    • (Criador) Agradeceu o feedback e disse que agora já implantou uma nova imagem para verificar apenas o objetivo
      Uma checagem perfeita é difícil, mas eles seguem melhorando para minimizar false negatives
  • (Conversa sobre um comentário apagado)

    • Houve menção de que o Advent of Code também exige conta
    • (Criador) Disse que, na plataforma, basta clicar duas vezes em Home → “give me a server” e a VM é entregue na hora
      Acha que quase não existem SaaS que forneçam VM sem cadastro
      Agradeceu o feedback e disse que adicionou um botão claro na página /advent
    • Também houve uma resposta em tom de brincadeira: “Então como você queria que isso funcionasse, você é mesmo um sysadmin de verdade?”