Zugschlusbeobachtungen (Entries tagged as zkmlf)

zkmlf: Dokumentiert! Besonders, wenn es stressig ist

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 05 Jan 2010 12:00:00 +0100

Wenn irgendwas unerwartet schief läuft (und das wird es - niemand kann für alle Eventualitäten planen), schreibt Euch auf, was wann wie nicht funktioniert hat, notiert, welche Tests Ihr durchgeführt habt und woran es schließlich lag. Daraus könnt Ihr nur lernen, und im Zweifel hilft Euch diese Dokumentation, um in der Nachlese zu erklären, was da eigentlich passiert ist. Wer schreibt, der bleibt - dieser Spruch ist nie so wahr wie in Streitigkeiten mit dem Kunden. Ich habe gute Erfahrungen damit gemacht, ein Diktiergerät neben mir liegen zu haben, denn ein kurzer Zwischenstand lässt sich schneller sprechen als schreiben, und nebenbei hat es auch noch den Vorteil, dass der Kunde einem nicht über die Schulter guckt und in dem Text, den man eben nur so als Gedächtnisstütze hingeschludert hat, anfängt herumzukorrigieren. Zeit, um das diktierte zu schreiben und in druckreife Form zu gießen, habt Ihr außerhalb der heißen Migrationsphase noch genug. Im Nachhinein geschriebene Braindumps sind oft zu lückenhaft und manchmal auch schlicht inkorrekt.

Natürlich solltet Ihr auch dokumentieren, wenn Ihr nicht an einer Verzögerung schuld seid. Mit vom Kunden verursachten Verzögerungen (Rackschlüssel nicht da, Suche nach Montagematerial, Patchkabeln etc) kommt man einem wutschnaubendem Manager prima bei, der die Begründung dafür haben möchte, warum man am Ende der angekündigten Downtime immer noch nicht wieder vollständig “up” ist. Im Idealfall wäre man ohne die vom Kunden zu verantwortende Verzögerung gerade “in time” fertig geworden, oder, noch besser, die Bräsigkeit des Kunden hat die eigene Arbeit so verzögert, dass man selbst noch unverschuldet weitere Verzögerungen erzeugt hat.

zkmlf: Management macht Ärger, Benutzersupport hält Ärger fern

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 04 Jan 2010 12:00:00 +0100

Achtet darauf, dass die korrekte und aktuelle Zeitplanung nicht nur mit Eurem technischen Ansprechpartner abgeklärt ist, sondern dass auch das Management und der Benutzersupport Bescheid wissen und den Zeitplan abgenickt haben: Das eine macht Euch im Zweifel bei Misstverständnis mitten in der heißen Phase die Hölle heiß, das andere kann Euch den Rücken von störenden Rückfragen freihalten. Etabliert einen Verteiler, über den Ihr bei Verzögerungen zeitnah informiert, damit der angenehme Zustand der Ruhe beim Arbeiten möglichst lang aufrecht erhalten werden kann. Nehmt bei größeren Aktionen einen Praktikanten oder Azubi mit, der für Euch die Kommunikation mit der Außenwelt macht: So habt ihr den Kopf frei für Euren eigentlichen Job.

zkmlf: Fallstrick VPN

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 03 Jan 2010 12:00:00 +0100

VPNs sind eine Thematik, die einem besonders bei Firewallprojekten immer wieder schmerzhaft auf die Füße fallen. Im Gegensatz zur klassischen Firewall hat man es bei VPN-Links oft mit Setups zu tun, bei denen man von einer Gegenstelle und deren technischer Kompetenz oder Kooperationsbereitschaft abhängt.

Es kommt in der Praxis vor, dass ein solches Projekt auf die Nase fällt oder auf einen vorhergehenden Stand zurückgerollt werden muss, weil nach dem Tausch einer Komponente der VPN-Link nicht mehr auf die Füße kommt, weil der paranoiden Gegenstelle ein vom neuen Gerät anders gesetztes Statusbit im IKE-Phase-1-Proposal nicht in den Kram passt und man morgens um zwei keinen technischen Ansprechpartner der Gegenseite zu fassen bekommt, der einem aus dem Log der Gegenstelle vorlesen könnte oder der gar eine von uns dringend benötigte Anpassung schnell durchführen kann.

