Advent of SysAdmin 2025

 (sadservers.com)
12 Punkte von GN⁺ 2025-12-02 | 2 Kommentare | Auf WhatsApp teilen
  • Der Adventskalender 2025 für Systemadministratoren ist eine 12-tägige Linux- und DevOps-Challenge-Serie, die vom 1. bis 12. Dezember läuft
    • An jedem Tag wird ein neues szenariobasiertes Problem mit unterschiedlichem Schwierigkeitsgrad veröffentlicht
  • Teilnehmende können ihren Fortschritt über eine kostenlose Kontoerstellung verfolgen (ein Konto ist erforderlich, um Punkte und Ranglisten zu verwalten)
  • Es gibt ein Szenario, das auch ohne Registrierung ausprobiert werden kann, sodass jeder sofort loslegen kann
  • Der Fokus liegt auf der Stärkung von Troubleshooting- und Systemadministrationsfähigkeiten in einer praxisnahen DevOps-Umgebung

Beispiel-Szenario: „Auderghem: containers miscommunication”

  • Szenarioname: „Auderghem: containers miscommunication”
    • Schwierigkeitsgrad: Easy
    • Typ: Fix
    • Zugangsart: E-Mail-Verifizierung erforderlich
    • Zeitlimit: 30 Minuten
  • Problembeschreibung:
    • Der nginx-Docker-Container sollte Traffic auf Port 80 empfangen und an zwei andere Container (statichtml1, statichtml2) weiterleiten, funktioniert aber nicht
    • Die Teilnehmenden müssen dieses Problem beheben
    • Alle Container dürfen neu gestartet, aber nicht gestoppt oder gelöscht werden
  • Testbedingungen:

Informationen zur Plattform SadServers

  • SadServers, der Anbieter, ist eine Plattform für Troubleshooting-Interviews und praxisnahe Szenarien in Linux- und DevOps-Umgebungen

Verwandte Beiträge

2 Kommentare

 
roxie 2025-12-03

Es war also die Geschichte eines traurigen Servers! Wirklich eine großartige Plattform.
 
