„Efektywność infrastruktury – zrób coś, proszę!”

Data: 2015-02-16
Autor: Sebastian Konkol
„Efektywność infrastruktury – zrób coś, proszę!”

To kolejne zdanie, jakie często słyszę od moich klientów, albo wyczytuję je z wyrazu twarzy, kiedy próbują zrozumieć, co takiego „ten cały złom” robi – kiedy robi to, co ma robić. Zagadnienie to ma dwa „dna” – oczywiste i behawioralne.

Oczywiste „dno” jest często artykułowane przez menedżerów IT – struktura infrastruktury i sposób zarządzania nią nie są zgodne ze strukturą i sposobem zarządzania systemami informatycznymi w ich „warstwach powyżej” infrastruktury. „Dno” behawioralne zasadza się na tym, że specjaliści od infrastruktury postrzegają swoją rolę w sposób skupiony wyłącznie na infrastrukturze, a specjaliści od aplikacji działają niemalże wyłącznie w sferze swojego zainteresowania. Jeśli ktoś tego nie czuje, proponuję w ramach jakiegoś projektu rozwojowego zorganizować spotkanie „infrastruktury z aplikacjami” – niezapomniane wrażenia.

Problemy te ujawniają się na różne sposoby, a typowe symptomy, jakie obserwowałem wielokrotnie, mogą być następujące:

  • Znaczące problemy towarzyszą produkcyjnemu wdrożeniu większej zmiany w środowisku informatycznym. Systemy pozytywnie zweryfikowane w testach na środowisku testowym okazują się nie działać w środowisku produkcyjnym.
  • Brakuje zasobów dla obsługi zapotrzebowania wprowadzanego do środowiska produkcyjnego przez nowe wdrożenia.
  • Projekty rozwoju aplikacji i zmian w infrastrukturze „wchodzą w kolizję” w czasie migracji na środowisko produkcyjne – ich efekty są niezgodne i wzajemnie wykluczające.
  • Specjaliści rozwoju aplikacji i specjaliści od infrastruktury pozostają w stanie permanentnego konfliktu.

Podstawowym powodem istnienia takich problemów jest niewłaściwy rozdział odpowiedzialności pomiędzy grupy, które – niejako z definicji – muszą reprezentować odmienne punkty widzenia. Bez wątpienia, problemy te powinny być rozwiązane w sferze organizacji, a właściwą metodą do wykorzystania jest IT Governance. Nie sposób jednak skutecznie rozwiązywać takie problemy bez ustalenia przedmiotu działań – tu właśnie ujawnia się potencjał pozytywnych działań architektów. Z moich doświadczeń, skuteczną metodą jest przeprowadzenie działań w następujących obszarach:

  • Zdefiniuj infrastrukturę. Trzeba odpowiedzieć sobie na pytanie, co ma być określane jako infrastruktura ucinając na tym etapie wszelkie zalążki dyskusji o tym, kto za co odpowiada. Czy infrastruktura to tylko sprzęt „obliczeniowy” (serwer), sieć i przestrzeń składowania danych (macierze), czy też infrastrukturą jest także platforma operacyjna (system operacyjny), a może także platforma aplikacyjna (serwer aplikacyjny, serwer WWW, serwer bazy danych)? W mojej ocenie wszystkie wymienione składniki są infrastrukturą.
  • Zdefiniuj interfejsy między infrastrukturą i aplikacją. W jakich kategoriach określać zapotrzebowanie na zasoby infrastrukturalne aplikacji (transakcje na sekundę, TPERFs, IOPs)? Jak określić te „usługi” infrastruktury, na których opierać się ma aplikacja (usługą bez wątpienia nie jest częstotliwość zegara procesora, ani liczba rdzeni procesora, ani wielkość dostępnej przestrzeni RAM)? Co to znaczy SLA dla takich usług?
  • Określ uprawnienia decyzyjne. Infrastruktura zapewnia świadczenie usług, a aplikacje konsumują te usługi, realizując swoje zadania. Taka relacja powinna być określona w kategoriach podaży i popytu – w formie umowy. Zarówno specjaliści od infrastruktury jak i specjaliści od aplikacji powinni być uprawnieni do podejmowania wszelkich decyzji pozostających w ich obszarach działań, o ile konsekwencje tych decyzji nie wpłyną na możliwość wywiązywania się z umowy podaży-popytu.

Ustanowienie takich zasad jest kluczowe z dwóch powodów. Pierwszym jest możliwości bezpośredniego rozwiązania konfliktu decyzyjnego i pośredniego rozwiązania zagadnień niezgodności infrastruktury i aplikacji. Drugim jest możliwość reprezentowania w portfelu działań IT przedsięwzięć zwykle niewidocznych (ciągła optymalizacja infrastruktury). Przedsięwzięcia z drugiej grupy mogą dotyczyć:

  • Relokacje infrastruktury. Określenie infrastruktury i interfejsów ze światem aplikacji (z zapewnieniem przestrzegania tych ustaleń) pozwala na łatwiejsze planowanie zmian infrastruktury (konsolidacje, rozbudowy, czasowe przesunięcia) bez konieczności ustalania wszystkiego ze wszystkimi.
  • Inżynieria systemowa. Wszystkie warstwy systemów informatycznych wymagają działań utrzymaniowych: wdrażanie poprawek (np. system operacyjny, platforma aplikacyjna, komponenty gotowe), bieżący tuning (np. przestrzeń i efektywność bazy danych), konsolidacja i wirtualizacja.
  • Zarządzanie siecią. Znacząca część usług infrastruktury wymaga sieci. To bardzo podstawowy obszar optymalizacji (np. segmentacja, kierowanie ruchem) i najoczywistsze miejsce aplikowania zasad i polityki bezpieczeństwa.

Koszt posiadania infrastruktury to poważna składowa każdego budżetu IT, a optymalizacja infrastruktury obiecuje oszczędności. Opierając się na filozofii architektury korporacyjnej (EA, Enterprise Architecture), analizy podaży usług infrastruktury i popytu na nie w przejrzysty sposób uzyskuje się wymaganą separację i zdolność do rozdzielenia kompetencji decyzyjnych. Podejście takie opiera się na dekompozycji stosu technologicznego i oparcia na nich definicji usług, dla których wyznaczane byłyby warunki podaży i popytu. Niełatwe, ale da się zrobić.

Skuteczny podział kompetencji decyzyjnych wymaga precyzji i transparentności określenia przedmiotu tych procesów decyzyjnych. EA stanowi najlepszą kanwę dla wykreślania – precyzyjnych i transparentnych – granic między składowymi architektury, co czyni ją najlepszą kanwą dla rozwiązania także tego zagadnienia zarządzania IT.

Pozostaw komentarz