Veel DBA's worden tegenwoordig gevraagd om bij te dragen in een DevOps-cultuur. Een DBA die ik ken, vertelde me het verhaal van een recente reorganisatie die zijn bedrijf doormaakte en toen ze het nieuwe organigram uitstuurden, werd zijn titel eigenlijk veranderd van DBA in DevOps-ingenieur. Wat doet hij nu dat anders is dan voorheen? Nou, het blijkt... Niet veel. Het meeste van wat hij nu doet is nog steeds hetzelfde. Maar zijn hokje is nu ground zero voor DevOps, dus hij neemt deze nieuwe titel behoorlijk serieus.
Dit is de waarheid:DBA's zijn vrijwel altijd onderdeel geweest van DevOps. Dat komt omdat de meesten al Dev-taken doen. Dingen zoals het schrijven van SQL, het afstemmen van SQL Server-prestaties, het doen van objectanalyse en rapportage en ze doen al Ops-taken zoals het configureren van servers, het uitvoeren van back-ups en herstel, en het afstemmen van het besturingssysteem, het netwerk en de opslag.
De belangrijkste verandering is dat DevOps applicatieontwikkelaars vaak plaatst tegen infrastructuurteams vanwege stabiliteits- en prestatieproblemen. Dev en Ops hebben verschillende prioriteiten die een goede evenwichtsoefening vereisen.
Er zijn twee kanten aan dit verhaal. De Ontwikkelaar kant van het huis wordt gemeten hoe snel en betrouwbaar ze veranderingen in productie kunnen krijgen. Hun doel is om zo snel mogelijk code te ontwikkelen die voldoet aan de specificaties, deze in productie te krijgen en ervoor te zorgen dat die wijzigingen blijven komen.
Ops houdt zich bezig met ervoor te zorgen dat dingen niet kapot gaan als je je ogen van ze afwendt. Het gaat om alle basisprincipes die ervoor zorgen dat de lichten aan blijven en de gegevens in beweging blijven.
DBA's spelen een grote rol bij het samenvoegen van Dev en Ops. Het is zelfs een grote kans voor DBA's om door te groeien naar deze opkomende rol van DevOps-ingenieur, inclusief het bewaken en optimaliseren van de SQL-serverprestaties.
Een groot deel van DevOps is gebaseerd op het motto:"Faal vaak, faal snel." Breng kleine, incrementele wijzigingen aan en voer ze in productie. Als ze een probleem veroorzaken of als ze niet helemaal zijn wat klanten wilden, rol ze dan snel terug, repareer ze en breng ze snel weer in productie.
Toch brengt dit reële risico's met zich mee...
Het is niet altijd gemakkelijk om de oorzaak van een prestatie- of stabiliteitsprobleem te begrijpen. Het vergt nogal wat graafwerk om de punten te verbinden tussen een wijziging die iemand heeft aangebracht in de applicatie of de infrastructuur en de impact die het heeft op de werklast en prestaties van de database.
Deze concepten zijn een beetje nieuw voor de DBA en de taak om in het midden samen te komen om deel te nemen aan de DevOps-cultuur lijkt misschien een beetje overweldigend. Maar je moet ergens beginnen. Veel organisaties benaderen de prestatieproblemen van SQL-servers vanuit een andere lens en implementeren een andere methode van monitoring.
Wat als u inzicht had in de status van uw SQL Server-omgeving die nodig is om prestatieproblemen proactief op te lossen … voordat ze ernstige gevolgen hebben voor uw bedrijf? Wat als u prestatievermindering snel zou kunnen identificeren, de oorzaak zou kunnen isoleren en zou kunnen analyseren en afstemmen om soortgelijke problemen in de toekomst te voorkomen?
Oh, en wat als je dit allemaal op abonnementsbasis zou kunnen hebben? Zonder extra hardware, software, zonder onderhoudskosten en overal en altijd en op elk apparaat toegang te hebben?
Met Spotlight Cloud kan dat! Het is net zo eenvoudig als Aanmelden. Inloggen. Oplossen.
Ga aan de slag met Spotlight Cloud voor ongeëvenaarde, in de cloud gehoste databasebewaking en diagnostiek voor SQL Server. Het is alsof je jezelf meteen een promotie geeft!