Bei Client-VPNs für mobile User hat man oft keine Möglichkeit, selbst zu testen, weil der VPN-Zugang in vielen Unternehmen ein Statussymbol ist und das Fußvolk, mit dem man es im Projekt zu tun hat, nicht über so einen Zugang verfügt. Hier lohnt es sich in aller Regel, durch alle vom Kunden aufgestellten brennenden Reifen zu springen, um einen solchen Zugang während der Migration zur Verfügung gestellt zu bekommen, damit man testen kann. Sonst darf man zu irgendwelchen Unzeiten (morgens um acht nach einer bis vier Uhr morgens gehenden Migrationsnacht) mit unwilligen und unhöflichen Managern telefonieren und mit ihnen zusammen das VPN debuggen, nicht ohne sich ständig anhören zu müssen dass der Gesprächspartner eigentlich arbeiten müsste. Zum selbst testen ist ein unabhängiger Internetzugang von Vorteil, der notfalls per UMTS oder (besser!) mit einem UMTS-to-WLAN-Router oder (noch besser!) mit einem extra für solche Zwecke bereitgehaltenen DSL-Zugang in den Arbeitsräumen des Migrationsprojekts - zumindest die UMTS-Lösungen kann man für den Fall eines Falles selbst bereithalten.

Rechnet gerade im Falle von IPSEC nicht damit, dass das, was der Kunde als Dokumentation im Schrank stehen hat, stimmt. Die Parameter einer IPSEC-Verbindung sind vielfältig, und bei vielen Geräten hat man nicht die Möglichkeit, an wirklich jeder Stellschraube zu drehen. Deswegen ist es nicht selten, dass die Mail, die der Kunde archiviert hat, nur das theoretische “Wunschkonzert” einer der beiden Seiten darstellt, und eventuell stimmt beispielsweise die Time-To-Live des Phase2-Proposals nicht mehr mit der Dokumentation überein, weil das VPN-Gerät der Gegenseite gar nicht erlaubt, diesen Wert getrennt von seinem Phase1-Gegenstück einzustellen. Wenn man bei einem Gerät einen Parameter nicht einstellen kann, muss man wissen, welchen Wert das Gerät hier verwendet - das muss nicht notwendigerweise der Wert sein, der in der Dokumentation steht.

So gerne ich bei Debuggingaktionen einfach mal mit einem Sniffer aufs Kabel gucke, so wenig hilft das in aller Regel bei VPN-Tunneln - denn die Kommunikation ist aus naheliegenden Gründen verschlüsselt. Das reicht also höchstens dafür, um beurteilen zu können, ob die Geräte überhaupt versuchen, miteinander zu kommunizieren. Will man es genauer wissen, muss man in den sauren Apfel beißen und gucken, ob man dem Gateway selbst irgendwelche Informationen entlocken kann. Leider ist das oft auch der Punkt, wo die Herstellerdokumentation aufhört, weil es nun interessant wird. Mit Glück kriegt man noch gesagt, wie das Kommando zum Aktivieren des Debugging heißt.

Lustig sind hier auch die Shared Secrets, denn bei vielen Geräten bekommt man sie zwar rein, nicht aber wieder aus dem Gerät heraus. Und wenn sich dann auch noch herausstellt, dass das alte Gerät im Shared Secret standardwidrig keine Sonderzeichen erlaubt, das dokumentierte Passwort aber solche enthält, weiß man nicht, was denn nun als Shared Secret auf den neuen Tunnel konfiguriert gehört. Schade, Schade, Schade, und es ist Zeit für ein Telefonat mit der Gegenseite, die hoffentlich (a) gerade erreichbar und (b) kooperativ genug ist, um “on the fly” ein neues Shared Secret zu vereinbaren. Normalerweise ist so eine Situation ein akuter Showstopper, da man ja gerade migriert und es vermutlich gerade mitten in der Nacht ist.

In den allermeisten Fällen sind alle VPN-Tunnel auf einer einzigen IP-Adresse des eigenen Systems terminiert, was sofort bedeutet, dass alle auf dem Gerät terminierten VPN-Tunnel gleichzeitig umziehen müssen. Man hat es also im übelsten Fall mit zehn verschiedenen Gegenstellen zu tun, die alle verschiedene Arbeitszeiten haben, bei denen die Hälfte der Ansprechpartner mit Sachkenntnis im Projekt, Urlaub oder in Elternzeit sind und wo jede einzelne Gegenstelle für den Kunden überlebenswichtig ist.

