Home

Advertisement

Me ne vado

  • Aug. 18th, 2007 at 10:03 AM

Alla fine ho seguito i consigli (anche se suonavano piu' come intimazioni) di Dani3l3 ed ho installato WordPress sul nostro server e sul mio sito. Di conseguenza scrivero' li' d'ora in poi (effettivamente ha anche piu' senso :)))

Il link al mio sito (e quindi al mio nuovo blog) diventa [questo]

Skype down?

  • Aug. 17th, 2007 at 8:02 AM

Qualcuno di voi si sara' probabilmente chiesto come mai non fosse possibile accedere a Skype nelle ultime... 36 ore. Stamattina per cercare di capire che succede con uno dei client di IM che piu' rapidamente si e' diffuso nel mondo, sono andato ad indagare. Non ci e' voluto molto in effetti per capirlo. In homepage c'era un annuncio che parlava di problemi legati all'accesso al sistema, problemi su cui stanno lavorando (stando al bollettino) in tutto il mondo dalle 14:00 GMT circa. L'ultimo aggiornamento di oggi risale alle 5.00 GMT. Pare che tutto sia derivante da una inefficienza di un algoritmo del client e non un attacco informatico. Questo e' consolante e rassicurante, ma come la possono prendere coloro che magari usano Skype per lavoro? Purtoppo per loro il problema non si pone visto che il software e' gratuito.

Al momento attuale il mio client sembra che stia riuscendo a collegarsi per qualche istante (anche se torna irrimediabilmente offline dopo qualche minuto) pero' la capacita' del gruppo di eBay/skype di lavorare per risolvere il problema cosi' celermente dimostra quanto il prodotto rappresenti una nuova dimensione di servizi online.
biohazard

Le reti aziendali crescono assieme (fortunatamente) alle aziende che cominciano a godere dei vantaggi derivanti dalla possibilita' di connettere, a costi ragionevoli, sedi geograficamente dislocate. VPN over Internet, connessioni dedicate o VPN realizzate sui backbone degli ISP... le scelte possibili sono tante con tanti vantaggi e svantaggi in ognuna di esse. L'unico fattore che tutt'ora accomuna le varie soluzioni e' la capacita' del canale trasmissivo. Prendiamo una qualsiasi linea ADSL in wholesale: enorme capacita' di banda in download, uno spiraglio minimo (256Kbps) per l'upload. Questa e' una caratteristica tecnica che puo' essere accettabile per un'azienda che deve navigare oppure (gia' meno) utilizzare i mezzi di messaggistica elettronica. Vediamo invece una necessita' puramente amministrativa: quale azienda non dispone di un sistema gestionale? Anche in questo ambito esistono soluzioni di diversa natura e concezione, eppure tutti hanno qualcosa in comune: il modello client/server (come del resto la stragrande maggioranza di applicazioni).

La cosa che maggiormente mi colpisce del modello "client/server" di oggi e' che pochi sembrano aver imparato qualcosa dal passato. Pensiamo un attimo ai terminali 3270 di IBM, detti anche "Display Device" utilizzato per l'accesso al sistema gestionale residente su Mainframe (server) su terminali stupidi utilizzando un programma testuale: Telnet (client). Un modello semplice in cui l'utente inseriva i dati o si aspettava dei dati sul proprio terminale trasmettendoli o ricevendoli dal server. Il modello e' eccellente ed e' costituito da tre stadi: il client in cui e' presente l'interfaccia utente, il server che effettivamente e' l'applicazione che elabora i dati provenienti dai client e li ritrasmette ad esso, e il database. La caratteristica fenomenale e' che decine di utenti potevano operare utilizzando delle connessioni ridottissime visto che la capacita' di banda utilizzata dai terminali era attorno al Kbps (si, uno) se non durante le fasi di stampa (che bello, all'epoca si inviavano dati ASCII alle stampanti ad aghi: 80 caratteri per ogni riga, piu' i codici CR ed LF oppure FF).

Oggi il modello e' "presuntuosamente" uguale, ma in realta' ha una pecca di fondo. Hanno eliminato uno strato dal modello precedente. Oggi il client e' un'interfaccia grafica (GUI) mentre il server e' brutalmente il Database. Client/Server. Giusto no?

No.

Il problema delle connessioni di rete e' che sono latenti e con capacita' ridotte. Le capacita' ampie sono tutt'ora onerose e giustificare la necessita' di una connessione 10Mbps per poter far accedere un utente al sistema gestionale e' praticamente una follia. Ricordiamoci anche che la velocita' di connessione tra due sedi connesse in VPN e' pari "alla velocita' massima della connessione piu' lenta". Tanto per capirci, se due sedi sono connesse tra di loro in VPN usando il backbone del ISP, parlando di connessioni Wholesale, anche ammettendo che sulla tratta non ci sia alcun traffico le sedi non potranno comunicare tra di loro a piu' di 256Kbps. Parlando di gestionali, questo vuol dire che se un utente in una sede di Torino cerca di accedere al gestionale che sta a Milano avra' a disposizione solamente i suddetti 256Kbps per il trasferimento di dati. Ogni volta che l'utente poi effettua un'operazione sull'interfaccia utente, il "client" genera una query, la inoltra al "server" e attende il risultato... un risultato che e' un recordset (un insieme di righe generate dal database) che deve essere di nuovo interpretato ed elaborato. Capita spesso che i database "lascino" i risultati nella propria memoria, pertanto ogni "passaggio di elaborazione" tra un record e l'altro necessita di una nuova richiesta di dati dal client al DB e una corrispondente risposta. Inoltre i timeout delle connessioni o le latenze portano con se problemi di stabilita' nella connessione tra il client e il server, introducendo tutta una serie di problemi e fastidi tanto all'utenza (che diventa improduttiva) quanto alla gestione dei sistemi (che - di fatto - non ha modo di risolvere il problema).

La soluzione sarebbe quella di inserire un "middleware" tra i due strati: il client invia una richiesta al nostro "middleware" (che - nel caso di sistemi gestionali - e' l'applicativo gestionale vero e proprio), questi interroga il database (che da un punto di vista tecnico e' connesso al DB con una rete ad alte prestazioni) e invia al client i risultati gia' elaborati. Non dobbiamo certo andare ad inventarci nuovi protocolli di trasmissione per fare queste operazioni, ce ne sono gia' tanti e sono ottimizzati per questo tipo di attivita'. Da un punto di vista funzionale, beh... le cose cambiano considerevolmente. Intanto l'utente non ha piu' i problemi di lentezza di creazione della connessione e rice/trasmissione dati, e i 256Kbps di banda non rappresentano certo un problema (alla fine anche se le linee vanno in backup ISDN con 128Kbps l'utenza puo' tranquillamente continuare a lavorare indisturbata).

Tags:


 Funziona. L'integrazione di un e-mail server Linux, basato su Cyrus e Postfix, con Active Directory e' una realta' in produzione e stabile. Ho gia' buttato giu' un documento scaricabile da questo url in cui ho descritto l'intera procedura. Ora mi rimane da fare lo script che interroga Active Directory per creare in automatico le mailbox e riprendere in mano un progetto che ho abbandonato nel 2004, un'interfaccia di gestione per Cyrus interamente basata sul protocollo IMAP (per maggiori informazioni: ecco il link).

Che razza di periodo

  • Aug. 11th, 2007 at 6:42 PM

Non e' andata come speravo... o meglio... come doveva andare... il sistema e' ancora bloccato... non riesco a darmi pace, continuo a riesaminare e riesaminare i dati che ho tirato fuori stamattina... debug di quelli piu' assidui, a vedere cosa fa il sistema mentre elabora il batch... DLL, filesystem, memoria... nessuna conclusione... trovato un altro problemino sulle cache dei dischi di sistema... eppure non ho risolto. A livello di sistema quelle macchine sono perfette, anche a volerlo non hanno nessun errore di configurazione.

Dicono che il nostro sistema sia identico a quello di un'altra realta'... io ho un presentimento sulla internazionalizzazione del sistema... sapremo lunedi'. Oggi penso che andro' avanti sull'analisi del sistema di posta elettronica...

Tags:

Non si finisce mai

  • Aug. 10th, 2007 at 9:33 PM

Sistema in produzione, eppure... gli script di GN3 non ne vogliono sapere di generare gli XML e le immagini da esportare. Ieri con Ivan pazzi a testare gli script di importazione dal server di produzione all'ambiente web, tutto a posto e oggi... sorpresa delle sorprese, l'esecuzione dello script VB che genera foto e articoli ci sputa fuori un gran bel "Microsoft Visual C++ Runtime Library Runtime Error!". A quanto pare secondo una KB di Microsoft (articolo n. 916177) e' un problema legato alla versione 6.6.8063 della DLL mfc42u.dll. Ho ricevuto solo ora la hotfix via email, sveglia puntata alle 5.00AM e domani mattina sparati in ufficio ad installarla. Con un pizzico di fortuna riesco a mettere la hotfix sul server prima che partano i job di acquisizione web, il che risolverebbe non pochi problemi, altrimenti vedo di finire lo script PHP che va a interrogare il DB MSSQL e estrapola le immagini direttamente sul filesystem. Sperem di farcela entro la deadline delle 7:30am.

Tags:

New Challenge

  • Aug. 9th, 2007 at 11:06 PM

Alla domanda: "risparmiamo sul sistema di posta elettronica ma rendiamola veramente efficace" la mia risposta e': Linux RedHat (o Fedora, o CentOS), Cyrus e Postfix. Che cosa ha di speciale? Dimenticavo il quarto ingrediente: Active Directory.

Sto studiando un sistema che consenta il raggiungimento di questi obiettivi:

  • riduzione dei costi di licenza sui sistemi di posta elettronica
  • tenere tutta la posta elettronica in linea (IMAP)
  • ridurre i costi di amministrazione del sistema

A che punto sono? Ho un IMAP server che si autentica su KDC di Active Directory (non e' single sign on ma e' possibile consolidare il meccanismo di autenticazione su un sistema gia' presente in tante aziende: Active Directory appunto) e utilizza la stessa per l'aliasing dei messaggi e il delivery (praticamente fa delle query LDAP). Avro' un paper pronto tra qualche giorno, ci sto lavorando di notte :p

Stay tuned.

Ora che siamo lucidi

  • Aug. 9th, 2007 at 10:13 PM

Il mio post precedente? Sicuramente incomprensibile... ero stravolto... 4 ore di sonno, un idiota che mi e' venuto addosso e s'e' spaccato lo specchietto del suo squallido camper sul finestrino della mia macchina alle 2 di mattina, e poi, nuovamente uno sforzo immane per riuscire ad essere lucido stamane per poter risolvere in fretta i possibili problemi derivanti dalla agoniata migrazione di ieri notte. Alla fin dei conti e' andata bene, molto meglio di quanto mi aspettassi, di certo in modo imparagonabile rispetto alle settimane precedenti, dove le abbiamo viste di tutti i colori. Tra l'altro gli imprevisti non sono mancati, tuttavia siamo riusciti a rimediare a tutto quanto in tempi umanamente ammissibili. Fatto sta che alle 8:00 di stamane un SMS di MT mi ha confortato: "nessuna chiamata ricevuta... quindi va tutto per il meglio". In effetti era cosi'. Poco dopo le 8 ho verificato e gli utenti Citrix gia' riuscivano a lavorare.

La cronaca di due giorni di preparazione per migrare il sistema editoriale? Intanto l'assenza di MS, che avrebbe avuto modo di dare un grande apporto, soprattutto perche' viveva l'implementazione di alcune nuove policy che ho messo in piedi nella gestione dei profili (che m'e' costata anche 3 giorni da urlo settimana scorsa nel riconfigurare tutta la farm Citrix... fortuna che il lavoro era solo su Windows 2003, perche' senza MS smanettare in Citrix non sarebbe stato cosi' semplice). Comunque sia, due giorni passati a vedere e rivedere i server, verificare le configurazioni, confrontarle con i dati di progetto e le previsioni di utilizzo. Esito? Server IBM che vedevano solo 3,5Gb di RAM (anziche' 10Gb), sistema di storage (SAN) configurata non secondo le specifiche che avevo prospettato io (oltre ad un dispendio di spazio un po' inutile che vado a sistemare ancora domani... 3 dischi da 500Gb inutilizzati :-/)... e ale'!! Backup preventivo di tutti i dati dell'unita' logica da 250Gb prima di convertire a caldo l'unita' logica... e' comunque andato tutto bene, devo dire che le promesse fatte da IBM su questo DS4700 sono state tutte esaudite fino ad oggi: ha convertito il RAID-5 in RAID-10 in circa 6 ore, ora abbiamo una unita' logica costituita da 8 dischi FC da 146Gb per un totale di poco meno di 600Gb di spazio utile (di cui 500 sono gia' allocati). Capisco che un RAID-5 faccia perdere meno spazio per il overhead (in effetti avremmo avuto uno spazio di poco piu' di 1TB rispetto ai 600Gb) ma... le performance? Peraltro un RAID-5 su 8 dischi con il midplane della SAN ancora a 2Gbps... volevo un RAID-10, quella macchina deve lavorare e lavorera' tanto quindi deve essere performante. Comunque sia la SAN tutto sommato e' stata davvero il problema piu' piccolo di tutti (i tecnici che stavano installando il sistema editoriale non si sono nemmeno accorti che gli stavo sostituendo la geometria del RAID sotto le chiappette :))))... peccato che i dischi siano dinamici... questo mi fa veramente inviperire non poco. Avevo detto esplicitamente che volevo fare dei cluster active standby su quelle macchine, e cosa mi ci fanno??? "Beh li converti"... si certo: formatto l'unita' logica, elimino il disco logico, converto il disco, lo ricreo, lo ripristino ed e' fatta. E quando le trovo piu' 2 ore per fare questo lavoro?!?! Pazienza... tanto so gia' come work-around-are questo problema.

Server... verifiche, verifiche, ancora verifiche... "SQL si pianta ogni 5 minuti, poi riprende"... manco il tempo di guardare il registro eventi: skew sugli orologi di sistema di 4 minuti. Ma perche' la gente non controlla mai gli orologi di sistema??? (Ora che ci penso non ho configurato NTP sui Catalyst - metto in nota - ma l'ora SI!!). Qualcuno ha mai letto la documentazione su Kerberos o Active Directory?? Se gli orologi sono disallineati i token di autenticazione perdono validita' e creano problemi... solo che in questo caso non bastava: anche la parte di sincronia tra i due server (ovviamente) andava a pallino. Regole sugli orologi di sistema sistemate... i DC si allineano con un orologio stratum-2 e distribuisce gli aggiornamenti a tutte le altre macchine della rete. Problema: risolto.

Server... ancora verifiche... "scusate, ma i due x3950 non avevano 10Gb di RAM?". La risposta era naturalmente convinta e tranquilla... "com'e' che ne vede solo 3,5Gb??". Primo dubbio: verifica della versione di Microsoft Windows 2003 Server: tutto bene, e' una Enterprise... e allora?! Cerchiamo in Internet, visto il passato si profila all'orizzonte il terrore che sia un nuovo problema hardware o firmware. Microsoft dice di ignorare gli errori PNPMEM nel registro eventi, pero' continuano a mancarmi 7Gb all'appello. La soluzione arriva da casa di big blue (un problema peraltro ben conosciuto - per chi avesse lo stesso problema sulle macchine x32 questo e' il link alla KB di IBM). Modifica dei file boot.ini dei due server editoriali, aggiunto switch /PAE, reboot dei server: 10240Mb di RAM presente ed installata. Problema: risolto.

I tecnici dell'editoriale necessitano di una utenza che monti correttamente le unita' disco del nuovo sistema, senza ovviamente andare ad intaccare il lavoro degli altri utenti. Creato un nuovo utente che possano utilizzare, creato un nuovo logon script... verifica operativa del lavoro fatto settimana scorsa su Active Directory. Logon utente e.... tutto a posto, i tecnici possono procedere alla grande a lavorare e tutto funziona perfettamente: Problema: inesistente.

L'ansia di MT era piuttosto evidente, e visti i trascorsi non sono affatto stupito della cosa. Anzi... Intanto acchiappo il secondo Cisco Catalyst 2960-G (24 porte Gigabit in rame) e lo configuro... scendo... salgo... collego... avvio... configuro... spengo... riporto giu'... insomma un lavoraccio: 15' e il secondo catalyst e' pronto per il lavoro... 25' ed e' anche nel suo armadio. 4 patch cord rossi (speriamo che MS non sia daltonico) crossati al volo, etichettati (a prova di daltonico ;)) e cablati sull'americana che corre lungo il datacenter. Network: pronto.

E via... preparazione ai lavori, ore 19:40, ci sono anche delle cronache registrate sul blog dell'editoriale (ecco l'indirizzo per i filmati). Spegnamo tutti i metaframe. Hanno ancora qualche noia sulla gestione delle console, ma probabilmente e' colpa del nostro switch KVM. Spenti, smontate le guide, rimontate ed infilati nuovamente nel nuovo rack, tutti attaccati, ad alta densita'. Gia' che c'eravamo con Aste abbiamo pulito le ventole con l'aria compressa. Tra un colpo di avvitatore (che mi ero portato appresso per l'occasione) e i click/clack delle guide, in 25 minuti nemmeno i server erano nel nuovo alloggiamento. Aste ha meticolosamente collegato tutti i server, i cavi di alimentazione visibilmente etichettati e fissati alle guide, cavi di rete grigi per i server collegati allo switch e via si riparte: partenza di ogni singolo server, verifica funzionale, installazione di IBM Director per la gestione centralizzata della farm e i server sono nuovamente operativi. Citrix farm: up and running.

Spostiamo la LUN della SAN dedicata all'archivio dei PDF (inezie, solo anni di storia dei giornali, svariate centinaia di Gb di dati... le solite cose) dal server su cui ha lavorato fino ad oggi verso il nuovo server. Praticamente indolore, ho provato a far salire l'ansia a MT dicendogli che abbiamo "una complicazione" ma non e' cascato nel tranello (forse dovevo rovesciarmi la bottiglietta d'acqua addosso per fingere l'ansia). Storage: up and running.

Ultimi preparativi, 3 ore tranquilli mentre i colleghi della societa' che ci sta installando l'editoriale finisce di migrare l'ambiente. Intanto mi sono messo di tutto punto a rivedere i logon script dei terminal server, centralizzato i logon script che prima erano locali sulla condivisione NETLOGON del dominio. A mezzanotte circa abbiamo fatto il cambio. Modifiche ai logon script, verifiche finali per essere sicuri che l'editoriale funzionasse l'indomani senza troppi problemi (sapevamo di qualche sede che avrebbe comunque avuto noie, ma piu' che altro perche' non sono a dominio). Tutto sembra andare a posto, un'oretta a finire di controllare che i logon script siano impeccabili. Editoriale: OK!

Finalmente possiamo staccare la rete, con Aste ci accingiamo a buttare giu' il secondo Catalyst, stacchiamo tutti i cavi di rete e lo montiamo nell'armadio di destinazione. Incidentalmente ho toccato (ma dico io?!?!?!) il cavo di alimentazione del secondo switch in fibra per lo storage. Momento di preoccupazione perche' se perdeva i dati di una transazione o c'era un errore nella configurazione della rete F.C. eravamo punto e a capo. Pero' l'infrastruttura, da questo punto di vista, e' impeccabile: ha tutto continuato a funzionare senza battere ciglio: il sistema ha gestito perfettamente la ridondanza dei circuiti, ho dato un colpo di telefono a MT per sentire se va tutto bene, li' ha capito che qualcosa era successo (anche se non aveva capito cosa di primo acchito). Pero' tutto cio' e' bene: sistema di fault-tolerance sul sistema di storage: testato. (mi rammarico solo di non aver effettuato crash test degli alimentatori ridondati dei server IBM... :()

Collegato secondo switch di rete, cavi gialli apparati di rete e servizi critici, cavi grigi server. Per ora non abbiamo una rete ridondata su layer 2, pero' siamo gia' pronti. Tutte le schede di rete dei server sono configurate in failover e i catalyst hanno RSTP pronto per funzionare, cosi' un domani mettiamo altri due catalyst e abbiamo alta affidabilita' anche sul backbone dei server. Collegati i 4 cavi che vanno verso il secondo catalyst nell'armadio di fianco... spie verdi. Ping: 1ms. Perfetto, abbiamo finito. Backbone: editoriale: 1Gbps tra i server, con 4Gbps tra un armadio e l'altro! Ora si comincia davvero a ragionare.

Oggi le piccole problematiche che prevedevamo, tranne un problema su SQL Server che s'e' trovato una macchina con 10Gb di memoria RAM e solo 2 di file di paging. Fortunatamente e' stato possibile risolvere questo problema a caldo senza dover riavviare l'editoriale (che a mezzogiorno in giorno di chiusura poteva essere "annoying" per gli utenti). Qualche interventino qua e la sulle stazioni remote ma niente di trascendentale. Insomma una migrazione pacifica, tra tutte quelle che ho visto e vissuto fino ad oggi, e' stata probabilmente la piu' tranquilla in assoluto.

Ricordate il mio post sull'attivazione di una nuova sede? Questa e' vita vissuta, non una visione ;) Ed e' il motivo per cui non cambierei il mio lavoro per nulla al mondo :)

Troppo divertito

  • Aug. 9th, 2007 at 8:35 AM

Alla fine ieri abbiamo finalmente messo mano a quella bella famigliola dei server Editoriali. Un'impresa che - stando agli standard visti fino ad oggi - per spostare 4 server da un server all'altro, modificare i percorsi della rete ethernet, installare due Catalyst 2960 nei nuovi armadi, configurarli e cablarli, avrebbe dovuto impiegare circa 2 giorni e' durata poco piu' di due ore effettive di lavoro. Abbiamo eliminato i vecchi switch di rete 10/100, finalmente il backbone dei server e' gigabit (rame) anche se privo di ridondanza fisica (RSTP e' comunque gia' configurato e pronto per l'aggiunta di nuovi 2 switch). Mentre i tecnici dell'editoriale stavano facendo il loro lavoro sull'editoriale per migrare i servizi io e Aste83 ci siamo impegnati a spostare i 4 server metaframe... un lavoro arduissimo: 30' netti e gia' stavamo installando Director su tutti i metaframe. Finalmente i server sono tutti uno sopra l'altro, insieme (i 4 xSeries sopra la SAN). Nei giorni precedenti avevamo riconvertito una unita' logica RAID precedentemente fatta in RAID-5 (su 9 dischi :-/) in un RAID-10, visto la quantita' di dati che questi dischi dovranno gestire in ingresso e in uscita. Unico momento di quasi-panico e' quando toccando dentro l'alimentazione di uno degli switch FC questo ha spento lo switch stesso (ora il cavo non si stacchera' di certo) pero' la cosa ci ha dato modo di provare che il MPIO funziona :)))

