Migracja z Power Automate do n8n bez utraty SLA: jak przenieść automatyzacje i zachować logi

Od czego zacząć migrację z Power Automate do n8n, żeby nie zgubić krytycznych procesów?

Zacznij od inwentaryzacji i klasyfikacji istniejących przepływów w Power Automate tak, aby jednoznacznie wskazać, co jest krytyczne i jakie ma wymagania operacyjne. W praktyce oznacza to zebranie listy wszystkich flow wraz z: wyzwalaczem (trigger), systemami źródłowymi i docelowymi, kontami/połączeniami (connections) i uprawnieniami, harmonogramem/warunkami uruchomienia, zależnościami między przepływami, wymaganiami czasowymi (SLA) oraz sposobem obsługi błędów (retry, timeouty, ścieżki awaryjne). Bez tego łatwo przenieść „logikę”, ale zgubić elementy, które decydują o niezawodności.

Następnie ustal „minimalny zakres migracji” dla procesów krytycznych: co dokładnie ma zostać zachowane 1:1 (np. warunki uruchomienia, idempotencja, reguły ponowień, rozdzielenie ścieżek sukces/błąd), a co może ulec zmianie bez wpływu na SLA. Kluczowe jest też potwierdzenie ekwiwalentów integracyjnych po stronie n8n: czy potrzebne konektory istnieją, czy wymagają użycia HTTP/API, oraz czy n8n ma dostęp sieciowy do tych samych zasobów (np. systemów on-prem, prywatnych endpointów). Jeśli na tym etapie wyjdą luki (brak dostępu, brak bezpiecznego uwierzytelnienia, brak odpowiednika danego kroku), to proces jest „krytyczny”, ale niegotowy do migracji i powinien pozostać w Power Automate do czasu usunięcia blokad.

Dopiero mając mapę procesów i wymagania, przygotuj w n8n środowisko pod migrację: spójny sposób zarządzania danymi uwierzytelniającymi, zmiennymi/sekretami, kontrolą dostępu do workflow oraz standardem nazewnictwa i wersjonowania. To ogranicza ryzyko, że krytyczne automatyzacje zostaną wdrożone „ręcznie” i niespójnie, a później nie będzie wiadomo, na jakich kontach działają i kto ma do nich dostęp.

Na koniec zaplanuj migrację krytycznych procesów jako uruchomienie równoległe (co najmniej przez okres obserwacji), z jednoznacznym kryterium przełączenia i możliwością szybkiego rollbacku. Równoległość jest istotna, bo pozwala porównać wyniki i wykryć różnice w zachowaniu (np. kolejność zdarzeń, duplikaty, limity API, opóźnienia) zanim wyłączysz oryginalny flow. Jeśli nie jesteś w stanie zapewnić równoległego działania (np. z powodu skutków ubocznych), zaprojektuj „bezpieczny test” na danych kontrolowanych lub w trybie odczytu, żeby zweryfikować logikę bez wpływu na produkcję.

2 - Jak zrobić inwentaryzację flow i wyznaczyć priorytety pod kątem SLA oraz ryzyka biznesowego?

Inwentaryzację zacznij od zebrania pełnej listy flow (w tym wyłączonych i uruchamianych ręcznie) oraz ich podstawowych metadanych. Dla każdego flow zanotuj: nazwę i właściciela biznesowego, opis celu, systemy źródłowe/docelowe, typ wyzwalacza (zdarzenie/harmonogram/manual), częstotliwość, krytyczne kroki (np. zapis do systemu finansowego), wolumen (liczba uruchomień/dzień), średni i maksymalny czas wykonania, historyczną liczbę błędów oraz sposób obsługi awarii (retry, alerty, ręczna naprawa). Równolegle dopisz zależności: czy flow uruchamia inne flow lub jest częścią łańcucha, oraz jakie dane i uprawnienia przetwarza.

Następnie dla każdego flow określ wymagania SLA w kategoriach mierzalnych i możliwych do monitorowania: RTO (jak szybko musi wrócić po awarii), RPO (akceptowalna utrata danych/zdarzeń), docelową dostępność (np. okno serwisowe), maksymalny czas przetworzenia od triggera do efektu oraz progi alertowania (czas bez uruchomienia, liczba błędów z rzędu, opóźnienie kolejki). Jeśli formalnego SLA nie ma, ustal je z właścicielem procesu na podstawie skutków opóźnienia lub błędu (np. opóźniona faktura vs. błędna aktualizacja stanów magazynowych).