Oft ist es empfehlenswert, das neue System parallel zum alten aufzubauen und jeden einzelnen Tunnel - mit Hilfe der Gegenstelle und unter Veränderung der eigenen Gateway-Adresse - einzeln auf das neue System umzuziehen. Das ist sicherlich die Lösung, die für jede Anwendung die kürzeste Einzeldowntime hat; dafür ist es oft aufwändig zu organisieren. Bei hinreichend hirnrissiger Architektur beim Kunden sind die Funktionen jedoch so miteinander verwoben, dass man nicht auf eine andere IP-Adresse ausweichen kann, oder politische Entscheidungen (“dem Tunnel hat die Gegenstelle erst nach dem zehnten Ouzo zugestimmt, den hat er bestimmt vergessen, wir wollen nicht dass er sich daran erinnert”) zwingen zu einem anderen Vorgehen.

Dann sollte man alle Tunnel auf dem neuen Gerät möglichst so einrichten, dass sie mit dem alten Equipment ebenfalls funktionieren, damit man die Möglichkeit hat, auf die alte Umgebung zurückzuwechseln, wenn der Tunnel, um den man sich gerade kümmert, beispielsweise ohne Kommunikation mit der Gegenstelle mit dem neuen Gerät partout nicht funktionieren mag. Wenn tatsächlich eine Änderung an der Konfiguration der Gegenseite notwendig ist, sollte auch der geänderte Tunnel mit dem alten Gerät noch funktionieren - denn im Zweifel zwingt einen ein anderer Tunnel wieder auf die alte Umgebung zurück, und den Kunden vor die Wahl “entweder Berlin oder Leipzig, aber derzeit nicht beide gleichzeitig” stellen zu müssen, beschert totsicheren Ärger.

Im allgemeinen zwingen einen Kombigeräte hier zu abenteuerlichsten Vorgehensweisen, weil der Wechsel “zurück” bei einer mit einem VPN-Gateway kombinierten Firewall üblicherweise ein erheblich tieferer Eingriff in die Infrastruktur ist als das “interface foo; shut; interface bar; no shut” auf dem Switch, an dem die beiden reinen VPN-Geräte angeschlossen sind. Dies ist übrigens einer der Gründe, warum ich meinen Kunden immer empfehle, Firewall und VPN voneinander zu trennen: Das ist im Wirkbetrieb und in Migrationen einfach viel besser zu debuggen und besser zu handhaben.

zkmlf: Was muss danach funktionieren?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 02 Jan 2010 12:00:00 +0100

Teil des Projektplans sollte eine Liste der Dienste sein, deren Funktionsfähigkeit während der Migration möglichst schnell wieder herzustellen ist. Dabei sollte man darauf achten, dass man für die notwendigen Tests nicht auf die Mitarbeit anderer angewiesen ist, sprich: Es sollte eine Testprozedur vorab definiert sein, nach deren erfolgreichem Ablaufen der Dienst als “verfügbar” klassifiziert ist. Wenn hierfür Zugangsdaten notwendig sind, muss der Kunde diese zur Verfügung stellen. Ein Testaccount reicht natürlich, aber dann muss es dem Kunden auch reichen, wenn nur mit dem Testaccount getestet wird.

Ganz wichtig: Die Testprozeduren muss man unbedingt vor dem Beginn der eigentlichen Migration einmal selbst ausgeführt haben. Nur so ist sichergestellt, dass man die Prozedur verstanden hat, und dass der Dienst vorher überhaupt funktionstüchtig war. Wenn man diese Prüfung unterlässt, kann es sein, dass man nach der Migration stundenlang herumdebugged und dann zu dem Schluß kommt, dass der Dienst schon seit Tagen kaputt ist, es nur keinen interessiert hat, man mit der Debuggingaktion nur sein eigenes Projekt verzögert hat und man selbst das Ding gar nicht reparieren kann weil man schlicht nicht schuld daran ist dass es nicht funktioniert.

zkmlf: Kommunikation mit dem Kunden

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 31 Dec 2009 12:00:00 +0100

