Много DBA днес са помолени да допринесат за DevOps култура. Един DBA, когото познавам, ми разказа историята за скорошна реорганизация, през която е преминала неговата компания и когато изпратиха новата организационна диаграма, заглавието му всъщност беше променено от DBA на инженер DevOps. Какво прави сега, което е различно от преди? Е, оказва се… Не много. Повечето от това, което прави сега, е все същото. Но неговата кабина вече е нула за DevOps, така че той приема това ново заглавие доста сериозно.
Ето истината – DBA почти винаги са били част от DevOps. Това е така, защото повечето вече изпълняват задачи на Dev. Неща като писане на SQL, настройка на производителността на SQL Server, извършване на анализ на обекти и отчитане и те вече изпълняват задачи по операции като конфигуриране на сървъри, стартиране на архивиране и възстановяване и настройка на ОС, мрежа и съхранение.
Основната промяна е, че DevOps често противопоставя разработчиците на приложения срещу инфраструктурни екипи заради проблеми със стабилността и производителността. Dev и Ops имат различни приоритети, които изискват фин баланс.
Има две страни на тази история. Dev страна на къщата се измерва колко бързо и надеждно могат да внесат промени в производството. Тяхната цел е да разработят код за спецификация възможно най-бързо, да го вкарат в производство и да поддържат тези промени предстоящите.
Опп се грижи нещата да не се счупят, когато откъснеш поглед от тях. Става въпрос за всички основни неща, които поддържат светлините и движението на данните.
DBA имат голяма роля при сливането на Dev и Ops. Всъщност това е голяма възможност за администраторите на база данни да прераснат в тази нововъзникваща роля на инженер на DevOps, включително наблюдение и оптимизиране на производителността на SQL сървъра.
Голяма част от DevOps се основава на мотото „Често се проваляй, бързо се проваляй“. Направете малки, постепенни промени и ги пуснете в производство. Ако причинят проблем или ако не са точно това, което клиентите искат, бързо ги върнете обратно, поправете ги и бързо ги върнете в производство.
Но това крие реални рискове...
Не винаги е лесно да се разбере основната причина за проблем с производителността или стабилността. Отнема доста ровене, за да се свържат точките между промяната, която някой е направил в приложението или инфраструктурата, и въздействието, което оказва върху натоварването и производителността на базата данни.
Тези концепции са малко нови за DBA и задачата да се срещнете в средата, за да участвате в DevOps Culture, може да изглежда малко непосилна. Но трябва да започнете отнякъде. Много организации възприемат подхода да разглеждат проблемите с производителността на SQL сървъра от различен обектив и прилагат различен метод за наблюдение.
Ами ако сте имали видимостта за здравето на вашата среда на SQL Server, необходима за проактивно разрешаване на проблемите с производителността... преди те да повлияят сериозно на вашия бизнес? Ами ако можете бързо да идентифицирате влошаване на производителността, да изолирате причината и да анализирате и настроите, за да предотвратите подобни проблеми в бъдеще?
О, и какво, ако можете да имате всичко това на база абонамент? Без допълнителен хардуер, без софтуер, без разходи за поддръжка и с възможност за достъп до него отвсякъде и по всяко време на всяко устройство?
С Spotlight Cloud можете! Това е толкова лесно, колкото да се регистрирате. Впиши се. Разрешете.
Започнете с Spotlight Cloud за ненадминат мониторинг и диагностика на база данни, хоствана в облак за SQL Server. Това е като да си дадеш незабавно повишение!