Finalmente mi e' chiaro anche come funziona gran parte delle applicazioni dell'editoriale (mica per altro, ma perche' capire il giro che fanno le foto prima di entrare in pagina bisognava vedere la cosa sul nascere).

Insomma un passaggio molto meno doloroso delle settimane precedenti (GPO sui metaframe completamente incartate, una revisione totale di tutto l'ambiente di produzione, SAN con un RAID-1 perso e apparentemente irrecuperabile, giusto quei 100 e rotti Gb di dati - recuperato il giorno successivo da Aste83...) anzi... e' stato quasi piacevole, mi sono divertito un sacco. Unico mancamento e' la carenza di sonno... abbiamo iniziato alle 20 e finito alla 1:45 ma tutto sommato ne e' valsa la pena :)))

Tags:


E' incredibile la quantita' di computer portatili che vengono rubati dalle automobili. A prescindere dal lasciarli (o meno) in vista quando si pacheggia all'autogrill, probabilmente la perdita materiale dell'apparecchio e' il problema minore. La posta elettronica (vedi mie precedenti osservazioni) e' anche semplicemente salvaguardabile, ma il resto dei dati? Una tragedia. Forse la fortuna vuole che alcuni individui non badino nemmeno alle informazioni in essi contenuti, tuttavia esiste una potenziale possibilita' che chi ruba un computer portatile (ma naturalmente la cosa si applica anche a computer fissi) possa attingere ad informazioni classificate. Seguendo la regola della scala sociale (delle aziende si intende) piu' il notebook e' recente maggiori sono le possibilita' che contenga dati sensibili o comunque di importanza rilevante per l'azienda poiche' il computer stesso sara' di un dirigente. Quello che maggiormente mi lascia stupito e' il fatto che quando parlo di crittografia dei dati tutti pensino ad una cosa complessa da implementare, mantenere e soprattutto utilizzare. Poi parlo di EFS e il mondo sorride a chi deve curare i dati contenuti in un notebook.

