„Dostępność sprzętu jest zawsze wąskim gardłem”

Data: 2015-03-16
Autor: Sebastian Konkol
„Dostępność sprzętu jest zawsze wąskim gardłem”

To zdanie, jakie słyszę od szefów projektów IT, jest bez wątpienia prawdą. Sprzęt to jedyny komponent stosu technologii informatycznej, który musi być fizycznie dostarczony. Na to potrzeba czasu, choć nie sam czas dostawy (Lead Time) jest tu decydujący – najpierw ktoś go musi kupić. Pomijając sztuczki i triki zakupowe, sprzęt jest zwykle zamawiany na początku projektu i sporo czasu upłynie, zanim zacznie być wykorzystywany w stopniu zamierzonym. Tak, zakupy sprzętu zwykle zabierają tyle czasu.

Sprzęt kupowany jest zwykle w dużych „porcjach”, aby był w stanie sprostać prognozowanemu w przyszłości obciążeniu. Pełna utylizacja „porcji” sprzętu kupowanej na początku projektu następuje zwykle długo po zakończeniu tego projektu. Zakup sprzętu zamraża sporo kapitału na raczej długi czas. Patrzenie na zakup sprzętu jako na inwestycję wymaga dużej porcji wiary… Z drugiej strony, nie widziałem jeszcze projektu (i nie słyszałem o takim), w którym – po uruchomieniu systemu – nie wprowadzono żadnych zmian wpływających na predykcje obciążenia. Predykcje te to mit, który jest jednak niezmiennie wykorzystywany do uzasadniania zakupów sprzętu…

Z punktu widzenia praktyk księgowości, zakupy sprzętu muszą być inwestycją (budżet CAPEX), więc muszą być związane z projektem i „występować” w budżecie projektu. I tu pułapka się zamyka – projekt może być zawieszony lub zamknięty, ale sprzęt „już jedzie”.

Do takiej listy słabości związanych z zakupami sprzętu należy dołączyć co najmniej trzy kolejne:

  • Komponenty infrastruktury mają tendencje do bycia zapominanymi po inicjalnej alokacji do określonego projektu. Nawet jeśli projekt zostanie skasowany lub rzeczywiste obciążenie jest znacznie mniejsze od estymowanego, sprzęt pozostaje „na wyłączność” projektu.
  • Z powodu tradycyjnego podejścia, niejako w opozycji do punktu widzenia architektury korporacyjnej (EA, Enterprise Architecture), planowanie pojemności poszczególnych systemów daje w efekcie niezależne alokacje odseparowanych systemów.
  • Ponieważ rozwój systemów i działania utrzymaniowe są mocno rozdzielone w sferze decyzyjnej, decyzje dotyczące zakupów sprzętu wynikających z potrzeb zapewnienia obsługi naturalnego wzrostu obciążenia działających już systemów zapadają w oderwaniu od decyzji zakupów takiego samego sprzętu na potrzeby rozwoju funkcjonalności tego samego systemu.

Każde z tych zagadnień dodaje kolejnego „smaczku” do całkiem niezłego już bigosu nieefektywności wykorzystania sprzętu informatycznego – zakupy „na szybko” są drogie, a zakupy „w akceptowalnej cenie” trwają długo.

