Releaseankündigungen auf Webseite ja oder nein??

[MatzeA]

Servus,

nun doch mal eine Umfrage zum Thema Internet.
Wie doch einige wissen dürften, darf ich mich mit dem Thema Releasemanagement herumschlagen.

Tja wie man bei so vielen Online Webanwendungen feststellt.
-> So auch hier ;-))

Die Kunden / Endkunde bekommen in vielen sehr viele Fällen gar nicht mit, dass demnächst ein Releasewechsel ansteht.

Vor allem bei Bugfixes wird das sehr häufig praktiziert.
Ich spreche nicht von Hot sondern Bugfixes.

Meine Meinung zum Thema ist eigentlich, dass man sich die mühe machen solle und derartige Termine veröffentlichen.
Manche Anwendung hat eben bei einer Versorgung offline Zeite von rund 30 -60 Minuten.

Und aus sicht des Endkunden ist es wohl seltern bescheuert, wenn man mitten im shopen ist und plötzich sind alle Daten futsch.

Was meint Ihr dazu?

Gruss Matze

[MudGuard]

Hi,

Tja wie man bei so vielen Online Webanwendungen feststellt.
Die Kunden / Endkunde bekommen in vielen sehr viele Fällen gar nicht mit, dass demnächst ein Releasewechsel ansteht.
Meine Meinung zum Thema ist eigentlich, dass man sich die mühe machen solle und derartige Termine veröffentlichen.

ja, sollte man. Aber bei einer Ausfallzeit im Stundenbereich sollte eine Vorwarnzeit von ca. 1 bis 2 Stunden ausreichen.

Während der Offline-Zeit sollte nach Möglichkeit eine Seite mit Hinweis auf die Wartungsarbeiten und auch dem voraussichtlichen Zeitpunkt der Wieder-Verfügbarkeit angezeigt werden.

cu,
Andreas

[fastix®]

Moin!

Ich spreche nicht von Hot sondern Bugfixes.

Wo bitte ist denn der wirkliche Unterschied?

Was meint Ihr dazu?

Mach es nachts um drei und fertig. (Es sei den  die Mehrzahl Deiner Kunden sitzen in den Staaten...)
Releases werden doch praktisch nie zum Angekündigten Zeitpunkt fertig.

Wieso ist da jedesmal der Server für 30 bis 60 Minuten down? Geht das _wirklich_ nicht anders?
Da scheint mir das Problem zu sitzen. Konstruktionsfehler. Ich _vermute_ da ist irgendwas nicht sauber getrennt: Logik, Daten, Darstellung.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[MatzeA]

Servus,

hotfix -> Ohne ankündigung bei einem totalen Ausfall oder schwehrwiegendem Fehler
bugfix -> Mit ankündigung zu vereinbarten Terminen um "Schönheitsfehler" oder unwichtige Funktionsfehler zu beheben.

2. Fahr einen Bea Applikationserver runter deploy eine -> .EAR = 56 MB grosse Anwednung hoch. Das dauert vor allem wenn dann noch rund 2-3 GB Daten gefüllt (cache füllen) werden.

Bis die Anwendung wirklich wieder in Betrieb ist kann das dauern.
Je nachdem welches Produt es ist gibt es ja auch cluster Lösungen aber wegen der Performance werden die EJB Sessions nicht repliziert.
Das wäre leider ein Supergau bei den aktuellen zugriffen die wir teilweise haben.

Tja Du siehst es liegt gar nicht mal so an der aRchitektur bei mehreren Millionen Artikel.
Ausserdem sind die anwendungen meistens sogar multilingual,
mehrsprachig. -> Wir haben teilweise eine sehr konstante Last, sodass es egal ist wenn man die Maschine aus dem Netz nimmt dies bei nahezu jeder Tages bzw. Nachtzeit rund 100 - 300 Tausend Benutzer bedeutet.

Dass eine Fehlerseite eingeblendet ist steht ausser Frage.
Nur sole man die Benutzer einen Tag vorher schon mit nervigem Alert Fenster bzw. einem Popup etc. darauf hinweisen:
Hey morgen ist der Dienst von bis weg?

Mich nervt das z.B: bei vielen anwendungen höllisch wenn man im Netz ist den Warenkorb füllt und dann am ende erfährt, nö Einkaufen geht grad nicht.

