Verifiche al database: quali i vantaggi?

verifiche al databaseLe verifiche del database, come quelle effettuate in caso di audit, permettono di indagare le responsabilità, di rilevare le intrusioni e analizzare i problemi, evitando al business un terribile crollo.

Gli audit, registrando tutte le attività del sistema, rilevano le violazioni di sicurezza, i problemi di prestazione e i flussi dell’applicazione. Le verifiche del DB forniscono quindi informazioni fondamentali sulle operazioni eseguite, sugli utenti che le svolgono e sulla data e l’ora di esecuzione, mitigando potenziali rischi e fornendo informazioni utili per ridurre il carico di lavoro per il DBA.

Sfruttare le verifiche del database su base regolare può dunque fornire dei bei vantaggi. Eccone i principali quattro:

  1. Responsabilità

La responsabilità è uno dei concetti più importanti sul lavoro, in particolare all’interno di un contesto DevOps. È attraverso la verifica del DB che i CIO e i DBA possono lavorare insieme per promuovere e garantire una maggiore responsabilità, tenendo traccia di tutti i cambiamenti e accrescendo il senso di fiducia e responsabilità tra gli sviluppatori.

  1. Analisi dei problemi

La capacità di identificare, diagnosticare e risolvere i problemi interni al sistema rientra nei task quotidiani di ogni DBA. Le verifiche del DB, attraverso l’utilizzo di strumenti online, permettono di identificare questi problemi in tempo reale.

L’auditing real-time viene comunemente implementato per monitorare lo stato dei processi e, grazie alla connessione online, le tecniche di analisi rimangono sempre aggiornate. I registri delle prestazioni del sistema completano questo meccanismo, osservando eventi quali l’aumento dell’utilizzo delle risorse del sistema o l’utilizzo del modem. Tali eventi possono non significare nulla, così come a volte possono indicare una violazione della sicurezza.

  1. Rilevamento delle intrusioni

Attraverso l’auditing, gli utenti hanno una minor probabilità di violare la sicurezza o modificare i dati in modo improprio. Le verifiche del database limitano l’utilizzo delle risorse del sistema, consentendo agli utenti l’accesso solo a risorse predefinite.

Anche se il rilevamento real-time delle intrusioni è rivolto principalmente agli utenti esterni che tentano di accedere ad un sistema specifico, questa operazione può essere anche utilizzata per rilevare problemi legati alle prestazioni interne del sistema.

In sintesi, il rilevamento delle intrusioni fa sì che sia gli sviluppatori che il management siano consapevoli dei problemi (esterni ed interni) prima ancora che questi minaccino i dati dell’azienda.

  1. Ricostruzione degli eventi

Se un sistema presenta un qualche problema, gli eventi che portano all’anomalia possono essere analizzati e ricostruiti attraverso l’auditing del DB.

Il Database Risk Management, infatti, può essere massimizzato grazie alla revisione delle verifiche, che permette di individuare come, quando e perché il problema si è verificato. Oggi, le verifiche sono abbastanza intelligenti per comprendere la differenza tra gli errori dell’operatore e quelli creati dal sistema. Sapere esattamente quali condizioni hanno causato il problema può essere estremamente utile per evitare problemi simili in futuro.

Attuare le verifiche al database è il modo più efficace per assicurarsi che l’azienda rimanga protetta dagli errori di programmazione e dalle violazioni di sicurezza. L’audit è un bene importante per il business di ogni impresa, in quanto permette di risparmiare tempo e denaro e di mantenere salda la propria reputazione.

Per saperne di più scarica l’eBook Modernizing your database processes with DevSecOps.

 

Image courtesy of Stuart Miles at FreeDigitalPhotos.net

Verifiche al database: quali i vantaggi?

DevOps e Security: fazioni nemiche o grandi amici?

Se il DevOps mira a guardare avanti, cercando di fornire nuovi programmi in modo rapido ed efficiente, i tradizionali processi di sicurezza tendono invece ad essere più scrupolosi in termini di agilità e vengono generalmente affrontati nelle ultime fasi dello sviluppo.

Questi due approcci, così diversi tra loro, potrebbero quindi essere considerati “nemici”.

DevOps e Security: fazioni in lotta o grandi amici?

ID-100284442Fazioni nemiche? Non deve essere così. Con i sempre più numerosi security breaches che si verificano ogni settimana, è di vitale importanza che la sicurezza e il DevOps lavorino insieme per integrare e semplificare il delivery, bilanciando la velocità e la sicurezza senza alcun compromesso.

Nonostante questi approcci siano entrambi validi e vitali per il corretto funzionamento di un’impresa, i team che operano in questi due ambiti non sono generalmente integrati, e questo può provocare dei malintesi.