Kommunikation verhindert Mißverständnisse. Das ist in komplexen Systemen wichtig, und zwar insbesondere in einem Migrationsprojekt, wo man den aktuellen Betriebszustand zu Beginn der eigentlichen Migration, der so G*tt will “System funktioniert” heißt, erstmal massiv verschlechtern muss, denn ganz ohne Downtime geht eine Migration in aller Regel nur mit massivstem Materialaufwand.

Deswegen kommt es bei einem Migrationsprojekt darauf an, dass man glasklar mit dem Kunden bespricht, wie die Migration ablaufen wird, wie der Zeitplan ist, und zu welchen Zeitpunkten mit welchen Teilfunktionalitäten des Systems (nicht) gerechnet werden kann. Wenn der Kunde von einem anderen Ablauf der Migration ausgeht als man selbst, gibt das Ärger, und zwar nicht selten mitten in der Migration.

Stellt man den Zeitplan in einem Meeting vor, ist es trotzdem essenziell, ihn dem Kunden nachvollziehbar zu übergeben, zum Beispiel im Rahmen eines Besprechungsprotokolls oder einer online erreichbaren Projektwebseite. Denn so kann man dem Kunden im Zweifel jederzeit nachweisen, was man vorab angekündigt hatte. Das verhilft manchen Hitzköpfen auch dann zur schnellen Abkühlung, wenn man als Dienstleister den Zeitplan wirklich verletzt hat: Denn in den seltensten Fällen sind die Erwartungen des Kunden deckungsgleich mit dem, was ursprünglich angekündigt war.

Teilt dem Kunden ausdrücklich mit, wenn Eure Planung einen Zeitraum enthält, bei dem nur Teile der Funktionalitäten beim Endbenutzer ankommen. Achtet auch darauf, dass diese Information auch beim Endbenutzer ankommt. Oft sind solche Bauzustände anstrebenswert, sinnvoll oder gar unvermeidbar, aber nicht informierte Benutzer tendieren dazu, Euch dann mit Aussagen wie “Internet geht, aber ich komm noch nicht ans CRM” zu belästigen, obwohl das Migrationsprojekt genau dort ist, wo es zum aktuellen Zeitpunkt sein sollte.

Lasst Euch die Benachrichtigungen zeigen, die der Kunde an seine Benutzer verschicken wird, denn dort steht im allgemeinen das drin, was er von Euch erwarten wird. Wenn Ihr dem Kunden gesagt habt, “wir klemmen das alte System um 19.00 Uhr ab und sind dann - wenn alles gut läuft - um 20.00 Uhr mit den Grundfunktionalitäten wieder online”, sollte der nicht an seine Benutzer kommunizieren “Ab 20.00 Uhr sind wir wieder in Betrieb”, denn im Zweifel läuft irgendwas triviales schief, oder der wichtige Benutzer möchte ab 20.05 Uhr eine Funktionalität nutzen, die im um 20.00 Uhr erreichten Bauzustand noch nicht wieder zur Verfügung steht.

zkmlf: Sammelt Informationen ein wo Ihr sie kriegen könnt

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 30 Dec 2009 12:00:00 +0100

Bei einer Migration ist es immer wichtig zu wissen, womit man es zu tun hat. Dazu gehört insbesondere die Sammlung von Informationen, die man braucht, um das neue System erfolgreich an den Start zu bekommen.

Dazu gehören insbesondere ein kompletter aktueller Netzplan, der auch mit IP-Adressen beschriftet sein sollte. Auf diese Weise bekommt man einfach raus, was für Überraschungen im Projekt noch lauern. Vielleicht ist da ein fast vergessenes, weil seit fünf Jahren problemlos funktionierender VPN-Link zu einem anderen Unternehmen, der bedauerlicherweise für das wirtschaftliche Überleben des Kunden total essenziell ist, oder ein mit einer RFC1918-Adresse und einer bis dato unbekannten Webadresse versehener Webserver zeigt einem, dass man es entgegen der Behauptungen des Kunden doch mit Destination NAT oder gar Proxy ARP zu tun haben wird.

Wenn man’s ganz gründlich haben will, macht man Stichproben, um zu gucken, ob der Plan auch wirklich aktuell ist.

