View source for I cinque errori più comuni del Open Source IT Manager

== Sbaglio #1: Essere reattivi e non proattivi ==
 

Lo sbaglio piu pericoloso che un amministratore di sistema rischia di commettere è di tenere nei confronti delle emergenze un atteggiamento reattivo e non proattivo. In termini pratici ciò si traduce, ad esempio, nellessenza di un preciso piano operativo che permetta di far fronte a specifici problemi hardware, disastri naturali o software danneggiati sia per cause esterne che per mancanza di cura/attenzione degli utenti interni. Se la risoluzione delle emergenze è la routine quotidiana dellamministratore di sistema, è evidente la mancanza di un piano per prevenire situazioni pericolose. Inoltre, in termini di risorse finanziarie ed umane impiegate, è molto piu costoso risolvere un problema piuttosto che prevenirlo. Dal punto di vista software, inoltre, lamministratore di un sistema Open Source deve affrontare un altro tipo di problema, ossia scegliere applicativi che siano supportati da una comunitá folta e attiva. Sebbene ci siano progetti estremamente affidabili come Samba e Apache, bisogna ricordare che per i progetti Open Source (ad esempio quelli pubblicati su SourceForge) esiste una mortalitá infantile piuttosto elevata. Dal punto di vista hardware si rammenta limportanza di scegliere prodotti con una elevata prospettiva di vita e ben supportati, senza dimenticare come il rilascio da parte del produttore del codice del kernel (oppure la sua esaustiva documentazione) sia sicuramente un vantaggio per evitare situazioni di lock-in oppure mancato supporto futuro.


== Sbaglio #2: trascurare limportanza della documentazione e delladdestramento ==

Il problema che affligge buona parte degli amministratori di sistema è riconducibile alla scarsa documentazione tecnica che viene prodotta. Normalmente ciò è causato proprio dallo sbaglio #1 in quanto il fatto di dover risolvere continuamente delle emergenze priva lamministratore di sistema del tempo necessario per lasciare traccia delle modifiche o migliorie apportare sia a livello hardware che software. Molto spesso informazioni vitali come liste password, informazioni di sicurezza o regole di firewalling vivono con lamministratore invece di essere trascritte e custodite in un luogo unico e custodito. Il problema si acuisce e normalmente degenera in una situazione quasi incontrollabile nel momento in cui avviene una sostituzione dellamministratore di sistema, in quanto il nuovo personale deve necessariamente spendere molto tempo per ricostruire a ritroso sia la configurazione dei sistemi che le procedure di funzionamento.


== Sbaglio #3: imprecisione nellidentificare punti di forza e di debolezza ==

Molto spesso lamministratore di sistema deve valutare scelte di make or buy, ossia se tenere lo sviluppo di un progetto allinterno dellazienda oppure se affidarsi ad un soggetto esterno in outsourcing. Questa è una situazione molto delicata soprattutto in presenza di software Open Source, dato che questo tipo di software per sua natura intrinseca permette a chiunque di apportare modifiche ed effettuare sperimentazioni sul codice. Ad ogni modo, la presenza di questa possibilitá non significa automaticamente la presenza della corrispondente capacitá tecnica necessaria per apportare tali modifiche, dato che esse dipendono molto anche dallesperienza accumulata su un determinato software. Di conseguenza, è molto importante da parte dellamministratore di sistema saper valutare in maniera imparziale se il proprio team è in grado di sostenere lo sviluppo di un applicativo oppure se non sia meglio esternalizzarlo.


== Sbaglio #4: Migrazione troppo intensa e troppo rapida ==

Sebbene la scelta di migrare verso sistemi Open Source sia ammirevole, bisogna sottolineare come la transizione dovrebbe essere compiuta con gradualitá per evitare ripercussioni sulla produttivitá degli utenti. In generale, ogni cambiamento a livello di sistemi informatici (anche il minimo upgrade) ha potenzialmente un effetto destabilizzante a causa di incompatibilitá, bug vari e non ultimo la mancata accettazione da parte degli utenti. Ad esempio, prima di rendere Firefox il browser standard a livello aziendale bisogna accertarsi che esso non crei problemi nella visita di siti che sono essenziali per lo svolgimento dellattivitá lavorativa degli utenti. Allo stesso modo, Open Office è sicuramente un ottimo prodotto ma e meglio analizzare con anticipo limpatto che un cambiamento di formato dei file può avere sia verso lesterno dellazienda e sia nei confronti dei file creati in passato.


== Sbaglio #5: la sicurezza come obiettivo secondario ==

Un mito che deve essere in parte sfatato è che i sistemi Linux e in generale tutto il software Open Source sia sicuro di default. E indubbio come il software OS sia costruito su basi più solide rispetto a quello proprietario, ma ciò non garantisce automaticamente un migliore livello di sicurezza. Non ci stiamo riferendo solo allinstallazione immediata di patch o di regole di firewalling molto restrittive, ma anche e soprattutto allaccesso fisico ai locali dove sono custoditi i server. Provvedere al rinnovo automatico delle password ogni 4 settimane è sicuramente una buona politica aziendale, ma che avrá un effetto limitato sulla sicurezza se esistono in azienda e sono facilmente accessibili terminali dove il root user viene normalmente lasciato in sessione attiva. Infine, non è da sottovalutare la possibilitá di rivolgersi a professionisti della sicurezza per far testare i propri sistemi periodicamente anche tramite attacchi simulati dallesterno.

-- 

[http://www.happylinux.it/index.php?option=com_content&task=view&id=218&Itemid=2 Fonte]