Dal codice al cloud: rafforzare la resilienza lungo l’intera pipeline DevOps

DevOps gestisce il codice, le pipeline, l’automazione e i metadati. Quando queste risorse non sono disponibili, le pipeline di distribuzione si bloccanoe le attività aziendali ne risentono. 

Cancellazioni accidentali, azioni da parte del personale interno, configurazioni errate, limiti delle API, ransomware e interruzioni del servizio cloud colpiscono anche le organizzazioni più consolidate. 

Spesso mancano di funzionalità di archiviazione a lungo termine, protezione dei metadati, ripristino multipiattaforma e controlli di sicurezza di livello aziendale. 

Contribuendo a fornire una protezione unificata e nativa per il cloud con funzionalità di Recovery granulare, ripristini tra diversi cloud, RBAC, tracciabilità e storage scalabile. 

Le interruzioni del servizio ritardano il lancio dei prodotti, compromettono la produttività, aumentano i rischi legati alla conformità e danneggiano la reputazione, rendendo indispensabile la resilienza del DevOps. 

Per la trascrizione con l’indicazione dei tempi, guarda il videoqui

…

Ciao a tutti, benvenuti alla nostra sessione “Dal codice al cloud: rafforzare la resilienza lungo l’intero
“DevOps per le pipeline”.

Mi chiamo Aashray Agur e sono Senior Product Manager presso Commvault.

Questo è il mio terzo anno in Commvault.

Lavoro a Bangalore, in India.

Per quanto riguarda il mio ruolo, collaboro con il team delle applicazioni SaaS e sono direttamente responsabile delle soluzioni Salesforce e
DevOps.

In parole povere, sono la persona incaricata di comprendere le esigenze dei clienti e
progettare soluzioni software efficaci in questo settore.

Oggi il nostro relatore e ospite è Anilkumar di Oikocredit.

Prima di lasciargli la parola, vorrei parlare un po’ di Oikocredit.

Oikocredit è uno dei principali investitori e cooperative a impatto sociale al mondo.

Promuove lo sviluppo sostenibile attraverso investimenti nell’inclusione finanziaria,
nell’agricoltura e nelle energie rinnovabili.

La sua sede centrale si trova nei Paesi Bassi.

Anil è ingegnere cloud presso

Oikocredit.

Ciao, Anil.

Sarebbe fantastico se potessi raccontarci un po’ del tuo ruolo e di dove lavori. Sì,
Certo.

Sì, innanzitutto… ehm, mi chiamo Anil.

Lavoro come ingegnere cloud presso Oikocredit, quindi lavoro nei Paesi Bassi.

Il mio lavoro si concentra sull’implementazione, sull’assistenza nella progettazione e sulla manutenzione dell’infrastruttura basata su
sul cloud.

La parte più divertente è il processo di automazione, che permette di velocizzare le operazioni.

In breve, mi assicuro che il nostro ambiente cloud funzioni in modo fluido, sicuro ed efficiente.

Ecco l’ordine del giorno della sessione.

Inizieremo parlando dei rischi crescenti nell’ambito DevOps, poi approfondiremo un po’…
l’importanza della resilienza e quali sono i limiti di alcune delle soluzioni esistenti.

Poi passeremo alla dimostrazione.

Negli ultimi due anni circa, abbiamo visto alcuni dei nomi più affidabili del settore
tecnologico

hanno dovuto affrontare problemi imprevisti all’interno dei propri ambienti DevOps.

Ad esempio, una piattaforma di collaborazione leader ha perso oltre 100 repository GitHub.

Un provider cloud globale ha subito un errore di configurazione che ha causato un’interruzione del servizio DevOps
a livello regionale.

Allo stesso modo, un leader del settore automobilistico ha visto cancellate le proprie pipeline chiave.

Non si è trattato né di casi isolati né di falle nella sicurezza.

Sono cose che capitano anche alle organizzazioni dotate di risorse adeguate e altamente mature.

Il punto fondamentale è che questo elenco non è affatto esaustivo.

Se si osservano queste situazioni, si può notare che avrebbero potuto verificarsi in qualsiasi organizzazione.

Quindi, ciò che dobbiamo riconoscere è che i rischi all’interno dei nostri strumenti DevOps sono in aumento.

Perché non chiediamo a qualcuno che opera in questo settore? Anil, gestisci ambienti DevOps
ormai da parecchio tempo.

Quando ti capita di vedere episodi come questi nel settore, come li interpreti?