Forse non tutti sanno che EFS (Encrypted File System) e' una funzionalita' gia' presente in Windows 2000, e quindi anche in Windows XP. La sua implementazione e' semplice: selezioniamo la cartella Documenti del computer del nostro dirigente, nelle proprieta' avanzate impostiamo che il contenuto della cartella deve essere crittografato e la descrizione della cartella diventa di colore verde. L'unica nostra preoccupazione da questo momento in poi e' quella che il nostro dirigente non perda la propria password e non ne utilizzi una particolarmente semplice. In ogni caso possiamo rendere le cose difficili al probabile ladro impostando delle GPO di lockout sufficienti da esasperarlo e convincerlo a cambiare le password dopo aver forzato l'utente administrator. Se questo dovesse capitare continueremo a dormire sogni tranquilli: il certificato con cui vengono cifrati i documenti perde di validita', e i documenti diventano completamente illeggibili.

L'utente non deve fare nessuna operazione specifica. Ogni documento che salva nella cartella documenti sara' cifrato. Nessuna proprieta' avanzata, nessun applicativo aggiuntivo, e' tutto li', pronto per essere utilizzato da chiunque.

Esistono anche software che operano in modo alquanto simile, eppure visto che abbiamo una funzione forte e a portata di mano e, soprattutto, integrata nel nostro sistema, perche' non usarla? Tanto piu' che l'utente deve solo imparare a tenere in ordine i propri documenti, cosa che richiede uno sforzo piuttosto limitato e quindi piu' facilmente assimilabile da esso rispetto all'imparare l'utilizzo di un nuovo applicativo sicuramente complesso, pieno di password da ricordare e parametri da impostare. Aprire e chiudere documenti normalmente e, forse, dopo un po' se trovano un documento sul disco il cui colore e' nero piuttosto che verde, domandarsi il motivo e contattare il supporto tecnico con una domanda che - dal nostro punto di vista - e' finalmente un segno di miglioramento perche' i dati sono sicuri.

Ovunque io abbia lavorato mi è capitato di dover sviluppare un’applicazione per gestire determinate situazioni. Progetti, gestione supporto tecnico, IT governance, e via discorrendo. Ultimamente ho molto a cuore la parte di gestione del supporto tecnico che cerco di plasmare secondo quella che è la realtà corporativa in cui mi trovo (vedi Visioni IT: continuiamo ad integrare il Help Desk). Uno degli argomenti di cui invece non ho mai avuto modo di parlare sono sicuramente gli aspetti sistemistici.
 
In passato ho lavorato molto con Apache e RedHat Linux e continuo a farlo con una discreta soddisfazione tuttavia la mia scelta nell’ambito aziendale è caduta su Microsoft Windows 2003 Server come piattaforma server per l’applicazione, pur mantenendo una componente Open per la sua implementazione (PHP, MySQL, OpenLDAP, ecc). Le motivazioni sono svariate, ma in linea di massima devo ammettere che Windows 2003 Server è uno dei prodotti che mi piacciono maggiormente. Secondo me è uno dei prodotti migliori rilasciati da Microsoft negli ultimi anni (credo che se avessi dovuto scegliere tra RedHat Linux e Windows 2000 Server ci avrei pensato con molta più attenzione a cosa scegliere).  Avendo sempre un consistente numero di utenti da gestire (> 50) e un dominio Active Directory in cui sono gestiti tutti gli utenti, mettersi a duplicare un database utenti è più o meno equivalente ad un suicidio amministrativo (da un punto di vista di gestione sistemi naturalmente). Per questa ragione (praticamente ovvia), IIS6 con autenticazione Integrata (o base) è la scelta naturale per risolvere il mio problema. L’obiettivo è tipicamente quello di dare agli utenti il minor numero possibile di cose da ricordare e semplificare il più possibile la loro vita (autenticazione trasparente di IE). Per quanto riguarda la sicurezza, il supporto HTTPS di IIS6 risponde totalmente ai miei requisiti. In altri termini, con un costo in licensing relativamente ridotto ho la possibilità di mettere in piedi un frontend di produzione (anche virtuale) con un elevato livello funzionale e in grado di darmi le funzionalità di Alta Affidabilità mediante il servizio Load Balancing (disponibile anche su Windows 2003 Web Edition).
 
