DBA, koniec kapłaństwa

Uwaga: ten post inżynierski został napisany przez naszego administratora danych, Silvię Botros i pierwotnie pojawił się na blogu Sysadvent w grudniu 2016 r.

Firmy od lat mają i potrzebują administratorów baz danych. Dane to jeden z najważniejszych aktywów firmy. Oznacza to, że wiele firm, które rozwiną się do punktu, w którym muszą być w stanie szybko się skalować, potrzebują kogoś, kto upewni się, że zasoby są dobrze zarządzane, wydajne dla potrzeb produktu i dostępne do przywrócenia w przypadku awarii.

W tradycyjnym sensie praca administratora baz danych oznacza, że ​​jest ona jedyną osobą mającą dostęp do serwerów, na których znajdują się dane, osobą, do której należy utworzyć nowy klaster baz danych dla nowych funkcji, osobą, która projektuje nowe schematy i jedyną osoba do kontaktu, gdy coś związanego z bazą danych ulegnie awarii w środowisku produkcyjnym.

Ponieważ administratorzy baz danych tradycyjnie pełnią tak wyjątkowe role, ich czas jest na wagę złota, trudniej jest myśleć całościowo, gdy codzienne zadania są przytłaczające. Typowe jest uciekanie się do kruchych narzędzi, takich jak bash, do wszelkiego rodzaju zadań operacyjnych w świecie DBA. Potrzebujesz nowej konfiguracji bazy danych z czystej instalacji systemu operacyjnego? Wykonywać, sprawdzać lub przywracać kopie zapasowe? Obracać partycje lub nieaktualne dane? Kiedy najczęściej używanym narzędziem jest skryptowanie bash, wszystko wygląda jak gwóźdź. Jestem pewien, że wielu czytelników przygotowuje tweety, aby powiedzieć mi, jak potężny jest bash, ale proszę wstrzymaj się z komentarzem do czasu oceny mojego rozumowania.

Czy to wszystko brzmi jak opis Twojej pracy jako DBA? Czy opis zadania zawiera szczegółowe informacje na temat aktualizacji serwerów, tworzenia i testowania kopii zapasowych oraz monitorowania? Większość typowych ofert pracy dla administratorów baz danych z pewnością powie, że musisz skonfigurować i skonfigurować „wiele” serwerów baz danych (ponieważ oczekuje się, że administratorzy baz danych będą je wykonywać ręcznie) oraz zautomatyzować zadania związane z zarządzaniem bazą danych za pomocą (ręcznie przygotowanych) skryptów.

Czy to naprawdę skalowalne podejście dla zespołu składającego się często z jednego zespołu w rozwijającej się, szybko rozwijającej się organizacji?

Jestem tutaj, aby argumentować, że Twoim zadaniem nie jest wykonywanie i zarządzanie kopiami zapasowymi, tworzenie i zarządzanie bazami danych ani optymalizacja zapytań. Wszystkie te czynności wykonasz w trakcie swojej pracy, ale głównym celem jest zapewnienie dostępności i skalowalności danych Twojej firmy. Nie chodzi tylko o to, aby firma mogła obsługiwać bieżący produkt, ale także budować nowe funkcje i dostarczać wartość klientom.

Czemu

Możesz zapytać, dlaczego miałbym to zrobić? Przemawia za kontynuacją pełnienia roli DBA w sposób tradycyjny: bezpieczeństwo pracy, prawda? Wiele organizacji technologicznych obecnie wykonuje jedną lub więcej z następujących czynności:

