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 - Documentare ogni cosa

1.2. Documentare ogni cosa

Se vi viene data la possibilit� di installare un server nuovo o scrivere un documento sulle procedure su come eseguire i backup del sistema, l'amministratore di sistema medio sceglier� sempre di installare un server nuovo. � fortemente consigliato di documentare sempre quello che fate. Molti amministratori non documentano quello che fanno a causa di svariati motivi:

"Lo far� pi� tardi."

Sfortunatamente, questo non accade quasi mai. Infatti la natura dei compiti che un amministratore deve affrontare, � cos� caotica che in molti casi � impossibile "rinviare". Anccora peggio, pi� si aspetta, e pi� facilmente si dimentica, creando cos� una documentazione non molto dettagliata (e quindi quasi inutile).

"Perch� scrivere tutto? � pi� semplice ricordare."

A meno che non siate uno di quei pochissimi individui con una memoria fotografica, non sarete in grado di ricordare tutto. O peggio ancora, ne ricorderete solo la met�, senza sapere di aver perso l'intera storia. Ci� ne scaturisce una perdita di tempo nel cercare di ricordare quello che avete dimenticato o di correggere quello che avete scritto.

"Se lo terr� nella mia mente, non possono licenziarmi — sicurezza del posto di lavoro!"

Anche se questa tattica potr� essere valida per un p� di tempo — essa non risulta — essere molto sicura. Cercate di pensare per un momento cosa possa succedere durante una emergenza. Voi potreste non essere reperibili; la vostra documentazione potrebbe risultare importante permettendo ad un'altra persona di risolvere il problema durante la vostra assenza. In questi casi, � meglio avere la vostra documentazione in modo da risolvere il problema, che notare la vostra assenza e annoverarla come una delle cause del problema.

In aggiunta, se fate parte di una piccola organizzazione in continua crescita, sar� possibile che la stessa abbia bisogno di un nuovo amministratore. Come potete aspettarvi che questo nuovo amministratore possa sostituirvi se mantenete tutte le informazioni nella vostra testa? Ancora peggio, se non documentate niente, potr� essere richiesta sempre la vostra presenza, 'sareste indispensabili', in modo da intaccare la vostra carriera e quindi le vostre promozioni a compiti dirigenziali. Potreste trovarvi a svolgere il lavoro della persona assunta per assistervi nel vostro incarico.

Si spera che adesso abbiate capito l'importanza di una documentazione. Ci� ci porta a formulare un'altra domanda: Cosa documentare? Ecco un breve elenco:

Policy

Le policy vengono scritte per ufficializzare e chiarire la relazione che intercorre tra voi e la community dei vostri utenti. Esse chiariscono ai vostri utenti come le richieste sulle risorse vengano assistite e gestite. La natura, lo stile, ed il metodo di diffusione delle policy per la vostra community varia da organizzazione a organizzazione.

Procedure

Le procedure non sono altro che una sequenza di azioni passo dopo passo da intraprendere per poter completare un compito. Le procedure da documentare possono includere le procedure di backup, quelle di gestione dello user account, inerenti le problematiche nel riporto delle procedure, e cos� via. Come l'automazione, se una procedura viene seguita pi� di una volta, � consigliabile documentarla.

Modifiche

Gran parte della carriera di un amministratore di sistema ruota intorno alle modifiche — alla configurazione dei sistemi per massimizzarne le prestazioni, alle modifiche dei file di configurazione, agli script e cos� via. Tutte queste modifiche devono essere documentate in qualche modo. In caso contrario, potreste trovarvi spiazzati a causa di una modifica eseguita in passato.

Alcune organizzazioni utilizzano metodi pi� complessi per registrare le suddette modifiche, ma in molti casi potrebbe essere solo necessario una semplice nota all'inizio del file modificato. Come minimo, ogni entry presente nella cronologia dovrebbe contenere:

  • Il nome o le iniziali della persona che ha eseguito la modifica

  • La data nella quale � stata eseguita la modifica

  • La ragione per la quale � stata apportata la modifica

Il risultato, e le entry pi� utili:

ECB, 12-Giugno-2002 — Entry aggiornata per nuove stampanti di contabilit� (per supportare l'abilit� di stampa duplex della stampante)

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