Zero Touch. Główna siedziba administratorów infrastruktury 0 Touch. Chmura prywatna ING Banku Śląskiego. Godzina 6:00

Transkrypt

1 Zero Touch Główna siedziba administratorów infrastruktury 0 Touch Chmura prywatna ING Banku Śląskiego. Godzina 6:00 Mam na imię Piotr jestem nowym specjalistą ds. automatyzacji i monitoringu infrastruktury IT w ING Banku Śląskim. Właśnie zaczynam poranną zmianę. Pierwszy rzut oka na konsolę administracyjną upewnia mnie, że wszystko jest pod kontrolą. Testy automatyczne dla kilku aplikacji zakończyły się o 3:30. Wyniki, wygenerowane automatycznie zostały przesłane do zlecających. Nie mam żadnych czerwonych alertów. W trakcie testów kilka serwerów wirtualnych przekroczyło wskaźniki wydajności - głównie brakowało pamięci wirtualnej. Zlecający testy już pewnie o tym wiedzą, ale na wszelki wypadek zadzwonię i upewnię się, że do następnych testów poprawią wzorcową konfigurację maszyn a może któraś funkcja za bardzo poszalała i potrzebne są zmiany w aplikacji dojdą do tego, właśnie dla takich wniosków robimy testy. Godzina 4:00 to krytyczny moment, w którym środowisko zaczyna się zmieniać. Cała infrastruktura przechodzi na model dzienny. Uwielbiam to obserwować, kiedy mam zmianę nocną. Wówczas, jak za dotknięciem czarodziejskiej różdżki serwery zaczynają znikać z konsoli. Cała moc obliczeniowa centrum danych zostaje oddana serwerom produkcyjnym. Już nie są potrzebne wirtualne maszyny testowe. Na ich miejscu, na tych samych zasobach, powstają kolejne maszyny produkcyjne. Ich zadaniem jest przyjęcie dziennej pracy aplikacji, czy naszych użytkowników rozlokowanych w oddziałach lub przedstawicieli mobilnych - zewnętrznych firm obsługujących ruch telefoniczny kampanii sprzedażowych i wsparcia klienta. Dopóki nie zacząłem tu pracować nie zdawałem sobie sprawy, do jakiego poziomu i do jakiej perfekcji można doprowadzić proces automatyzacji. Zawsze wyobrażałem sobie, że środowiskiem kilku tysięcy serwerów zawiadują setki osób, zmiany wykonywane są miesiącami, a proces przygotowania nowych środowisk i infrastruktury pod nowe aplikacje jest bardzo czasochłonny. Tu, w Banku jest zupełnie inaczej: wszystko budujemy z klocków, które architekci nazywają standardami. Jest ich kilkadziesiąt, jak w dobrym zestawie LEGO Technic, ale i tak dużo mniej niż w firmach, w których pracowałem wcześniej. Nie wiem jak udało się to wszystko posprzątać i uzgodnić, ale mamy np. tylko dwie wersje systemu operacyjnego, dwie wersje bazy danych, o sprzęcie i serwerach fizycznych nie wspomnę. Nie ma potrzeby kombinować, wystarczy wybrać najlepszy standard dla danych zastosowań i już! Ze standardów budujemy tzw. STOSY - gotowe moduły, (sprzęt, wirtualizator, system operacyjny, serwer aplikacyjny, czy baza danych i aplikacja), które są podstawą do stworzenia serwera wirtualnego. Ta wirtualizacja jest obecna na każdym kroku wirtualne serwery, wirtualne zasoby dyskowe, ale dzięki temu incydenty związane z zakupem nowego sprzętu są rzadkością. Dobre planowanie pojemności i ilości sprzętu ogranicza ten proceder do niezbędnego minimum. Starzy administratorzy mówią, że ostatnie duże zakupy były dwa lata temu. Godzina 7:00 Proces tworzenia świeżych serwerów z jednego wzorca dla sieci oddziałów i Call Centre zakończył się pozytywnie. Widzę pierwsze logujące się osoby, które zaczynają swoją codzienną pracę. Wczoraj dodaliśmy kolejny moduł aplikacji do obsługi kampanii sprzedażowej powiązanej z serwisem aukcyjnym nic dużego Moduł ten sprawdza w największych polskich serwisach numery telefonów osób wystawiających aukcje sprzedaży i porównuje je z numerami naszych klientów. Następnie