Mentre in passato la colpa è stata attribuita al DevOps, colpevole di seguire cattive pratiche in termini di sicurezza, oggigiorno è inopportuno e controproducente perseverare con questa visione. Infatti, molti team DevOps sono più focalizzati sulla sicurezza rispetto ad un tradizionale team di sviluppo. Dunque, è sufficiente definire i parametri e le priorità a livello di sicurezza affinché entrambi i team lavorino bene insieme. Così facendo, i team possono identificare i punti deboli e gli obiettivi condivisi e sviluppare un metodo di lavoro reciprocamente vantaggioso.

Sia il DevOps che la Security sono gestiti da risorse con competenze approfondite, per cui favorire e sviluppare una comprensione reciproca è fondamentale.

L’obiettivo deve quindi essere quello di modificare i processi per garantire che i team DevOps e di Security siano totalmente coinvolti sin dall’inizio di un progetto.

Automazione

Scoprire quali componenti dei processi di sicurezza possono essere automatizzati consente alle aziende di garantire che questi task siano eseguiti presto, spesso e in modo coerente. L’automazione è importante in quanto consente un risparmio di tempo e assicura una regolarità, ma affinché questo avvenga è necessario che i team abbiano già capito o stabilito dove sono le aree di vulnerabilità e cosa si sta cercando di sfruttare.

Creazione di best practice

Comprendere i metodi e i processi migliori all’interno dei team DevOps e di sicurezza deve essere una best practice. Sono fondamentali, quindi, due elementi di interconnessione: collaborazione e comunicazione.

È necessario garantire la collaborazione tra i team includendo la sicurezza fin dall’inizio del processo, ovvero coinvolgendo i team di sicurezza sin dal momento in cui gli sviluppatori iniziano il processo di sviluppo del codice, il che permette di non avere brutte sorprese da entrambi i lati.

Oltra alla collaborazione, anche la comunicazione è essenziale: è un punto ovvio, che va necessariamente preso in considerazione. Quando una parte sensibile del codice viene modificata o aggiornata, gli sviluppatori devono condividere gli aggiornamenti con il team di sicurezza al fine di individuare la posizione di potenziali vulnerabilità. E allo stesso modo, i team di sicurezza devono indicare le priorità e il mutevole scenario delle minacce affinché il team DevOps ne sia al corrente.

Valutazione

Tutto ciò non significa necessariamente misurare il successo di ogni team, ma piuttosto garantire che entrambi lavorino insieme in modo efficace.

Per far sì che questo accada non c’è bisogno di reinventare la ruota, ma è sufficiente utilizzare metriche esistenti, quali il defect rate, il tempo medio delle failure e le metriche di vulnerabilità nelle scansioni del codice.

DevOps e sicurezza: amici che collaborano

La corretta integrazione tra DevOps e Security richiede fondamentalmente un cambiamento nelle persone, nei processi e negli strumenti, con l’obiettivo di creare in modo efficace un ambiente di lavoro semplificato e collaborativo.

Per saperne di più su DevOps e Security, il 24 ottobre segui dall’Italia l’ALL DAY DEVOPS 2017, la conferenza online di 24 ore in cui si susseguiranno speech dedicati al DevOps. Tra le 16:00 e le 21:00 nella sede Emerasoft di Piazza Castello 9 a Torino, verrà trasmesso l’evento live. Registrati all’evento.

DevOps e Security: fazioni nemiche o grandi amici?

Perché affidarsi alla Security Automation?

ID-100549405Vi ricordate di quando le stanze degli hotel non erano dotate di serrature automatiche? Le chiavi magnetiche sono oggi universali e le porte si aprono e si chiudono automaticamente, aumentando la sicurezza anche quando ci scordiamo di chiudere la porta.

Questa è una forma di Security Automation, che può essere paragonata a quella che viene oggigiorno applicata nello sviluppo software.

Perché affidarsi alla Security Automation?

Anche se può sembrare il contrario, se si automatizza la sicurezza in azienda si promuovono i principi DevOps, e quindi una cultura in cui si valorizzano le persone e la fiducia nei loro confronti, capaci di ridurre drasticamente le vulnerabilità.

Come si può automatizzare la sicurezza?

Iniziamo considerando il code review. Come pensate di integrare le revisioni del codice e sfruttare il pair programming? Avete implementato pratiche CI/CD (Continuous Integration/Continuous Development)? Al giorno d’oggi, infatti, è possibile avvalersi di tool e processi per collegare i deployments ai controlli di revisione e agli strumenti di continuous integration e utilizzare un tool di workflow costruito attorno al deployment automatico. Se ogni parte del processo è automatizzata, all’interno di ognuna di queste si hanno revisioni del codice in grado di agire come una sorta di approvazione, rendendo gli auditor felici. E quando gli auditor sono felici, lo sono tutti.