Il backend applicativo (normalmente installato sulla stessa macchina) invece basa la sua struttura su un database MySQL 5 e come linguaggio di programmazione l’intramontabile PHP. Sono due applicativi che conosco ormai molto bene e staccarmene a favore di piattaforme superiori (come .NET ed MSSQL) non mi intriga un gran che (sebbene io usi anche le altre due piattaforme, anche in un contesto web – vedi più avanti). MySQL 5 è un database robusto, veloce e capace di gestire volumi di informazioni consistenti senza nessun problema. Lo uso dalla lontana 3.23, rigorosamente con supporto relazionale. Oggi penso di saperlo usare con una grande capacità, sfruttando tutti i benefici che mi può portare, dal supporto per le transazioni alle stored procedure, fino ad arrivare alla gestione dei trigger (con l’avvento della versione 5). Anche PHP è una scelta derivata dagli anni di esperienza: è veloce, ha un set di funzioni molto vasto e un framework che mi sono creato nel corso degli anni facilita molto le cose. La conoscenza del linguaggio è stata sicuramente la scelta determinante.
 
Ora torniamo agli aspetti sistemistici. Ho accennato al problema dell’autenticazione utenti e indubbiamente questa è una tra le ragioni più importanti per cui ho optato per Windows come web server. Un’altra ragione è senza dubbio l’archiviazione documentale e il sistema di indicizzazione integrato in Windows. E come non apprezzare l’accesso alle risorse di sistema di Windows se non attraverso le librerie di PHP e gli oggetti COM? Questi ultimi (gli oggetti COM appunto) richiamati da PHP aprono frontiere che su Linux non sono attraversabili. Pensiamo solo alla generazione dei report. Molti subito diranno “ma come, possiamo generarli in PDF!”. E il problema si risolve. Il problema è che questa è una risposta da tecnico/programmatore e la mia opinione a riguardo è che il PDF non è un formato pratico. È un formato in sola lettura, poco gestibile e soprattutto difficilmente riutilizzabile. Ricordiamoci che stiamo parlando di applicazioni corporative, non siti Internet (nel qual caso i PDF sono senz’altro un’ottima soluzione).
 
Installando Microsoft Office sul server è possibile richiamare documenti Office veri e propri, generati in modalità nativa che di certo non causeranno problemi di compatibilità con i pacchetti Office diffusi in azienda. Generare quindi report in formato Excel o Word diventa un gioco da ragazzi. Allo stesso modo, le stampe dei report non sono più da gestire via pagine HTML bensì in formati più “apprezzati” dalle stampanti: inviare i documenti in stampa direttamente alle code di stampa sulla rete diventa altresì semplice. Un altro vantaggio di questo sistema integrato è quello di poter delegare ad un utente non programmatore l’autonomia per generare nuovi formati elettronici. Supponiamo di dover stampare un report su carta intestata o con una formattazione particolare. L’utente che genera il formato del report deve solo costruire lo scheletro del documento, formattarlo in modo che l’applicativo sostituisca determinate zone (o campi) con i valori generati dall’applicazione (ovviamente un breve corso di formazione è indispensabile). Nessun intervento sul codice dell’applicativo è necessaria, management e dipartimento IT non hanno necessità di cooperare per un’operazione tipica della prima divisione.
 
Vogliamo andare avanti? Questa è più una delle mie “Visioni” di come le cose potrebbero andare, ma qualche tempo fa ci avevo provato a giocare. Prendiamo le librerie di oggetti COM di Skype e facciamo in modo che il nostro applicativo possa anche parlare con gli operatori, sfondando la barriera delle email e sfruttando in modo senza dubbio proficuo anche i sistemi di messaggistica immediata.
 
Non dimentichiamo .NET e le sue funzionalità di sistema che possono essere molto comode. Prendiamo per esempio un banale applicativo sviluppato in ambiente di prova per la mia Intranet. L’esigenza era quella di riuscire a creare un ambiente di spool in cui una fotocopiatrice possa “parcheggiare” un file PDF acquisito. La fotocopiatrice carica il file sul server usando un accesso SMB diretto. Una volta che il file viene “sganciato” sul disco del server (ergo, vengono tolti i lock in lettura) il server deve modificare il nome del file e catalogarlo sul filesystem in una certa maniera. Qui .NET torna utilissimo, soprattutto se ciò che mettiamo in piedi è un semplice servizio di sistema con poche righe di C# che intercetta il file appena creato (con FilesystemWatcher) e lo sposta in una posizione altrimenti non accessibile agli utenti.
 
Sicuramente la gamma di prodotti disponibili per gli ambienti Microsoft Windows sono più ampi rispetto ai prodotti Open Source che, spesso e volentieri, richiedono diverse ore di studio, adattamento tecnico e inevitabilmente anche grafico prima di essere implementate negli ambienti di produzione. Il supporto tecnico, poi, è una cosa che ci tocca sperare di avere in tempi brevi e comunque sempre da supporto comunitario.
 
Insomma, secondo il mio personale punto di vista, integrare soluzioni vendor specific ha i suoi vantaggi (tempi di risposta, implementazione, supporto tecnico, documentazione) e svantaggi (costi) rispetto al mondo delle soluzioni Open Source, tuttavia una scelta bilanciata delle due dimensioni per trarre i vantaggi di entrambe le fazioni può portare vantaggi tangibili ed efficienti all’ambiente corporativo in cui ci troviamo a lavorare tutti i giorni, dando ottimi strumenti di lavoro all’utenza che – senza di noi – non avrebbe modo di lavorare come si deve. Molti mondi diversi possono finalmente lavorare insieme senza dover impazzire a trovare software che svolga ogni singola azione da fornitori esterni, dandoci la possibilità di creare un unico sistema integrato e cooperante.

Tags:


Questa cosa l'avevo gia' pensata piu' di una volta. All'apparenza e' una cosa ovvia in un sistema di gestione delle chiamate ma poiche' il sistema di tracking del Help Desk l'ho sviluppato io, per un motivo o per un altro, non e' mai stato implementato (essenzialmente mancanza di tempo e/o risorse per poterlo fare). A carattere generale ho deciso, per una vasta serie di motivi, di sviluppare l’applicazione su un server Microsoft Windows 2003, IIS, un database MySQL e PHP 5. I motivi di questa scelta saranno sicuramente motivo di una discussione più avanti :)
 
Il concetto di questa idea è piuttosto semplice: e se potessimo intercettare le telefonate che arrivano ai nostri interni (del supporto tecnico) per recuperarli quando andiamo a compilare i dati su una chiamata? Mi spiego meglio.
 
Attualmente le chiamate vengono gestite in modo manuale: un utente chiama, registriamo la chiamata, la categoria di guasto, il nome dell'utente e il suo recapito telefonico. Ma se il numero di telefono venisse direttamente dal centralino? Il nodo cardine di tutto questo e' che so anche come fare la cosa.
 
Un utente chiama il supporto tecnico. Il telefono (malauguratamente) inizia a squillare. Il centralino fa partire una trap SNMP verso il sistema gestionale che, alla sua ricezione, carica i dati nel database. L'Operatore risponde al telefono e fa click sul hyperlink che gestisce le chiamate in arrivo. L’inserimento del record genera automaticamente una chiamata tecnica, ancora priva di informazioni supplementari. In questo modo, se tutti gli Operatori sono occupati, rimane comunque traccia delle chiamate in entrata.
 
L’Operatore risponde al telefono, e dall’elenco delle chiamate in ingresso sul Gestionale seleziona la chiamata che sta gestendo. La classifica, vi assegna una priorità e la chiamata passa in fase di elaborazione in meno di 30’’ (calcolando convenevoli come saluti e domande di rito sul tempo e la salute). Intanto si può procedere con l’analisi del problema e l’eventuale soluzione al telefono del medesimo, altrimenti rimane traccia di quelle che sono le attività ancora da fare (e quindi seguono il ciclo di vita normale di un caso di soluzione del problema). Qualora gli Operatori fossero tutti occupati a rispondere ad altre chiamate, oppure a lavorare su un problema generale, o fossero semplicemente in bagno, il sistema continua a raccogliere i numeri di telefono che possono essere richiamati quando il o gli Operatori ritornano alla propria postazione.
 
Ora, questo sistema può vedere alcuni vantaggi ed alcuni svantaggi. Iniziando dagli svantaggi, la compilazione dei fari elementi delle form potrebbero essere abbastanza seccanti, per cui la cosa si potrebbe ovviare con una serie di “bookmark” e dati preconfezionati al fine di ridurre le operazioni di immissione dati a pochi secondi. Personalmente, da un punto di vista sia organizzativo che tecnico, vedo solo questo come problema cruciale. I vantaggi invece mi sembrano enormi. Iniziamo dal fatto che tutte le chiamate entranti al helpdesk vengono registrate. Poiché si tratta di un sistema di gestione delle chiamate di assistenza, non abbiamo il problema della privacy (consideriamo anche che i vari Call Center fanno esattamente la stessa cosa anche in ambiti pubblici). Il sistema raccoglie la data e l’ora esatta della chiamata, col vantaggio di avere un punto certo di partenza della segnalazione (talvolta lasciato all’Operatore del HelpDesk, azione che va ad impattare molto su eventuali SLA e regolamenti interni per la soluzione dei problemi). In un ambiente geograficamente distribuito, la raccolta e il raggruppamento dei dati eseguibile direttamente sul database può portare alla generazione di report dettagliati e capillari sui costi di mantenimento e sforzi amministrativi per la soluzione dei problemi sui vari centri di costo, per non parlare del fatto che l’analisi dei dati (con opportuni report) può anche portare a fare previsioni e proiezioni nel futuro sui problemi e sulle necessità di una determinata sede.
 
Help Desk home made? Decisamente continuerei su questa linea.

Disclaimer... oh my Disclaimer

  • Jun. 20th, 2007 at 7:04 PM

