Nota Bene
I casi citati sono reali, ma non viene citata né l'azienda, né la soluzione individuata in mancanza di autorizzazioni dei diretti interessati.
Casi Aziendali
|
La responsabilità
Avendo io sollecitato e commissionato il progetto non posso che assumermi la totale responsabilità dell'insuccesso.
Resta l'amarezza non solo di questo, ma anche di non aver trovato nel Partner quella correttezza che ti porta a volte a rifiutare "un affare" se non ritieni di poter assolvere fino in fondo ai tuoi compiti.
Il Sistemista iniziale assolse quindi solo il ruolo di far "fatturare" un servizio in più. Il suo.
Breve Descrizione
Firewall interamente realizzati in ambiente Linux.
Contesto iniziale
La migrazione da una rete Frame Relay sostanzialmente chiusa ad una rete ADSL rendeva necessaria l'implementazione di Firewall locali in grado di attivare più VPN tra le sedi.
Le necessità di gestire gli accessi a Internet e la protezione a livello generale consigliavano una soluzione estremamente sicura ed affidabile.
Soluzione individuata
In accordo con il Business Partner si decise di implementare una soluzione basata su Linux ed anziché adottare degli apparati dedicati, si decise di rilevare un numero di PC ritenuti obsoleti per l'adozione da parte degli utenti, ma dalle caratteristiche ritenute invece sufficienti per implementare un Firewall.
La distribuzione Linux adottata era Debian, ritenuta molto più sicura ed affidabile di altre.
Evoluzione del progetto
Dopo una fase di analisi condotta da un Sistemista Senior, il progetto fu dato incarico dal Business Partner ad un suo tecnico Linux il quale però preferì adottare una distribuzione Suse, da lui meglio conosciuta.
Il progetto Pilota e la prima fase di implementazione in laboratorio diede ottimi risultati.
La successiva messa in produzione dell'intera rete di Firewall produsse solo dei disastri.
Alle linee che continuavano a cadere si cercò di porre rimedio aumentando la memoria del PC perché si riteneva fosse insufficiente per il numero di VPN attive.
In seguito si rilevarono problemi agli HD, attivi 24 ore su 24, tanto che si rese necessaria la loro sostituzione e, poi, anche la loro ridondanza con un secondo disco.
Infine si decise di predisporre dei muletti da inviare con tempestività presso la sede remota per ovviare ai vari blocchi che periodicamente si determinavano.
"Dulcis in fundo", ci si trovò pure nelle condizioni di un blocco delle linee per oltre 2 giorni senza che nessuno fosse in grado di determinarne le cause.
Risultato finale
Nonostante le ampie assicurazioni iniziali il Business Partner non riuscì a consolidare il progetto e persino un nuovo BP che ne prese il testimone riuscì a portarlo a termine felicemente.
Il progetto venne così abbandonato dopo pochi mesi per adottare dei firewall basati su apparati fisici.
Considerazioni finali
Come spesso accade il Business Partner non ha al suo interno le competenze per assicurare la copertura delle tecnologie che lui stesso offre per garantire anche la sua presenza nel Mercato IT.
Nel nostro caso risultò che il primo tecnico era un "freelance" con sì una significativa competenza su Linux e progetti di Firewall, ma non aveva mai implementato una rete di firewall tra loro connessi. Anche il secondo risultò essere un "freelance" che aveva, invece, una significativa competenza solo a livello di server Linux e nessuna a livello di firewall.
Anche se buona parte dei costi di intervento non venne mai riconosciuta ai due BP, i costi aziendali sostenuti non furono indifferenti.
Quello che sembravano inizialmente un minor costo si rivelò un costo indiretto assai elevato.
Per ovviare a incidenti analoghi si decise:
|