Prima hätte ich das vorher gewusst hätte ich später angefangen.

Gruss Matze

[fastix®]

Moin!

Wir haben teilweise eine sehr konstante Last, sodass es egal ist wenn man die Maschine aus dem Netz nimmt dies bei nahezu jeder Tages bzw. Nachtzeit rund 100 - 300 Tausend Benutzer bedeutet.

Es ist etwas ungewöhnlich, eine ein derartiges "System" betreffende Frage hier in einem solchen Forum   zu finden...

Dennoch: (Ohne wirklich drinzustecken)
Wenn solche Updates notwendig sind sollte sich die Downzeit bei konsequenter Trennung von Datenbasis, Logik und Darstellung kürzer halten lassen. In vielen Fällen sollte es gar keine geben. Wenn natürlich an Datenbank und Logik zugleich was geändert wurde mag das unter Umständen unumgänglich sein. Dann wäre eine Idee:

Mietserver  mieten + Replikation der DB, Mietserver via DNS online, warten, bis beim eigentlichen Server keine Zugriffe mehr stattfinden, Austausch, eigentlicher Server via DNS online , Mietserver nach Zugriffsende offline, Vertrag beendet. Das geht natürlich am besten, wenn die DB auf einem oder mehreren getrennten Servern liegt (gegenseitige Replikation A->B[->C...]->A).

Aber eine 24- Stunden- Ankündigung ist mit Popups und Alerts bei einem Shop absolut kontraproduktiv. Nehmt meinetwegen die Seiten entsprechend dem Besucherverhalten "von vorn nach hinten" gruppenweise aus dem Betrieb. "Please wait 4 Wartung".

Die andere Variante ist ohnehin die Lastverteilung via DNS zu benutzen und statt einem Superserver mehrere kleine zu verwenden. Die können dann der Reihe nach aus dem DNS genommen und mit dem update versehen werden. Das klappt sogar bei Google.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[MatzeA]

Servus,

naja das geht so leider nicht.
Problem ist 1, dass wir nich nur eine "witzlose" scuhe haben, sondern Anwendungen ernstzunehmende Anwendungen darauf betreiben wie z.B: Mysap etc.

Solche dienste und Service lassen sich nicht so ohne weiteres auseinander Koppeln, vorallem nicht, wenn man aus performance Gründen einen Cache betreibt und die Basis Daten dort hält usw. usw. usw. Abhängigkeiten zu weiteren Applikationsserver usw.
Ich spreche nicht von einem "einfach Webshöpchen" Sondern von anwednugnen mit min. 100 000 offenen Transaktionen und mehr gleichzeitig bei einem Transaktions Durchsatz von 2 - 3 MIO min täglich.

Ausserdem der deploymentprozess selber ist ein akt von 5 Minuten.
Aber rate mal wie oft der BEA schon aus unerfindlichen Gründen abgerauch ist. Wie oft der Kunde hoch und heilig versprochenhat ja alle Daten wurdn migriert.

Dass sich plötzlich Fehler ergeben, die man auf einer identischen Pre Produktiven Umgebung gestestet hat.

Tja so kochen die grossen schlampig hoch 3 dafür durfte ich gestern ein Telekom Produkt überwachen.
Jaja die hosten nicht selber, weil die es auch nicht besser hinbekommen.

Darum geht es aber gar nicht es ist nur eine reine philosophische Frage.
Ja sagt man dem Endkunde Morgen von bis ists nix mit einkaufen oder lässt man den mal schnell stunden lang im system rum hameln, bis er dann feststellt, Schade heute kann ich meine in 30 Minuten zusammengestöberte Bestellung nicht absenden.

Gruss Matze

[fastix®]

Moin!

Darum geht es aber gar nicht es ist nur eine reine philosophische Frage.

Eben!

Ich bring jetzt mal meinen Lieblingsspruch:

"Große Lösungen: große Probleme."