Oltre a code review e pratiche CI/CD, ecco alcuni fattori da considerare per gestire al meglio la Security Automation:

Rischio. Alcune aziende o alcune applicazioni software non hanno voglia di rischiare, spesso per validi motivi. Ma siete ancora in tempo per approfittare di queste considerazioni e applicarle ai business case dove c’è un’esposizione minore al rischio

Formazione. La formazione annuale è noiosa e le persone fanno di tutto pur di evitarla, ma questo non aiuta nessuno. Dando alla formazione interna una vena più ludica, aumenterete sicuramente la partecipazione e la retention.

OWASP. L’Open Web Application Security Project è una grande risorsa, decisiva per la sicurezza delle applicazioni. Questo progetto si allinea perfettamente con le esigenze di Security e con le pratiche DevOps.

Tool. Esistono svariate tipologie di tool allineate alla cultura DevOps. Non vi resta che trovare quella che più si adatta alla vostra azienda e implementarla.

Collaborazione. Collaborate con il vostro team di sicurezza su ciascuno degli aspetti trattati.

L’automazione della sicurezza rimane ancora un mistero? Avete domande su DevOps e Security?

Il 24 ottobre a Torino Emerasoft e Sonatype ospiteranno il live party dell’ALL DAY DEVOPS 2017: la conferenza online di 24 ore, dove si susseguiranno speech dedicati al DevOps, e non solo (le sessioni includeranno Automated Security, CI/CD e Modern Infrastructure).

Approfittatene per seguire gratuitamente l’evento live dall’Italia: www.emerasoft.com/all-day-dev-ops-viewing-party-italia/

Image courtesy of lekkyjustdoit at FreeDigitalPhotos.net

Perché affidarsi alla Security Automation?

Continuous Integration e Continuous Delivery: quali benefici?

code-2620118_1920Continuous Integration (CI) e Continuous Delivery (CD) sono al centro dello sviluppo software moderno, in quanto permettono di rilasciare nuove features, prima e più spesso.

La CI, infatti, sta diventando una parte integrante del lavoro quotidiano degli sviluppatori, garantendo molteplici benefici.

Risparmio di tempo

Uno dei principali vantaggi della CI è la capacità di automatizzare i processi manuali che spesso rappresentano una lunga e noiosa parte del lavoro di uno sviluppatore. La Continuous Integration riduce il debug manuale e permette agli sviluppatori di non preoccuparsi più di effettuare le build delle change con una moltitudine di sistemi operativi diversi o in altri ambienti. Il sistema di CI, infatti, si occupa di tutti questi aspetti e sfrutta la capacità di integrarsi con strumenti come Docker e Kubernetes per trarre pieno vantaggio dalla potenza del Cloud senza dover eseguire le operazioni su una macchina di sviluppo.

Ancor meglio, tutto questo lavoro viene automatizzato, consentendo allo sviluppatore di spostarsi su altre attività, mentre build e test vengono completati.

Risparmio di denaro

Sfruttando uno strumento di CI, è possibile approfittare della sua maggiore flessibilità e potenza: ad esempio, si possono eseguire test su più sistemi operativi, su più browser e, in generale, si può svolgere più lavoro di quanto sia fattibile sulla macchina di un singolo sviluppatore.

Ciò consente al team di identificare le issue più rapidamente e prima lungo il ciclo di sviluppo, quando è economico, anziché dover tornare indietro più avanti. Infatti, se si attende la fine dello sviluppo per scoprire che una modifica non funziona in un sistema operativo o in un browser specifico, potrebbe essere costoso e compromettere il rilascio.

In sintesi, sfruttando la CI si diventa proattivi anzichè reattivi, risparmiando denaro.

Riduzione del downtime

Integrando frequentemente le change e assicurandosi che il nuovo codice sia pronto per essere spedito in qualsiasi momento, i tempi di inattività durante l’implementazione degli aggiornamenti diventano parte del passato.

Ciò non solo è meno stressante per gli sviluppatori e i manager, ma è inoltre meno frustrante per gli utenti.

Ti trovi di fronte a queste problematiche e vuoi approfondire i benefici di CI/CD?

Stai già utilizzando strumenti di CI/CD e vuoi ottimizzarne l’uso?

SCARICA IL WHITEPAPER (IN ITALIANO) “CONTINUOUS INTEGRATION & DELIVERY SU MISURA”

Continuous Integration e Continuous Delivery: quali benefici?

Progetti Open Source: come gestirli?

ID-100547145I progetti open source sono come le startup: nascono da un’idea e per crescere richiedono ingenti investimenti in termini di risorse, oltre che una forte determinazione da parte dei creatori.