zkmlf: Architekturanpassungen vorschlagen, Altlasten von morgen verhindern

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 29 Dec 2009 12:00:00 +0100

Oft stolpert man bei der Vorbereitung einer Migration auf Altlasten, deren Implementierung im neuen System zwar möglich ist, man das aber aus verschiedenen Gründen nicht möchte. Manche Kunden sind dazu bereit, im Rahmen des laufenden Projekts auch an anderen Stellen Anpassungen vorzunehmen, die ihnen in Zukunft das Leben erleichtern. Man sollte sich nicht scheuen, solche Maßnahmen vorzuschlagen - etwas Blick über den Tellerrand hat noch keinem geschadet.

So hatte ein von mir besonders gehasstes Firewallprodukt die Möglichkeit, durch einfache und für wenig erfahrene Leute verständliche Konfiguration Zugriffe auf gewisse Ports einer IP-Adresse aus dem äußeren Transfernetz durch eine ekelhafte Kombination aus Proxy-ARP und Destination NAT auf einen “innen” liegenden Server weiterzuleiten. Da dieses Feature so schön einfach zu nutzen ist (man muss nicht beim ISP um ein weiteres Netz offizieller IP-Adressen für “innen” liegende Server betteln und ihn nicht um statische Routen bitten), wurde das natürlich auch fleißig benutzt. Auf “richtigen” Firewalls muss man sich für die Nachbildung mit virtuellen IP-Adressen oder Alias-Adressen einen abbrechen und den ganzen Mist auch noch dokumentieren. Dabei wäre es doch viel einfacher, es gleich “richtig” zu machen, dem Zielserver eine offizielle IP-Adresse aus einem neuen Servicenetz zu verpassen und den Traffic einfach nach passender Filterung weiterzurouten.

Auch immer wieder gern genommen ist die Classful-Denke vieler historisch ausgebildeter Leute, für die es keine Prefixlängen zwischen /16 und /24 gibt und die für ihr 300-Client-Netz deswegen ein “flaches” /16-Netz, gerne das komplette 192.168/16 oder Standardprefixe wie 10.0/16. Wenn man dann aufgekauft wird oder aus anderen Gründen das eigene Netz mit einem Gegner verheiraten muss, der denselben Designfehler gemacht hat, darf entweder einer der beiden renumbern oder man muss sich auf beiden Seiten mit NAT einen abbrechen. Letzteres geht üblicherweise damit einher, dass man aus Gründen der “Einfachheit” nicht mit DNS arbeitet, sondern direkt IP-Adressen der Gegenseite überall einträgt, was dazu führt, dass bei weiteren Umstellungsarbeiten entweder noch mehr geNATtet wird oder man sich schwer zu debuggende Fehler oder noch aufwändigere Migration einfängt. Daraus entsteht meine Empfehlung, Netze immer noch so groß wie nötig, aber so klein wie möglich zu machen und den Prefix aus den zur Verfügung stehenden Adressräumen zusammenzuwürfeln, möglichst nicht systematisch. Denn auf Ideen wie “10.49.62/24 ist Deutschland, Rhein-Neckar”, sind vor uns auch noch andere gekommen.

Und dann gibt es natürlich auch die Designfehler, die man ohne Neuinstallation der gesamten Windows-Welt niemalsnie wieder los wird. Besonders gern genommen natürlich der “example.com” als AD-Root der Example GmbH, die extern genauso benutzt wird. Wenn man sich hier vertut, hat man “innen” andere Fehler als “außen”, merkt “innen” nicht, dass außen der RR für www.example.com oder gar der MX für example.com verschwunden ist, oder es steht mitten in der Migration das Marketing auf Deinem Fuß und brüllt Dich an, warum die Aktionswebseite nicht mehr aufgelöst werden kann. Ich bin übrigens kurz davor, einen Preis dafür auszuloben, dass mir jemand das Microsoft-Whitepaper beschafft, in dem der Example Ltd explizit davon abgeraten wird, für ihr AD den Root intern.example.com zu verwenden, wenn example.com “draußen” produktiv verwendet wird - denn das wäre eine Konfiguration, die aus meiner Sicht ausgesprochen sinnvoll wäre.

zkmlf: Vorbereitung des neuen Systems

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 28 Dec 2009 12:00:00 +0100

