Come iniziare a prendere sul serio la Database Security?

id-100410579Nonostante un security breach del DB possa essere disastroso, costando milioni di euro e causando la perdita di clienti e di posti di lavoro, la Database Security non sta ricevendo l’attenzione che merita.

Da un recente sondaggio, a cui hanno partecipato 209 dipendenti informati sul Database Management della propria azienda, è emerso che:

  • nel 47% delle aziende non vi è nessuno che si occupi di sicurezza del DB;
  • il 39% delle aziende non ha la possibilità di monitorare real-time il proprio database, dando ai potenziali hacker il tempo sufficiente per operare sul DB prima che qualcuno se ne accorga;
  • solo il 19% degli intervistati considera “eccellente” la visibilità che ha del proprio database, mentre più della metà (il 59%) non sa con certezza quali utenti, clienti o applicazioni abbiano effettivamente accesso al DB.

Quali sono le più grandi preoccupazioni delle aziende circa la sicurezza del database? 

Mentre il 50% degli intervistati ritiene che la compromissione delle credenziali costituisca il più grande rischio per l’azienda, il 47% afferma che l’incapacità di anticipare l’individuazione delle violazioni di dati sia invece una delle questioni più gravi. A queste preoccupazioni si aggiungono i tempi d’inattività provocati da eventuali infiltrazioni all’interno del network.

A causa delle numerose minacce alla sicurezza del database, sempre più aziende stanno diventando consapevoli del problema e si stanno attivando per risolverlo. Secondo le previsioni, nel corso del prossimo anno, l’enfasi sulla sicurezza del DB dovrebbe aumentare dal 40% al 54%.

Le aziende possiedono le giuste competenze e tecnologie per gestire la Database Security?

Molti intervistati hanno sostenuto di avere un database estremamente vulnerabile a potenziali security breaches. Il 39% ha affermato di non avere strumenti di rilevamento in grado di individuare una violazione delle credenziali. Solo il 21% ha dichiarato di essere in grado di scoprire immediatamente una compromissione delle credenziali, mentre il 34% ha detto che ci sarebbe voluto un giorno, e il 18% ha detto che avrebbe bisogno di una settimana per risolvere il problema. Il resto degli intervistati avrebbe bisogno di almeno un mese, o più.

Come iniziare a prendere sul serio la sicurezza del database?

Il mondo della sicurezza del DB ha ancora una lunga strada da percorrere prima che le aziende possano sentirsi veramente sicure circa la sicurezza dei propri dati. Organizzazioni e aziende devono ancora fare molto per garantire che le informazioni personali dei propri clienti siano sicure e che i dati riservati dell’azienda siano visibili solo a chi di dovere.

Il primo step da seguire è senza dubbio l’allineamento della sicurezza aziendale con l’implementazione della metodologia DevOps, con l’intento di migliorare la qualità dei processi, automatizzando le operazioni e accelerando l’individuazione delle falle di sicurezza.

A Natale Emerasoft ti offre il SecDevOps ToolKit, una selezione di licenze temporanee per ottimizzare la gestione del rischio a livello Enterprise, integrando Cyber Security e DevOps: richiedilo subito scrivendo a sales@emerasoft.com

Image courtesy of Geerati at FreeDigitalPhotos.net

Come iniziare a prendere sul serio la Database Security?

L’integrazione tra DevOps e Cyber Security: nasce così il SecDevOps

id-100428844Bug. Falle di sicurezza. Rallentamenti. Si tratta d’imprevisti costosi, difficili da riparare, e che possono causare una reputazione negativa da cui è complicato liberarsi.

Il DevOps può gestire questi rischi?

Sì. Il DevOps, se implementato correttamente, può essere uno strumento estremamente utile: è stato rilevato che i reparti IT che utilizzano metodi DevOps rilasciano software (con successo) 200 volte più frequentemente rispetto a quelle imprese che non seguono pratiche DevOps. Tuttavia, è necessario che le aziende non puntino solo ed esclusivamente alla velocizzazione dei rilasci, senza prendere in considerazione il tema legato alla sicurezza.

Il DevOps ha fatto passi da gigante nel corso degli ultimi cinque anni, eppure c’è ancora un ulteriore step da compiere per ottimizzare la gestione del rischio a livello Enterprise: integrare pienamente la Cyber Security al suo interno.