Nonostante queste difficoltà preliminari, i progetti open source possono essere molto vantaggiosi per il mondo della tecnologia: creano tool utili, consentono un risparmio di tempo e denaro, incoraggiano la collaborazione e accrescono il talento.

Se stai cercando di avviare il tuo progetto open source o sei interessato a questo mondo, ecco alcuni suggerimenti su come trasformare la tua idea in un progetto di successo.

  1. Focalizzati sull’audience, non sul codice

Allontanati dal codice sorgente e concentrati sul marketing. Hai già il codice, non ti resta che diffondere il progetto e spargere la voce:

  • Documenta il progetto: crea contenuti attraverso blog post e rispondi a domande su forum come Stack Overflow. Ciò fornirà informazioni aggiuntive agli utenti, i quali saranno incoraggiati a utilizzare il tuo progetto.
  • Investi nell’UX del tuo progetto: c’è una maggiore probabilità che gli utenti consiglino un progetto dalla ottima User Experience.
  • Crea canali di supporto per aiutare gli utenti e al contempo utilizza le domande che vengono poste come feedback per valutare lo sviluppo del tuo progetto.
  1. Una volta messo in piedi il progetto, cambia la tattica

Dopo aver stabilito le infrastrutture per la distribuzione del progetto, è tempo di accrescerlo e gestirlo. Inizia attirando i contributors. Ci sono molti tipi di collaboratori: programmatori, tester, creatori di contenuti, ecc.

Hai bisogno di tutti questi contributors, quindi valorizzali e investi su di essi: ricordati che non consumano passivamente il tuo progetto, bensì vi contribuiscono e lo amplificano. I contributors sono come i partner di una startup.

  1. Sii cosciente di quando occorre mollare

Nonostante tu sia l’ideatore del progetto, non comportarti da dittatore o non cercare di rimanere per sempre il re del progetto. Se lo fai, il tuo progetto rimarrà in una campana di vetro e non attirerai mai abbastanza contributors. Di conseguenza, il progetto non sopravvivrà. Questa è una trappola tipica dei creatori di progetto open source: quindi sappi che ad un certo punto dovrai cedere il controllo e poi ritirarti.

Ma nel mondo Enterprise? Come introdurre o gestire progetti open source in azienda?

Emerasoft crea e gestisce open communities per ambienti e prodotti open source e fornisce consulenza e servizi per l’Italia che coprono svariati settori del business IT. Nello specifico, vengono offerti servizi e consulenza sugli stream:

  • Configuration e Versioning con Subversion, GIT e GitLab
  • DevOps con Jenkins, Maven, Nexus, Puppet, Dockers
  • Test con Selenium
  • DB Management con PostgreSQL e EnterpriseDB.

Contatta Emerasoft per maggiori informazioni.

Image courtesy of Khotcharak at FreeDigitalPhotos.net

Progetti Open Source: come gestirli?

Software Innovation attraverso DevOps e OpenSource

Innovare: questo è l’imperativo per le aziende che non vogliono rimanere indietro.

La sfida più grande è rappresentata dalle abitudini culturali e dai silos presenti in azienda, eretti rispettivamente dallo sviluppo di software, dall’application security e dai team di operations, che creano attriti, diminuiscono la velocità e riducono l’innovazione.

Per un’azienda, sia che si tratti di una banca, una casa farmaceutica, un produttore di automobili o un retailer, la sopravvivenza dipende dalla capacità di innovare. Lo sviluppo software, infatti, non è più considerato come un costo per fare affari, ma piuttosto come una competenza fondamentale e un imperativo strategico che definisce il business. Per questa ragione sono sempre più numerose le imprese di tutto il mondo che stanno abbracciando il DevOps, con l’intento di innovare più velocemente dei competitors e, quindi, primeggiare sul mercato.

Questa tendenza è dimostrata da alcuni dati:

  • L’adozione del DevOps è aumentata dal 66% nel 2015 al 74% nel 2016.
  • L’adozione del DevOps è più forte a livello Enterprise (81% nelle grandi imprese rispetto al 70% nelle PMI).
  • L’adozione del DevOps avviene dal basso verso l’alto (29% nei team IT, 31% delle nelle business units e 21% in tutta l’azienda).

Inoltre, è evidente come le aziende che hanno adottato pratiche DevOps stiano riscontrando notevoli benefici:

  • I team DevOps eseguono il deploy 46 volte più frequentemente, ovvero effettuano il deploy più volte al giorno anziché una volta alla settimana (o meno).
  • I team DevOps eseguono il deploy 440 volte più velocemente, ovvero hanno tempi di esecuzione inferiori a un’ora anziché più di una settimana.
  • I team DevOps risolvono un downtime 96 volte più velocemente, ovvero in meno di un’ora anziché in giorni.
  • I team DevOps hanno un tasso di fallimento inferiore di 5 volte, ovvero le change in produzione falliscono il 7,5% delle volte anziché il 38,5%.

