Ist eine VM Live Migration ein Change?

marabunta
Goto Top
Hallo,

wenn eine Abteilung für Server x bei produktiven Änderungen informiert werden soll, gilt dies dann auch für Live-Migrationen von Host A zu Host B?
Ich würde so eine nicht spürbare Grundfunktion, die teilweise automatisch passiert nicht als Change bzw. Informationsrelevant für die Abteilung betrachten.

Stimmt ihr zu?

Danke

Content-Key: 3554338354

Url: https://administrator.de/contentid/3554338354

Ausgedruckt am: 19.08.2022 um 10:08 Uhr

Mitglied: Mystery-at-min
Mystery-at-min 05.08.2022 um 15:48:31 Uhr
Goto Top
Wie immer, es kommt drauf an. Durchaus kann es ein Informations-relevanter Change sein.
Mitglied: MrCount
MrCount 05.08.2022 um 15:57:11 Uhr
Goto Top
Servus,

besser 1x zu viel informiert als 1x zu wenig face-wink
Mitglied: unbelanglos
unbelanglos 05.08.2022 um 16:02:07 Uhr
Goto Top
Definiere Change.
Mitglied: Marabunta
Marabunta 05.08.2022 um 18:03:40 Uhr
Goto Top
kein ITIL Prozess. Ein Wunsch bei Änderung am produktiv System infomiert zu werden.
Mitglied: it-fraggle
it-fraggle 05.08.2022 aktualisiert um 21:14:29 Uhr
Goto Top
Zitat von @Marabunta:
Ich würde so eine nicht spürbare Grundfunktion, die teilweise automatisch passiert nicht als Change bzw. Informationsrelevant für die Abteilung betrachten.

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.
Mitglied: Snowman25
Snowman25 05.08.2022 um 22:04:16 Uhr
Goto Top
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...)
Mitglied: yoppi1
yoppi1 06.08.2022 um 11:05:55 Uhr
Goto Top
"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.
Mitglied: Penny.Cilin
Penny.Cilin 06.08.2022 um 13:00:53 Uhr
Goto Top
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.
Mitglied: Marabunta
Marabunta 06.08.2022 um 20:32:02 Uhr
Goto Top
deshalb meinte ich es geht hier nicht um itil
Mitglied: Snowman25
Snowman25 06.08.2022 um 20:43:37 Uhr
Goto Top
Zitat von @Marabunta:

deshalb meinte ich es geht hier nicht um itil

Dann ein klares "Nein", weil nichts ein Change ist, was ihr nicht selbst definiert habt.
Mitglied: yoppi1
yoppi1 08.08.2022 um 15:34:38 Uhr
Goto Top
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".
Mitglied: unbelanglos
unbelanglos 08.08.2022 um 17:40:51 Uhr
Goto Top
Was Post #4 wieder in den Vordergrund rückt.