Paweł Domański
150 lines
5.6 KiB
Markdown
150 lines
5.6 KiB
Markdown
---
|
||
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”.
|
||
|