Otwieranie ticketu Sophos przez Support Assistant
Nową sprawę można rozpocząć dwiema standardowymi drogami: bezpośrednio z menu pomocy w Sophos Fusion (dawniej Sophos Central) albo przez Support Assistant w Sophos Support Portal. Uczestniczące tenanty Central mają dodatkowo własny moduł Assistant w ramach Early Access Program. Od 18 lipca 2026 Assistant zastępuje w portalu dla zalogowanych klientów dawny formularz New Technical Support Case.
💡 Ważne: Support Assistant jest przewodnikiem wspomaganym przez AI, a nie Support Engineerem ani otwartym ticketem. Przed zmianą należy merytorycznie zweryfikować jego wskazówki. Sprawa istnieje dopiero wtedy, gdy Sophos wyświetli jej numer lub potwierdzi go e-mailem.
Dobre przygotowanie pozostaje więc ważniejsze niż nowy dialog. W przypadku Sophos Firewall pakiet dowodowy powinien obejmować przede wszystkim numer seryjny, model, wersję firmware, status licencji, czas błędu, dotkniętą funkcję, logi, zrzuty ekranu i wykonane kontrole. Do klasyfikacji różnych dostępów Sophos pasuje także artykuł Portale Sophos: SophosID, Central, support i dostępy do firewalla.
Kiedy ticket Sophos ma sens
Ticket Sophos ma sens, gdy problemu nie da się już wyjaśnić lokalnie wyłącznie przez konfigurację, logi lub znane procesy operacyjne.
Typowe przypadki:
- uszkodzenie sprzętu, RMA lub podejrzenie wadliwej appliance
- problem z licencją lub kontem z konkretnym numerem seryjnym
- problem z firmware, hotfixem lub aktualizacją
- powtarzający się crash usługi lub niejasny stan systemu
- problem VPN, WAF, HA, RED lub routingu po własnym wstępnym zawężeniu
- błąd, który po sprawdzeniu logów i reprodukcji wygląda na problem produktu
- zgłoszenie, w którym Sophos potrzebuje dostępu do wewnętrznych danych analitycznych
Przed ticketem należy wykonać oczywiste kontrole lokalne. W Sophos Firewall nie oznacza to, że wszystko musi być już rozwiązane. Im dokładniej opisane są sytuacja wyjściowa, okno czasowe i dotknięta funkcja, tym mniej pytań zwrotnych.
Co zapewnia Sophos Support, a czego nie
Sophos Support pomaga przy technicznych problemach produktu i może odpowiadać na ogólne pytania konfiguracyjne. Nie zastępuje jednak pełnego wdrożenia, migracji ani projektowania nowej architektury. Ticket jest szczególnie właściwy, gdy funkcja nie działa prawidłowo mimo przejrzystej konfiguracji albo podejrzewany jest konkretny błąd produktu, licencji, sprzętu lub oprogramowania.
Zwykła sprawa product support nie jest główną drogą dla tych zadań:
- planowanie nowej topologii VPN
- uporządkowanie reguł firewalla
- konfiguracja NAT lub WAF dla nowej usługi
- sprawdzenie projektu HA
- ocena koncepcji routingu lub architektury VLAN
- przebudowa istniejącej konfiguracji według best practices
W takich przypadkach lepszym kontaktem jest Avanet Support. Firewall można wtedy sprawdzić, zaplanować lub skonfigurować zgodnie z wymaganiami w ramach warunków supportu Avanet. Sophos Support pozostaje właściwą drogą dla konkretnych błędów produktu i ogólnej pomocy w ramach udokumentowanego zakresu wsparcia.
Prawidłowa klasyfikacja Severity i priorytetu
Plan wsparcia określa uprawnienia i cele reakcji; obowiązują warunki dotyczące danego kontraktu w chwili otwierania sprawy. Dlatego poniższe poziomy celowo nie zawierają stałych czasów. Cel odpowiedzi nie jest też gwarantowanym czasem rozwiązania.
| Severity | Typowy wpływ |
|---|---|
| Critical | Krytyczna usługa produkcyjna jest całkowicie niedostępna i nie ma akceptowalnego obejścia |
| High | Znaczna utrata usługi; praca jest możliwa tylko w ograniczonym zakresie lub przez trasę alternatywną |
| Medium | Brak albo niewielka utrata usługi; działanie nie jest istotnie zablokowane |
| Low | Pytanie operacyjne lub oczekiwana zmiana produktu bądź dokumentacji |
Severity należy dobrać do rzeczywistego aktualnego wpływu, a nie oczekiwanej szybkości obsługi. Dla sprawy krytycznej trzeba podać dotknięte lokalizacje i użytkowników, brak workaroundu, czas rozpoczęcia ze strefą czasową, status redundancji i wykonane kontrole. Gdy wpływ się zmienia, należy uaktualnić tę samą sprawę zamiast otwierać duplikat.
Wymagania
Do technicznego ticketu supportowego zwykle potrzebne są:
- SophosID do Support Portal
- ważna licencja lub aktywne uprawnienie do wsparcia
- dotknięty numer seryjny albo przypisanie konta
- w przypadkach partnerskich: przypisanie klienta i odpowiednia licencja lub numer seryjny
- produkt i model, na przykład XGS Appliance albo firewall wirtualny
- wersja firmware i build
- krótki opis błędu z wpływem
- okno czasowe problemu ze strefą czasową
- dostępne logi, zrzuty ekranu lub komunikaty błędów
Sophos sprawdza w sprawach supportowych przypisanie licencji i numeru seryjnego. Bez pasującej licencji lub numeru seryjnego case może trafić do Customer Care do walidacji. To opóźnia obsługę techniczną. Jeśli partner otwiera case dla klienta, przypisanie klienta i dotknięta licencja lub numer seryjny również muszą być podane jasno. Jeśli Avanet ma zarządzać sprawami supportowymi w imieniu klienta, klient musi przyznać Avanet odpowiedni dostęp partnerski.
Numer seryjny firewalla znajduje się bezpośrednio w dashboardzie SFOS. Procedura jest opisana w Znajdowanie numeru seryjnego Sophos Firewall.
Jeśli zgłoszenie dotyczy uszkodzenia sprzętu, należy dodatkowo sprawdzić artykuł Co zrobić w przypadku technicznej usterki sprzętu Sophos?.
Klasyfikacja kanałów supportu
Sophos oferuje kilka dróg do supportu. Nie każda droga jest tak samo dobra do tego samego celu.
Typowe kanały supportu:
- Menu pomocy w Sophos Fusion: bezpośredni formularz sprawy Central; podczas wysyłania można opcjonalnie udostępnić Remote Assistance.
- Support Assistant w Sophos Support Portal: główny punkt startowy dla zalogowanych klientów, self-service, pytania licencyjne i prowadzone tworzenie sprawy.
- Cases w Support Portal: zarządzanie istniejącymi sprawami, historią, załącznikami, statusem i eskalacją.
- Telefon: otwieranie spraw Critical i High oraz rozwiązywanie pilnych problemów z dostępem do portalu.
- Sophos Community: pytania niepoufne, znane objawy, wymiana z innymi administratorami
- Sophos TechVids i Docs: tematy how-to, konfiguracja i znane procedury
Sophos testuje również Support Assistant w Sophos Fusion w ramach Early Access Program. W tenantach uczestniczących w programie pojawia się on pod ikoną Sparkle na górnym pasku Central. Ten asystent EAP nie jest zsynchronizowany z asystentem w support.sophos.com, dlatego wcześniejsze rozmowy z portalu nie pojawiają się na jego liście czatów.
Asystent Central przeszukuje dokumentację Sophos i artykuły KB, może wyświetlić istniejące sprawy za pomocą Show me my support cases oraz rozpocząć tworzenie nowej sprawy poleceniem Create a new support case. Wyraźna prośba o kontakt z człowiekiem z zespołu Support powoduje eskalację rozmowy i utworzenie ticketu do dalszego śledzenia. Do wcześniejszych rozmów w Central można wrócić również po wylogowaniu lub przekroczeniu limitu nieaktywności. Dla udokumentowanego zgłoszenia nadal liczy się jednak potwierdzony numer sprawy, a nie samo rozpoczęcie czatu z AI.
Jeżeli zwykły problem techniczny jest zgłaszany w Support Portal, proces zaczyna się w Support Assistant. Sprawy Critical i High należy natomiast inicjować telefonicznie, a nie przez stronę internetową lub e-mail. W sprawie Critical zalogowany użytkownik dodatkowo najpierw tworzy sprawę internetową, zapisuje jej numer, a następnie dzwoni; osoba bez konta Support Portal korzysta bezpośrednio z drogi telefonicznej For Critical Cases. Ta kolejność — sprawa internetowa, numer, a następnie telefon — nie dotyczy spraw High. Nie należy polegać wyłącznie na rozmowie z Assistant. Należy podać produkt, numer seryjny, wpływ, dostępność obejścia oraz numer sprawy, jeśli został już nadany.
Numery telefonów mogą się zmieniać. W obszarze wsparcia należy wybrać region i kraj, sprawdzić informacje o opłatach i przygotować numer istniejącej sprawy. Jeśli logowanie do portalu nie działa, należy użyć oferowanej tam drogi telefonicznej For Critical Cases i zgłosić także problem z dostępem.
Prawidłowe kierowanie zgłoszeń Managed Risk
Pytania dotyczące usługi Managed Risk oraz zmiany ustawień skanowania nie powinny trafiać do zwykłego zgłoszenia pomocy technicznej dotyczącego produktu. W Sophos Fusion należy użyć ścieżki Threat Analysis Center > Cases > Create case > Managed Risk service request. Pełny proces opisuje artykuł Tworzenie i obsługa spraw Managed Risk.
Jeśli natomiast produkt lub urządzenie Managed Risk nie działa prawidłowo, właściwym odbiorcą jest Product Support. Przed eskalacją warto skorzystać z artykułu Rozwiązywanie problemów z Managed Risk, aby przeprowadzić bezpieczne kontrole i przygotować odpowiedni pakiet diagnostyczny. Należy podać treść błędu, czas wraz ze strefą czasową, widoczny stan, skan lub urządzenie, którego dotyczy problem, oraz wyniki wykonanych kontroli, ale nigdy nie przesyłać haseł, tokenów, kluczy prywatnych ani innych sekretów.
Przygotowanie konta i dostępu partnera
Do Support Portal wymagany jest SophosID. Konto powinno pasować do firmy, licencji lub tenanta Sophos Fusion, aby dotknięte produkty były widoczne. Jeśli firewall jest obsługiwany przez partnera, przed właściwą sprawą supportową należy wyjaśnić, czy partner może zarządzać cases.
Jeśli Avanet ma towarzyszyć case w imieniu klienta albo komunikować się z Sophos, dostęp do przypisania klienta w Sophos Support Portal musi być dozwolony.
Praktycznie oznacza to:
- Sprawdzić SophosID oraz przygotować licencję lub numer seryjny.
- Jeśli Avanet ma pomagać, w My Partners wybrać Grant data access, sprawdzić warunki i kliknąć Confirm.
- Partner zobaczy wszystkie zasoby konta. Dostęp należy przyznać tylko właściwemu partnerowi i sprawdzić ponownie po sprawie.
- Gdy brakuje My Partners, Customer Care może najpierw zmienić profil na Super Customer. Klient z miesięczną licencją przez MSP nie może nadać tego dostępu; MSP otwiera sprawę we własnym imieniu.
- Support Access przygotować dopiero wtedy, gdy Sophos potrzebuje go do tej sprawy.
Przygotowanie przed ticketem
Support Case powinien być sformułowany tak, aby support mógł zaklasyfikować problem bez zgadywania.
Dane techniczne
Dla Sophos Firewall powinny być gotowe:
- numer seryjny
- model lub platforma
- wersja firmware i build
- status licencji lub plan supportu, jeśli istotny
- status HA, jeśli firewall jest częścią klastra
- dotknięta funkcja, na przykład IPsec, SSL VPN, WAF, RED, Web Protection lub Reporting
- dokładna godzina błędu ze strefą czasową
- dotknięci użytkownicy, sieci, lokalizacje lub usługi
- ostatnie zmiany przed problemem
W klastrach HA oba węzły powinny być jednoznacznie udokumentowane. Do klasyfikacji ról, numerów seryjnych i pracy HA pasuje Warianty i eksploatacja klastra HA Sophos Firewall.
Reprodukcja i wpływ
Opis nie powinien mówić tylko, że coś nie działa. Lepszy jest krótki, możliwy do sprawdzenia opis:
- Czego oczekiwano?
- Co dzieje się zamiast tego?
- Od kiedy problem występuje?
- Czy problem jest stały czy sporadyczny?
- Jak można go odtworzyć?
- Którzy użytkownicy lub usługi są dotknięte?
- Czy istnieje workaround?
- Jak krytyczny jest wpływ na działanie?
Jeśli ticket składa się tylko ze zrzutu ekranu i jednego zdania, support niemal na pewno będzie musiał dopytywać. To kosztuje czas, szczególnie przy problemach VPN, routingu lub HA.
Logi i załączniki
W problemach firewallowych logi są często ważniejsze niż długie przypuszczenia. Jeśli problem da się odtworzyć, należy możliwie dokładnie zapisać okno błędu, a następnie zabezpieczyć odpowiednie logi.
W zależności od problemu pomocne są:
- zrzut ekranu komunikatu błędu
- zrzut Log Viewer z filtrem
- właściwe logi usług
- Packet Capture lub
tcpdump, jeśli przepływ pakietów jest niejasny - zrzut firmware lub licencji
- krótki schemat sieci albo dotknięte adresy IP, jeśli dotyczy routingu
- opis już sprawdzonych reguł, obiektów NAT lub parametrów VPN
Dla pełnych archiwów logów właściwą procedurą jest Zabezpieczanie logów Sophos Firewall do supportu i analizy. Który plik logu należy do którego modułu, podsumowuje Prawidłowe przypisanie logów usług Sophos Firewall.
Nie każdy załącznik odpowiada na to samo pytanie:
- Która reguła lub moduł podjął decyzję?: eksport Log Viewer, Rule ID, NAT ID, dotknięty okres
- Która usługa zgłasza błędy?: odpowiednie logi usług lub pełne archiwum
/log - Czy ruch dociera i przechodzi dalej?: Packet Capture w WebAdmin
- Czy support potrzebuje pliku PCAP?: wąski zrzut tcpdump, oddzielnie od archiwum logów
- Czy zmiana wywołała problem?: audit trail, czas zmiany, dotknięte obiekty
Szerokie archiwum logów bez czasu błędu jest często mniej pomocne niż mniejszy pakiet danych z dokładną godziną, jasną reprodukcją i odpowiednim zrzutem. Przy problemach przepływu pakietów plik PCAP powinien być traktowany oddzielnie od archiwum logów, aby w tickecie było jasne, który plik zawiera logi usług, a który pakiety sieciowe.
⚠️ Logi, zrzuty ekranu i Packet Captures mogą zawierać wewnętrzne adresy IP, publiczne IP, nazwy użytkowników, nazwy hostów, szczegóły certyfikatów lub inne informacje poufne. Przed przesłaniem musi być jasne, kto otrzyma dane i czy trzeba je wcześniej oczyścić.
Materiał dowodowy przy nieudanej integracji ITDR
Po wyczerpaniu udokumentowanych kroków odtworzeniowych dodaj do istniejącej sprawy supportowej wyłącznie materiały właściwe dla ITDR. Najpierw porównaj obserwację z instrukcją integracji Microsoft Entra ID lub sensora ITDR dla lokalnego Active Directory; statusy i integracje podrzędne sprawdź w ustawieniach ITDR Identity.
- produkt Sophos ITDR, typ i nazwa integracji, dotknięty tenant Sophos oraz tenant Entra lub domeny AD
- dokładny tekst błędu; w wierszach Entra widoczny Health Status i objęte problemem Child Integrations; w integracji lokalnego AD widoczne wartości Health i Status; oraz czas kontroli ze strefą czasową
- zachowanie oczekiwane i rzeczywiste, początek i wpływ biznesowy oraz czas ostatniej udanej synchronizacji
- ostatnie zmiany consentu, licencji, sensora, domeny, filtrów lub sieci oraz wykonane kroki odtworzeniowe wraz z wynikami
- dla Entra: aktywna licencja, sprawdzone dane źródłowe Microsoft i uwzględniony interwał pobierania; dla lokalnego AD: wersje Windows i .NET, przebieg synchronizacji oraz oddzielne wyniki testów DNS i HTTPS
- oczyszczone zrzuty ekranu i tylko załączniki wyraźnie wskazane przez support
Ustaw Severity zgodnie z rzeczywistym wpływem. Hasła, Client Secrets, tokeny, cookies i inne dane logowania nie mogą znaleźć się w opisie, zrzutach ani załącznikach; nie dołączaj też plików z domniemanych ścieżek logów.
NDR Appliance i Investigation Console
W przypadku NDR najpierw ustal, którego komponentu dotyczy problem: integracji NDR lub Integration Appliance czy odrębnej Investigation Console. Dla Integration Appliance centralna ścieżka prowadzi przez Threat Analysis Center > Integrations > Configured > Integration Appliances. Zapisz tam nazwę appliance, typ, widoczny status, czas ze strefą czasową oraz dotknięte obciążenie NDR lub Log Collector; System ID i wersja są dostępne w Appliance Manager. Opcja Collect logs w menu z trzema kropkami zleca zebranie logów appliance; bez dostępu do VM przekaż następnie Sophos Support nazwę pliku widoczną pod Log requested. Mając uprawniony dostęp do VM, pakiet można pobrać przez Open Appliance Manager > Actions > Download Log File.
Dla Investigation Console wybierz Collect Logs przy odpowiednim wpisie na stronie Investigation Console. Jeśli konsola jest dostępna lokalnie, System Details pokazuje nazwę, Uptime oraz wartości CPU, pamięci i dysków; w Actions > Download Log File dostępny jest pakiet logów ZIP. Health Logs zawiera dodatkowo filtrowalne komunikaty o połączeniu konsoli z przypisanymi Integration Appliances. Dla każdej ścieżki zapisz przedział występowania błędu i strefę czasową, zamiast przesyłać nieopisane pełne archiwa.
Hasła, klucze prywatne, tokeny i session cookies nie mogą znaleźć się w tickecie. Przed przesłaniem sprawdź wygenerowany pakiet logów pod kątem danych poufnych zgodnie z własnymi zasadami. Usuwaj takie treści tylko wtedy, gdy jest to dozwolone i nie zafałszuje diagnostyki.
Żądany przez Sophos, specyficzny dla komponentu Remote Assistant włącz dopiero po uzyskaniu numeru Case i określeniu jasnego celu. Dla Investigation Console dostęp może pozostawać aktywny najwyżej 24 godziny, a dla Integration Appliance najwyżej siedem dni. Przez uzgodniony kanał supportu przekaż Sophos wyłącznie wygenerowany Access ID, nigdy hasło zadmin. Wyłącz dostęp po zakończeniu sesji, nawet jeśli wybrany okres jeszcze nie upłynął.
Consolidated Troubleshooting Report w SFOS 22
Sophos może poprosić o Consolidated Troubleshooting Report (CTR). W SFOS 22 należy otworzyć Diagnostics > Tools > Consolidated troubleshooting report, zaznaczyć System snapshot i All log files, podać konkretny powód i kliknąć Generate. Po zakończeniu wybrać Download i dodać zaszyfrowane archiwum do istniejącej sprawy.
Taki raport jest szczególnie pomocny przy:
- crashach usług
- niejasnych stanach systemu
- powtarzających się błędach po aktualizacjach
- problemach, których Sophos nie może ocenić tylko na podstawie zrzutu ekranu
- sprawach supportowych, w których może być dotkniętych kilka modułów
Raport nie zastępuje opisu błędu. Nadal potrzebne są czas, strefa, funkcja i reprodukcja. W klastrze HA logi i raporty nie są synchronizowane między Primary i Auxiliary Device; gdy oba węzły mogą mieć znaczenie, CTR zbiera się osobno z każdego.
Support Access i Access ID
Sophos może poprosić o Support Access i wygenerowany Access ID. W SFOS 22 funkcja jest w Diagnostics > Support access. Firewall łączy się z *.apu.sophos.com przez TCP 22, więc router nadrzędny musi zezwalać na to połączenie wychodzące. Access ID daje Sophos dostęp do WebAdmin i shell bez przekazywania danych administratora.
Support Access należy aktywować wyłącznie dla konkretnej sprawy i na wymagany czas: włączyć Support access i potwierdzić przyciskiem OK, wybrać czas trwania, kliknąć Apply i ponownie potwierdzić przyciskiem OK. W sekcji Access status skopiować wyświetlony Access ID i przekazać go w bezpieczny sposób wyłącznie do Sophos Support. Dostęp można wyłączyć w dowolnym momencie i należy go dezaktywować po zakończeniu analizy. Pełną procedurę w GUI opisuje Support access w przewodniku SSH. Odrębną drogą jest osobno autoryzowany bezpośredni dostęp administratora dla Avanet; Sophos Access ID nie jest przeznaczony do tego dostępu i nie jest przekazywany Avanet.
W tickecie należy podać:
- czy Support Access jest już aktywny
- Access ID, jeśli istnieje
- na jak długo dostęp został włączony
- czy MFA lub reguły ACL wpływają na dostęp
- czy istnieje okno serwisowe na testy
W sprawie dotyczącej Central zamiast tego używa się funkcji Remote Assistance dla tenanta. Ścieżka to Profil > Support settings. Dostęp jest domyślnie wyłączony i można go udostępnić na 3, 7, 14, 30 lub 60 dni. Jeśli Remote Assistance zostanie włączone bezpośrednio podczas tworzenia sprawy supportowej Central, Sophos automatycznie wyłączy tę funkcję po 120 godzinach.
Dostęp zostaje przyznany dopiero wtedy, gdy znane są numer sprawy, cel, odpowiedzialny administrator i czas trwania. Po analizie wyłącza się go wcześniej w Support settings, a aktywność sprawdza w Audit Log. Remote Assistance dla tenanta Central nie jest tym samym co Remote Assistance ID firewalla, switcha ani urządzenia NDR.
Partner Assistance i Enterprise Admin Access to kolejne, odmiennie działające drogi dostępu. Różnice opisano w artykule Zabezpieczanie Sophos Fusion Partner Assistance i Remote Assistance.
Otwieranie sprawy bezpośrednio w Sophos Fusion
Ta droga jest przydatna, gdy administrator pracuje już w tenantcie Central, którego dotyczy problem. Należy ją odróżnić od zależnego od tenantu programu EAP Support Assistant oraz od Assistant w Support Portal.
- Otworzyć ikonę Help w prawym górnym rogu.
- W menu Sophos Help wybrać strzałkę obok Support center.
- Kliknąć Create a support case.
- Wypełnić formularz możliwie precyzyjnie. Opcjonalnie można zezwolić Sophos na bezpośredni dostęp do bieżącej sesji Central.
- Kliknąć Send, zapisać wyświetlony numer sprawy i potwierdzić przyciskiem OK.
Jeżeli przed wysłaniem wybrano opcję dostępu, kliknięcie Send aktywuje Remote Assistance. Sophos wyłączy ją automatycznie po 120 godzinach. Aby zakończyć dostęp wcześniej, należy otworzyć nazwę konta w prawym górnym rogu, a następnie Support Settings.
💡 Poprawne wysłanie i numer sprawy potwierdzają jej utworzenie, a nie stały termin odpowiedzi lub rozwiązania. Priorytet i następny kanał kontaktu zależą od kontraktu i rzeczywistego wpływu. Sprawy Critical i High należy inicjować telefonicznie; w sprawie Critical zalogowany użytkownik dodatkowo tworzy sprawę internetową, zapisuje numer, a następnie dzwoni.
Otwieranie ticketu przez Sophos Support Assistant
Sophos Support Portal jest dostępny tutaj:
➜ Otwórz Sophos Support Portal
Sophos uruchomił czat Assistant 3 czerwca 2026 r.; jest on dostępny 24x7. Głębsza integracja z portalem od połowy lipca uczyniła go głównym punktem wejścia dla zalogowanych klientów. Po zalogowaniu przez SophosID Support Assistant jest dostępny w dużym polu na stronie głównej i pod czarnym przyciskiem Assistant w prawym dolnym rogu. Menu Cases pozostaje dostępne dla istniejących spraw, ale nie jest już normalnym punktem startowym dla nowej.