Sia le risorse operanti in ambito DevOps che i team di Security hanno bisogno di soddisfare obiettivi reciproci: infatti, così come il DevOps mira a sviluppare e rilasciare il software rapidamente, la Security intende mitigare e gestire il rischio controllando accuratamente qualsiasi elemento fragile o violabile all’interno del software.

Come velocizzare dunque l’innovazione integrando all’interno della metodologia DevOps appropriate soluzioni di Cyber Security?

Se lo scopo è migliorare l’efficienza delle imprese ottimizzando la gestione della sicurezza e del rischio, la strada è avvicinare la metodologia DevOps alle pratiche di Cyber Security, avviando un processo di convergenza tra questi due approcci.

Nasce così ciò che è stato definito il “SecDevOps”, un approccio volto a perseguire un perfetto allineamento tra il DevOps e il mondo della sicurezza informatica, con l’obiettivo di:

  • ottimizzare il Risk Management;
  • accelerare l’individuazione di falle di sicurezza;
  • automatizzare e orchestrare le change necessarie nelle catene dei servizi di sicurezza.

La transizione verso il “SecDevOps” aprirà le porte ad un modo più dinamico e sicuro di gestire le infrastrutture e il deployment automatizzato, facendo della sicurezza una responsabilità condivisa da tutta l’organizzazione e una realtà ben salda a tutte le tappe del processo di sviluppo.

Richiedi il tuo SecDevOps Toolkit gratuito: scrivi a sales@emerasoft.com

Image courtesy of cookie__cutter at FreeDigitalPhotos.net

L’integrazione tra DevOps e Cyber Security: nasce così il SecDevOps

Il DevOps come soluzione per la Cyber Security

soluzione per la cyber securityLe aziende si trovano oggi strette in una trappola determinata dalla necessità di rilasciare prodotti e servizi di miglior qualità in tempi più rapidi, e al contempo dall’esigenza di tutelare i dati e le informazioni sensibili in un mercato sempre più minacciato da hacker e frodi informatiche.

Ma è possibile puntare a rilasci migliori e più veloci senza sacrificare la sicurezza aziendale?

La protezione della proprietà intellettuale e dei dati sensibili è una grande sfida per le aziende. Un sondaggio* svolto su oltre 800 Senior Business Manager e professionisti IT ha riscontrato nell’89% degli intervistati una forte preoccupazione riguardo a potenziali attacchi sull’Intellectual Property.

Infatti, nonostante le grandi imprese dedichino ingenti risorse per salvaguardare informazioni e operazioni aziendali, le violazioni dei dati rappresentano tuttora una minaccia quotidiana. I più grandi attacchi (ossia quelli che coinvolgono più di 30.000 record) sono, infatti, in grado di compromettere l’integrità dei dati delle imprese di qualsiasi settore.

Nonostante i progressi compiuti in ambito Security, i tool di sicurezza presenti sul mercato tutelano i dati a livello perimetrale, senza securizzare al contempo la fonte di tali dati. La maggior parte delle soluzioni non riesce a mitigare completamente attacchi e frodi informatiche.

Questa sfida è aggravata dal fatto che i product team sono dispersi a livello globale, con appaltatori e partner commerciali esterni che collaborano su più asset (come codice sorgente, file binari, firmware, hardware, immagini, file e video, ecc). Spesso tali dati vengono memorizzati in repository non sicuri caratterizzati da poche restrizioni, rendendo la proprietà intellettuale vulnerabile a errori o accessi indesiderati.

Le cose si complicano ulteriormente per i settori soggetti a severe policy di compliance, come i settori alimentare, farmaceutico, medicale, automotive e aerospace, obbligati a garantire la tracciabilità dei dati, l’applicazione delle policy, e la revisione delle change per un rispetto assoluto della conformità normativa.

Quindi, come proteggere la proprietà intellettuale delle aziende consentendo al contempo di accelerare lo sviluppo, migliorandone la qualità?

Una valida soluzione è la metodologia DevOps che, oltre a favorire una miglior affidabilità e qualità dei rilasci, garantisce una migliore governance dei dati e, quindi, una maggior sicurezza. Se implementato correttamente, il DevOps non solo aiuta le aziende a rilasciare applicazioni più velocemente, ma ottimizza la Cyber Security.

Grazie a:

  • autenticazione flessibile
  • sicurezza elevata delle password
  • controlli granulari degli accessi
  • massima visibilità dei log di audit
  • riproduzione sicura
  • integrazione tra tool

è possibile catturare eventuali falle di sicurezza all’inizio dell’interno del ciclo di sviluppo.