E stai notando che le organizzazioni stanno diventando più consapevoli riguardo alla protezione dei propri ambienti DevOps
?

Sì, è un’ottima domanda.

Qualche anno fa, il DevOps era considerato principalmente come un flusso di lavoro destinato agli sviluppatori.

Oggi, invece, si è trasformato in qualcosa di molto più ampio.

È considerato parte dell’infrastruttura critica aziendale.

Quindi tutti si concentrano soprattutto sui sistemi di produzione attivi e funzionanti, ma anche sui sistemi che
coloro che creano e distribuiscono tali applicazioni, ovvero l’ambiente DevOps, sono fondamentali.

C’è quindi una crescente consapevolezza in tutto il mondo

per proteggere questo livello non solo dalle minacce esterne, ma anche da modifiche accidentali,
azioni interne o addirittura interruzioni del funzionamento della piattaforma.

È fantastico vedere che la resilienza sta iniziando a essere integrata nel DevOps fin dall’inizio,
anziché essere un elemento aggiunto in un secondo momento.

È un’osservazione eccellente.

Soffermiamoci un attimo sul

perché, in realtà, la resilienza è importante.

Ancor prima di parlare di resilienza, facciamo un passo indietro e chiariamo cosa significa effettivamente DevOps
.

Come hai detto prima, agli albori del DevOps lo sviluppo del software era affidato a due team
: uno scriveva il codice e il secondo, il team operativo, aveva il compito principale di

garantire il funzionamento di questi sistemi.

Ora il DevOps ha

ha davvero cambiato il modo in cui avviene lo sviluppo del software.

Non ci sono più due squadre.

Oggi, tutto avviene in un unico ciclo continuo.

Ad esempio, si parte da un piano.

Nella fase di pianificazione, si valuta quali funzionalità realizzare e quali nuove soluzioni sviluppare
e così via.

Per farlo, si può ricorrere a una soluzione come Jira, ad esempio.

Una volta pianificato, si scrive il codice.

Questo codice viene archiviato in un repository e conservato in un luogo come

GitHub o GitLab.

Una volta scritto il codice, lo si compila e si rilascia una build, come se fosse un artefatto.

Successivamente, si verifica che tutto funzioni correttamente, si distribuisce la soluzione e poi la si monitora.

Una volta completata l’attività di monitoraggio, emergono i requisiti.

A quel punto, si ricomincia a pianificare.

Vedete, è come un ciclo infinito.

Chiedete a chiunque abbia lavorato nel settore dello sviluppo software.

Tutti sarebbero d’accordo sul fatto che questo processo andrebbe avanti all’infinito.

Allora, Anil, perché pensi che il DevOps sia diventato così centrale nel modo in cui operano
Oggi le organizzazioni moderne, soprattutto quando si tratta di agilità e innovazione?

Sì, credo che non si tratti tanto di una singola organizzazione, quanto piuttosto di come sia
è cambiata in generale la distribuzione del software.

Oggi tutti puntano sulla velocità e sulla collaborazione.

Il DevOps unisce davvero le operazioni di sviluppo e persino

la sicurezza, affinché le idee possano passare da un concetto alla produzione in modo rapido e affidabile.

Quindi, non si tratta più solo di efficienza.

Ehm, l’ambiente DevOps ora contiene gli elementi più critici come il codice sorgente, la pipeline, ehm
, le logiche aziendali, che sono fondamentalmente la proprietà intellettuale dell’organizzazione e la sua

.

Pertanto, il DevOps ha assunto un ruolo più strategico.

Oggi le aziende devono innovare, dimostrare resilienza e mantenere anche un vantaggio competitivo.

Esatto.

La capacità di agire rapidamente, automatizzare i processi e favorire la collaborazione tra i vari team è diventata un vantaggio competitivo
, senza alcun dubbio.

Ma penso anche che, a causa di questa interconnessione, di questa fortissima interconnessione, un
avrà un problema in un punto 

effetti a cascata lungo l’intera catena.

Ad esempio, se si smarrisce il codice, tutto ciò che dipende da esso ne risentirà.

Sapete, ci sono dei rischi.

Ora cerchiamo di capire quali rischi esistono oggi.

Nella nostra prima diapositiva abbiamo già visto alcuni esempi di ciò che hanno vissuto alcune aziende
, giusto?

Sto solo cercando di dare un nome a questi rischi.

Pertanto, in caso di attacco ransomware, è probabile che i vostri repository vengano crittografati.

Nel caso di insider con intenti malevoli, un malintenzionato potrebbe procedere alla cancellazione delle vostre configurazioni.