Nicht traurig sein: ist ja nicht gegen Dich gerichtet.
Also wenn Du, wie beschrieben, unter Umständen so extreme Arbeitszeiteinbußen hast, dann würde ich warnen. Und bei der nächsten Produktversion daran denken, daß man so etwas ohne "downtime" stricken _muss_. 3 Stunden Arbeit zu verlieren ist kein Spaß, weswegen jeder einfachen Sekretärin immer gesagt wird: "Zwischenspeichern! Zwischenspeichern!" Und dann werden solche mördermäßigen Anwendungen gestrickt. Ist doch ein Unding- oder? Aber das ist ja nun weder Deine Schuld, noch Dein aktuelles Problem.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[MatzeA]

Servus,

Nicht traurig sein: ist ja nicht gegen Dich gerichtet.
Also wenn Du, wie beschrieben, unter Umständen so extreme Arbeitszeiteinbußen hast, dann würde ich warnen. Und bei der nächsten Produktversion daran denken, daß man so etwas ohne "downtime" stricken _muss_. 3 Stunden Arbeit zu verlieren ist kein Spaß, weswegen jeder einfachen Sekretärin immer gesagt wird: "Zwischenspeichern! Zwischenspeichern!" Und dann werden solche mördermäßigen Anwendungen gestrickt. Ist doch ein Unding- oder? Aber das ist ja nun weder Deine Schuld, noch Dein aktuelles Problem.

Hach wenn das so einfach wäre. Die Ursprüngliche Anwendung war wohl überlegt und gut durchdacht. Ja Sie war für das gemacht, was Sie ehemals tun sollte.
Denn Sie sollte nur eine Transaktionsplattform für eine Gesellschaft bzw. eine grosse Anwendung sein.
Heute laufen rund 85 Unterschiedliche Brands darauf. Alle gehen auf die gleiche Datenbasis und verwenden teilweise modifizierte oder der Basis gleichen Adapter und Komponenten.

Nun ja dafür war eben die Architektur der Anwendung nie gedacht und geschaffen. Es hat ja auch kein Mensch damals dran gedacht, dass das nun "jeder" haben will.

Inzwischen gibt es nur noch einzelne vom Kernteam, die das ganze Produkt kennen. Tja Geld für eine neue Architekur sowie die Zeit hatauch keiner mehr. Da hilft nur eines das beste draus machen.

Grus Matze

[Auge]

Hallo

Ja sagt man dem Endkunde Morgen von bis ists nix mit einkaufen oder lässt man den mal schnell stunden lang im system rum hameln, bis er dann feststellt, Schade heute kann ich meine in 30 Minuten zusammengestöberte Bestellung nicht absenden.

Was würdest _du_ als Kunde erwarten?

Tschö, Auge

[MatzeA]

Servus,

Was würdest _du_ als Kunde erwarten?

In welcher Position?
Als Endanwender?
Ja als Endanwender wäre ich glücklich zu wissen, jetzt macht das Arbeiten am System wenig Sinn, weil man eh nix speichern kann.

Oder als mein Kunde, der das Sysem teuer betreibt und sich damit Einnahmen (Provision) erhofft?

Tja als solcher stelt sich die Frage wer soll das entscheiden?
Ein Manager der sich gedanken darüber macht, ob man nacher in der Besprechung merkt, das auf seiner Hose ein Wasserflckchen ist.
Der mathematisch versucht zu berechenen, wie weit sich das negativ auswirken könnte?

Tja als solcher würde ich sagen, tun wir mal so als ob das Prolem am Endkunde liegt.

Als Supportmanager der hinterher die Anrufe verzweifelter DAUS bekommt. Tja als solcher würde ich ganz klar ein Baustellen Schild aufstellen.
Früher oder später kommt es eh raus.

Ich tu das was der wo bezahlt haben will.
Wenn der sagt lass de Leute dumm sterben. Dann bleibt das Wissen eben im Haus.

Mich hat nur die Meinung zum Thema interesiert, weil diese Diskussion bestimmt bald wieder ansteht.

Da würde mich interesieren, wie andere dazu stehen.
Würde es z.B. Quelle eine krone rausreisen, wenn man dezent aber gleich zu anfang darauf hingewiesen wird, heute gibts noch ein Update also Bestell lieber morgen, da es heute zu Probleme kommen wird.

(Um vorschnelle antworten auszuräumen, ich spreche nicht davon eine offtime vn mehr als 1 Stunde zu haben. Das mit dem Ta war nur so daher geplappert. Quasi Sinngemäs.)

Gruss Matze

