Zmiany w IT
Postępująca transformacja cyfrowa napędza procesy zmian w strukturach IT naszych organizacji. Dynamika tych zmian szczególnie przyspieszyła w ostatnich dwóch latach za sprawą pandemii COVID-19. Administratorzy stanęli przed wyzwaniem utrzymywania architektury systemów, wydajności działania aplikacji czy sterowania dostępem do wewnętrznych zasobów firmy w jeszcze bardziej dynamicznych środowiskach. Z drugiej strony, chcąc pozostać konkurencyjnym na rynku, nie możemy rezygnować z wprowadzania najnowszych technologii, takich jak rozwiązania mikrousługowe czy przetwarzanie chmurowe, które niestety tę złożoność i dynamikę jeszcze potęgują. Jak zatem rejestrować obecny stan naszej struktury IT, jej konfiguracji, jak obserwować i zapisywać pojawiające się w niej zmiany? Jakie mogą być dla nas korzyści takiego rozwiązania, a jaki jest koszt jego wdrożenia?
Przykład
Załóżmy daną sytuację: w ramach projektu rozwojowego naszego przedsiębiorstwa wdrożona została dedykowana aplikacja do zarządzania instalacjami naszych usług u klientów końcowych. Jej głównymi elementami są panel webowy dla managerów oraz aplikacja mobilna, z której korzystają monterzy. Dodatkowo system jest zintegrowany z platformą sprzedażową z bazą klientów i zamówień. Firma zewnętrzna przygotowała projekt aplikacji i architektury, a następnie przy współpracy z działem utrzymania wdrożyła rozwiązanie. Przygotowała nawet szczegółową dokumentację! Posiadamy środowisko testowe, wykorzystywane do wspólnej weryfikacji kolejnych wersji aplikacji, oraz środowisko produkcyjne, gdzie wszystko powinno już działać bez zakłóceń. Tak jest w teorii.
Wyzwania
Pewnego dnia dochodzi do sytuacji, w której system produkcyjny nagle przestaje działać. Szybka diagnoza wskazuje, że przed awarią doszło do wdrożenia nowej wersji aplikacji. Natychmiast zwołano zebranie, na którym znaleźli się reprezentanci zespołu deweloperskiego dostawcy, działu utrzymania aplikacji oraz biznesu. Pierwszym rozwiązaniem, które się pojawiło, było oczywiście jak najszybsze przywrócenie poprzedniej działającej wersji aplikacji. Zrzucałoby to winę na deweloperów, którzy jednak zastrzegają, że przeprowadzili dokładne weryfikacje na środowisku testowym i wszystko powinno być w porządku. Nie protestowali natomiast i wykonano szybko przywrócenie poprzedniej wersji. Niestety, ku mocnemu zdziwieniu wszystkich, to również nie pomogło. Procesy aplikacyjne dalej nie chciały działać, wyrzucając szereg dziwnych komunikatów w momencie startu. Sytuacja zrobiła się bardzo napięta, biznes naciskał na naprawienie systemu w trybie pilnym, a deweloperzy z administratorami zaczęli już przerzucać się oskarżeniami. Postawiono tezę, że być może zmieniło się coś na środowisku produkcyjnym, co różni je od testowego i dlatego aplikacja nie działa. Jak natomiast szybko porównać ze sobą te dwa systemy? Zweryfikować dokładnie, co zmieniło się w tym czasie? Mamy oczywiście dokumentację wskazującą, jak teoretycznie powinna wyglądać architektura systemu z określeniem wersji oprogramowania i konfiguracji. Tylko jak skorelować to ze stanem faktycznym? Nie mamy niestety jego aktualnego obrazu. Na całe szczęście jednemu z administratorów przypomniał się upgrade jednego z frameworków, na który wskazał dział bezpieczeństwa po ostatnim audycie. Okazało się, że został on zaktualizowany tylko na środowisku produkcyjnym, automatycznie w czasie okna serwisowego wspólnie z wdrożeniem nowej wersji aplikacji. Nowsza wersja nie była wstecznie kompatybilna z aplikacją i to wywołało problem. Tymczasowo przywrócono poprzednią jego wersję i aplikacja ruszyła.
Morał
Po tej sytuacji postanowiono w zdecydowany sposób zapobiec tego typu wydarzeniom w przyszłości. Podjęto decyzję, że nie możemy dalej akceptować faktu, że po pierwsze: nie znamy obecnego, faktycznego stanu naszej infrastruktury, wersji oprogramowania, konfiguracji i innych parametrów czy atrybutów mogących mieć wpływ na działanie aplikacji oraz po drugie: nie monitorujemy wystąpienia zmian w tych obszarach. Potrzebna jest zatem baza danych zawierająca te informacje oraz sposób na rejestrowanie zmian w nich. Możliwe byłoby tutaj podejście ręczne: zbudowanie schematów obecnej architektury, zebranie wersji oprogramowania, plików konfiguracyjnych, stanów i powiązań pomiędzy poszczególnymi elementami systemu. Następnie każda modyfikacja musiałaby zostać zaakceptowana i zapisana, zmodyfikowana w zestawieniu. Nie jest to podejście nowe, już w 2002 roku można znaleźć w zbiorze dobrych praktyk ITIL definicję Configuration Management Database (CMDB) - inwentarza zasobów hardware’owych i software’owych rozbijający elementy systemu na wyszczególnione warstwy i zależności. Od tej pory w wielu organizacjach podejmowano próby wdrożenia takiego podejścia, jak pokazuje jednak doświadczenie - z marnym skutkiem. Najczęściej wszystko rozbija się o zmotywowanie zespołów do ciągłej weryfikacji zmian i wprowadzania ich do wskazanego systemu. Każda najmniejsza pomyłka czy pominięcie zmniejszała zgodność ze stanem faktycznym i przede wszystkim wiarygodność danych. Czy jest jednak na to inne rozwiązanie?
Nowy trend – Real-time CMDB
Po serii niepowodzeń pojawiła się koncepcja automatyzacji tworzenia i aktualizacji baz konfiguracyjnych. Jednym z podejść jest usługa skanowania przestrzeni sieciowej przez roboty, które mogą mieć nawet możliwość zalogowania się do weryfikowanego hosta i zmapowania obecnych na nim zasobów oraz połączeń. W takim przypadku aktualizację przeprowadzamy tylko raz na pewien czas, a zatem w dalszym ciągu nie mamy bieżących informacji o zmianach. Innym, coraz popularniejszym rozwiązaniem jest instalacja na elementach, hostach, które chcemy monitorować, niewielkiej aplikacji - agenta, który ma ciągły, bezpośredni dostęp do informacji i może dzięki temu w czasie rzeczywistym śledzić i wysyłać dane o konfiguracjach i powiązaniach. Podejście to jest już szeroko wykorzystywane w platformach do monitoringu wydajności aplikacji (APM), takich jak choćby lider tego rynku – Dynatrace. Serwer główny zbiera i przetwarza przesłane informacje, może budować na ich podstawie drzewo zasobów i konfiguracji z listą zmian w czasie. W tym przypadku nasza praca sprowadza się tylko do instalacji samego agenta – koniec mrówczej pracy przy utrzymywaniu. Jak wygląda takie rozwiązanie w praktyce?
Rozwiązanie – Versio.io
Niemiecka firma QMETHODS stworzyła Versio.io – platformę software’ową, która zapewnia centralny inwentarz zasobów i konfiguracji dla biznesu i IT, a przy tym wykrywa i przetwarza ich zmiany. Jej baza konfiguracji tworzy i aktualizuje się samodzielnie. Pozwala na to przede wszystkim mechanizm agenta OneImporter, który po instalacji zaczyna monitorować wybrane obszary i zauważa modyfikacje zmapowanych atrybutów. Versio.io może również korzystać z danych już pozyskanych przez inne systemy poprzez integracje czy dodane przez dedykowane API.
Stan każdego z elementów możemy zobaczyć na osi czasu z chronologicznym zapisem wykonanych modyfikacji. Pozwala to na sprawdzenie czy nawet przywrócenie z wybranego momentu z przeszłości. Dzięki temu dowiemy się, że dany element został dodany, zmodyfikowany bądź usunięty z systemu.
Zasoby i konfiguracje mogą być zależne od siebie. W Versio.io usługa topologizacji automatycznie tworzy mapy takich zależności. Co więcej, pozwala na ich historyzację, czyli poznanie różnic w czasie również na tym poziomie.
Przechwytywane mogą być wszystkie ważne z punktu widzenia biznesowego elementy systemów, na każdym poziomie organizacji – zarchiwizowane, z topologią powiązań i przechowane w centralnym repozytorium.
Epilog
W jaki sposób wdrożenie Versio.io dla organizacji z naszego przykładu mogłoby zapobiec sytuacji, która zaistniała? Wersja frameworku, która okazała się problematyczna, zostałaby zmapowana jako jeden z atrybutów procesów działających w środowisku produkcyjnym. Jej zmiana zostałaby zarejestrowana i jeśli byśmy chcieli, zostalibyśmy o tym powiadomieni. A to z kolei mogłoby zapobiec awarii przy aktualizacji aplikacji. Nawet gdyby do niej doszło, to zespół deweloperów i administratorów, mając przegląd zdarzeń dla danego obszaru, zauważyłby o wiele szybciej, co zostało zmodyfikowane i w ten sposób powiązano by tą informację z błędami. Na koniec, topologie i poszczególne cechy środowiska testowego i produkcyjnego mogłyby być na bieżąco ze sobą porównywane (automatycznie, jako jedna z funkcji Versio.io – Delta topology), a wykryte różnice wskazywałyby na potencjalne problemy przy wdrożeniu nowych wersji. Co najważniejsze, nikt nie musiałby wykonywać ręcznej pracy związanej z weryfikacją tych zmian – to zadanie agenta OneImporter zainstalowanego na hostach.
Przedstawiony przykład to jeden z szeregu przypadków zastosowania platformy Versio.io. W następnych odcinkach poznamy jej kolejne funkcje i przewagi. Jeśli jesteś zainteresowany i chcesz dowiedzieć się więcej, zachęcamy do kontaktu z Omnilogy oraz do zapoznania się ze stroną producenta – www.versio.io.
