Od jakiegoś czasu (czterech pracodawców wstecz) nurtuje mnie problem opanowania chaosu w środowisku, którym zarządzam. Środowisko nie było nigdy na tyle duże, żeby do każdej usługi oddelegowany był osobny zespół czy pracownik, ale też nie było homogeniczne. Stąd rodziły się różne problemy – np. X zajmował się głównie bazami danych, podczas gdy na serwerach pocztowych znał się słabo i zajmował jedynie z doskoku. Ew. znał tylko jedną technologię, a produktem innego dostawcy w tym samym zakresie (np. serwer WWW) opiekował się Y.
Oczywistym jest fakt, że należy tworzyć dokumentację wszystkich wdrażanych i testowanych rozwiązań, ale często jako powód braku jakiegokolwiek opisu podawany był brak środków (ugh!). Wszystko działa i jest fajnie do czasu jak pracownik mający w głowie wiedzę jest dostępny. Poza tym dokumentacja często jest lakoniczna, bo po co opisywać trywialne rzeczy. Niby tak, ale jak ktoś przejmuje taki środowisko, to nie wszystko jest jasne. Z drugiej strony szczegółowa dokumentacja odpycha (przechodziłem przez przedsiębiorstwo z ISO 9001:2000), a w razie awarii, gdzie każda sekunda jest cenna nie ma czasu na czytanie książek.
Podejścia do tworzenia opisów systemu poznałem różne (edytor tekstu, tablica suchościerna – tego mi najbardziej teraz brakuje, Wiki). Z każdego coś wyciągnąłem, ale brakowało mi zawsze schematu zależności pomiędzy usługami. Rozważmy hipotetyczną sytuację: nie wyświetla się strona główna naszej firmy, osoba odpowiedzialna jest na zagranicznych wczasach bez telefonu z roamingiem, a my musimy zdiagnozować problem i go rozwiązać. Ja widzę to tak: bierzemy do ręki mapę powiązań, odszukujemy usługi ‘strona WWW’, widzimy, że zależy od jakiegoś serwera WWW na serwerze WUWUWU oraz bazy danych na serwerze DEBE – oba serwery to wirtualne środowiska na serwerze WIRTU-OZ. Wiemy, że serwer i baza to warunki wystarczające, by nasza usługa była dostępna, więc badamy tylko składowe na konkretnych serwerach i znajdujemy źródło awarii. To czemu nie działało możemy zostawić specjaliście lub doskonalić się poprzez zagłębienie w temat po usunięciu usterki.
Jako, że nigdy nie miałem styczności z oprogramowaniem dedykowanym do rozwiązania takiego problemu, sam wymyśliłem strukturę bazy, gdzie są:
- usługi – czyli obiekty zawierające jedną lub kilka składowych, dające nam konkretny wynik; naturalnie nie ma sensu definiować tego zbyt obszernie (np. system informatyczny firmy), ale też nie powinniśmy za bardzo tego rozdrabniać ; przykład: system poczty czy strona WWW,
- składniki – niepodzielne części danej usługi, stanowiące osobny byt. Tu może być np. greylist lub antywirus dla poczty, czy też baza danych, od której zależy poprawne wyświetlanie strony internetowej,
- serwery – środowiska, w których działają składniki.
Jeśli chodzi o zależności pomiędzy powyższymi, to mamy tak: jedna usługa to jeden lub więcej składników, przy czym składnik może należeć do wielu usług (np. baza danych obsługuje serwis WWW i konta pocztowe), a na jednym serwerze może pracować wiele składników. Usługa (w tym rozumieniu) nie posiada konfiguracji, ma natomiast opis – jak najbardziej czytelny. Opis może zawierać dokumentację wdrożenia, schematy, itp. dane charakteryzujące usługę. Składnik, oprócz krótkiego opisu, musi zawierać konfigurację wzorcową, którą należy uaktualniać przy każdej poważniejszej zmianie. Dodatkowo każdy składnik może zależeć od innego składnika i to też musi być zaznaczone w schemacie (np. greylist to składowa systemu pocztowego, ale zależy od bazy danych, bo tam trzyma swoje informacje).
Przy takich założeniach i wykonanej rzetelnie mapie powiązań, młodszy informatyk (czy my po półrocznej przerwie w pracy przy danym rozwiązaniu) jest w stanie przed wykonaniem telefonu do eksperta stwierdzić, które ogniwo łańcucha jest odpowiedzialne za usterkę.
Od takiej mapy już krok do zdefiniowania serwerów, usług i powiązań w narzędziu do monitoringu (np. Nagios), co sprawi, że proces diagnozowania będzie skrócony do minimum.
Jestem przekonany, że taka mapa przyda się nie tylko w czasie awarii, ale także w sytuacji, gdy dana usługa kończy swój żywot (lub też gdy migrujemy na inne rozwiązanie) i musimy sprawdzić gdzie pozamiatać, ew. przy aktualizacji składowych (lub całkowitym ich wyłączeniu) – możemy wyświetlić nadrzędne usługi i sprawdzić je po zakończonym procesie.
Naturalnie żadna dokumentacja, nawet najlepsza, nie da nam gwarancji, że środowisko będzie zawsze działać. Od czasu do czasu warto przeprowadzać testy sytuacji awaryjnych.
Powyższe, to na razie moje luźne przemyślenia, nie mam jeszcze gotowej implementacji i liczę, że za jakiś czas, po przeczytaniu komentarzy do tej wiadomości będę mógł siąść do budowy gotowego rozwiązania, które posłuży mi w przyszłości, a także komuś, dla kogo moja teraźniejszość będzie przyszłością.
To problem, który dotyka chyba każdego admina zarządzającego serwerami w liczbie > 2. Osobiście po głowie chodziły mi obrazy a la MS Visio i konfiguratory sprzętu na stronach takich dostawców jak DELL, IBM etc.
Przyjemnie byłoby mieć rozwiązanie, gdzie ma się szafy. Do tych szaf można „zajrzeć” i obejrzeć dany serwer (zarówno informacje o hw jak i systemie/ach na nim uruchomionych). Dalej klikamy sobie w interesujący nas serwer/system (jeśli zwirtualizowany) i „rozwijamy” sobie listę usług w nim uruchomionych. Jeśli usługa X korzysta z czegoś na innym serwerze, to jakiś mareker „…”, po którego kliknięciu pokazuje nam się szafa->serwer->usługa Y z której korzysta X. Ach fajnie by było;-)