Aujourd'hui, de nombreux DBA sont invités à contribuer à une culture DevOps. Un DBA que je connais m'a raconté l'histoire d'une récente réorganisation de son entreprise et quand ils ont envoyé le nouvel organigramme, son titre a en fait été changé de DBA à ingénieur DevOps. Que fait-il maintenant de différent d'avant ? Eh bien, il s'avère… Pas grand-chose. La plupart de ce qu'il fait maintenant est toujours le même. Mais sa cabine est maintenant au point zéro pour DevOps, alors il prend ce nouveau titre très au sérieux.
Voici la vérité :les DBA ont pratiquement toujours fait partie de DevOps. C'est parce que la plupart font déjà des tâches de développement. Des choses comme l'écriture de SQL, le réglage des performances de SQL Server, l'analyse d'objets et la création de rapports, et ils effectuent déjà des tâches opérationnelles telles que la configuration de serveurs, l'exécution de sauvegardes et de restaurations, et le réglage du système d'exploitation, du réseau et du stockage.
Le principal changement est que DevOps oppose souvent les développeurs d'applications aux équipes d'infrastructure pour des problèmes de stabilité et de performances. Dev et Ops ont des priorités différentes qui nécessitent un équilibre délicat.
Il y a deux côtés à cette histoire. Le dév côté de la maison est mesuré sur la rapidité et la fiabilité avec lesquelles ils peuvent apporter des modifications à la production. Leur objectif est de développer le code le plus rapidement possible selon les spécifications, de le mettre en production et de continuer à apporter ces modifications.
Opérations est soucieux de s'assurer que les choses ne se cassent pas lorsque vous les quittez des yeux. Il s'agit de tous les fondamentaux qui maintiennent les lumières allumées et les données en mouvement.
Les DBA ont un grand rôle à jouer dans la fusion de Dev et Ops. En fait, c'est une grande opportunité pour les DBA de se développer dans ce rôle émergent d'ingénieur DevOps, y compris la surveillance et l'optimisation des performances du serveur SQL.
Une grande partie de DevOps est basée sur la devise « Échouez souvent, échouez vite ». Apportez de petites modifications incrémentielles et mettez-les en production. S'ils causent un problème ou s'ils ne correspondent pas tout à fait à ce que les clients souhaitaient, annulez-les rapidement, réparez-les et remettez-les rapidement en production.
Pourtant cela présente de réels risques…
Il n'est pas toujours facile de comprendre la cause première d'un problème de performance ou de stabilité. Il faut creuser un peu pour faire le lien entre une modification apportée à l'application ou à l'infrastructure et son impact sur la charge de travail et les performances de la base de données.
Ces concepts sont un peu nouveaux pour le DBA et la tâche de se réunir au milieu pour participer à la culture DevOps peut sembler un peu écrasante. Mais, vous devez commencer quelque part. De nombreuses organisations adoptent l'approche consistant à examiner les problèmes de performances des serveurs SQL sous un angle différent et à mettre en œuvre une méthode de surveillance différente.
Et si vous disposiez de la visibilité sur la santé de votre environnement SQL Server nécessaire pour résoudre les problèmes de performances de manière proactive… avant qu'ils n'affectent sérieusement votre entreprise ? Et si vous pouviez identifier rapidement la dégradation des performances, en isoler la cause, l'analyser et la régler pour éviter des problèmes similaires à l'avenir ?
Oh, et si vous pouviez avoir tout cela sur la base d'un abonnement ? Sans matériel supplémentaire, sans logiciel, sans frais de maintenance et pouvoir y accéder de n'importe où, n'importe quand sur n'importe quel appareil ?
Avec Spotlight Cloud, c'est possible ! C'est aussi simple que de s'inscrire. S'identifier. Résoudre.
Démarrez avec Spotlight Cloud pour une surveillance et des diagnostics de base de données hébergés dans le cloud inégalés pour SQL Server. C'est comme s'offrir une promotion immédiate !
