Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Introduzione al System Administration - Comunicare il pi� possibile

1.3. Comunicare il pi� possibile

Per quanto riguarda i vostri utenti, la comunicazione non � mai abbastanza. Fate attenzione che anche le pi� piccole modifiche che per voi potrebbero essere irrilevanti, possono essere motivo di confusione per la gestione del personale (Human Resources).

Il metodo attraverso il quale comunicate con i vostri utenti pu� variare a seconda della vostra organizzazione. Alcune organizzazioni usano le email, altre utilizzano un sito web interno, altre ancora possono affidarsi alle comunicazioni di rete o IRC. Potrebbe risultare sufficiente in questo contesto, l'utilizzo di un pezzo di carta da affiggere nell'area di ricreazione. In ogni caso, utilizzate qualsiasi metodo che ritenete pi� opportuno.

In generale, � consigliato seguire uno di questo consigli:

  1. Comunicate ai vostri utenti cosa farete

  2. Comunicate ai vostri utenti cosa state per fare

  3. Comunicate ai vostri utenti cosa avete fatto

Le seguenti sezioni affrontano queste fasi in maniera pi� dettagliata.

1.3.1. Comunicate ai vostri utenti cosa farete

Assicuratevi di avvisare i vostri utenti prima di fare qualcosa. Il tempo di preavviso per i vostri utenti varia a seconda del tipo di modifica (l'aggiornamento di un sistema operativo richiede un tempo di preavviso maggiore rispetto a quello necessario per la modifica del colore di default della scermata di login del sistema), e della natura della community dei vostri utenti (gli utenti pi� esperti possono essere in grado di gestire le modifiche molto pi� facilmente rispetto ad utenti meno esperti.)

Come minimo, � necessario descrivere:

  • La natura della modifica

  • Quando verr� messa in atto

  • Perch� � stata eseguita tale modifica

  • Il tempo necessario per tale modifica

  • L'impatto (se causato) che gli utenti possono aspettarsi a causa di tale modifica

  • Informazioni su chi contattare in caso di necessit�

Ecco una ipotetica situazione. La sezione responsabile alle finanze presenta alcuni problemi dovuti alla lentezza del proprio database. Voi disattiverete il server, aggiornerete il modulo CPU utilizzando cos� un modello pi� veloce, ed eseguirete successivamente un riavvio. Una volta aver seguito la suddetta procedura, appronterete il vostro database con uno storage basato sul RAID pi� veloce. Ecco cosa potreste fare per informare i vostri utenti:

Downtime del sistema previsto per venerd� notte

Inizio questo venerd� ore 18:00, tutte le applicazioni interessate non saranno disponibili per un periodo di circa quattro ore.

Durante il quale saranno apportate le modifiche all'hardware e al software del server del database in questione. Queste modifiche avranno lo scopo di diminuire il tempo necessario per eseguire le applicazioni del tipo Accounts Payable 'per la fatturazione passiva' e Accounts Receivable , ed i rapporti sull'attivit� settimanale.

Oltre alla modifica nel runtime, la maggior parte delle persone non dovrebbero notare altri cambiamenti. Tuttavia, coloro che hanno scritto le proprie richieste SQL, devono essere a conoscenza che la struttura di alcuni indici potrebbero essere stati modificati. Ci� viene documentato nell'intranet del sito web della compagnia, nella pagina inerente le finanze dell'azienda stessa.

Se avete delle domande, commenti o problematiche, si prega di contattare l'amministratore del sistema digitando l'interno 4321.

� importante notare:

  • Comunicate in modo effettivo l'inizio e la durata di ogni downtime che si pu� verificare a causa della modifica.

  • Assicuratevi d'informare in modo efficiente tutti gli utenti, sull'orario della modifica.

  • Utilizzate termini facili da capire. Alle persone coinvolte in questa modifica, non importa che il nuovo modulo CPU � una unit� di 2GHz con una cache L2 doppia, o che il database � stato posizionato su di un volume logico RAID 5.

1.3.2. Comunicate ai vostri utenti cosa state facendo

Questa fase � generalmente un avviso del tipo 'last minute' della modifica che st� per avvenire; pertanto dovrebbe essere una breve ripetizione del primo messaggio, rendendo pi� visibile la natura della modifica ("L'aggiornamento del sistema verr� eseguito QUESTA SERA."). Questo � anche il momento migliore per rispondere a qualsiasi domanda ricevuta a causa del primo messaggio.

Continuando il nostro ipotetico esempio, ecco un ultimissimo avviso:

Downtime del sistema previsto per questa sera

Ricordatevi. Il downtime del sistema annunciato questo Luned�, avverr� come privisto questa sera alle ore18:00.Potete trovare il messaggio originale nella pagina intranet del sito web della compagnia, nella pagina amministrativa del sistema.

Diverse persone hanno richiesto di poter terminare prima questa sera in modo da eseguire un backup del loro lavoro prima del periodo di downtime. Quest� non sar� necessario, in quanto il lavoro svolto questa sera non avr� alcun impatto su quello eseguito sulla vostra workstation personale.

Ricordate, coloro che hanno salvato le proprie richieste SQL, devono essere a conoscenza che la struttura di alcuni indici sar� cambiata. Ci� viene documentato nell'intranet della compagnia sulla pagina delle finanze.

I vostri utenti sono stati avvisati, adesso sarete in grado di svolgere il vostro lavoro.

1.3.3. Comunicate ai vostri utenti cosa avete fatto

Dopo aver finito le modifiche, dovete informare i vostri utenti su quello che avete fatto. Ancora una volta, questo dovrebbe essere un sunto dei messaggi precedenti (ci sar� sempre qualcuno che non li ha letti.) [1]

Tuttavia, vi � ancora un'aggiunta importante da fare. � vitale informare i vostri utenti dello stato attuale del sistema. L'aggiornamento non � stato molto semplice da eseguire? Il server dello storage era in grado di servire solo i sistemi della sezione d'ingegneria e non quelli delle finanze? Queste problematiche devono essere affrontate qui.

Ovviamente, se lo stato corrente differisce da quello comunicato precedentemente, dovrete allora descrivere le fasi da intraprendere per arrivare alla soluzione finale.

Nel nostro esempio, il periodo di downtime presenta alcuni problemi. Il nuovo modulo CPU non ha funzionato; una telefonata al rivenditore del sistema ha rivelato che � necessaria una nuova versione. Nell'altra ipotesi, la migrazione del database sul volume RAID ha avuto successo (anche se ha richiesto un tempo maggiore di quello previsto a causa dei problemi dovuti al modulo della CPU.)

Ecco una possibile comunicazione:

Periodo di downtime del sistema terminato

Il periodo di downtime previsto per venerd� sera (consultare la pagina di amministrazione del sistema presente nell'intranet della compagnia) � terminato. Sfortunatamente, alcune problematiche riguardanti l'hardware non hanno reso possibile il completamento di uno dei compiti previsti. A causa di ci�, i restanti compiti hanno avuto bisogno di un periodo pi� lungo di quello previsto. Tutti i sistemi sono tornati alla normalit� alla mezzanotte.

A causa delle restanti problematiche hardware, le prestazioni AP, AR e dei rapporti sui fogli di bilancio saranno leggermente migliorati ma non in modo previsto. Un secondo periodo di downtime verr� programmato e annunciato appena le problematiche sopra indicate saranno risolte.

Si prega di notare che il periodo di downtime ha effettivamente modificato gli indici del database; le persone che hanno salvato le loro richieste SQL, dovrebbero consultare la pagina inerente alle Finanze nell'intranet della compagnia.

Si prega di contattare l'amministratore all'interno 4321 per eventuali chiarimenti.

Con questo tipo di informazioni, i vostri utenti avranno elementi sufficienti per continuare il loro lavoro, e capire come i cambiamenti possano influenzare i loro compiti.

Note

[1]

Assicuratevi d'inviare questo messaggio subito dopo aver terminato il vostro lavoro, prima di tornare a casa. Una volta lasciato l'ufficio, � molto facile dimenticare, lasciando i vostri utenti nel dubbio se usare o meno il sistema.

 
 
  Published under the terms of the GNU General Public License Design by Interspire