Io ogni giorno trovo delle cose a dir poco meravigliose nelle email che leggo. Oggi ne ho vista una nuova che ha veramente dell'affascinante:

"please don't print this e-mail unless you really need to."

Ora mi chiedo: ma che senso ha? E' come quella norma che dice che "per inviare comunicazioni ad un'azienda per mezzo della posta elettronica, bisogna prima chiedere - sempre via email - se e' possibile inviare detta comunicazione". Non ha senso, allora anche le aziende che distribuiscono volantini dovrebbero lasciare nelle nostre caselle di posta prima una richiesta di consenso alle comunicazioni commerciali!

Le cose che i nostri adorati politici (sempre rigorosamente laici) stanno mettendo in piedi a noi tecnocrati sono norme e regole assolutamente inutili, prive di senso e spesso poco attuabili. Ma la cosa continua e non penso accennera' a finire molto presto :)

Tags:

Bella Vita

  • Jun. 18th, 2007 at 12:49 AM

Immancabilmente anche oggi ho sentito la famigerata frase “ah, voi sistemisti sì che fate una bella vita”. Già, nello stereotipo sociale chi lavora sui Sistemi o sulle Reti (o – forma che non apprezzo molto – fa l’Informatico) fa un lavoro sedentario, seduto dietro ad una scrivania intento a battere tasti sulla tastiera. Nessuno stress, nessuna preoccupazione maggiore, orario fisso, e soldi a palate. Beh, immancabilmente, come tutte le volte, la persona che ha detto questa frase non ha assolutamente idea di quello che voglia dire fare il nostro lavoro.

Penso che quello dell’amministratore di Sistema e/o di Reti sia il lavoro in assoluto più difficile al mondo. Non lo dico perchè mi sento affaticato nel farlo (anche perchè non sarebbe assolutamente vero), ma perchè è un settore completamente fuori controllo. È frenetico, si evolve ad una velocità agghiacciante. Ogni giorno, se non ogni ora, esce qualcosa di nuovo, un buco nella sicurezza, un aggiornamento, un programma nuovo, una versione nuova. Per non parlare degli aspetti aziendali del caso. Un responsabile tecnico per sistemi informativi deve avere una visione di insieme che ha veramente dell’incredibile (non stupitevi se poi sono monotematici questi individui). Dall’esterno vedete solo una serie di macchine che, messi ordinati nei propri armadi, fanno anche la loro porca figura. Ma chi li vede con un occhio diverso, vede problemi di ogni sorta: temperatura, corrente, pericolo d’incendio, pericolo d’effrazione, possibili danni causati da software, virus, problemi meccanici, e come se non bastasse a volte ci si mette anche il Sole con le sue macchie solari. Chi di voi si è mai chiesto se la zona in cui avete la sede è una zona con attività sismiche? Sapete quante sono le stazioni di rilevamento sismico nella vostra zona? Oppure vi siete mai chiesti se la zona in cui siete è a rischio di allagamento?
 
Combattiamo ogni giorno con problemi ricorrenti e fissazioni che non ci fanno quasi mai smettere di pensare al nostro lavoro, avremmo da pensare e riflettere in ogni istante se dovessimo pensare a tutto, e 24 ore al giorno non ci basterebbero nemmeno lontanamente. E come se non bastasse ci mancano anche i problemi che ci danno gli sviluppatori, noti consumatori di risorse di ogni genere perchè (spesso) troppo pigri per riflettere su ciò che fanno. Rimangono quindi interminabili i conflitti tra i due livelli di Informatici che si accusano a vicenda di non saper fare il proprio lavoro. Fornitori di prodotti software che anziché risolvere problemi ne creano perchè loro hanno dalla loro parte “l’esperienza”. Tanto di cappello signori, ma a volte, forse, chi lavora in un’azienda, conosce quest’ultima meglio di voi, per non parlare del fatto che il mercato dai tempi dei sistemi 390 è passato da qualche tempo, e l’era Intel ragiona con metodiche un po’ diverse. Alla fine rimangono quelli che quando gli parli di alcune tecnologie ti guardano come se fossi un alienato appena scappato da un centro di salute mentale.
 
Insomma... non è proprio rose e fiori il nostro lavoro e di certo non è remunerato così bene come tanti pensano (ah già, ma questo solo in Italia!!). Quello che viviamo ogni giorno, come anche frasi del tipo “se non sei capace di fare il tuo lavoro, ne troviamo altre decine più bravi di te”, non è certo considerabile una vita facile. Spesso ci tocca fare turni pazzeschi, tirate da 24 ore perchè siamo in mezzo ad un mare in tempesta e non possiamo smettere finché non abbiamo riparato il danno (avete letto “Informatico vs. Medico”?) perchè se no la nostra azienda rimane ferma.

La Information Technology è il motore di ogni azienda ormai, sottovalutata, sottostimata e sempre sfruttata al massimo in qualsiasi ambiente. Noialtri, in qualità di responsabili di far funzionare questi motori, ci troviamo tra le mani un lavoro sporco, che ci mette sempre a dura prova, sia emotivamente che fisicamente (montatevi voi gli armadi o fate i cablaggi dove serve: qualsiasi tecnocrate come si deve lo fa coi propri colleghi questo lavoro). E guardate che non ho inventato nulla... 

Io l'altra sera sono uscito con dei carissimi amici (non sono certo di quelli che fanno affermazioni come quelle che hanno fatto nascere questo post), e quando hanno detto che "conoscere la tecnologia, oggi come oggi, e' come avere i superpoteri" mi sono sentito bene. Devo dire che non ho avuto ripensamenti sulla scelta del mio lavoro, continua a piacermi in ogni suo aspetto (o quasi). Pero' sentirsi dire certe cose... e' una notevole soddisfazione :)

Tags:


Il bello del conoscere la propria realtà lavorativa è quello di poter organizzare praticamente qualsiasi evenienza. Conosciamo gli utenti, conosciamo le logiche aziendali, sappiamo di “che morte morire”. Quando le realtà aziendali poi sono in crescita, è motivo di duplice orgoglio: il primo è che il management è ottimo, si vede perchè la produttività e le dimensioni dell’azienda crescono. Il secondo è che cresce su un fondamento stabile e solido. Il ruolo di noi del IT è proprio questo: creare un fondamento che non mostri segni di cedimento a nessun tipo di richiesta che venga dal Management.
 
Parola chiave: crescita. Requisito: pianificazione.
 
Per alcuni la pianificazione è una cosa su cui hanno fondato il proprio lavoro: parlo naturalmente dei Project Manager. Il problema di costoro è che talvolta non conoscono i problemi che potrebbero verificarsi. Noi, d’altro canto, conosciamo perfettamente il nostro campo e sappiamo quali sono gli anelli deboli della catena. In una crescita aziendale, in particolare l’aggiunta di una sede ad una rete corporativa, l’anello debole è il tempo (ma non lo è per tutti i progetti?).
 
I tempi in Italia per attivare una nuova linea dati sono a dir poco raccapriccianti. Quando va bene, ce la facciamo in due settimane ad avere una ADSL, quando va male... ci tocca aspettare quasi un anno (vedi “Operatori TLC alla ribalta”). Certo non possiamo sperare che vada tutto bene, per cui (come sempre) ci tocca trovare una soluzione. Ecco la mia “visione”.
 
“Partiamo con una nuova sede tra un mese”. Annuncio fantastico, sono tutti contenti. L’ufficio IT normalmente assumerebbe un’aria greve in cui la gente inizia a farsi prendere dal panico. “Un mese!? Ma non ce la faremo mai!!”.
 
Da noi è diverso.
 
Giorno uno. Arriva il mandato. Apriamo una nuova sede, ci saranno n persone a lavorare e svolgeranno questo e quest’altro ruolo. Prendiamo in carico i dati, un breve meeting per capire quali sono i requisiti della sede, raccogliere i dati significanti come indirizzo, condizioni dello stabile e cose così. Partono le prime telefonate ai fornitori con cui abbiamo stretta collaborazione. Armadio rack mezza altezza, pannelli di permutazione, router, switch di rete, prese di distribuzione, UPS, server dipartimentale e centralino telefonico. Conferme degli ordini ricevuti in giornata (abbiamo dei fornitori tosti ;)) e i tempi di consegna: settimana prossima abbiamo tutto il materiale. Intanto sentiamo anche l’elettricista e chiediamo autorizzazione al Capo per fare un sopraluogo della sede. Già che ci siamo sentiamo anche i nostri operatori per capire quanti ceri dovremo accendere per avere le linee dati (funzionanti) presso quella sede.
 
Giorno due: tutto tranquillo, il solito tram tram lavorativo. Qualche piccolo intervento su Active Directory e sul sistema gestionale/editoriale. Continua la raccolta dei dati sulla nuova sede, domani si va a vederla.
 
Giorno tre: visione della sede, con l’elettricista e un rappresentante del Management corporativo per capire che cosa vogliono fare in quella sede. Inquadriamo l’area tecnica, definiamo i lavori elettrici e gli eventuali cablaggi. La sede è grande, ci vorrà anche un access point wireless per la sala riunioni e un sistema di videoconferenza. Telefonate già fatte ai fornitori (ah già, nei mesi passati abbiamo stilato una rigida policy sui prodotti e servizi che andiamo ad implementare, quindi prima ancora che la sede venga “pensata” sappiamo già quanto costerà l’infrastruttura del core). OK dei fornitori, tutto procede regolarmente.
 
Giorno sette: arrivata gran parte del materiale, è tutto correttamente funzionante. Abbiamo già stampato ed etichettato tutti gli apparati, configurati gli switch di rete e il server dipartimentale... arranca. Ha un alimentatore guasto. Richiesta di supporto (NBD?) e intanto chiudiamo l’armadio, certificandone il funzionamento. Continuiamo con il nostro day by day, che tanto non ci si annoia.
 
