Najlepsze praktyki zarządzania infrastrukturą

Sklep internetowy, ERP, system magazynowy i integracja z dostawcami nie tworzą niezawodnego środowiska tylko dlatego, że wszystkie serwery wydają się być dostępne. Najlepsze praktyki wprowadzania zarządzania infrastrukturą tworzą porządek operacyjny, który wyjaśnia: kto podejmuje decyzje, kto zarządza, co można zmienić, co jest udokumentowane i jak można sprawdzić stan systemu krytycznego dla biznesu.

Zarządzanie nie jest warstwą administracyjną nad infrastrukturą. Jeśli jest dobrze zaprojektowane, zmniejsza niepewne granice odpowiedzialności, ryzyko ręcznych interwencji i ukryte zależności, które zazwyczaj stają się widoczne dopiero podczas awarii, audytów lub rozszerzeń. Jest to szczególnie ważne w firmach, gdzie wiele wewnętrznych systemów, zewnętrznych partnerstw i hybrydowych infrastruktur obsługuje jeden proces biznesowy.

Celem zarządzania nie jest spowolnienie, ale umożliwienie przewidywalnego podejmowania decyzji.

Zarządzanie infrastrukturą często napotyka opór, ponieważ zarówno menedżerowie, jak i operatorzy widzą w nim nowe cykle zatwierdzania, więcej dokumentacji i wolniejsze zmiany. Jest to realne ryzyko, jeśli regulacje nie są dostosowane do operacji biznesowych. Zbyt sztywny proces może rzeczywiście opóźniać na przykład rozszerzenia pojemności, modyfikacje integracji lub poprawki bezpieczeństwa.

Jednak właściwym celem nie jest przenoszenie każdej decyzji przed centralny komitet. Celem jest, aby decyzje były podejmowane na odpowiednim poziomie, z określoną odpowiedzialnością i możliwością śledzenia. Wstępnie zatwierdzone, niskiego ryzyka zadanie konserwacyjne wymaga innej procedury niż zmiana architektury sieciowej bazy danych ERP lub aktywacja nowego połączenia API z partnerem logistycznym. partner logistyczny aktywacja połączenia API.

Dobre zarządzanie jest zatem oparte na ryzyku. Tam, gdzie wpływ na biznes jest znaczny, potrzebna jest bardziej rygorystyczna kontrola, testowanie i zatwierdzanie. Tam, gdzie zmiana jest powtarzalna, udokumentowana i łatwo odwracalna, bardziej odpowiedni jest zautomatyzowany lub wstępnie zatwierdzony proces.

Punkt wyjścia do wprowadzenia zarządzania infrastrukturą: rzeczywista ocena stanu

Nie zaleca się budowania ram zarządzania na podstawie założeń. W wielu firmach infrastruktura jest częściowo udokumentowana, krytyczna wiedza jest w posiadaniu kilku kolegów lub zewnętrznych dostawców, a połączenia systemowe rozwijały się stopniowo przez lata. W takich przypadkach pierwszym zadaniem nie jest pisanie nowych zasad, ale odkrycie obecnego działania.

W tym procesie nie wystarczy lista serwerów i licencji. Należy również uwidocznić usługi biznesowe: które aplikacje są niezbędne do przetwarzania zamówień, wydawania magazynowego, fakturowania lub przesyłania danych produkcyjnych; jakie przepływy danych je łączą; od jakich zewnętrznych usług są zależne; i co się dzieje, gdy komponent ulegnie awarii. przesyłania danych produkcyjnych; jakie przepływy danych je łączą; od jakich zewnętrznych usług są zależne; i co się dzieje, gdy komponent ulegnie awarii.

Warto zarejestrować właściciela każdej krytycznej usługi, odpowiedzialnego technicznie, zarządcę danych, oczekiwany poziom dostępności, wymagania dotyczące kopii zapasowych i priorytet biznesowy odzyskiwania. Nie oznacza to koniecznie złożonej bazy danych zarządzania konfiguracją od pierwszego dnia. Na początku konsekwentnie utrzymywana rejestracja usług i zależności jest bardziej wartościowa niż przerośnięte narzędzie, którego nikt nie aktualizuje.

Własność musi być wyjaśniona zarówno z perspektywy biznesowej, jak i technicznej

Najczęstszym błędem operacyjnym jest sytuacja, gdy system ma operatora, ale nie ma właściciela biznesowego, lub odwrotnie. Operator może być odpowiedzialny za aktualizacje, monitorowanie i kopie zapasowe, ale nie może samodzielnie decydować, jak długo usługa może być niedostępna. To musi być określone przez dział biznesowy.

Jednocześnie właściciel biznesowy nie może podejmować decyzji technicznych bez odpowiednich informacji. Jednym z zadań zarządzania jest przekształcanie potrzeb biznesowych w mierzalne wymagania techniczne. Na przykład, jeśli przerwa w działaniu aplikacji mobilnej magazynu powoduje znaczące zakłócenia po dziesięciu minutach, to pociąga to za sobą cele odzyskiwania, potrzeby redundancji, monitorowanie i ograniczenia zmian.

Role, uprawnienia decyzyjne i wyjątki

Zarządzanie działa, gdy odpowiedzialność nie jest ogólnym stwierdzeniem, ale jest powiązana z konkretnymi decyzjami. Jasny model operacyjny określa, kto zatwierdza większe zmiany architektoniczne, kto zezwala na wyjątki dostępu, kto ponosi ryzyko usługowe i kto nadzoruje wykonanie.