GN⁺ 2025-12-02
Hacker-News-Kommentare

  • Es wurden 12 echte Sysadmin/DevOps-Herausforderungen aus dem Arbeitsalltag zusammengestellt
    1. Benutzer davon abhalten, sich als root anzumelden
    2. Die Praxis beenden, dass alle Benutzer für alle Server ein gemeinsames Konto und Passwort teilen
    3. Jemanden dazu bringen, die Abhängigkeiten seiner Anwendung auf Versionen nach 2010 zu aktualisieren
    4. Statt Konfigurationsdateien per scp vom Laptop auf den Server zu werfen, ein Konfigurationsmanagement-Tool verwenden lassen
    5. Statt Konfigurationsmanagement unveränderliche Images (immutable images) mit eingebauter Konfiguration verwenden lassen
    6. Jenkins abschaffen und zu GitHub Actions wechseln
    7. Die Situation beenden, dass in S3 alle Production-Secrets in einer einzigen Datei liegen, und stattdessen ein Secret-Management-System verwenden lassen
    8. Management und Benutzer davon überzeugen, die Frage „Es gab seit Jahren kein Problem, warum brauchen wir einen neuen Server?“ aufzugeben, und die Anschaffung neuer Server genehmigen zu lassen, obwohl in Wahrheit bei allen Geräten Netzteil, Festplatten, NICs und RAM kurz vor dem Ausfall stehen und es keine Ersatzteile mehr gibt
    9. Vom Management die Befugnis bekommen, AWS-Access-Keys zu rotieren, die seit unglaublichen 8 Jahren nicht geändert wurden
    10. Den Wahnsinn beenden, dass eine Anwendung Access-Keys des AWS-Root-Accounts verwendet
    11. Benutzer dazu bringen, ihre Anwendung als Container zu bauen
    12. Benutzer dazu bringen, ohne deine Hilfe selbst zu deployen
    Nach jeder erledigten Aufgabe darf man einen Schluck Scotch trinken. Frohe Feiertage!

    • Zu Punkt 6 mit GitHub Actions: Es gab ein Problem, bei dem authentifizierte Worker nach etwa 5 Tagen Inaktivität aus dem Pool verschwanden
      Man hatte komplexe PR-Workflows aufgebaut, und wenn es ein paar Tage lang keine PRs gab, brach plötzlich alles auseinander
      Von GitHub gab es dazu weder Hinweise noch eine Alternative. Für CI seien andere Lösungen deutlich besser
    • Der erste Schritt bei solchen Problemen ist, konkret und dokumentiert zu erklären, warum sie wichtig sind
      Das meiste ist offensichtlich, aber eben nicht für alle
    • Von Jenkins auf GitHub Actions wechseln? … Ich verstehe wirklich nicht, warum man das tun sollte
    • Zur Aussage „Sysadmin/DevOps sind inzwischen Synonyme“ wurde scherzhaft gesagt, man habe das den Behörden gemeldet
    • Punkt 5 und 6 sind Geschmacks- und Trade-off-Fragen, aber dem Rest stimme ich voll zu

  • Unsere Firma verwendet Sad Servers zur Bewertung von DevOps-/SRE-Kandidaten
    Während des Interviews sei es laut Feedback etwas stressig, aber hinterher sagen alle, es sei eine gute Erfahrung gewesen
    Man schickt einfach den Link im Zoom-Chat und braucht nur Screen-Sharing, daher ist die Interview-Effizienz sehr hoch

    • Es freut mich, das zu hören, und ich will ab heute auch die Daily Challenges von Sad Servers anfangen
      Ich habe Erfahrung mit Homelabs und als Tech Lead in kleinen Firmen, aber noch nicht in großen Umgebungen
      Momentan konzentriere ich mich darauf, Wissenslücken zu schließen und mich auf Zertifizierungen vorzubereiten

  • Wenn man niedergeschlagen ist und nichts zu tun hat, klingt es spaßig, Sad-Server-Probleme wie ein Hacking-Rätsel zu lösen

  • Stell dir vor, du willst im Terminal mit Ctrl+w ein Wort löschen, aber es ist in Wirklichkeit ein Browserfenster und das Fenster schließt sich … pure Traurigkeit

    • Früher habe ich mit gotty ein Terminal im Browser genutzt, und das ganze Team hat Ctrl+w auf Ctrl+` umgemappt
      Nach anderthalb Jahren Entwicklung in dieser Umgebung habe ich bis heute Angst, dass ich mit Ctrl+w ein echtes Terminal schließe
    • Da merkt man wieder, wie dankbar man für die Trennung durch die Command-Taste in macOS sein kann
    • Immerhin kann man mit Ctrl+Shift+T den zuletzt geschlossenen Tab wieder öffnen
    • (Autor) Tut mir leid. Man kann einfach noch einmal auf „Open the Server Terminal in a New Window“ klicken
    • Ich kann das Gefühl nachvollziehen. Mit KVM passiert mir das auch oft

  • Heute nennt man das wohl SRE
    Ich mag es nicht, wenn einfach nur Namen geändert werden, um Buzzwords zu erzeugen

    • Meine Lieblingsdefinition war: SRE bedeutet, Operations als Softwareproblem zu behandeln
    • Ich mag Buzzwords auch nicht, aber SRE ist definitiv eine andere Rolle
    • SRE sorgt dafür, dass Anwendungen auf der Plattform weiterlaufen
      Dazu gehören viele Tools wie Metrik-Erfassung oder Deployment-Automatisierung
      In kleinen Firmen übernimmt ein Sysadmin oft auch die SRE-Rolle, aber mit wachsender Größe trennt sich das klar

  • Es scheint, als würde der Fortschritt nicht gespeichert

    • (Autor) Man solle im Dashboard nachsehen und sich, falls es weiterhin nicht funktioniert, per E-Mail oder über das Formular auf der Website melden

  • Ich mag Sad Servers wirklich sehr und warte auf eine Windows-Version

    • (Autor) Danke, und man denke darüber nach, irgendwann auch eine Windows-Version anzubieten

  • So eine Plattform wäre auch für das Container-Ökosystem wie k8s oder Docker wünschenswert

    • (SadServers-Autor) Es gibt bereits k8s-basierte Szenarien
      Es gibt auch eine Version, die auf einer einzelnen VM läuft, und es wird mit einem k8s-Cluster für PoCs experimentiert, in dem sie auf Pod-Ebene laufen
      Künftig sollen auch Podman-Szenarien hinzukommen

  • Ich vermeide Spoiler, aber ich habe das Problem gelöst und das Check-Skript schlägt trotzdem fehl
    curl funktionierte problemlos, aber das Skript erzwang eine bestimmte Art der Konfiguration
    So etwas sollte wie bei einem CTF lieber nur das Ergebnis prüfen

    • (Autor) Danke für das Feedback, man habe inzwischen ein neues Image ausgerollt, das nur noch das Ziel prüft
      Perfekte Checks seien schwierig, aber man arbeite weiter daran, False Negatives zu minimieren

  • (Gespräch zu einem gelöschten Kommentar)

    • Es wurde erwähnt, dass auch Advent of Code ein Konto erfordert
    • (Autor) Auf der Plattform bekommt man sofort eine VM, wenn man auf Home geht und zweimal auf „give me a server“ klickt
      Es gebe kaum SaaS-Angebote, die ohne Registrierung eine VM bereitstellen
      Danke für das Feedback; auf der Seite /advent sei nun ein klarer Button hinzugefügt worden
    • Es gab auch die scherzhafte Reaktion: „Wie soll es denn sonst funktionieren, bist du wirklich ein Sysadmin?“