In caso di errore umano, potrebbe capitare, ad esempio, che voi e i nostri sviluppatori software integriate una
una serie di strumenti di terze parti.

Se l’integrazione va male, l’intero sistema ne risente.

Quindi i rischi ci sono, ma sono sotto il nostro controllo.

Allora, Anil, secondo te, cosa succede se queste pipeline DevOps subiscono un’interruzione, anche
breve?

Ehm… È una domanda interessante.

La nostra pipeline DevOps è fondamentalmente il sistema che garantisce che le Features e gli aggiornamenti delle
le nostre applicazioni interne vengano distribuite in modo fluido e sicuro, in linea con le nostre

.

Quindi non si tratta solo di distribuire il codice.

È questo che fa andare avanti tutto: testare, integrare e rilasciare le modifiche
senza alcun ritardo.

Quindi, se il processo venisse interrotto anche solo da un piccolo imprevisto, rallenterebbe contemporaneamente i nostri
diversi team.

Ehm… L’impatto non è solo tecnico.

I membri del nostro team devono avere la certezza che, finora, tutto stia funzionando come previsto.

Ehm… Ci concentriamo soprattutto sulla risoluzione del problema e sul ripristinare il funzionamento di tutto.

Quindi, il progetto…

Non perdiamo lo slancio.

Capito.

Capito.

Ho cercato di individuare, ehm, i rischi immediati.

Ad esempio, come hai detto tu, se si perde qualcosa, ci saranno ritardi nella distribuzione.

Se si utilizza un test di esempio, la qualità del prodotto ne risentirà.

E oggi il codice custodisce la tua proprietà intellettuale.

Oggi il codice è come il cuore dei tuoi dati.

Se lo utilizzi, vai incontro a rischi legati alla perdita della tua proprietà intellettuale.

Ehm…

Al di là dell’aspetto tecnico, quale impatto avrebbe sul business se i dati
E se i DevOps diventassero indisponibili, ad esempio, nel contesto dei nostri dati aziendali?

Sì, in quel caso, ehm, se i dati DevOps diventassero indisponibili anche solo per ore o giorni, l’impatto
in particolare, ehm, riguarderebbe lo stato di avanzamento.

Pertanto, quando il sistema che gestisce la distribuzione del software si blocca, rallenta gli aggiornamenti e
i miglioramenti su cui il team fa affidamento.

Ecco perché la resilienza e Recovery non sono facoltativi.

Sono integrate nel processo fin dall’inizio.

Si tratta piuttosto di garantire che la continuità sia parte integrante della progettazione.

In questo modo, anche se qualcosa va storto, possiamo riprenderci rapidamente e continuare ad andare avanti.

Insomma, non avrei potuto dirlo meglio, volevo solo aggiungere qualcosa a quanto hai detto tu.

Ehm, non si tratta solo di…

tasso di perdita dei dati, si tratterebbe di una perdita di produttività.

Potenzialmente, si tratterebbe di danni alla reputazione.

Se si opera in settori regolamentati, si andrebbe incontro a numerose carenze in materia di conformità.

Ecco perché la resilienza deve essere integrata nel DevOps fin dalla fase di progettazione e concordo con l’affermazione:
Non è mai abbastanza, tutto qui.

Ok, abbiamo stabilito che nel DevOps è necessaria la resilienza.

Ora parliamo un po’ delle soluzioni attualmente disponibili sul mercato e di quali siano alcune
dei limiti di tali strumenti.

Per quanto riguarda le soluzioni disponibili sul mercato, in base alla mia esperienza come product
manager; alcune si avvalgono di strumenti nativi, il cosiddetto “cestino”.

Alcuni provano a utilizzare script, anche personalizzati, per eseguire i backup, e poi ci sono
soluzioni specifiche.

Mamma,

queste presentano alcuni limiti significativi.

Prima di intervenire in qualità di product manager, vorrei chiedervi, in qualità di clienti, perché pensate che
Ci sono ancora team che si affidano a queste funzionalità native o agli script?

Perché queste soluzioni non sono incluse nel nostro prodotto?

È un’ottima domanda.

Sì, posso parlare in base alla mia esperienza.

All’inizio abbiamo utilizzato le funzionalità integrate nella piattaforma e altri strumenti disponibili sul
mercato.

E quelle opzioni non coprono, ehm, l’ampia gamma di funzionalità che stiamo cercando.

Coprono le funzionalità di base, ma richiedono un’elevata manutenzione.

