NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux Einfuhrung in die System-Administration - So viel wie m�glich kommunizieren
Red Hat Enterprise Linux 4: Einf�hrung in die System-Administration
Wenn es um Benutzer geht, k�nnen Sie niemals zu viel kommunizieren. Seien Sie sich bewusst, dass die winzigen System�nderungen, die f�r Sie fast unmerklich erscheinen, vielleicht jemanden in einer anderen Abteilung v�llig verwirren k�nnen.
Die Art und Weise, auf die Sie mit den Benutzern kommunizieren, unterscheidet sich von Unternehmen zu Unternehmen. Einige Unternehmen verwenden E-Mail, andere eine interne Webseite. Wieder andere verlassen sich vielleicht auf Usenet oder IRC. F�r manche ist vielleicht ein Blatt Papier an einem Mitteilungsbrett in der Gemeinschaftsk�che praktikabel. Egal wie, verwenden Sie die Methode, die am besten in Ihrem Unternehmen funktioniert.
Im allgemeinen wird empfohlen, dem folgenden Ansatz, der f�r das Schreiben von Zeitungsartikeln verwendet wird, zu folgen:
Sagen Sie den Benutzern, was Sie machen werden
Sagen Sie den Benutzern, was Sie gerade machen
Sagen Sie den Benutzern, was Sie gemacht haben
Im folgenden Abschnitt werden diese Schritte eingehender beschrieben.
1.3.1. Sagen Sie den Benutzern, was Sie machen werden
Stellen Sie sicher, dass Sie den Benutzern gen�gend Warnung vor irgendwelchen �nderungen geben. Die eigentliche Frist h�ngt davon ab, was genau durchgef�hrt werden soll (das Aktualisieren eines Betriebssystems erfordert mehr Vorwarnung als das �ndern des Bildschirmhintergrunds)
Als absolutes Minimum sollten Sie beschreiben:
Die Art der �nderung
Wann die �nderung durchgef�hrt wird
Warum dies durchgef�hrt wird
Wielange dies dauern wird
Die Auswirkungen (wenn �berhaupt), die aufgrund der �nderungen zu erwarten sind
Kontaktinformationen, sollten Fragen oder Bedenken auftreten
Hier eine hypothetische Situation. Die Finanzabteilung hatte Probleme mit einem langsamen Datenbankserver. Sie fahren den Server herunter, aktualisieren das CPU-Modul und booten neu. Sobald dies durchgef�hrt ist, verschieben Sie die Datenbank auf einen schnelleren, RAID-basierten Speicher. Hier ist ein Beispiel f�r das Mitteilen dieser Situation:
System-Downtime geplant f�r Freitag Nacht
Diesen Freitag ab 18.00 Uhr (17.00 Uhr f�r unsere Gesch�ftsstellen in London) stehen alle Finanz-Applikationen f�r einen Zeitraum von vier Stunden nicht zur Verf�gung.
Innerhalb diesen Zeitraums werden �nderungen an der Hardware und Software auf dem Finanz-Datenbank-Server durchgef�hrt. Diese �nderungen sollten die Zeit f�r das Ausf�hren der Kreditoren- und Debitoren-Applikationen und Bilanzen erheblich beschleunigen.
Abgesehen von den �nderungen in der Runtime sollten keine weiteren �nderungen festgestellt werden. Diejenigen von Ihnen, die eigene SQL-Queries erstellt haben, sollten sich jedoch bewusst sein, dass das Layout einiger Indexe ge�ndert wird. Dies wird im Firmen-Intranet auf der Finanzseite dokumentiert.
Haben Sie Fragen, Kommentare oder Bedenken, dann kontaktieren Sie bitte die Systemadministration unter Durchwahl 4321.
Einige Punkte sollten beachtet werden:
Geben Sie Startzeit und Dauer einer Downtime als Teil der �nderungen effektiv bekannt.
Stellen Sie sicher, dass der Zeitpunkt der �nderung so bekanntgegeben wird, dass dies f�r alle Benutzer sinnvoll ist, egal wo diese sich gerade befinden.
Verwenden Sie Begriffe, die jeder verstehen kann. Die betroffenen Kollegen interessiert h�chstwahrscheinlich nicht, dass das neue CPU-Modul 2 GHz und doppelt soviel L2-Cache hat oder das die Datenbank auf einem RAID 5 Logischem Volumen gespeichert wird.
1.3.2. Sagen Sie Benutzern, was Sie gerade machen
Dieser Schritt ist haupts�chlich eine kurzfristige Warnung vor der direkt bevorstehenden �nderung; die Mitteilung sollte kurz die erste Nachricht zusammenfassen und die bevorstehende �nderung st�rker hervorheben ("Die Systemaktualisierung findet HEUTE NACHT statt"). An dieser Stelle k�nnen Sie auch �ffentlich alle Fragen, die eventuell eingegangen sind, beantworten.
Als Fortsetzung unseres hypothetischen Beispiels hier eine m�gliche kurzfristige Warnung:
System-Downtime heute Nacht
Erinnerung: Die am letzten Montag angek�ndigte System-Downtime wird wie geplant um 18.00 Uhr durchgef�hrt (17.00 f�r die Gesch�ftsstelle in London). Die urspr�ngliche Ank�ndigung befindet sich im Firmenintranet auf der Seite der Systemadministrationen.
Mehrere Kollegen haben angefragt, ob sie heute fr�her Feierabend machen sollen, um sicherzustellen, dass deren Arbeit vor der Downtime gesichert wird. Dies ist nicht n�tig, da die Aktualisierungen die Arbeit auf Personal Workstations nicht beeinflussen.
Denken Sie daran, dass f�r diejenigen, die ihre eigenen SQL-Queries geschrieben haben, sich das Layout einiger Indexe �ndert. Dies wird auf der Finanzseite im Firmenintranet dokumentiert.
Die Benutzer wurden gewarnt; Sie k�nnen jetzt die eigentliche Arbeit ausf�hren.
1.3.3. Sagen Sie den Benutzern, was Sie gemacht haben
Nachdem die �nderungen ausgef�hrt wurden, m�ssen Sie Ihren Benutzern mitteilen, was Sie gemacht haben. Dies sollte wiederum eine Zusammenfassung der vorhergehenden Nachrichten sein (h�chstwahrscheinlich gibt es ein paar Leute, die diese nicht gelesen haben.)[1]
Es gibt jedoch einen wichtigen Zusatz, den Sie hinzuf�gen m�ssen. Es ist wichtig, dass Sie den Benutzern den aktuellen Zustand mitteilen. Lief die Aktualisierung nicht so wie geplant? Konnte der neue Server nur die Systeme in Engineering versorgen und nicht die in Finanzen? Diese Art von Problemen m�ssen hier angesprochen werden.
Unterscheidet sich der aktuelle Status von dem vorhergesagten Status, sollten Sie dies hervorheben und beschreiben, was zum Erreichen des eigentlichen Ziels durchgef�hrt wird.
In dieser hypothetischen Situation traten w�hrend der Downtime Probleme auf. Das neue CPU-Modul funktionierte nicht, ein Anruf beim Hersteller zeigte, dass f�r diese Upgrade eine spezielle Version des Moduls ben�tigt wird. Auf der positiven Seite verlief die Migration der Datenbank zum RAID-Volume gut (auch wenn dies etwas l�nger als geplant dauerte, aufgrund der Probleme mit dem CPU-Modul).
Hier eine Beispiel-Ank�ndigung:
System-Downtime abgeschlossen
Die f�r letzten Freitag geplante System-Downtime (siehe Webseite der Systemadministration im Firmenintranet) wurde abgeschlossen. Leider verhinderten Probleme mit der Hardware das Ausf�hren einer Aufgabe. Aufgrund dessen dauerten die anderen Aufgaben l�nger als die eigentlich geplanten vier Stunden. Alle Systeme liefen wieder wie geplant um Mitternacht (23.00 Uhr in London).
Aufgrund der weiterhin bestehenden Hardware-Probleme ist die Leistung der Debitoren- und Kreditoren-Applikationen sowie die Bilanzfunktion leicht verbessert, jedoch nicht im geplanten Ausma�. Eine zweite Downtime ist geplant, sobald alle Probleme, die die bisherige Ausf�hrung der Aufgaben verhindert haben, gel�st wurden.
Bitte beachten Sie, dass die Downtime einige Datenbank-Indexe ge�ndert hat; Diejenigen, die ihre eigenen SQL-Queries geschrieben haben, sollten die Finanzseiten im Firmenintranet pr�fen.
Sollten Sie Fragen haben, kontaktieren Sie bitte die Systemadministration unter Durchwahl 4321.
Durch diese Informationen erhalten die Benutzer gen�gend Hintergrundwissen, um deren Arbeit fortzusetzen und zu verstehen, inwieweit sie von den �nderungen betroffen sind.
Stellen Sie sicher, dass Sie die Nachricht so schnell wie m�glich nach durchgef�hrter �nderung senden. Auf jeden Fall noch bevor Sie nach Hause fahren. Sobald Sie n�mlich das B�ro verlassen haben, ist es viel zu einfach, dies zu vergessen und Sie lassen damit die Benutzer im Dunkeln, ob diese das System benutzen k�nnen oder nicht.
