Projekt Phoenix. Kevin Behr

Читать онлайн.
Название Projekt Phoenix
Автор произведения Kevin Behr
Жанр Зарубежная деловая литература
Серия
Издательство Зарубежная деловая литература
Год выпуска 0
isbn 9783958751774



Скачать книгу

dass das SAN-Upgrade daran schuld ist, dass der Payroll-Lauf fehlgeschlagen ist?«

      Brent verdreht die Augen. »Ich habe einem der SAN-Techniker mit dem Firmware-Upgrade geholfen, nachdem alle anderen nach Hause gegangen waren. Das hat viel länger gedauert als erwartet, und nichts lief so, wie in der Tech Note angegeben. Es war ziemlich knifflig, aber gegen 19 Uhr waren wir endlich fertig.

      Dann starteten wir das SAN neu, aber alle Selbsttests schlugen fehl. Wir haben daran etwa 15 Minuten gearbeitet, um herauszufinden, was schiefging. Dann kam die E-Mail mit dem Fehler beim Payroll-Lauf. Da zog ich die Reißleine.

      Wir waren einfach zu viele Versionen hintendran. Der SAN-Hersteller hat vermutlich nie den Upgrade-Pfad getestet, dem wir gefolgt sind. Ich habe dich angerufen, weil ich das Ganze abbrechen wollte. Mit deiner Zustimmung haben wir dann mit dem Rollback begonnen.

      Und da ist das SAN abgestürzt.« Brent lässt sich in seinen Stuhl zurückfallen. »Davon ist nicht nur die Payroll betroffen, sondern noch ein ganzer Haufen anderer Server.«

      »Wir wollten die SAN-Firmware schon seit Jahren aktualisieren, haben das aber irgendwie nie geschafft«, erklärt Wes. »Einmal waren wir kurz davor, aber da gab es kein ausreichend großes Wartungsfenster. Die Performance ist immer schlechter geworden, bis zu viele kritische Anwendungen betroffen waren. Daher haben wir uns schließlich gestern dazu entschieden, in den sauren Apfel zu beißen und das Upgrade durchzuführen.«

      Ich nicke. Da klingelt mein Telefon.

      Es ist Ann, daher mache ich den Lautsprecher an.

      »Wie von Ihnen vorgeschlagen, haben wir uns die Daten aus der Payroll-Datenbank angeschaut. Der letzte Monat war in Ordnung, aber dieses Mal sind alle Sozialversicherungsnummern für die stundenbasierten Mitarbeiter völliger Müll. Und alle Felder für Arbeitsstunden und Stundensätze stehen auf null. Das hat hier noch keiner so erlebt.«

      »Nur eine Spalte enthält Müll?«, frage ich und hebe überrascht meine Augenbrauen. »Was meinen Sie mit ›Müll‹? Was steht in den Feldern?«

      Sie versucht zu beschreiben, was sie auf ihrem Bildschirm sieht. »Na ja, da stehen keine Ziffern oder Buchstaben. Ich sehe Herzchen, Piks und seltsame Zeichen ... Und es gibt einen Haufen Zeichen mit Akzenten und Umlauten ... Und es gibt keine Leerzeichen. Ist das wichtig?«

      Als Brent kichert, weil Ann versucht, den Unfug in den Feldern laut vorzulesen, erhält er von mir einen bösen Blick. »Ich denke, wir haben verstanden«, sage ich. »Das ist ein wichtiger Hinweis. Können Sie mir das Arbeitsblatt mit den kaputten Daten zumailen?«

      Sie sagt es zu. »Ach übrigens, kann es sein, dass jetzt eine ganze Reihe von Datenbanken unten ist? Gestern Abend waren sie noch da.«

      Wes murmelt etwas und sorgt dafür, dass Brent still bleibt.

      »Ähm, ja. Wir sind uns dessen bewusst und arbeiten auch daran«, antworte ich, ohne mit der Wimper zu zucken.

      Als sie auflegt, atme ich erst einmal tief aus und nehme mir einen Moment, um welcher Gottheit auch immer zu danken, die Menschen schützt, die Feuer löschen oder Computerpannen beheben.

      »Nur ein kaputtes Feld in der Datenbank? Kommt, Leute, das klingt wirklich nicht wie ein SAN-Fehler«, sage ich. »Brent, was lief gestern abgesehen vom SAN-Upgrade noch, das den Payroll-Lauf hätte stören können?«

      Brent dreht sich mit seinem Bürostuhl um die eigene Achse, während er nachdenkt. »Hmm, jetzt, wo du es sagst ... Ein Entwickler von der Zeiterfassungsanwendung hat mich gestern angerufen und mir eine seltsame Frage zur Struktur der Datenbanktabelle gestellt. Ich steckte mitten in der Phoenix-Test-VM, daher habe ich ihm nur kurz geantwortet. Du glaubst doch nicht, dass er irgendetwas gemacht hat, wodurch das Programm jetzt nicht mehr läuft, oder?«

      Wes dreht sich schnell zu dem Telefon, über das die ganze Zeit die NOC-Telefonkonferenz lief, und schaltet das Mikro wieder ein. »Hey Leute, Wes hier. Ich sitze mit Brent und Patty zusammen, und unser neuer Chef, Bill Palmer, ist da. Steve Masters hat ihn zum Chef von IT Ops gemacht. Hört also alle mal zu.«

      Meine Hoffnung auf eine ordentliche Bekanntgabe meiner neuen Aufgabe schwindet zusehends.

      Wes fährt fort: »Weiß irgendjemand von einem Entwickler, der an der Zeiterfassungssoftware gedreht hat, die in den Fabriken genutzt wird? Brent sagt, jemand hat ihn angerufen, der an einer Datenbanktabelle arbeiten wollte.«

      Aus dem Lautsprecher erklingt eine Stimme. »Ja, ich habe jemandem geholfen, der Verbindungsprobleme zu einer Fabrik hatte. Ich bin ziemlich sicher, dass er ein Entwickler für die Zeiterfassungs-App war. Er installierte irgendeine Security-Anwendung, die John noch diese Woche aktiviert haben wollte. Ich glaube, er hieß Max. Irgendwo hier müssen noch seine Kontaktdaten sein ... Er sagte, er würde heute in Urlaub gehen, daher war das Ganze so eilig.«

      Jetzt kommen wir der Sache näher.

      Ein Entwickler, der schnell noch eine unaufschiebbare Änderung ins System schiebt, um in Urlaub gehen zu können – eventuell als Teil eines dringenden Projekts unseres Chief Information Security Officers John Pesche.

      Solche Situationen bestätigen immer wieder meinen Argwohn gegenüber Entwicklern: Sie machen sich häufig keine Gedanken darüber, dass sie etwas kaputt machen könnten, bevor sie verschwinden. Und IT Operations muss dann wieder hinterherräumen.

      Gefährlicher als ein Entwickler ist nur ein Entwickler, der mit der Security zusammenarbeitet. Zusammen haben sie die Mittel, das Motiv und die Gelegenheit.

      Ich vermute, unser CISO hat einen Entwicklungsmanager dazu gedrängt, etwas zu tun. Das hat dazu geführt, dass ein Entwickler irgendetwas anderes tat, und dadurch blieb dann der Payroll-Lauf hängen.

      Die Information Security bedrängt immer wieder die Leute mit eiligen Anforderungen und interessiert sich dann nicht für die Folgen für den Rest der Firma. Darum laden wir sie nicht so häufig zu Meetings ein. Wenn man etwas erledigt haben will, ist es am besten, wenn sie nicht dabei sind.

      Sie kommen immer mit Millionen von Gründen, warum etwas, das wir machen wollen, eine Sicherheitslücke erzeugt, durch die Alien-Hacker in unsere schöne Firma eindringen und unseren Code, das geistige Eigentum, die Kreditkartennummern und die Fotos unserer Familien stehlen können. Das sind zwar alles potenziell mögliche Risiken, aber ich sehe oft keine Verbindung zwischen ihren schrillen, hysterischen und selbstgerechten Anforderungen und dem tatsächlichen Verbessern der Abwehr unserer Umgebung.

      »Okay, Leute«, sage ich entschieden. »Der Fehler bei der Gehaltsabrechnung ist wie ein Tatort, und wir sind Scotland Yard. Das SAN ist kein Verdächtiger mehr, aber leider haben wir es während der Untersuchung verstümmelt. Brent, du arbeitest weiter am verletzten SAN – das müssen wir ganz offensichtlich wieder ans Laufen bringen.

      Wes und Patty, unsere neuen Verdächtigen sind Max und sein Manager«, sage ich. »Tut alles, was nötig ist, um sie zu finden, festzusetzen und herauszufinden, was passiert ist. Mir ist egal, ob Max Urlaub hat. Er hat vermutlich irgendetwas durcheinandergebracht, und wir müssen das bis 15 Uhr wieder geradeziehen.«

      Ich denke einen Moment nach. »Ich werde mich auf die Suche nach John machen. Möchte mir jemand dabei helfen?«

      Wes und Patty diskutieren darüber, wer John mit verhören möchte. Patty sagt unnachgiebig: »Ich sollte dabei sein. Seit Jahren versuche ich, Johns Leute in der Spur zu halten. Sie folgen nie unseren Prozessen und sorgen immer wieder für Probleme. Ich würde zu gern sehen, wie Steve und Dick ihn für diesen Stunt auseinandernehmen.«

      Das ist anscheinend ein überzeugendes Argument, daher sagt Wes: »Okay, er gehört dir. Er tut mir jetzt schon ein wenig leid.«

      Ich bereue meine Wortwahl. Das ist hier keine Hexenjagd, und ich will keine Vergeltung. Wir müssen immer noch wissen, welche Aktivitäten zu diesem Fehler geführt haben.

      Aufgrund falscher Schlussfolgerungen kam es gestern Abend zu dem SAN-Fehler. Das würde nicht wieder passieren. Nicht unter meiner Leitung.

      Als