DBAdmin/journals/meetings/07-10-2025-dba.md

title, date, tags, type, Status, _archived

title	date	tags	type	Status	_archived
October 7, 2025	2025-10-07T00:00:00.000Z	dba migracja	Meeting	Archived	true

Uporządkowane notatki ze spotkania

1) Temat przewodni

• Przegląd zadań infrastrukturalnych i wpływu na DBA

• Szacunki czasowe i odpowiedzialności zespołów (DBA, Windows, Linux, Network)

• Porządkowanie procesu ticketów/obserwowalności i dokumentacji pracy

• Planowanie rebootów (server uptime) i migracji (m.in. HU)

2) Decyzje i ustalenia

• Active Directory end-of-life:

  • Decommissioning kontrolerów domeny w Europie (ok. 91 DC) – brak wpływu na bazy danych, bo nie dekomisjonujemy domen/AD.

• DHCP, KMS, serwery plików, Veeam, jump stations (Windows):

  • Brak bezpośrednich zadań dla DBA, z wyjątkiem jump stations.

• Jump stations (Windows):

  • Potrzebne klienty DB: SQL Server Management Studio (SSMS), MySQL client/workbench (freeware, ale wymagane zgłoszenie/proces).

  • Konieczna migracja zapisanych połączeń/konfiguracji (uwaga: skopiować pełny zestaw plików konfiguracyjnych, nie 2/3).

  • Integracja z CyberArk – zachować spójność po migracji.

  • Szacunek pracy: wpisujemy 20 godzin (kompromis – w zespole są rozbieżne potrzeby od 2h do pełnego dnia/osobę).

• Server uptime / kwartalne restarty:

  • Cel: każdy serwer restartowany raz na kwartał; przygotowanie procesu identyfikacji maszyn z długim uptime i bezpiecznych restartów.

  • DBA: obecność standby podczas okien restartowych, weryfikacja dostępności instancji po restarcie, szybkie sanity checki.

  • Szacunek przygotowawczy: 30 godzin (osobodzień DBA/kwartał na przeglądy i koordynację; BAU/KTLO później).

• Migracja HU (Węgry):

  • 16 serwerów (gł. Windows). Zakres DBA zależny od tego, czy to będzie „lift-and-shift” VM czy równoległa modernizacja (np. 2012 → 2025).

  • Jeśli 1:1 przeniesienie – kilka godzin DBA na walidację; jeśli modernizacja – większy nakład (kontrola kompatybilności, logins, joby, ustawienia instancji).

  • Na teraz wpisane 50 godzin (do weryfikacji po doprecyzowaniu listy baz i sposobu migracji).

• Projekty end-of-life baz danych:

  • Nie ma dodatkowych pozycji poza tymi widocznymi; migracje baz trwają ciągle (co miesiąc). To powinno być uwzględniane w planie rocznym.

• Inne:

  • „Disable switchboards impaired by migration to GCP” – faza discovery przez ServiceNow/DB app (czeka na doprecyzowanie/scan).

3) Wpływ na DBA – główne punkty

• Jump stations:

  • Instalacja i konfiguracja klientów (SSMS, MySQL), przeniesienie profili/połączeń, dostosowanie CyberArk.

• Rebooty kwartalne:

  • Standby i post-check po restarcie; test zapytań zdrowotnych; ewentualne odtworzenie dostępu.

• Migracje (ciągłe, miesięczne):

  • Realny, stały nakład pracy nieodzwierciedlony w bieżącym arkuszu – potrzeba lepszej ewidencji.

• HU:

  • Do potwierdzenia sposób migracji i lista instancji, możliwy większy effort przy modernizacji.

4) Szacunki godzin (aktualne wpisy)

• Jump stations (DBA): 20h

• Server uptime (przygotowanie procesu, nie BAU): 30h

• Migracja HU: 50h

• Inne zespoły: w arkuszu łącznie ~60h dla Network/Linux/Windows (potwierdzone jako sensowne)

• Uwaga: migracje comiesięczne baz – duży, stały effort, którego nie widać w sumie godzin (do odzwierciedlenia).

5) Ryzyka i uwagi

• Utrata zapisanych połączeń/konfiguracji na jump stations – konieczny pełny backup plików konfiguracyjnych klientów DB.

• Zależności od AD (konty serwisowe dla SQL/Agent), uprawnień i dostępów – czasochłonne i często niewidoczne w taskach głównych.

• Niska obserwowalność po stronie DB (brak pełnej integracji ze Splunk/Zabbix/ServiceNow) powoduje niedoszacowanie prac DBA.

• Długie cykle ticketów DBA i prace równoległe utrudniają rzetelne raportowanie czasu.

6) Działania następne

• Jump stations:

  • Sporządzić krótką instrukcję eksportu/importu konfiguracji klientów (SSMS, MySQL Workbench/CLI).

  • Zgłosić instalacje freeware formalnym kanałem; potwierdzić zgodność z CyberArk.

• Server uptime:

  • Zbudować proces: generowanie listy serwerów z długim uptime, planowe okna, lista kontrolna DB po restarcie, przypisanie odpowiedzialnych/standby.

• Migracja HU:

  • Uzyskać inwentarz baz/instancji, potwierdzić tryb migracji (lift-and-shift vs modernizacja), zaktualizować estymaty.

• Widoczność pracy DBA:

  • Ustalić automatyzację generowania ticketów z alertów (preferowany Splunk; ewentualnie mostkowanie Zabbix → ServiceNow).

  • Zdefiniować minimalne logowanie czasu przy incydentach/projektach, aby tworzyć metryki (dashboard obciążenia i typów pracy).

  • Przegląd listy odpowiedzialności DBA i dopisanie brakujących elementów do arkusza projektów (szczególnie migracje cykliczne).

• Komunikacja:

  • W piątek wrócić do tematu metryk/ticketów i potwierdzić estymaty (zwłaszcza jump stations, server uptime, HU).

7) Otwarte pytania

• Czy HU będzie czystym przeniesieniem VM, czy modernizacją systemów/SQL?

• Jaki dokładnie zestaw klientów DB ma być standardem na jump stations (wersje, polityka aktualizacji)?

• Które narzędzie do automatyzacji ticketów wybieramy (Splunk vs integracja Zabbix → ServiceNow) i jaki jest plan wdrożenia?

• Jak formalnie włączyć comiesięczne migracje DB do planu/arkusza (pozycja BAU/KTLO czy dedykowane projekty)?

Jeśli chcesz, przygotuję krótką checklistę dla:

• eksportu/importu profili połączeń SSMS i MySQL Workbench,

• sanity check po restarcie serwera dla SQL Server i MySQL,

• szablon zadania w ServiceNow dla „quarterly reboot DB check”.