Rozpoczęcie sprawy w Support Assistant
- Zalogować się do Support Portal.
- Otworzyć duże pole wprowadzania lub przycisk Assistant.
- Jasno podać produkt, problem i cel. Przy błędzie produktu rozmowę można rozpocząć na przykład od:
I need to open a technical support case for Sophos Firewall. - Dodać objawy, wpływ i kontrole.
IPsec VPN fails after upgrade to SFOS 22.0 on XGS 2100jest lepsze niżVPN problem; model i wersję należy zastąpić własnymi. - Przed działaniem merytorycznie zweryfikować sugerowaną dokumentację i kroki troubleshooting. Nie należy wykonywać niepasujących lub ryzykownych zmian wyłącznie dlatego, że zasugerowała je odpowiedź AI.
- Jeśli problem pozostaje nierozwiązany, wyraźnie zaznaczyć, że potrzebny jest ludzki Support Engineer i Technical Support Case.
- Odpowiedzieć na pytania diagnostyczne i sprawdzić konto, kontakt, produkt, licencję lub numer seryjny, wpływ i opis, gdy pola się pojawią.
- Sprawdzić i wysłać podsumowanie. Wyświetlony później numer sprawy jest kryterium sukcesu.
- Następnie dodać logi, CTR lub PCAP przez Cases > numer sprawy > Upload a File.
Dialog jest dynamiczny: Sophos może najpierw pokazać instrukcję, sprawdzić licencję lub zadać pytania. Należy kontynuować do numeru sprawy. Nie można już wybrać preferowanego zespołu; po wykryciu obsługiwanego języka Assistant może zaproponować przekazanie do zespołu regionalnego.

