mit 455 Km erster Werkstattbesuchmit dem Mokka beim FOH

was war jetzt das Problem?also war es doch nicht die Wasserpumpe.

Tja, dann war es doch mal wieder der Simmerring. Ist doch immer wieder interessant, dass man bei Opel tatsächlich nicht weiß in welche Modellreihen man den Schrott überall eingebaut hat. Überhaupt will ich nicht begreifen, was man an dem Simmerring noch verbessern wollte. Der alte Simmerring bereitete doch überhaupt keine Probleme. War wohl eine Arbeitsbeschaffungsmaßnahme? Altbewährtes muss von jungen Dipl.-Ing. unbedingt verworfen werden.

Zitat von squeakysheep

Tja, dann war es doch mal wieder der Simmerring. Ist doch immer wieder interessant, dass man bei Opel tatsächlich nicht weiß in welche Modellreihen man den Schrott überall eingebaut hat. Überhaupt will ich nicht begreifen, was man an dem Simmerring noch verbessern wollte. Der alte Simmerring bereitete doch überhaupt keine Probleme. War wohl eine Arbeitsbeschaffungsmaßnahme? Altbewährtes muss von jungen Dipl.-Ing. unbedingt verworfen werden.

Hallo squeakysheep,

vielleicht hat Opel einen anderen Hersteller für den Simmerring gefunden, der ihn billiger herstellt.

Das ist nicht auszuschließen. Beim 1.7 Dieselmotor gab es ganz kurze Zeit wegen Ölundichtigkeit, weil der Simmerring geändert wurde. Als die ersten Problemen auftraten wurde ganz schnell wieder zum alten Simmerring gegriffen. Dem Eigentümer des Astra konnte letztlich nur noch per Motortausch geholfen werden, die Dichtfläche auf der Kurbelwelle war zu sehr durch den Simmerring geschädigt worden, ein Wegpolieren dieser umlaufenden Kante brachte zuvor auch keinen Erfolg. Da kam auch die lapidare Info von einem Opel-Mitarbeiter "Da meinte wieder jemand den Simmerring neu erfinden zu müssen".

Einfach mal gut sein lassen, nicht immer alles ändern. Kostet nur unnötig Geld
Die EDV-Leute sagen auch immer "Never change a running system"

Zitat von squeakysheep

Die EDV-Leute sagen auch immer "Never change a running system"

Das kann ich als Servicetechniker nur bestätigen!
NEVER TUCH A RUNNING SYSTEM!

Der hier Folgende Text findet daher nur bedingt meine Zustimmung
Verschlimmbessern geht halt immer!

Der Leitsatz "Never change a running system" ist eine der am häufigsten missverstandenen IT-Empfehlungen überhaupt. Abgesehen davon, dass es sich um einen deutschen Pseudo-Anglizismus handelt (im angloamerikanischen Sprachraum nutzt man diesen Spruch nicht, sondern nur in Deutschland – ähnlich wie das Wort "Handy"), dient dieser Satz in der Regel dazu, ein fehlendes Patchmanagement für Betriebssysteme und Applikationen zu rechtfertigen. Berechtigt ist das praktisch nie.

Der Spruch leitet sich von der Sportweisheit "never change a winning team" ab. Jeder halbwegs fähige Trainer weiß aber, dass selbst das nur für sehr begrenzte Zeit gut geht, weil das Team dann eben nicht mehr gewinnt. Die Aufgabe eines guten Teamchefs besteht darin, sein Team weiterzuentwickeln, damit es besser wird oder zumindest seinen Status nicht verliert. Selbst die Mannschaft von Bayern München wird ständig umbesetzt, obwohl es mehr als den Meistertitel in der Bundesliga kaum zu gewinnen gibt.

Bei dieser falsch verstandenen und falsch angewandten Binsenweisheit geht es nicht darum, ein System nie zu patchen, weil es grundsätzlich läuft, also in Betrieb ist. Im Gegenteil geht es nur darum, ein System nicht in genau dem Moment in seiner Funktion zu verändern, in dem kritische Prozesse darauf von den Anwendern aktiv benötigt werden! Heißt also: Wartungsfenster definieren, statt einfach die Maschine zu patchen.

Aus Sicht der Sicherheit und Stabilität eines Systems kann es nur lauten: Patch your stuff! Nicht umsonst lautet die idiomatische Entsprechung zu unserem nicht so richtig englischen Sprichwort "if it ain't broke don't fix it" – wenn es nicht kaputt ist, dann repariere es nicht. Warum aber erscheinen Patches und Service Packs? Nur deshalb, weil im Herstellersupport festgestellt wurde, dass der ursprüngliche Code fehlerhaft ist. Das System ist also bereits kaputt – und daher muss es repariert werden!

Die richtige Einstellung ist also, ein aktives Patch- und Updatemanagement zu betreiben. Die technische Infrastruktur dafür existiert seit Jahren. Ein professionelles Patchmanagement in einem kleineren oder mittleren Unternehmen muss auch nicht ständig Arbeitskraft binden: Mit Virtualisierungs-Laboren lassen sich die kritischen Systeme schnell simulieren und die Auswirkungen von Patches und Service Packs prüfen. Läuft das Testsystem danach noch, kann der Patch produktiv eingesetzt werden. Da die meisten Patches deinstallierbar sind (bei den Ausnahmen ist dies in der Regel dokumentiert), ist auch das Fallback-Verfahren bekannt, es braucht nur eine gewisse Aufmerksamkeit.
entnommen: Logo faq-o-matic.net