Ma se le si esamina più da vicino, spesso hanno, ehm, periodi di conservazione più brevi e non acquisiscono
tutto ciò che conta, come le pipeline, le bacheche e i metadati.

Capisco.

In effetti, questa è stata la mia esperienza quando ho intervistato diverse persone.

Ehm, i cestini non coprono necessariamente tutto.

Persino gli script non coprono completamente elementi come i metadati.

Uno dei principali segnali d’allarme che si notano, supponendo che si utilizzino gli script, sarebbe
la sicurezza.

Anche i backup rimangono nello stesso ambiente.

E questo è un serio, ehm, campanello d’allarme.

Ehm, se la produzione va in tilt, anche il backup va in tilt.

Quindi non è possibile effettuare un backup

Stesso ambiente.

E poi c’è il problema della verificabilità.

Quando si utilizzano gli script, non è possibile vedere quali dati sono stati sottoposti a backup e quali lo saranno.

Infine, ehm, la struttura aziendale.

Sebbene esistano script e soluzioni specifiche che offrono le tre caratteristiche sopra menzionate,
Ehm… hanno difficoltà a gestire la scalabilità.

Probabilmente riescono a gestire centinaia di repository, ma quando si arriva a migliaia di repository
o un terabyte di dati,

fanno fatica, crollano a causa dei limiti delle API.

Ed è proprio questo il motivo per cui né gli script né le cosiddette soluzioni puntuali sono
in grado di soddisfare i requisiti a livello aziendale.

Ed è proprio questa lacuna il motivo per cui Commvault esiste: innanzitutto per colmare queste lacune.

Ora, prima di illustrare i vantaggi della mia soluzione, vorrei dare la parola ad Anil, in qualità di

nostro cliente, qual è stato il motivo principale che ti ha
Cosa l’ha spinta a scegliere la soluzione Commvault?

Sì, direi che i fattori determinanti sono stati la semplicità e la coerenza.

Prima dovevamo destreggiarci tra diversi strumenti e politiche per ogni ambito, il che
rendeva la protezione complessa e più difficile da gestire.

Con il backup Commvault per DevOps,

Ora disponiamo di un unico approccio unificato, un unico punto da cui monitorare, proteggere e recuperare i dati in tutto l’ambiente DevOps.

E sì, questa coerenza ha anche rafforzato la nostra sicurezza.

Ehm, sì, il controllo degli accessi e le politiche di conservazione vengono applicate allo stesso modo ovunque, il che
riduce anche i rischi e ci aiuta a garantire la conformità senza comportare alcun onere aggiuntivo.

Ottimo, sono d’accordo.

Infatti, una delle prime cose che sento dire dai nostri clienti riguarda proprio l’interfaccia unificata
, un unico punto da cui è possibile proteggere tutti i propri carichi di lavoro.

Oltre a quanto hai sottolineato, vorrei soffermarmi brevemente su due
punti molto importanti, poiché sono collegati alla mia diapositiva precedente.

Abbiamo parlato di scalabilità e di come molte soluzioni presenti sul mercato non siano in grado di gestire configurazioni di grandi dimensioni.

Ciò è dovuto ai limiti di velocità delle API.

Ognuna di queste piattaforme, Azure DevOps, GitHub, GitHub… sapete, queste piattaforme limitano la
la frequenza dei backup e, intendo dire, la frequenza o il numero di API che è possibile utilizzare.

Una volta raggiunti tali limiti, i vostri processi rallentano o smettono di funzionare.

E noi risolviamo questo problema tramite la rotazione automatica dei token.

In questo modo i backup vengono eseguiti in parallelo senza mai raggiungere i limiti di frequenza.

Possiamo utilizzare più token e alternarli senza interruzioni.

Inoltre, distribuiamo i nostri carichi di lavoro in modo intelligente, affinché gli ambienti su larga scala continuino a funzionare
senza intoppi e senza alcun intervento.

E il prossimo argomento che vorrei affrontare è il ripristino multipiattaforma.

Come abbiamo già detto, potrebbero verificarsi interruzioni del servizio.

Anche i principali operatori possono subire interruzioni.

Quando ciò accade, per risolvere il problema è possibile spostare i propri report da Azure
Da DevOps a GitHub, da GitHub a GitLab e in qualsiasi combinazione di questo tipo;

si è davvero resilienti e il lavoro non si interrompe.

Oltre a ciò, disponiamo di tutte le funzionalità standard, come i registri di audit dettagliati
, il controllo degli accessi basato su regole e così via.

