Na solidnym fundamencie

Kluczowe pytanie związane z zarządzaniem konfiguracją brzmi: jak głęboko?

Kluczowe pytanie związane z zarządzaniem konfiguracją brzmi: jak głęboko?

Awaria na początku wyglądała niewinnie. Użytkownicy III piętra narzekali na uciążliwe przerwy w dostępie do aplikacji. Od razu wiadomo było, że problem tkwi w nienormalnym obciążeniu sieci na tym piętrze. Po analizie okazało się, że jeden z serwerów plików generuje niespodziewanie dużo ruchu sieciowego. Ktoś przytomnie postawił pytanie, co takiego serwer robi i po analizie serwisów nt. bezpieczeństwa sieciowego okazało się, że w jego systemie musiał zainstalować się robak. Błąd co prawda znany był od dawna, ale jakoś przy ostatnim "łataniu" zapomniano o serwerze plików z III piętra. Błyskawicznie odłączono urządzenie, wykonano odwirusowanie i zainstalowano wszystkie potrzebne uaktualnienia. Oprócz przestoju sieci musiano ponownie sprawdzić wszystkie serwery na obecność luk, które hakerzy mogliby wykorzystać. Koszty przestoju oraz wszystkich operacji naprawczych sięgnęły tysięcy złotych, a firma do dzisiaj nie wie, jakie dokumenty i gdzie zostały wysłane przez złośliwe oprogramowanie, które przez pewien czas przejęło kontrolę nad komputerem.

Rozważmy inny scenariusz, związany z kosztami. Przedsiębiorstwo postanowiło zbudować nową aplikację centralizującą dane o klientach, dotąd rozproszone w systemach - jakby zalążek systemu CRM. Do tego celu postanowiono zakupić nowy, wysoko wydajny, dwuprocesorowy serwer, na którym miała działać aplikacja oraz baza danych. Koszt takiego zakupu wyniósł - wraz z kosztem licencji i rocznego wsparcia - niemal 70 tys. zł. Tymczasem po analizie przez niezależnego konsultanta okazało się, że zakup był całkowicie zbędny. Istniejący park serwerowy w zupełności wystarczałby na obsłużenie nowej funkcjonalności - należało jedynie skonsolidować trzy inne bazy i aplikacje funkcjonujące na niezależnych maszynach, wykorzystywanych w ok. 20-50%. Uwalniało się w ten sposób dwa fizyczne serwery - główny i zapasowy - bez konieczności zakupu nowego sprzętu i licencji oraz w ramach istniejących kontraktów serwisowych. Konsolidacja aplikacji i baz kosztowała nie więcej niż 15% tego, co należałoby wydać na nowy serwer.

W obu opisanych sytuacjach warunkiem uniknięcia niepotrzebnych strat lub wydatków jest posiadanie scentralizowanej informacji o infrastrukturze. Jednym słowem: potrzebna była baza konfiguracji.

O rzeczach i zjawiskach

Czymże jest baza konfiguracji (CMDB)? Przytoczmy najbardziej popularną definicję: baza konfiguracji to miejsce składowania informacji o elementach wspierających świadczenie usług informatycznych w organizacji. Minimalna zawartość bazy konfiguracji to opis sprzętu i oprogramowania znajdującego się w organizacji. Do tego wiele źródeł informacji dodaje jeszcze dwie: dokumentacja i personel. Wszystko to mieści się w pojęciu: elementy konfiguracji (Configuration Items, CI). Jakkolwiek brzmi to trochę jak "masło maślane", baza konfiguracji to miejsce przechowywania elementów konfiguracji.

Do samych elementów dodajmy szalenie istotny element - zależności między nimi. Zamiast o bazie powinniśmy więc zacząć mówić o mapie; dobra baza konfiguracji przypomina raczej siatkę połączeń kolejowych albo hipertekstowy przewodnik, nie zaś katalog książek w bibliotece.

