 Willkommen zum Vortrag von Promaso. Promaso ist Mitglied des Hardinett. Das ist vom HardicoEV. Das Internetteam. Macht Netzwerk dort. Ich habe gehört, Studenten wollen WLAN haben. Manchmal. Und Promaso erzählt euch heute was über Migrationen und was man dabei so richtig und vielleicht auch falsch machen kann. Viel Spaß. Genau, ich wollte euch ein bisschen was erzählen darüber, wie man Migration erfolgreich machen kann oder auch nicht erfolgreich machen kann. Ein bisschen mal so aus dem Nähkästchen plaudern. Wie und was man so, was so passiert, so im Alltag, wenn man als Admin, sei es im Beruf, sei es im Wohnheim, im Ehrenamt oder irgendwo anders, halt mal das Thema anfasst. Ich stelle mich kurz vor, definiere ein paar Begriffe, erzähle ein bisschen was möglicherweise bei so einer Migration passieren kann, die Gründe dafür, weswegen so was passiert, gebe ein paar Empfehlungen ab und am Ende noch so ein paar Lessons lört, so als kurze Zusammenfassung. Dann kurz zu mir. Ich bin Adrian oder auch Promasu. Admin für Netzwerknahedienste und Automatisierung im HDQV unter anderem. Mach sonst auch sehr viel ehrenamtliche IT jetzt irgendwie hier mit verantwortlich, dass das Netzwerk hier auf der Veranstaltung funktioniert hat. Bin beim Freifunk in Karlsruhe zum Beispiel noch aktiv und auch meine Finger mit im Spiel bei der IT vom Intro-PV. Der diese ganze Veranstaltung hier überhaupt möglich macht. Im Mächtenleben bin ich als Netzwerkkonseiten tätig, dementsprechend habe ich auch da regelmäßig damit zu tun, bei Kunden, Kundeninfrastrukturen zu migrieren oder zu erweitern. Damit wir alle auf dem gleichen Stand sind und ich habe explizit angekündigt, dass sie relativ einsteigerfreundlich ist, erst mal ein paar Begrifflichkeiten. Was verstehen wir unter einer Migration oder was verstehe ich unter einer Migration? Migration kommt aus dem Lateinischen und heißt so viel wie Wandern, Wegziehen, Wanderung. In der Sociologie kennen wir Migration ja als ein Wegziehen in ein anderes Land. Jetzt muss man wegen aus welchen Gründen auch immer. In der IT ist es in der Regel ein Umzug auf eine neue Umgebung. Umgebung heißt in dem Fall auf neue Hardware, auf neue Software, auf irgendwie ein neues Betriebssystem, wie auch immer. Was kann ich denn so alles migrieren? Prinzipiell, ich kann Software zum Beispiel zwischen Servern migrieren. Ich habe einen alten Server, ich habe einen neuen Server und möchte, dass meine alte Software von dem einen Server auf den neuen Server kommt, aus welchen Gründen auch immer. Ich kann Daten zwischen Festplatten hin und her migrieren, weil die eine Festplatte zu klein ist oder zu wenig Leistung hat und ich deswegen schauen muss, dass die Daten irgendwie woanders hinkommen. Ich kann Netzwerk auf neuen Hersteller migrieren. Zum Beispiel bei uns im Wohnheim passiert. Sowohl mit dem WLAN als auch mit dem LAN da vor Ort. Dazu habe ich letztes Jahr hier auf der GPN auch einen Talk gehalten. Man kann auch das Betriebssystem ändern. Keine Ahnung, man ist aus irgendwelchen Obstkorengründen auf einem Centres oder auf einem Rattat derivat und sagt okay, das Debian 12, was jetzt gestern rausgekommen ist, ist voll geil, lass mal alles dahin ziehen. Aber Updates und Upgrades. Updates und Upgrades fasse ich explizit nicht unter dem Begriff einer Migration. So ein Update hat eine sehr begrenzte Komplexität in der Regel und hat einen überschaubaren Aufwand. Das funktioniert eigentlich immer gleich. Die Räger haben Hersteller sinnvoll dokumentiert, was man wie machen muss, was wie tief gehen kann, was man ändern muss. Man kann sie vorher testen, sinnvoll mit vergleichbar geringem Aufwand. Sie haben sowieso einen gemeinen geringen Umfang und sind gegenüber einer Migration eigentlich besser planbar und haben, wenn alles klappt, weniger User Impact. Einfach dadurch, dass sie weniger komplex sind. Was kann bei so einer Migration eigentlich alles schief laufen? Zum Beispiel sind die Kollegen sauer. Die Kunden sind sauer, die IT selber ist sauer, hat keinen Bock mehr. Also die Server oder die Netzwerkart wäre oder es passiert halt nichts. Kann auch vorkommen. Kollegen sind sauer. Beispielsweise, ihr habt ein Monitoring von eurer Infrastruktur. Ein Monitoring ist dazu da, um unvorhergesehene und nicht geplante Veränderungen an einem System zu überwachen. Deswegen bieten Monitoring Systeme in der Regel eine Funktion, um eine Wartung quasi einzutragen und zu sagen, okay, wir verändern jetzt was an dem System. Das sorgt dafür, dass dieses System sich anders verhält als sonst. Das ist gewollt, dementsprechend würde man in der Regel annehmen, wenn man eine Migration macht. Man trägt das in das Monitoring ein, sagt, hey, für dieses System gibt es für den geplanten Zeitraum der Migration keine Alarme, weil wir machen hier eine Migration, hier link zur Doku zur Migration, und dann wird zum Beispiel nicht die Bereitschaft aufgeweckt, weil man hat, oder man macht eine Migration, die Bereitschaft schläft, aber irgendwie ein Server, der geplant ausgehen sollte, wird alarmiert als Server ist aus, ist schlimm, hoher Impact, Bereitschaft wird aufgeweckt, rausgeklingelt, Bereitschaft guckt drauf. Ja, danke schön, lieber Kollege. Das war geplant, das war angekündigt, hättest du halt mal eingetragen, dass das System jetzt tatsächlich wirklich nicht laufen soll. Passiert einem Bekannten regelmäßig, dass dem seine Kollegen eben nichts Sachen eintragen und dann irgendwie hunderttausende E-Mails für sehr viele Festplatten oder sowas in einem System, in einem Server halt geschickt werden, nur weil eine Migration gemacht wird, die geplant war, aber halt nicht eingetragen, Monitoring-System. Oder auch Kollegen stören die Migration. Wir alle, wenn wir irgendwie mit Systemen arbeiten, kennen nach einer Zeit unser System und wissen, okay, das und das, oder wenn das und das Schief läuft, Monitoring zum Beispiel, das und das sagt, dann muss ich das und das machen, damit es wieder funktioniert. Manche Sachen passieren regelmäßig, aus welchen Gründen auch immer oder können regelmäßig passieren, dann mache ich da irgendwas und probiere, dieses Problem zu beseitigen. Ist in dem Fall dann, ist in dem Fall dann doof, weil, naja, meine Kollegen sind gerade, oder mein Kollege ist gerade dabei, das Monitoring irgendwie in ein System zu migrieren und ich pfusch da mitten rein und sorg dafür, dass, naja, ich pfusch halt mitten rein und sorg dafür, dass der Kollege halt seine Arbeit nicht sauer machen kann und sabotieren quasi eigentlich. Ist auch unschön. Kunden sind sauer. Wieso ist der Dienst jetzt kaputt? Ich wollte doch unbedingt an diese Daten ran. Kommt dann drei Monate, nachdem man ein User, oder ein User eine Mail geschrieben hat, oder den User eine Mail geschrieben hat mit, wir schalten diesen Dienst zu dem und dem Datum ab. Ab da sind die Daten nicht mehr verfügbar. Ja, aber ich habe doch, ich brauche die Daten jetzt unbedingt. Ja, du hast da fünf Mails zu bekommen und du hast die definitiv dazu bekommen und du hattest eineinhalb Jahr Zeit, um deine Daten da wegzuziehen. Ja, aber mi, mi, mi. Oder auch eine sehr schöne Frage, wenn man gerade mal Internet umbaut, ist mein Internet schon wieder da, während das komplette Netzwerk-Team im Serverraum steht, zwei Minuten nach Ankündigung der Migration und gerade das Stromkabel vom Sitch gezogen wurde, ist auch immer schön. Ne, Lukas? Oder die schöne Frage, wann seid ihr denn fertig? Ja, wir haben einen Wartungsfenster angekündigt. Wir haben gesagt, wir fangen um 18 Uhr an, wir sind um 2 Uhr fertig, wenn alles gut läuft, wenn morgens um 6 Uhr noch nicht wieder alles so funktioniert, wie ihr erwartet, dann sagt halt mal Bescheid, ihr kriegt im Zweifel über Dollar-Website eine Info darüber, wie unser aktueller Status ist. Oder auch immer sehr beliebt, geht das nicht mal ein wenig schneller, weil ich möchte jetzt meine Videos gucken oder sowas. Ja, Migration dauern halt, so lange wie sie dauern und sich zu stressen bringt da nicht viel als die Person, die jetzt diese Migration ausführt. IT ist sauer, passiert auch ab und an mal, hat dann einfach keine Lust mehr, keine Ahnung, man hat einen Vm-Cluster und sagt den Admins, hey, wir müssen jetzt alle unsere Server da rüber migrieren, weil so langsam am Ende der Lebenszeit, ja, die Migration läuft in Anführungszeichen, die Admins kümmern sich halt nicht und irgendwann sagt dann der Vm-Server, gut, ich habe jetzt meine 12 Jahre auf dem Buckel, ich will nicht mehr, tschüss, viel Spaß beim Wiederherstellen aus den Backups. Passiert auch mal. Oder allgemein Dienste gehen kaputt, weil, wieso auch immer, ja auf dem alten Server hat es ja noch funktioniert und man hat nicht ordentlich vorbereitet, sorgt dafür, dass, naja, man macht irgendwas, man zieht einen Dienst von A nach B, sagt ja, eigentlich ist ja alles gleich, scheinbar ja doch nicht. Oder Datenverlust, weil, wir kennen das, wenn wir irgendwie, keine Ahnung, bei einem Linux-System, wir haben umgebungsvariablen lokal im Applikationsverzeichens abgelegt und der Dateiname hat einen Punkt am Anfang. CP-Sternchen, das inkludiert alle Dateien, die sichtbar sind, also alle Dateien, die keinen Punkt am Anfang haben. Dann fliegen auf einmal, es sind auf einmal Konfigurationsdateien weg und dann funktioniert auch krams nicht, gegebenenfalls sorgt das halt dafür, dass, naja, Daten verloren gehen, zumindest auf dem migrierten System. Oder spontane Abhängigkeiten, weil, naja, man migriert irgendwas, vertraut darauf, dass wenn man den Service jetzt neu installiert, dass die Upstream-Server da sind, dann hat irgendwie der eine, der eine Dienst, da sind die GPG-Kis ausgelaufen vom Repository, ich kann die Daten nicht sinnvoll, ich kann die Systeme nicht sinnvoll neu installieren, dann fehlt irgendwie vom Packet-Manager, vom Note, ist irgendwie mal wieder einen Paket kaputt oder so, auch Mist. Und natürlich, was, da kann auch nichts passieren. Okay, komisch. Aber kommt auch ab und an mal vor. Was sind denn jetzt zum Beispiel Gründe dafür? Da hast du mich erinnert, egal. Was sind denn jetzt zum Beispiel Gründe dafür? Gründe sind zum Beispiel mangende Kommunikation. Wir Menschen neigen dazu, prinzipiell immer und immer wieder viel zu wenig zu kommunizieren, viel zu wenig miteinander zu reden und sorgt letztendlich dafür, dass irgendwie Unmut auf irgendeiner Seite herrscht, weil man sich nicht informiert fühlt oder so. Ungenügend Vorbereitung. Ich habe im Vorfeld nicht genau getestet und sage, ja, das passt schon, wir schütteln das jetzt so aus dem Ärmel, alles gut, geht ja ganz fix oder so. Und dann geht es halt kaputt und funktioniert nicht so, wie es funktionieren soll. Manche in der Dokumentation. Auch so ein schönes Ding. Ich gebe fest der Meinung, dass auf diesem System irgendetwas auf eine bestimmte Art und Weise ist, weil das müsste sich ja so verhalten, weil das ist aus so einem Grund, ist das so. Und man vergisst dann trotzdem irgendetwas, weil irgendjemand was gemacht hat, geändert hat und das nicht aufgeschrieben wurde oder so. Und auch ein ganz wichtiger Punkt ist Selbstüberschätzung. Wir sind alle nicht unfehlbar und sorg der letzten Endes dafür, dass wir teilweise dazu neigen und selber zu überschätzen und sagen, ach, das geht schon, das kriege ich schon hin, alles gut, braucht keine Hilfe, voll okay. Gut. Kommunikation. Was kann ich da? Sekunde. Genau, Empfehlungen dazu. Kommunikation. Das kann ich an der Kommunikation verbessern. Kollegen lieber doppelt und dreifach informieren, zu sagen, hey, wir migrieren da in zwei bis drei Wochen oder wir migrieren da zwei Wochen, schreib's zwei Wochen vorher oder schreib's sechs Wochen vorher oder so ne Mail. Hey, wir migrieren da an dem und dem Datum, den und den Server, ab da und da wird diese Änderung aktiv und ab da und da fahren wir den alten Server herunter. Das liest man oder nimmt man dann vor zwei Monaten dann zur Kenntnis, wenn diese Mail einmal kommt. Vergiss das wieder, sagt ja, man kümmert sich da später drum, da denkt man nicht mehr dran, dann wird migriert und hinterher ist das Geschrei groß, ah, ich hab davon aber keine Info gehabt, ich wurde nicht informiert. Mi, mi, mi, ich brauche jetzt meine Daten wieder. Oder sowas. Im Monitoring-Wartung eintragen, auch total gut, total sinnvoll, weil gegebenenfalls ernauen uns das Monitoring sogar mit Nachricht Hey, maintenance start mit dem und dem Grund und die Kollegen kriegen eine Mail aus dem Monitoring, keine Hunderttausend und dem Monitoring steht drin, hey, das und das wird an dem und dem System gerade gemacht. Dem Kunden, realistische Zeiten mit Puffer, realistische Zeiten mit Puffer mitteilen. Wenn wir sagen, ja okay, das habe ich schon tausendmal gemacht, hier eigentlich sollte, eigentlich sollte das, ich baue jetzt einen Switch neu ein und da hängen irgendwie fünf Geräte dran, eigentlich sollte das ja gar kein Problem sein. Passiert ab und an mal auf Arbeit oder so, dass man halt bei einem Kunden vor Ort ist, man kennt die Infrastruktur nicht und sagt, ja, das sind fünf Ports auf dem Switch, passt schon, alles gut, ich reiß den alten Switch raus, neuen Switch rein, die Benutzer werden informiert, maximal alles gut. Dann fehlt hier aber eine Leiter, weil das Rack in drei Metern Höhe hängt. Eigentlich solltest du da nicht hochgehen, weil du diese Leiter nicht sind, vorher sicher hinstellen kannst, dann lässt du es den Kunden selber machen. Dann sind die noch die Netzerkabel kaputt und aus so einer halben Stunde wurde dann mehr so eine Stunde, anderthalb oder sowas. Ist jetzt ein doofes Beispiel, also da stelle lieber halt sagen, wir blasen das an der Stelle ab, wir kriegen das in der Zeit nicht hin. Rollback, auch ohne, dass man irgendetwas bisher je gemacht hat, aber halt sagen, okay, Migration war scheiße geplant, ist doof, wäre die sinnvolle Option, aber halt auch zu sagen, hey, wenn alles gut läuft, brauchen wir eine Viertelstunde für, wir planen mal so eine halbe Stunde ein und sagen, könnte auch 45 Minuten dauern, sehr viel besser. Und während der Migration Updates posten, wenn man dazu in der Lage ist, das zu tun, dann ist es cool, wenn man halt irgendwie kommuniziert mit, wir haben diese To-do-Liste und wir arbeiten die von oben nach unten irgendwie ab und man hakt dann quasi irgendwie, entweder man hakt in der To-do-Liste die Punkte ab, die man vorhat oder man schreibt Update, der und der Zeitpunkt, das und das funktioniert jetzt wieder oder das und das ist fertig, Mikrit. So als Beispiel, wir tauschen im Verteiler-Strang ein paar Kabel, die Wartung dauert 12 Stunden, Norddeutscher Internetanbieter. Das ist halt so ein Ding, wo man sich dann als Kunde irgendwie hart verarscht vorkommt, wenn man so eine Wartungsankündigung bekommt. Man hat beispielsweise, in dem Fall hat der Bekannte SLRs auf dieser Leitung und der Dienstleister geht halt hin und sagt, jop, wir nehmen hier 12 Stunden lang diese Internetleitung offline, weil wir ein paar Kabel tauschen. Als IT-Lasso ja, wieso braucht ihr 12 Stunden lang, um ein paar Kabel zu tauschen? Wenn ich an den Petschrang gehe, Kabel raus, Kabel rein fettig, ist eine halbe Stunde gemacht maximal, wieso dann 12 Stunden? Ist halt einfach scheiße kommuniziert in dem Fall. Zum Thema Vorbereitung und Dokumentation. Vorher wissen, was alles installiert ist. Ist immer ganz sinnvoll, mal sich einen Überblick zu verschaffen. Was ist da überhaupt alles drauf? Keine Ahnung, ich migriere einen Service von dem einen Server auf einem anderen Server oder ich führe mehrere Services zusammen, ziehe die rüber und irgendjemand dachte, es wäre eine gute Idee, dass noch irgendwie einen Service, der eigentlich mit dem Server gar nichts zu tun hat, noch damit draufkommt, weil der Wahrheit ja gerade da haut. Sogt er dafür, dass gegebenenfalls man irgendwie den alten Server runterfährt und plötzlich ist Krams weg oder nicht mehr verfügbar, was man eigentlich gedacht hätte, was verfügbar wäre. Da ist dann wieder auch, wenn ich mal Monitoring sinnvoll pflege und im Monitoring ordentlich meine Systeme anharke mit, das und das wird nicht mehr verfügbar, eine Nachricht im Monitoring so, hey, das und das ist da gerade gestorben, eventuell mal danach gucken. Infrastructure is Code ist auch eine sehr, sehr sinnvolle Dokumentation, insbesondere bei Servern und insbesondere kann man da nachvollziehen, wenn man irgendwie was geändert hat oder was gegebenenfalls geändert werden muss und man kann mit vergleichbar geringem Aufwand vorher so eine Migration testen. Wenn ich sage, okay, ich teste meine Migration vorher, das heißt, ich installiere einmal alles so, wie es im Sol-Zustand sein soll, ziehe die alten Daten runter, ziehe die Daten rüber, installiere die dann da oder füge die da dann wieder ein und schau, ob alles funktioniert, dann kann ich meine Migration testen, weiß, worauf es ankommt, was schieflaufen kann, schreibt mir das gegebenenfalls auch noch auf und kann zum Beispiel vom neuen wieder anfangen nochmal neu, nochmal testen, ah, jetzt funktioniert das viel besser, ich werde schneller, ich mache weniger Fehler und ich finde die Fallstricke. Da dann als Beispiel, man kann Enzy-Bilder für benutzen, andere Leute benutzen Puppet dafür, Grüße an der Stelle an Johanna, man kann auch Bundlewrap benutzen. Genau. Migration vorher sinnvoll planen. Vorher sich zu überlegen, was man wie in welcher Reihenfolge macht gemein sehr sinnvoll. Häufiger ist es so, ja, ich migrele in Service halt da dann rüber und ich gucke dann mal sorgt halt dafür, dass man Fehler macht, Sachen vergisst, vorher sich ein Runbook oder sowas aufschreiben, hingehen, ich mach zuerst das, dann das, dann das, gegebenenfalls sogar die Punkte mit aufnehmen. Ich kommuniziere das an meine Kollegen, ich mach das Monitoring aus und so weiter sofort und ich schreibe irgendwie fein granular auf in welcher Reihenfolge, welche Schritte oder so mache und hab dann diese Liste, die ich zum einen während der Testphase zum Beispiel irgendwie dann durchgehe und überprüfen kann, validieren kann, dass das funktioniert und ich kann während der Migration auch hingehen und dieses Runbook eben abarbeiten, abhaken, hab einen Übersicht da auch über, was ich schon gemacht habe, was ich schon machen muss, gegebenenfalls nehme ich da dann sogar Punkte auf, die mir erlauben zu validieren, dass meine Migration on track ist und sinnvoll funktioniert, dass ich gegebenenfalls sagen kann, okay, ich erkläre diese Migration jetzt für gescheitert, ich mach einen Rollback, mache meine Änderungen auf dem ehemaligen Produktivsystem, soweit rückgängig, dass das wieder live gehen kann und sorgt dafür, dass meine Migration nicht ewig lange dauert, ich frustriert bin und irgendwie alle anderen auch frustriert sind, weil sie eigentlich damit rechnen, dass meine Wartungsantikönigung zum Beispiel stimmt, passzeitlich gut abgeschätzt ist und dann dauert's doch 2 Stunden länger und irgendwie geplante Meetings oder so können die stattfinden, weil man halt länger braucht. Auch als kleinere Anekdote dazu, zum Beispiel das Thema Dokumentation 0.54 Monitoring has quit Connection closed, IAC eines Studentenwohnheims ja, das war eine Migration von dem Monitoring-System und man hat halt vergessen den IAC-Bot der auf diesem System lief mit umzuziehen, dachte ich so okay, wir haben da vorher zwei Monitoring-Büchsen gehabt, die sind jetzt alle wegmigriert, wunderbar, alles gut, machen wir die einfach mal aus, passt schon, zack Monitoring-Pfad halt tot war da ein bisschen ungut, aber ist aufgefallen, ich meine, da hat man ja Monitoring oder so ähnlich, ist aufgefallen so wie wir anmachen, ging dann wieder alles gut Selbstüberschätzung es kann immer was schief laufen wir sind alles Menschen, wir machen alle Fehler ist voll in Ordnung es kann irgendwas schief gehen man kann nicht an alles denken und insbesondere kann man auch nicht alles auf einmal machen, ich kann hingehen und sage, ich habe hier ein super, super komplexes System, ich zieh einfach mal alles auf einen Schlag rüber keine Ahnung, ich hab da Mailing-Listen drauf, ich hab Mailing-Server ich hab da Mailing-Listen drauf, ich hab einen alten Mailing-Server einen Mailing-Server fürs Empfang, einen zum senden, in dem Fall ExSim und Dovgot und migriere das gleichzeitig auch noch auf eine andere Software rüber und dann update ich währenddessen noch Mailing-Listen-Software und Allgemein-Software und plane noch irgendwie das Webmail noch abzudaten und aus zwei Webmail-Systemen zusammenzuführen und ihr merkt, das ist eine ewig lange Liste und ewig komplex sollte man nicht so machen sondern Schritt für Schritt schauen was kann ich irgendwie rausdrehen, was kann ich auf einmal, oder was muss ich auf einmal machen was kann ich was kann ich nacheinander machen und dann geht man dann halt nicht hin und ist irgendwie 29 Stunden lang beschäftig so ein dämlichen Mailserver zu migrieren bis alles wieder ordentlich läuft Schlafmange sorgt für Fehler Ja, man möchte die Migration irgendwie fertig bekommen wenn man da gerade mitten drin ist voll verständlich aber wenn man halt irgendwie schon 17 Stunden lang zu gange ist wird das dann langsam schwer die Augen aufzuhalten Kommandsrichtige einzutippen an alles zu denken so lange Migration zu planen oder halt aus unvermögener sinnvollen Planungen so lange zu brauchen für so eine Migration ist halt dann lieber mit einem Team arbeiten wenn man sich so was hat was man so groß machen muss aus welchen Gründen auch immer dann lieber mit mehreren irgendwie daran arbeiten schauen okay ich mich hier jetzt irgendwie X Y und gebe dann den Part an den anderen Kollegen ab oder sowas im Endeffekt ist das besser für alle ich mach mich nicht kaputt und ich komm auch auf genügend Schlaf und bin konzentriert bei der Arbeit und natürlich der Punkt ist Robert Beck ist eine valide Option in der Regel ich kann wenn ich meine Migration sinnvoll plane sinnvoll mache dafür sorgen dass ich wieder auf den alten Stand zurückkomme und eben nichts kaputt geht wenn ich merke okay wir haben da Sachen nicht bedacht und Sachen beim Labor beim Testen sind immer anders als unter Produktivlast man kann das nicht sinnvoll machen beziehungsweise wenn man das machen möchte wir haben sehr viele Ressourcen dementsprechend die Realität ist immer anders als wenn man testet und wenn ich merke okay die Realität ist so viel anders im Gegensatz zu dem wie ich es geplant habe dann aufhören, merken oder aufschreiben was ist anders, was muss ich bedenken Robert Beck auf die alte Infrastruktur zurück, dann funktioniert alles und nacharbeiten, gucken was kann ich besser machen und einen neuen Versuch starten genau ich finde wir sollten einfach schneller fertig werden nach über 12 Stunden Arbeit an einer Migration er kam von einem Mesawardman diese Migration habe ich ja gerade schon erläutert diese Migration lief insgesamt 29 Stunden lang zu zweit zwischendrin war mal 2 Stunden schlafmeinig war nicht ganz so geil war nicht ganz so geil und im Nachgang musste man sehr viel nacharbeiten einfach aufgrund der Fehler die dann irgendwie passiert sind lessons learned als letzter Punkt es ist sehr sinnvoll die Systeme zu kennen mit dem man arbeitet dass man eben nichts falsch macht entweder sei es durch Dokumentation irgendwie Dokumentation in Form von einem wiki von einem konflikten oder ähnlichem in Form von Infrastructure as Code was mir mein System beschreibt was ich da habe kennt ihr deine Kollegen wenn ich jetzt natürlich Leute habe denen es absolut egal ist wenn irgendwie das Monitoring rumspampt uns 400 Nachrichten durch die Gegend schießt oder 800 oder so weil man gerade den WLAN Controller irgendwie von einem Ort zum anderen migriert und deswegen das WLAN kurz ausgeht beziehungsweise für das Monitoring die WLAN APs nicht sichtbar sind man sollte trotzdem eine Downtime eintragen aber im Endeffekt wenn es niemand interessiert alles ordentlich vorbereiten natürlich im Endeffekt sich Gedanken dazu machen wie und was kann ich machen muss ich machen gegebenenfalls gibt es einen Tool was für mich meine Migration macht gegebenenfalls gibt es einen Tool was für mich meine Migration einfacher macht wenn ich meine Tools kenne meine Systeme kenne kann ich zum Beispiel sagen ok ich habe hier einen System was fürs kollaborative arbeiten da ist und dieses System schreibt für jede Änderung die ich mache quasi eine neue Datei auf den Server so PimalDom beziehungsweise wenn es Dateien updated dann sind diese Änderungen entsprechend sichtbar es geht nichts kaputt wenn ich unvollständige Daten auf einen anderen Server migriere da ist dann zum Beispiel AirSync ein super Tool weil ich kann hingehen und sagen ok ich habe hier meine alte Software ich installiere die neue Software auf dem neuen Server daneben schieb den Krams einmal per AirSync teste ok das funktioniert mit dem Snapshot kann da hingehen sagen AirSync büge das alles rüber was ich gendert hat bis ich halt zu Beginn der Migration oder kurz vorall noch mal alles rüberziehe sag ok ich mache Datenservice aus ziehe das im DNS oder ähnlichen darüber und schiebe den Rest der Daten nach sorgt im Endeffekt dafür meine Kunden sehen von dieser Migration nichts also sehen tatsächlich gar nichts wenn man noch ein paar andere Sachen mit quasi mit einbaut oder so da kriegt man so eine Migration hin eben weil man seinen Tool sehr gut kennt und lassen User das mitbekommt hatte ich auch schon mal dann so ja ihr habt eine Migration angekündigt ich habe nicht mitbekommen dass da irgendwie was passiert ist macht ihr die denn noch muss ich denn damit rechnen wurde die verschoben wie ist das denn und zu dem Zeitpunkt war die Migration schon seit längerem durch wie auch immer gut gibt es Fragen ich glaube zu du rennst mit Mikrofon durch die Gegend wir warten auf die Technik das geht bestimmt gleich und sonst der Raum ist ja klein genug genau und wenns dein Ton gut dann improvisieren wir das der Raum ist ja klein genug ich wieder genau ich wiederhole die Fragen einfach sehr flexibel zweiter Punkt glücklich sei derjenige der eine zerstörungsfreie Migration durchführt points of no return scheiße habe ich für herr angst haben wir vor denen gehabt und wie viel ist an denen schon schiefgegangen ja ja also der erste Satz der erste Satz war sinngemäß wenn man sich die Mühe gemacht hat sich eine Runbook zu schreiben kann man sich daran halten weil wenn man irgendwie Abkürzungen in der Planung nimmt sorgt das nur dafür dass alles länger dauert Dankeschön ich wollte nochmal nachfragen das Einstichwort gehabt dass mir nichts gesagt hat und die Beispiele dazu auch nicht wollte ich fragen ob du noch zwei Worte dazu sagen kannst zu infrastructure as code infrastructure as code kann ich sehr gerne machen das war auf dieser Folie infrastructure as code ist ein Konzept dass du hingehst und quasi code schreibst der deine Infrastruktur beschreibt also du gehst hin und hast irgendwie eine Sprache eine Sprache die dir die irgendwie Aktionen beschreibt die passieren beispielsweise ich möchte ich habe eine Definition ich möchte in dieser Datei ich möchte diese und diese Software installiert haben und ich krieg daraus eine Definition von einem System mit auf diesen System sind diese User drauf auf diesen System sind diese Dateien drauf auf diesen System ist diese Software drauf jedenfalls irgendwie auch Dateienhalte Passworder und ähnliches und kann damit quasi unter der Voraussetzung dass alles in diesem Repository drin ist in dieser Definition eben drin ist kann unter der Voraussetzung halt hingehen und quasi den exaktes Replikat von meinem Dienst auf einem anderen Server installieren halt ohne die Daten soweit verständlich wunderbar noch weitere Fragen das ist das Ganze am Ende ganz kurz erwähnt aber was ich persönlich in meinen Erfahrungen auch mit mehreren Migrationen hatte ganz ganz wichtig Smoke Tests am Ende herausfinden funktioniert das wirklich alles so wie es sein soll und seid ja auch alle Use Cases bewusst ich hatte oft Migrationen gehabt wo dann einmal im Monat irgendein Job gelaufen ist und genau der natürlich dann auf der neuen Umgebung nicht gelaufen ist und das sind meistens Report Jobs die gerne die Management sehen will ja, ja das ist richtig man sollte seine Systeme kennen und eben auch wissen wie das da jetzt drauf läuft wofür das Thema benutzt werden und so und das ist halt genau der Punkt wenn besonders in der Firma immer doof wenn das Management hat seine Exitabellen oder seine wunderschönen Grafiken nicht bekommt du hattest auf einer Folie mit den zwölf Stunden und dem Partiler die Kommunikation du hast gesagt ja ist nicht so schön das sehe ich total ein würde mich auch irgendwie trägern welches lesen würde ich habe da mehr Erfahrungen wie ich wahrscheinlich was wäre denn aus der Sicht eine akzeptable Kommunikation gewesen die zwölf Stunden dauert und wie versuch das dem Nutzer klar zu machen dass es jetzt zwölf Stunden dauert ohne ihm mit technischen Labereien zu nerven und das auch in den fünfjährigen zu erklären dass es jetzt wirklich zwölf Stunden dauert und er jetzt da Geduld haben muss auch in das Informatiker Geduld hat also die Kommunikation ist wichtig, sehe ich ein aber wie würdest du seine Erfahrungen besser machen im Endeffekt in dem Ding sind versteckt halt zwei Kritikpunkte das eine ist das eine ist, dass wir tauschen im Verteilerschrank ein paar Kabel nicht pass zu dem wir brauchen da zwölf Stunden für so was andere ist dass das halt sehr runtergebrochen und sehr knapp ist im Endeffekt sei offen sei detailliert und sag ok wir haben hier wie auch immer wir migrieren hier irgendwie irgendwas und lass so ausdrücke wir ein paar Kabel weg geh lieber hin oder je nachdem kommt auf deine Kunden an wenn du jetzt nur Endkunden oder sowas hast wo dann die Telekom geht hin, hat ein Verteilerschrank und tauscht da dann irgendwie Sachen aus dann geh halt hin und sag ok wir sanieren den in Richtung Endkunden den interessieren so technische Details nicht ich geh hin und sag ok wir sanieren hier in dieser und dieser Straße unsere Verteilerschränke für schnelleres Internet dafür müssen alle Teile in diesem Schrank ausgetauscht werden und neu eingebaut und so das braucht halt zwölf Stunden in der Zeit ist kein Internet verfügbar oder sowas auf der anderen Seite größtenteils irgendwie oder war das halt Internet oder hat das eine Internetleitung betroffen die größtenteils nur wo Firmenkunden primär dran hängen beziehungsweise auch da du kannst deinen Firmenkunden anders kommunizieren als deinen Endkunden oder sowas in dem Fall dann halt einem Firmenkunden der halt Internetanbieter ist halt dieser Internetanbieter verkauft Kabelwege an andere Internetanbieter in dem Fall nein, das ist nicht die Telekom gewesen und in dem Fall geh halt hin und sag den Leuten oder wenn du weißt dass deine Kundenstamm technisch versiert ist geh tatsächlich hin und sag hey wir tauschen da nicht nur ein paar Kabel sondern da ist eine umfassende Störung und das ist eine umfassende Störung wir tauschen da tatsächlich sehr sehr viel Hardware drin das und das und das wird alles gemacht und im Grund sorgt das dafür dass es so lange dauert weil jeder mit ein wenig technischem Verstand weiß, keine Ahnung wenn ich bei mir im PC 5 Kabel einstecke dann brauche ich da keine 12 Stunden für oder ein paar Kabel einstecke da brauche ich da keine 12 Stunden für und das ist einfach mehr beschreib also entweder gehst du halt wirklich hin mehr wieso du das machst was dann halt nach Aufwand klingt dass das entsprechend gerechtfertigt wird und dass der Kunde auch irgendwie sieht dass er da einen Nutzen dran hat oder so wenn es das wenn das möglich ist oder ich gehe halt hin und sage okay hier technisch das wird detailliert gemacht für die Leute die es halt interessiert beim Thema Kommunikation das würde ich noch kurz gerne aufgreifen das hat sich irgendwie immer gut bewährt die Leute sobald die Migration begonnen hat ein bisschen von externer Kommunikation abzuschirmen also die die das technische Doing machen sobald die Migration begonnen hat einfach nicht mehr mit extern reden weil der setzt halt unnötigen Druck und dann passieren halt noch mehr Fehler ja richtig, das ist halt da hatte ich da nicht mit drauf aber es genau das wenn ich gerade mit beiden Arme irgendwie im Verteiler-Schrank hängen und wenn ich die Kabel neu ziehe dann kommt plötzlich von hinten jemand an das seid ihr schon fertig also idealerweise hat man eine Person für die man dafür abstellt die halt eben nicht involviert ist ja richtig die hat dann quasi daneben steht sowohl die Updates postet als auch dann halt hingeht und irgendwie Kommunikation übernimmt ja wir sind auch dabei, ja das dauert noch ein bisschen sind aber gut dabei danke dir wir hatten vorhin kurz das ist mit mehr Details ich finde zu viele Details sind auch nicht immer hilfreich die Kunden interessiert am Ende nur warum du es machst und nicht wirklich oder die Kunden oder die Benutzer und nicht wirklich was du alles tust weil im Endeffekt verstehen sie dich wahrscheinlich falsch wenn du sagst ein paar Kabel umstecken was für Kabel, wie lang ist das Kabel wenn das Kabel zwei Kilometer lang ist und du musst von A nach B fahren um es an beiden Enden einzustecken nicht immer zu viele Details helfen da auch nicht ich fand das ein bisschen verwirrend okay ich finde auch so oder du hast mehrmals gesagt Mimimi das dauert zu lange und ich finde gerade dort so ein Feedback ist auch anzunehmen und nicht wegzuschmeißen gerade so ein Mimimi klingt so ein bisschen abwertend vielleicht ist da auch an der Stelle wenn zu viele KundInnen oder zu viele NutterInnen Mimimi sagen ich habe falsch kommuniziert oder auch ein wir hatten das Kunden nutzt Confluence was eigentlich ein Wikisystem ist und nutzt das aber zur Projektplanung wofür das System eigentlich gar nicht gedacht ist und da ist die Frage wenn ich als Systemadministrator in mein System kenne und ich nehme an das ist ein Confluence, das ist ein Wikisystem und ich das dann umziehe dann mache ich das System vielleicht bei der Migration kaputt weil der Kunde das komplett anders nutzt und da die Migration überhaupt gar nicht drauf ausgelegt ist da ist dann die Frage ab eben nicht teilweise doch mehr eingehen auf die Nichtwissenden auch so eine Migration retten kann davor dass sie überhaupt erst schief läuft ja also ja prinzipiell schon das mit dem Mimimi klang sehr abwertend kommt halt immer auf den Kontext an in dem Fall wo ich es gesagt hatte meine ich war gemeint dass 5 Minuten nach Beginn der angekündigten Migration sich beschwert wurde dass sich beschwert wurde dass dass die Migration noch nicht fertig ist und das ist dann halt schon okay ja was habe ich daran falsch gemacht okay vielleicht hätte ich nochmal besser kommunizieren sollen wir fangen damit gerade an so das war halt das war gemeint als Beispiel für da haben sich da haben sich Leute beschwert und was kann ich da daraus für mich da rausziehen an Informationen und was ich besser machen kann und wie du ganz richtig sagst der Punkt mit dem Systeme kennen natürlich wenn meine Benutzer oder mein Kunde oder so einen System komplett anders verwenden als es eigentlich vorgesehen ist dann kann ich natürlich mit meiner Migration oder mit dem was ich tue kann ich natürlich was kaputt machen man kann was schieflaufen klar und da ist insbesondere wenn halt Kunden auch involviert sind die das ist jetzt bei wenn man Internet macht ist das anders als wenn man tatsächlich Systeme irgendwie betreut Software betreut dass ich tatsächlich mit meinen Kunden auch irgendwie in Kontakt trete mit wie benutzt ihr das eigentlich wie planen wir das um das zu tun kann da was dabei kaputt gehen oder so oder gegebenenfalls hat wirklich hinzugehen und sagen okay wir müssen das migrieren, wir wollen das migrieren hier habt ihr ein Testsystem ich teste jeder mal die Migration wenn das für dich in Ordnung ist lieber Kunde und sag mir bitte ob das so für dich passt oder ob wir noch was ändern müssen was auch teilweise auch eben in dieses Mimimi mit reinkommt ist oft in der Kommunikation von Migration sind sogar oder von Downtimes allgemein ist den End-Usern sehr oft nicht klar was das tatsächlich für sie bedeutet als End-Konsequenz egal wie dick du das in der E-Mail reinschreibst das System ist nicht verfügbar in der Zeit die können mit dem Namen des Systems vielleicht noch nicht mal was anfangen weil auf deren Seite vielleicht ein ganz anderes Wording da existiert bei denen heißt das vielleicht einfach nur Wiki und nicht Confluence das Logo oben links mag ja sein und wir wissen alle wie ein Confluence aussieht im Gegensatz zu einem anderen Wiki-System die die damit nur damit arbeiten mehr oder weniger ihr ganzes Arbeitsleben kennen das nur unter dem Namen Wiki und einfach solche Feinheiten gerade in der Kommunikation eine Vorab-Kommunikation was genau passiert und vor allem wenn du Migration von Datenstrukturen machst welche Daten sind vielleicht später dann nicht mehr da ja vielen Dank da hinten ist noch eine Frage wir haben Zeit ja du hast Testsysteme erwähnt wie sinnvoll findest du es die Migration zuerst auf ein Testsystem zu testen also zum Beispiel nicht jetzt direkt auf die neuen Server sondern einfach eine virtuelle Maschine zu holen und dort erstmal alles zu testen und dann zu sehen okay die Schritte sind gut gelaufen die nicht und dann erst auf die echten Server zu migrieren wenn ich die Möglichkeit dazu habe meine Migration die ich machen möchte vorher zu testen dann ist das immer sehr sinnvoll das im Vorfeld zu tun eben um genau solche Schritte auszuschließen oder solche Punkte auszuschließen das was schiefläuft dass ich mich verplant habe dass ich was vergessen habe wenn ich eine virtuelle Maschine habe oder so die ich migrieren möchte da kann mir jeder Hypervisor also jeder Haus dafür eigentlich ein spiegelgleiches Update zur Verfügung stellen beispielsweise oder ich habe da internes Tooling für für so eine Spiegelung von so einem System und kann dann halt tatsächlich da hinten gehen ich teste das jetzt einfach mal ich gehe das jetzt mal durch und schau ob das alles funktioniert und wenn es halt eben nicht funktioniert woran hat es gelegen was kann ich besser machen und das sollte man auf jeden Fall eigentlich immer tun wenn man das eben kann hingehen testen ausprobieren Fehler finden, Fehler beheben nochmal testen nochmal ausprobieren weil mein erster Migrationsversuch muss ich an Punkt XYZ denken da kann ich ja jetzt migrieren mach zwar Punkt XYZ da ist dann aber trotzdem noch irgendwas was deswegen schiefläuft was ich nicht bedenke und dann ist das doof deswegen vorher schauen ausprobieren, gucken, dass es funktioniert wenn es funktioniert, wunderbar, alles gut dann bin ich vorbereitet dafür wenn es halt nicht funktioniert anpassen, nochmal testen so lange bis es eben alles gut ist noch weitere Fragen sieht nicht so aus eine Person kommt noch eine Anmerkung zum testen ist es auch sehr wichtig dass du eine grobe Abschätzung kriegst wie lange das dauert dass du halt tatsächlich Zeitvergaben machen kannst weil das kann bei Migrationen schon mal deutlich von deiner Planung abweichen und wenn du es dann wenigstens im Testsystem macht hast auch wenn es dann andere Kapazität hat hast du wenigstens eine wie lange das dauert ja, das ist halt es ist genau das und wenn ich beispielsweise feststelle hey ich kann die Daten die ich habe im Vorfeld schon mal migrieren und dann halt incrementell nur noch einen Diff davon rüberschieben dann ist das voll geil weil das sorgt dafür, dass meine Downtime geringer ist weil ich halt wirklich sagen kann ich migriere das alles schon mal rüber bis auf in welche Migrationstasks auf dem System selber weil neue Version oder sowas dann gehe ich halt hin schiebe einfach die Daten Migration startet jetzt, mach es aus schiebe die Daten die halt zwischen dem letzten Sync und jetzt noch geschrieben wurden schiebe ich einmal rüber dauert vergleichsweise kurz und kann dann halt entsprechend migrieren und dann funktioniert das irgendwie mehrere hundert Gigabyte an Mail-Dateien habe von rotierenden Platten dann würde sowas halt dann mal eben schnell wenn ich irgendwie in den 800 Gigabyte an Daten kopiere das dauert halt seine Zeit und in der Zeit funktioniert der Service halt nicht während ich technische Möglichkeit hätte das sinnvoller und eleganter zu machen vielen Dank, ich glaube noch, dass die Fragen anüberstanden ja voll gut Danke Pro Maso