A questo punto, vorrei cogliere l’occasione per annunciare che presto
Inizieremo a supportare Jira.

A partire da dicembre daremo il via al nostro programma di accesso anticipato.

Con Jira, siamo entrati nella nostra prossima fase di sviluppo nell’ambito del DevOps e siamo davvero
entusiasti del nostro supporto per Jira.

Passiamo ora alla parte successiva della nostra presentazione: la dimostrazione del prodotto.

Questa è la nostra Commvault Cloud Console.

Si tratta di un unico pannello di controllo tramite il quale è possibile proteggere praticamente tutti i vostri
carichi di lavoro.

Questa è la pagina iniziale del nostro strumento DevOps.

Vorrei dividere la mia demo in due parti.

Nella prima parte parlerò della pagina panoramica e di come integrare la vostra app.

Nella seconda parte mi concentrerò sul ripristino.

La pagina di panoramica vi offre una

una panoramica delle applicazioni a vostra disposizione e delle loro dimensioni.

Ad esempio, non abbiamo configurato Jira, quindi qui non vedete Jira.

Ma indipendentemente dalle impostazioni configurate, potrete vedere la dimensione del backup e il numero di repository protetti.

Questo vi dà un’idea di quanti backup sono stati effettuati e di quante istanze non sono state sottoposte a
copia di sicurezza.

In questo modo si ottiene una verifica dello stato di salute del sistema.

Ora vediamo brevemente come integrare un’applicazione.

Queste sono tutte le app che abbiamo configurato.

Ehm… Il riassunto di tutto questo è quello che avete visto in questa… ehm… pagina di panoramica.

Ora integriamo un’app.

Fai clic su “Aggiungi app DevOps”.

Ehm… Queste sono tutte e quattro le applicazioni che supportiamo.

La procedura di configurazione è abbastanza simile per tutte queste piattaforme.

Fai clic su “Avanti”.

Il nome dell’app può essere, ehm, qualsiasi cosa che

che ti consenta di identificarla facilmente: può essere uno dei tuoi nomi Azure DevOps o qualsiasi altra cosa che funzioni per te.

Esistono due modi per effettuare l’onboarding.

Se si utilizza la configurazione express, è Commvault a fornire l’app.

Puoi utilizzare la tua configurazione personalizzata.

Ciò significa che puoi utilizzare la tua app anche con la configurazione Express.

Ci vuole meno di un minuto per aggiungerla.

Vediamo come funziona.

Bingo.

Abbiamo stabilito un contatto con questa organizzazione.

Passiamo ora ad Access Node.

In sostanza, devi scegliere la regione di archiviazione.

Siamo presenti praticamente ovunque.

Supponiamo che la vostra sede si trovi negli Stati Uniti: vedrete la regione di archiviazione degli Stati Uniti; lo stesso vale per l’Europa e
l’Asia.

Questa opzione verrà visualizzata automaticamente.

Seleziona la regione.

E poi scegli il piano.

Nella sezione “Piano”, in sostanza puoi

scegliere… ehm… la frequenza con cui vuoi eseguire il backup.

Ehm… Offriamo già uno spazio di archiviazione incluso nel pacchetto e puoi anche scegliere il periodo di conservazione.

Pertanto offriamo una conservazione illimitata.

È possibile eseguire il backup almeno una volta al giorno.

E infine, i contenuti.

Questi sono tutti i servizi che proteggiamo.

Se non volete che un servizio venga protetto, potete deselezionarlo.

Per quanto riguarda i progetti, quando si selezionano tutti i progetti, qualsiasi nuovo
Ogni giorno, ogni progetto o repository viene sottoposto a scansione e a backup.

Se, ad esempio, desiderate proteggere o deselezionare solo determinati carichi di lavoro, potete scegliere
questa opzione.

Poiché lo spazio di archiviazione è incluso nella licenza, si consiglia di selezionare tutti i progetti.

Fai clic su Invia.

Ecco fatto.

La vostra istanza è stata creata.

Ora, ehm, vorrei soffermarmi su uno dei punti su cui ho insistito nella mia presentazione,
ovvero la scalabilità.

Perché molte soluzioni presenti sul mercato non garantiscono la scalabilità?

Si tratta del supporto per più token.

Oggi abbiamo già aggiunto un’app,

che ti fornisce un token.

Ora aggiungiamone altri.

Questa è una credenziale che ho già creato.

Se ne vuoi altre, clicca qui.

