W celu lepszego zrozumienia i pokazania jak należy tworzyć katalog usług wcieliłem się w postać Marka Zuckerberga, twórcy najbardziej znanego i najpopularniejszego portalu społecznościowego Facebook. Przygotuję katalog usług dla Facebooka dla wybranej usługi biznesowej i usługi systemu. Oczywiście będą to przeze mnie wymyślone usługi z parametrami jakie według mnie powinny posiadać ale jak najbardziej zbliżone do realnych. Może Mark z nich skorzysta ?

Definiowanie usługi biznesowej

• Nazwa usługi – Konto dla użytkownika indywidualnego

• Opis usługi – usługa umożliwia dostęp do konta na portalu Facebook dla użytkowników indywidualnych z urządzeń stacjonarnych i mobilnych. Użytkownik po zalogowaniu może korzystać ze wszystkich funkcjonalności w ramach swojego profilu

• Ważność dla biznesu– krytycza, ze względu na fakt, że jest to jedna z głównych funkcjonalności portalu. Oprócz niej są jeszcze inne takie jak np. FunPage, promowanie postów

• Termin wdrożenia na produkcję – 4.02.2004 (według https://pl.wikipedia.org/wiki/Facebook#Utworzenie)

Parametry usługi biznesowej

• Role – trochę przekornie podałem prawie wszędzie Marka Zuckerberga jako pełniącego wszystkie role (oprócz użytkownika) ale tak naprawdę w 2003/2004 roku tak było

  • Właściciel usługi biznesowej – Mark Zuckerberg,

  • Użytkownik/Użytkownicy – wszystkie osoby mające dostęp do internetu

  • Kierownik Projektu – Mark Zuckerberg

  • Service Level Manager – Mark Zuckerberg

  • Service Manager/Owner – Mark Zuckerberg

  • Analityk – Mark Zuckerberg

  • Architekt, Architekt infrastruktury, Architekt bezpieczeństwa – Mark Zuckerberg

• Ciągłość działania (BCP) – usługa jest krytyczna dla Facebook. Na niej opiera się najważniejszy biznes FB wię jest krytyczna i musi być uwzględniona w BCP. Nie robię analizy ryzyka ale od razu wiem, że wartości dla wartości dla dwóch parametrów powinny być następujące:

  • Recovery Time Objective (RTO) = 0 godzin 0 minut – FB nie może pozwolić sobie na niedostępność swojej krytycznej i najważniejszej usługi dlatego zostosowano rozwiązania High Availability, zapewniające ciągłość działania nawet w przypadku wystąpienia awarii

  • Recovery Point Obejctve (RPO) = 0 godzin 0 minut – FB nie może sobie pozwolić na utratę jakichkolwiek danych

• Bezpieczeństwo

  • metoda uwierzytelniania/dostępu – login i hasło, można ustawić two-factor authentication, który zwiększa poziom bezpieczeństwa poprzez potwierdzenia określonych czynności specjalnym kodem wysyłanym sms ma telefon komórkowy

  • polityka haseł – dostępna funkcjonalność, która pokazuje podczas zmiany hasła czy spełnia określone wymagania: długość, złożoność itp

  • odzyskiwanie hasła – działa funkcja przypominania hasła w przypadku jego zapomnienia

Definiowanie usługi systemu

• Nazwę usługi – Publikacja posta na profilu prywatnym

• Opis usługi – usługa umożliwia opublikowanie posta w formie tekstu, zdjęcia, wideo, aktywności na profilu prywatnym przez jego właściciela z urządzenia stacjonarnego lub mobilnego

• Ważność dla biznesu – krytycza, ze względu na fakt, że jest to jedna z głównych funkcjonalności profilu prywatnego. Oprócz niej są jeszcze inne takie jak np. wideo na żywo, like’owanie, komentowanie i dzielenie się postami innych użytkowników

Parametry usługi systemu (SLA)

Dostępność

• Kalendarz świadczenia – 24/7/365 – usługa musi być dostępna non-stop

• Dostępność w % = 99,999% w miesiącu – bardzo wysoka dostępność związana z krytycznością usługi

• Niedostępność = 26 sek w miesiącu – przeliczona z procentów na czas niedostępność usługi

Wydajność

• Wolumetria (pojemność) – rzeczywiste dane o wolumetrii Facebook dostępne są na stronach https://www.brandwatch.com/blog/47-facebook-statistics-2016/ https://expandedramblings.com/index.php/by-the-numbers-17-amazing-facebook-stats/. Zachęcam do zapoznania, niektóre liczby powalają.

• Czas odpowiedzi = 1 sekunda – takiego czasu odpowiedzi oczekują po kliknięciu na opublikuj posta

Obsługa serwisowa

• Przyjmowanie zgłoszeń – 24/7/365 – skoro usługa jest krytyczna i świadczona non-stop to przyjmowanie zgłoszeń również powinno być non-stop.

• Obsługa zgłoszeń – 24/7/365 – analogicznie jak przyjmowanie zgłoszeń przez https://www.facebook.com/help/

• Czas reakcji = 30 minut – wartość pożądana, której nie udało się potwierdzić na stronach FB

• Czas rozwiązania = 4 godziny– wartość pożądana, której nie udało się potwierdzić na stronach FB

• Okno serwisowe – od 00:00 do 06:00 GMT bez niedostępności. Architektura FB jest tak zaprojektowana i wdrożona, że wdrażanie poprawek lub nowych wersji nie wpływa na dostępność usługi dla użytkowników

Przedstawiłem przykładową usługę biznesową i systemy dla Facebook. Wierzę głęboko, że pozwoliło to przybliżyć tematykę tworzenia katalogu usług, dla osób które mają z nią pierwszy kontakt.

Zachęcam do dyskusji czy zdefiniowane przeze mnie usługa biznesowa i systemy oraz parametry je opisujące wiarygodnie opisują funkcjonalności Facebook, i które parametry mogą mieć wartości takie jak w rzeczywistości a które nie. Jeżeli masz jakieś pytania lub uwagi napisz je w komentarzy pod publikacją.

Artykuł Katalog usług dla Facebook pochodzi z serwisu Mariusz Siek.

W pierwszej części przedstawiłem jak zdefiniować usługę biznesową i jakie przypisać jej parametry w tym związane z SLA. W części drugiej zaprezentuję jak zdefiniować usługę systemu i jak określić dla niej parametry na poziom usług (SLA). Dana usługa systemu jest ściśle powiązana z konkretną usługą biznesową i dziedziczy po niej parametry usługi biznesowej.

Co jest potrzebne do zdefiniowania usługi systemu?

Definiując usługę systemu postępujemy analogicznie jak dla usługi biznesowej. Korzystamy z dokumentacji analitycznej przygotowanej przez zespół analizy oraz dokumentacji architektonicznej. Ponieważ co raz częściej zespoły wytwórcze pracują według metodyk zwinnych (Agile, Scrum) nie ma dokumentacji analitycznej a jedynym źródłem są historyjki. Dobrym sposobem jest spotkanie się z analitykiem i/lub architektem i pozyskanie niezbędnych informacji.

Definiowanie usługi systemu

Na podstawie uzyskanych informacji tworzymy usługę systemu. Pomagamy sobie definicją usługi systemu – jednoznacznie wyodrębniona w granicach systemu, funkcjonalność, która spełnia warunki: inicjuje ją użytkownik, daje określony rezultat i w ramach której wykonywane są operacje.

W oparciu o definicję tworzymy:

• Nazwę usługi, która pozwoli ją jednoznacznie zidentyfikować i będzie pozwalała na zrozumienie czego ona dotyczy

• Opis usługi, zawierający bardziej szczegółowe informacje o jej działaniu

• Ważność dla biznesu, określający jak ważna dla biznesu jest usługa systemu. Możemy wyróżnić trzy poziomy ważności: krytyczna, bardzo ważna i ważna. Ważność dla biznesu będzie miała wpływ na wyznaczenie poziomu usługi (SLA).

Katalog usług – Parametry usługi systemu (SLA)

Dla zdefiniowanej usługi systemu w katalogu usług, określamy jej poziom świadczenia następującymi parametrami SLA.

Dostępność

• Kalendarz świadczenia, określający w jakich dniach tygodnia i godzinach usługa jest świadczona dla użytkowników np. dni robocze 8:00-16:00

• Dostępność w %, określa jaki procent czasu usługa jest dostępna w ustalonym kalendarzu świadczenia za dany okres (najczęściej miesiąc) np. 99%

• Niedostępność, w inny sposób wyrażona dostępność w % pokazująca ile czasu (minut, godzin) usługa może być niedostępna w kalendarzu świadczenia za dany okres (najczęściej miesiąc) np. 101 minut w miesiącu (1 godz 41 minut), dla kalendarza świadczenia dni robocze 8:00-16:00 i dostępności w procentach 99%

Wydajność

• Wolumetria (pojemność), wyznacza maksymalną liczbę wywołań usługi systemu w jednostce czasu (minuta, godzina, dzień, miesiąc, rok), określając maksymalną pojemność dla usługi. Przykładowe parametry wolumetryczne:

  • Maksymalna liczba wywołań usługi w czasie

  • Średnia liczba wywołań usługi w czasie

• Czas odpowiedzi, określa czas oczekiwania użytkownika od momentu wywołania usługi do zwrócenia przez usługę odpowiedzi/wyniku np. 1 sekunda. Aby wyznaczyć czas odpowiedzi należy zdefiniować początek i koniec usługi systemu.

Obsługa serwisowa

• Przyjmowanie zgłoszeń, wskazuje przedział czasu, w którym przyjmowane są zgłoszenia (incydenty, service requesty, problemy) od użytkowników. Przyjmowanie zgłoszeń może być procesem automatycznym i różnić się od czasu obsługi zgłoszeń np. dni robocze od 6:00 do 18:00

• Obsługa zgłoszeń, wyznacza przedział czasu, w którym zespoły wsparcia obsługują zgłoszenia np. dnia robocze 8:00-16:00. Na zespoły wsparcia składają się I linia wsparcia (Service Desk), II linia wsparcia (zespoły utrzymania) i III linia wsparcia (zespoły wytwórcze lub dostawcy zewnętrzni).

• Czas reakcji, określa czas od przekazania zgłoszenia przez użytkownika (telefon, maila, narzędzie ITSM) do Service Desk do potwierdzenie przyjęcia zgłoszenia przez Service Desk np. 30 minut.

• Czas rozwiązania, wskazuje ile czasu zespoły wsparcia mają na rozwiązanie zgłoszenia (incydent, service request, problem) liczone od jego potwierdzenia przez Service Desk do dostarczenia skutecznego rozwiązania do użytkownika np. 4 godziny. Czas reakcji i rozwiązania można różnicować w zależności od ważności usługi dla biznesu (krytyczna, bardzo ważna i ważna)

• Okno serwisowe, podaje przedział czasu, w którym zespoły wsparcia mogą wdrażać rozwiązania zgłoszeń (incydenty, service requesty, problemy) oraz zmiany na produkcję np. codziennie 18:00-20:00. Okno serwisowe wiąże się przeważnie z niedostępnością usługi i powinno być poza kalendarzem jej świadczenia. Wyjątkiem są usługi świadczone w trybie 24/7/365.

Przedstawiłem najważniejsze parametry dla usługi systemu i na tym zakończę część drugą i ostatnią dotyczącą tworzenia katalogu usług. Oczywiście jeżeli są inne wymagania, można dla nich również zdefiniować parametry SLA. Mam nadzieję, że przedstawiona wiedza pomoże lepiej zrozumieć katalog usług i poziom świadczenia usług (SLA).

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz

Zapisz

Artykuł Katalog Usług – co powinien zawierać? Część 2 pochodzi z serwisu Mariusz Siek.