[Sven Rautenberg]

Moin!

Manche Anwendung hat eben bei einer Versorgung offline Zeite von rund 30 -60 Minuten.

Und aus sicht des Endkunden ist es wohl seltern bescheuert, wenn man mitten im shopen ist und plötzich sind alle Daten futsch.

Da es hier um eine Anwendung mit hohen Zugriffszahlen geht, halte ich eine Downzeit von einer Stunde schon für unzumutbar.

Du schreibst von 100.000 bis 300.000 Besuchern. Am Tag? Pro Stunde? Jedenfalls ist das eine erhebliche Zahl, und wenn die eine Stunde lang nicht shoppen können, dann ist das äußerst übel. Egal wie toll entschuldigt das wird. Die Anwendung steht ja sicherlich nicht zum Spaß da.

Also: Zweite Infrastruktur schaffen. Für kleine Anwendungen hätte ich gesagt, dass man mit entsprechenden virtualhost-Einträgen in einem Apache was tun könnte.

Kann man tatsächlich auch. Wenn es (wie gesagt: klein gedacht) um eine PHP-Anwendung ginge, könnte man die in einem neuen Verzeichnis installieren und erstmal über einen Testnamen angucken. Die Datenbank bleibt vielleicht identisch, die Session-Daten liegen auch an derselben Stelle - dann kann man durch simples Wechseln der Virtualhost-Konfiguration nahezu unterbrechungsfrei auf die neue Version updaten, ohne dass irgendwelche Daten verlorengehen.

Wenn an der DB Strukturen geändert wurden, ist das ganze etwas schwieriger. Dann muß man versuchen, die DB möglichst verlustfrei auszutauschen. Dabei kann es im Zweifel zu Verlusten kommen, denn solange die alte Applikation läuft, kommen neue Datensätze in der alten DB hinzu, die alle in die neue DB integriert werden müssen. Hierfür ist unter Umständen Downtime notwendig, andererseits ließe sich auch ein zeitweiliger Parallelbetrieb einrichten. Bestehende Sessions können bis zu ihrem Verfall die alte DB weiternutzen, und neue Sessions werden nur noch aufs neue System geleitet.

In jedem Fall muß man solche Downtime-Vermeidungsstrategien im Konzept vorsehen. Nachträglich reinpfriemeln dürfte schwierig werden.

Und wenn sowas dann tatsächlich notwendig wird, ist eine Ankündigung sicherlich nicht verkehrt. Nur bitte entsprechend dezent. Popups und Alertboxen sind nicht förderlich. Das erzeugt dann eher das Gefühl, man habe es irgendwie mit einer Beta-Version zu tun, wenn man so eindringlich vor der Benutzung gewarnt würde.

- Sven Rautenberg

[MatzeA]

Servus,

Du schreibst von 100.000 bis 300.000 Besuchern. Am Tag? Pro Stunde? Jedenfalls ist das eine erhebliche Zahl, und wenn die eine Stunde lang nicht shoppen können, dann ist das äußerst übel. Egal wie toll entschuldigt das wird. Die Anwendung steht ja sicherlich nicht zum Spaß da.

