Wielu administratorów baz danych jest dziś prosonych o udział w kulturze DevOps. Jeden z administratorów, którego znam, opowiedział mi historię niedawnej reorganizacji, przez którą przeszła jego firma, a kiedy wysłali nowy schemat organizacyjny, jego tytuł został faktycznie zmieniony z DBA na inżyniera DevOps. Co on robi teraz, co różni się od tego, co robił wcześniej? Cóż, okazuje się… Niewiele. Większość tego, co teraz robi, jest nadal taka sama. Ale jego boks jest teraz punktem zerowym dla DevOps, więc traktuje ten nowy tytuł całkiem poważnie.
Oto prawda — administratorzy baz danych praktycznie zawsze byli częścią DevOps. To dlatego, że większość już wykonuje zadania programistyczne. Rzeczy takie jak pisanie SQL, dostrajanie wydajności SQL Server, przeprowadzanie analizy obiektów i raportowanie, a oni już wykonują zadania Ops, takie jak konfigurowanie serwerów, wykonywanie kopii zapasowych i przywracanie oraz dostrajanie systemu operacyjnego, sieci i pamięci masowej.
Główną zmianą jest to, że DevOps często stawia programistów aplikacji przeciwko zespołom infrastruktury w kwestiach stabilności i wydajności. Deweloperzy i operatorzy mają różne priorytety, które wymagają starannego wyważenia.
Ta historia ma dwie strony. Programista strona domu jest mierzona tym, jak szybko i niezawodnie mogą wprowadzić zmiany do produkcji. Ich celem jest jak najszybsze opracowanie kodu do specyfikacji, wprowadzenie go do produkcji i utrzymanie nadchodzących zmian.
Operacje dotyczy upewnienia się, że rzeczy się nie zepsują, gdy oderwiesz od nich wzrok. Chodzi o wszystkie podstawy, dzięki którym światła są włączone, a dane w ruchu.
Administratorzy baz danych mają do odegrania dużą rolę w łączeniu Dev i Ops. W rzeczywistości jest to duża szansa dla administratorów baz danych, aby dorosnąć do tej rozwijającej się roli inżyniera DevOps, w tym monitorowania i optymalizacji wydajności serwera SQL.
Wiele DevOps opiera się na motcie:„Często upaść, szybko upaść”. Dokonuj małych, przyrostowych zmian i wprowadzaj je do produkcji. Jeśli powodują problem lub nie spełniają oczekiwań klientów, szybko je wycofaj, napraw i szybko przywróć do produkcji.
Jednak stanowi to realne ryzyko…
Nie zawsze łatwo jest zrozumieć podstawową przyczynę problemów z wydajnością lub stabilnością. Powiązanie kropek między zmianą, którą ktoś wprowadził w aplikacji lub infrastrukturze, a jej wpływem na obciążenie i wydajność bazy danych, zajmuje sporo czasu.
Te koncepcje są nieco nowe w DBA i zadanie spotkania się w środku, aby wziąć udział w kulturze DevOps, może wydawać się nieco przytłaczające. Ale musisz od czegoś zacząć. Wiele organizacji przyjmuje podejście polegające na przyglądaniu się problemom z wydajnością serwera SQL z innej perspektywy i wdrażaniu innej metody monitorowania.
Co by było, gdybyś miał wgląd w stan środowiska SQL Server potrzebny do proaktywnego rozwiązywania problemów z wydajnością… zanim poważnie wpłyną one na Twoją firmę? Co by było, gdybyś mógł szybko zidentyfikować pogorszenie wydajności, wyizolować przyczynę oraz przeanalizować i dostroić, aby zapobiec podobnym problemom w przyszłości?
A co by było, gdybyś mógł mieć to wszystko na zasadzie abonamentu? Bez dodatkowego sprzętu, bez oprogramowania, bez kosztów konserwacji i mieć do niego dostęp z dowolnego miejsca i o każdej porze na dowolnym urządzeniu?
Dzięki Spotlight Cloud możesz! To tak proste, jak Zarejestruj się. Zaloguj. Rozwiąż.
Zacznij od Spotlight Cloud, aby zapewnić niezrównane monitorowanie i diagnostykę baz danych hostowanych w chmurze dla programu SQL Server. To jak natychmiastowy awans!
