Cykl życia data center (DC) to nie tylko projekt, budowa, utrzymanie i ciągły rozwój. W pewnym momencie przychodzi taki czas, kiedy trzeba zamknąć lub przekazać komuś innemu obiekt, z którym wiązaliśmy wiele planów i nowych perspektyw rozwoju. Czas jest jednak nieubłagany, a zmiany rokowań ekonomicznych, fuzje, przejęcia i generalnie koniunktura rynkowa, za którą muszą podążać decyzje biznesowe, są bezwzględne i nieustannie się zmieniają.

Zamykanie ośrodka przetwarzania danych stało się również udziałem autora w minionym roku. Dlatego w poniższym artykule spróbujemy przyjrzeć się kilku istotnym punktom tego zagadnienia oraz przekazać osobiste przemyślenia i, miejmy nadzieję, pomocne wskazówki. Powodów zamknięcia danej lokalizacji DC może być kilka. Najczęściej możemy mieć do czynienia z:

• ogólnym ustaniem zapotrzebowania na taki ośrodek (np. wskutek przeniesienia większości usług do chmury obliczeniowej);
• fuzją z inną firmą, która ma własne ośrodki;
• outsourcingiem usług, co powoduje zminimalizowanie potrzeb biznesu dotyczących zasobów IT;
• sprzedażą części serwisów firmom zewnętrznym;
• oszczędnościami, cięciami lub po prostu trudną sytuacją firmy.

Wspominamy o tym, dlatego że przyczyny zamknięcia mogą bezpośrednio dotknąć samą fazę zamykania centrum danych. Mowa tu przede wszystkim o różnym podejściu do kwestii przenoszenia własności i zarządzania majątkiem firmy, ale również o nastawieniu ludzi, którzy będą zaangażowani w proces wygaszania części działalności. W pewnym momencie mogą dojść do wniosku, że również dla nich zabraknie miejsca w nowej strukturze przedsiębiorstwa. A to może pociągać za sobą wiele pytań, nieufności lub nawet doprowadzić do masowych odejść z firmy w najbardziej newralgicznym okresie.

Kwestia przedstawienia całej sprawy i podejście do zagadnień kadrowych może mieć więc istotne znaczenie. Liczy się tutaj przede wszystkim wrażliwość, szczerość i transparentność wobec pracowników. Raz zawiedzione zaufanie trudno potem odbudować. Nawet brutalna prawda jest lepsza od nieszczerości i prób zaciemniania faktycznego stanu rzeczy.

> Przygotowania

Na samym początku musimy sobie uświadomić, że przed nami poważny, złożony projekt, który niestety nie zakończy się raczej wielkim rozwojowym sukcesem. Jego efektem będzie tym razem pomniejszenie naszego firmowego kapitału o jeden, a może kilka ośrodków. Cel? Najczęściej oszczędności, redukcja kosztów czy szeroko pojęta restrukturyzacja przedsiębiorstwa. Cała przygoda może trwać od kilku miesięcy do nawet kilku lat, jeśli mamy do czynienia z potężnym i skomplikowanym centrum danych.

Skoro rozpoczynamy tak złożony projekt, to nie zapominajmy oczywiście o trójkącie projektu, czyli budżecie, czasie i zakresie. A całe przedsięwzięcie zaczynamy od dobrego planowania i zebrania jak największej ilości informacji. Kierownik projektu powinien postarać się zebrać wartościowe dane w następujących obszarach:

• zespoły administracyjne odpowiedzialne za poszczególne części architektury IT, księgowość, security, dział prawny, zespół data center odpowiedzialny za utrzymanie infrastruktury krytycznej itd. – to wsparcie osób z tych zespołów będzie kluczowe w zbieraniu kolejnych porcji danych z dalszych podpunktów;
• umowy z administratorem obiektu i wszystkimi podwykonawcami, którzy świadczą jakiekolwiek usługi;
• dane na temat zainstalowanego w serwerowni sprzętu IT: ilości, modele, numery seryjne, barcody, dane finansowe;
• architektura IT: wspierane procesy biznesowe, aplikacje, urządzenia dostępowe, przetwarzane dane, środowiska operacyjne, serwery wirtualne, podsieci, magazyny danych;
• projekty powykonawcze: architektura, infrastruktura techniczna, sieci logiczne;
• określenie zależności pomiędzy różnymi obszarami – zależności biznesowe, logiczne, sprzętowe (np. dana aplikacja i jej zasoby fizyczne – serwery).