Jak rozpoznać prawidłowe zakończenie
Pomocna odpowiedź AI lub wyświetlony artykuł KB nie są jeszcze Support Case. Proces jest zakończony dopiero wtedy, gdy numer sprawy zostanie pokazany lub potwierdzony e-mailem. Następnie sprawę można otworzyć pod Cases, uzupełniać i śledzić. Obszary bez AI, takie jak Cases, Accounts, Followed Cases i zwykłe wyszukiwanie wiedzy, pozostają dostępne.
Sprawy Critical i High wymagają kontaktu telefonicznego. W sprawie Critical zalogowany użytkownik dodatkowo tworzy sprawę, zapisuje jej numer, a następnie dzwoni. Assistant nie zastępuje pilnego kontaktu z człowiekiem.
Bezpieczne rozwiązywanie typowych problemów z portalem
- Pętla logowania, pusta strona lub brak Assistant: sprawdzić właściwy SophosID i kontekst tenant/konto, zezwolić na wymagane pliki cookie i skrypty, a następnie ponownie otworzyć proces w aktualnej przeglądarce lub oknie prywatnym. Przy możliwej awarii zapisać lokalnie szkic bez sekretów; sprawy Critical lub High kontynuować telefonicznie.
- Brak produktu, Cases lub tworzenia sprawy: sprawdzić przypisanie konta i assetów, uprawnienie licencyjne/supportowe oraz, dla partnera, przypisanie klienta. Nie wybierać numeru seryjnego innego klienta; brakujące przypisanie poprawić w procesie konta lub Customer Care.
- Assistant zwraca tylko artykuły: doprecyzować problem i wpływ biznesowy oraz wyraźnie poprosić o Technical Support Case z pomocą człowieka. Bez numeru sprawy ticket jeszcze nie istnieje.
- Brak kodu uploadu, CAPTCHA lub komunikatu SendSafely: podczas pierwszej weryfikacji sprawdzić adres e-mail powiązany z zalogowanym kontem Support Portal i ukończyć CAPTCHA. Dopiero gdy komunikat Thank you potwierdzi powodzenie, zapisać wyświetloną Submission ID i odświeżyć stronę sprawy. Odświeżony komunikat SendSafely jest widoczny tylko wtedy, gdy zalogowany e-mail odpowiada polu Case Contact. Nie wysyłać plików bez szyfrowania jako obejścia; po błędzie zapisać w istniejącej sprawie czas i oczyszczony zrzut ekranu.
- Brak potwierdzenia po wysłaniu: najpierw przeszukać Cases i e-mail, także spam, pod kątem numeru sprawy. Nie wysyłać ponownie w ciemno. Jeśli sprawy nadal nie ma, skontaktować się ze wsparciem, podając czas, konto i oczyszczony zrzut; przy pilnym wpływie eskalować telefonicznie.
Co powinno znaleźć się w opisie
Dobry opis jest wystarczająco krótki do przeczytania i wystarczająco konkretny do pracy.
Praktyczny szablon:
Product:
Serial number:
License number:
Model:
Firmware version:
Support plan:
Impact:
Start time and time zone:
Affected users/sites/services:
Recent changes:
Expected behavior:
Actual behavior:
Steps to reproduce:
Checks already performed:
Support access ID:
Attachments:
Wypełniony przykład do dostosowania:
Product: Sophos Firewall
Serial number: [own serial number]
Model: XGS 2100 [replace]
Firmware version: SFOS 22.0 [replace with exact version and build]
Impact: Site-to-site VPN to production is down; 80 users cannot access ERP; no workaround
Start time and time zone: 2026-09-05 08:40 CEST [replace]
Recent changes: Firmware upgrade completed at 07:55 CEST
Expected behavior: IPsec tunnel establishes and production subnet is reachable
Actual behavior: Tunnel remains down; peer is reachable; authentication fails
Steps to reproduce: Disable and re-enable the affected connection once
Checks already performed: Peer reachability, matching proposals, Log Viewer at 08:43 CEST
Support access ID: Not enabled; can be enabled for an agreed window
Attachments: Filtered Log Viewer export and topology diagram; CTR available on request
Wartości w nawiasach trzeba zastąpić. Użytkownicy, ERP i objaw są przykładami; Severity ma odpowiadać realnemu wpływowi. Nigdy nie podawać haseł, Pre-Shared Keys, kluczy prywatnych ani cookies sesji.
Przesyłanie plików po utworzeniu sprawy
Zalogować się do Support Portal, otworzyć Cases, wybrać numer i Upload a File. Przy pierwszym przesłaniu SendSafely może zweryfikować kodem i CAPTCHA adres e-mail powiązany z tym kontem Support Portal. Wiele plików, pliki bez dozwolonego rozszerzenia, ponad 100 GB lub wykonywalne należy najpierw spakować do ZIP. Na wspólnym urządzeniu nie zaznaczać remember me for 30 days.
Dopiero komunikat Thank you potwierdza przesłanie. Zapisać Submission ID i odświeżyć stronę; komunikat SendSafely widać tylko, gdy e-mail zgadza się z Case Contact. Aby później wyświetlić lub pobrać przesłany plik, zalogowany użytkownik musi być jednocześnie osobą, która go przesłała, oraz Case Contact.
Przy problemach z regułami firewalla, NAT lub VPN należy dodatkowo podać:
- sieci source i destination
- dotkniętą usługę lub port
- oczekiwaną regułę firewalla
- regułę NAT, jeśli dotyczy
- tunel VPN lub profil Remote Access
- wynik Log Viewer
- Packet Capture lub tcpdump PCAP, jeśli przepływ pakietów jest istotny
- Support Access ID, jeśli Sophos potrzebuje dostępu zdalnego
Przy analizie reguł Test reguły firewalla z Log Viewer, Policy Test i Packet Capture może pomóc przed otwarciem Support Case.
RMA i uszkodzenie sprzętu
Przy uszkodzeniach sprzętu Sophos potrzebuje dodatkowych informacji do obsługi RMA. Obejmuje to nie tylko opis błędu i numer seryjny, lecz także model, rewizję, firmware, licencję, status HA i dane wysyłkowe.
Należy przygotować:
- uszkodzony produkt i model
- numer seryjny dotkniętego urządzenia
- wersję firmware
- numer licencji lub przypisanie licencji
- opis objawów i już sprawdzone punkty
Dead on arrival, jeśli urządzenie było dotknięte bezpośrednio po dostawie- klaster HA: tak lub nie
- adres dostawy i osobę kontaktową
- numer telefonu i adres e-mail
- szczególne wskazówki wysyłkowe
Przy firewallach należy dodatkowo sprawdzić, czy istnieje aktualny backup i jak zostanie odtworzony firewall zastępczy. Dla backupu i restore pasuje Backup i restore na Sophos Firewall.
W przypadkach RMA należy przekazać wymagane dane przez aktualny Sophos Support Portal i postępować zgodnie z instrukcjami w tickecie. W konkretnej sprawie trzeba uzupełnić wszelkie dodatkowo wymagane informacje o urządzeniu, licencji lub wysyłce.
Dopytywanie i eskalacja
Po otwarciu powinno przyjść e-mailem potwierdzenie z numerem sprawy. Numer należy podawać w każdej późniejszej komunikacji. Pod Cases można otworzyć sprawę, dodać informacje i śledzić jej stan.
Jeśli krytyczna sprawa nie postępuje wystarczająco szybko, nie należy otwierać drugiego ticketu. Duplikaty powodują więcej koordynacji i mogą raczej spowolnić obsługę.
Lepiej:
- mieć gotowy istniejący numer ticketu
- konkretnie opisać impact i pilność
- dosłać brakujące logi lub odpowiedzi
- przy sprawach krytycznych dopytać telefonicznie z numerem sprawy
- wybrać Request Escalation, region, powód i wpływ, a następnie kliknąć Escalate
- wewnętrznie udokumentować, kto przekazał jaką odpowiedź
Eskalacja powinna być uzasadniona. Sensowne powody to na przykład:
- przekroczono docelowy czas odpowiedzi.
- awaria produkcyjna trwa nadal.
- brak reakcji mimo dosłanych informacji.
- błędne przypisanie lub niepasująca kategoria produktu.
- case blokuje planowany proces odtworzenia lub konserwacji.
Eskalacja powinna zawsze opisywać aktualny wpływ na działalność. Zdanie We need an update jest mniej konkretne niż stwierdzenie The main site-to-site VPN between headquarters and production is still down, 80 users cannot access ERP, no workaround is available. Alternatywnie Sophos przyjmuje wiadomość e-mail na supportescalations@sophos.com z numerem sprawy, wyraźną prośbą o eskalację, jej powodem i wpływem na działalność. W sprawach pilnych Sophos zaleca również kontakt telefoniczny.
Przy poważnych przypadkach bezpieczeństwa lub awarii należy dodatkowo sprawdzić, czy mają zastosowanie inne procesy supportu lub incident response. Zwykły ticket techniczny nie jest automatycznie pełnym procesem incident response.
Checklista
- SophosID działa.
- Licencja i uprawnienie do supportu są wyjaśnione.
- Numer seryjny, model i wersja firmware są udokumentowane.
- Znany jest czas błędu ze strefą czasową.
- Opisano wpływ na użytkowników, usługi lub lokalizację.
- Ostatnie zmiany zostały zanotowane.
- Reprodukcja lub objaw są zrozumiałe.
- Odpowiednie logi i zrzuty ekranu są przygotowane.
- Packet Capture lub tcpdump PCAP jest przygotowany tylko dla problemów przepływu pakietów.
- Dane poufne w załącznikach zostały sprawdzone.
- Przy RMA: dane wysyłkowe i status HA są przygotowane.
- Tworzenie sprawy wybraną drogą zostało doprowadzone do potwierdzonego numeru.
- Numer ticketu jest dokumentowany wewnętrznie.