Per saperne di più SCARICA IL WHITEPAPERPerforce Helix: Security & Compliance with Intellectual Property

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Image courtesy of jscreationzs at FreeDigitalPhotos.net

Il DevOps come soluzione per la Cyber Security

5 consigli fondamentali per evitare il downtime del database

id-100228532Il downtime del DB è un problema molto diffuso che può costare caro: in media, i tempi di inattività del DB costano $ 7.900 al minuto, con un incremento del 41% negli ultimi due anni. L’80% del downtime è dovuto a errori umani e la durata media delle interruzioni è di 90 minuti, raggiungendo un totale medio di 97 ore all’anno.

Dati gli ingenti costi, i DBA dovrebbero cercare di limitare al minimo i rischi di downtime. Ma come?

Ecco 5 consigli fondamentali:

  1. Assicurarsi di iniziare la migrazione solo dopo aver esaminato le applicazioni, i processi e gli utenti importanti, per determinare ciò che deve essere spostato e ciò che invece deve rimanere dove si trova. Non iniziare la migrazione finché non si è pensato agli ambienti esistenti e non si è considerato il potenziale impatto sui flussi di lavoro e sulle infrastrutture.
  2. Evitare di incasinare il regolare funzionamento, in modo che utenti e colleghi non si sentano frustrati. Schedulare fuori orario le operazioni di migrazione ad alta intensità di risorse può essere utile se si pensa che queste attività possano causare tempi d’inattività per il database.
  3. Se la migrazione sta richiedendo un po’ di tempo, fare in modo che gli utenti non rimangano bloccati in differenti versioni del database o in prodotti completamente diversi. Cercare di offrire una convivenza tra i vecchi e i nuovi sistemi, in modo che tutti gli utenti possano continuare a svolgere i task necessari senza alcun problema.
  4. Per evitare la perdita di dati, considerare un piano di recovery e backup. Durante la migrazione è importante non perder traccia di ciò che si deve fare per ripristinare improvvisamente i dati a metà del progetto.
  5. Non dimenticare che il project management gioca un ruolo chiave nelle migrazioni e negli aggiornamenti ben eseguiti. Infatti, il lavoro del DBA deve comprendere anche la pianificazione, la comunicazione, la gestione delle risorse e il reporting sui progressi; facendo attenzione a tutti questi task si evitano successive confusioni.

Questi sono i cinque consigli chiave per una migrazione o un update di successo. Per garantire un processo regolare, è fondamentale che ogni punto sopraelencato sia considerato accuratamente prima di procedere.

Scopri quali sono i vantaggi derivanti dall’automazione del database: scarica il whitepaper “Automation A Win-Win for Database Administration and DevOps”.

Vai all’articolo completo.

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Image courtesy of watcharakun at FreeDigitalPhotos.net

5 consigli fondamentali per evitare il downtime del database

Test & Quality Management: il DevOps può essere d’aiuto?

Di fronte all’attuale evoluzione dello svilppo software, come stanno reagendo il Test & Quality Management?

Una volta, occuparsi degli aspetti della qualità significava rispettare rigorosamente una lista ben definita di criteri di rilascio, come ad esempio una percentuale di test positivi superiore al 95% o il controllo del codice superiore al 65%. Tutto, infatti, doveva essere impresso su un supporto da distribuire: una scheda perforata, un floppy, un CD, un DVD. Oggi, invece, i bug si possono correggere velocemente, e si utilizzano il “cloud”, gli “utenti virtuali” o i “containers”.

Il lavoro del Test Engineer è quindi diventato più facile? Non proprio, anzi, forse è diventato più difficile, di sicuro più complicato. La Quality Assurance si trova di fronte a nuove tipologie di problemi, come ad esempio:

Quanto spesso bisogna effettuare nuovi rilasci?

Come si fa a sapere se tutto funzionerà correttamente quando verrà eseguito il deploy? Come effettuare un rollback in caso di fallimento? 

Come si può coordinare il deploy tra diverse piattaforme?

Anche se il deploy è andato bene, come sapere se il servizio continua a funzionare o se i server sono crashati, rallentati, o sono stati hackerati?

È positivo vedere che un numero crescente di aziende sta maturando le proprie pratiche QA per sostenere l’innovazione digitale nel mercato competitivo di oggi. La logica legata al business viene costantemente convalidata, sia in modo automatico che manuale.

