Surftech 10 Years Anniversary

SURFTECH 10 YEARS ANNIVERSARY 

Venerdì 11 maggio ’18 per noi è stato un giorno di festa. Si perché quest’anno (esattamente il 14 febbraio) abbiamo raggiunto un importante traguardo, ovvero i nostri primi 10 anni di attività.

Abbiamo colto l’occasione per ritrovare chi ha collaborato con noi in questi anni, clienti, fornitori, distributori e brand che ci hanno accompagnato in questo percorso fino a farci diventare un’azienda solida e riconosciuta.

Tutto si è svolto a Illasi, in provincia di Verona: pochi sanno che Surftech lavora prevalentemente in smart working e che non ha una sede operativa ma ci tenevamo a portare gli invitati nei luoghi a noi familiari, in mezzo alla natura in un contesto diverso e di pregio, confidando nella bella stagione e in una giornata di sole che per fortuna ci è stata regalata.

Per il ricevimento abbiamo scelto il ristorante Le Cedrare, dello Chef Marcantonio Sagramoso, nella splendida cornice della Villa Perez-Pompei-Sagramoso. Eleonora, moglie dello Chef, ha creato per noi un menù che comprendeva sapori di stagione rielaborati e presentati in chiave moderna e raffinata.

Gli ospiti sono stati accolti da un ricco buffet nel giardino all’italiana e hanno passato un’ora sotto gli alberi, cullati dal venticello primaverile, tra finger food e bollicine, a darsi il benvenuto e a scambiare i primi saluti. Sembrava tutto tranquillo, ma qualcosa non tornava: alcuni camerieri si comportavano in maniera inusuale. Ma certo, sono i camerieri matti di Giulia Cailotto! Lei e i suoi compagni hanno rallegrato tutto il ricevimento dando strambe ricette di cucina e cercando di mettere il più possibile a disagio in maniera scherzosa i nostri ospiti che hanno presto scoperto il gioco e preso parte allegramente a questa bizzarra animazione.

 

 

 

Il pranzo è stato servito nella veranda con vista sul giardino, in tavoli rotondi e ben curati, dove l’atmosfera era allegra e rilassata, il luogo perfetto per fare due chiacchere come tra vecchi compagni di classe.

Prima di servire il dolce abbiamo celebrato con un discorso informale questi 10 anni di attività: Francesco ha raccontato in breve da dove siamo partiti, i risultati raggiunti, quanto stiamo crescendo e i nostri nuovi obiettivi.

Perché allora non premiare chi ci ha aiutato durante questo percorso? Abbiamo voluto omaggiare con delle bottiglie di vino della cantina Ferragù i primi di ogni categoria; ecco di seguito tutti i vincitori:

Categoria Brand

Partner Brand più rilevante per Surftech: CITRIX
Partner Brand con fatturato totale più alto: LENOVO ITALY
Partner Brand con migliore programma di canale: IBM ITALIA

Categoria Fornitori

Primo fornitore per fatturato e in ordine di tempo: COMPUTERGROSS ITALIA
Fornitore con migliori competenze verticali: READY INFORMATICA  e ALIAS

Categoria Clienti

Primo cliente in ordine di tempo: ARNEG
Cliente con fatturato totale più alto: SONEPAR ITALIA
Cliente con fatturato servizi più alto: EUROSPIN ITALIA
Progetto più complesso effettuato: TRASLOCO EBARA PUMPS EUROPE
Progetto più innovativo effettuato: AZIENDA TRASPORTI VERONA – Endpoint management
Cliente con maggior utilizzo Cloud: MESSNER DR. HEINRICH
Cliente che è presente anche in qualità di fornitore: KNOLLSEISEN & PARTNERS

Categoria Surftech

Miglior dipendente sistemista Surftech: LUCA CHIARAMONTE e MANUEL SIMIONATO
Migliore risorsa di supporto alla direzione Surftech: LE MOGLI!

Dopo i premi sono arrivati i dolci e… la pioggia! Ma il breve temporale non ha fermato i festeggiamenti!

Sempre per far conoscere il nostro territorio abbiamo portato gli ospiti a visitare il Frantoio Bonamini, che è stato anche il protagonista degli omaggi della festa.
Sabrina ci ha accompagnato in un viaggio tra storia, tecnica e macchinari moderni spiegandoci il complicato processo di estrazione del prodotto e concludendo il giro con una deliziosa degustazione.