Gleichzeitig. Es finden pro Tag zwischen 2 und 4 mio Transaktion statt.
Es wird ja nicht täglich etwas deploy. Wenn e hoch kommt, dann ist die anwendung pro Monat 0,25 Stunden down. Das wiederum zu einer schwach besuchten Zeit ist ja klar. Ebenfalls ist bis zu 1 Stunde im Regelfall geht`s schneller aber leider nicht immer.
Den Worstcase haben wir in 60 Minuten debuggt gehabt.

-> Im übrigen sind wir Gott sei Dank nicht für den Schrott denn man uns liefet Verantwortlich.

Also: Zweite Infrastruktur schaffen. Für kleine Anwendungen hätte ich gesagt, dass man mit entsprechenden virtualhost-Einträgen in einem Apache was tun könnte.

»»

Das klappt aber auch nicht immer, da Du viele Transaktionen parallel halten müsstest.
Eine Transaktionsreplizierung bereitet sogar Sun Cluster Probleme.
Weswegen man davon wieder weg gekommen ist.
Einen Weblogic Server und Session Replizierung ist ein Todestoss der Extraklasse.

Kann man tatsächlich auch. Wenn es (wie gesagt: klein gedacht) um eine PHP-Anwendung ginge, könnte man die in einem neuen Verzeichnis installieren und erstmal über einen Testnamen angucken. Die Datenbank bleibt vielleicht identisch, die Session-Daten liegen auch an derselben Stelle - dann kann man durch simples Wechseln der Virtualhost-Konfiguration nahezu unterbrechungsfrei auf die neue Version updaten, ohne dass irgendwelche Daten verlorengehen.

Ja dann schon aber mit sowas habe ich recht selten zu tun.
Wir haben zwar ganz klar einen Load Balancer etc. damit schafft man downtimes auf das wenigste zu reduzieren aber bei DB Änderungen muss die Applikation komplett neu gestartet werden.
Da es leider einige unangenehme Abhängikeiten gibt, zwingt uns das auch immer wieder alle Bereich "gleichzeitig" neu zu versorgen.

Ich hasse diese Clonerei.

Wenn an der DB Strukturen geändert wurden, ist das ganze etwas schwieriger. Dann muß man versuchen, die DB möglichst verlustfrei auszutauschen. Dabei kann es im Zweifel zu Verlusten kommen, denn solange die alte Applikation läuft, kommen neue Datensätze in der alten DB hinzu, die alle in die neue DB integriert werden müssen. Hierfür ist unter Umständen Downtime notwendig, andererseits ließe sich auch ein zeitweiliger Parallelbetrieb einrichten. Bestehende Sessions können bis zu ihrem Verfall die alte DB weiternutzen, und neue Sessions werden nur noch aufs neue System geleitet.

Ja und diverse Anwendungen reissen dann den Bea incl. Nodemanager runter. Ausserdem werden unsere Daten aus der DB gelesen und im Cache Vollständig gehalten lediglich Transaktionen werden direkt über eine weiter Schnittstelle in der DB abgelegt.
Asyncron / Syncrone Replizierung nennt man das hier.

-> Die Anwendung ist nicht zwingend abhängig vom Abschluss der Transaktion prüft dieses jedoch ab und an mal wieder nach und aktualisiert diese bei bedarf.

Das schnellste Verfahren um überhaubt, das erlaubt uns ja eine extrem hohe Transaktionsverwaltung und bietet dem endkunden einen gleich "langsamen" Webauftritt.

In jedem Fall muß man solche Downtime-Vermeidungsstrategien im Konzept vorsehen. Nachträglich reinpfriemeln dürfte schwierig werden.

Sicher doch aber darum geht es ja eigentlich nicht.
Die Frage ist in wie weit man dem Enduser davon Bescheid gibt und zwar ganz am Anfang.

Wenn ich da an die Zeiterfassung bei einem unserer Kunden denke.
Man pflegt eine gute Stunde nseine Stunden eines Monats.
(Ich schreib e ja immer in mei Filofax und übertrage es hinterher in die Zeiterfassung.
Ein schönes Webinterface. Was pasierte kürzlich?
Klar die DB würde reindiziert.
Ich pflegte also 3 Stunden meine Daten. Ist halt ellen langsam und man muss jeden Handgriff auf eine andere Kostenstelle buchen.

Fertig. Ich wollte speichern. Was passiert?

Tut uns leid die DB wird gerade reindiziert.
Versuchen Sie es doch in 60 Min. wieder.
Tja aber in 5 Minuen läuft meine Session ab.
3 Stunden arbeit für die Katz *argh*

Und wenn sowas dann tatsächlich notwendig wird, ist eine Ankündigung sicherlich nicht verkehrt. Nur bitte entsprechend dezent. Popups und Alertboxen sind nicht förderlich. Das erzeugt dann eher das Gefühl, man habe es irgendwie mit einer Beta-Version zu tun, wenn man so eindringlich vor der Benutzung gewarnt würde.

Naja Popups sind ja auch keine schöne Lösug aber es sollte so erkennbar sein, dass man eben gleich von vornherein sieht.
Ja ok gucken kann man aber ales andere mach ich später.

Aber sind wir doch mal ehrlich. Das meiste was man in solchem Stil an Software hat sind ohnehin nur Betaversionen und der Endanwender ist der Betatester. Nur leider weiss das keiner.

Gruss Matze