Case Study: Środowisko testowe jako usługa z SLA

Data: 2016-03-02
Autor: Sebastian Konkol
Case Study: Środowisko testowe jako usługa z SLA

W ramach prac dla mojego aktualnego klienta „zderzyłem się” z ciekawym tematem, który objawił się koniecznością napisania umowy SLA dla usługi dostępu do środowiska testowego systemu informatycznego. Jak to zwykle bywa, objawy to jedno, a rzeczywiste zagadnienie do rozwiązania – zupełnie inna sprawa.

Z jednej strony system, dla którego miała być świadczona usługa środowiska testowego, jest dość ważny – infrastruktura krytyczna. Z drugiej strony, wymagający klient usługi, więc usługa ma być z SLA. Punkt wyjścia dyskusji „ma być 95%” – tylko czego? To jest takie rzeczywiste, z życia, zagadnienie praktyczne – nie takie, które rozwiązuje się „czystym ITILem”. Jak to w życiu – rozwiązanie prawdziwego problemu nie poddaje się teorii i wymaga kilku punktów widzenia.

Podobno facetom wszystko się kojarzy z jednym. Jestem facetem, więc nie będę próbował zaprzeczać. Zawodowo jednak czuję się przede wszystkim architektem i to jest mój podstawowy punkt widzenia na zagadnienia IT. Oczywiście, ITIL jest właściwym „przewodnikiem” po SLA, jednak – jak już kiedyś pisałem  – dla SLA ważniejsze jest to, żeby wiedzieć, co jest jego podstawą. Przygotowanie do napisania SLA dla środowiska testowego, czyli QA2 okiem architekta.

Architektura techniczna, infrastruktura środowiska testowego:

  • Jakie rodzaje testów klient chce prowadzić na tym środowisku? Jeśli tylko funkcjonalne, to pół biedy, ale jeśli wydajnościowe lub bezpieczeństwa, to infrastruktura testowa powinna odpowiadać produkcyjnej, a każda różnica powinna być znana – a przede wszystkim powinny być znane konsekwencje tego odstępstwa dla wiarygodności testów. Dla przykładu, dla testów wydajnościowych powinny być dobrze określone współczynniki skalowania poszczególnych elementów, aby dało się interpretować wyniki takich testów.
  • Jaki zasięg infrastruktury powinien być zapewniony? Czy chodzi o system informatyczny, czy także sieć, storage? Które elementy infrastruktury powinny być dostarczone, aby dało się prowadzić dany rodzaj testów? Czy da zapewnienia wiarygodności testów ta infrastruktura ma być dedykowana, czy współdzielona z innymi środowiskami?

Architektura danych, dane do testów:

  • Czy testy mają być prowadzone na kopii danych produkcyjnych, czy też muszą one być zanonimizowane? Czy ma być dostępny pełny zakres danych dostępnych na środowisku produkcyjnym, czy jakoś ograniczany? A może dane powinny być przygotowywane dla realizacji konkretnych testów i powinny zastępować / uzupełniać dane istniejące?
  • Jaki zakres danych, pochodzących z jakich systemów, powinien być dostępny do testów? Czy po przeprowadzeniu „edycji testów” dane mają pozostawać, czy być tworzone „od nowa” dla kolejnej edycji?

Architektura aplikacji, funkcjonalność realizująca testy:

  • Jakie systemy i jakie interfejsy muszą być udostępnione w środowisku testowym? Powinny one odpowiadać zakresowi testów, jakie chciałby prowadzić klient na środowisku. Czy konieczne jest włączenie do środowiska testowego systemów, czy też zastąpienie ich emulatorami tych systemów?
  • Czy środowisko testowe powinno być tworzone przez systemy odseparowane od środowisk produkcyjnych, czy też – z powodów wymagań świeżości danych, czy ograniczeń licencjonowania – niektóre systemy muszą być produkcyjne?

Architektura biznesowa, efekt testów:

  • Jakie procesy mają być dostępne w środowisku testowym? Czy mają to być procesy end-to-end, czy też jakieś ich fragmenty?
  • Jak ma być sprawdzany wynik testów – za pośrednictwem testowanych systemów, czy też w sposób niedostępny w trybie użytkownika systemu? W tym drugim przypadku konieczne jest zapewnienie dostępu w wymaganych trybach.

Reżim obsługi, wiarygodność testów:

  • Jakie rodzaje testów i w jakich warunkach można prowadzić na środowisku testowym? Przy jakich ograniczeniach i uwarunkowaniach poszczególne rodzaje testów mogą być uznane za wiarygodne? Jakich testów na pewno nie można prowadzić na dostępnym środowisku?
  • Jaka ma być „intensywność” prowadzenia testów? Jakie założenia dla przygotowywania środowiska należy przyjąć (wyprzedzenie informowania o potrzebie, czasy przygotowania, formalizmy odbioru gotowości środowiska testowego do danej edycji testów)?
  • Jakie zasady mają obowiązywać, kiedy klient „wywróci” środowisko testowe lub jakiś jego element?
  • Jak stwierdzić, że środowisko jest „dostępne” dla prowadzenia testów? Jak odróżnić sytuację „niedostępności” środowiska od błędu zidentyfikowanego w ramach prowadzenia testów?

Rzecz jasna powyższa lista nie stanowi pełnej listy zagadnień, jakich rozstrzygnięcia wymaga rzetelne przygotowanie umowy SLA. Odpowiedź na większość powyższych pytań ma jednak przynajmniej trzy komponenty: techniczny (co trzeba zrobić w środowisku testowym, aby „działało”), organizacyjny (jakie prace należy organizować, aby wypełniać zobowiązania) i uwarunkowań (co klient może, a czego mu nie wolno). Każde SLA sprowadza się w końcu do perspektywy finansowej (ile to będzie kosztować).

Odpowiedzieliśmy na powyższe pytania, więc piszemy umowę SLA. Wbrew pozorom, w tym trzyliterowym skrócie tkwi sporo mądrości:

  • Service. Dostęp do środowiska testowego nie jest usługą i nigdy nią nie będzie. Usługą jest możliwość weryfikacji zmian w systemach, przeprowadzona w kontrolowanych warunkach, dających odpowiedni poziom ufności w wyniki weryfikacji. Usługa taka ma wiele procesów obsługi (np. rekonfiguracja infrastruktury, przygotowanie danych, dostosowanie aplikacji, obsługa incydentów środowiska), które muszą działać, aby usługę uznać za świadczoną.
  • Level. Początkowe „95%”, ale czego? Dostępność środowiska mierzona parametrami technicznymi nie ma nic wspólnego z możliwością prowadzenia testów, których wynik może być uznany za wiarygodny. Konieczne jest ustalenie nie tylko miar technicznych, ale także miar jakości procesów obsługi, a także – chyba przede wszystkim – uwarunkowań, jakie muszą być spełnione dla realizacji testów, także przez klienta.
  • Agreement. To na co się strony umawiają w odniesieniu do uwarunkowań prowadzenia testów, uprawnień i obowiązków każdej ze stron? Jakie będą konsekwencje naruszenia uwarunkowań, uprawnień lub obowiązków? Za co więc ma płacić klient – tylko za usługę, czy za swoje błędy też?

Niby wszystko zupełnie oczywiste, tylko dlaczego nie jest stosowane? Dla mojego aktualnego klienta ta „podróż” po pisaniu umowy SLA ze spojrzeniem architektonicznym była odkryciem. Myślę, że życie zawodowe nie przestanie mnie zaskakiwać. Ktoś jeszcze chce ma potrzebę napisania dobrego SLA?

Pozostaw komentarz