Es gibt Projekte, die bleiben im Gedächtnis. Nicht weil sie perfekt geplant waren. Nicht weil alles von Anfang an reibungslos lief. Sondern weil sie genau das Gegenteil waren: komplex, riskant und voller Überraschungen.
Eines dieser Projekte durfte ich 2007 als technischer Produktmanager bei der damaligen 1&1 Internet AG begleiten. Heute kennt man das Unternehmen als IONOS. Damals standen wir vor einer Aufgabe, die aus heutiger Sicht fast schon absurd erscheint. Mehr als 15.000 Linux Shared-Hosting und Managed-Server sollten auf eine neue Linux-Distribution migriert werden. Ganz ohne Redundanz, ohne Hochverfügbarkeitscluster und ohne die Möglichkeiten moderner Cloud-Infrastrukturen.
Jeder einzelne Server musste aktualisiert werden. Jeder einzelne Server würde währenddessen nicht verfügbar sein. Und auf jedem einzelnen Server lagen Webseiten, Shops und andere Anwendungen zahlreicher Kunden.
Die Herausforderung bestand nicht darin, ob das technisch möglich war. Die eigentliche Herausforderung bestand darin, die Ausfallzeiten für unsere Kunden so gering wie möglich zu halten. Und dabei möglichst keine Überraschungen zu erleben.
Natürlich kam es anders.
Eine Infrastruktur aus einer anderen Zeit
Wer heute über Hosting spricht, denkt an Container, Kubernetes, IaaS-Plattformen, Load-Balancer und automatisierte Rollouts. Server werden innerhalb von Minuten neu bereitgestellt. Updates laufen im Hintergrund. Fällt ein System aus, übernimmt ein anderes.
2007 sah die Welt noch völlig anders aus. Damals basierte die Linux Shared-Hosting- und Managed-Server-Infrastruktur noch auf Debian Woody. Eine Distribution, deren erste Version bereits im Jahr 2002 veröffentlicht worden war. Für moderne Verhältnisse war das selbst damals nahezu ein Fossil.
Natürlich war das nicht ungewöhnlich. Hosting-Plattformen waren damals deutlich konservativer. Stabilität stand über allem. Solange Systeme zuverlässig liefen, wurden sie nicht leichtfertig verändert. Doch irgendwann kommt der Punkt, an dem technische Schulden größer werden als die Risiken einer Migration.
Genau an diesem Punkt befanden wir uns. Und damit gleichzeitig auch mein erstes Projekt als technischer Produktmanager.
Der Plan bestand darin, die Plattform auf Debian Etch zu aktualisieren. Das bedeutete nicht nur neue Pakete und neue Bibliotheken. Praktisch jede Kernkomponente des Systems würde sich verändern. Betriebssystem, Dienste, Abhängigkeiten und unzählige Anwendungen mussten überprüft werden.
Schon damals war uns klar, dass wir nicht einfach ein paar Testsysteme aktualisieren und anschließend produktiv loslegen konnten. Dafür war die Umgebung zu groß und die Auswirkungen potenzieller Fehler zu gravierend. Deshalb bauten wir zunächst eine möglichst realistische Testumgebung auf.
Eine Entscheidung, die sich als goldrichtig herausstellen sollte.
Der Moment, in dem das Projekt zu scheitern drohte
Die ersten Tests verliefen vielversprechend. Server ließen sich migrieren. Webseiten funktionierten. E-Mail-Dienste liefen. Datenbanken arbeiteten stabil. Das Projekt schien auf einem guten Weg zu sein. Bis wir auf ein Produkt stießen, das viele bereits vergessen haben dürften – Microsoft FrontPage.
Damals nutzten noch rund 40.000 Kunden die sogenannten FrontPage Server Extensions. Diese Erweiterungen ermöglichten Funktionen, die FrontPage-Webseiten für Formulare, Veröffentlichungen und weitere Features benötigten.
Aus heutiger Sicht wirkt das fast schon wie ein Relikt aus einer anderen Epoche des Internets. Doch damals war FrontPage für viele kleine Unternehmen, Vereine und Privatpersonen ein wichtiges Werkzeug. Und genau dort lag unser Problem.
Während die Erweiterungen unter Debian Woody funktionierten, liefen sie unter Debian Etch nicht mehr. Die Ursache war zwar schnell gefunden, doch hatte Microsoft die Pflege der FrontPage Server Extensions längst abgegeben. Ein Drittanbieter hatte den Support übernommen und stellte entsprechende Pakete bereit. Allerdings nicht für Debian, sondern ausschließlich für Red Hat.
Damit standen wir vor einer Situation, die kein Projektplan vorgesehen hatte. 40.000 Kunden nutzten eine Funktion, die nach dem Upgrade nicht mehr funktionieren würde.
Das wohl ungewöhnlichste Supportgespräch meiner Karriere
Natürlich versuchten wir zunächst den offiziellen Weg. Gemeinsam mit mehreren Linux-Administratoren nahmen wir Kontakt zum Anbieter auf. Vielleicht existierte eine Debian-Version. Vielleicht gab es Unterstützung bei einer Portierung. Vielleicht konnten wir einen kostenpflichtigen Supportvertrag abschließen. Mit all diesen Möglichkeiten hatten wir gerechnet. Was dann geschah, überraschte uns allerdings komplett.
Nachdem wir unsere Situation erklärt hatten und wissen wollten, ob man uns gegen entsprechende Vergütung unterstützen könne, kam praktisch sofort die Gegenfrage: „Wie lautet Ihre Kreditkartennummer?“
Keine Analyse, keine technischen Rückfragen, keine Diskussion über Machbarkeit, keine Interesse an der eigentlichen Herausforderung – lediglich die Frage nach der Kreditkarte.
Ein kurzer Blick in die Runde genügte und wir beendeten das Gespräch. Bis heute gehört dieser Moment zu den absurdesten Support-Erfahrungen meiner beruflichen Laufbahn. Nicht wegen der Kosten, die uns quasi gar nicht erst offeriert wurden. Sondern wegen der Haltung. Wir suchten eine technische Lösung für ein reales Problem. Stattdessen fühlte sich das Gespräch an, als wolle man eine Rechnung schreiben, bevor überhaupt verstanden wurde, worum es ging.
Wenn die besten Ideen nach Feierabend entstehen
Jeder, der schon einmal in größeren IT-Projekten gearbeitet hat, kennt solche Momente. Man hat analysiert, man hat diskutiert, man hat Meetings abgehalten, man hat Whiteboards gefüllt und trotzdem gibt es keine Lösung. Genau in einer solchen Situation befanden wir uns damals.
Nach einem langen Arbeitstag beschlossen wir, gemeinsam in eine Karlsruher Studentenkneipe zu gehen. Das gesamte Team war dabei. Linux-Administratoren, Support-Mitarbeiter, technische Experten und Projektbeteiligte. Wir tranken Bier, einige bevorzugten Wein, andere bestellten Korea (das war ich). Vor allem aber redeten wir. Zunächst natürlich über das Problem, über FrontPage, über den 3rd-Party-Dienstleister und über die Sackgasse, in der wir steckten.
Doch irgendwann wechselte das Thema, wie so oft nach Feierabend. Plötzlich ging es um Gaming. Wer spielte gerade welches Spiel? Welche Klassiker waren wieder interessant? Ich erwähnte beiläufig, dass ich mir kürzlich einen Emulator heruntergeladen hatte, um alte Spiele erneut zu spielen. Und genau in diesem Moment machte es Klick – ein Emulator. Warum eigentlich nicht? Warum musste die FrontPage-Erweiterung zwingend nativ vorhanden sein? Warum konnten wir die benötigten Funktionen nicht emulieren? Warum nicht mit PHP, was man quasi in jeden Hosting-Tarif inkludieren konnte? Die Frage stand plötzlich im Raum und sofort entstand eine Dynamik, die man nicht planen kann.
Die Umsetzung eines Support-Mitarbeiters rettet das Projekt
Kaum war die Idee ausgesprochen, reagierte einer unserer Support-Mitarbeiter sofort. Er holte sein Notebook hervor und noch direkt in der Kneipe, noch während wir zusammensaßen begann er zu programmieren. Heute klingt das vielleicht wie eine Geschichte aus einem Film. Tatsächlich geschah es genau so. Während ich mit dem restlichen Projektteam über die veränderte Vorgehensweise weiterdiskutierte, schrieb er erste PHP-Snippets und analysierte die benötigten Funktionen. Keine zwanzig Minuten später blickte er auf und sagte einen Satz, den ich nie vergessen werde: „Das kriege ich hin.“.
Natürlich war damit nicht alles gelöst. Zwischen einem Prototypen und einer produktionsreifen Lösung liegen Welten. Doch zum ersten Mal hatten wir wieder eine realistische Perspektive. In den folgenden Wochen entstand daraus ein FrontPage-Emulator auf PHP-Basis, der die für unsere Kunden relevanten Funktionen abbildete. Nicht als perfekte Kopie, nicht als vollständige Neuentwicklung, sondern als pragmatische Lösung für ein konkretes Problem. Genau das machte den Unterschied.
Technik allein reicht nicht aus
Viele IT-Projekte scheitern nicht an der Technik. Sie scheitern an der Kommunikation. Genau deshalb investierten wir mindestens genauso viel Energie in die Kundenkommunikation wie in die technische Umsetzung. Uns war bewusst, dass 40.000 betroffene Kunden enorme Risiken bedeuteten. Schon geringe Unsicherheiten hätten tausende Support-Anfragen auslösen können. Fehlende Informationen in der Umstellung hätten Frust erzeugt. Und kleinste Missverständnisse hätten Kündigungen verursachen können. Deshalb entwickelten wir eine umfassende Kommunikationsstrategie.
Dazu gehörten unter anderem:
- Frühzeitige und regelmäßig wiederkehrende und zielgerichtete Kundeninformationen
- Umfangreiche FAQ-Dokumentationen
- Klare Erläuterungen der Änderungen, insbesondere für die betroffenen Frontpage-Kunden
- Schulungen für Customer-Care-Mitarbeitende
- Interne Eskalationsprozesse
- Technische Leitfäden für Sonderfälle
Jeder dieser Punkte hatte einen klaren Zweck. Die Kunden sollten verstehen, was passiert. Sie sollten wissen, warum die Änderungen notwendig waren. Und sie sollten jederzeit Unterstützung erhalten können.
Besonders die FAQ-Dokumentationen erwiesen sich als entscheidender Erfolgsfaktor. Viele Fragen konnten bereits beantwortet werden, bevor sie überhaupt gestellt wurden. Das reduzierte Unsicherheit und stärkte gleichzeitig das Vertrauen in den Migrationsprozess.
Auch die intensive Schulung der Customer-Care-Teams zahlte sich aus. Kunden erhielten kompetente Antworten, ohne zwischen verschiedenen Abteilungen weitergereicht zu werden. Dadurch entstand der Eindruck einer kontrollierten und professionellen Umstellung.
Rückblickend war dies mindestens genauso wichtig wie jede technische Lösung.
Die eigentliche Migration
Wochen später war es soweit. Die Vorbereitungen waren abgeschlossen. Die Testläufe erfolgreich. Die Kommunikationsmaßnahmen waren bereits aktiv und der FrontPage-Emulator einsatzbereit.
Nun begann die eigentliche Migration, Server für Server, Nacht für Nacht, Kontrolliert und geplant. Die Arbeiten starteten bewusst nach Mitternacht europäischer Zeit. Dadurch konnten Auswirkungen auf die meisten Webseitenbesucher minimiert werden. Auch die amerikanischen Kunden profitierten von dieser Planung, da die Zugriffe dort ebenfalls außerhalb der Hauptnutzungszeiten lagen. Und mit jedem Tag wurde die Anzahl zu migrierender Server je Tag um ein vielfaches erhöht.
Jede Migration bedeutete einen kontrollierten Ausfall des jeweiligen Servers. Anders war es technisch nicht möglich. Dennoch gelang es dem Team, die durchschnittliche Downtime auf rund fünf Minuten zu begrenzen. Fünf Minuten. Heute klingt das möglicherweise viel. Damals war das für ein Distributionsupgrade dieser Größenordnung ein hervorragender Wert.
Noch wichtiger war jedoch etwas anderes: Die meisten Kunden bemerkten die Downtime überhaupt nicht.
Das Ergebnis überraschte alle
Vor dem Projekt gab es zahlreiche Prognosen. Einige rechneten mit Beschwerden. Andere erwarteten eine massive Belastung des Supports. Wieder andere gingen von einer spürbaren Anzahl an Sonderkündigungen aus. Insbesondere die rund 40.000 FrontPage-Kunden galten als Risiko.
Die Realität sah jedoch völlig anders aus. Die Support-Hotlines wurden nicht überlastet. Die erwarteten Beschwerdewellen blieben aus. Die Sonderkündigungen blieben ebenfalls aus. Genauer gesagt: Es gab keine einzige Kündigung aufgrund der FrontPage-Umstellung. Keine. Null.
Für ein Projekt dieser Größenordnung war das bemerkenswert. Nicht weil alles perfekt war. Sondern weil die Kombination aus Technik, Kommunikation und Teamarbeit funktionierte. Genau das machte den Unterschied.
Was dieses Projekt mich bis heute gelehrt hat
Auch viele Jahre später denke ich noch regelmäßig an dieses Projekt zurück. Nicht wegen der 15.000 Server. Nicht wegen Debian Woody oder Debian Etch. Nicht einmal wegen FrontPage. Sondern wegen der Menschen.
Technische Herausforderungen lassen sich meistens lösen. Manchmal dauert es länger. Manchmal werden Umwege notwendig. Aber fast immer existiert eine Lösung. Die eigentliche Frage lautet, ob das richtige Team vorhanden ist.
Dieses Projekt hat gezeigt, was möglich wird, wenn unterschiedliche Kompetenzen zusammenkommen. Linux-Administratoren, Support-Mitarbeiter, Produktmanager und Customer-Care-Teams arbeiteten gemeinsam an einem Ziel. Niemand dachte in Abteilungsgrenzen. Niemand versteckte sich hinter Zuständigkeiten. Und genau deshalb gelang das Projekt.
Eine weitere Erkenntnis war, dass gute Ideen selten auf Knopfdruck entstehen. Sie kommen oft dann, wenn der Druck kurz nachlässt. Nicht im Meetingraum. Nicht während der hundertsten PowerPoint-Präsentation. Sondern manchmal in einer Studentenkneipe bei einem Bier und einem Gespräch über Computerspiele.
Natürlich bestand die Lösung nicht aus Alkohol. Natürlich bestand sie auch nicht aus Gaming. Doch beides sorgte dafür, dass die Köpfe frei wurden und ein neuer Blickwinkel entstand. Manchmal reicht genau das.
Von fünf Minuten Downtime zu Null-Downtime-Architekturen
Heute hat sich die Hosting-Welt grundlegend verändert. IaaS-Plattformen ermöglichen es, komplette Server innerhalb kürzester Zeit bereitzustellen. Redundante Architekturen sorgen dafür, dass einzelne Systeme ausfallen können, ohne dass Kunden etwas davon bemerken. Rolling Updates, Container-Orchestrierung und Hochverfügbarkeitskonzepte machen viele Probleme von damals nahezu unsichtbar.
Selbst Downtimes von fünf Minuten gelten heute in vielen Umgebungen bereits als kritisch. 2007 waren fünf Minuten bei einem Betriebssystem-Upgrade auf einer Plattform mit mehr als 15.000 Servern dagegen ein exzellentes Ergebnis.
Die Technologie hat sich verändert. Die Herausforderungen haben sich verändert. Doch eines ist geblieben: Erfolgreiche Projekte entstehen nicht durch Technik allein. Sie entstehen durch Menschen, die gemeinsam Verantwortung übernehmen, kreativ denken und auch in schwierigen Situationen nicht aufgeben.
Und manchmal beginnt die entscheidende Lösung eben nicht im Rechenzentrum, sondern in einer Karlsruher Studentenkneipe.