Chiaramente la software innovation è il meccanismo primario attraverso cui le aziende moderne concorrono sul mercato, spinte da una sempre più forte pressione per innovare, meglio e più velocemente dei competitors.

DevOps e e OpenSourceIn risposta a questa pressione, i team di sviluppo software non solo scelgono di rivolgersi al DevOps, ma decidono anche di affidarsi a componenti open source per quattro semplici motivi:

  1. Risparmiare tempo e denaro

L’accesso libero e gratuito a componenti software preesistenti evita di dover reinventare la ruota e consente alle aziende di risparmiare significativamente tempo e denaro.

  1. Migliorare la qualità

La legge di Linus, formulata nel 1999 da Eric S. Raymond, afferma che “Dato un numero sufficiente di occhi, tutti i bug vengono a galla”. In altre parole, se uno specifico componente software è esposto ad una sufficientemente grande community di co-sviluppatori e beta-tester, i problemi vengono facilmente identificati e rapidamente risolti. Questo semplice concetto è il motivo per cui i componenti open source portano ad applicazioni software di qualità superiore e perché le imprese come General Motors, General Electric, American Airlines e Bank of America hanno scelto di abbracciare una policy open source.

  1. Incrementare l’agilità aziendale

L’attuale legge di sopravvivenza richiede che le aziende reagiscano velocemente ad uno scenario in rapida evoluzione in cui minacce competitive e opportunità strategiche sono i protagonisti. L’open source, accelerando il ritmo dello sviluppo del software, aumenta l’agilità per gli sviluppatori e per le imprese. Inoltre, le aziende che utilizzano l’open source non sono legate a un fornitore proprietario. Poter controllare il proprio destino senza dipendere da vendors esterni e massimizzare la flessibilità sono ancora due delle ragioni per cui l’open source incrementa l’agilità aziendale.

  1. Mitigare il rischio

Un altro vantaggio dell’open source è la riduzione del rischio aziendale. Mentre i venditori vanno e vengono e le priorità commerciali cambiano, l’attenzione nei confronti di una community può rimanere costante per anni, persino per decenni. L’apertura e la trasparenza delle community open source, infatti, mitigano il rischio, soprattutto quando le aziende utilizzano i migliori componenti dei migliori fornitori.

Ma come si può essere certi di utilizzare i migliori componenti open source?

È possibile verificare lo stato di salute di un’applicazione?

Come gestire la governance open source e monitorare la qualità dei componenti utilizzati?

Scarica il report 2017 State of the Software Supply Chain e scopri cosa si nasconde nella tua supply chain del software.

Software Innovation attraverso DevOps e OpenSource

Come impedire una violazione del database?

Come può un’azienda proteggere informazioni e dati sensibili, impedendo una violazione del database?

ID-100562461Di seguito elenchiamo 5 best practice che possono venire in aiuto:

1. Analizzare continuamente l’intera infrastruttura del database

Spesso le aziende sottovalutano il numero dei DB attivi che possiedono.

I database sconosciuti vengono generalmente utilizzati attraverso credenziali di default, che gli hacker possono quindi facilmente scovare.

Il discovering automatico del DB è un investimento cruciale per evitare questo genere di violazione.

2. Implementare un PSM (Privileged Session Manager)

Un Privileged Session Manager (PSM) consente agli utenti di connettersi ai sistemi senza esporre le informazioni private relative alle password utilizzate.

Il PSM registra inoltre l’attività di ogni sessione, assicurando che le modifiche apportate siano facilmente tracciate e monitorate.

3. Applicare accessi con privilegi minori

La struttura aziendale basata sull’anzianità dei dipendenti dovrebbe essere applicata anche alle autorizzazioni del DB.

I nuovi dipendenti non dovrebbero avere un accesso completo al DB, così come i ruoli Senior dovrebbero avere l’accesso in base alle posizioni ricoperte.

Minori sono gli accessi al database, maggiore sarà la sicurezza stessa del DB.

4. Utilizzare password efficaci

I tuoi dipendenti non utilizzano password deboli per i propri account di posta elettronica, quindi perché dovrebbero utilizzarli quando hanno a che fare con i dati sensibili dell’azienda?

Può sembrare una misura preventiva ovvia, ma vale la pena ripeterlo: usa password efficaci!

5. Implementare l’identificazione avanzata delle credenziali compromesse

Gli utenti autorizzati utilizzano i database in modo prevedibile e ricorrente. Sulla base dei movimenti all’interno del sistema, è dunque chiaro quando un utente non autorizzato sta accedendo al DB.

