Ist eine VM Live Migration ein Change?

Servus,

besser 1x zu viel informiert als 1x zu wenig

Definiere Change.

Wenn es automatisch passiert, weil es so konfiguriert wurde, dann tendiere ich zu nein, weil du am System selbst nichts änderst, sondern eine bestehende Konfiguration ihre Arbeit macht. Wenn du es aber mit der Hand selber machst, dann verstehe ich schon einen Change darunter.

Ein Change ist m. M. n. eine Änderung eines Systems, die jemand vornimmt.

Change, falls durch den neuen Host Änderungen im Verhalten des Systems auftauchen.
z.B.: Angeschlossenes USB-Gerät am Host (ist nach Neustart weg)
oder: Highspeed-Anwendung, welche anfällig gegenüber winzigsten Verzögerungen ist (Highspeed-Trading, etc...)

"teilweise automatisch" impliziert "teilweise manuell". Also wird wohl irgendwer irgendwann einmal gefordert haben, dass "A nach B migriert wird".
Das nennt man auf ITIL-Sprech wohl "Change", denn es wird ja etwas geändert und jemand hat einen "Request for Change" eröffnet.

Man kann sich jetzt noch überlegen, ob alle einzelnen Migrationen in einem RfC auftauchen und deshalb alles einzelne "Changes" sind, oder ob der Prozess selbst der eigentliche Change ist. Der wird dann einmalig definiert und nur wenn man den Prozess der Migration anpasst, würde wieder ein RfC fällig.

Wenn der Informationsfluss an einem Change hängt, dann kommt man mit der letzteren Methode besser weg, weil die Empfänger der Informationen einmal am Anfang informiert werden ("es gibt eine regelmäßige Migration von A nach B") und allenfalls bei Änderungen als "stake holder" bei RfC eingebunden werden. Oder halt bei Störungen (Incidents) informiert werden.

Sollten die Migrationen allerdings immer manuell angestossen werden und nicht z.B. zeitbasiert automtatisch, dann würde ich jedesmal einen neuen Informationsaustausch erwarten.

Letztendlich kommt's drauf an, was IHR als Change definiert habt. Ob ihr nahe an ITIL oder ITSM seid oder eigene Definitionen nutzt bzw. wer wem bei was zu berichten hat.

Moin,

was gibt den die Prozeßbeschreibung her?
Ohne Prozeßbeschreibung ist die Diskussion sinnlos.
Wurde dieser Prozeß den definiert, dokumentiert und im Unternehmen veröffentlicht.

Prozesse, welche nicht dokumentiert und veröffentlicht sind, existieren nicht!

P.S. Die Diskussion haben wir im IT-Unternehmen permanent. Jede Führungskraft faselt von Prozessen und deren Einhaltung. Wenn man nachfragt, wie dieser Prozeß heißt und wo er veröffentlicht ist. Schweigen im Walde.

Das antworte ich jeder Führungskraft, wenn diese mit Prozessen anfängt. Wie heißt der Prozeß und wo ist dieser dokumentiert und veröffentlicht, damit sich jeder IT-Mitarbeiter im Unternehmen daran orientieren / halten muss?

Einer der ganz wenigen Prozesse, welche bei uns als Prozeß dokumentiert ist, ist der Changeprozeß. Und wie dieser funktioniert (Vorplanung, Feinplanung, Implementierung, Evaluation). Aber GENAU nicht wann ist was ein Change.
ich habe schon ein paarmal angesprochen, daß ein Serverneustart ein Change ist, weil sich der Betriebszustand bzw. die Verfügbarkeit des Servers ändert. D.h. ein Server darf OHNE Change nicht neu gestartet werden.

Gruss Penny.

Dann ein klares "Nein", weil nichts ein Change ist, was ihr nicht selbst definiert habt.

Zu der These, dass es kein Prozess sei, wenn der nicht dokumentiert ist:
Auch Prozesse, die nicht niedergeschrieben sind, sind Prozesse. Man kann sie schließlich nachdokumentieren. "Gelebte Prozesse" oder solche, die sich aus konkludentem Verhalten ergeben, fallen auch darunter.

Zu der Aussage, dass es nicht um ITIL geht: es gibt auch andere Frameworks. Wenn allerdings kein (bekanntes/definiertes) Framework benutzt wird und das Unternehmen den freien Begriff "Change" nicht definiert hat, dann kann man sich weitere Diskussionen sparen. Dann klingt auch die Eingangsfragestellung eher nach "Buzzwordwerfen".