May 17, 2026, 11:40 PM

2026-05-18 06:40:19 +00:00
commit 64944cf004
896 changed files with 310709 additions and 0 deletions
@@ -0,0 +1,149 @@
+---
+type: 'DailyNote'
+title: October 7, 2025
+date: '2025-10-07T00:00:00.000Z'
+tags: [dba, migracja]
+---
+
+### 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”.
+