• Tworzą je wiele mniejszych zespołów
• Zapewniają funkcjonalność, tworząc wiele mikroserwisów w miejsce jednej lub kilku większych usług
• Przyjmują metodyki zwinne, aby przyspieszyć dostarczanie funkcji
• Łączą operacje i inżynierię pod jednym kierownictwem
• Włączają inżynierów operacyjnych z programistami na jak najwcześniejszym etapie procesu projektowania
• Silos DBA w ramach operacji oznacza, że ​​zespół operacyjny ma mniejsze możliwości pomagania w debugowaniu problemów produkcyjnych we własnym stosie, czasami nie jest w stanie reagować i naprawiać problemów bez pomocy i szczerze mówiąc, mniej wiarygodny w wymaganiu bliższej i wcześniejszej współpracy z zespołami inżynierskimi nie praktykowania tego, co głoszą w Tech Ops.

Co zatem można zrobić, aby obalić ten silos i ułatwić innym debugowanie, pomóc skalować warstwę bazy danych i umożliwić inżynierom projektowanie usług, które można skalować? Większość rozwijających się sklepów ma co najwyżej jednego wewnętrznego administratora baz danych. Czy jeden administrator baz danych może być „obecny” na wszystkich spotkaniach projektowych, zatwierdzać każdą zmianę w schemacie i być gotowym do obsługi rozległej, stale rosnącej bazy danych?

DBA nie mogą już być strażnikami ani magikami. DBA może i powinien być źródłem wiedzy i doświadczenia dla inżynierów w organizacji. Powinna pomagać zespołom dostawczym nie tylko w dostarczaniu funkcji, ale także w dostarczaniu produktów, które skalują się i pozwalają im nie bać się bazy danych. Ale jak DBA może to osiągnąć, wykonując codzienną pracę związaną z zarządzaniem warstwą danych? Jest wiele sposobów, w jakie ty, DBA, możesz przygotować się na doskonałość.

Zarządzanie konfiguracją

To bardzo ważne. Administratorzy baz danych zwykle preferują stare narzędzia szkolne, takie jak bash, do konfiguracji bazy danych. Nawiązałem do tego wcześniej i nie mam nic przeciwko używaniu samego basha. Właściwie często go używam. Ale nie jest to właściwe narzędzie do konfiguracji klastra. Zwłaszcza jeśli reszta operatorów NIE używa Bash do zarządzania resztą architektury. To prawda, że ​​inżynierowie operacyjni również znają Bash, ale jeśli zarządzają resztą infrastruktury za pomocą narzędzia takiego jak Chef lub Puppet, a bazami danych zarządzają głównie ręcznie tworzone skrypty napisane przez DBA, narzucasz im przeszkodę w dostarczaniu pomoc, gdy potrzebna jest pilna zmiana.

Co więcej, coraz trudniej jest pomagać zespołom inżynierskim w samoobsługi i tworzeniu nowych klastrów, których potrzebują do nowej funkcji „foo”. Stajesz się „blokerem” w wykonywaniu pracy. Zapoznanie się z zarządzaniem konfiguracją w Twojej firmie to także korzyść dwukierunkowa. Gdy zapoznasz się ze sposobem zarządzania infrastrukturą, poznasz standardy zespołu, zaznajomisz się ze stosem i będziesz w stanie współpracować przy zmianach, które ostatecznie wpływają na skalę produktu.

DBA, który jest dostrojony do produktu i infrastruktury organizacji jako całości, jest nieoceniony.

Runbooki

Technicznie rzecz biorąc, jest to podzbiór dokumentacji, którą musisz napisać, ale z mojego doświadczenia wynika, że ​​jest o wiele bardziej przydatny, ponieważ uważam, że należy go wskazać osobno. Kiedy mówię runbooki, mam na myśli dokument napisany dla odbiorców, który NIE jest DBA. Istnieje wiele problemów z produkcyjną bazą danych, które możemy napotkać jako administratorzy baz danych, które są dla nas łatwe do debugowania i rozwiązania. Mamy tendencję do niedoceniania tej pamięci mięśniowej i wpadamy w schemat „po prostu wyślij mi wiadomość” i „zajmujemy się rzeczami”.

