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 Urlaubszeit 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.