Baza konfiguracji to żyjąca dokumentacja infrastruktury informatycznej przedsiębiorstwa. Im wcześniej wdrożymy bazę konfiguracji oraz procesy zarządzania nią (przede wszystkim proces kontroli zmiany), tym "taniej" uzyskamy korzyści, jakie CMDB przynosi. Najtrudniej rozpocząć zarządzanie konfiguracją, kiedy w przedsiębiorstwie jest już niemała i nieudokumentowana infrastruktura oraz, na dodatek, istnieje grupa osób, które przyzwyczajone są do zarządzania nią na zasadzie ad hoc. W tej sytuacji np. powołanie nowej instancji bazy danych wydaje im się czynnością czysto techniczną, do wykonania w wolnej chwili, bez dodatkowych autoryzacji i dokumentacji. Wdrożenie CMDB zmienia wszystko - osoba, która chciałaby powołać nową instancję bazy, musi najpierw ten fakt zaplanować, potem uzyskać stosowne akceptacje, później wykonać czynność techniczną, a na końcu odzwierciedlić nowy stan bazy konfiguracji. Nieomal wszystkie czynności wydają jej się jałowe i kłopotliwe - choć z punktu widzenia firmy są niezbędne.

Kwestia głębokości

Kluczowe pytanie związane z zarządzaniem konfiguracją brzmi: jak głęboko? Ten sam obiekt fizyczny możemy zamodelować na kilka sposobów. Przypuśćmy, że posiadamy serwer z przykładu podanego na początku tego artykułu. Można go skatalogować w CMDB na trzy przykładowe sposoby. Pierwszy, najprostszy, każe uczynić elementem konfiguracji cały serwer, zaś w mniej lub bardziej ustrukturalizowanym opisie zawrzeć po prostu szczegóły techniczne, np. liczbę procesorów, rozmiar dysków, posadowiony system operacyjny itd. Inne, bardziej szczegółowe podejście, to wyodrębnienie części hardware jako osobnych elementów konfiguracji. Na przykład może być używana zarówno z tym serwerem, jak i z innym i warto wyodrębnić ją jako oddzielny element, zaś interfejsy sieciowe typu Gigabit Ethernet mogą być zarządzane zdalnie za pomocą protokołu SNMP i również warto odwzorować je osobno. Trzecie, jeszcze bardziej szczegółowe podejście, kazałoby odwzorować dokładnie system operacyjny oraz oprogramowanie wraz z istotnymi komponentami, aż do konkretnych aplikacji i bibliotek (plików wykonywalnych).

Jak głęboko więc należy modelować bazę konfiguracji? Pytanie jest źle postawione. Prawidłowe pytanie brzmi: w jakich sytuacjach będzie nam potrzebna baza konfiguracji i czy wysiłek, który poświęcimy na jej stworzenie i utrzymanie, będzie "zwracał się" w wyniku lepszego zarządzania infrastrukturą? CMDB, najkrócej mówiąc, służy do eliminacji ryzyk. Wymieńmy kilka sytuacji, w których dostęp do informacji co, gdzie i jak można znaleźć w naszej infrastrukturze może informatykom zaoszczędzić wydatków, czasu albo nerwów. A więc:

  • rozwiązywanie problemu zgłoszonego przez użytkownika - powinniśmy wtedy mieć pod ręką informację co i w jakiej wersji użytkownik ma na swoim komputerze, aby sprawnie mu pomóc;
  • reakcja na awarię - w tej sytuacji musimy błyskawicznie zastąpić uszkodzony element infrastruktury identycznym lub równoprawnym urządzeniem - a w tym celu konieczna jest znajomość nie tylko jego numeru seryjnego i modelu, ale i najczęściej dokładnej konfiguracji;
  • naruszenie bezpieczeństwa - musimy szybko zdiagnozować skutki incydentu i opracować sposób zapobieżenia dalszym szkodom;
  • ochrona bezpieczeństwa - kiedy np. publikowana jest nowa łatka do systemu operacyjnego, a lokalne służby IT mają ograniczony czas, aby ją nanieść - powinny więc od razu uzyskać informację, na jakich serwerach i/lub stacjach roboczych łatka powinna zostać zainstalowana;
  • wprowadzenie nowego elementu do infrastruktury - aby ocenić, jakie są potencjalne konsekwencje (analiza wpływu);
  • audyt systemów informatycznych - posiadając bazę konfiguracji, wysiłek związany z audytem jest ograniczony do minimum;
  • wprowadzenie zmiany - w wyniku któregoś z powyższych.

Konfiguracja i procesy