Jeśli twój zespół operacyjny jest taki jak mój, w którym jesteś jedynym administratorem bazy danych, prawdopodobnie oznacza to, że ktoś inny w zespole jest pierwszą linią obrony, gdy strony związane ze zdarzeniami związanymi z DB. Prosta dokumentacja dotycząca wstępnego debugowania i zbierania danych może znacznie ułatwić pozostałym zespołowi operacyjnemu komfort korzystania z warstwy bazy danych i lepsze zapoznanie się z tym, jak ją monitorujemy i debugujemy. Nawet jeśli to wydarzenie nadal prowadzi do stronicowania DBA, powoli, ale pewnie, runbook staje się miejscem, w którym każdy może dodać zdobytą wiedzę.

Dodatkowo dodaję link do powiązanej sekcji elementu Runbook (użyj kotwic!) do opisów stron, które przechodzą do pagera. Jest to niezwykle pomocne dla kogoś, kto jest odwiedzany przez hosta bazy danych o 3 nad ranem, aby znaleźć miejsce, od którego można zacząć. Te rzeczy mogą wydawać się małe, ale z mojego doświadczenia przeszły długą drogę w przełamywaniu barier mentalnych dla mojego zespołu operacyjnego pracującego w warstwie bazy danych, gdy jest to konieczne.

Zgodnie z osobistymi preferencjami piszę je jako dokumenty przeceny w repozytoriach moich książek kucharskich szefa kuchni. To bezproblemowo wpisuje się w wzorzec żądania ściągnięcia, przeglądu i scalania i staje się integralną częścią wzorca książek kucharskich baz danych. Gdy zespoły inżynierskie zaczynają tworzyć własne, elementy runbook stają się znanym szablonem, ponieważ nowe klastry baz danych pojawiają się w każdym miejscu.

Widoczność

Lubimy nasze ekrany terminali. Kochamy ich. Najpopularniejszymi narzędziami w świecie MySQL są nadal narzędzia terminalowe, które żyją bezpośrednio na hostach baz danych i wymagają wcześniejszej wiedzy o nich i sposobie ich używania. Mówię o rzeczach takich jak innotop i powłoka MySQL. Są w porządku i nadal pomocne, ale są stworzone dla administratorów baz danych. Jeśli nie chcesz być strażnikiem na pytania typu „czy jest teraz opóźnienie replikacji?” potrzebujesz lepszych narzędzi, aby każdy stan klastra, teraz i w przeszłości, był dostępny i łatwy do strawienia dla wszystkich członków zespołu. Mam na tej arenie kilka przykładów:

Orkiestrator

Używamy replik do odczytu, aby rozłożyć to obciążenie z dala od podstawowego, co oznacza, że ​​gdy opóźnienie osiągnie określony próg, staje się zdarzeniem obsługi klienta. Ważne jest, aby ułatwić każdemu w firmie sprawdzenie w dowolnym momencie, czy w klastrze występuje opóźnienie, jakie są serwery w tym klastrze i czy któryś z hostów nie działa. Orchestrator jest świetnym narzędziem pod tym względem, ponieważ sprawia, że ​​wizualizacja klastrów i ich kondycji jest z dala od okna przeglądarki.

Grafana/Grafit

Metryki dla warstwy DB muszą znajdować się w tym samym miejscu co pozostałe metryki infrastruktury. Dla zespołu ważne jest, aby móc zestawić te wskaźniki obok siebie. I ważne jest, aby mieć łatwy sposób na przeglądanie historycznych metryk dla dowolnego klastra DB. Chociaż możesz mieć osobiste preferencje dotyczące kaktusów, munin lub rzemieślniczych szablonów, które napisałeś przez lata, jeśli metryki, których używasz do badania problemów, nie znajdują się w tym samym miejscu, co reszta metryk infrastruktury, tworzy to barierę dla inni zapracowani inżynierowie – i będą mniej skłonni do używania twoich narzędzi niż tych, które są używane gdzie indziej. Graphite jest szeroko stosowany do pozyskiwania metryk w nowoczesnych zespołach infrastruktury, a Grafana jest szeroko stosowanym interfejsem do tworzenia kokpitów dla metryk i analiz.