Priorytetyzację wykonaj, nadając każdemu flow dwie niezależne oceny: krytyczność SLA (jak dotkliwy jest brak dotrzymania parametrów czasu/dostępności) oraz ryzyko biznesowe (jak dotkliwe są błędy merytoryczne, utrata danych, naruszenie zgodności lub bezpieczeństwa). Oceny warto oprzeć na prostych, spójnych kryteriach (np. skala 1–5), a wynik końcowy wyznaczyć jako macierz: najpierw migrować i zabezpieczać flow o wysokiej krytyczności SLA i wysokim ryzyku biznesowym.

Na koniec utwórz krótką listę „Top N” flow do pierwszej fali (wysokie SLA i/lub wysokie ryzyko) oraz grupę „low risk/low SLA” do migracji masowej. Dla flow z wysokim ryzykiem, ale niższym SLA, priorytet uzasadnia zwykle konieczność kontroli poprawności danych i rozliczalności (np. możliwość odtworzenia, jednoznaczne identyfikatory transakcji, odporność na duplikaty). Taki podział pozwala zaplanować kolejność prac tak, by najpierw zabezpieczyć procesy krytyczne dla ciągłości działania i minimalizować ryzyko incydentów biznesowych podczas migracji.

Jak mapować konektory i akcje Power Automate na node’y w n8n, gdy nie ma 1:1 odpowiedników?

Mapowanie zacznij od ustalenia, co dana akcja w Power Automate faktycznie robi na poziomie technicznym: jaki jest system docelowy, jaki typ operacji (odczyt/zapis/wywołanie), jakie dane wejściowe/wyjściowe oraz jakie wymagania ma uwierzytelnienie. W n8n nie szuka się „tej samej akcji”, tylko odtwarza ten sam efekt biznesowy, często inną kombinacją node’ów.

Jeżeli w n8n nie ma odpowiednika danego konektora/akcji, najczęściej zastępuje się go wywołaniem API danego systemu przez HTTP Request. To podejście wymaga przeniesienia z Power Automate szczegółów, które w konektorze były ukryte: endpointów, metod, nagłówków, parametrów, paginacji, limitów oraz modelu autoryzacji (np. OAuth2, token, klucze). Dzięki temu uzyskujesz kontrolę nad dokładnym zachowaniem integracji i minimalizujesz ryzyko różnic funkcjonalnych wynikających z „magii” konektorów.

Dla akcji transformacyjnych i sterujących, które w Power Automate występują jako osobne kroki (np. warunki, pętle, manipulacje danymi), mapowanie zwykle polega na złożeniu ich z wbudowanych mechanizmów n8n. W praktyce oznacza to przeniesienie logiki do node’ów typu IF (warunki), Switch (wielowariantowe rozgałęzienia), Merge (łączenie strumieni danych) oraz do node’ów skryptowych (Code) przy bardziej niestandardowych przekształceniach. Kluczowe jest dopasowanie nie nazwy kroku, tylko semantyki: kiedy powstaje nowy „rekord” danych, jak wygląda iteracja po elementach i jakie pola są przekazywane dalej.

W przypadku operacji na systemach Microsoft 365 typowym problemem jest różnica w „warstwie integracji”: Power Automate często używa dedykowanych akcji, a w n8n bywa, że szybciej i precyzyjniej odtworzysz je przez Microsoft Graph (czyli znowu przez HTTP Request), zwłaszcza gdy potrzebujesz funkcji, których nie obejmuje dostępny node. Przy mapowaniu zawsze weryfikuj, czy dana akcja w Power Automate nie wykonywała dodatkowych czynności ubocznych (np. automatyczne dopasowanie identyfikatorów, domyślne filtrowanie, niejawne konwersje typów), bo w n8n te elementy muszą zostać zaimplementowane jawnie.

Ostatni krok to dopasowanie kontraktów danych między krokami. Power Automate często pracuje na „dynamic content” i obiektach o przewidywalnej strukturze, natomiast w n8n trzeba świadomie ustalić, czy kolejne node’y mają dostawać pojedynczy element czy listę elementów oraz jak będą nazywały się pola. Tam, gdzie nie ma 1:1 odpowiednika, poprawne mapowanie polega na tym, że po wykonaniu zastępczych node’ów otrzymujesz ten sam kształt danych (lub zgodny z oczekiwaniami następnych kroków), nawet jeśli droga do tego jest inna.