Giorno dieci: rack pronto, montato e caricato sul furgone. Abbiamo un appuntamento con l’elettricista che ha finito la posa della linea elettrica nella sede. Arrivo in sede, collocamento dell’armadio. Fissato al pavimento, collegato alla corrente, e... tutto a posto. Il core della sede è funzionante (peccato non ci siano ancora le ADSL). Telecom però ci ha portato le borchie ISDN, per cui possiamo stabilire delle connessioni temporanee. Verifica dei punti rete e corretta configurazione degli apparati. Facciamo le connessioni ISDN e verifichiamo che tutto sia regolare. Ci risulta che lo sia (sempre grazie alla documentazione che abbiamo stilato nei mesi precedenti).
 
Giorno quindici: gli utenti della nuova sede vengono nella sede principale per un breve corso di formazione sul sistema che andremo a proporgli: GUI di Windows e applicazioni web disponibili ovunque. Illustriamo loro anche le nostre politiche di sicurezza e gli spieghiamo il perchè di esse. Il nostro fine è solo quello di proteggere la corporazione, quindi niente obiezioni. Opuscoli alla mano di tutti gli utenti, con i manuali d’uso e le eventuali procedure di routine (come contattare il Help Desk, quali numeri per che cosa, chi sono le persone del Dipartimento IT e che cosa fanno). Insomma, ci presentiamo come persone che hanno anche il desiderio di trasmettere qualche cosa, non solo fare un lavoro dietro le quinte. Alla fin dei conti siamo tutti nella stessa barca. Fine della presentazione, lasciamo spazio a qualche domanda e... doverosa pausa del caffè.
 
Giorno venti: test da remoto della sede, prime verifiche operative. Gli utenti possono di fatto lavorare, non ci dovrebbero essere grandi intoppi. Verifichiamo di nuovo le documentazioni per apportare modifiche minori al progetto, documentiamo il tutto e siamo a posto.

Giorno ventinove: ultimi test, definitivi. Siamo a posto con tutto quanto, abbiamo fatto del troubleshooting minore nei giorni scorsi per scaramanzia, ma ora siamo davvero pronti.
 
Giorno trenta, sei del mattino: uomo in sede per verifiche tecniche, accensione del sistema e configurazione di quelli che possono essere considerati come situazioni “last minute”. Nove del mattino: arrivano i nostri nuovi colleghi, entrano nell’ufficio e ci trovano il nostro uomo (probabilmente al dodicesimo caffè) iper attivo e pronto a spiegare loro come identificare gli apparati di rete e come agire su di essi: in altri termini: “leggi qui, schiaccia qui”. I cavi sono colorati a prova di daltonico, per cui non dovremmo aspettarci scene del tipo “oddio il filo rosso o il filo blu?”. Ma non convinti di aver fatto il giusto ci abbiamo applicato anche delle etichette ben leggibili sui cavi e incollato una bella piantina sulla porta dell’armadio (su cui, del resto, è anche scritto il numero di telefono da chiamare per il supporto tecnico).
 
Giorno sessanta (forse): arrivano le xDSL. L’operatore dell’ufficio tecnico comunica alla società di servizi in sede che devono semplicemente attestare i cavi delle xDSL sul pannello di permutazione, punto 23 e punto 24. Il punto 23 va nella porta ATM0 del router A, mentre il punto 24 va nella ATM0 del router B. I link risultano UP (meravigliosa invenzione il controllo remoto) e quindi possiamo rilasciare il servizio sulla VPN corporativa. 45 secondi di disservizio per la convergenza di tutto il sistema, solo che l’operatore, dopo 200 telefonate, s’è tagliato fuori dal router. No problem: chiamata al cellulare del collega in sede: “mi puoi seguire la procedura di riavvio del router A?”. Dopo due minuti il router è di nuovo gestibile, finiamo le configurazioni (caffè in mezzo per ricordarsi che usiamo BGP e non OSPF) e appuriamo che tutto funzioni.
 
copy running-config startup config
 
e buon lavoro.
 
È una visione utopistica? Sfidatemi.

Tags:

Email Systems Management

  • Jun. 10th, 2007 at 6:45 PM

th

Che gli utenti siano inaffidabili si sa. Così come si sa che il 90% dei problemi, secondo il layer OSI, si trova nell'ottavo livello (ovvero tra la sedia e la console). 

Il SysAdmin assume un nuovo "passatempo": predire il futuro. E fortuna vuole che Murphy abbia scritto la sua legge: se qualcosa può andare storto, lo farà. Il mio corollario è: se c'è di mezzo un utente, lo farà prima del previsto. L'utente finale tende ad essere un catalizzatore di disastri, quando c'è di mezzo un "laico" succedono sempre cose inspiegabili. Quelli di questo articolo si riferiscono alla perdita di messaggi di posta elettronica che avvengono autonomamente.

Vediamo il problema: utente finale, scarica la sua posta elettronica sul proprio profilo utente. Ci lavora per mesi e poi, ovviamente quando lui ha la massima necessità di un messaggio, si scopre che quel messaggio non c'è più. Si è cancellato. Si, esatto, non è che è stato erroneamente cancellato, si è cancellato da solo assieme alle email di tutta la settimana precedente. Insomma, se vogliamo essere pessimistici, seguendo la legge di Murphy, l'utente avrebbe dovuto perdere la posta elettronica in modo irreversibile nel momento cruciale. Invece abbiamo a che fare con un disastro "selettivo". Quando pensi di averle viste tutte, eh?

Io sono uno dei sostenitori della posta in linea. Ho avuto modo di convincermi di questo sistema gia' molte volte, e piu' vado avanti e piu' sono certo della mia presa di posizione. In qualita' di Responsabile Sistemi Informativi la cosa piu' importante da tenere sempre presente e' che bisogna sempre garantire la disponibilita' degli strumenti e delle informazioni che esse mettono a disposizione agli utenti. Dormire tranquillo, per quanto mi riguarda, non vuol dire sapere che i servizi non crolleranno, ma anche che i dati saranno accessibili, e se non sono piu' accessibili, poterli recuperare.

All'utenza dei vertici delle aziende non interessa normalmente "come le cose funzionano", desiderano solo che funzionino. Punto.

La posta elettronica e' uno strumento di lavoro che assume sempre una maggiore importanza. L'idea di avere MX multipli, piu' server di backend non e' sufficiente. Sfortuna vuole che l'utenza non sia molto attendibile e chiedere aglu utenti di fare delle copie di backup dei propri dati e' assolutamente un'utopia. I processi di logoff possono richiedere tempo in base alle dimensioni dei file di dati che piu' diventano grossi, piu' diventano pesanti da trasferire (via rete) e fragili. Tutto questo porta ad una sola conclusione: prima o poi uno (o piu' utenti) si lamenteranno della perdita di tutti i messaggi. E questo e' un problema seccante.

Tenere la posta elettronica in linea ha pro e contro (come tutto). Il pro e' che il "point of failure" e' uno (e non magari 300). Avendo una valida gestione delle quote si possono ottenere ottimi risultati in termini di performance e sicurezza. Come amministratore di sistema, gestire un server e' molto meno problematico che gestire un client di rete (manca l'elemento "utente") e generalmente si e' in grado di prevedere un problema prima che questo effettivamente assuma quell'aspetto (di problema appunto). Inoltre, a insaputa degli utenti, si possono fare attivita' di backup sui messaggi di posta elettronica, cosa che non puo' certo fare che bene alla salvaguardia dell'azienda stessa.

Fare i backup dei messaggi di posta elettronica non e' semplice. Anzi, esistono innumerevoli problemi nella gestione di un sistema di questo tipo. A seconda del server di posta elettronica, poi, esistono anche diverse tipologie di backup che si possono fare. I sistemi che usano singoli file per il mailbox store (come Courier) sono quelli piu' problematici, poiche' o supportano un sistema di "log circolari/incrementali" per registrare i singoli messaggi che transitano sulla casella, oppure ci tocca fare solo dei backup completi delle mailbox. Altri server, come Cyrus, usano singoli file organizzati in directory, per salvare i messaggi. La policy di backup incrementale, in questo caso, ha senso e puo' essere applicata usando la "data di ultima modifica" come sistema di riferimento, tuttavia il processo di ripristino va studiato poiche' i file vengono nominati con un numero pari all'indice del messaggio sulla directory IMAP. Esistono poi le soluzioni commerciali (come Symantec Backup Exec con l'agente per Exchange Server) in cui e' possibile fare i backup dei singoli messaggi di posta durante le normali operazioni del server.

A prescindere dalla tipologia di server che si intende utilizzare, fatte le opportune valutazioni di storage (una SAN, per esempio sarebbe un grande beneficio in una infrastruttura simile) il concetto fondamentale dovrebbe essere quello che i messaggi devono essere sempre disponibili e, in caso di necessita', non doversi mai trovare in condizioni di dire "mi spiace ma non ho modo di recuperare il tuo messaggio di ieri". Vi assicuro che non e' per niente gradevole dover ammettere una cosa simile :-)

Tags:

Potenza o Continuita'?

  • Jun. 9th, 2007 at 11:51 AM

Una delle cose del mondo IT che meno approvo e per cui ho un rifiuto concettuale e' quando societa' di consulenza (o presunti guru di settore) riescono a convincere le aziende ad acquisire potenze di calcolo enormi senza pensare alle conseguenze delle proprie azioni. Macchine a quattro o otto vie, con capacita' di memoria mastodontiche, certo con unita' disco in RAID per prevenire la perdita di dati e alimentazioni ridondate... ehm... scusate, ma se muore la macchina, il Vostro business che fine fa? Premettendo di avere anche il migliore dei contratti di assistenza, riuscirete ad avere un fermo anche di quattro ore (leggi: mezza giornata) sul vostro lavoro... menomale che c'e' il solitario di windows.