Ma ci sono due aspetti importanti nel processo di delivery che rimangono comunemente “non testati”: il provisioning e il deploy su tutti gli ambienti. Purtroppo, infatti, molti problemi di produzione sono legati a failure durante il questi due passaggi, spesso manuali. Secondo un sondaggio 2016 di Forrester, solo il 16% delle aziende è in grado di effettuare correttamente provisioning e depoyment di build automatizzato. Questo dato implica che, anche se il team QA fosse in grado di rilevare tutti i defect nella logica di business, e lo sviluppo fosse in grado di risolvere tutti questi errori, ci sarebbero ugualmente problemi di produzione, proprio a causa della differenza di provisioning o deployment tra gli ambienti. Inoltre, il rischio di errori aumenta in modo significativo quando si usano processi manuali.

Il DevOps può essere d’aiuto?

SCARICA IL WHITEPAPER “The Value of DevOps for Test & Quality” per conoscere i benefici del DevOps nel contesto del Test & Quality Management.

Esiste una soluzione per allineare la logica di business con il provisioning e il deployment?

L’unico modo per favorire questo allineamento è trattare su tutte le piattaforme la logica di provisioning e deployment come il codice, e farla passare attraverso il processo di QA allo stesso modo della logica di business.

test & quality management

Siccome ogni ambiente ha delle impostazioni specifiche, occorrerebbe astrarre un ambiente all’interno di un template, con le variabili dell’environment e con specifici valori come mostrato nell’immagine sovrastante.

La combinazione di una logica di build, stage, provision e deploy con un corrispondente template di environment permette che la stessa logica venga utilizzata e testata in tutti gli ambienti e su tutte le piattaforme. Come risultato, la logica di delivery può diventare parte integrante del ciclo di QA e può essere testata più volte prima dell’uso effettivo in un ambiente di produzione, riducendo notevolmente il rischio di delivery ed errori correlati.

Conosci i benefici della Lean Application Delivery?

SCARICA IL WHITEPAPER “Lean Application Delivery: ROI potential” per scoprire come combinare la gestione del ciclo di vita di applicazioni e servizi, l’automazione di release e deployment e il configuration management all’interno di un unico tool, offrendo agli utenti una visione end-to-end ineguagliabile.

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Test & Quality Management: il DevOps può essere d’aiuto?

Change al DB? Impara a gestirle con un sistema DevOps

change al dbApportare continuamente nuove modifiche al dabatase è un’operazione cruciale, in quanto permette alle aziende di produrre risultati più velocemente e senza intoppi. Tuttavia, sono molteplici i problemi che possono verificarsi durante l’esecuzione delle change, e alcuni di questi possono essere particolarmente costosi.

Circa l’80% dei tempi di downtime del DB, infatti, è dovuto alle change. Queste interruzioni ricorrenti accadono perché i nostri sistemi sono diventati sempre più complessi. L’obiettivo sarebbe riuscire a eseguire ogni minima modifica all’interno di questi sistemi così ampi, che possono comprendere ambienti Web, Cloud e Mobile, senza alcuna problematica.

Per riuscirci è possibile adottare una strategia di Database Change Management, che garantisce l’esecuzione di transizioni e revisioni senza conseguenze.

Sono principalmente tre le sfide che tendono a presentarsi nell’implementazione del Database Change Management attraverso la sempre più adottata metodologia Agile:

  • L’incapacità di cogliere con precisione tutte le change legate alla configurazione;
  • troppi errori in fase di deploy o di produzione;
  • incapacità di effettuare operazioni di rollback.

Se non ci si occupa di questi problemi, non si fa altro che rallentare ulteriormente i processi aziendali. Quindi, come muoversi?

In molti sostengono che mettere sullo stesso piano tutte le change per poi eseguirne il deploy un’unica volta consenta di risparmiare tempo; in realtà il più delle volte succede esattamente il contrario: si generano molti più errori, perché ogni singola change non viene presa in considerazione prima del deploy.

Così, mentre la fase di sviluppo si è adattata ed è in grado di rilasciare rapidamente le change, le operations hanno bisogno di più tempo per monitorare ogni modifica prima che queste vengano pubblicate e distribuite. Questo è il problema che molte aziende stanno incontrando.

Ed è qui che entra in gioco il DevOps: anziché far comunicare lo sviluppo con le operations solo quando occorre introdurre una change, il DevOps considera sviluppo e operations come un unico team, responsabile della creazione dell’automazione, che consente che ogni elemento passi senza intoppi dal team di sviluppo al team operativo. Al fine di rendere sicure le change frequenti, è necessario un team in grado di eseguirne il deploy ed il monitoraggio in modo automatico.

