..."Ich meine, man kann auch mit bescheidenen Mitteln Tag und Nacht Logfiles schreiben. Ich würde es vielleicht nicht 24x7x365 nennen, aber evtl reicht ja x363. Das die letzten Prozent oder Promille von irgendwas in der EDV oft nicht lineare Kostensteigerungen bedeuten, ist ja doch den meisten klar."...
Exakt so argumentiere Ich auch!
- ...und setze mich so absichtlich oft in die Nesseln, weil ich eben absichtlich keine "99,9999..% Garantien" gebe, und nur mit dafür aber zumindest technisch/statistisch realisitischen Wahrscheinlichkeiten von ~98% argumentiere... wenn ein Kunde (bzw. dessen IT) sowas im Konsens auch so sieht und selbst zum "Restrisiko" ein technisch vernünftiges Konzept mitträgt und so beauftragt, werde ich im WorstCase den Kunden im Rahmen aller unserer technischem Möglichkeiten nicht hängen lassen!
- ... bei wieder besseres/dokumentiertes Wissen absichtlich so gewollten Sparbrötchen-Lösungen würde ich zwar selbst abunzu gerne "Nein" sagen, aber wenn der Kunde einen passenden Vertrag ohne "Garantien unsererseits" unbedingt so will, dann soll es eben so sein. WorstCase wird es dann aber sehr teuer und dauert eventuell sehr lange wenn unsererseits dann Lösungen "auch nur versucht" werden
Für unsere Kunden erarbeiten wir stets "Ergebnis offen" gemäß der "wirklichen Bedürfnisse" ein technisch vernünftiges Konzept... (Von "HighEnd" mit ClusterDB + ClusterOS + ClusterVMs + mehrfach redundanter PC & Netzwerkhardware bis "LowEnd" nur mit StreamingClient->FiFoBuffer->Single(
DB)Server)... wenn ein Kunde uns das zahlt, ist es uns sogar egal ob er das dann mit uns realisiert, oder es extern vergibt.
..."Einen robusten Client mit Buffering zu haben, ist natürlich auch nicht verkehrt. Der ist offenbar nicht vorhanden und damit keine Sofortlösung."...
=> jo, aber aus meiner Sicht wäre dies unter Berücksichtigung aller gegebenen Info mit dem sturem Serverbetreiber hier eine der wohl "technisch sinnvollsten" Lösungen