Im bardziej kierownik projektu przyłoży się do fazy zbierania i porządkowania informacji, tym mniej niespodzianych sytuacji spotka go w późniejszym czasie. Na pewno dostęp do wszelkich repozytoriów poprzednich projektów, narzędzia do zarządzaniami assetami (np. SAP, CMDB, DCIM), wszelkie bazy danych czy wewnętrzne dokumentacje zespołów okażą się na wagę złota. Należy szczególnie dobrze przeanalizować kwestie związane z architekturą IT, a tutaj niestety w niektórych wypadkach dokumentacja jest niewystarczająca lub mało aktualna i trzeba się często wspierać tzw. zaciąganiem języka u specjalistów odpowiedzialnych za poszczególne obszary. Może to być żmudna i niewdzięczna praca, ale wykonanie jej na pewno zaowocuje w przyszłości.

Od project managera (PM), który będzie nadzorował cały proces, wymagane jest zaangażowanie, wytrwałość, cierpliwość i upór, a także wszechstronna wiedza o firmie, zasobach i procesach. Zespół projektowy, którym będzie kierowała taka osoba, musi być przede wszystkim interdyscyplinarny. Różne umiejętności i wiedza okażą się przydatne na różnych etapach projektu. Dlatego tym bardziej potrzebne będą wysokie umiejętności interpersonalne ze strony PM-a, aby „okiełznać” różnorodność charakterów i uzyskać zamierzony efekt. Jak już wspominaliśmy wcześniej, ludzie mogą różnie podchodzić do tematu zamykania ośrodka ze względu na specyfikę projektu. Kiedy wiesz, że za parę miesięcy lub rok możesz stracić posadę np. ze względu na przeniesienie Twojego zakresu pracy na zewnątrz i likwidację stanowiska, wtedy zaangażowanie może błyskawicznie stopnieć do zera. Taki pracownik będzie raczej słabym punktem wsparcia dla całego zespołu. W obliczu takiej sytuacji trzeba przede wszystkim zadbać o przejrzystość całego procesu oraz przedstawić wszystkim ewentualne możliwości i przyszłe plany firmy związane z kwestiami restrukturyzacji w obszarze zatrudnienia.

> Krok za krokiem

Po zebraniu szczegółowych informacji z różnych obszarów, ustaleniu zakresu, budżetu i daty zakończenia projektu przychodzi czas na wykonanie Quality and Risk Analysis (QRA). Analiza ryzyka dla naszego projektu pomoże nam lepiej zrozumieć stojące przed nami zadanie oraz pozwoli zwrócić uwagę sponsora projektu na ewentualne problemy i trudności, które napotkamy w dalszej fazie. Już na tym etapie PM będzie miał pewną możliwość negocjacji trójkąta projektu, jeśli tylko jego argumenty będą odpowiednio silne i poparte konkretnymi analizami czy zidentyfikowanymi ryzykami.

Sprawą, którą należy zająć się równolegle, jest przeanalizowanie umów koniecznych do wypowiedzenia, które najczęściej są podpisywane na kilka lat z góry. Będą to umowy dotyczące najmu powierzchni – czy to biurowych, czy samego data center – obsługi administracyjnej, obsługi techniczno-serwisowej dotyczącej infrastruktury krytycznej czy nawet umowy na wywóz nieczystości lub inne usługi, które były świadczone w biurach z pomieszczeniami adaptowanymi na serwerownie. Odnośnie do umów mogą wystąpić dwa główne scenariusze: albo zostały one podpisane na zbyt długi okres i należy je wypowiedzieć wcześniej (tutaj wchodzi w grę kwestia płacenia ewentualnych kar umownych), albo już na początku projektu wiemy, że nie zdążymy w ciągu np. jednego roku zamknąć ośrodka i należy umowy przedłużyć. W tym miejscu ponownie pada trudne pytanie: o ile? Niestety przy wynajmie powierzchni od innych podmiotów nierzadko jest tak, że istnieje jakiś minimalny okres podnajmu, którego nie da się skrócić. Wtedy bardzo mocno trzeba uważać na opłacalność całego przedsięwzięcia i adekwatność planowanych terminów zamknięcia.

[...]

Autor jest specjalistą ds. utrzymania infrastruktury data center. Zajmuje się problematyką budowy, utrzymania i zarządzania centrami przetwarzania danych oraz koordynowaniem zmian dotyczących krytycznej infrastruktury IT.