nicht angemeldet
Moin!
Du hast ein technisches Problem, und bist offenbar dicht genug an der Aufgabe dran, dass man dir Verantwortlichkeit zuweisen kann - und sei es nur, weil "du dich ja auskennst und es dein Job ist", die Chefs aber nicht.
Trenne Politik von Technik. Die Politik ist, dass jetzt Fingerpointing und Verantwortungszuweisung passiert und irgendwer um eine Kopflänge kürzer gemacht werden könnte. Das ist vermutlich nicht deine Aufgabe.
Deine Aufgabe ist augenscheinlich, zu machen, dass es läuft. Konzentriere dich darauf. Finde Lösungen, mit denen das sichergestellt werden kann. Tools dafür gibts reichlich, nutze sie.
Vor kurzem ist unser neuer Webauftritt online gegangen. Das Ganze hat etwa 5 Stunden gedauert, bis ich alle Beteiligten überzeugt hatte, das es besser ist, die alte Konfiguration wieder herzustellen. Das neue System, was eine Agentur für uns ausgearbeitet hat, (mit deren Leistung wir ohnehin nicht zufrieden sind), ist umgehend unter "Last" zusammengebrochen. Meine im Vorfeld an die Agentur gestellte Forderung, Lasttests durchzuführen wurde ignoriert. Die Beratungsresitenz der Agentur ist kaum zu übertreffen, auch in anderen Dingen.
Das bedeutet, dass ihr als Auftraggeber Abnahmekriterien definieren müsst, die die Agentur zu erfüllen hat. Sowas ist natürlich idealerweise schon ganz zu Beginn geschehen, ohne Frage aber kann nicht vereinbart gewesen sein, dass der neue Webauftritt von der Menge an Usern, die den alten besuchen, nicht verkraftet wird.
Insofern ist ein softes Abnahmekriterium nach meiner Auffassung: Neue Website kann die alte Last aushalten. Unter der unumgehbaren Bedingung, dass dieselbe Hardware genutzt wird.
Jetzt ist das Problem natürlich: Was ist Last? Last ist nicht, ausschließlich die Startseite mit Apache-Benchmark tausendfach abzurufen und zu gucken, wie toll der Cache arbeitet. Realistische Last zu erzeugen ist eine Kunst. Realistische Aussagen eines realistisch konfigurierten Last-Tests lassen sich auch nur mit realistischer (sprich: produktionsidentischer) Hardware treffen.
Ein Lasttest sollte also mindestens mal die Aktivitäten umfassen, die User gewöhnlich auf der Website entfalten - und sofern die alte Website dasselbe geboten hat, ergeben sich daraus auch die Relationen, wieviele User wieviele unterschiedliche Dinge auf der Site tun. Ein Lasttest muss solche Usecases in realistischer Mischung und Menge abbilden.
Nun werden laufend Tests gemacht, speicherdumps zum Hersteller des CMS geschickt um das Problem in den Griff zu bekommen und weitere schwachsinnige Maßnahmen, wie das zusammenführen von statischen Inhalten wie CSS und JS in eine globale Datei.
Ist nicht schwachsinnig, aber es ist Optimierung an einer Stelle, die vermutlich keine entscheidende Auswirkung hat.
Ich bezweifele dass das Problem in den Griff zu bekommen ist, da ich quasi von zu Hause aus, ohne Botnezt o.ä. im Moment den Server zum "kotzen" bringen kann. Das eigentliche Problem was ich habe, eine vernünftige Argumentation gegenüber meinen Vorgesetzten zu finden, das Projekt nicht mehr dieses Jahr zu Launchen, sondern erst wenn sicher gestellt ist, dass es stabil läuft. Die "Bosse" sind der Meinung, dass es unbedingt noch vor Weihnachten sein muss.
Solange keine objektiven Kriterien auf dem Tisch sind, die definieren, was "akzeptables Verhalten" der neuen Website ist, solange ist jede Diskussion darüber unsinnig, weil ausschließlich mit Bauchgefühl argumentiert wird. Dein "Ich glaube nicht, dass die Website der Last standhalten wird" steht ein "Ich glaube DOCH, dass die Website der Last standhält" der Vorgesetzten entgegen. Und der einzige Beweis ist ein erneuter Launch und das Gucken, wer dann Recht behält.
Auf der anderen Seite: Kümmert es dich? Wie tief hängst du da mit drin, wenn es nicht läuft? Es klingt zwar Scheiße, aber je nach Schwere der Verantlichmachung ist "Cover your ass" jetzt vermutlich eine gute Idee, wenngleich es ziemlich negative Auswirkungen aufs Unternehmen hat, wenn die IT ständig im Cover-your-ass-Modus operiert. Das verhindert nämlich sehr effektiv Innovationen, weil niemand mehr bereit ist, ein Risiko einzugehen.
Auch ein unter großem Getöse gegen die Wand gefahrenes Projekt, welches im Nachgang zu den üblichen rollenden Köpfen geführt hat, hat in der Regel solche Auswirkungen. Wenn die Firmenkultur es nicht erlaubt, schon kleine Fehler zu benennen und zu beheben, sondern zum Totschweigen zwingt, bis der Fehler nicht mehr übersehen werden kann, und als Konsequenz dann Köpfe rollen (natürlich nicht die der Chefs), dann ist der Firma eigentlich nur ein baldiges Ableben zu wünschen.
Leider erfüllen sich solche Wünsche zu selten.
Irgendwelche Anregungen dazu?
Hattest du nicht früher schon mal etwas haarsträubende Geschichten gepostet? Falls ja: Hast du über das Suchen einer neuen Stelle schon nachgedacht? Im Moment werden erfahrene Entwickler wie die Nadel im Hauhaufen von allen Plattformen, Headhuntern und IT-Abteilungen gesucht und nicht gefunden.
- Sven Rautenberg