La giornata è stata proprio come volevamo. L’argomento era di carattere lavorativo certo, ma ci tenevamo che fosse una vera e propria festa e i tanti sorrisi, racconti e ricordi hanno confermato il bellissimo legame che abbiamo con i nostri collaboratori.

 

Si sa, il nostro lavoro è fatto di macchine, processi, tecnologia, ma la chiave di tutto è il rapporto umano.

Non rimane che dire… ci vediamo al prossimo traguardo!

Foto di Roberto Mettifogo

Guarda tutte le immagini dell’evento su Facebook
Monitoraggio

Monitoraggio: ecco perché è importante

MONITORAGGIO: ECCO PERCHE’ E’ IMPORTANTE

Molti ricorderanno uno spot pubblicitario di qualche anno fa: “La potenza è nulla senza controllo”. Questa massima può essere ben applicata anche alle infrastrutture informatiche: non è così infrequente avere infatti a che fare con impianti potenti, ridondati in ogni loro componente e dotati delle migliori tecnologie sul mercato che poi vengono vanificati da un disco pieno su un server o da un servizio che va in errore.

Per dipingere un quadro più completo della situazione, a quella massima mi piace aggiungerne un’altra: “Non si può controllare ciò che non si conosce”. Un’affermazione che può sembrare banale, ma che in realtà è spesso il punto focale della questione: è assolutamente necessario infatti, nel progettare un sistema di controllo, possedere una visibilità a 360° dei sistemi coinvolti nei processi e delle loro interazioni, proprio per evitare che un singolo servizio o parametro fuori controllo (di solito proprio quello a cui nessuno aveva pensato) possa bloccare l’erogazione di un servizio o peggio, innescando il tipico “effetto domino”, l’erogazione di più servizi in cascata.

Ancora prima quindi di decidere quale strumento o tecnica di controllo adottare, è indispensabile anzitutto individuare i sistemi e i parametri da tenere sotto controllo determinandone anche le soglie di corretto funzionamento, le modalità di calcolo dei parametri e le modalità di segnalazione in caso di anomalia, cercando per quanto possibile di non dimenticarsi nulla. Infatti, tutto sommato, la scelta del sistema di monitoraggio non è così cruciale come si può pensare: molto più importante è sapere cosa controllare e impostare gli avvisi in modo che siano mirati e circoscritti a situazioni di effettiva anomalia, evitando così di inondare il povero personale IT di segnalazioni numerose e ripetute che dopo un po’ non vengono più nemmeno lette, all’interno delle quali si possa poi nascondere quell’unica segnalazione davvero importante che necessita di immediata attenzione.

Detto questo, scendiamo un po’ più nel dettaglio.

Partendo dal “basso”, si inizia con lo strato hardware: pressoché tutti i sistemi sono dotati di schede di gestione in grado di inviare segnalazioni in caso di problemi di natura hardware. Si tratta di schede presenti sulle motherboard dei server (IMM per IBM, ILO per HP, iDRAC per Dell e così via) che, opportunamente configurate, sono in grado di segnalare proattivamente problemi legati al funzionamento delle componenti hardware del sistema, ad esempio ventole o alimentatori non funzionanti, moduli di memoria guasti, dischi offline etc; strumenti analoghi sono disponibili su componenti come storage, unità nastro, moduli UPS, apparati di rete, sensori di controllo ambientale etc.

Una corretta impostazione di questi parametri consente di individuare e segnalare un problema hardware pressoché nel momento stesso in cui si verifica e provvedere quindi alla sua gestione prima che il problema impatti sul livello superiore, quello su cui operano i servizi.  Va detto che i sistemi sono usualmente progettati con un livello interno di ridondanza, che consente di gestire il singolo guasto senza impatto sul funzionamento del sistema stesso: l’importante qui è intercettare il problema e gestirlo immediatamente, spesso con la sostituzione della parte guasta, prima che l’eventuale aggiunta di un secondo problema possa a quel punto avere un impatto percettibile sul funzionamento. A questo livello il filtraggio degli eventi non è così importante: un problema hardware è un problema hardware e quando si manifesta va gestito tout court.

