Year: 2022
Soundtrack for the evening
Eigentlich mag ich Dubstep mit Vocals ja nicht
- aber das hier: https://yewtu.be/watch?v=ad5L_LIJ2ms aus dem audite Mix Skeptical and Open Minded hat einfach was.
Mal wieder in den Archiven der Fundstücke gebuddelt…
...und eine Stunde Ohrenbassmassage hervorgekramt - war mir so nach. Ein etwas älterer Dubstep-Mix von audite für den KFMW-Adventskalender 2013.
Tut euch selber einen Gefallen und hört euch das nicht auf dem Smartphone oder Laptop an. Kopfhörer - wenn sie dicht sitzen und eine gute Basswiedergabe haben. Sonst auch die nicht.
Aphexia : The Gates
So, auch geschafft…
Blog umgezogen - nja, ok, nur den Content. Und ich sehe gerade das da noch was mit der Menüstruktur im Blog nicht passt...
Neues Plugin installiert, damit ich euch aus meinem Blog im Fediverse auf den Senkel gehen kann ;-), funktioniert auch sauber.
Das erste Mal seit langer Zeit wieder
Heute geht es auf nach Köln, zu einer Veranstaltung meines zukünftigen Arbeitgebers. Irgendwie freue ich mich richtig darauf, weil ich dort einige Kunden sehen werde, die ich schon seit Jahren betreue aber nur vom Telefon kenne. Dazu kommen noch einige ehemalige Kollegen, die zu anderen Unternehmen gewechselt sind und zu denen über die Jahre ein loser Kontakt bestand. Und dann sind da auch noch ein paar der neuen Arbeitskollegen.
Andererseits habe ich leichte Bauchschmerzen wegen der ganzen Corona-Situation. Es gibt keine Test- und Maskenpflicht mehr, gestern hat mich ein Kunde mit dem ich mich auf der Veranstaltung treffen wollte abgesagt - Corona. Hatte dann auch noch ein paar Sachen wegen der Veranstaltung mit meinem zukünftigen Arbeitgeber zu klären, kamen da auch nochmal kurz auf das Thema zu sprechen: die haben auch schon einige Corona-bedingte Absagen erhalten. Mal schauen ob ich ein Andenken mitbringe...
Desaster incoming
oder auch
...told you so. Mein ehemaliger Arbeitgeber hat ein Projekt am laufen, in dem es darum geht das die ganzen Rechenzentren zentralisiert werden. Vorausgegangen ist ein massiver Umbau der IT-Organisation. Im Rahmen dieses Umbaus der IT-Organisation ist Wissen verloren gegangen - was ganz einfach zu erklären ist:
- Geschriebene Dokumentation ist nie ein 1:1 Abbild des dokumentierten Systemes. Um geschriebene Dokumentation richtig nutzen zu können, muss Grundwissen vorhanden sein. Ein allgemeines IT-Grundwissen UND ein Grundwissen über das System, zu dem die Dokumentation gehört.
- Kündigungsfristen: Es gibt Länder, die haben - für beide Seiten - ziemlich kurze Kündigungsfristen. Da kann es dann passieren das man einen Arbeitnehmer kündigt - oder der kündigt, der seinen Resturlaub einreicht und sofort weg ist.
- Personalstamm: Wenn die Aufgabe(n), die ein das Unternehmen verlassender Mitarbeiter hat, nicht wegfällt, wäre es sehr sinnvoll wenn jemand anders die Kapazität hat diese Aufgaben rechtzeitig zu übernehmen. Muss man dagegen erst monatelang mit Finance diskutieren ob die Stelle neu besetzt wird - oder es einen allgemeinen Hire Freeze gibt...
- nicht beachtete Seiteneffekte: Wenn man die Hälfte des Personals eines Standortes mit einem kurzen knappen Statement entlässt (arbeitsrechtlich war es in dem Land in Ordnung) - muss man damit rechnen das die nicht gekündigten Mitarbeiter ebenfalls kündigen. Sind die nicht gekündigten Mitarbeiter dann auch noch von der IT-Crew und es in dem Land eine starke Nachfrage gibt - kann man sich wohl ausmalen was passiert: große Teile der IT-Crew haben sofort ihre Kontakte spielen lassen, neue Arbeitgeber gefunden und gekündigt. Und dann ist da wieder das Thema mit den Kündigungsfristen und dem Urlaub...
- Arbeitnehmer, die sich den Laden kurz angeguckt haben und das Unternehmen innerhalb der Probezeit wieder verlassen haben oder gekündigt worden sind - aber halt auch irgendwas in den Systemen gemacht / geändert haben.
Alles in allem also schon mal gute Voraussetzungen für große Projekte.
Irgendwann waren dann die Rechenzentren dran, wo wir unsere Systeme drin laufen hatten. Ursprünglich war die Aufteilung der beiden RZ, das eins Production - nennen wir es RZ-P - und eins Fallback - RZ-F - ist. Passend dazu gab es regelmäßig einmal im Quartal DRD Aktionen, bei denen die IT-Crew Notfälle durchgespielt hat.
Randnotiz - nur der Chef der IT-Crew wusste welches System bei der Aktion wie ausfällt. Der hat dann auch schon mal einen Core-Switch außer Betrieb gesetzt oder einem Oracle DB-Cluster die Netzwerkverbindung gekappt - also richtige Ausfälle erzeugt. Die Aktionen liefen immer am Wochenende und wurden vorher angekündigt, so dass alle - sowohl Mitarbeiter als auch Kunden informiert waren.
Im Laufe der Jahre wurden trotz Virtualisierung immer mehr physikalische Komponenten benötigt, was dazu geführt hat das beide Rechenzentren Production wurden. Dabei wurde am Anfang noch darauf geachtet, das immer nur komplette Systeme (also alles was zusammen zu einem Produkt gehört) umgezogen oder aufgebaut wurden, es aber nie zu einem Spread kommt.
Tja - am Anfang... Man hat für Umzugswellen definiert, einmal alles was 'nur' intern verwendet wird und alles, was direkt mit Kunden interagiert. Das ganze halt dementsprechend für beide Rechenzentren.
So fing es mit den Vorbereitungen an, man hat Software auf allen Servern installiert um zu die Nutzung zu analysieren. Es gab diverse Runden mit 'Wem gehört welches System' und 'Was macht das'. Alles wurde in Excel-Dateien zusammengefasst, ausgewertet - und dann hat man sich dazu entschieden das es nicht intern mit externer Unterstützung gemacht wird, sondern komplett von einer externen Firma gemacht wird, die die IT-Crew anleitet und denen Anweisungen gibt. Und die vorher gesammelten Information - mehr oder weniger obsolet, beziehungsweise erfolgreich ignoriert.
Irgendwann kam der Startschuss für RZ-F, interne Systeme. Es gab diverse Meetings, in denen diverse Informationen abgefragt worden sind, ein Termin wurde genannt, verschoben, genannt, verschoben, genannt - und dann ging es los. Angeblich würde es nur minimale Nebenwirkungen geben - so der Plan. Es kam zum Rollback, man hat das ganze Projekt um einen Monat nach hinten verschoben.
RZ-F, interne Systeme, nächster Versuch: wieder hieß es: kaum Nebenwirkungen. räusper 3 Tage Full Stop sind also kaum Nebenwirkungen.
Eine der Ursachen: Es wurden von irgendwelchen Leuten Systeme, die direkte Abhängigkeiten zueinander haben, doch auf beide RZ verteilt. Damit gab es auf einmal extreme Verzögerungen durch Latenzen, Systeme die sich aufgrund von Änderungen in den IP-Ranges nicht mehr gesehen haben und andere Späße.
Jetzt könnte man ja davon ausgehen, dass das Desaster einen gewissen 'Lessons learned' Effekt hat. Könnte, wohlgemerkt.
RZ-F, produktive Systeme: ich mach's kurz, ihr könnt es euch denken: Desaster Teil 2.
Überraschung - für RZ-P gab es neue Verantwortliche. Es wurden wieder Termine genannt, wieder das gleiche Spiel, erst internes und dann produktives. Es wurde deutlich mehr auf Abhängigkeiten geachtet, man hat sich zum Beispiel auf Einwand der Netzwerker explizit noch mal die Netzwerkkommunikation angeschaut und mit dem abgeglichen, was da so dokumentiert war - beziehungsweise wie einzelnen Netzwerke getaggt waren. Das hat die erste Verschiebung verursacht.
Dann gab es im RZ-P ein zentrales Storage-System, dessen Inhalt auch in das neue RZ musste. Hat sich rausgestellt: Ist etwas defekt, ist etwas falsch konfiguriert. Jedes Mal, wenn man angefangen hat Daten aus bestimmten Volumes zu kopoieren, ist die Performance des Storage-Systems extrem zusammengebrochen. Und zwar soweit, dass es für die Kunden teilweise nicht mehr möglich war zu arbeiten. Automatisierte Jobs die in Abhängigkeiten zueinander stehen, sind auf die Klappe gefallen.
Normale Laufzeiten von 2-3 Stunden brauchten auf einmal 20 und mehr Stunden. Automatisierte Bereitstellung von Daten - von 6 auf 60 Stunden. Und wir sind nur in der Vorbereitung. Alles in allem: nächste Verschiebung - und hier wird es dann nochmal richtig lustig: mitten in meine Urlaubszeit1 rein, was ich auch sofort bei der Bekanntgabe des Termines gesagt habe.
Bei irgendwem hätte spätestens jetzt ein Glockenspiel aus Alarmglocken losgehen müssen. Weit gefehlt - Nada, niente, zilch. Still ruhte der See, obwohl ich es immer wieder erwähnt habe und auch immer wieder gefragt worden bin wer den bitte meine Aufgaben übernimmt. Da sich keiner bei mir gemeldet hat - siehe https://jugglingjester.net/2022/04/05/wann-macht-man-eine-ubergabe/, hatte ich da keine Antwort drauf. Bis dann das Thema am vorletzten Tag vor meinem Urlaub vom Projektleiter angesprochen worden ist. Daraufhin hat es eine kleine Eskalation, am letzten Arbeitstag halt nochmal 2 Meetings von jeweils 1,5 Stunden zur Übergabe. Reicht natürlich vorne und hinten nicht, insbesondere wenn a) die Leute schon vollgepackt sind, b) das erste Mal von den Systemen hören und c) generell kein Background-Wissen über die Produktlandschaft haben.
Clusterfuck, the aftermath
Tag 1 nach meinem Urlaub, SoCf + 10d:
- Voicebox abgehört: wtf? Klare Ansage, das ich erst ab dem daunddaten wieder erreichbar bin. Trotzdem diverse Kunden, die mich um sofortigen Rückruf bitten. Okayy, spannend.
- em@ils: über 600 neue Mails, erstmal durchfiltern. Monitoring -> als gelesen markiert, ab in die Tonne. Job-Status-Mails: same. Voicebox Notifications -> auch weg. Irgendwann war ich runter auf knapp 100 ungelesene eM@ils, die dann kurz überflogen. Größter Teil davon auch in die Tonne, da Support-Ticket-Benachrichtigungen und ähnliches Geschnassel. Irgendwelche Mails von Vertriebsmitarbeitern - ich möchte mich doch bitte umgehend mit dem Kunden XYZ in Verbindung setzen, weil - da geht was nicht. Aus dem wtf? wurde ein W.T.F.?!
- Teams: ich mach's kurz - aus dem W.T.F.?! wurde ein ausgewachsener Clusterfuck. Ich überlegte kurz ob ich nicht vielleicht vom Dach springen sollte - und entschied mich für 8 Tage Spaß und Gezoffe.
Wenn man ein System oder eine Systemlandschaft umzieht - so habe ich mal gehört - kann es durchaus vorkommen das sich IP-Adressen ändern. Egal wo, egal warum. Sollte man auf dem Schirm haben - insbesondere, wenn man für Firewalls zuständig ist. Eines der Probleme: Kunden konnten bestimmte Services nicht mehr erreichen. Das ging vor SoCf, d.h. die Firewall Rules haben existiert und funktioniert. Nach diversen Diskussionen mit Netzwerkern, ob das ein Problem des Umzuges ist oder nicht, hat sich dann am SoCf +12 irgendwann einer der Obernetzwerker der Sache angenommen und das Thema in 5 Minuten erledigt. Lösung: Auf dem Outgoing Interface der Firewall war noch die alte IP-Adresse getaggt, die nicht mehr gültig und nicht mehr erreichbar war.
Triggert mich ein Kollege an, mit dem ich zusammen (er Inhalt, ich Jobs, IT-Crew die Systeme) eine Umgebung betreue. "Hör mal, kannst du dir bitte mal dasunddas anschauen? Hast du da vielleicht eine Idee wie man das lösen kann?" Er zeigte mir die Fehlermedungen, die einer der automatischen Jobs rausgeworfen hat. Joa, das Tool macht einen Check auf den Zeitstempel "Created". Als man die Daten vom Storage-System aus dem RZ-P rübergeschoben hat, wurde ein großer Teil am gleichen Tag zur gleichen Uhrzeit von dem System, über das die Synchronisierung gemacht worden ist, commited. Die IT-Crew angetriggert - "Jungs, das und das ist das Problem, das wäre die Lösung, das wären die Tools mit denen man das machen kann". Vorschlag wurde angenommen - hat nur SoCf + 15 Tage gedauert bis es umgesetzt worden ist.
Anderes Problem mit vielen unnötigen Diskussionen: Irgendwas ist bei der Anpassung von DNS-Records dezent daneben gegangen. 2 Webseiten waren seit SoCf nicht mehr per Domain Name erreichbar, nur noch per IP. Problem - Zertifikate werden auf Namen ausgestellt. Also mal ein wenig getestet, analysiert, Netzwerker (ja, die haben angefangen mich zu haßlieben) nochmal angetriggert. Die Netzwerker haben selber untereinander Pingelriez mit ranfassen gespielt, keiner kam weiter. Jeder hatte andere Ergebnisse bei DNS-Queries, jeder hatte andere Lösungsansätze. SoCf + 16 Tage später hat man dann mal den DNS Registrar angetriggert, der ein paar Korrekturen vorgenommen hat. Meine Vertretung kam, als das Problem SoCf aufgetreten ist, nichts unternommen die Ursache herausfinden zu lassen, er hat die Kunden dazu gebracht, das sie alternative DNS-Server von Google eintragen, wahlweise in die NIC oder in den Router. Nur - auch mit den DNS-Servern von Google gab es die gleichen Probleme - sie konnten die Namen auch nicht immer zuverlässig auflösen...
Dann gab es da noch eine weitere Kommunikationssache, die nicht lief. Vom Verhalten her roch das gewaltig nach dem Thema mit der alten IP-Adresse auf dem Outgoing Interface. Also Netzwerker SoCf +13 angetriggert, da nicht ganz so dringend weil nur intern relevant. Fingen die gleichen Diskussionen wieder an, dieses Mal noch ignoranter, obwohl ich gleich darauf hingewiesen habe das die sich mal die entsprechende Firewall-Rule anschauen sollten. Wurde dann SoCf + 16 innerhalb von 5 Minuten durch den Obernetzwerker erledigt - es war das Thema mit dem Outgoing...
Zu guter Letzt gab es SoCf + 19 noch einen kleinen Spaß: Kein Kunde konnte irgendwelche externen Systeme erreichen. Stellte sich dann sehr schnell raus: Die haben in der Nacht von SoCf +18 auf +19 einen DNS-Server ausgeschaltet, der bei diversen Systemen als DNS Forwarder eingetragen war. War so geplant, hat es aber nicht für nötig gehalten irgendjemanden zu informieren. Kein großes Thema, 3 neue IP-Adressen bekommen, eingetragen, getestet - funktioniert.
Warum dann jetzt "Told you so"? Ganz einfach - alle Leute die schon etwas länger in den Unternehmen sind (wir sprechen da von 5+ Jahren) haben das kommen sehen. Es gab (oder gibt) ein Excel-Sheet, das als Issue Log gedient hat. SoCF hat es bei 0 angefangen. SoCf +10 war Issue 340 aktuell. SoCf +19, mein letzter aktiver Arbeitstag, stand der Zähler bei über 450, still counting. Der größte Teil - so um die 85 % - geschlossen, aber auch irgendwo in den kleinen 200ern offene High Prio Issues, dazu diverse offene Low oder Medium Prio Issues.
-
Ich hatte am Beginn der Planung gleich gesagt das ich a) gekündigt habe und b) von Anfang April an zweieinhalb Wochen und den ganzen Mai Urlaub habe. ↩
Wann macht man eine Übergabe?
Definitiv nicht am letzten Tag, den der zukünftig ehemalige Arbeitnehmer verfügbar ist. So hatte ich dann letzte Woche Freitag das Vergnügen zwei etwas längere Übergabe-Sitzungen zu haben. Mit Menschen, die vorher noch nie etwas mit den entsprechenden Umgebungen zu tun hatten.
Also mein bestes getan und erklärt, was man in einer oder anderthalb Stunden an Wissen vermitteln kann. Nervig war der Line Manager des Teams: der kam gleich bei dem ersten Thema (Datenbanken) auf den Gedanken das alles erstmal haarklein erklärt haben zu wollen. Den habe ich dann etwas barsch abgebürstet: "Hör mal, wir haben nur eine begrenzte Zeit. Und ich soll dir hier jetzt die Funktionsweise des Datenbankservers erklären? Geht mal so garnicht. Ich halte es für sinnvoller wenn ich die gesamte Struktur und bekannte Stolperstellen erkläre. Dabei werden wir dann auch gleichzeitig auf wichtige Konfigurationsdateien, Scripte und CronJobs kommen."
Den Rest der Sitzung war er dann ruhig und hat keine Fragen gestellt - ebenso bei der zweiten Sitzung.
…and the show goes on
Bezüglich des Wechsel meines Arbeitgebers - es kommt genau so wie ich es befürchtet habe. Keiner will / darf / kann was übernehmen, es gibt viele ungeklärte offene Punkte.
Was soll ich sagen - es ist mir schlichtweg egal. Es war vorhersehbar, ich habe die Themen mit der Übergabe immer wieder angesprochen - irgendwer hat auch an irgendwen irgendwas gemeldet - nur passieren tut nichts.
Hinzu kommt noch - unser Unternehmen ist gerade dabei seine über ganz Europa verteilten Rechenzentren zu konsolidieren. Der Umzugstermin für das Rechenzentrum in dem 'meine' Systeme liegen, wurde letzte Woche verschoben. Genau mitten in meinen Urlaub rein. Ich hatte das mehrfach angesprochen - man kümmert sich.