Oft hat man vor dem Einstieg in die heiße Migrationsphase die Gelegenheit, die neuen Systeme vorzubereiten und zumindest teilweise vorzukonfigurieren. Das sollte man natürlich besonders bei Produkten machen, deren Eigenheiten man noch nicht in- und auswendig kennt, denn außerhalb der heißen Phase hat man Zeit und Ruhe und kann auch mal manche Dinge ausprobieren, die einen vielleicht nur akademisch interessieren. So fasst man Vertrauen zum Produkt und solches Wissen kann man sicher auch irgendwann mal wieder gebrauchen.

Ich baue neue Systeme - so vertretbar möglich - immer erstmal in einer Laborumgebung (“einem Lab”) auf, das die Infrastruktur des Kunden möglichst 1:1 nachbildet.

Das schließt insbesondere ein, dass ich in dem Lab dieselben IP-Adressen verwende, wie sie auch beim Kunden in Benutzung sind, inklusive dessen öffentlicher Adressen. Das bedeutet natürlich, dass man höllisch aufpassen muss, dass die im Lab “widerrechtlich” verwendeten Adressen irgendwie nach draußen leaken, weil Wechselwirkungen mit den produktiven Systemen des Kunden nicht ausgeschlossen sind. Meist wird man das Lab also von “richtiger” Infrastruktur getrennt aufbauen und den mit hoher Wahrscheinlichkeit trotzdem benötigten Internetzugang über NAT realisieren, wie man es auch machen würde, wenn das Lab im Internet nicht geroutete site-local-Adressen verwenden würde. Und wenn man schonmal dabei ist, kann man auch gleich die Zugriffe aus dem eigenen Office so natten, dass sie beim Zielsystem so ankommen, als stünde dies schon an seinem endgültigen Einsatzort.

So ein Setup ist zwar eine ausgesuchte Sammlung aus verschiedenen Netzschweinereien, hat aber den Vorteil, dass man das System zur Migration 1:1 aus dem Lab in die Produktivumgebung versetzen kann, ohne sich Gedanken darüber machen zu müssen, ob IP-Adressen, Routen, Gateways und Accesslisten auch an der produktiven Position so stimmen, dass das System direkt funktioniert. Das hilft, die Downtime bei der Umstellung zu verkürzen und nimmt deutlich Stress aus der eigentlichen Migration.

Der Aufbau eines solchen Setups benötigt allerdings erheblich mehr Kenntnisse über IP und NAT, als beim durchschnittlichen Administrator eines Endkunden oder Techniker des Mitbewerbs zu finden ist. Ich empfehle diese Vorgehensweise trotzdem dringend, da sie erhebliche Vorteile mit sich bringt. Außerdem ist das ein Alleinstellungsmerkmal gegenüber dem allergrößten Teil der Marktbegleiter, die mangels Kenntnissen auf solche Ideen gar nicht erst kommen. Ich wäre ja schön blöd, wenn ich diesen Vorteil nicht nutzen würde.

zkmlf: Proper Preflight Planning Prevents Poor Performance

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 27 Dec 2009 12:00:00 +0100

Der Titel dieses Artikels ist ein alter Fliegerspruch, der in IT-Projekten natürlich auch seine Richtigkeit hat. Guckt Euch die Konfiguration der abzulösenden Systeme an, macht Euch Gedanken über den möglichen Weg vom aktuellen Zustand zum Zielzustand, definiert Euch Meilensteine und für den Kunden akzeptable Bauzustände, bei denen man im Falle eines Falles eine auch längere Pause einlegen oder ganz abbrechen kann. Auf den Originalzustand zurückrollen ist oft keine realistische Option oder macht bereits geleistete Arbeit zunichte. Nichtsdestotrotz sollte man sich diese Option als Manöver des letzten Augenblicks offen halten.

Informiert den Kunden über diese Planung und achtet darauf, dass er die Idee des Bauzustands versteht und nicht erwartet, dass in jedem Bauzustand jede Funktionalität unbedingt funktioniert, und dass er nicht meint, dass bloß weil Ping in die Welt und der Zugriff auf Sp**g*l Online wieder funktioniert, die Migration fertig abgeschlossen ist und alles was jetzt noch nicht funktioniert gleich eine Schlechtleistung des Dienstleisters darstellt.