I sistemi di sicurezza basati sul machine learning automatico sono in grado di identificare un utente indesiderato basandosi esclusivamente sull’analisi di algoritmi, impedendo un data breach massivo prima che questo accada.

Mettiamoci a lavoro!

I difetti di sicurezza del database, se esposti dalla persona sbagliata, sono costosi da rimediare e comportano una reputazione negativa, da cui è difficile riprendersi.

Nonostante sia impossibile garantire che non si verifichi una violazione del DB, ci sono alcuni strumenti che le aziende possono utilizzare per prevenire un breach del database.

Seguire queste cinque best practice consente di creare il giusto deterrente di cui ogni azienda ha bisogno.

Per approfondire il tema:

Image courtesy of hyena reality at FreeDigitalPhotos.net

Come impedire una violazione del database?

Come risparmiare attraverso l’automazione del database

ID-100429110È risaputo che adottare i tool e le metodologie DevOps è una componente essenziale nella transizione dell’azienda verso l’economia digitale.

I manager potrebbero mettere pressione riguardo all’implementazione del DevOps e richiedere di stilare un ROI di questa mossa. Sia l’azienda che i manager conoscono le ragioni per cui è conveniente estendere il DevOps al database, tra le quali i tempi di produzione e il time to market più rapidi, una produzione di maggior qualità, ecc.

Ma come si può assestare il valore completo dell’implementazione del DevOps, senza sapere cosa si otterrà da queste vaghe promesse di miglioramento? Anche se si potesse quantificare l’apporto di queste KPI, come si trasformano in denaro?

Molti calcoli tendono a presentare le efficienze del DevOps nei processi di sviluppo, ma il calcolo dei risparmi nell’intera automazione del rilascio, sia nel codice che nel database, è molto più impegnativo e scarso. Questa mancanza di trasparenza porta alcune aziende a pensare – erroneamente – che investire nel database per come lo si fa insieme al resto dell’ecosistema di sviluppo non è necessario.

Calcolatore ROI di DBmaestro

La buona notizia è che ora è possibile calcolare facilmente l’intero processo di automazione del rilascio.

DBmaestro è fiero di presentare il calcolatore ROI per DevOps. L’unico calcolatore che integra la ricerca industriale (i record degli IT di Gartner e TCO) e le migliori pratiche raccolte da DBmaestro dalla base su 1000 clienti Fortune.

Si può usare questo tool per calcolare il ROI del proprio programma DevOps, compresi:

  • Il costo del tempo di inattività dell’applicazione nelle grandi aziende (circa 7.900 $ al minuto).
  • Il costo medio dell’eliminazione delle barriere tra sviluppo e operation.
  • Il costo degli errori umani che portano a crash devastanti e centinaia di migliaia di dollari spesi in fix non necessarie.

Scopri lo spreco, scopri l’opportunità

Molte aziende hanno scoperto, ad esempio, che i tempi di inattività del database stavano esercitando un peso gravoso sulle loro spese operazionali. Un cliente ha scoperto che stavano perdendo 500.000 $ all’ora a causa di errori critici nell’applicazione. Una volta scoperto, gli sono bastate sei ore per sistemare il guasto, ed evitare uno spreco non necessario di 3M $ all’anno.

Come calcolare un’analisi costi-benefici del database?

Mentre molti studi sono stati intrapresi nel tentativo di identificare il ROI dell’automatizzazione del database e dei processi di rilascio – come il calcolatore TCO di Gartner – sarebbe necessaria un’analisi ulteriore. In modo particolare bisognerebbe anche calcolare i risparmi sulla produttività del team, quelli generati dall’automazione e quelli dalla riduzione del pericolo di tempi di inattività.

Usando il calcolatore ROI di DBmaestro per valutare il database, l’analisi costi benefici mostra un ampio spettro di fattori e considerazioni, che presentano una rottura di ciò che si sta spendendo in costi non necessari e dove c’è bisogno di miglioramenti.

Far combaciare i numeri dell’azienda con le proprie condizioni operazionali, permette di essere più orientato ai dati nel prendere decisioni. Può anche dare un’immagine più chiara di quanto più efficiente possa essere la propria azienda e quanto si possa risparmiare implementando un programma DevOps completo.

CLICCA QUI PER CALCOLARE IL ROI DEL TUO PROGRAMMA DEVOPS.

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

Image courtesy of cookie__cutter at FreeDigitalPhotos.net

Come risparmiare attraverso l’automazione del database

I 7 step per un DevOps di successo

Il DevOps è un tema sempre più di rilievo nell’ambiente IT.

