---
title: October 7, 2025
date: '2025-10-07T00:00:00.000Z'
tags: [dba, migracja]
type: Meeting
Status: Archived
_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”.