2 wystawia tego klienta do kampanii sprzedażowej kredytów, jako potencjalnego nabywcę innego podobnego przedmiotu sprzedałeś samochód pewnie będziesz chciał kupić nowy Wszystkie elementy w module przeszły pozytywnie testy obciążeniowe dla środowiska. Skalowanie ilości serwerów w farmie było zrobione poprawnie, niezbędne zasoby zostały dodane, ale tak jak mówią specjaliści od zarządzania pojemnością: przy nowościach zawsze musimy założyć wzmożoną klikalność, a co za tym idzie zwiększone obciążenie infrastruktury. Nie boje się tego, mimo że dzisiaj jestem sam na zmianie. Wiem, że automat, cały czas sprawdza dopuszczalną ilość użytkowników na serwerze, średnie obciążenie procesora i zużycie pamięci dla każdej sesji. Jeśli nagle zacznie czegoś brakować, automat sam rozpocznie uruchamianie kolejnych serwerów, które uzupełnią lukę w niezbędnej pojemności zasobów. Fajnie pomyślane czasami próbuję sobie wyobrazić, co by było gdyby nagle wszyscy zaczęli używać bardzo zaawansowanej graficznie strony internetowej lub oglądać jakiś film instruktarzowy ze szkolenia e-learning. Czy automat podoła i zareaguje odpowiednio szybko? Pewnie tak po dwóch minutach już wie, że obciążenie wzrasta, po dziesięciu dodatkowe 100 serwerów działa w produkcji i równomiernie rozkłada ruch użytkowników. A co jak braknie zasobów fizycznych serwerów w naszym Centrum Danych? Tu zawsze mamy zapas wolne miejsce cały czas czeka na wykorzystanie. W niezależnych centrach danych, połączonych z naszymi systemami w tzw. hybrydę, mamy tyle mocy ile potrzebujemy. Ta Hybryda to dwie lub więcej połączone ze sobą chmury obliczeniowe np. Publiczna i Prywatna, które potrafią współdziałać między sobą. Ten nowy pomysł, wdrożony w tym roku, daje praktycznie nieograniczoną skalowalność i czas na zakup sprzętu do naszego prywatnego ogródka, a z drugiej strony zapewnia pełne bezpieczeństwo w sytuacjach krytycznych. Było z tym bardzo dużo problemów prawnych, ale ostatecznie nowe przepisy UE przełożyły się na regulacje KNF. W efekcie tych zmian pozwoliło to na uruchomienie podobnych usług na szerszą skalę i bardzo dobrze dane są bezpieczne, a ja mam spokojną głowę. Godzina 7:30 Czas na drugą kawę Do 9:00 muszę przygotować kolejny automat monitorujący dla aplikacji. Prosta sprawa: czasami systemy lub aplikacje odmawiają posłuszeństwa, ale potrafią to zgłosić. Wystarczy, że aplikacja/system powie mi, że ma problem i zapisze tą informację w logach serwera. Mam gotowy scenariusz działań, które muszą być zrealizowane by błąd wyprowadzić lub czasami po prostu zgłosić do opiekuna. Przecież nikt nie będzie tego robił ręcznie i oglądał tysięcy wpisów w logach. Czasami jest to zestawienie ze sobą kilku błędów i scenariuszy, w zależności od kolejności występowania i w takim przypadku nazywam to Paczką Zarządzającą. Znane błędy będą wyprowadzone w kolejnym release aplikacyjnym. Czasami jest potrzeba szczegółowego zaraportowania ich występowania w zależności od akcji, które wykonuje użytkownik na aplikacji, a czasami proste obejście - przeładowanie jakiegoś procesu może pomóc. Musi to być zrobione zaraz po wystąpieniu błędu, tak by użytkownik tego nie zauważył człowiek jest zbyt wolny do przeprowadzenia takich operacji a moja Paczka Zarządzająca wyłapie, co się dzieje, uruchomi odpowiednie akcje i jeszcze zaraportuje w postaci zestawienia łatwego do analizy. Przekonałem się, że w wymyślaniu scenariuszy ogranicza nas tylko wyobraźnia. Im więcej awarii i problematycznych sytuacji uda się przewidzieć i przygotować dla nich automaty, tym mniej mamy problemów w bieżącej pracy. W przygotowaniu automatów pomaga mi dwóch gości jeden ma na imię Orchestrator, drugi SCOM, obaj są z rodziny produktów Microsoft System Center SCOM monitoruje, Orchestrator wykonuje akcje, które wymyśliłem. Jak na rodzinę przystało jest tam jeszcze szef serwisu tzw. Service manager, dzięki któremu nasi administratorzy i developerzy mogą w prosty sposób zażądać nowych serwerów lub całych środowisk aplikacyjnych, założyć użytkownika, czy poprosić o wyższe