Bazując na dostępnych dzisiaj opcjach (np. Amazon AWS lub EC2, prywatne i publiczne chmury obliczeniowe), technicznie możliwe jest wyeliminowanie zakupów sprzętu w ogóle. W praktyce jednak wszyscy boją się „wycieku danych”, czym uzasadniają konieczność dalszego „inwestowania” we własny park maszynowy. Skoro więc nie można skorzystać z „rozwiązania ostatecznego”, to czy coś jednak można zrobić? Można, a to coś nazwałem buforem sprzętowym, rządzącym się następującymi zasadami:

  1. Budowa infrastruktury opiera się na dostępnych od kilku już lat (w skali czasu postępu technologicznego to już prehistoria) możliwościach wirtualizacji sprzętu i konsolidacji funkcji infrastruktury.
  2. Planowanie pojemności infrastruktury zapewnia „zasilanie pojemności” do bufora. Wielkość bufora ma pokrywać stronę „popytu” heurystyki popyt-podaż „sumy” zapotrzebowani i jest mniejsza, niż zsumowane zapotrzebowanie poszczególnych składowych.
  3. Strona „popytu” jest zorientowaną w czasie sumą składowych, wynikających ze wszystkich projektów oraz naturalnego wzrostu obciążenia działających na tej infrastrukturze systemów, pomniejszaną o planowane działania optymalizacji infrastruktury i wyłączanie systemów kończących swój żywot.
  4. Każdy powód rozszerzenia infrastruktury jest uzupełniany o oszacowanie prawdopodobieństwa materializacji takiego rozszerzenia, tworząc – zważoną tym prawdopodobieństwem – miarę oczekiwanego na dany moment obciążenia (jak w EMV, Expected Monetary Value).
  5. Wymagany czas reakcji na nowe zapotrzebowanie na infrastrukturę powinno być określone jako maksymalny czas, jaki może upłynąć między momentem uzgodnienia nowej porcji „popytu” a dostarczeniem infrastruktury – zapewnieniem „podaży”.
  6. Zakupy sprzętu powinny odbywać się w możliwie dużych paczkach, aby dawało się uzyskać ekonomiczny efekt skali, dzięki czemu jednostkowo cena zakupu jest niższa – cykl zakupowy powinien być zaplanowany z wystarczającym wyprzedzeniem, aby zapewnić dostępność wielkości bufora zgodnie z oczekiwanym czasem reakcji.
  7. Strona „podaży” powinna być wypełniana tak, aby zapewnić dostępność bufora infrastruktury, minimalizować jednostkowy koszt zakupu oraz uwzględnić wyprzedzenie czasu dostawy i optymalizację wynikającą z procesów zakupowych.
  8. Alokacja bufora powinna być okresowo weryfikowana, dla identyfikacji ewentualnych zmian w planach zakupowych.

Bufor infrastruktury (strona „podaży”) jest więc budowany w oparciu o heurystykę uwzględniającą wszystkie składowe „popytu”, zważone ich prawdopodobieństwem. Rozbudowa bufora nie jest jednak realizowana na potrzeby konkretnego projektu – część bufora może być alokowana (i realokowana) w odpowiedzi na zmienne potrzeby. O ile wybrana heurystyka jest wiarygodna, bufor powinien być zaalokowany w stopniu niemalże pełnym na moment kolejnego zakupu. Ustalanie parametrów heurystyki opiera się więc na dwóch podstawach: miarach prawdopodobieństwa materializacji elementów „popytu” (im większa „ważność” zapotrzebowania tym wyższe prawdopodobieństwo) i oczekiwanym czasie reakcji na zapotrzebowanie (im krótszy, tym większy bufor). W tym znaczeniu zarządzanie buforem sprowadza się więc do „zdrowej” oceny ryzyka inwestycyjnego.

Konstruując reguły określania wartości sterujących heurystyką, różne elementy można brać pod uwagę. Z dotychczasowych doświadczeń wynika, że uwzględnienie następujących elementów zapewnia skuteczność planowania:

  • Priorytet projektu. Wagi prawdopodobieństw można dobierać w zależności od (zmiennego w czasie) priorytetu projektu. W przypadku projektów „niedyskutowalnych” składowa bufora wynikająca z tego projektu jest równa co do pojemności dokładnie zapotrzebowaniu tego projektu. Nadal jednak wspomaga mechanizm realokacji, obniżając koszt posiadania bufora.
  • Nieoznaczoność zapotrzebowania. Zmienność obciążenia generowanego przez poszczególne systemy, która wpływa nie tyle na możliwość realizacji planów rozwojowych co na użyteczność działających już systemów, może być w różny sposób uwzględniana w „strukturze” bufora – jeśli system jest krytyczny, to 100% obserwowanej wcześniej zmienności, a jeśli system nie jest „tak ważny”, to mniejsza część. Nadal jednak są to składowe, które mogą być współdzielone, minimalizując ryzyko na całym „portfelu” aplikacji.
  • Poziom akceptacji opóźnień projektów. Im mniejszy poziom akceptowanego opóźnienia projektu w przypadku braku dostępności infrastruktury, tym większa pojemność bufora. Nadal jednak nie wynosząca 100% sumy „popytu” wynikającego z poszczególnych składowych.

We współczesnych realiach ekonomicznych, każda inicjatywa kontroli kosztów powinna być postrzegana przez pryzmat globalnej optymalizacji kosztów. Inicjatywy kontroli kosztów infrastruktury powinny więc być także oceniane przez pryzmat całego środowiska systemów informatycznych i oceniane portfelowo. Oparcie takiej optymalizacji na podstawach pomijających EA może – w najlepszym wypadku – zapewnić uwzględnienie czynników drugorzędowych, podczas gdy gros potencjału optymalizacji pozostanie nadal poza zasięgiem takich inicjatyw.

Pozostaw komentarz