Un sistema DevOps implementato tra lo sviluppo e le operations, assicura quindi che i due team collaborino alla velocità Agile, favorendo change sicure e costantemente monitorate ed evitando, quindi, costosi errori per l’azienda.

Vuoi saperne di più? Scarica il whitepaper “Database Development and Deployment Risks” per scoprire quali sono i principali rischi legati allo sviluppo e al deploy del database.

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Image courtesy of David Castillo Dominici at FreeDigitalPhotos.net

Change al DB? Impara a gestirle con un sistema DevOps

Un’implementazione DevOps di successo? Ecco i 10 consigli fondamentali

implementazione devopsCome noto, il DevOps sta diventando un fattore chiave all’interno di un crescente numero di aziende. Cosa stanno facendo per implementare con successo questa metodologia?

Se usato correttamente diventa uno strumento estremamente utile: è stato rilevato che i reparti IT che utilizzano metodi DevOps rilasciano software (con successo) 200 volte più frequentemente rispetto alle altre.

Ecco 10 consigli fondamentali di cui i tech leader dovrebbero tener conto per un’implementazione DevOps di successo:

  1. E’ importante che le politiche aziendali non interferiscano con la collaborazione tra il team di sviluppo e il team IT. Al team di sviluppo devono essere date la libertà e le risorse necessarie per favorire il successo del DevOps. Ciò si traduce in metodi agili che permettono di abbreviare i cicli di rilascio e ridurre i downtime del deploy. Tuttavia, la responsabilità fondamentale risiede nel management, che deve necessariamente sostenere il cambiamento culturale e abbattere i silos tra Dev e Ops.
  1. Non perdere di vista il motivo per cui si stanno svolgendo determinate attività. Spesso le persone si possono perdere in ciò che fanno, senza fare il punto sul perché lo stiano facendo e senza tenere in considerazione l’intera azienda. Sarebbe consigliabile procedere da un collo di bottiglia all’altro, migliorando ogni elemento, in modo tale che l’intero sistema continui a prendere velocità ed efficienza.
  1. Il DevOps come automatizzazione delle varie parti del sistema non prenderà il posto di lavoro di nessun componente dei team.DevOps significa cambiare il modo in cui i team di sviluppo e Operations lavorano.
  1. Il feedback continuo è un elemento cruciale per misurare l’efficacia del DevOps. Per ogni parte del processo, tra cui lo sviluppo, la progettazione e la gestione del prodotto, è importante utilizzare un feedback continuo per mantenere una visione lineare del processo di delivery e per imparare continuamente dai propri errori.
  2. Il lavoro di squadra e il rispetto reciproco non possono essere sottovalutati. Tutti i dipendenti hanno bisogno di essere allineati e lavorare insieme su obiettivi comuni.
  3. Non tardare nel gestire le questioni legate alla sicurezza. Prendere decisioni inerenti al DevOps senza considerare il fattore sicurezza può essere molto pericoloso. La sicurezza deve essere intesa come una caratteristica del prodotto e non come un fattore da affrontare in seguito.
  1. Prendere in considerazione i fornitori di terze parti, dai cui servizi dipende l’azienda. Per crescere è necessario costruire buone relazioni con i fornitori, i quali prosperano su un feedback onesto.
  1. Con il DevOps la conformità alle normative resta rilevante e gli sviluppatori non dovranno avere root access ai server di produzione, bensì useranno meccanismi simili che gestiscono tutti i server e minimizzeranno i potenziali problemi.
  2. Considerare che i team DevOps dedicano circa 25 ore alla settimana a monitorare gli ambienti cloud, togliendo del tempo necessario per le altre funzioni lavorative.
  3. Condividere con tutta l’azienda le informazioni e i progressi svolti. Gli aggiornamenti sullo stato di avanzamento e le notifiche delle failure possono allineare l’intera azienda, favorendo la produttività e la velocità.

Come tech leader prendete questi dieci consigli e assicuratevi di applicarli all’interno dell’azienda. Il DevOps non è qualcosa che s’implementa un’unica volta e che poi agisce come spettatore, ma una pratica che ha bisogno di essere costantemente aggiornata e migliorata.

Esiste una quantità infinita di cose che potete fare per aumentare la velocità della produzione e l’efficienza dei team; cominciate con l’implementazione di questi dieci consigli e compierete un passo da gigante nella giusta direzione.

