marabunta
Goto Top

Ist eine VM Live Migration ein Change?

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-ID: 3554338354

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

Printed on: December 9, 2024 at 03:12 o'clock

Mystery-at-min
Mystery-at-min Aug 05, 2022 at 13:48:31 (UTC)
Goto Top
Wie immer, es kommt drauf an. Durchaus kann es ein Informations-relevanter Change sein.
MrCount
MrCount Aug 05, 2022 at 13:57:11 (UTC)
Goto Top
Servus,

besser 1x zu viel informiert als 1x zu wenig face-wink
2423392070
2423392070 Aug 05, 2022 at 14:02:07 (UTC)
Goto Top
Definiere Change.
Marabunta
Marabunta Aug 05, 2022 at 16:03:40 (UTC)
Goto Top
kein ITIL Prozess. Ein Wunsch bei Änderung am produktiv System infomiert zu werden.
it-fraggle
it-fraggle Aug 05, 2022 updated at 19:14:29 (UTC)
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.
Snowman25
Snowman25 Aug 05, 2022 at 20:04:16 (UTC)
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...)
137960
137960 Aug 06, 2022 at 09:05:55 (UTC)
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.
Penny.Cilin
Penny.Cilin Aug 06, 2022 at 11:00:53 (UTC)
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.
Marabunta
Marabunta Aug 06, 2022 at 18:32:02 (UTC)
Goto Top
deshalb meinte ich es geht hier nicht um itil
Snowman25
Snowman25 Aug 06, 2022 at 18:43:37 (UTC)
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.
137960
137960 Aug 08, 2022 at 13:34:38 (UTC)
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".
2423392070
2423392070 Aug 08, 2022 at 15:40:51 (UTC)
Goto Top
Was Post #4 wieder in den Vordergrund rückt.