Service Desk
Co to jest Service Desk
W Blue Media / Autopay budujemy kulturę pracy z użyciem standardu Service Desk.
Według definicji, Service Desk to pojedyncza osoba lub zespół, który odpowiada za świadczenie wsparcia technicznego i rozwiązywanie problemów związanych z technologią i informatyką w organizacji. Service Desk jest punktem kontaktowym między użytkownikami a zespołem IT, który pomaga w rozwiązywaniu problemów technicznych i zapewnia wsparcie techniczne na różnych poziomach.
Zadaniem Service Desku jest zbieranie zgłoszeń od użytkowników, ocena ich priorytetu, rozwiązywanie łatwych problemów na miejscu, a także przekierowywanie bardziej złożonych zapytań do specjalistów IT, którzy zajmą się bardziej zaawansowanymi problemami.
Wiele Service Desków wykorzystuje narzędzia do zarządzania incydentami i zgłoszeniami, co pozwala na śledzenie postępów w rozwiązywaniu problemów oraz raportowanie o wykorzystaniu zasobów i poziomie satysfakcji użytkowników.
Lokalizacja Service Desk BM
Rodzaje usług dostępnych w Service Desk BM
Service Desk
W miejscu tym możesz zlecić problem, zadanie, w następujących tematach:
Rodzaj zgłoszenia | Opis |
|---|---|
Communication | Zadania dotyczące systemów SMS i Mailer |
Payment Gateway | Zgłaszane problemy przez Partnerów związane z:
|
Problem with transaction (to AM) | Rozwiązywanie problemów z pojedynczymi transakcjami. |
Jira support | Tworzenie i modyfikacja projektów na Jira (w tym Service Desk), rozwiązywanie problemów technicznych z tym narzędziem. |
Access | Dostępy do paneli, źródeł danych. Nie dotyczy infrastruktury i dostępów do hostów |
Reporting (Internal Integrations) |
Zadania dotyczące analizy i naprawy błędów w procesach raportujących i rozliczeniowych: MBS, KNF/KIP, ACCOUNTANT/AGREST/FAKTURA, SCRIBE |
Verifications | Zadania dotyczące weryfikacji AIS/1PLN/Photo, m.in.:
|
Statuspage | Wysyłka powiadomienia o planowanych pracach serwisowych, dodanie do listy odbiorców, aktualizacja aktualnej listy odbiorców. |
Create Environment | Zlecenia w zakresie wdrożeń i konfiguracji. Parametryzacja w utrzymaniu np. zadania dotyczące zmian stawek, potrzeby wsparcia w spotkaniach. |
E-commerce Plugins | Zadania dotyczące problemów konfiguracyjnych / komunikacyjnych z wtyczką na linii sklep <-> BM (czyli np. "nie dochodzi mi ITN") |
Frontend | Problemy z częścią frontową serwisów:
|
Mass Bank Statements | Problemy z przesłaniem statusów transakcji. Zadania mają automatycznie podlinkowane instrukcje przygotowane przez DEV |
FMA Service Configuration for BM Integrator | ??? |
Zasady zakładania zadań
Wszystkie sprawy, wymagające angażowania zespołów wsparcia i zespołów wytwórczych muszą zostać zainicjowane zadaniem na SDZadania muszą mieć wypełnione pole Sponsor: Sponsor - jak wybrać dla zadania
Zasady realizacji
Zadania przechodzą następującą ścieżkę:
Statusy oczekiwania na realizację w danej linii:
I linia: ISS
II linia: waiting for second line
III linia: waiting for developer
Ogólna reguła SD w naszej organizacji mówi, że nie ma możliwości przypisania zadania bezpośrednio z I linii, od razu na III linię. Od tej reguły są jednak wyjątki i dotyczą sytuacji gdzie kompetencje linii wyższych nie są i nie mają być rozwijane dla danej grupy problemów. Dokładna ścieżka, jaką zgłoszenie będzie procedowane można znaleźć w opisie kategorii zadania:
IT Support
Kategorie problemów (w IT Support niniejsze kategorie mogą prowadzić do szczegółowych podkategorii zadań):
Rodzaj zgłoszenia | Opis |
|---|---|
Access Management | Przyznawanie, weryfikacja, odbieranie dostępów do infrastruktury |
DevOps | Zarządzanie środowiskiem serwerów aplikacyjnych, rozwiązaniami chmurowymi, narzędziami komunikacji między systemami IT. |
Networking | Udrażnianie połączeń między systemami IT, analiza problemów sieciowych systemów i pracowników (VPN), tworzenie tuneli sieciowych do usług kontrahentów. |
Help Desk | Wsparcie techniczne:
|
Database Administration | Tworzenie i administracja bazami danych, tworzenie backupów, replik, aktualizacje wersji, zarządzanie dostępami. |
Security | Wsparcie z dziedziny bezpieczeństwa aplikacji i procesów. Konsultacje dla kontrahentów, audyty wewnętrzne itp. |
Produkt
Rodzaj zgłoszenia | Opis |
|---|---|
Zgłoś inicjatywę | Miejsce służące zaproponowaniu stworzenia nowego produktu lub zmiany istniejącego. Sposób obsługi tej kategorii opisany jest przez Framework Współpracy: Framework Współpracy w Organizacji |
Pytanie o produkt/informacje | Tutaj uzyskasz wszelkie informacje o produktach, ich charakterystyce, sposobie działania itp. |
Potrzebne wsparcie produktowe | W tym miejscu zgłaszasz potrzebę wsparcia Product Ownerów, Product Managerów (tych znajdujących się w Delivery) lub osób technicznych do takich celów jak na przykład warsztaty z kontrahentem. |
Incidents
Incydent IT - definicja
1. Gdzie i kiedy zgłosić incydent
Jakie awarie zgłaszamy:
Wszystkie awarie produkcyjne, bardzo poważne awarie środowiska akceptacyjnego np. nie działa cała baza paybm-accept (nie działają wszystkie usługi płatnicze)
W przypadku powtarzających się problemów wewnętrznych, które nie mają wpływu na działanie usług - komunikujemy się na kanałach zespołowych, jeśli taki nie istnieje lub nie otrzymujemy odpowiedniej reakcji wykorzystujemy kanał Delivery->Tech-Park. Przykładem takiego problemu może być narastająca ilość zajętego miejsca na maszynach i potrzeba czyszczenia co kilka godzin. Jeśli taki problem przyjmuje bardzo dużą skalę (bardzo duży przyrost logów, zagrożenie, że na maszynie skończy się miejsce, potrzeba czyszczenia np. co 30 min, zagrożenie, że taka ilość logów może być spowodowana poważnym błędem) zgłaszamy sytuację jako incydent przez formularz https://incident.bm.pl z severity przynajmniej 3 (spowoduje to wysłanie wiadomości na kanał awaria).
Gdzie zgłaszamy: Incydent zakładamy przez formularz https://bluemedia.atlassian.net/servicedesk/customer/portal/31 , dostępny także pod
incident.bm.pl W celu zgłoszenia incydentu IT wybieramy opcję Report an IT Incident
2. Formularz zakładania incydentu IT
Zostaniemy skierowani na prosty formularz zgłoszenia incydentu z polami:
Summary - będzie widoczne w tytule incydentu, krótko opisujemy z czym jest problem/co nie działa. Np. Problemy z bazą paybm czy Niedziałające płatności kartowe
Description - nieco bardziej szczegółowy opis tego co zaobserwowaliśmy. Np. Od godzny 12:15 nie obserwujemy pozytywnych transakcji kartowych, na stronach partnerów nie jest dostępna opcja płatności kartą czy load na bazie paybm skoczył do 150 na x cpu, wszystkie usługi, które korzystają z bazy mogą mieć opóźnienia/problemy z realizacją
Severity - impakt jaki wg naszej wiedzy ma awaria, opisane bezpośrednio na formularzu
Impacted Systems - checklista systemów, które wg naszej wiedzy są objęte awarią
Po wybraniu severity pokaże nam się dodatkowe pole z pytaniem o chęć uzupełnienia dalszej części formularza. Domyślnie zaznaczona jest opcja no.
Jeśli posiadamy więcej informacji dotyczących awarii możemy wybrać opcję yes, wteyd wyświetli nam się dodatkowa część formularza
Incident Owner Team - zespół, który jest właścicielem incydentu
Incident Type - typ incydentu
Financial loss - strata finansowa
Link to recovery task - link zadań związanych z odzyskiwaniem pieniędzy
Qualitative impact of the problem - skala wpływu incydentu na organizację
Need to report to the supervisor - czy jest potrzeba zgłoszenia incydentu do nadzorcy
Information Security Incident - czy jest to incydent bezpieczeństwa informacji
Personal data leakage - czy nastąpił wyciek danych osobowych
Dla incydentów SEV-3 i SEV-4 dostępne są ponadto pola (w SEV-1 i SEV-2 do wypełnienia w formularzu postmortem):
Incident start time - czas rozpoczęcia incydentu
Incident end time - czas zakończenia incydentu
Incident detection time - czas wykrycia incydentu
Description of corrective actions - opis zadań naprawczych
3. Zmiany w incydencie
Po uzupełnieniu przynajmniej wymaganych pól tworzymy incydent. W tym miejscu możemy edytować pola, które już uzupełniliśmy wybierając opcję Edit. Jeśli chcemy przejść do widoku zadania to klikamy w link (w tym przypadku INCYDENT-183).
4. Uzupełnienie incydentu
Po przejściu w widok zadania możemy edytować uzupełnione wcześniej pola przez wejście w opcję Edit (bez tego zadanie jest w formie tylko do odczytu). Należy wypełnić wymagane pola i złożyć formularz przez opcję Submit, jest to wymagane, aby zmienić status incydentu na Resolved.
5. Postmortem
Do incydentów SEV-1 i SEV-2 automatycznie linkowany jest formularz postmortem (na screenie powyżej Linked issues - INCYDENT-184), dodatkowo link do niego umieszczany jest w komentarzu do zadania. Do czasu wdrożenia Incident Commander postmortem wypełnia developer z obszaru objętego awarią. Po wdrożeniu pełnego procesu, IC będzie wypełniał pola, o których informacje zdobędzie w trakcie rozwiązywania incydentu.
Link do instrukcji wypełniania postmortem
<Link do instrukcji wypełniania postmortem wkrótce>
Quality Assurance
Poniżej znajdziesz informacje, jakie testy możemy dla Ciebie przeprowadzić i w jaki sposób możesz zgłosić zapotrzebowanie na nie.
Jakie testy wykonujemy?
testy manualne:
testy integracyjne, w tym testy API
testy systemowe e2e
testy akceptacyjne, w tym testy GUI
testy powdrożeniowe, produkcyjne
Testy automatyczne:
testy integracyjne, w tym testy API
testy systemowe e2e
testy GUI
Testy wydajnościowe - temat w trakcie rozwoju
W jaki sposób zgłaszamy zapotrzebowanie na testy?
Zespół QA ma swoje dedykowane SD znajdujące się pod adresem https://qa.bm.pl/. Do wyboru mamy 2 warianty testów - testy Web i testy Mobile.
Każdy z tych wariantów zawiera w sobie odpowiedni formularz, gdzie podajemy niezbędne przy testach informacje.
Co powinno zawierać zgłoszenie?
Zgłoszenie powinno zawierać informacje, które pozwolą każdej testerowi z odpowiednimi kompetencjami (tester manualny/automatyzujący) podjąć temat.
Summary - krótki opis czego dotyczą testy.
Type of tests - jakiego rodzaju testy mają zostać wykonane. Do wyboru mamy Manual, Automatic i Other (np. stress testy)
Components - wybieramy z listy obszar, którego dotyczą testy.
Project Owner - kto jest właścicielem projektu.
Contact Person - podajemy dane osoby, z którą tester może się kontaktować w momencie pojawienia się pytań co do testowanego tematu.
Link to documentation - odnośnik do wiki/makiet, które pozwolą testerowi zrozumieć temat zlecony do testów.
Link to Swagger - jeżeli mają być wykonane testy automatyczne badź testy manualne po API, tester powinien mieć dostęp do Swaggera, gdzie zespół developerski umieszcza informacje o wykorzystywanych w projekcie endpointach.
Environment - jakiego środowiska dotyczą testy.
Deployment date - od kiedy tester może zacząć testy.
Tests deadline - do kiedy testy powinny być wykonane.
Domain address - adres domeny, której dotyczą testy bądź z której testy mają być startowane (np. adres formsów).
Description - tutaj umieszczamy jak najbardziej szczegółowy opis tego, co ma zostać wykonane podczas testów. Pamiętajmy, że zadanie może podjąć każdy, więc opis powinien zawierać wszystkie niezbędne informacje. Najważniejsze informacje, jakie mogą się przydać:
zakres testów, czyli co dokładnie mamy przetestować (najlepiej w formie user stories z kryteriami akceptacji), może być link do wiki,
jeżeli testy dotyczą weryfikacji wprowadzonych zmian, to co było przed ich wprowadzeniem a co powinno pojawiać się po,
jakie są oczekiwane rezultaty tych testów (np. przy ścieżce sukcesu powinniśmy dostać komunikat OK, przy ścieżce negatywnej powinien pojawić się komunikat NIE OK). Jeżeli do weryfikacji rezultatów należy korzystać z dodatkowych systemów (bazy, panel oplaca-sie), to również należy to wskazać w zgłoszeniu,
jeżeli są to testy Mobile, dodaj proszę informację o systemie operacyjnym, którego mają dotyczyć.
Masz pytania?
Jeżeli któryś z punktów jest dla Ciebie niejasny, zgłoś się do dowolnej osoby z zespołu QA Organizacja zespołu - Zespół QA
Pozostałe
Wsparcie PayBM
DAS(OPS)
Omnichannel Customer Care
POLICJA
Księgowość
OPS_CF_MBS
Support for external Partners
Zakup
ODO
Incident Sandbox