Di recente ne vedo svariate di queste realta', che richiedono una elevata capacita' di elaborazione. Non sono certo tra le persone che si spaventano dei numeri di elaborazioni o di transazioni (applicative, non database) di cui l'azienda ha bisogno. Pero' mi sono spesso domandato del perche' nessuno (o quasi nessuno) parli mai del modello "load balancing". Forse non tutti sanno che i cluster non servono solo a garantire la continuita' di un servizio, ma possono essere anche utilizzati per aumentare la capacita' di elaborazione del sistema nella sua complessita'.

Prendo come esempio un progetto che ho sviluppato (a livello di laboratorio, ma e' assolutamente in grado di operare nel mondo reale) per un test. Il problema era di poter effettuare elaborazioni di una grande quantita' di documenti in formato PostScript da convertire in PDF.

Per lo sviluppo dell'ambiente di test ho utilizzato delle macchine virtuali su cui girava un Windows Server 2003 Standard Edition (si, la standard edition, quindi non e' proibitivo in termini di costi). Il primo server Windows 2003 l'ho configurato facendone subito il hardening anche dell'applicazione, al fine di avere una macchina virtuale da replicare su tutte le altre. Conclusa l'installazione ho sigillato il sistema con sysprep (altra componente di sistema) e mi sono copiato l'immagine del disco su un DVD. Ho avviato la prima macchina virtuale, completato la sua configurazione e quindi messa a dominio (in questo caso avevo gia' due DC funzionanti). Per gli altri tre nodi ho semplicemente copiato la mia immagine dal DVD e avviato la macchina virtuale da quel disco. In meno di due ore avevo 4 server perfettamente pronti per poter essere configurati nel cluster.

Per il clustering in bilanciamento di carico ho usato il Network Load Balancing di Microsoft Windows 2003 Server, ho creato il cluster e aggiunto i 4 nodi. Il servizio condiviso era naturalmente il servizio di condivisione file e stampanti. Poi ho cominciato ad inviare i file al cluster e verificato che venissero analizzati dai vari nodi del server. Naturalmente non potevo pretendere delle prestazioni formidabili (il laboratorio girava su una macchina monoprocessore) pero' cambiando architettura hardware (passando magari a server Xeon, Dual Core oppure addirittura su processori Power) il vantaggio sarebbe stato evidente.

La soluzione presentata avrebbe consentito di poter elaborare una piu' grande quantita' di dati che con una singola macchina (riducendo i tempi di attesa dell'output) con un risparmio sul hardware (quasi il 20%) rispetto alla proposta fatta da un'altra parte (una macchina quadriprocessore con un boato di memoria e dei dischi con configurazioni incomprensibili). Il vantaggio vero di una soluzione in load balancing (rispetto ad un hardware che apporti lo stesso volume di calcolo) e' la continuita' del servizio. Supponiamo (come e' nel caso del progetto descritto) che la generazione del PDF sia cruciale per l'attivita' dell'azienda e che una mancanza di consegna dei PDF apporti una perdita non solo momentanea ma anche di immagine. Che succede se il sistema si ferma? Tra intervento tecnico, telefonate di utenti che inveiscono sull'amministratore di sistema, la chiamata all'assistenza e le preghiere che "non sia il controller disco" passano tra le 2 e le 4 ore prima che il problema venga risolto (gia', perche' il corriere ha trovato traffico a causa di un incidente, e se il nostro SysAdmin apre la macchina la garanzia se ne va a quel paese). Il danno e' fatto: mancano due ore alle 20, scadenza ultima della consegna dei PDF, il giorno dopo c'e' un'importante manifestazione in cui l'azienda aveva investito denaro e non potra' avere le brochure dalla tipografia. Il sistema viene risolto, sono le 19, il sistema e' appena ripartito, sta prendendo in carico i primi file... sono danneggiati, bisogna ricontattare il grafico per rimetterle in coda di processi... passano le 20, il sistema e' ancora a meta' strada per finire le conversioni...

Definitivamente la soluzione "tutto su uno" non funziona, soprattutto perche' non da effettivi vantaggi in questo tipo di applicazioni. Se fosse morta una sola macchina virtuale (dump di sistema, crash applicativo), gli altri nodi avrebbero comunque continuato a operare e il ritardo sarebbe stato veramente ridotto, non compromettendo l'immagine dell'azienda.

Business Continuity o Alta affidabilita'? Parliamone...

Tags:

Visioni IT: Gestione Integrata Magazzino

  • Jun. 6th, 2007 at 7:17 PM

Immagina la tua azienda che dispone di un magazzino prodotti per clienti, completamente informatizzato. Un database con tutti gli articoli a magazzino, etichettati con una etichettatrice che stampa il numero di matricola con un codice a barre. Il tuo dipendente entra in magazzno, non gli serve sapere che magazzino è, quando è stato acquistato o altro: la scatola è lì, ha un'etichetta, quindi può essere prelevato. Il tuo dipendente prende la scatola, passa al terminale in magazzino, inserisce il proprio numero di matricola e la password (che guarda caso e' la username e password che usa per il PC), legge il codice a barre, inserisce il destinatario del collo e la causale. Invia la form al server gestionale che gli fa uscire sulla stampante lì di fianco la bolla di accompagnamento del prodotto. Tutto viene gia' registrato e salvato nel tuo database gestionale, l'operatore che si occupa del magazzino si ritrova l'operazione a video immediatamente, nessuna perdita di tempo, nessun problema organizzativo. Pensi che sarebbe fantastico, ma hai paura che costi una follia esagerata? Forse non e' così.

La scelta giusta delle piattaforme puo' portare benefici considerevoli in ambienti aziendali. Realizzare una Intranet basata sul web, per esempio, ha il vantaggio di poter essere estesa a tutto il contesto aziendale in tempo minimo e senza che si debbano installare client specifici sui terminali degli utenti. La scelta di Microsoft Windows Server 2003 per mettere in esecuzione l'applicazione potrebbe favorire il concetto di "single sign on" (a condizione di avere un dominio NT5 o NT6 a disposizione) grazie al quale gli utenti si abituano a poche cose (gestire un solo nome utente ed una sola password) in modo opportuno (complessita' delle credenziali, cambio autonomo della password) per tutte le applicazioni aziendali. Una soluzione che si riflette anche sulla gestione delle suddette che devono essere conformi a documenti pragmatici sulla sicurezza e ovvie politiche di gestione delle credenziali di accesso degli utenti. L'adozione di Microsoft Windows Server come piattaforma applicativa offre un secondo vantaggio alla mia visione: il supporto nativo per driver di stampanti diverse (etichettattrice o stampante di rete non necessariamente PS) consente una maggiore duttilita' nella scelta dei prodotti da usare e l'inutilita' di scrivere codice "ad hoc" per la detta stampante, in quanto il middleware tra applicativo e stampante scende dal codice applicativo stesso al driver della periferica stessa. Terzo e non certo per importanza, il concetto di oggetti COM di Microsoft Office consente all'applicativo web di utilizzare Word oppure Excel come "motore" di gestione delle stampe (notoriamente poco gestibili via html) rendendo i processi di stampa piu' semplici e, ancora una volta, piu' indipendenti dalla periferica di output usata (laser, getto, termica, aghi).

Ma l'Open Source e' gratis! Certo, non c'e' dubbio che installare un web server Linux abbia un costo legato unicamente al hardware, vuol anche dire che le conoscenze del mezzo sono delegate ad un numero ridotto di persone che conoscono quell'ambiente. Vuol anche dire creare un sistema che non puo' amalgamarsi con il resto dell'infrastruttura azendale la quale, inevitabilmente, si appoggia a piattaforme commerciali. Significa introdurre ulteriori "punti deboli" alla catena (gia' fragile) di stabilita' del sistema e creare scompiglio tra gli utenti, complicando la vita a questi ultimi che, salvo rare eccezioni, sono pigri e faticano a pensare anche al loro piccolo. Provate a spiegare ad un utente che deve ricordarsi la propria password del pc, quella della posta elettronica, quella del proxy, quella del gestionale, quella della Intranet. E che ai sensi di legge, devono anche pensare di tenerle tutte complesse e cambiarle ogni tanto!! Per quanto le soluzioni tecniche Open Source possano essere belle e strafighe (passatemi il termine) corporativamente parlando (e politicamente) sono un suicidio amministrativo (tecnicamente parlando).

Come appunto ho appena affermato, scelte opportune si riflettono su ambiti differenti. La spesa (perpetua) di acquisizione di licenze per Microsoft Office e Windows 2003 Server (anche web edition) possono essere facilmente recuperabili calcolando il risparmio nel tempo di sviluppo applicativo anche usando (come del resto suggerirei io stesso) linguaggi di programmazione Open Source come PHP e piattaforme database come MySQL o PostgreSQL (senza tuttavia dimenticare, laddove possibile o necessario) i database commerciali come Oracle, DB2 o SQL Server.

Lo sviluppo misto tra prodtti di fascia enterprise e metodo open source, secondo la mia personale opinione, potrebbe (perche' normalmente si punta o "tutto open" o "tutto branded") portare a livelli di integrazione che oggi sembrano solo alla portata di grosse imprese che si affidano ad enormi solution provider, entrambi addendi di una formula che da come somma investimenti spropositati (inutili e difficilmente giustificabili, IMHO).

Tags:

Privacy & Sviluppo Web

  • Jun. 5th, 2007 at 10:39 AM

Le attuali leggi sulla Privacy (e il buon senso) richiedono che lo sviluppo applicativo sia fatto in modo da tutelare l’accesso ai dati sensibili alle persone che effettivamente ne abbiano l’autorizzazione. Secondo alcune linee guida, lo sviluppo prevede che si creino sul database viste e query che, in base al livello utente, diano l’accesso a un determinato set di informazioni. Questo tipo di approccio, secondo me, è molto oneroso in termini di risorse e visti i tempi di sviluppo effettivamente a disposizione, non è facilmente perseguibile. Quello che vi voglio proporre qui è un metodo alternativo per sviluppare applicazioni web che rispondano a suddette esigenze in modo rapido.
 
L’applicazione utilizza PHP come linguaggio di programmazione di esempio tuttavia può essere applicato a qualsiasi altro linguaggio di programmazione. Le query SQL riportate sono di MySQL.
 
La prima fase di questo sviluppo dovrebbe consistere nello sviluppo di una forte serie di funzioni che realizzino le funzioni di autenticazione ed autorizzazione. Questo insieme di funzioni devono svolgere i compiti di seguito proposti. Assegnerò ad alcune funzioni dei nomi, in modo da poterle richiamare nel codice di esempio che vado proponendo.
 
Funzione di autenticazione
 
Questa funzionalità deve essere presente sempre. Non la si può omettere, deve supportare un meccanismo di controllo che verifichi l’esistenza delle credenziali e la loro correttezza, lo stato attivato o meno dell’account. A livello di codice applicativo questa funzione può essere omessa in quanto la gestione delle credenziali può essere delegata al Web Server (autenticazione di base, ecc.) poiché più facilmente gestibile ed integrabile con altri sistemi di autenticazione o single sign on (per es. IIS ed Active Directory) che sono più facilmente controllabili e dispongono già di un forte sistema di controllo dell’accounting utente (scadenza password, complessità, ecc.)
 
Funzione di gestione delle autorizzazioni
 
Questa a differenza della suddetta componente, invece, è indispensabile. La funzione assegna all’utente un “livello” di autorizzazione che, trasversalmente su tutta l’applicazione, fornisce all’utente accesso a determinate componenti o contenuti. La funzione caricherà in sessione (non in cookie!!!) i livelli di autorizzazione dell’utente che devono essere sempre accessibili. Al logon utente il set di credenziali fornito verrà quindi confrontato con il livello dell’utente, e il suo “token” di autorizzazione verrà salvato in sessione. Ogni volta che si andrà a pubblicare una componente (un’ancora, un record, anche una singola etichetta) il programma andrà a verificare se l’utente è autorizzato o meno ad accedere a quella informazione usando il “token” come metodo di confronto.
 
Come gestiamo l’accesso ai dati?
 
Supponiamo di avere una tabella anagrafiche strutturata così:
CREATE TABLE tbl_pazienti (
 ID_paziente INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
 nome_paziente VARCHAR(45) NULL,
 codice_fiscale CHAR(15) NULL,
 indirizzo VARCHAR(45) NULL,
 localita VARCHAR(255) NULL,
 provincia CHAR(2) NULL,
 stato CHAR(3) NULL DEFAULT "ITA",
 telefono VARCHAR(20) NULL,
 codice_assistito CHAR(10) NULL,
 PRIMARY KEY(ID_paziente)
);
Secondo le linee guida, per ogni “livello” di autorizzazione dovremmo creare una vista che dia accesso solo ad una limitata componente di dati. A livello di codice, poi, dovremmo fare una serie di strutture di controllo che, in base al livello utente, carica la vista opportuna. L’impegno per la gestione dei permessi diventa onero, mentre l’aggiunta di un nuovo livello di autorizzazione richiederebbe l’intervento almeno di un DBA (se il codice è stato strutturato opportunamente).
 
Implementando il metodo descritto nel presente articolo, invece, andiamo a gestire tutto a livello applicativo. Attraverso un pannello di configurazione è possibile configurare i parametri di “autorizzazione”. Il processo di creazione di un nuovo livello di autorizzazione prevede i seguenti passaggi:
  1. Creazione del livello di autorizzazione
  2. Per ogni tabella andiamo a definire quale colonna l’utente può visualizzare e quale no (un valore booleano)
  3. Salviamo le modifiche
La suddetta operazione può essere svolta tranquillamente da qualsiasi utente che abbia le opportune credenziali di accesso al pannello amministrativo, e non deve assolutamente essere né un DBA, né un programmatore. A livello di codice invece? Tutto esattamente uguale. Vediamo come.
 
Partendo dalla SELECT che interroga il database, supponiamo di caricare il record di un determinato paziente.
SELECT t.nome_paziente, t.codice_fiscale, t.indirizzo, t.localita,
       t.provincia, t.stato, t.telefono, t.codice_assistito
FROM tbl_pazienti t
WHERE t.ID_paziente = 25
LIMIT 1;
La query restituisce un record solo con i dati anagrafici del paziente. Ora vediamo il codice applicativo.
 
La regola del RAD (Rapid Application Development) dice che per visualizzare i dati dobbiamo fare una struttura del tipo:
$q = “SELECT.....”;
$r = mysql_query( $q );
$data = mysql_fetch_array( $r );
 
# Altro codice
 
print( $data[ “nome_paziente” ] );
Non vogliamo stravolgere la regola dello sviluppo rapido delle applicazioni, anzi, lo vogliamo mantenere. Allora sostituiamo solo una sola funzione di tutto il set suddetto: la funzione print().
 
La nostra nuova funzione (che chiamerò “getElement” ) non fa altro che fare l’output del contenuto di un elemento $data, tuttavia prima di farlo, verifica se l’utente ha il permesso di visualizzare quel elemento. Secondo il suddetto esempio, pertanto, avremo che il codice da noi scritto sarà più simile al seguente esempio:
$sql = “SELECT ....”;
$obj->query( $sql );
 
# Altro codice
 
print $obj->getElement( “nome_paziente” );
Conclusioni
 
Il vantaggio di questo metodo di programmazione è che lo sviluppatore può sviluppare le applicazioni in modo rapido, senza più curarsi del concetto di autorizzazione. Il sistema descritto può essere applicato a qualsiasi elemento del programma come etichette, elementi dei form, ancore, ecc. Sviluppando delle guide all’interno dell’area di amministrazione si effettua una completa spaccatura tra Utente Finale che deve fruire di un’applicazione, e il gruppo di sviluppo che invece deve intervenire su di essa aggiungendo nuove funzionalità. Quando un utente finale necessita di modificare un livello di autorizzazione, con il sistema proposto è sufficiente che si rivolga alla persona che si occupa della gestione dei livelli la quale, normalmente, è una persona interna che conosce bene l’ottica aziendale. Se usassimo delle viste, invece, ci troveremmo a dover chiamare un DBA o lo sviluppatore, con la logica conseguenza di dover attendere un periodo di tempo più lungo per avere la modifica (e possibilmente anche dei bug poiché la modifica è eseguita sul codice).
 
Esistono degli aspetti sulla sicurezza e sulla privacy (questo esempio è legato al mondo sanitario che mi affascina molto ultimamente) che non ho contemplato nell’articolo poiché sono principalmente argomenti sistemistici. Questi elementi sono la comunicazione tra database e application server, e tra application server e client di rete, la crittografia dei dati sui dischi dei database, e l’eventuale crittografia dei dati all’interno delle tabelle dei database. Magari saranno argomento di un altro articolo :)

 

Che nostalgia

  • May. 30th, 2007 at 6:23 PM

"L'applicazione e' lenta"
"Comprate una macchina con 8 processori"

La (triste) storia dell'Information Technology degli ultimi anni e' proprio questa... i programmatori sono drogati di risorse di sistema. Personalmente rimpiango i tempi in cui si programmava in Assembler: avevi un set di istruzioni ridotto e se non progettavi un programma bene finivi la memoria a disposizione per il sorgente applicativo. Erano tempi duri, ma quando rilasciavi il software erano vere soddisfazioni. I processori avevano i clock a 16MHz, 24MHz nel migliore dei casi. Se una funzione era troppo lenta (magari in applicazioni industriali) ti toccava riscrivere la routine per ridurre il numero di cicli macchina che impiegava a completarsi (e a fare i conti con un foglio XL piuttosto che Lotus 123 per vedere il numero di cicli macchina e quindi millisecondi ci mette). Se invece ci metteva troppo mettevamo un numero di NOP sufficiente per perdere abbastanza tempo... PERDERE TEMPO!!!

Oggi no. Codice lurido, non strutturato, ad oggetti... MegaByte di memoria allocata in non si capisce bene quale motivo... come disse qualcuno anni fa (non ricordo chi - abbiate pieta') "man mano che il linguaggio di programmazione diventa alto, la capacita' analitica dei programmatori calera'"... forse arrivera' il giorno in cui il codice si scrivera' da solo... oggi chiunque sappia usare frontpage e' programmatore (momento di gelo).

La fine e' abbastanza drammatica: applicazioni non strutturate, non documentate, pessimamente commentate, poco sicure e poco efficienti. Un collega mi racconto' di un'applicazione sviluppata in ambiente non forkabile che, per dare migliori performance, e' stata installata su una macchina a 8 processori. L'esito di questa installazione e' facilmente deducibile. Ma allora mi chiedo: perche' gli sviluppatori non hanno l'umilita' di ammettere che non capiscono niente di sistemi e hardware, non riflettono sul fatto che le applicazioni possono essere migliorate semplicemente ottimizzando il codice (o le query, o il carico di lavoro tra applicazione e database)? Qual'e' questa drammatica fenditura che si e' verificata tra "programmazione" e "conoscenza del hardware" su cui l'applicazione deve girare?

Poi si dice che bisogna risparmiare sulle infrastrutture. Io rimpiango le persone come il mio professore di Sistemi Industriali all'ITIS che ti ribaltava la testa se facevi una routine in 13 righe quando potevi farlo in 7. Aveva ragione, io oggi me ne rendo conto, ma possibile che persone cosi' non insegnino piu'?