3 uprawnienia. Mamy jeszcze moduły do dystrybucji oprogramowania SCCM i moduł do zarządzania wirtualnymi maszynami VMM. Całość, jak na scentralizowany system przystało, wie wszystko o wszystkim dzięki zintegrowanej bazie zasobów CMDB. Ta baza, jak wielki brat, ma policzone rdzenie w procesorach, wentylatory w serwerach, a nawet wie, kto co i kiedy instalował na swoim laptopie. Strach się bać, jaka wiedza tam jest. Ale jakie to daje możliwości analizy, porównywania, sprawdzania oraz wymyślania scenariuszy! Godzina 8:50 Mój automat już działa A może by tak w przyszłości zastosować jakiś moduł sztucznej inteligencji, który analizuje przypadki zaobserwowane na środowisku i ucząc się proponuje gotowe rozwiązania lub makra automatyzujące. Wyobraźmy sobie, że moduł taki analizuje scenariusze pracy użytkowników parametry systemów i samodzielnie podejmuje akcje przecież awarię na bazie symptomów jesteśmy w stanie wykryć już dużo wcześniej. Czasami wystarczy informacja o wydłużeniu czasów odpowiedzi procesu lub po prostu wzrost temperatury układów w serwerze. Skorelowanie tego chociażby z ilością nerwowych kliknięć zdesperowanych użytkowników da nam info, że cos jest nie tak. - chyba za bardzo wychodzę w przyszłość ;-) ale analiza kilometrów przejechanych myszką już dawno świadczy o ergonomii bądź jej braku w aplikacjach czy stronach internetowych a kliknięcia czy zmiany ekranów to cenny czas. Scenariusz, kiedy uszkodzona aplikacja bądź serwer sam powiadomi użytkownika, że jest wymagana dodatkowa akcja np. przelogowanie lub spokojne oczekiwanie na przywrócenie sesji jest już dziś możliwy do realizacji jak to znacząco może ograniczyć liczbę telefonów do Service Desk u. Przecież wystarczy, że dostanę SMS a czekaj serwer uszkodzony za 2 minuty sesja odnowi się na nowym. Mogę iść zrobić kawę lub zagadywać zdenerwowanego klienta opowiadaniem o nowych ofertach. Godzina 10:30 Przygotowanie raportów kosztowych Nic nie może zaistnieć w naszej chmurze bez akceptacji kosztowej. Każda aplikacja, to stojący za nią faktyczny budżet, który jest po części dedykowany dla infrastruktury. Dobry monitoring przydzielania zasobów z jednoczesnym przypisaniem do aplikacji daje komfort szybkiego raportowania kosztów. W każdej chwili opiekun, czy właściciel aplikacji wie ile kosztował go dany serwer lub przestrzeń na dyskach macierzy. Może to szybko skorelować np. z ilością transakcji. Czy to nie piękne, że możemy dokładnie policzyć ile kosztuje nas jedna operacja w aplikacji? Ile kosztuje nas środowisko testowe albo np. zwiększenie przestrzeni ze względu na przyrost danych. Wszystko jest raportowane automatycznie z informacji przechowywanych przez bazę CMDB i driver ów, które wcześniej zostały zdefiniowane dla różnego typu standardów. Wiem ile średnio kosztuje mnie serwer, ile kosztuje 1 GB RAM lub 1 GB dysku na różnych macierzach. Szacowanie kosztów backup u także nie stanowi problemu. Wiedząc ile kosztuje oprogramowanie, potrafię w szybki sposób opracować kosztorys dla nowego projektu. Nie muszę używać ekstra kalkulatorów. Wystarczy, że wejdę na stronę intranetową do zamawiania nowych środowisk aplikacyjnych. Prosty kreator pozwala mi wybrać typ środowiska, systemy ze standardu, bazy danych czy serwery aplikacyjne Wszystko mogę wyskalować według moich potrzeb, a w przyszłości samodzielnie rozszerzyć. Kliknięcie w przycisk przelicz podsumuje koszty, a jeżeli chcę zamówić, to co wyliczyłem po kolejnym kliknięciu rozpocznie się proces akceptacji kosztowej u moich przełożonych. Najważniejsze, że takie zamówienia i szacowania mogą robić wszyscy zaangażowani w proces budowy lub opieki nad aplikacjami - projektanci i programiści w IT oraz grupy twórców które przygotowują narzędzia EUC Skraca to do minimum czas niezbędny do stania się właścicielem nowego serwera, na którym możemy zacząć pracę, skończyć ją w klika godzin, przekazać do produkcji i zwolnić już niepotrzebne zasoby.

