Files
DBAdmin/inbox/uporzadkowane_notatki.md
Paweł Domański d72848434d Jun 9, 2026, 3:55 PM
2026-06-09 13:55:39 +00:00

4.8 KiB
Raw Permalink Blame History

Notatki ze spotkania

Spotkanie 1: Strategia patchowania i optymalizacja operacji

Tematy dyskusji:

  • Zespół zdecydował o kontynuowaniu patchowania środowisk produkcyjnych i nieprodukcyjnych w okresie letnim, z wyjątkiem produkcji w Szwecji, Danii, Norwegii i Finlandii z powodu obecnych ograniczeń.
  • Leszek wyjaśnił, że konieczna jest zmiana w projekcie automatyzacji, aby umożliwić zatrzymanie patchowania na konkretnych rynkach, i potwierdził, że jest to wykonalne.
  • Omówiono potrzebę wykluczania lub nieustawiania niestandardowych polityk (w tym dynamicznych i statycznych) dla niektórych krajów.
  • Zespoły inżynieryjne i platformowe współpracują nad optymalizacją wymiany certyfikatów w całej Europie, aby zmniejszyć obciążenie operacyjne ze względu na skracające się okresy ważności certyfikatów.

Zgodność z RODO i Logowanie systemów:

  • Dyskutowano nad wdrażaniem logowania systemów dla wszystkich usług w Europie. Logi będą wysyłane do Splunka i przekazywane do działu bezpieczeństwa, z wyłączeniem danych chronionych przez RODO.
  • Oleksandr wyraził obawy dotyczące niejasnych planów przyszłego gromadzenia logów mogą one być zbierane bez odpowiedniej weryfikacji, co niesie ryzyko problemów ze zgodnością z RODO.
  • Leszek podkreślił, że wszelkie zmiany w zbieraniu logów mające wpływ na produkcję muszą wymagać procedury Change Request (CR) i obejmować wszystkie dotknięte elementy konfiguracji.
  • Zgodzono się na potrzebę ogólnoeuropejskiego rozwiązania zapewniającego zgodność logowania SecOps z RODO, unikając obsługiwania wyjątków na poziomie pojedynczych serwerów.
  • Zasugerowano konsultacje z Larsem Gehringiem w sprawach definicji i wymogów RODO (które są omawiane na firmowych szkoleniach bezpieczeństwa). Lars ma poprowadzić dyskusje z działem prawnym i compliance, a wszelkie przyszłe zmiany w zbieraniu logów powinny być przez nich zatwierdzane.
  • Uzgodniono, że konieczne jest dostarczenie przykładów chronionych danych oraz nazw plików do wykluczenia (zadanie ręczne, wymagające koordynacji z odpowiednim zespołem). Zgodzono się omówić kwestie zgodności RODO z Larsem na spotkaniu zaplanowanym na kolejny dzień.

Migracja sieci:

  • Martin wyjaśnił, że ostatnia partia sieci serwerowych połączonych z backendowymi zaporami sieciowymi Checkpoint zostanie zmigrowana w środę o 3:00 rano. Ma to na celu zamknięcie przestarzałych zapór (End-of-Life) do końca czerwca.
  • Migracje w Finlandii i Szwajcarii zostały już zakończone. Backendowe zapory w Szwecji będą zmigrowane w nadchodzącej partii, natomiast zapory zwrócone w stronę internetu zaplanowano na pierwsze okno serwisowe po przerwie letniej.

Zadania następcze (Follow-up tasks):

  • Prześlij plany urlopowe na okres letni (wszyscy uczestnicy).
  • Wdróż zmianę w projekcie automatyzacji, umożliwiającą zatrzymanie patchowania dla konkretnych rynków (Leszek).
  • Wyklucz kraje nordyckie z patchowania w lipcu, kontynuując patchowanie w czerwcu i sierpniu (wszyscy uczestnicy).
  • Przedstaw i wyślij konkretne przykłady danych chronionych przez RODO znalezionych w logach systemowych Dimie do analizy bezpieczeństwa (Oleksandr, wszyscy uczestnicy).
  • Zaplanuj spotkanie z Larsem, aby przejrzeć zgody prawne i zgodności dotyczące zmian w gromadzeniu logów (Kamil, TEAMS RM STO Quantum).

Spotkanie 2: Migracja serwerów (Paweł)

Tematy dyskusji:

  • Paweł poinformował, że testy migracji zostały wstrzymane w oczekiwaniu na licencje, które mają zostać dostarczone przez Adriana.
  • Paweł zadeklarował gotowość do wsparcia przy konfiguracji dostępu dla deweloperów oraz przygotowaniu środowiska przed migracją.

Zadania następcze (Follow-up tasks):

  • Prześlij roadmapę projektu migracji oraz opisz, w jaki sposób zbudowana jest aplikacja i baza danych Oracle (Gregor).

Spotkanie 3: Migracja i bazy danych (Gregor)

Tematy dyskusji:

  • Gregor ma zgłosić Service Request (SR) o nadanie dostępu dla swoich użytkowników. Poinformowano go, że nie otrzyma uprawnień administratora systemu (sys admin), więc należy ustalić alternatywny sposób działania.
  • Główne założenia i rola w projekcie: Zmiksowanie (migracja) 3 istniejących instancji oraz podłączenie nowych do serwera SQL.
  • Harmonogram: Zespół Gregora ma rozpocząć pracę i wejść do projektu migracyjnego przed końcem czerwca.
  • Ustalenia: Należy uzyskać od Gregora roadmapę całego przedsięwzięcia w celu ustosunkowania się i zaplanowania własnej pracy w ramach tego projektu.
  • Podejście techniczne: Gregor wyjaśnił, że proces będzie specyficzny (równoległe wsparcie dla bazy Oracle i nowej SQL). Proces odłączania starych i przyłączania nowych systemów ma być płynny i "bardzo przyjazny dla użytkownika".