Una volta inventariato e coperto lo strato ‘basso’, si sale di livello e si arriva allo strato di infrastruttura; di questo strato fanno parte i sistemi di virtualizzazione (gli host facenti parte di una farm VMware ad esempio), i sistemi storage (cluster di sistemi dischi come IBM Hyperswap, infrastrutture Hyperconverged, cluster Netapp etc), l’infrastruttura di rete interna ed esterna (switch, collegamenti da/con l’esterno etc); anche in questo caso le varie console di gestione, dal VCenter Server per la farm VMware al software ONTAP per i sistemi NetApp per citare un paio di esempi, hanno ampia possibilità di segnalare eventuali anomalie e sono quindi in grado di riportare problemi ed eventi di varia natura ed importanza. A questo livello comincia a diventare importante il filtraggio degli avvisi: ad esempio VCenter consente di segnalare molteplici eventi sull’infrastruttura virtuale (tra questi: datastores saturi, perdita di ridondanza del collegamento di rete o verso lo storage, utilizzo anomalo di memoria o processore etc), ma solo una parte di essi sono davvero significativi e l’abilità di chi configura sta proprio nel scegliere i parametri importanti nel “mare magnum” di avvisi disponibili.

Salendo ancora di livello, si arriva finalmente allo strato dove operano i sistemi, ovvero lo strato dei sistemi operativi e dei servizi; qui il tema si fa più complicato perché a questo livello il filtraggio diventa la parte più importante del lavoro di configurazione: è infatti tutto sommato semplice mettere sotto controllo “tutto” di un server: spazi disco e carichi su memoria e processore, raggiungibilità, porte di comunicazione, servizi presenti sul server… più difficile, proprio perché bisogna scendere nel merito delle attività che un server gestisce, è però scegliere tra tutti questi parametri quello che davvero è importante monitorare.

Infatti, parlando nello specifico di server su piattaforma MS Windows, su ogni server solitamente è attivo un numero relativamente elevato di servizi, parecchi dei quali sono servizi standard di sistema operativo; ma solo una piccola parte di questi servizi sono fondamentali per le attività che quel server deve gestire, ed è molto importante concentrare l’attenzione su quei servizi critici, proprio per evitare di confondere avvisi importanti con avvisi trascurabili e, in caso di anomalia, essere subito guidati in modo il più possibile diretto ad individuare cause e correlazioni ed arrivare così ad una gestione rapida ed efficiente dei problemi.

Molto spesso presso vari clienti sento la fatidica frase “con il software x faccio una scansione della rete e in 10 minuti ho il sistema di monitoraggio up&running che mi controlla tutto”; sicuramente molto comodo, questo controllo totale fa però perdere di vista la necessità di individuare i servizi fondamentali di un server (e oltretutto non richiede nemmeno di avere conoscenza di ciò che si sta controllando, il che collide con la seconda regola con cui ho iniziato l’articolo), e inonda l’IT di messaggi di errore rendendo difficile, e sicuramente poco efficiente, individuare cause e correlazioni.

Ecco quindi che su questo terzo strato l’esperienza diventa importante: il consulente esperto sa bene dove si possono annidare i problemi e, accanto ad un “nocciolo duro” di controlli obbligatori su ogni server indipendentemente dalla sua funzione, sa inserire i controlli più opportuni.  Alcuni dei quali, va detto, possono anche essere controlli esterni al server stesso, come le simulazioni di attività utente: per fare un esempio concreto, è plausibile che un server che eroga servizi web vada controllato nei confronti della risposta su determinate porte di comunicazione (http/s tipicamente), ma questo non è sufficiente a garantire che il servizio erogato stia funzionando correttamente: è necessario simulare un’operazione di prelievo della pagina web, che sarà quindi in grado di avvisarci non solo se la porta di comunicazione non risponde, ma soprattutto se l’applicazione che genera la pagina sta funzionando correttamente.