Per scoprire quali sono i luoghi comuni sul DevOps e le best practices da seguire, scaricate il whitepaper “DevOps Misconceptions and Best Practices”.

Un’implementazione DevOps di successo? Ecco i 10 consigli fondamentali

I 6 super poteri per diventare un DevOps Hero

devops heroDi fronte alla crescente pressione del mercato, le aziende necessitano di rilasciare il più rapidamente possibile software di alta qualità. Per questa ragione si ha bisogno di strumenti in grado di evidenziare in modo automatico i componenti buoni, e non. Tuttavia, questo non è un compito facile, a causa dei miliardi di componenti Open Source e di terze parti utilizzati ogni anno attraverso caotiche supply chain del software.

La soluzione? Utilizzare dei superpoteri!

Intelligenza sovraumana

Sapere quali sono i migliori componenti all’interno di un’applicazione è davvero un compito arduo. Svolgere una ricerca sulla qualità dei componenti, infatti, non significa solo identificare se un determinato componente è vulnerabile, bensì comprenderne la causa.

L’intelligenza artificiale, in grado di individuare e comprendere le cause delle possibili vulnerabilità, è una delle principali features offerte dalla suite di prodotti Sonatype.

Vista a raggi X

I componenti software sono presenti lungo tutta la supply chain software. Vivono negli IDE, nei repository manager, nei centri di controllo qualità e nella produzione. Per identificare, monitorare e tracciare il loro utilizzo, è necessaria una visione esperta e approfondita, attraverso molteplici punti di integrazione.

Il portfolio Sonatype fornisce una visione a raggi X delle tecnologie più diffuse, tra cui Jenkins, Maven, Nexus Repository Managers, Docker, e altri ancora.

Se volete avere un assaggio della vista a raggi X all’interno delle applicazioni, fate un’analisi gratuita.

Potere rigenerante

L’intelligenza sovraumana e la visione a raggi X aiutano i team DevOps a identificare e rintracciare più velocemente i defect, riducendo l’MTTI (Mean Time To Identification). Oltre a questi, un superpotere altrettanto importante, necessario per tutti i team DevOps, è la capacità di guarigione che permette di accelerare il Mean Time to Remediation (MTTR).

Grazie alla suite di prodotti Sonatype, i team DevOps hanno una visione real-time di maggior qualità della propria supply chain del software e sono supportati tramite soluzioni di risanamento, in grado di sostituire i componenti dalle vulnerabilità note.

Campo di forza

Il campo di forza è rappresentato da Sonatype Nexus Firewall, introdotto nell’ottobre del 2015.

Nexus Firewall valuta ogni componente scaricato sul Nexus Repository Pro per assicurarsi che non ci siano vulnerabilità note e che ogni componente sia conforme alle policy aziendali.

Nexus Firewall rappresenta un vero e proprio campo di forza capace di respingere e mettere in quarantena i componenti malvagi.

Viaggio nel tempo

Per le pratiche DevOps, il lavoro non pianificato non è mai ben accetto. Eppure sappiamo tutti che i componenti invecchiano come il latte (più che come il vino): quando si scoprono vulnerabilità di sicurezza vanno a male. Quando ciò accade, i team devono sapere immediatamente se è stato utilizzato un componente con una vulnerabilità nota e, in caso affermativo, dove è possibile individuarlo.

Per i team al di fuori delle pratiche DevOps, questo passaggio richiede il monitoraggio e la valutazione manuale attraverso un portfolio di tutti i componenti di qualsiasi applicazione.

Diversamente, gli utenti di Nexus Auditor hanno accesso a un ulteriore superpotere: il viaggio nel tempo. Grazie ad un accurato Bill of Materials che permette di mantenere aggiornato e di monitorare l’inventario dei componenti di tutte le applicazioni in produzione, Nexus Auditor può immediatamente tornare indietro nel tempo fornendo ai team informazioni accurate su dove si trovano i componenti che presentano dei defect, riducendo il Mean Time To Detect (M-T-T-D).

Velocità sovraumana

L’ultimo superpotere di cui i team DevOps dovrebbero dotarsi è la velocità. Quando si tratta di analisi, identificazione, monitoraggio e risanamento dei componenti difettosi è bene sapere che possono essere compiute in pochi secondi.