In questo modo, supponiamo che con una si raggiungano i limiti di rate limit dell’API: passeremo
automaticamente in seconda e poi in terza.

In questo modo puoi aggiungere tutte le app che vuoi.

Quindi, ogni volta che raggiungi i limiti di velocità dell’API, passiamo a un’altra credenziale e otteniamo questo risultato.

Ecco come gestiamo la scalabilità.

Con questo, abbiamo concluso la parte introduttiva della demo.

Ora passiamo alla parte relativa al ripristino.

Torniamo all’organizzazione.

Questi sono tutti i backup che sono stati effettuati.

Vedrete questo timestamp.

Potete selezionare una data qualsiasi e fare clic su “Ripristina”.

Questa è l’organizzazione.

Potete cliccare sull’organizzazione.

Questi sono tutti i progetti.

Quindi la gerarchia è: organizzazione, progetti e repository.

Come potete vedere, ci sono centinaia di progetti.

È possibile accedere a uno qualsiasi dei progetti e vedere quali repository sono presenti.

Questi sono tutti i repository esistenti.

Ora, se, ad esempio, volete ripristinare.

Clicca sul pulsante “Ripristina”.

Esatto.

Ora offriamo un livello di dettaglio ancora maggiore.

Supponiamo, ad esempio, che vogliate ripristinare solo gli artefatti.

Basta deselezionarli.

Oppure volete ripristinare solo i repository.

Potete deselezionare gli altri servizi.

È così che affrontiamo la questione della granularità.

Allo stesso modo, il ripristino in loco è ovvio.

Ma offriamo il ripristino fuori sede e persino su disco.

Questo è utile per la vostra Readiness alle emergenze.

Ora, diamo un’occhiata al ripristino fuori sede.

Ho parlato anche di un fattore importante, vero?

Supponiamo che anche le vostre piattaforme possano subire interruzioni del servizio.

In tal caso, potreste decidere di trasferire i vostri report su altre piattaforme.

Ad esempio, Azure DevOps o GitHub.

E noi sosteniamo questa opzione.

Ad esempio, potreste scegliere una qualsiasi delle app configurate durante l’installazione.

Ecco l’arco.

Come vedi, basta cliccare su “Invia”.

Ehm… Questi report verrebbero ripristinati senza problemi nella vostra app.

GitHub e, detto questo, con questo si conclude il… oh.

Per concludere l’intera discussione, cosa abbiamo visto?

Guardiamo in faccia la realtà: gli incidenti informatici non sono solo una questione teorica.

Abbiamo visto aziende che ne subiscono le conseguenze a giorni alterni, quindi i rischi sono ben chiari: il
Il divario tra gli strumenti nativi e gli script fai-da-te, ehm, presenta alcuni limiti, mentre le soluzioni ad hoc

non riescono a gestire la scalabilità.

Affidarsi a loro comprometterà la vostra resilienza informatica.

E abbiamo anche parlato dei rischi.

Avete considerato la perdita di produttività, il danno alla reputazione, la violazione della fiducia dei clienti e
altri possibili rischi.

La soluzione è dotarsi di una soluzione di livello aziendale come Commvault per affrontare questi
rischi ed essere pronti.

Vorrei quindi concludere rivolgendomi a quelle organizzazioni

che stanno appena iniziando a pensare alla protezione dei propri ambienti DevOps: che consiglio darei?
glielo daresti?

Sì, inizierei a considerare i dati DevOps alla stregua di qualsiasi altro dato critico per l’azienda.

Un altro malinteso diffuso è che gli strumenti nativi o gli script veloci siano sufficienti, ma
In realtà potrebbero coprire solo la Recovery di base.

Non sono progettati per garantire sicurezza a lungo termine, scalabilità o addirittura conformità.

Quindi, il secondo punto che vorrei sottolineare è: puntate sulla semplicità.

Più la strategia di protezione è frammentata, più diventa difficile garantire
coerenza e sicurezza.

Ehm… Dovremmo quindi adottare un approccio unificato che garantisca visibilità, automazione e anche solide
controlli di accesso.

Questo fa un’enorme differenza nelle operazioni IT quotidiane.

Ottimo consiglio.

Apprezzo davvero le tue riflessioni.

Prima di salutarci, usa questi codici QR per scaricare la nostra sintesi sulla soluzione DevOps e iscriverti
partecipare al nostro workshop sulla resilienza informatica, effettuare la valutazione della Readiness informatica e saperne di più

sui nostri programmi di accesso anticipato.

Grazie.