Powiedzieliśmy już o procesie zarządzania zmianą. To bodaj najważniejszy proces w zarządzaniu konfiguracją, ale także i największa korzyść z jej posiadania. W przedsiębiorstwie, dla którego istotna jest np. ciągłość pracy, nie można sobie pozwolić na najkrótsze nawet zatrzymanie funkcjonowania kluczowych aplikacji. Dlatego każde wprowadzenie zmiany powinno być poprzedzone analizą potencjalnych jej skutków - i w tym właśnie ujawniają się największe korzyści z CMDB. Dzięki bazie możemy nieomal natychmiast dowiedzieć się: jakie elementy zależą od zmienianego? Co może się stać i jak możemy temu zaradzić?

Przypuśćmy, że mamy do czynienia z jednym z najprostszych rodzajów zmiany: zmianą w sprzęcie. Zamieniamy np. koncentrator sieciowy na inny. Zanim to zrobimy, sprawdzamy więc, gdzie ów koncentrator się znajduje, z jakimi komputerami jest połączony oraz do jakiego segmentu należy. Zastanawiamy się wtedy: co zdarzy się, jeśli nowy koncentrator nie będzie prawidłowo spełniał swojego zadania? Mogą zostać odcięte komputery znajdujące się w tym segmencie sieci. A kto pracuje na tych komputerach i co na nich działa? Być może są to kluczowe aplikacje, których odcięcie choćby na moment spowoduje poważne problemy biznesowe. Może więc należy najpierw sprawdzić tę operację na wydzielonym segmencie, służącym tylko do testu, bo ryzyko jest zbyt poważne? To przykład rozumowania, które można skutecznie przeprowadzić tylko mając dojrzałą i odpowiednio zamodelowaną bazę konfiguracji.

Kolejny proces to reakcja na pojawiające się problemy. Przy odpowiednio bogatej bazie konfiguracji możemy stopniowo ograniczać zakres problemu; np. na początku wiemy, że mamy jakiś problem z siecią, potem ograniczamy to do segmentu, w którym odwzorowaliśmy grupę urządzeń aktywnych oraz stacji roboczych, aż wreszcie izolujemy problem do jednego komputera. Na koniec okazuje się, że jest na nim niedostatecznie zabezpieczony system operacyjny. W ten sposób, poruszając się jedynie po narzędziu informatycznym, potrafimy przybliżyć problem. A w przypadku gdy nie da się go usunąć inaczej niż przez wymianę urządzenia lub instalację oprogramowania od nowa - mamy pod ręką jego specyfikację.

Następny przykład procesu ułatwianego przez CMDB to zarządzanie licencjami. Aby firma posiadała ważne licencje na wszystkie systemy stosowane na komputerach i - co nie mniej ważne - by wykorzystywała je wszystkie optymalnie, potrzebna jest baza konfiguracji. W dużych firmach oszczędności pochodzące z optymalnego zarządzania licencjami mogą iść w dziesiątki tysięcy złotych.

Ostatnia wreszcie zaleta, ostatni proces związany z konfiguracją to jej raportowanie. Przydaje się to w nader wielu okolicznościach - np. przy przygotowaniu budżetu, przy inwentaryzacji i audycie systemów, przy próbach ujednolicenia platformy, outsourcingu itd.

Wiarygodność przede wszystkim

Pamiętajmy, że dokładność odwzorowania infrastruktury nie jest najważniejszym wyzwaniem dla bazy konfiguracji. Tak jak przy każdym repozytorium danych obowiązuje zasada garbage in garbage out. Baza konfiguracji będzie dawać dobre informacje tylko wtedy, gdy jakość danych w niej zgromadzonych będzie właściwa. Typowy błąd popełniany przez przedsiębiorstwa to budowanie bazy "z doskoku"; jako jednorazowy akt, nie zaś jako ciągły proces. Po krótkim czasie taka baza, nieobudowana procedurami kontroli zmiany oraz audytu zawartości, pozostaje w tyle za rzeczywistością.

Dlatego wiele firm powołuje specjalną rolę "strażnika bazy konfiguracji", który jest jedyną osobą upoważnioną do nanoszenia zmian. Jeżeli on trzyma się pewnych reguł - istnieje duże prawdopodobieństwo, że to, co jest w bazie, jest także w rzeczywistości.

Jeżeli rygor udaje się utrzymać, a skala jest odpowiednio duża, korzyści z CMDB są trudne do przecenienia. Wie to każdy, kto wdrożył u siebie zarządzanie konfiguracją; kto jeszcze tego nie zrobił, wkrótce stanie przed tą decyzją.


TOP 200