Początkiem projektu automatyzacji był dysonans – niepokojące uczucie, że coś jest nie tak. Jak „wieszający się” Matrix. Wraz z objęciem stanowiska dyrektora IT „odziedziczyłem” komplet dobrych procedur: politykę backupu, plany awaryjne. Miałem możliwość redundancji. Bardziej hipotetyczną, dawno nietestowaną, ale miałem. Nie miałem natomiast swobody wdrożeniowej. Nie mówię nawet o miesięcznym czy kwartalnym, stałym oknie serwisowym. Nie miałem okna wcale…
…miałem za to dynamicznie rosnącą Grupę Kapitałową Kęty, z reżimem pracy 24 godziny dziennie, 7 dni w tygodniu i praktycznie 365 dni w roku. Na to nakładała się ambitna strategia zarządu (ciągły wzrost) i wielomilionowy obrót generowany dziennie. Jednocześnie zaś miałem z tyłu głowy ciągłe pytanie, czy jak coś „padnie” to czy serwis dowiezie/naprawi to w 6 godzin, jak deklaruje? Czy jak stracę podstawową serwerownię, to czy po kilku dniach wzorcowej procedury odtwarzania będzie jeszcze dla kogo świadczyć usługi?
Silny sojusznik w zarządzie
Zarząd Grupy Kapitałowej Kęty miał wizję stworzenia „firmy światowej klasy w obszarach swoich działań”. Gdy w misji firmy pojawiają się takie wartości, jak: „dla przyszłości, zapewniając rozwój pracowników” czy „bezpieczeństwo”, to przekonanie zarządu do niezbędnego – z mojej perspektywy – uaktualnienia planów ciągłości działania zajęło mi mniej czasu niż Państwu przejrzenie spisu treści bieżącego numeru ITwiz.
Miałem więc cel i silnego sojusznika. Pozostał tylko plan na realizację oraz sprzedaż tematu. Na końcu naszej drogi zwykle jest bowiem Katalog Usług, za który ktoś będzie musiał – i chciał – zapłacić. W domyśle zarządy wszystkich spółek w Grupie Kapitałowej Kęty.
Wymagania zbyt trudne do zaspokojenia
Miałem dwa „super-serwery”, problemy wydajnościowe, kilka wzajemnie wykluczających się raportów dotyczących przyczyn oraz wizję, gdzie chcę się znaleźć. Celem było prawie-automatycznie przełączające się środowisko bez problemów wydajnościowych. Zacząłem „pingować” dostawców – dużych integratorów, operatorów telekomunikacyjnych. Dlaczego w końcu nie mieć zapasowego centrum w chmurze?
Projekt mający na celu zbudowanie świadomości konieczności posiadania Disaster Recovery Center wśród osób zarządzających oraz zdobycie sojuszników i klientów na planowaną usługę miał miejsce w IV kwartale 2013 r. Równolegle decydowaliśmy o wybraniu drogi- własnej bądź rozwiązania chmurowego.Finalnie przeważyła strona kosztowa oraz fakt, że dysponowałem kilkoma lokalizacjami z własnymi serwerowniami, chociaż wszystkie wymagały gruntownej modernizacji lub – w najlepszym przypadku – doposażenia.
Odpowiedzi były niestety niesatysfakcjonujące – oczywiście mamy, możemy, zapraszamy – ale „super-serwerów” w ofercie nie mamy. Tylko jedna firma podjęła rękawice, ale oferta, którą dostałem spowodowała mocniejsze bicie mojego, krakowskiego serca odpowiedzialnego za wydatki. Postanowiłem szukać własnej, optymalnej, „aluminiowej” drogi.
Myśl długofalowo
Pierwsze, prawdziwe, stress-testy miały miejsce w maju 2015 roku. Cała Grupa Kapitałowa Kęty została „przepięta” do zapasowej lokalizacji. Wszystkie spółki pracowały na systemach znajdujących się w zapasowej serwerowni. Po zakończeniu kilkudniowych testów i przepięciu się na podstawową serwerownię można było odtrąbić sukces. Sekwencja wielu projektów zmierzających do celu miała swoje, szczęśliwe zakończenie.
Projekt pierwszy, mający na celu zbudowanie świadomości wśród osób zarządzających oraz zdobycie sojuszników i klientów na planowaną usługę miał miejsce w ostatnim kwartale roku 2013. Równolegle, w drugim projekciedecydowaliśmy o wybraniu drogi – własnej bądź rozwiązania chmurowego. Finalnie przeważyła strona kosztowa oraz fakt, że dysponowałem kilkoma lokalizacjami z własnymi serwerowniami, chociaż wszystkie wymagały gruntownej modernizacji lub – w najlepszym przypadku – doposażenia.
Trudne pytania bez „dobrej” odpowiedzi
Trzeci projektmiał nam dać odpowiedź na jakim sprzęcie postawimy całe nowe środowisko. Rozmowy z dostawcami zewnętrznymi utwierdziły mnie w przekonaniu, że droga „super-serwerów” jest ślepą uliczką. Przywiązuje mnie do producenta i jego serwisu. Nie daje też żadnego pola manewru. „Sizing” z naszym dostawcą systemu ERP – który deklaruje zgodność z każdą platformą sprzętową oraz systemową – był największą niewiadomą. Jesteśmy jednym z bardziej skomplikowanych wdrożeń tego systemu ERP w Europie. Ogromna ilość przechowywanych w nim danych i kastomizacji powoduje, że nie mamy punktu odniesienia.
Testy nowej platformy wypadły obiecująco. Ale aby przestawić całą Grupę Kapitałową Kęty na nową platformę należało zmienić system operacyjny i wersję bazy danych w tym samym czasie.Pierwsze testy techniczne mówiły o tygodniowej przerwie na migrację i upgrade…Nie było to możliwe. Stanęło na jednym weekendzie. Wykres Gantta opisujący czynności, które trzeba było wykonać (często specjalnie budząc się na tę okoliczność) był imponujący. Do tej pory przedstawiam go jako wzorcowy.
Finalnie dostaję „propozycję”. Z wyżej wymienionych powodów ciężko uznać, że jest to żelazna rekomendacja. Jest nią klaster zwykłych serwerów w architekturze Intel. Wymaga to jednocześnie zmiany systemu operacyjnego oraz rozdzielenie serwera aplikacji i bazy danych. Sprzęt – wg. wyliczeń papierowych – ma być 4-krotnie szybszy od moich super maszyn i tańszy w zakupie blisko 10-krotnie.
Czy to możliwe? Czy chcemy to robić? Nikt od nas nie oczekuje takiej efektywności kosztowej. Mamy jedynie zapewnić bezpieczeństwo i rozwiązać problemy wydajnościowe. Po co się narażać? Może lepiej kupić kolejny „super-serwer”, przeprowadzić łatwy projekt migracji i kupić kolejne 2-3 lata względnego spokoju? Po miesiącu wewnętrznej walki oportunisty z innowatorem postanawiam, „na próbę”, kupić pierwszy klaster oparty o architekturę Intel. Duch poszukiwacza wygrał z końcem roku 2013.
Migracja skrócona z 3 tygodni do jednego weekendu
Najtrudniejszy projekt to taki, który nie wiadomo jak zrobić. Testy wypadły obiecująco. Ale aby przestawić całą Grupę Kapitałową Kęty na nową platformę należało zmienić system operacyjny i wersję bazy danych w tym samym czasie. Pierwsze testy techniczne mówiły o tygodniowej przerwie na migrację i upgrade. Nie było to możliwe. Stanęło na jednym weekendzie. Wykres Gantta opisujący czynności, które trzeba było wykonać (często specjalnie budząc się na tę okoliczność) był imponujący. Do tej pory przedstawiam go jako wzorcowy.
Wyszarpanie biznesowi całego weekendu – po raz pierwszy w historii – wymagałoby oddzielnego artykułu. Chociaż dodam, że wszyscy mieli dużo zrozumienia dla naszego wspólnego celu. Ostatecznie 19 maja 2014 roku Grupa Kapitałowa Kęty ruszyła na nowym klastrze. Po jego uruchomieniu wydajność systemu wzrosła dramatycznie. Dało nam to duży zastrzyk zaufania i poczucia pewności, że idziemy we właściwym kierunku.
Od pomysłu do gotowej procedury awaryjnej
Mimo iż były to kolejne trudne projekty – postawienie serwera aplikacji na analogicznym klastrze; modernizacja serwerowni zapasowej i przygotowanie odpowiedniego medium telekomunikacyjnego pomiędzy oddziałami – z perspektywy czasu wydają się małymi krokami, gdy my już pędziliśmy pełnym gazem rozzuchwaleni pierwszym sukcesem. Wybór koncepcji Distaster Recovery Plan (DRP), różnych dostawców i integratorów był już przysłowiową kropką nad i, wieńczącą półtoraroczną sekwencję wcześniejszy projektów.
Posiadanie zapasowej lokalizacji pozwoliło na pełną modernizację podstawowej serwerowni. Był to temat, którego nie chciałem dotykać wcześniej z oczywistych przyczyn. Plany ciągłości działania i architektura Active-Pasive ewoluowały do Active-Active. Bizneszaś wymaga dziś więcej! Pamiętając cele projektu oczekuje jeszcze wyższej dostępności i czasu przywrócenia usługi liczonej w minutach. Pierwotny dokument odtworzenia mówił zaś o kilkudziesięciu dniach przywrócenia usług po katastrofie…
Od decyzji do stress-testów minęło pół roku. Projekt, w którym było zaangażowane kilka firm – który z pewnością można byłoby przeprowadzić lepiej i oszczędzić sobie bezsennych nocy oraz napisać oddzielny (trzeci już) artykuł – finalnie dostarczył produkt, na który czekaliśmy. Zamknięcie papierowej procedury awaryjnej w sejfie zarządu zamknęło 2-letnią klamrę łącznie 6 projektów i wciągnęło procedury bezpieczeństwa Grupy Kapitałowej Kęty na zupełnie nowy poziom.
Od tego czasu wiele się zmieniło. Posiadanie zapasowej lokalizacji pozwoliło na pełną modernizację podstawowej serwerowni. Był to temat, którego nie chciałem dotykać wcześniej z oczywistych przyczyn. Plany ciągłości działania i architektura Active-Pasive ewoluowały do Active-Active. Biznes zaś wymaga dziś więcej! Pamiętając cele projektu oczekuje jeszcze wyższej dostępności i czasu przywrócenia usługi liczonej w minutach. Pierwotny dokument odtworzenia mówił zaś o kilkudziesięciu dniach przywrócenia usług po katastrofie…
Wiesław Rzepiński, dyrektor IT w Grupie Kęty
Opinie innych członków CIONET Polska w specjalnym wydaniu magazynu ITwiz
Podzieliliśmy je na 6 głównych działów: kreowanie wartości i przychodów; Customer Experience; automatyzacja; cyberbezpieczeństwo; Business Leadership i Talent Management. Doświadczenia swoich organizacji z tym związane opisało 17 liderów cyfryzacji reprezentują: PKO BP; Miejskie Przedsiębiorstwo Wodociągów i Kanalizacji we Wrocławiu; BEST SA; AmRest Holding SE; Liberty Global (właściciela UPC Polska); Zarząd Morskich Portów Szczecin i Świnoujście; Nowa Itaka; Rossman; Grupa Kęty; Optima; Nordea; Idea Bank; Grupa Onet; Moneygram; T-Mobile Polska i Tauron Polska Energia.
Ups! Nie mogliśmy znaleźć twojego formularza.