4 Rachunek przyjdzie pocztą ;-) ale nikt nie będzie zaskoczony szefowie wszystko wiedzą Godzina 13:45 Do oddziałów przychodzi druga zmiana obserwuję chwilowy wzrost obciążenia, a potem spadek. Automat uznał, że nie ma potrzeby dodawać nowych serwerów. Wczoraj był 25 ostatni termin płatności podatku VAT było to widać we wzmożonym ruchu aplikacyjnym klientów internetowych automat zareagował, dostawił dwa kolejne serwery aplikacyjne w DMZ podpoił je do cluster a oraz powiększył zasoby na serwerze bazy danych. Godzina 15:25 Koniec zmiany, a tu nagle pojawia się kilka czerwonych wpisów w rejestrze logów zawieszone procesy? Coś jest nie tak z 20 serwerami wirtualnymi obserwuję, co się dzieje Uszkodzenie modułów pamięci w serwerze fizycznym!!! Mój zmiennik już jest uspokaja mnie, będzie OK - automaty działają Jeszcze nie doświadczyłem osobiście takiej sytuacji. Na konsoli widać jak serwery wirtualne zaczynają samodzielnie przenosić się na działające zasoby innego serwera w chmurze. Jednocześnie system wysłał mailowe zgłoszenie do dostawcy sprzętu ja także już mam SMS a z powiadomieniem. HA High Availability W przypadku awarii hosta automatyczne uruchomienie wszystkich jego maszyn wirtualnych na pozostałych działających (w danym klastrze) hostach. Godzina 16:00 Telefon z serwisu - Administratorzy prywatnej chmury ING Banku Śląskiego? - Tak. - Za dwie godziny będzie nowy serwer na podmianę. Czy wszystko jest OK? - Tak, chmura działa poprawnie. - ;-) Godzina 16:05 Koniec zmiany 26 Marzec, 2016 rok ;-) Autor: Michał Jurga, ING Bank Śląski

5 Uwaga: Powyższy artykuł przedstawia wizję automatyzacji procesów IT w ING Banku Śląskim (wersja optymistyczna). Główna część obecnie toczącego się projektu zakończy się w marcu 2016r. Wprowadzenie niektórych opisanych rozwiązań będzie wymagało dalszych analiz i prac czy dostępności jeszcze bardziej zaawansowanych technologii. Czy wiesz, że ING Bank Śląski jest jedną z największych firm informatycznych w Polsce? Sprawdź nasze oferty pracy w obszarze IT i