Nie każda organizacja potrzebuje oddzielnego komitetu ds. infrastruktury. W średniej wielkości środowisku korporacyjnym często bardziej efektywne jest wyznaczenie regularnego spotkania technicznego i biznesowego, w którym uczestniczy kierownictwo IT, odpowiedzialni za operacje, rozwój lub integrację oraz przedstawiciel odpowiedniego działu biznesowego. Wartość forum nie tkwi w liczbie formalnych spotkań, ale w tym, że ma właściciela i termin dla otwartych ryzyk i decyzji.

Zarządzanie wyjątkami zasługuje na szczególną uwagę. Stary kontroler produkcji, nieobsługiwana aplikacja lub integracja wymagana przez partnera czasami nie spełniają wszystkich wewnętrznych standardów. Właściwą odpowiedzią nie jest ignorowanie tego, ani forsowanie niemożliwego do osiągnięcia idealnego stanu. Wyjątek należy udokumentować, określić właściciela ryzyka i, jeśli to możliwe, przypisać plan naprawczy z terminem.

Zarządzanie zmianami jako narzędzie ciągłości biznesowej

Wiele zmian wprowadzanych w środowisku produkcyjnym jest uzasadnionych samo w sobie: poprawki bezpieczeństwa, rozszerzenia pojemności, wprowadzanie nowych funkcji, modyfikacje sieci lub przekształcenia połączeń danych. Problemem zazwyczaj nie jest sama zmiana, ale brak oceny wpływu, testowania i planu przywracania.

W przypadku każdej znaczącej zmiany cel, zakres usług objętych zmianą, okno wykonawcze, osoba odpowiedzialna, metoda testowania i plan przywracania muszą być jasne. Jeśli zmiana się nie powiedzie, nie wystarczy powiedzieć, że "przywrócimy". Trzeba wiedzieć, z czego, w jakiej kolejności, z jakimi kontrolami integralności danych i kto podejmuje decyzję o zatrzymaniu.

W przypadku standardowych zmian nie ma potrzeby inicjowania pełnego procesu zatwierdzania za każdym razem. Udokumentowana, zautomatyzowana i kontrolowana regularna konserwacja może być wstępnie zatwierdzona. To pozwala zespołowi skupić się na naprawdę ryzykownych zmianach, jednocześnie nie spowalniając niepotrzebnie pracy operacyjnej.

Zasady są wartościowe tylko wtedy, gdy można je sprawdzić

Regulacje infrastruktury często składają się z ogólnych stwierdzeń, takich jak "regularne kopie zapasowe", "ograniczony dostęp" czy "odpowiednie logowanie". Są to właściwe zasady, ale same w sobie nie są zarządzalne. Zarządzanie wymaga weryfikowalnych wymagań.

W przypadku kopii zapasowych należy określić, które systemy muszą być zabezpieczone, z jaką częstotliwością, z jakim czasem przechowywania, gdzie są przechowywane i jaki test przywracania potwierdza ich użyteczność. W zarządzaniu dostępem nie liczy się tylko istnienie kont, ale także to, jak są przeglądane logowania, wylogowania, zmiany ról i przywileje dostępu.

To samo dotyczy monitorowania. Monitorowanie wspiera zarządzanie, jeśli nie tylko generuje techniczne alarmy, ale także dostarcza obraz stanu krytycznych usług biznesowych. Zaległości w kolejce przetwarzania, nieudany transfer danych lub niezwykle długie synchronizacje często szybciej sygnalizują problem biznesowy niż alarm obciążenia serwera.

Metryki wskazujące na widoczne ryzyko

Raport zarządzania na poziomie kierowniczym nie musi zawierać tuzina technicznych metryk. Przydatne jest to, co wspiera podejmowanie decyzji: ile krytycznych systemów nie ma przypisanego właściciela, które kopie zapasowe nie zostały przetestowane w planowanym okresie, ile jest otwartych wyjątków wysokiego ryzyka lub jak długo istnieje znane ograniczenie pojemności.

Wybór metryk zależy od działania firmy. Dla firmy e-commerce synchronizacja danych zamówień i zapasów może być krytyczna, podczas gdy w produkcji większą wagę może mieć zbieranie danych produkcyjnych lub ciągłość sieci na miejscu. Wspólną zasadą jest, że stan techniczny należy interpretować razem z wpływem na biznes.

Stopniowe wprowadzanie, a nie jednorazowy projekt

Wprowadzanie zarządzania rzadko jest skuteczne, jeśli traktuje się je jako jeden duży projekt regulacyjny. Warto najpierw skupić się na najważniejszych usługach i największych ryzykach operacyjnych: strukturze własności, dostępie, kopiach zapasowych, zarządzaniu zmianami i udokumentowanym odzyskiwaniu. Następnie model można rozszerzyć na inne systemy, lokalizacje lub środowiska chmurowe.

Według CGAT zarządzanie infrastrukturą przynosi prawdziwą wartość, gdy reprezentowane są architektura systemowa, integracje, operacje i procesy biznesowe. Nie chodzi o oddzielny zestaw dokumentów, ale o zdyscyplinowane działanie, w którym technologia firmy pozostaje przejrzysta i zarządzalna, nawet podczas wzrostu. zarządzanie infrastrukturą przynosi prawdziwą wartość, gdy reprezentowane są architektura systemowa, integracje, operacje i procesy biznesowe. Nie chodzi o oddzielny zestaw dokumentów, ale o zdyscyplinowane działanie, w którym technologia firmy pozostaje przejrzysta i zarządzalna, nawet podczas wzrostu.

Kolejny sensowny krok jest zazwyczaj prosty: wybierzmy proces krytyczny dla biznesu, zmapujmy jego systemy i zależności, a następnie zidentyfikujmy, gdzie brakuje uprawnień decyzyjnych, nadzoru lub zabezpieczeń odzyskiwania. Stąd można zbudować konkretny, zarządzalny plan rozwoju, a nie teoretyczny program zarządzania.