Zugschlus' kleiner Migrationsleitfaden

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 26 Dec 2009 12:00:00 +0100

Migrationen von einem alten System auf ein neues System sind etwas, was ich besonders gut kann. Ich bekomme es immer wieder hin, mit ein wenig Planung vorab die Migration mit deutlich kürzerer Downtime hinzubekommen, als es bei der naiven Vorgehensweise wäre. Dabei habe ich wenig Angst, einen Bauzustand mit vielleicht nichtmal sechzigprozentiger Funktionalität online gehen zu lassen, wenn mich das bei der Durchführung der Restarbeiten nicht behindert - frei nach “lieber ein wenig Funktionalität als gar keine”.

Da mein “Lieblings”-Firewallhersteller seine Produkte Gott sei Dank Ende 2009 aus dem Support laufen lässt, habe ich in den letzten Monaten nicht nur ein Firewallmigrationsprojekt bei und mit Endkunden durchgeführt. Dabei ist natürilch das eine oder andere schiefgelaufen, und in der folgenden Artikelreihe “Zugschlus’ kleiner Migrationsleitfaden” versuche ich diese neuen oder nicht mehr ganz so neuen Erfahrungen so aufzuarbeiten, dass vielleicht auch Ihr etwas davon habt.

Entgegen der landläufigen Meinung ist eine Migration übrigens erheblich komplexer und schwieriger als die Inbetriebnahme eines ganz neuen Systems ohne Vorgänger. Bei einer Migration hat man einen Ausfall eines Dienstes, von dem vielleicht Teile der Kundenorganisation abhängen, man muss Daten übernehmen, und hat es plötzlich und akut mit Befindlichkeiten von Benutzern und kleinen Fürsten zu tun, denen Funktionalität kurzfristig (im Rahmen der Umbauarbeiten) oder langfristig (weil das neue System vielleicht manche Dinge nicht mehr kann) verloren geht. Ein Projektstopp bedeutet bei einer Migration in aller Regel weitere Arbeiten, um auf den Ursprungszustand zurückzukommen, während man bei einer Neueinführung einfach alles stehen lassen kann.

Die Artikel sind mit “zkmlf” getagged und können jederzeit gesammelt aufgerufen werden. Es gibt auch einen RSS feed.

zkmlf: Widrigkeiten im RZ

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 06 Jan 2009 12:00:00 +0100

Ein neues Gerät wird irgendwo eingebaut. Und bei diesem Einbau kann so einiges schiefgehen. Gegen die meisten dieser Failures kann man sich vorher absichern, wenn man wenigstens kurz davon gesprochen hat. Dieser Artikel scheint Euch vermutilch wie eine Ansammlung trivialer Klarheiten, aber in der Praxis wartet man öfter mal stundenlang auf eine einzelne Schraube.

Einige der Fragen, die man sich hierbei stellen sollte, sind:

Gibt es Platz im Rack?
Passt das neue Gerät auch von der Tiefe her in den Schrank? Sind Schienen notwendig, und sind sie da?
Brauchen wir andere Schrauben?
Ist das neue Gerät genauso groß wie das alte Gerät?
Kann man beide Geräte gleichzeitig eingebaut haben?
Gibt es Strom für das neue Gerät? Sind Kabel in passender Länge mit den passenden Steckern griffbereit?
Sind die Netzwerk- und sonstigen Kabel lang genug? Passen sie?
Haben wir Zugriff auf die Netzwerkinfrastruktur? Ist jemand da, der damit umgehen kann und darf?

Ich bin ein großer Freund davon, sowohl das alte als auch das neue Gerät gleichzeitig eingebaut zu haben. Das braucht zwar Platz und zusätzliche Kabel, Switchports und Steckdosen, aber man gewinnt dabei Flexibilität. Wenn das alte Gerät weg ist, ist es mehr Aufwand, wieder zurückzuwechseln, man kann keine Teilaufgaben als temporären Workaround weiterhin von der alten Kiste erledigen lassen und hat auch eine längere Downtime für den eigentlichen Umbau, weil das alte Gerät weg sein muss, bevor man überhaupt beginnt, das neue Gerät physikalisch einzubauen.