Altro aspetto fondamentale è la gestione post-attivazione del sistema di monitoraggio, sia dal punto di vista della pulizia degli eventi ricorrenti, sia per il successivo adeguamento in caso di modifiche all’infrastruttura: è infatti del tutto normale che quando si mette un’infrastruttura sotto controllo si rivelino contestualmente, specialmente per quanto riguarda il terzo strato, tutta una serie di “comportamenti” della nostra infrastruttura di cui probabilmente nessuno era del tutto consapevole: servizi che si stoppano e ripartono a causa di processi di manutenzione programmata, carichi di processore dovuti ad elaborazioni notturne, spazi disco che si riempiono e poi si svuotano per operazioni di varia natura… sono tutti esempi concreti di cosa può emergere durante le prime settimane di vita di un sistema di monitoraggio. Alcuni eventi riveleranno anomalie, che andranno quindi gestite e risolte, altri eventi invece risulteranno normali e come tali andranno gestiti, configurando il sistema di monitoraggio in modo che non riporti all’IT quegli eventi ricorrenti.  Questo affinamento del sistema di monitoraggio è un lavoro che può durare settimane ma è importante che sia gestito tenendo sempre a mente la regola di base che gli avvisi devono essere pochi e mirati, altrimenti un sistema di controllo diventa di fatto inutile.  Analogamente, è fondamentale che a fronte di una modifica all’infrastruttura (un nuovo server introdotto in rete, nuovi servizi o nuovo hardware) il sistema sia subito adeguato con le opportune modifiche: non c’è nulla di peggio di un sistema di monitoraggio abbandonato dove mancano parte dei sistemi e che ci fa quindi serenamente ritenere di essere perfettamente a posto quando invece dietro di noi si sta preparando a nostra insaputa la tempesta perfetta.

Ultime due osservazioni: dove è opportuno posizionare il sistema di monitoraggio e come fare arrivare gli avvisi a destinazione.

E’ chiaro che il posizionamento ottimale per un sistema di monitoraggio non è all’interno del sistema che si sta monitorando, sarebbe come tagliare il ramo su cui si è seduti. Il sistema di monitoraggio dovrebbe sempre trovarsi all’esterno dei sistemi che controlla, magari in una sala server separata, sicuramente su hardware separato rispetto ai sistemi oggetto dei controlli, in modo che in caso di caduta generale dei sistemi non cada banalmente anche il sistema di monitoraggio stesso. Solitamente allo scopo viene utile un hardware anche di recupero su cui installare il sistema di controllo: normalmente i sistemi di monitoraggio non richiedono risorse importanti ed anche un vecchio server può così ritrovare una nuova giovinezza.  Riguardo la modalità di recapito degli avvisi, è chiaro che la forma della email è quella preferita: le email si possono gestire, categorizzare, filtrare, e solitamente vengono lette in tempo reale dato che via email gestiamo ormai il 90% delle comunicazioni con colleghi ed esterni.  Certamente se ad essere in crisi è proprio il sistema di posta elettronica la sola email può non essere sufficiente: ecco quindi che è assolutamente opportuno affiancare all’invio delle email anche sistemi di invio per vie alternative, ad esempio via SMS, che segnalino solo un sottoinsieme estremamente selezionato degli avvisi, ad esempio blocchi del sistema di posta o blocchi relativi alla rete, che impedirebbero alla email di essere correttamente recapitata, sia all’interno che verso fornitori esterni.

Riassumendo: l’implementazione di un sistema di monitoraggio è tutt’altro che banale, perché richiede una profonda conoscenza dell’infrastruttura oggetto di controllo e delle dinamiche in essa operanti. Tutto sommato la scelta di quale strumento usare diventa secondaria rispetto all’importanza di costruire filtri efficaci e soprattutto di individuare cosa esattamente controllare, sicuramente è fondamentale che lo strumento sia adattabile proprio per poterlo plasmare nel modo più opportuno rispetto all’infrastruttura da controllare.

Alcuni nomi popolari sul mercato sono PRTG, Zabbix, Solarwinds, Nagios.  Quest’ultimo è lo strumento proposto da Surftech, che ne utilizza la versione open source e ha nel tempo e con l’esperienza costruito una solida base che consente di gestire pressoché la totalità delle situazioni che si possono presentare (tra queste interrogazioni di apparati via SNMP, gestione di query WMI, disponibilità di grafici di andamenti nel tempo dei vari parametri, disponibilità di plugin per interrogazioni su vari ambienti e apparati). La diffusione di Nagios, che ne fa uno degli strumenti di monitoraggio più utilizzati a livello mondiale, la disponibilità di codici open source e di una sterminata libreria pubblica di plugin, rende particolarmente agevole la gestione degli ambienti più disparati; ad oggi possiamo affermare che non ci si è ancora presentato un caso di “ambiente non monitorabile”.