I team DevOps possono sostituire gli sforzi manuali, che un tempo richiedevano settimane, per l’identificazione e l’analisi del ciclo di vita di sviluppo. Ciò che prima richiedeva una valutazione di due settimane, ora richiede due minuti, segnando un miglioramento nelle performance di 10.000 volte.

I pericoli che si sono insediati in passato nel settore dell’auto non devono essere ripetuti in alcun ambito software.

È possibile. Se equipaggiati con la giusta intelligenza, vista, protezione e velocità, i team DevOps possono incorporare fin dall’inizio un maggior livello di qualità all’interno dei propri processi.

Ora, è più facile che mai assemblare il proprio gruppo di eroi e di super poteri per raggiungere un vera e propria supremazia in ambito DevOps.

E tu, sei sicuro della salute delle tue applicazioni? Scoprilo gratuitamente in 5 minuti.

 

Per maggiori informazioni SCARICA IL REPORT “2016 Software Supply Chain Report” e GUARDA IL WEBINAR ON DEMAND per scoprire i dati provenienti dalla ricerca condotta da Sonatype nexus su su 3.000 aziende e più di 25.000 applicazioni.

 

Segui i nostri canali LinkedIn e Twitter per ricevere gli articoli pubblicati sul blog.

Image courtesy of Sira Anamwong at FreeDigitalPhotos.net

I 6 super poteri per diventare un DevOps Hero

Cinque consigli per implementare con successo l’Enterprise Agile

enterprise agileQuando si decide di intraprendere il cammino verso l’Enterprise Agile, cosa succede a quei piccoli (e accettabili) errori che si sono commessi nell’utilizzo dell’Agile, ma che da ora non saranno più così tollerabili?

Ecco 5 consigli per un’adozione Agile a livello Enterprise di successo:

  1. Metti alla prova la decisione di muoverti verso l’Enterprise Agile.

Fallo solo se sei veramente soddisfatto della tua adozione Agile e se hai bisogno di una soluzione più pervasiva all’interno dell’azienda.

Infatti, è sconsigliabile muoversi verso l’Enterprise Agile solo perché non si è soddisfatti di come l’Agile sia stato implementato, o perché si pensa che l’Enterprise Agile sia in grado di risolvere i problemi incontrati nell’adozione dell’Agile a livello di team/progetto.

  1. Se credi che la tua azienda non sia adatta a team e progetti Agile, allora non sei pronto per l’Enterprise Agile.

Se pensi…

  • “Utilizzando alcune pratiche Agile trasformeremo il nostro Enterprise waterfall in Enterprise Agile”.
  • “Oh, bene: non possiamo usare l’Agile a livello di team perché siamo troppo grandi, quindi passiamo direttamente all’Enterprise Agile”.

…allora il tuo tentativo di Enterprise Agile sarà un fallimento.

  1. Non pensare che l’Enterprise Agile sia una burocrazia per far sì che i team rimangano Agile, o sia qualcosa che permetta alle aziende non-Agile di avere un maggior controllo.

L’Agility, infatti, è una mentalità. E l’Enterprise Agility è una mentalità prettamente aziendale.

  1. Utilizza un approccio incrementale.

Ci sono un paio di approcci per abbracciare l’Enterprise Agile: l’approccio “one shot” e l’approccio basato su miglioramenti pianificati nel corso del tempo.

E’ evidente come il primo approccio non funzioni. Nell’articolo “Seven Sins of Scrum and other Agile Antipatterns Seven Sins of Scrum and other Agile Antipatterns” il concetto di incrementalità è chiaramente indicato come consiglio conclusivo per i cosiddetti “Agilists”:

  • Utilizzare retrospettive
  • Migliorare l’incrementalità
  • Scegliere 1 o 2 item alla volta
  • Far affidamento al training e al coaching se necessario.
  1. Ultimo consiglio, ma non meno importante: utilizza il giusto tool.

Se utilizzare uno strumento sbagliato era un problema nell’Agile, questo rappresenterà sicuramente un incubo nell’Enterprise Agile. Infatti, i processi di Enterprise Agile sono di gran lunga più complessi dei processi Agile. Ciò è ovvio, in quanto i primi coinvolgono molte più persone all’interno dell’azienda e toccano, oltre al “solo” sviluppo software, molte altre attività.

Dunque, occorre seguire un approccio incrementale nell’adozione dell’Enterprise Agile, e il successo si concretizzerà nel miglioramento (frequente o continuo) dei processi.

