StudiVZ Downtime

Würde ich für eine Dienstleistung wie die vom StudiVZ auch noch Geld zahlen, würde mir bei dem Gedanken an die andauernde Nicht-Erreichbarkeit spontan spei-übel werden. Der Server dieses OpenBC-Clones war in den letzten (subjektiv gefühlten) 1,5 bis 2 Tagen nicht erreichbar. Alles was darauf hinweist, dass irgendetwas im Argen ist, ist ein wohl nachträglich umgebogener DNS Eintrag auf das hauseigene Blog – wo ich eigentlich ein wenig mehr seriöse Inhalte erwarte als Partybilder. So langsam beschleicht mich das Gefühl, dass ich entweder komplett anders ticke, wenn ich eine Dienstleistung in Anspruch nehme, oder die meisten Nutzer der Plattform einfach nicht verstehen, dass soetwas einfach nicht läuft. Das geht nicht. Ich werde mich nicht wie die Masse der dort kommentierenden echten (oder vielleicht sogar unechten) User mit soetwas anfreunden. Deswegen hier die raren Tipps, mit welchen man aus der subjektiv empfundenen heißen Dampfdusche doch ins kalte Schwimmbecken zur Abkühlung springen kann.

Goldene Regeln für eine Umbauphase (vom Naseweis-Besserwisser)

  • Informiere deinen User schon lange im Voraus darüber, dass Du etwas am Basteln bist. Gegebenenfalls wird das mit einer E-Mail oder Systemnachricht erfolgen, aber nicht mit einer „Ooops, nun geht nimmer der DNS, der Server macht ein Timeout, ooops“ Meldung, die man sich noch selbst aus den Fingern saugen darf.
  • Auch wenn etwas Alpha, Beta oder pre-RC ist, heißt das nicht, dass man ein Live-System mit lustigen Programmzeilen kompromittiert, so dass eine Dienstleistung einfach mal weg ist.
  • Wenn etwas neues kommt, ist das natürlich schon durchgeprüft. Also belasse das System so wie es ist und schalte dann erst auf das neue schon mehrfach durchgetestete und überarbeitete System mit sämtlichen aktuellen Daten, sobald alles fertig ist und auch kein User in die Röhre gucken muss.
  • Mache dabei einen sauberen Übergang, denn eine temporäre Schließung der Registrierung oder Unterbindung der Erstellung von neuen Inhalten der Datenbank ist ja für eine kurze Zeit zu verschmerzen. Nur um Gottes Willen doch keine Blockade wie zu Kriegszeiten!

Was bleibt also? Viel Spaß beim Basteln. Seid mir bitte nicht böse, aber diese Aktion war einfach ein tiefer Griff ins Klo, liebe StudiVZ-Macher. Da bleibe ich wohl doch eher dabei, ein wenig mit OpenBC zu kuscheln… ist nicht so quietschig dort, da weiß man was man hat, und es ist doch eher Networking als Sandkastenkuscheln. Und bitte nicht von Web 2.0 sprechen, denn das war eher Web 0.5 wie damals, als wir die Stromkabel rausnahmen, um den Server aufzuschrauben und dort ein wenig Staub zu wischen. Sorry. SORRY!

11 Kommentare
  1. martin sagte:

    StudiVZ ist schon seit einiger Zeit wieder hölleschnell! Die Jungs dort scheinen das Problem gelöst zu haben. Ich bin sehr begeistert wie schnell jetzt alles geht. War schon schlimm mit der Downtime und den langsamen Seiten, aber das ist anscheinend vorbei.

  2. Suna sagte:

    leider funktioniert mein studivz nicht, wegen dem gleichen problem…wie es hier geschildert wird!und ich habe keine ahnung wie ich dieses loesen koennte…bin momentan im ausland und hier ist mein internetanschluss eh nicht der beste…aber ich glaube das es nicht an dem computer oder internetanschluss liegt sondern einfach an studivz, koennte das sein?

    hilfeee :)

    Lg

Trackbacks & Pingbacks

  1. […] zum Domaingrabbing und Piraterie, Kommunikationshemmnisse, Klonen und “Server Problem Chen” und die jüngste Darstellung durch die Berichterstattung in den traditionellen […]

  2. […] Many bloggers point out that there are other options available for keeping a site running – even through maintenance. They also criticise the communication regarding the maintenance (see Sichelputzer (I), Sichelputzer (II), Dittes (I), Dittes (II)). […]

  3. […] Dieser Morgen bescheerte mir einige Trackbacks zum Thema StudiVZ: Obstruse Verbindungen mit dem Völkischen Beobachter, Technorati Optimierungen (mittlerweile Platz 1), Domaingrabbing und Piraterie, Kommunikationshemmnisse, Klonen und “Server Problem Chen” und die jüngste Darstellung durch die Berichterstattung in den traditionellen Medien verheißt unheilvolles. […]

  4. […] StudiVZ is blaming their telephone company and their technical apparatus (see their blog here, here, here, here and here). They claim that nobody had expected such an amount of traffic and that they are now trying to work on the software and make it leaner. But the bloggers criticise that there are other options available for keeping a site running even through maintenance. Many bloggers also criticise the communication regarding the maintenance (see Sichelputzer (I), Sichelputzer (III), Dittes (I), Dittes (II)). […]

  5. […] Eigentlich fand ich die Idee damals sehr schick, dass ich eine inhaltliche Trennung von beruflichen Kontakten via OpenBC auch von den studentischen Kontakten mit dem StudiVZ durchziehen konnte. Die ersten Probleme schlugen natürlich auch auf, es waren jedoch rein technische Gründe weshalb diese Serverproblemchen zu Buche schlugen. […]

  6. […] Ganz klipp und klar gesagt: Den Reload Trick hat man ja sowieso drauf, falls etwas ein wenig komisch dargestellt wird. Nebenbei kann man ja auch seinen Browser so konfigurieren, dass er jede Datei jedes Mal aus dem Internet zieht und sich keiner Version aus dem Cache bedient. Doch dass man immer wieder darauf hingewiesen wird, dass man sich erneut einloggen soll und dass anscheinend nebenbei am Server aktiv gearbeitet wird… soetwas entzieht sich wieder einmal des guten Menschenverstandes. Es tut mir echt leid, aber auch wenn etwas am Server brennt, bitte schaltet auf eine “Temporarily Down” Seite und gut ist. Keine Arbeiten am Live System, wenn der Nutzer noch zugreifen kann. Keine Arbeiten am Live System! Das hatte ich doch vor ein paar Tagen schon einmal gesagt. Nebenbei gab es eine schöne HTML Kommentar Meldung im Stil von “site down on purpose” – na lecker. […]

Kommentare sind deaktiviert.