Jak przenieść obsługę błędów, retry i time-outy, żeby zachować niezawodność procesu?

W n8n niezawodność procesu uzyskuje się przez świadome rozdzielenie trzech mechanizmów: obsługi błędów (co robić, gdy coś się nie uda), ponowień (kiedy i ile razy próbować ponownie) oraz limitów czasu (kiedy przerwać oczekiwanie). W praktyce oznacza to, że podczas migracji trzeba zidentyfikować miejsca w Power Automate, gdzie błąd był „łapany” warunkami lub konfiguracją akcji, a następnie odtworzyć to w n8n na poziomie przepływu: ścieżką awaryjną uruchamianą po niepowodzeniu kroku oraz decyzją, czy błąd ma zatrzymać workflow, czy zostać obsłużony i przejść dalej (np. z oznaczeniem statusu).

Retry w n8n należy przenieść jako kontrolowaną pętlę lub wbudowane ponowienia tam, gdzie są dostępne, z tym samym celem co w Power Automate: odporność na chwilowe błędy sieci, limity API i niestabilność usług. Kluczowe jest rozróżnienie błędów przejściowych od trwałych: ponowienia mają sens dla timeoutów i odpowiedzi typu „rate limit”, ale nie dla błędów walidacji danych czy braku uprawnień. Przy migracji warto zachować równoważne parametry: maksymalną liczbę prób, odstęp między próbami oraz strategię opóźnień (stała lub narastająca), a także warunek przerwania ponowień, gdy błąd jest jednoznacznie trwały.

Time-outy trzeba przenieść na poziomie wywołań zewnętrznych (np. żądań HTTP, operacji na bazie, integracji), tak aby pojedynczy krok nie blokował całego wykonania dłużej niż dopuszcza SLA. Jeśli w Power Automate dany krok miał limit czasu lub „timeout policy”, w n8n należy zapewnić analogiczny limit przez konfigurację czasu oczekiwania w węźle (o ile wspierane) lub przez logikę przepływu, która po przekroczeniu czasu przechodzi w ścieżkę błędu i np. planuje ponowienie. Najważniejsze jest spójne ustawienie budżetu czasu: suma time-outów i opóźnień między retry nie może przekroczyć maksymalnego czasu, po którym proces ma zostać uznany za nieudany i przekazany do obsługi awaryjnej.

Żeby zachować przewidywalność, obsługę błędów projektuje się tak, by każdy nieudany krok kończył się jednoznacznym rezultatem: albo kontrolowanym przerwaniem całego workflow, albo zakończeniem z oznaczeniem porażki i przekazaniem kontekstu (co się stało, jaki był ostatni poprawny etap, jaki identyfikator rekordu/sprawy). Dzięki temu retry i time-outy nie „maskują” problemów, a jednocześnie proces jest odporny na incydenty przejściowe bez utraty kontroli nad czasem wykonania.

Jak zachować idempotencję i uniknąć duplikowania operacji po awarii w nowym środowisku?

Idempotencja w kontekście n8n oznacza, że ponowne uruchomienie tego samego workflow (np. po restarcie, timeoucie, błędzie w połowie wykonania lub ponownym dostarczeniu webhooka) nie może spowodować ponownego wykonania skutków ubocznych, takich jak podwójne wysłanie e-maila, utworzenie dwóch rekordów czy ponowne obciążenie płatności. W praktyce trzeba rozdzielić „przetwarzanie zdarzenia” od „wykonania skutku” i zapewnić, że każde zdarzenie lub każda operacja ma jednoznaczny identyfikator, po którym rozpoznasz, że została już obsłużona.

Podstawą jest stały klucz idempotencji (idempotency key) wyliczany deterministycznie dla danego zdarzenia/żądania, np. z identyfikatora źródłowego (messageId/eventId/ticketId) lub z kombinacji pól, które jednoznacznie opisują operację. Ten klucz musi być przechowywany w trwałym magazynie (np. w bazie) razem ze statusem przetworzenia i ewentualnie skrótem parametrów, aby po awarii móc stwierdzić: „to już było” albo „to jest retry tej samej operacji”. Samo poleganie na historii wykonania workflow nie wystarcza, bo retry może wystąpić na poziomie triggera (np. webhook/retry po stronie systemu źródłowego) albo na poziomie infrastruktury.

