Paweł Domański
92 lines
7.6 KiB
Markdown
92 lines
7.6 KiB
Markdown
---
|
||
type: Meeting
|
||
Status: Archived
|
||
_archived: true
|
||
---
|
||
📝 Notatka ze spotkania: Local Swiss System Piccard
|
||
Cel spotkania: Ujednolicenie oczekiwań oraz planu działań w związku z niedawnymi incydentami wydajnościowymi w systemie Piccard i innych systemach szwajcarskich.
|
||
|
||
🔍 Główne tematy dyskusji
|
||
Wpływ incydentów i odpowiedzialność: Ostatnie awarie miały bezpośredni wpływ na ciągłość biznesową w Szwajcarii (Antje). Ustalono, że konieczne jest jasne zdefiniowanie własności systemów i odpowiedzialności za rozwiązywanie problemów.
|
||
Zmiany organizacyjne i dług techniczny: Zespoły Sundarama, Radka i Luki raportują teraz do Sunila, a zespoły infrastrukturalne do Adriana. Po odejściu Guido (który dbał o doraźne łatki) zespół musi skupić się na eliminacji przyczyn źródłowych (Root Cause) zamiast stosowania obejść.
|
||
Zarządzanie incydentami: Należy poprawić jakość zgłoszeń (ticketów) i wykorzystywać tzw. "working bridges" (mostki) w celu szybszej i lepszej współpracy międzyzespołowej. Aby priorytetyzować prace nad przestarzałymi systemami, Antje zasugerowała mocniejsze wykorzystywanie procesów PIR (Post-Incident Review).
|
||
Problemy z bazą danych: Trwające problemy z blokującymi się sesjami i stabilnością dotyczą bazy audytowej frameworka Spring Batch, a nie głównej bazy biznesowej Piccard (Martin, Luca). Jest to powrót problemu sprzed 3 lat.
|
||
Propozycje rozwiązań technicznych:
|
||
Głęboka analiza pojemności i zmian we wzorcach użycia bazy audytowej (Antje).
|
||
Partycjonowanie danych – rozwiązanie, które w przeszłości zastosował Guido, gdy wolumen danych znacząco wzrósł (Luca).
|
||
Analiza zależności procesów, odpytywanie bazy o uruchomione zadania i ich sortowanie, aby zidentyfikować główne blokady (Leszek).
|
||
Aktualizacja systemu Piccard: Kompleksowy upgrade to duży projekt wymagający zmian strukturalnych w nowej bazie danych (Roberto).
|
||
🎯 Podjęte decyzje
|
||
Wszystkie stopniowe ulepszenia i wnioski z analiz będą na bieżąco dokumentowane w systemie śledzenia zadań.
|
||
Zostanie zaplanowane kolejne spotkanie (follow-up) w celu weryfikacji postępów prac.
|
||
❓ Otwarte pytania
|
||
Dokładna przyczyna źródłowa (Root Cause) ciągłego blokowania się bazy audytowej nadal wymaga zbadania.
|
||
Decyzja o aktualizacji (upgrade) całego systemu Piccard jest zawieszona – wymaga weryfikacji dostępnych zasobów i ustalenia priorytetów.
|
||
📋 Zadania do wykonania (Action Items)
|
||
[Antje, Adrian, Sundaram, Radek, Luca] – Doprecyzowanie odpowiedzialności i podziału zadań związanych z trwającymi incydentami w systemach szwajcarskich.
|
||
[Adrian, Luca, Martin, DB team, AO team] – Ustanowienie "incident bridge" dla awarii związanych z systemem Piccard w celu sprawnej współpracy i przypisywania zadań do odpowiedzialnych zespołów.
|
||
[Luca] – Przygotowanie listy wymaganych aktualizacji systemowych i ulepszeń dla szwajcarskich produktów (i udostępnienie jej na czacie).
|
||
[Adrian] – Rozpoczęcie analizy przyczyny źródłowej powtarzających się problemów z wykonywaniem zadań (jobów) w bazie audytowej.
|
||
[Paweł, Leszek, Luca] – Wypracowanie jasnego podziału na problemy leżące po stronie aplikacji vs problemy po stronie bazy danych, aby usprawnić troubleshooting.
|
||
[Zespoły techniczne] – Zaplanowanie regularnych sesji roboczych (deep dives / burze mózgów) w celu rozwiązywania cyklicznie powracających problemów.
|
||
|
||
|
||
--- source
|
||
Decisions
|
||
|
||
Document incremental improvements and findings in a tracking system.
|
||
Set up a follow-up meeting to review progress.
|
||
Open questions
|
||
|
||
Root cause of audit database blocking needs further investigation.
|
||
Feasibility of Picard system upgrade is unresolved due to priorities and resources.
|
||
Agenda
|
||
Goal: Align on expectations and actions regarding recent incidents in Piccard and other Swiss systems
|
||
|
||
|
||
Review recent incidents for Piccard and Swiss systems (10 min)
|
||
Discuss potential improvements in monitoring and alerting (10 min)
|
||
Align on expectations and actions for incident/engagement process (10 min)
|
||
Meeting notes
|
||
Incident impact and ownership
|
||
|
||
Antje explained that recent incidents in Piccard and other Swiss systems have caused disruptions to the local Swiss business, and highlighted the need to clarify ownership and responsibilities moving forward.
|
||
Roles and reporting structure
|
||
|
||
Antje confirmed that Sundaram, Radek, Luca, and their teams now report to Sunil, while infrastructure teams continue to report to Adrian.
|
||
System maintenance and transition
|
||
|
||
Adrian stated that Guido previously played a critical role in maintaining Swiss products, often implementing temporary fixes, and emphasized the need to address root causes now that Guido is no longer with the organization.
|
||
Luca confirmed that their team is actively working on improvements for recurring issues in Swiss products
|
||
Antje suggested using the PIR as a vehicle to prioritize backlog items for aging Swiss systems
|
||
Incident management
|
||
|
||
Antje discussed the importance of improving ticket quality and encouraged all teams to use working bridges for timely cross-team collaboration
|
||
Luca described ongoing collaboration with Paweł, Demchuk, and Martin to address daily database hanging sessions and improve system stability
|
||
System stability and database issues
|
||
|
||
Martin clarified that the recurring issues are caused by the audit database used by the Spring Batch framework, not the Picard business database.
|
||
Martin described that recurring job execution issues in the audit database have resurfaced, similar to incidents from three years ago, and emphasized that fixing these consumes significant daily effort.
|
||
Antje suggested conducting a deeper analysis of the audit database to investigate potential capacity issues and evolving usage patterns.
|
||
Luca recalled that Guido previously improved performance by partitioning the database when data volume reached a certain level, and proposed reviewing if similar action is needed now.
|
||
Leszek recommended breaking down processes, querying the database for running jobs, and sorting them by data dependencies to identify and resolve blocking issues.
|
||
Martin described that recurring job execution issues in the audit database have resurfaced, similar to incidents from three years ago, and emphasized that fixing these consumes significant daily effort.
|
||
Antje suggested conducting a deeper analysis of the audit database to investigate potential capacity issues and evolving usage patterns.
|
||
System upgrades and project scope
|
||
|
||
Roberto confirmed that structural changes to the new database would be required, making the upgrade a significant project.
|
||
System architecture
|
||
|
||
Luca clarified that the audit database is related to the Spring Batch environment and not to GDPR compliance, addressing previous confusion
|
||
Follow-up tasks
|
||
|
||
Task Assigned to Due date Bucket
|
||
Clarify ownership of tasks and responsibilities for ongoing incidents in Swiss systems (Antje, Adrian, Sundaram, Radek, Luca)
|
||
Establish an incident bridge for Picard-related incidents to enable cross-team collaboration and assign tasks to accountable teams (Adrian, Luca, Martin, DB team, AO team)
|
||
Compile a list of system upgrades and improvements needed for Swiss products and share in the chat (Luca)
|
||
Adrian proposed investigating the underlying cause of recurring job execution issues in the audit database after the meeting.
|
||
Clarify the distinction between application-level and database-level issues for more effective troubleshooting (Paweł, Leszek, Luca)
|
||
Antje suggested that the technical team hold regular working sessions to conduct deep dives and brainstorming on recurring issues
|
||
Compile a list of system upgrades and improvements needed for Swiss products and share in the chat (Luca)
|
||
|