Systemverfügbarkeit

[Markus**]

Moin!

Moinsen! ;)

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.

Naja - ich muss im Grunde nicht "machen dass es Läuft" sondern hier eher versuchen einer, wie schon erwähnt ziemlich beratungsresistenten Agentur, die Aufgabe überlassen.
Natürlich habe ich mir auch die Logfiles nach deren "Lasttests" angesehen. Problem dabei ist das Verhältnis statischer zu dynamischer Inhalte die geladen werden. ca 15statisch:1dynamisch. Werden also pro Seitenaufruf 16 Anforderungen an den Server gestellt. 15 Mal mit < 50ms beantwortet aber ein Mal dauert es knapp 2 Sekunden, wenn's gut läuft. Gibt im Schnitt aktzeptable 170ms. Trotzdem doof, weil unrealistisch. Dauert ja erstmal 2 Sek bis das DOM soweit ist, um dem Browser zu sagen was er an statischen Daten nachladen muss.

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.

Genau - wir prüfen grade ob evtl. im Vertrag ein "Launch" als "Abnahme" gilt um ggf. einen Hinweis auf das Beharren des Website-Starts von Seiten der Agentur zu bekommen. Die sollten selbst wissen, dass das Projekt eigentlich noch nicht online gehen kann.

Insofern ist ein softes Abnahmekriterium nach meiner Auffassung: Neue Website kann die alte Last aushalten. Unter der unumgehbaren Bedingung, dass dieselbe Hardware genutzt wird.

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.

Genau... (siehe auch oben) Probleme gibts im Grunde wenn dynamische Inhalte verarbeitet werden (ASP.Net) dann wird's lahm, was darauf schließen lässt, dass es möglicherweise im Code zu begründen ist.

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.

Stimmt! ;) Genau das meinte ich auch, habe es aber im Wahn falsch formuliert.

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.

Es ist eher umgekehrt. Bin noch in der Probezeit und denke ich sollte grade in der entscheidenden Situation zeigen, was ich drauf hab und dass ich mein Geld wert bin.

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.

Ja, schon öfter mal! ;) Liegt vielleicht daran, dass ich noch nie an eine Agentur geraten bin, die derart stümperhafte Arbeit abliefert. Und inzwischen bin ich 15Jahre in der IT unterwegs und habe schon das ein oder andere gesehen.

• Sven Rautenberg

Gruß Markus