L’implementazione del DevOps nelle aziende di grandi dimensioni non è semplice e richiede una grande collaborazione tra settori diversi, oltre all’integrazione di piattaforme che consentano di gestirlo e ad un cambiamento significativo della cultura aziendale. Per poter implementare una strategia DevOps di successo occorre, infatti, partire dal presupposto che il DevOps non è un approccio che coinvolge singoli team o dipartimenti, bensì un metodo che abbraccia molti aspetti della gestione aziendale. Insomma, approcciarsi al DevOps implica uno sforzo non banale.

Considerato l’impegno necessario ad implementare il DevOps al meglio, vale davvero la pena investirci? Certo!

devops di successoI cambiamenti dovuti all’implementazione del DevOps portano grandi benefici all’azienda, permettono di migliorare il lavoro in termini di tempistiche e qualità e creano un ambiente collaborativo e ottimale per la massima resa di ogni singolo individuo. La filosofia del DevOps non a caso si fonda sui tre pilastri del successo di un’azienda: collaborazione, comunicazione e automazione. Rilasci rapidi, controlli qualità continui, comunicazione tra i settori e tra gli individui, trasversalità delle competenze, sono solo una parte dei benefici del DevOps e rappresentano la più alta realizzazione di questi tre grandi concetti.

Da dove partire, quindi, per divulgare in azienda la corretta filosofia DevOps e mettere in piedi una strategia vincente? 

Recentemente Eddy Pauwels, SVP di Clarive, si è interrogato sul DevOps e ha stilato una lista di 7 step per implementarlo al meglio nelle aziende. Qui di seguito riportiamo la lettera di presentazione dell’eBook ”My 7 Step strategy for successful DevOps in the evolving enterprise.

“Il DevOps  un tema caldo. Molte aziende sono nel pieno del processo di implementazione del DevOps o stanno stanziando un budget per poterlo fare in un futuro prossimo. Ad oggi molti analisti scrivono di DevOps, ma allo stesso tempo continuo a notare molta confusione su cosa sia davvero.

È un processo? Un metodo di lavoro? Una cultura aziendale? Un approccio? O riguarda tool e automazione? Consente progetti Agile o può essere applicato solo a progetti tradizionali?

Con questo eBook voglio presentare la mia visione del DevOps e condividere la mia strategia a 7 step, per un’implementazione di successo del DevOps nelle aziende in crescita.

Il contenuto di questo eBook si basa sulle molte conversazioni che ho avuto con persone esperte, durante la mia personale esperienza come consulente e formatore DevOps, con clienti e analisti e nei molti anni passati a leggere ed informarmi sull’argomento.

Spero che il contenuto di questo eBook sia fonte di ispirazione per il lettore e aiuti nell’introduzione al DevOps. Chi appartiene a grandi aziende spesso si trova nel processo di transizione delle proprie applicazioni, delle architetture per i servizi e dai processi di delivery che diventano interconnessi ai micro servizi. Spesso sono molto entusiasti dei benefici del DevOps, ma altrettanto spesso temono che sia un obiettivo difficile da raggiungere, per esempio a causa della scarsa adozione dell’agile di cui hanno fatto esperienza, di un approccio di gestione dei rilasci top-down e di una grande varietà di piattaforme con cui devono avere a che fare.”

Questo eBook presenta in maniera molto pratica ciò che spesso viene solo teorizzato. Se hai intenzione o hai già pianificato di passare al DevOps nella tua azienda, devi necessariamente conoscere a fondo l’argomento, al fine di massimizzarne la resa e trarne il massimo dei benefici. Come?

I 7 step per un DevOps di successo

DevOps e sicurezza anche per il database

“In quanto CTO e cofondatore di DBmaestro, ho speso gli ultimi anni a capire e imparare come ottenere uno sviluppo agile, la continuous delivery e l’integrazione per il database, noto anche come DevOps per il database” afferma Yaniv Yehuda.

ID-100435764Dopo aver sostenuto innumerevoli conversazioni con leader del campo, CIO e CTO, Yehuda ha concluso che la ragione primaria per cui le aziende decidono di non adottare il DevOps per il database è di preservare la sicurezza del database stesso. Se la sicurezza del database avesse un ruolo più importate nel DevOps, le grandi aziende, soprattutto quelle che gestiscono dati sensibili, sarebbero più aperte all’adozione dell’agile e delle pratiche di continuous per il database.

DBmaestro si propone di aiutare le aziende a raggiungere i propri obiettivi di rilascio rapido, gestendo al contempo i rischi. La soluzione è il DevSecOps, che permette ai processi di sviluppo delle applicazioni di essere accelerati, sottoposti a test e rilasciati in modo controllato e organizzato.

Il bisogno di velocità

La sfida del DevSecOps per il database è di aumentare velocità ed efficienza senza perdere il controllo. Com’è possibile per le aziende essere più veloci e restare protetti allo stesso tempo? Chi pratica mountain bike conosce questo problema: per andare veloci, si deve mettere in conto qualche rischio.