W newralgicznym miejscu, tuż przed wykonaniem akcji z efektem ubocznym, stosuje się wzorzec „sprawdź i zarezerwuj”: najpierw atomowo tworzysz wpis dla klucza idempotencji (lub ustawiasz blokadę), a dopiero potem wykonujesz operację. Jeśli wpis już istnieje w stanie „zakończone”, zwracasz poprzedni rezultat albo bezpiecznie kończysz przebieg bez wykonywania akcji. Jeśli istnieje w stanie „w trakcie”, traktujesz to jako równoległe wykonanie lub wcześniejszy crash i podejmujesz decyzję zgodną z polityką retry (np. odczekanie, przerwanie, albo weryfikacja stanu po stronie systemu docelowego).

Po stronie systemów docelowych należy maksymalnie wykorzystywać natywne mechanizmy idempotencji: nagłówki typu Idempotency-Key w API, operacje typu upsert (aktualizuj albo utwórz), warunki unikalności w bazie (unikalny indeks na kluczu biznesowym) oraz „compare-and-set”/ETag tam, gdzie jest dostępny. Gdy nie masz natywnej idempotencji, musisz ją emulować: przed „create” wykonaj lookup po kluczu biznesowym, a jeśli obiekt już istnieje, przejdź na ścieżkę aktualizacji albo zakończ bez zmian. To jest szczególnie ważne dla akcji, których nie da się bezpiecznie powtórzyć (np. wysyłka powiadomień) — w takich przypadkach zapis „wysłano” z kluczem idempotencji powinien powstać przed wysyłką lub w tej samej transakcji co rezerwacja, aby restart nie powodował ponownego wysłania.

Żeby ograniczyć duplikaty wynikające z równoległości, trzeba kontrolować współbieżność przetwarzania tego samego klucza: albo przez blokadę w magazynie (lock per key), albo przez kolejkę/serializację dla danej grupy zdarzeń. Dodatkowo warto stosować okno deduplikacji (np. TTL na kluczu idempotencji), dobrane do maksymalnego czasu, w którym może nadejść retry/ponowne dostarczenie. Po migracji do nowego środowiska kluczowe jest, aby identyfikatory zdarzeń i reguły budowy klucza idempotencji pozostały spójne z dotychczasowymi, inaczej system może uznać stare retry za „nowe” operacje i wykonać je ponownie.

Jak zorganizować logi, trace i audyt w n8n, żeby były porównywalne do historii uruchomień w Power Automate?

W Power Automate „Run history” łączy w jednym miejscu trzy rzeczy: wynik uruchomienia, szczegóły kroków (wejścia/wyjścia) oraz metadane audytowe (kto, kiedy, co uruchomił/zmienił). W n8n najbliższym odpowiednikiem jest widok Executions dla workflow, ale żeby uzyskać porównywalny poziom kontroli i odtwarzalności, trzeba świadomie rozdzielić: historię wykonań (log wykonania), trace danych (co przeszło między węzłami) oraz audyt zmian (kto i co zmodyfikował).

Historię uruchomień w n8n budujesz na bazie zapisywanych executions w bazie danych n8n. Kluczowe jest ustawienie retencji: ile dni i/lub ile ostatnich wykonań trzymać oraz czy zachowywać dane wykonania tylko dla błędów, czy również dla sukcesów. To odpowiada praktyce z Power Automate, gdzie do analizy incydentów zwykle wystarczają pełne szczegóły dla błędów, a dla sukcesów minimalny zapis (status, czasy, identyfikatory) – dzięki temu nie przechowujesz niepotrzebnie wrażliwych payloadów, a jednocześnie zachowujesz obserwowalność.

Trace (odpowiednik „Inputs/Outputs” per akcja w Run history) w n8n wynika z tego, czy zapisujesz execution data dla węzłów. Jeżeli chcesz mieć możliwość porównywania do Power Automate na poziomie „który krok co dostał i co zwrócił”, musisz dopilnować, by n8n przechowywał dane wykonania przynajmniej dla nieudanych uruchomień oraz dla tych workflow, które są krytyczne SLA. Jednocześnie trzeba zaplanować sanitację danych: n8n potrafi ukrywać sekrety/credentials, ale payloady biznesowe (np. dane osobowe z webhooków) to osobny temat retencji i minimalizacji zapisu.