Wydajność zapytań

Używamy VividCortex do śledzenia naszych zapytań w krytycznych klastrach i chociaż ten artykuł nie ma być reklamą płatnej usługi, powiem, że musisz mieć możliwość sprawdzenia wpływu wdrożeń i zmian kodu na uruchamianie zapytań i wydajność zapytań, coś, co nie wymaga specjalnego dostępu do dzienników i ręcznego ich przetwarzania. Jeśli VividCortex nie jest możliwy (chociaż, poważnie, są niesamowite!), istnieją inne produkty i narzędzia typu open source, które mogą przechwycić nawet powolny dziennik i umieścić go na łatwej do odczytania stronie internetowej do sprawdzenia przez osoby niebędące administratorami baz danych i zobacz efekt ich kodu. Ważną kwestią jest to, że jeśli zapewnisz środki do przeglądania danych, inżynierowie wykorzystają te dane i dołożą wszelkich starań, aby wszystko było wydajne. Ale udostępnienie tego dostępu jest częścią twojej pracy, a nie specjalną sztuczką DBA.

Walcz ze zmęczeniem pagera

Wiele organizacji nie traktuje skalowania warstwy bazy danych jako bardzo wczesnej konieczności projektowania stosu — i nie powinno. Na początku istnienia firmy nie powinieneś martwić się o to, jak dławisz wywołania API, jeśli nikt jeszcze z niego nie korzysta. Należy jednak wziąć pod uwagę kilka lat później, kiedy produkt zyskał popularność, a wywołanie interfejsu API, które trafiło na tabelę z kilkoma tysiącami wierszy przez garstkę klientów, jest teraz tabelą z wieloma milionami wierszy i kilku klientów. zbudowaliśmy zadania cron, które zalewają ten interfejs API każdego ranka o 6 rano w Twojej strefie czasowej.

Zmiana warstwy aplikacji dowolnego produktu w celu ochrony infrastruktury wymaga wiele pracy, aw międzyczasie umożliwienie fałszywej aktywności bazy danych powodującej zmęczenie pagera jest dużym zagrożeniem zarówno dla Ciebie, jak i dla reszty organizacji operacyjnej. Zapoznaj się z narzędziami, takimi jak pt-kill, których można użyć w mgnieniu oka, aby zapobiec poważnym przestojom hosta bazy danych z powodu nieplanowanego woluminu. Poinformuj o użyciu tego narzędzia i poinformuj o działaniu i jego efektach zespołowi inżynierskiemu, ale niezdrowe jest próbowanie wchłonięcia bólu związanego z czymś, czego bezpośrednio nie możesz zmienić, a pomoc zespołom inżynierskim ostatecznie nie będzie korzystna ' nauczyć się radzić sobie z bólami wzrostu.

Jest wiele sposobów, w jakie praca DBA jest wyjątkowa dla jej roli w porównaniu z resztą zespołu operacyjnego, ale to nie znaczy, że musi to być magiczne kapłaństwo, do którego nikt nie może się zbliżyć. Te kroki znacznie zwiększają przejrzystość Twojej pracy, ale co najważniejsze, nie traktujesz swojej pracy jako strażnika złotego ogrodu hosta bazy danych, ale jako eksperta w danej dziedzinie, który może udzielić porad i pomóc w rozwoju inżynierów, z którymi pracujesz, i zapewnić więcej wartość dla firmy niż kopie zapasowe i dostrajanie zapytań (ale to też jest zabawne!).

Specjalne podziękowania dla wspaniałego zespołu operacyjnego w Sendgrid, który nadal uczy mnie wielu rzeczy, oraz dla Charity Majors za wymyślenie tytułu tego postu. Sprawdź więcej postów na temat administratorów baz danych tutaj.