Esiste un’ovvia ragione che spiega questo bisogno di velocità: i clienti non hanno pazienza. Ai tempi della metodologia waterfall, le soluzioni per le aziende testate a fondo venivano lanciate una o due volte all’anno. Ora, con l’adozione dell’agile e dei processi continui, hanno tutti fretta. Le aspettative sono alte e il tempo per dedicarsi ai dettagli è poco.

Le aziende che continuano ad avere successo nell’era del DevSecOps hanno imparato a rilasciare rapidamente applicazioni senza intoppi, in modo efficiente e con successo, grazie all’automazione. Tuttavia il database veniva trascurato, continuando a svolgere molte attività in modo manuale. Gli amministratori del database si sono ritrovati a dover svolgere l’incarico impossibile di tenere il passo con i processi continui, usando implementazioni manuali.

L’automazione del database è sicura?

Il problema riscontrato è che automatizzare il database non era come automatizzare il codice. Il database non è una raccolta di file su un file system, perciò, a differenza del codice, il database non può essere copiato. È questa la caratteristica che contribuisce alle inconsistenze tra gli ambienti come le derive di configurazione e le modifiche esterne ai processi. Gli sviluppatori di codice sono incoraggiati a sbagliare in fretta e sbagliare spesso, ma se gli sviluppatori del database adottassero questa filosofia per il database, le aziende ne pagherebbero il prezzo.

A causa di questi rischi il team DBA è diventato un collo di bottiglia. Prima del DevSecOps per il database, i team di sviluppo erano frustrati perché avrebbero voluto essere più agile e autosufficienti. I DBA, responsabili della salute e delle operazioni di continuous del database, dovevano prestare attenzione alla valutazione e alla gestione dei rischi delle modifiche, portando via tempo prezioso.

Quando le aziende applicano il DevSecOps per il database, sia i team di sviluppo, sia i DBA, condividono le responsabilità di custodia dei preziosi dati nel database. Lavorando insieme, possono stabilire delle regole di base e dei controlli dei processi, nonché creare processi ripetibili. Il lavoro collaborativo richiesto dal DevSecOps aiuta le aziende a superare in sicurezza le sfide dell’automazione dello sviluppo e del deploy del database per stare al passo con i sempre più rapidi tempi di rilascio.

DevSecOps in azione

Il DevSecOps per il database crea le condizioni per un rilascio sicuro degli script del database. Ciò significa prepararsi alle derive di configurazione, alle modifiche esterne ai processi, aderire alla conformità normativa e alle richieste di revisione. Tutto ciò permetterà rilasci sicuri e rapidi in ambienti strutturati.

Per prima cosa, i team devono essere conformi alle regole della policy e capire i ruoli di ogni membro. In secondo luogo, è fondamentale impostare le regole per prevenire le modifiche che non sono conformi con la policy organizzativa. Inoltre, i cambiamenti ammessi dalle audit in fase di esecuzione degli aggiornamenti aggiungeranno un’ulteriore linea di difesa per prevenire errori del codice e inattività del database. In altre parole, qui ci si concentra sull’analisi d’impatto e non sul controllo dei danni.

Abilitare il rollback durante questa fase è imperativo per avere modifiche al database sicure. Per ottenere un processo sicuro, rapido e attendibile, questi step devono essere eseguiti alla perfezione. Dopo questo processo, comprendere chi ha fatto quale modifica, quando, dove e perché, è fondamentale per esaminare se questo processo può essere ripetuto (o automatizzato) o se il team DevSecOps deve tornare alla fase di pianificazione.

Non tralasciare il database

Non si tratta semplicemente di avere a che fare col database, ma con le intere applicazioni. La stessa rete di sicurezza costruita per i rilasci del codice può essere applicata al database avendo attivato una giusta pipeline di continuous delivery. Una delle maggiori preoccupazioni per le aziende che hanno a che fare con informazioni sensibili – in particolare il settore finanziario – è l’inattività, costosa sia in termini di denaro, a causa dei milioni di dollari persi, sia in termini di tempo, dovendo l’azienda tornare a ricostruirsi una reputazione.

Aziende che, come può essere comprensibile, non vogliono avvicinarsi all’automazione per evitare questi rischi, verranno superate perché non soddisfano le richieste dei clienti. Le aziende finanziarie devono capire che esiste una soluzione sicura e attuabile per automatizzare i rilasci del database e il ROI che ne deriverà ricompenserà i loro sforzi.

Per approfondire il tema scarica il wehitepaper: “DevOps per il database: pregiudizi e Best Practices“.

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

Image courtesy of yodiyim at FreeDigitalPhotos.net

DevOps e sicurezza anche per il database