| Liebe Leserin, lieber Leser,
|
| nichts ist wirklich sicher in der IT – auch die mühsam gehegte Infrastruktur im eigenen Betrieb nicht. Deshalb sollte man sich unbedingt vorher Gedanken machen, wie man seine Systeme wieder hochbekommt, wenn es mal so richtig gescheppert hat. Unser Titelautor Frank Benke hat bereits die Bewährungsprobe des Neustarts nach Ransomware-Befall gemeistert. Er berichtet, worauf es ankommt und wie Sie sich für den RZ-Kaltstart vorbereiten können. Einen Überblick aller Themen des neuen Hefts finden Sie im Inhaltsverzeichnis der iX 4/2026.
|  |
|
|
| |
|
|
| | | | Phönix aus der Asche: Wie im Ernstfall der IT-Neustart gelingt | |
| |
| |
Frank Benke ist Leiter der operativen IT in der HAHN Automation Group und verantwortlich für den Betrieb einer globalen Infrastruktur in neun Ländern.
Axel: Was sind knapp gesagt die wesentlichen Punkte für die Kaltstartfähigkeit der eigenen IT-Infrastruktur?
Frank: Das sind im Grunde drei ganz wesentliche Faktoren. Zuallererst Standardisierung als Voraussetzung . Ohne geht es nicht und bis man in einer gewachsenen Umgebung alle notwendigen Infrastruktur-Elemente und Systeme standardisiert hat, können schon ein paar Jahre ins Land gehen. Insofern lohnt es sich durchaus auch sofort mit Standardisieren anzufangen, selbst wenn die Kaltstartfähigkeit noch in den Sternen steht – die operativen Benefits erntet man sofort.
Darauf aufsetzend kommt die konsequente Automatisierung von allem, was sich irgendwie automatisieren lässt. Das vererbt dabei auch die Anforderung in die Standardisierung, dass eine grundsätzliche und unabdingbare Anforderung das Vorhandensein von Management-Schnittstellen oder APIs ist. Das Dritte ist dann eine ganz grundsätzliche und konsequente Data Governance, die Systemen und Informationen Prioritäten zuordnet und sie auch in den darunter liegenden Schichten der Infrastruktur ganz systematisch voneinander entkoppelt. Dazu braucht man noch die Disziplin, diese drei Themen konsequent durchzuziehen und eine Betriebsmannschaft, die auch Spaß daran hat, dies jeden Tag aufs Neue zu leben.
Axel: Die Krisenlage, die derzeit wohl am meisten gefürchtet wird, ist der Ransomware-Befall. Worauf kommt es in so einer brenzligen Situation an, wenn man seine Systeme wieder hochbringen will?
Frank: Meine Ansichten zum Thema Kaltstart kommen daher, dass ich schon einmal einen Neuaufbau einer kompromittierten IT-Infrastruktur orchestrieren durfte und dabei auch mit der Leidensfähigkeit und dem Enthusiasmus meiner Kollegen so haushalten musste, dass sie dieses Unterfangen auch durchstehen. Wir waren seinerzeit dahingehend sehr erfolgreich, dass die Infrastruktur innerhalb von zweieinhalb Wochen wieder bei 80 Prozent der Produktivität angekommen war.
Die erste Erkenntnis: Das Backup ist weder von der Forensik freigegeben noch wäre es schnell genug wiederherzustellen – man muss an Daten heran, die in der kompromittierten Zone sind und das auf eine sichere Art und Weise. Zweite Erkenntnis: Obwohl wir innerhalb von zwei Tagen eine vergleichsweise potente alternative Infrastruktur aus dem Boden stampfen konnten, hätte die Überführung der dort temporär in Betrieb genommenen Systeme in den Regelbetrieb viel zu lange gedauert. Das heißt, die "rote Zone" der kompromittierten Infrastruktur muss so schnell wie möglich bereinigt und dann wieder produktiv genommen werden. Und die dritte Erkenntnis war, dass wir nur überlebt haben, weil wir schon viele Standardisierungen umgesetzt haben und weitreichende Überlegungen zur Automatisierung sowie erste Umsetzungen am Start waren.
Und last but not least, der Human Factor. Ein erfolgreicher Angriff auf die Infrastruktur erschüttert das Vertrauen im Betrieb bis ins Fundament und konfrontiert alle damit, dass Pentests und mehrjährige Security-Improvement-Projekte immer noch nicht vor Zero Day Exploits schützen.
|
| |
|
|
| |
|
| |
|
|
| | Frank Benke (links) im Gespräch mit iX-Redakteur Axel Kannenberg
|
|
| |
|
| |
|
| | Axel: Was verbirgt sich hinter dem Ansatz des Site Reliability Engineering (SRE)?
Frank: SRE kommt dabei raus, wenn agile Softwareleute plötzlich Infrastruktur machen müssen. Es ist Abstraktion und Infrastruktur as Code und damit nicht mehr und nicht weniger als ein Paradigmenwechsel in der Art, wie Infrastruktur betrachtet und betrieben wird. Damit muss dann auch der geneigte IT-Verantwortliche sich von der traditionellen Sichtweise lösen, dass jedes System für sich gehätschelt und optimiert wird. Software lebt mit Fehlern und auch dem Umgang mit demselben. Dafür gibt es Fehlermeldungen und Reviews und hoffentlich sehr bald ein neues Release, das dieselben behebt. SRE führt dafür Fehlerbudgets ein, entlang derer Systeme integriert und kontinuierlich verbessert werden. Das geschieht in der Hoffnung, die bösen Fehler auch nur einmal zu machen, daraus zu lernen und das Wissen zu multiplizieren.
Axel: Wie kann Automatisierung bei der Vorbereitung für den Ernstfall helfen?
Frank: Automatisierung ist unabdingbar. Am Ende spielen bei einem Ernstfall ausschließlich Laufzeiten eine Rolle. Der Kunde, das Unternehmen, hat in eine Infrastruktur investiert und diese gibt die Grenzen des Machbaren vor. Der oben beschriebene Verlust des Vertrauens in die eigenen Fähigkeiten und Systeme bedingt, dass für die Initialisierung eines Wiederanlaufplanes Freiheiten geschaffen werden müssen. Die erlauben, sich mit den Ursachen und der Verhinderung des gleichen Vorfalls zu beschäftigen und auch die Themen abzufangen, die sich nicht automatisieren lassen oder die sich während des Ereignisses verändert haben.
Da auch die Bandbreite des Zugriffs auf die betroffene Infrastruktur begrenzt ist, muss ein Kernteam in der Lage sein, eine sichere Umgebung in kürzester Zeit wiederherzustellen, ebenso wie die Konfidenz in die eigenen Fähigkeiten und Systeme. dann einen breiteren Zugriff auf die Landschaft zu ermöglichen um die exotischen Themen ab zu räumen. Dabei ist die "Bandbreite" der Infrastruktur im Sinne dessen, was sie an Rollout-Workload insgesamt bewältigen kann, ein kritischer Faktor, an dem nicht ohne weiteres zu rütteln ist. Nur Automatisierung erlaubt es den Flaschenhals von der Infrastruktur auf die menschliche Schaffenskraft zu verschieben, die sich dann auf die Dinge konzentrieren muss, die man eben nicht automatisieren kann.
Axel: Wie sollten die Storage-Systeme und Storage-Pools strukturiert sein?
Frank: Das muss natürlich jeder für seine Umgebung selbst bewerten. Ich bin jedoch zu dem Schluss gekommen, dass ganz konsequent die oben genannten Prioritäten aus der Data Governance auch systemisch abgebildet sein müssen und zwar hinsichtlich Performance und Verfügbarkeit. Ein weiterer, extrem wichtiger Aspekt ist, Storage-Architekturen so weit wie möglich zu flexibilisieren. Das geht meiner Meinung nach mit monolithischen proprietären Storage-Systemen gar nicht, oder nur sehr bedingt. Daher bin ich seit mehr als zehn Jahren ein extrem großer Freund von Software Defined Storages. Das kann man sogar so viel weiter spinnen, dass man hier auf offene Standards und breit verfügbare Protokolle oder Codes abzielt.
|
| |
|
|
| |
|
| |
|
|
| | | | Im Heft geschmökert: Empfehlungen der iX-Redaktion | |
| |
|
| |
| | | | IT-Administratoren stehen vor der Herausforderung, die Vielzahl an Endgeräten im Unternehmen zu kontrollieren. Moderne Softwareplattformen für Unified Endpoint Management (UEM) erleichtern diese Aufgabe: Sie verwalten nahezu alle Gerätetypen über ihren gesamten Lebenszyklus, verteilen Updates, prüfen die Sicherheit und steuern das Nutzungsverhalten. Die iX-Marktübersicht zeigt nicht nur aktuelle Produkte und ihre Funktionen, sondern hilft auch bei der strategischen Entscheidung. Wichtige Fragen sind: Welche Compliance-Vorgaben gelten? Soll der Betrieb in der Cloud oder lokal erfolgen? Funktioniert die API-Anbindung an bestehende Securitysysteme?
Tilman Wittenhorst, Redakteur iX
|
| |
|
|
|---|
|
| |
|
| |
|
| | | | Coding-Agenten sollen die Softwareentwicklung beschleunigen, sind aber schwer zu koordinieren. Das Open-Source-Framework Gas Town von Steve Yegge orchestriert mehrere Agenten nach dem Vorbild von Kubernetes. Die Architektur ist dem Mad-Max-Film entlehnt: Die chaotischen Zustände in der Stadt stehen für das Chaos, das sich beim Koordinieren ergibt. Rollen und Abläufe sind daher festgelegt. Gas Town besitzt einen Kompensationsmechanismus, der beispielsweise zum Einsatz kommt, wenn ein Coding-Agent aus Versehen einen Unit-Test löscht, einen Merge-Konflikt verursacht oder unsauberen Code implementiert. Es beschränkt nicht das Chaos probabilistischer Sprachmodelle, sondern ordnet es.
Nicole Bechtel, Redakteurin iX
|
| |
|
|
|---|
|
| |
|
| |
|
|
| | | | Workshop-Tipp: KI für eigene Daten – Retrieval Augmented Generation (RAG) in der Praxis mit LangChain.js | |
| |
| |
Wie bringt man KI dazu, mit den eigenen Daten zu arbeiten? In diesem dreitägigen Hands-on-Workshop entwickeln Sie Schritt für Schritt eigene KI-Agenten mit LangChain.js und LangGraph.js und integrieren Retrieval Augmented Generation (RAG) in Ihre Anwendungen.
Der Fokus liegt auf praktischem Ausprobieren: In einer interaktiven Lernumgebung setzen Sie RAG selbst um, experimentieren mit Prompts und lernen, wie sich KI-Anwendungen effizient gestalten lassen. Anhand praxisnaher Beispiele bauen Sie eine moderne KI-Architektur auf – von der Anbindung eigener Daten über Retrieval-Pipelines bis hin zu KI-Lösungen, die zuverlässige Antworten liefern, in der Cloud oder on Premises.
Am Ende verfügen Sie nicht nur über ein solides Verständnis der Architektur, sondern auch über das Know-how, um RAG-basierte Lösungen direkt in eigenen Projekten umzusetzen.
|
| |
| |
|
| |
|
| |
|
|
| | | | Weitere Themen in der iX 4/2026 | |
| |
| | Außerdem gehen wir in der neuen iX den Haftungsfragen für KI am Arbeitsplatz auf den Grund und testen, wie sich Inferenz-Engines für LLMs im Vergleich schlagen. SAP-Nutzer finden außerdem einen ausführlichen Praxisartikel zu ABAP Cloud im April-Heft. Alle Themen finden Sie im Inhaltsverzeichnis der iX 4/2026.
Haben Sie Anregungen zum Newsletter oder zum Heft allgemein? Schreiben Sie mir unter axk@ix.de! Ich wünsche Ihnen einen sonnigen Start in den Frühling und ein frohes Osterfest, Ihr
|
|
| |
|
| |
| | Neugierig geworden? Sie erhalten die iX 4/2026 ab dem 19. März im heise Shop und ab dem 20. März am Kiosk:
|
| |
|
| |
|
| |
| Sie sind unter folgender Adresse eingetragen: unknown@unknown.invalid - .
Hier können Sie sich von künftigen Zusendungen abmelden.
| |
| Verantwortlich für den Inhalt:
Heise Medien GmbH & Co. KG
Karl-Wiechert-Allee 10
30625 Hannover
Telefon: +49 [0]511 5352-0
E-Mail: infoservice@heise.de
Registergericht:
Amtsgericht Hannover HRA 26709
|
| | Persönlich haftende Gesellschafterin:
Heise Medien Geschäftsführung GmbH
Registergericht:
Amtsgericht Hannover, HRB 60405
Geschäftsführer: Ansgar Heise, Beate Gerold
|
|
|---|
|
| |
| Herausgeber: Christian Heise, Ansgar Heise
Chefredakteur: Dr. Oliver Diedrich (verantwortlich)
Alle Rechte vorbehalten. Jegliche Vervielfältigung oder Weiterverbreitung in jedem Medium als Ganzes oder in Teilen bedarf der schriftlichen Zustimmung des Verlags. Copyright © 2026 Heise Medien GmbH & Co. KG
| |
|
| |
