W pierwszej części opowiedzieliśmy, dlaczego zdecydowaliśmy się na wymianę starego systemu zarządzania budynkami (BMS) w naszych centrach danych na nowy. I to nie tylko wymianę, ale opracowanie go od podstaw zgodnie z naszymi wymaganiami. W drugiej części przedstawiamy, jak to robiśmy.
Analiza rynku
Uwzględniając opisane w życzenia i decyzję o rezygnacji z aktualizacji istniejącego systemu, napisaliśmy specyfikację wymagań w celu poszukiwania rozwiązania na rynku i wysłaliśmy zapytania do kilku dużych firm, zajmujących się wyłącznie tworzeniem przemysłowych systemów SCADA.
Pierwsze odpowiedzi od nich pokazały, że liderzy rynku systemów monitorowania głównie nadal pracują na serwerach fizycznych, chociaż proces migracji do chmury w tym segmencie już się rozpoczął. Jeśli chodzi o rezerwację maszyn wirtualnych – ta opcja nie była wspierana przez nikogo. Co więcej, można było odnieść wrażenie, że nikt z zauważalnych na rynku deweloperów nawet nie rozumiał potrzeby rezerwacji: „chmura przecież się nie zawiesza” był najczęstszą odpowiedzią. Faktycznie proponowano nam umieścić monitoring centrum danych w chmurze, fizycznie znajdującej się w tym samym centrum danych.
Tutaj warto zrobić małe odchylenie dotyczące procesu wyboru wykonawcy. Cena, oczywiście, ma znaczenie, ale podczas każdego przetargu na realizację skomplikowanego projektu, na etapie dialogu z dostawcami zaczynasz odczuwać, kto z kandydatów jest bardziej zainteresowany i zdolny do jego realizacji.
Jest to szczególnie widoczne w skomplikowanych projektach.
Ze względu na charakter уточняющих pytania do specyfikacji wymagań można podzielić wykonawców na tych, którzy są zainteresowani jedynie sprzedażą (widać standardowy nacisk menedżera sprzedaży) oraz na tych, którzy są zainteresowani opracowaniem produktu, słuchając i rozumiejąc zamawiającego, wprowadzając konstruktywne poprawki w specyfikacji jeszcze przed ostatecznym wyborem (nawet pomimo rzeczywistego ryzyka poprawienia cudzego wymagania i przegrania przetargu), w końcu gotowych przyjąć profesjonalne wyzwanie i stworzyć dobry produkt.
Wszystko to skłoniło nas do zwrócenia uwagi na stosunkowo małego lokalnego dewelopera – grupę firm „Sanline”, która natychmiast odpowiedziała na większość naszych wymagań i była gotowa zrealizować wszystkie potrzeby związane z nowym systemem BMS.
Ryzyka
Podczas gdy duzi gracze próbowali zrozumieć, czego chcemy, i prowadzili z nami powolną korespondencję z udziałem specjalistów na poziomie presales, lokalny deweloper umówił spotkanie w naszym biurze z udziałem swojego zespołu technicznego. Na tym spotkaniu wykonawca po raz kolejny wyraził chęć uczestnictwa w projekcie i – co najważniejsze – wyjaśnił, jak wymagany system będzie wdrożony.
Przed spotkaniem dostrzegliśmy dwa ryzyka związane z pracą z zespołem, który nie ma za sobą zasobów dużej krajowej lub międzynarodowej firmy:
- Specjaliści mogli przeszacować swoje możliwości i w efekcie po prostu nie poradzić sobie, na przykład będą korzystać ze skomplikowanego oprogramowania lub zaprojektują niewykonalne algorytmy rezerwacji.
- Po realizacji projektu zespół projektu może się rozpaść, a tym samym wsparcie produktu znajdzie się w niebezpieczeństwie.
Aby zminimalizować te ryzyka, zaprosiliśmy na spotkanie naszych specjalistów ds. rozwoju. Pracownicy potencjalnego wykonawcy zostali dokładnie przesłuchani w zakresie tego, na czym oparta jest system, jak planowane jest wdrażanie rezerwacji oraz w innych kwestiach, w których my, jako służba eksploatacji, nie jesteśmy wystarczająco kompetentni.
Werdykt był pozytywny: architektura istniejącej już platformy BMS jest nowoczesna, prosta i niezawodna, może być rozwijana, proponowany schemat rezerwacji i synchronizacji jest logiczny i funkcjonalny.
Z pierwszym ryzykiem sobie poradziliśmy. Drugie wykluczyliśmy, otrzymując od wykonawcy potwierdzenie gotowości przekazania nam źródła kodu systemu oraz dokumentacji, a także wybierając język programowania Python, dobrze znany naszym specjalistom. To zapewniło nam możliwość samodzielnego wsparcia systemu bez jakichkolwiek trudności i długiego okresu szkolenia pracowników w przypadku wycofania się firmy dewelopera z rynku.
Dodatkową zaletą platformy było to, że została zrealizowana w kontenerach Docker: w tym środowisku działają jądro, interfejs webowy i baza danych produktu. Takie podejście oferuje wiele korzyści, w tym wstępne ustawienia, które zapewniają najwyższą prędkość wdrożenia rozwiązania w porównaniu do „klasyki” oraz łatwe dodawanie nowych urządzeń do systemu. Zasada „wszystko razem” maksymalnie upraszcza wdrażanie systemu: wystarczy rozpakować system, aby od razu można było go używać.
Z takim rozwiązaniem łatwiej jest robić kopie systemu, a udoskonalanie go oraz wprowadzanie aktualizacji można realizować w oddzielnym środowisku, bez zatrzymywania pracy rozwiązania jako całości.
Po zminimalizowaniu obu ryzyk, wykonawca dostarczył ofertę. Zawierała ona wszystkie najważniejsze dla nas parametry systemu BMS.
Rezerwa
Nowy system BMS miał znajdować się w chmurze, na maszynie wirtualnej.
Brak sprzętu, brak serwerów i wszelkich związanych z tym niedogodności i ryzyk – chmurowe rozwiązanie pozwoliło nam z nich zrezygnować na zawsze. Postanowiono, że system będzie działał w naszej chmurze na dwóch lokalizacjach centrum danych w Petersburgu i Moskwie. To dwa w pełni funkcjonalne systemy działające w trybie active standby z dostępem dla wszystkich autoryzowanych specjalistów.
Oba systemy wzajemnie się zabezpieczają, zapewniając pełny zapas zarówno mocy obliczeniowej, jak i kanałów transmisji danych. Ustawiono także dodatkowe środki bezpieczeństwa, w tym kopie zapasowe danych i kanałów, systemów, maszyn wirtualnych jako całości oraz osobne kopie zapasowe baz danych raz w miesiącu (najcenniejszy zasób w perspektywie zarządzania i analizy).
Warto zauważyć, że opcja rezerwacji w rozwiązaniu BMS została opracowana specjalnie na nasze potrzeby. Schemat rezerwacji wyglądał następująco:
Wsparcie
Najważniejszym punktem efektywnej eksploatacji rozwiązania BMS jest wsparcie techniczne.
Tutaj wszystko jest proste: nowy system kosztowałby nas w tym wymiarze 35 000 rubli miesięcznie za SLA „reakcja w ciągu 8 godzin”, czyli 35 000 x 12 / 80 = 5 250 USD rocznie. Pierwszy rok – za darmo.
Dla porównania: wsparcie starego BMS od dostawcy kosztowało 18 000 dolarów rocznie, z rosnącą kwotą za każde nowe urządzenie! Równocześnie firma nie zapewniała dedykowanego menedżera, całe взаимодействие odbywało się przez menedżera sprzedaży, który był zainteresowany nami jako potencjalnym klientem, z odpowiednim akcentem przy przetwarzaniu zapytań.
Za mniejsze pieniądze otrzymaliśmy pełne wsparcie produktu, z menedżerem konta, który brałby udział w rozwoju produktu, z jedną wspólną wtyczką itp. Wsparcie stało się znacznie bardziej elastyczne – dzięki bezpośredniemu dostępowi do programistów na szybkie korekty w dowolnych aspektach działania systemu, integracji przez API itp.
Aktualizacje
W zaproponowanej ofercie w nowej BMS wszystkie aktualizacje są wliczone w koszt wsparcia, tzn. nie wymagają dodatkowej opłaty. Wyjątek stanowi opracowanie dodatkowej funkcjonalności, ponad tę, która jest określona w specyfikacji.
Stary system wymagał płatności zarówno za aktualizacje wbudowanego, darmowego oprogramowania (typowo Java), jak i za poprawki błędów. Nie można było z tego zrezygnować, a brak aktualizacji powodował, że system ogółem „spowalniał” z powodu starych wersji wewnętrznych komponentów.
I oczywiście nie można było zaktualizować oprogramowania bez zakupu pakietu wsparcia.
Elastyczne podejście
Kolejnym kluczowym wymaganiem dotyczyło interfejsu. Chcieliśmy zapewnić dostęp do niego przez przeglądarkę internetową z dowolnego miejsca, bez obowiązkowej obecności inżyniera na terenie Centrum Danych. Ponadto dążyliśmy do stworzenia animowanego interfejsu, aby dynamika działania infrastruktury była bardziej widoczna dla inżynierów dyżurnych.
W nowym systemie należało również zapewnić wsparcie dla formuł do obliczania działania wirtualnych czujników w systemach inżynieryjnych – na przykład do optymalnego rozdziału mocy elektrycznych na stojaki z urządzeniami. W tym celu należy mieć w swoim zasięgu wszystkie znane operacje matematyczne, stosowane do wskaźników czujników.
Następnie wymagany był dostęp do bazy danych SQL, umożliwiający pobieranie potrzebnych danych o pracy urządzeń – a mianowicie, wszystkich zapisów dotyczących monitorowania dwóch tysięcy urządzeń i dwóch tysięcy wirtualnych czujników, generujących około 20 tysięcy zmiennych.
Potrzebny był również moduł monitorowania urządzeń w szafie rackowej, który zapewnia graficzną reprezentację rozmieszczenia urządzeń w każdej jednostce, z obliczeniem całkowitej wagi sprzętu, prowadzeniem biblioteki urządzeń oraz szczegółowymi informacjami o każdym elemencie.
Zatwierdzenie specyfikacji i podpisanie umowy
Kiedy nadszedł czas na rozpoczęcie pracy nad nowym systemem, rozmowy z "dużymi" firmami były nadal bardzo dalekie od dyskusji na temat kosztów ich ofert, dlatego porównaliśmy otrzymaną ofertę z kosztami zaktualizowania starego BMS (zob. ), a w rezultacie okazała się ona bardziej atrakcyjna cenowo i odpowiadająca naszym wymaganiom.
Dokonano wyboru.
Po wyborze wykonawcy prawnicy rozpoczęli przygotowanie umowy, a zespoły techniczne z obu stron szlifowały specyfikację. Jak wiadomo, szczegółowa i poprawna specyfikacja jest podstawą sukcesu wszelkich prac. Im więcej konkretów w specyfikacji, tym mniej rozczarowań, takich jak „a my chcieliśmy inaczej”.
Podam dwa przykłady poziomu szczegółowości wymagań w specyfikacji:
- Dyżurni w centrum danych mają uprawnienia do dodawania nowych urządzeń do BMS, najczęściej są to PDU. W starym BMS istniał poziom „administratora”, który pozwalał m.in. na zmianę ustawień zmiennych wszystkich urządzeń, a podział funkcji był niemożliwy. Nie odpowiadało nam to. W istniejącej wersji bazowej nowej platformy schemat był analogiczny. Od razu w specyfikacji wskazaliśmy, że chcemy podzielić te role: ustawienia powinien zmieniać tylko upoważniony pracownik, ale dyżurni powinni nadal mieć możliwość dodawania urządzeń. Taki schemat został przyjęty do realizacji.
- W każdej standardowej BMS znajdują się trzy typowe kategorie powiadomień: CZERWONE – należy natychmiast zareagować, ŻÓŁTE – można obserwować, NIEBIESKIE – „Informacyjne”. Tradycyjnie używaliśmy „niebieskich” powiadomień do monitorowania przekroczenia parametrów komercyjnych, takich jak przekroczenie limitu mocy szafy klienta. Ten typ powiadomień w naszym przypadku był przeznaczony dla menedżerów i nie interesował służby eksploatacji, ale w starej BMS regularnie zatykał listę aktywnych incydentów i przeszkadzał w pracy operacyjnej. Samą logikę i kolorową różnicę powiadomień uznaliśmy za udane i zachowaliśmy, jednak w specyfikacji technicznej zaznaczyliśmy, że „niebieskie” powiadomienia powinny, nie rozpraszając dyżurnych, cicho „sypać” się do oddzielnej sekcji, gdzie zajmą się nimi specjaliści komercyjni.
Z podobnym poziomem szczegółowości określono formaty budowy wykresów i generowania raportów, zarysy interfejsów, listę urządzeń, które trzeba było monitorować oraz wiele innych rzeczy.
To była naprawdę kreatywna praca trzech grup roboczych – służby zamawiającego, która narzucała swoje wymagania i warunki; specjalistów technicznych z obu stron, których zadaniem było przekształcenie tych warunków w dokumentację techniczną; zespołu programistów wykonawcy, którzy wdrażali wymagania zamawiającego zgodnie z opracowaną dokumentacją techniczną... W rezultacie część naszych niekluczowych wymagań dostosowaliśmy do funkcjonalności już istniejącej platformy, a coś wykonawca zobowiązał się dopisać dla nas.
Równoległa praca dwóch systemów
Nadszedł czas realizacji. W praktyce oznaczało to, że dajemy wykonawcy możliwość uruchomienia prototypu BMS w naszej wirtualnej chmurze oraz zapewniamy dostęp sieciowy do wszystkich urządzeń wymagających monitorowania.
Jednocześnie nowy system nie był jeszcze gotowy do pracy. Na tym etapie ważne było dla nas zachowanie monitorowania w starym systemie i jednoczesne udostępnienie urządzeń nowemu systemowi. Nie można normalnie zbudować systemu, nie widząc w nim urządzeń, które z kolei nie mogą być odłączone od monitorowania starego systemu.
Czy urządzenia wytrzymają jednoczesne zapytania z dwóch systemów, nie było oczywiste bez rzeczywistych prób. Istniało ryzyko, że podwójne jednoczesne zapytania doprowadzą do częstych odmów odpowiedzi od urządzeń, a to skutkowałoby licznymi błędami związanymi z niedostępnością urządzeń, co z kolei zablokowałoby działanie starego systemu monitorowania.
Dział sieciowy podłączył wirtualne trasy od prototypu nowej BMS wdrożonej w chmurze do urządzeń, a my otrzymaliśmy wyniki:
- urządzenia podłączone przez protokół SNMP praktycznie nie były odłączane z powodu jednoczesnych zapytań,
- urządzenia podłączone przez bramy według protokołów modbas-TCP miały problemy, które zostały rozwiązane przez rozsądne obniżenie częstotliwości ich zapytań.
A następnie zaczęliśmy obserwować, jak na naszych oczach powstaje nowy system, w którym pojawiają się już znane nam urządzenia, ale w innym interfejsie – wygodnym, szybkim, dostępnym nawet z telefonu.
O tym, co udało się osiągnąć w końcu, opowiemy w trzeciej części naszego artykułu.
Źródło: habr.com
