Alle paar Monate fällt ein großer Dienst so aus, dass er einen großen Teil des Internets mitreißt, und die Ursache liegt dann in genau der Ebene, von der alle dachten, sie sei längst wegabstrahiert.
Abstraktion versteckt die Ebene, sie löscht sie nicht
Die Geschichte, die über Infrastruktur in den letzten fünfzehn Jahren erzählt wurde, lautet: Sie ist in der Cloud verschwunden. Server wurden Instanzen, dann Container, dann Funktionen. Netzwerke wurden Konfiguration. Speicher wurde eine Schnittstelle.
Jeder dieser Schritte ist echt und nützlich, und keiner davon hat irgendetwas entfernt. Das Paket muss immer noch ein Ziel erreichen. Der Name muss immer noch aufgelöst werden. Das Zertifikat muss immer noch gültig und aktuell sein. Die Platte muss immer noch Kapazität haben. Die Uhr muss sich immer noch mit anderen Uhren einig sein.
Was sich geändert hat, ist, wer bemerkt, wenn eines davon ausfällt, und wie schwer es zu erkennen ist.
Abstraktion verschiebt den Fehler weiter weg von der Person, die ihn erlebt, was ihn schwerer auffindbar macht und die Person, die ihn finden kann, wertvoller.
Das ist das eigentliche Argument für diese Richtung. Keine Nostalgie fürs Server-Einbauen, sondern die Beobachtung, dass die Zahl der Leute, die durchdenken können, was darunter tatsächlich passiert, schneller gesunken ist als der Bedarf an ihnen.
Was die Richtung abdeckt
Der Umfang: Betriebssysteme, Hardware, Netzwerke, Server, Administration und Fehlersuche.
Vier Bereiche.
Networking. Adressierung, Routing, Namensauflösung, Load Balancing, Firewalls und der Weg, den eine Anfrage tatsächlich nimmt.
Betriebssysteme. Prozesse, Berechtigungen, Dateisysteme, Dienste und Logs, auf den Plattformen, die die Organisation betreibt.
Identität und Verzeichnisdienste. Authentifizierung, Autorisierung, Zertifikate und die Systeme, die sie ausstellen.
Betrieb. Monitoring, Backup und Wiederherstellung, Kapazität, Patchen und strukturierte Fehlersuche.
Es ist immer DNS – und warum dieser Witz stimmt
Der laufende Witz unter Infrastruktur-Ingenieuren zeigt auf etwas Echtes darüber, wie Systeme ausfallen.
Namensauflösung liegt unter fast allem, ist unsichtbar, solange sie funktioniert, und erzeugt Symptome, die wie völlig andere Probleme aussehen. Eine Anwendung wirkt langsam, wenn die Auflösung in Timeout läuft. Ein Dienst wirkt down, wenn ein Eintrag auf eine stillgelegte Adresse zeigt. Eine Änderung verbreitet sich ungleichmäßig wegen Caching auf mehreren Ebenen, sodass das System für manche Nutzer kaputt ist und für andere funktioniert – das schwierigste Fehlerbild überhaupt.
Drei weitere Mitglieder derselben Familie verursachen aus demselben Grund einen ähnlich großen Anteil der Vorfälle.
Zertifikate. Sie laufen ab. An einem Datum, das Jahre im Voraus bekannt war. Große Ausfälle bei großen Organisationen wurden genau dadurch verursacht, wiederholt, weil die Erneuerung manuell war und die Person, die davon wusste, gegangen ist.
Zeit. Uhrendrift bricht Authentifizierungsprotokolle, macht Zertifikatsprüfungen ungültig, verfälscht Log-Korrelation und lässt verteilte Systeme inkohärent handeln. Das äußert sich als Authentifizierungsproblem, also untersuchen Leute Authentifizierung.
Routing und Pfad. Asymmetrische Routen, Pfadänderungen, Firewall-Regeln, die für einen Zweck hinzugefügt wurden und einen anderen betreffen. Symptome treten periodisch auf und nur bei manchen Quellen.
Was sie eint: Jedes davon ist Infrastruktur, auf die alle angewiesen sind und die niemandem gehört, und jedes erzeugt Symptome weit von der Ursache entfernt. Ingenieure, die wissen, das zuerst zu prüfen, lösen in Minuten, was sonst einen Tag dauert.
Wo das in der Domäne steht
IT-Systeme und Computernetzwerke ist die siebte von acht Richtungen in Astra Trainers Domäne KI, Daten und Computing, und sie fungiert als Versorgungsleitung für den Rest. Cloud Computing und DevOps, Cybersecurity und Platform Engineering rekrutieren alle von hier, und alle stützen sich auf das Verständnis, das diese Richtung aufbaut.
Sie verbindet sich am direktesten mit Computer Science für das Betriebssystem- und Netzwerkmodell und mit Cybersecurity, wo die Fähigkeit, durchzudenken, was ein System wirklich tut, die Grundlage von Erkennung und Reaktion ist. Hier findest du die acht Richtungen.
Fehlersuche ist eine Methode, kein Talent
Die am besten übertragbare und am wenigsten gelehrte Kompetenz dieser Richtung. Sie wird behandelt, als hätten Leute sie oder nicht, dabei ist sie ein Verfahren.
Feststellen, was sich tatsächlich geändert hat. Systeme, die gestern liefen und heute ausfallen, haben sich meist geändert, auch wenn alle sagen, nichts habe sich geändert. Deployments, Zertifikatserneuerungen, Regeländerungen, abgelaufene Zugangsdaten, eine Platte, die eine Schwelle überschreitet.
Den Umfang präzise definieren. Alle Nutzer oder manche. Alle Standorte oder einer. Immer oder periodisch. Jede Antwort schließt ganze Ursachenkategorien aus, und Ungenauigkeit hier ist der Grund, warum Untersuchungen abschweifen.
Entlang des Pfads arbeiten. Eine Anfrage durchläuft eine bekannte Abfolge von Komponenten. Testet an Punkten entlang davon und stellt fest, wo das Verhalten von der Erwartung abweicht. Das verwandelt ein offenes Problem in eine Suche mit endlicher Antwort.
Immer nur eine Sache gleichzeitig ändern. Mehrere zu ändern und festzustellen, dass es funktioniert, lässt euch nicht wissen, warum – ihr könnt es also weder verhindern noch beim nächsten Mal beheben.
Logs richtig lesen. Nicht den letzten Fehler, der oft eine nachgelagerte Wirkung ist, sondern die erste Anomalie und die Abfolge drumherum, mit über Systeme hinweg abgeglichenen Zeitstempeln.
Wissen, wann wiederherstellen statt diagnostizieren. Während eines Ausfalls ist es oft richtig, den Dienst wiederherzustellen und danach zu untersuchen. Wiederherstellung mit Ursachenanalyse zu verwechseln ist der Grund, warum derselbe Vorfall wiederkehrt.
Explizit gelehrt macht das gewöhnliche Ingenieure dramatisch effektiver. Implizit gelassen entwickeln Leute es über Jahre – oder nie.
Das Karriereproblem, das diese Richtung wirklich hat
Lohnt sich, offen zu benennen, denn es ist die echte Beschränkung, und sie ist nicht technisch.
Infrastrukturarbeit wird als Gemeinkosten behandelt. Sie erscheint in Budgets als Kosten, wird am Fehlen von Problemen gemessen und fällt fast nur auf, wenn etwas ausfällt. Entwicklung baut Dinge, die angekündigt werden. Infrastruktur hält Dinge am Laufen, was keine Ankündigungen erzeugt.
Vier Konsequenzen folgen daraus.
Gehalt und Status hinken angrenzenden Rollen hinterher mit vergleichbarer oder geringerer Schwierigkeit, was fähige Leute aus der Disziplin drängt.
Investitionen kommen nach Vorfällen und ebben danach wieder ab, also wird Kompetenz reaktiv aufgebaut.
Outsourcing hat den Ausbildungsboden entfernt. Die Junior-Rollen, in denen Infrastrukturverständnis aufgebaut wurde, sind in vielen Organisationen ausgelagert – dieselbe Pipeline-Blockade wie in der Cybersecurity-Richtung beschrieben.
Das Wissen ist undokumentiert und personengebunden. Welche Systeme zählen, wie normal aussieht, wo die seltsame Abhängigkeit steckt. Es geht mit der Person, und die Nachfolge baut es langsam und teuer neu auf.
Eine Organisation, die Cloud-, Security- und Platform-Kompetenz will, sollte erkennen, dass sie gerade in genau die Population unterinvestiert, aus der diese Disziplinen rekrutieren – und dass sich das günstig umkehren lässt.
Die Rollen im Überblick
Systemadministratorinnen, über die wichtigsten Plattformen hinweg.
Netzwerktechniker und -architekten.
Infrastruktur-Ingenieurinnen.
Identity- und Verzeichnisspezialisten.
Storage- und Backup-Ingenieurinnen, deren Bedeutung genau einmal offensichtlich wird.
Virtualisierungsspezialisten.
End-User-Computing- und Endpoint-Ingenieurinnen.
Servicedesk und technischer Support, der häufigste Einstiegspunkt in die ganze Domäne.
Rechenzentrumstechniker, eine Population, die mit dem Ausbau von Rechenkapazität wieder gewachsen ist.
Wer sich dafür weiterbilden kann
Servicedesk- und Support-Mitarbeitende. Der klassische und immer noch beste Weg. Sie sehen bereits die gesamte Systemlandschaft, wissen, was kaputtgeht, und bringen einen Fehlersuche-Instinkt mit, den strukturiertes Training in Methode verwandelt.
Telekommunikationstechniker. In Networking, mit der physischen und der Übertragungsebene bereits im Gepäck.
Personal aus Militärkommunikation und Informationssystemen. Häufig exzellent, mit technischer Fähigkeit und Betriebsdisziplin zugleich.
Elektriker und Gebäudetechniker. In Rechenzentrums- und physische Infrastrukturarbeit.
Alle, die informell Systeme administriert haben, in einem kleinen Unternehmen oder als die Person, die andere fragen. Echte Kompetenz ohne formale Anerkennung.
Entwickler. In Infrastruktur- und Plattformrollen, mit Bedarf an der operativen Hälfte, die ihnen nie mitgegeben wurde.
Quereinsteiger aus operativen Rollen in Logistik, Fertigung oder Versorgung, wo Prozessdisziplin und Schichtarbeit sich direkt übertragen.
Zugriff, Änderungskontrolle und Kontinuitätspflichten. Administrativer Zugriff auf Produktionssysteme ist eine hochprivilegierte Position, die Change-Management-, Logging- und Funktionstrennungsanforderungen unterliegt, in regulierten Branchen auch spezifischen Kontrollrahmen. Backup- und Wiederherstellungsfähigkeit unterliegt in vielen Branchen rechtlichen und vertraglichen Pflichten, und ungetestete Backups haben schon wiederholt versagt, wenn sie gebraucht wurden. Astra Trainer baut technische Kompetenz und das Bewusstsein dafür auf, wo diese Pflichten gelten. Es verleiht keine Zugriffsberechtigung für irgendein System und ersetzt keine organisatorischen Kontrollanforderungen.
Was du mitnehmen solltest
Cloud-Abstraktionen haben Infrastruktur hinter eine Oberfläche verschoben, ohne sie zu entfernen, was Fehler schwerer auffindbar und die Leute, die sie finden können, wertvoller gemacht hat.
Namensauflösung, Zertifikate, Zeit und Routing verursachen einen unverhältnismäßig großen Teil der Ausfälle, weil sie unsichtbar sind, bis sie versagen, und Symptome weit von ihrer Ursache erzeugen.
Fehlersuche ist eine lehrbare Methode statt eines Talents, und sie explizit zu lehren ist eine der ertragreichsten technischen Interventionen überhaupt.
Die echte Beschränkung hier ist Status und Pipeline statt Nachfrage, und Outsourcing hat die Junior-Rollen entfernt, in denen dieses Verständnis früher aufgebaut wurde.
Und jedes Cloud-, DevOps- und Security-Team rekrutiert aus dieser Population. Hier zu unterinvestieren heißt, in alle drei zu unterinvestieren.
Hat die Cloud Infrastrukturkompetenzen überflüssig gemacht?
Nein. Sie hat Infrastruktur hinter eine Oberfläche verschoben. Netzwerke, Betriebssysteme, Namensauflösung und Speicher existieren weiterhin und fallen weiterhin aus, und die Abstraktion setzt den Fehler weiter vom Symptom entfernt, was die Diagnose erschwert.
Warum verursachen DNS, Zertifikate und Zeit so viele Ausfälle?
Weil alles von ihnen abhängt, niemand sie besitzt, sie unsichtbar sind, solange sie funktionieren, und ihre Ausfälle Symptome auf einer völlig anderen Ebene erzeugen. Zertifikatsablauf hat besonders schon wiederholt große Ausfälle verursacht, an Daten, die Jahre im Voraus bekannt waren.
Lässt sich Fehlersuche lehren?
Ja. Feststellen, was sich geändert hat, den Umfang präzise definieren, entlang des Anfragepfads testen, immer nur eine Sache ändern, Logs ab der ersten Anomalie statt ab dem letzten Fehler lesen, und Wiederherstellung von Ursachenfindung trennen.
Warum wird Infrastruktur unterschätzt?
Weil sie am Fehlen von Problemen gemessen und nur bei Ausfällen bemerkt wird, also im Budget als Kosten erscheint. Gehalt und Status hinken angrenzenden Rollen hinterher, Investition kommt reaktiv nach Vorfällen, und Outsourcing hat die Junior-Rollen entfernt, die die Kompetenz aufgebaut haben.
Wer konvertiert gut in Infrastrukturrollen?
Servicedesk- und Support-Mitarbeitende zuerst, dann Telekommunikationstechniker in Networking, Militärkommunikationspersonal, Elektriker in Rechenzentrumsarbeit, informelle Administratoren und Entwickler mit Bedarf an der operativen Hälfte.