In conclusione, nell’adozione dell’Enterprise Agile hai bisogno di:

  • un toolset in grado di coprire molteplici discipline;
  • un toolset in grado di supportare in modo incrementale pratiche e processi;
  • un toolset che incorpora la conoscenza dei processi e guida gli utenti attraverso i processi stessi;
  • un toolset che consente di misurare la qualità dei processi;
  • un toolset pronto ad abbracciare facilmente i miglioramenti dei processi.

A quale soluzione fare affidamento per raggiungere e implementare correttamente l’Enterprise Agile?

Contatta gli esperti!

Cinque consigli per implementare con successo l’Enterprise Agile

Cinque cose che il tuo team di Operations non ti ha detto sul DevOps

Cinque cosa da sapere sul DevOpsIntendete implementare il DevOps? Ecco cinque considerazioni per farlo meglio.

– Il DevOps è più Dev che Ops

Il DevOps si è generato dalle esigenze degli sviluppatori. I tool sono stati ottimizzati per le fasi iniziali del ciclo di vita dell’applicazione (sviluppo/test), diventando particolarmente efficienti nel prototipizzare ambienti operativi semplici.

La maggior parte dei tool DevOps, infatti, è più adatta a soddisfare le esigenze degli sviluppatori, anziché quelle dei team di operations. La maggior parte dei tool non è stata progettata pensando ai complessi ambienti di produzione o alle vaste applicazioni mission critical di oggi.

– Le operations possono essere più agili senza partire da zero

Le persone si lamentano dei runbook IT. E’ comprensibile, poiché sono lenti e non automatizzati. Alcuni sostengono che tutti questi processi dovrebbero essere sostituiti con degli strumenti DevOps.

Tuttavia, occorre considerare che i processi IT esistenti sono già collaudati. A volte vale la pena chiedersi se in determinate situazioni l’automazione di runbook e workbook possa essere una soluzione migliore rispetto al DevOps.

– Il DevOps non è adatto agli ambienti di produzione complessi

Vuoi mettere insieme uno stack LAMP ed eseguire alcuni test di integrazione? Niente lo fa meglio del DevOps.

Vuoi gestire e mantenere un’applicazione a sei livelli, equilibrata e rule-based con un database federato utilizzando una master-master replication e più slave? Nulla distrugge quell’ambiente più velocemente del DevOps.

Bisogna ricordare che il DevOps non deve essere l’unica scelta, soprattutto quando si tratta di ambienti complessi. I requisiti degli sviluppatori non sempre si sovrappongono al 100% con le esigenze dei team di operations.

– L’implementazione del DevOps potrebbe peggiorare le cose prima di migliorarle

Implementare il DevOps a volte può dare l’impressione di abbandonare la strada principale per prendere un sentiero. I tool DevOps si approcciano alle operations in un modo completamente nuovo. Non abbracciano le pratiche IT standard. Hanno un modo diverso di costruire gli ambienti con una serie di istruzioni che hanno poco in comune con runbook e workbook. Nella trasizione al DevOps ci si sentirà sicuramente confusi, ma preparatevi ad avere le cose disfatte inizialmente se il DevOps è la vostra unica strategia di automazione.

– L’Open Source non è sempre così importante quanto la robustezza

Dieci anni fa, quando tutti parlavano male dell’Open Source a favore del software proprietario, la maggior parte si sbagliava.

Oggi invece tutti screditano il software proprietario in favore dell’Open Source, come se l’Open Source implicasse automaticamente qualcosa di positivo.

Non tutti i software Open Source però sono robusti, così come non tutti i software robusti sono Open Source. Per le operazioni IT, l’essere collaudato deve sempre essere più importante dell’essere Open Source. Voi salireste sul volo inaugurale di un aereo?

Allora? Eravate a conoscenza di questi cinque punti?

Sono tanti i benefici che derivano dall’adozione di pratiche Agile nel settore IT di oggi, ma se non siete consapevoli e preparati di quali siano gli aspetti negativi che si possono presentare, rischiate di provocare guai seri a tutti i soggetti interessati.

Come partire con il DevOps con il piede giusto?

Approfitta dell’Emerasoft On Tour, un’occasione unica per organizzare una tavola rotonda direttamente presso la vostra sede con cui valutare, grazie al supporto degli esperti DevOps di Emerasoft, il livello di maturità DevOps della vostra azienda e disegnare il piano di adozione di un primo progetto DevOps.

Cinque cose che il tuo team di Operations non ti ha detto sul DevOps