Audyt w rozumieniu „kto zmienił workflow i kiedy” nie wynika automatycznie z samej historii wykonań. Żeby uzyskać audyt porównywalny z praktykami wokół Power Automate (kontrola zmian, rollback, odpowiedzialność), w n8n standardowo opiera się to o kontrolę dostępu (role/użytkownicy) oraz wersjonowanie definicji workflow w systemie kontroli wersji (np. repozytorium), gdzie źródłem prawdy jest eksport JSON i historia commitów. Wtedy historia wykonań odpowiada za „co się wykonało”, a historia repozytorium za „kto i co zmienił” — i dopiero razem dają pełny obraz audytowy.

Jeżeli potrzebujesz jednego miejsca do przeszukiwania i korelacji zdarzeń jak w Power Automate, praktycznym domknięciem jest centralizacja logów aplikacyjnych n8n (logi serwera/workera) i metryk wykonań do zewnętrznego systemu logowania/monitoringu oraz konsekwentne nadawanie identyfikatorów korelacyjnych. W n8n najczęściej robi się to przez przekazywanie correlationId w danych wejściowych (np. nagłówki webhooka) i logowanie go w kluczowych miejscach workflow, aby móc powiązać wpisy logów z konkretnym execution i konkretną ścieżką przetwarzania.

Jak bezpiecznie przenieść poświadczenia, tokeny i sekrety oraz spełnić wymagania compliance?

Poświadczeń, tokenów i sekretów nie należy „migrować” w sensie kopiowania ich z jednego systemu do drugiego, tylko odtworzyć je w n8n w kontrolowany sposób. Praktycznie oznacza to wygenerowanie nowych tokenów/kluczy w systemach źródłowych (lub ponowne uwierzytelnienie OAuth) i zapisanie ich w n8n jako osobne rekordy Credentials, zamiast przenoszenia istniejących wartości wyeksportowanych z Power Automate. Taki model minimalizuje ryzyko ujawnienia tajemnic oraz pozwala spełnić wymagania dotyczące cyklu życia sekretów (rotacja, unieważnienie, śledzenie zmian).

W zakresie bezpieczeństwa kluczowe jest, aby sekrety nie trafiały do workflow ani do logów. W n8n powinny być przechowywane wyłącznie w mechanizmie poświadczeń, a dane wejściowe/wyjściowe workflow należy tak skonfigurować, by nie utrwalać w logach pól zawierających wartości wrażliwe (np. nagłówków autoryzacyjnych, parametrów zapytań z tokenami, treści zawierających hasła). Jeśli wymagania compliance obejmują ograniczenie dostępu, należy powiązać dostęp do poświadczeń z kontrolą uprawnień w n8n (separacja ról, ograniczenie widoczności credentiali do zespołów/projektów) oraz zapewnić, że dostęp administracyjny jest nadawany tylko osobom, które faktycznie muszą zarządzać sekretami.

Spełnienie compliance zwykle sprowadza się do trzech elementów: kontroli dostępu, rozliczalności i kontroli przechowywania. Kontrola dostępu obejmuje zasadę najmniejszych uprawnień po stronie systemów zewnętrznych (tokeny z minimalnymi zakresami, osobne konta techniczne, ograniczenia IP jeśli możliwe) i po stronie n8n (kto może używać/edytować poświadczenia). Rozliczalność wymaga audytowalności operacji administracyjnych i zmian w konfiguracji (kto i kiedy dodał/zmienił poświadczenie, kto mógł uruchomić workflow korzystający z danego sekretu) oraz spójnego procesu rotacji i wycofywania kluczy. Kontrola przechowywania to szyfrowanie danych „w spoczynku” i „w tranzycie”, separacja środowisk (DEV/TEST/PROD z odrębnymi sekretami) oraz ograniczenie eksportów/backupów tak, by nie wynosiły tajemnic poza kontrolowane repozytoria i kanały.

