A molti DBA oggi viene chiesto di contribuire a una cultura DevOps. Un DBA che conosco mi ha raccontato la storia di una recente riorganizzazione che la sua azienda ha attraversato e quando hanno inviato il nuovo organigramma, il suo titolo è stato effettivamente cambiato da DBA a DevOps engineer. Cosa fa ora di diverso da prima? Bene, si scopre... Non molto. La maggior parte di quello che fa ora è sempre lo stesso. Ma ora il suo cubicolo è ground zero per DevOps, quindi sta prendendo questo nuovo titolo abbastanza seriamente.
Ecco la verità:i DBA hanno praticamente sempre fatto parte di DevOps. Questo perché la maggior parte già svolge attività di sviluppo. Cose come la scrittura di SQL, l'ottimizzazione delle prestazioni di SQL Server, l'analisi degli oggetti e la creazione di report e già svolgono attività operative come la configurazione dei server, l'esecuzione di backup e ripristini e l'ottimizzazione del sistema operativo, della rete e dell'archiviazione.
Il cambiamento principale è che DevOps spesso mette gli sviluppatori di applicazioni contro i team dell'infrastruttura per problemi di stabilità e prestazioni. Dev e Ops hanno priorità diverse che richiedono un ottimo bilanciamento.
Ci sono due lati di questa storia. Lo Sviluppatore lato della casa viene misurato su quanto velocemente e in modo affidabile possono apportare modifiche alla produzione. Il loro obiettivo è sviluppare il codice per specificare le specifiche il più velocemente possibile, metterlo in produzione e mantenere tali modifiche in arrivo.
Operazioni si preoccupa di assicurarsi che le cose non si rompano quando distogli gli occhi da loro. Riguarda tutti i fondamenti che tengono accese le luci e i dati in movimento.
I DBA hanno un ruolo importante da svolgere nella fusione di Dev e Ops. In effetti, è una grande opportunità per i DBA di crescere in questo ruolo emergente di ingegnere DevOps, incluso il monitoraggio e l'ottimizzazione delle prestazioni del server SQL.
Gran parte di DevOps si basa sul motto "Falli spesso, fallisci velocemente". Apporta piccole modifiche incrementali e mettile in produzione. Se causano un problema o se non sono esattamente ciò che i clienti desideravano, ripristinali rapidamente, riparali e rimettili rapidamente in produzione.
Eppure questo presenta rischi reali...
Non è sempre facile capire la causa principale di un problema di prestazioni o stabilità. Ci vuole un bel po' di ricerca per collegare i punti tra una modifica apportata da qualcuno all'applicazione o all'infrastruttura e l'impatto che ha sul carico di lavoro e sulle prestazioni del database.
Questi concetti sono un po' nuovi per il DBA e il compito di incontrarsi nel mezzo per partecipare alla cultura DevOps può sembrare un po' opprimente. Ma devi iniziare da qualche parte. Molte organizzazioni stanno adottando l'approccio di esaminare i problemi di prestazioni del server SQL da un obiettivo diverso e implementando un metodo di monitoraggio diverso.
E se avessi la visibilità sull'integrità del tuo ambiente SQL Server necessaria per risolvere i problemi di prestazioni in modo proattivo... prima che influissero seriamente sulla tua attività? E se potessi identificare rapidamente il degrado delle prestazioni, isolare la causa, analizzare e ottimizzare per prevenire problemi simili in futuro?
Oh, e se potessi avere tutto questo in abbonamento? Senza hardware aggiuntivo, senza software, senza costi di manutenzione ed essere in grado di accedervi da qualsiasi luogo, in qualsiasi momento e su qualsiasi dispositivo?
Con Spotlight Cloud, puoi! È facile come registrarsi. Registrazione. Risolvi.
Inizia con Spotlight Cloud per il monitoraggio e la diagnostica del database ospitato nel cloud senza eguali per SQL Server. È come regalarsi una promozione immediata!