W praktyce bezpieczny proces wygląda tak: najpierw identyfikujesz wszystkie miejsca, gdzie Power Automate korzysta z połączeń/sekretów (konektory, HTTP z nagłówkami, konta serwisowe), następnie dla każdego systemu docelowo generujesz nowe poświadczenia z minimalnym zakresem i od razu planujesz rotację/wycofanie starych. Potem konfigurujesz odpowiednie Credentials w n8n i podmieniasz je w workflow, wykonując testy tak, aby w żadnym momencie nie logować tajnych wartości. Na końcu unieważniasz stare tokeny, dokumentujesz mapowanie „który workflow używa którego credentiala” i zapewniasz, że polityki retencji logów oraz backupów nie przechowują danych wrażliwych dłużej, niż dopuszcza compliance.

Jak przeprowadzić przełączenie na produkcji (blue/green) i plan rollback bez przestoju?

Blue/green to sposób wdrożenia, w którym utrzymujesz dwa równoległe środowiska produkcyjne: blue (aktualnie obsługujące ruch) oraz green (nowa wersja, np. n8n po migracji). Przełączenie bez przestoju polega na tym, że green jest w pełni przygotowane i zweryfikowane pod ruchem zanim cokolwiek zmienisz w warstwie routingu, a sam „switch” to wyłącznie zmiana kierowania żądań (DNS/LB/ingress/proxy) lub aktywnego endpointu integracji.

Kluczowe warunki braku przestoju to zgodność interfejsów (te same URL-e webhooków lub stabilna warstwa proxy mapująca stare ścieżki na nowe), identyczne sekrety/poświadczenia w obu środowiskach oraz kontrola nad tym, kto w danym momencie „konsumuje” zdarzenia (webhooki, kolejki, harmonogramy). W praktyce przed przełączeniem uruchamiasz green w trybie „gotowy do pracy”: wykonujesz testy end-to-end na kopii zdarzeń lub ruchu testowym, upewniasz się, że przepływy mają identyczne zachowanie oraz że logowanie i metryki pozwolą szybko wykryć regresję po przełączeniu.

Aby uniknąć duplikacji lub utraty zadań w momencie przełączenia, musisz zadbać o deterministyczny „ownership” uruchomień. Dla webhooków najczęściej sprowadza się to do tego, że tylko jedno środowisko jest wskazane jako docelowy endpoint (drugie może działać w gotowości, ale nie przyjmować ruchu), a dla harmonogramów/cronów oraz workerów kolejek – tylko jedno środowisko ma aktywne harmonogramy/consumery (drugie ma je wyłączone lub działa na osobnej kolejce). Jeśli pewnych zdarzeń nie da się łatwo „przekierować” w locie, stosuje się krótkie okno „drain”: utrzymujesz blue jeszcze przez chwilę po przełączeniu, aby dokończyło rozpoczęte zadania, jednocześnie nie przyjmując już nowych.

Plan rollback bez przestoju w modelu blue/green to odwrócenie routingu z powrotem na blue przy zachowaniu tych samych zasad: green przestaje być odbiorcą nowych zdarzeń, a blue znów staje się źródłem prawdy. Żeby rollback był bezpieczny, zaplanuj z góry, jak obsłużysz stan i skutki uboczne: integracje powinny być w miarę możliwości idempotentne (powtórne wywołanie nie generuje podwójnych zapisów), a miejsca, w których stan jest trwały (np. bazy, zewnętrzne systemy), muszą mieć kompatybilny model danych lub jasno określoną strategię „forward-only” (jeśli nie da się cofnąć zmian w danych, rollback dotyczy tylko routingu, a nie stanu).

Operacyjnie przełączenie i rollback powinny być wykonywane jako kontrolowana zmiana: mierzysz błędy, czasy odpowiedzi i wskaźniki przetwarzania po przełączeniu, a kryteria powrotu ustalasz przed startem (np. wzrost odsetka błędów, kolejki rosnące szybciej niż są konsumowane, niezgodność wyników). Dzięki temu rollback jest szybki i nie wymaga „napraw” w trakcie — sprowadza się do przełączenia ruchu oraz przywrócenia aktywnych harmonogramów/consumerów w środowisku blue, przy równoczesnym odcięciu ich w green.

Formularz zgłoszeń w Teams, który nie ginie w czacie: jak ustawić priorytety i porządek 10 maja 2026

SharePoint: plan porządków po latach — 6 metryk bałaganu i harmonogram sprzątania bez przestojów 08 maja 2026