V první části jsme hovořili o tom, proč jsme se rozhodli vyměnit náš starý BMS systém v našich datových centrech za nový. A nejen vyměnit, ale vyvinout jej od základů podle svých požadavků. Ve druhé části vyprávíme, jak jsme to dělali.
Analýza trhu
S ohledem na uvedené předpoklady a rozhodnutí vzdát se aktualizace stávajícího systému jsme vypracovali technickou specifikaci pro hledání řešení na trhu a zaslali žádosti několika velkým společnostem, které se specializují pouze na vývoj průmyslových SCADA systémů.
První odpovědi od nich ukázaly, že lídři trhu monitorovacích systémů převážně stále pracují na fyzických serverech, i když proces migrace do cloudu v tomto segmentu již začal. Co se týče zajištění virtuálních strojů – tuto možnost nikdo nepodporoval. Navíc se zdálo, že žádný z významných vývojářů v oboru ani neprojevil pochopení pro potřebu zajištění: "alespoň cloud nespadne" byl nejčastější odpovědí. V podstatě nám nabízeli umístit monitoring datového centra do cloudu, který se fyzicky nachází ve stejném datovém centru.
Tady je potřeba udělat malou odbočku k procesu výběru dodavatele. Cena samozřejmě hraje roli, ale během jakéhokoli tendru na realizaci složitého projektu, ve fázi dialogu s dodavateli, začínáš mít pocit, kdo z kandidátů je více zainteresovaný a schopen ho realizovat.
To je obzvlášť patrné u složitých projektů.
Podle povahy doplňujících otázek k technické specifikaci lze dodavatele rozdělit na ty, kteří mají zájem pouze prodat (cítí se standardní tlak prodejního manažera) a ty, kteří mají zájem o vývoj produktu, naslouchají a rozumí zákazníkovi, provádějí konstruktivní úpravy technické specifikace již před finálním výběrem (i přes skutečné riziko zlepšit něčí technickou specifikaci a prohrát tender), a nakonec jednoduše ti, kteří jsou připraveni přijmout profesionální výzvu a vytvořit kvalitní produkt.
To vše nás přimělo věnovat pozornost relativně malému místnímu vývojáři – skupině společností "Sanline", která okamžitě reagovala na většinu našich požadavků a byla ochotna realizovat všechny potřeby týkající se nového BMS.
Rizika
Zatímco velcí hráči se snažili pochopit, co vlastně chceme, a vedli s námi pomalou korespondenci, do které zapojili specialisty na úrovni presales, místní vývojář si domluvil schůzku v naší kanceláři s účastí svého technického týmu. Na této schůzce dodavatel znovu prokázal zájem účastnit se projektu a - což je nejdůležitější - vysvětlil, jak bude požadovaný systém realizován.
Před schůzkou jsme identifikovali dvě rizika spolupráce s týmem, který nemá za sebou zdroje velké národní nebo mezinárodní společnosti:
- Specialisté mohli přecenit své možnosti a v důsledku toho se prostě nezvládnout, například použijí složitý software nebo navrhnou neproveditelné algoritmy rezervace.
- Po realizaci projektu se projektový tým může rozpadnout a tím pádem podpora produktu bude ohrožena.
Abychom minimalizovali tato rizika, pozvali jsme na schůzku naše vlastní specialisty na vývoj. Zaměstnanci potenciálního dodavatele byli důkladně dotazováni na to, na čem systém staví, jak plánují realizaci rezervací a na další otázky, v nichž nejsme jako provozní služba dostatečně kompetentní.
Verdikt byl pozitivní: architektura již existující platformy BMS je moderní, jednoduchá a spolehlivá, může být upravená, navrhovaná schéma rezervace a synchronizace je logická a funkční.
S prvním rizikem jsme se vypořádali. Druhé jsme vyloučili, když jsme od dodavatele získali potvrzení o ochotě předat nám zdrojové kódy systému a dokumentaci, a také jsme vybrali programovací jazyk Python, s nímž jsou naši specialisté dobře obeznámeni. To nám zaručilo možnost udržovat systém vlastními silami bez jakýchkoli obtíží a dlouhého období školení zaměstnanců v případě opuštění trhu společností vyvíjející software.
Další výhodou platformy bylo, že byla realizována v kontejnerech Docker: v tomto prostředí fungují jádro, webové rozhraní a databáze produktu. Tento přístup nabízí řadu výhod, včetně přednastavení konfigurací pro nejvyšší rychlost nasazení řešení ve srovnání s "klasikou" a snadné přidávání nových zařízení do systému. Princip „všechno dohromady“ maximálně zjednodušuje implementaci systému: stačí systém rozbalit a lze ho okamžitě používat.
S tímto řešením je jednodušší vytvářet záložní kopie systému, a jeho vylepšení a realizaci aktualizací lze provádět v odděleném prostředí, bez přerušení provozu celého řešení.
Poté, co byly oba rizika minimalizována, dodavatel poskytl cenovou nabídku. Ta zpracovala všechny pro nás nejdůležitější parametry systému BMS.
Zálohování
Nový systém BMS měl být umístěn v cloudu, na virtuálním stroji.
Žádný hardware, žádné servery a všechny související nepohodlí a rizika s tímto modelem nasazení – cloudové řešení nám umožnilo se jich navždy zbavit. Bylo rozhodnuto, že systém bude fungovat v našem cloudu na dvou místech datového centra v Petrohradu a Moskvě. Jsou to dva plně funkční systémy, které pracují v režimu active standby s přístupem pro všechny autorizované specialisty.
Dva systémy se navzájem zabezpečují, zajišťují plnou rezervu jak po výpočetním výkonu, tak po kanálech přenosu dat. Také byly nastaveny další bezpečnostní opatření, včetně zálohování dat a kanálů, systémů a virtuálních strojů jako celku, a samostatné měsíční zálohování databáze (nejcennější zdroj z pohledu správy a analýzy).
Je třeba poznamenat, že zálohování jako volba řešení BMS bylo vyvinuto speciálně na základě naší poptávky. Samotný schéma zálohování vypadala takto:
Podpora
Nejdůležitější aspekt pro efektivní provoz řešení BMS – technická podpora.
Tady je to jednoduché: nový systém by nás v tomto ohledu stál 35 000 Kč měsíčně za SLA „reakce do 8 hodin“, což je 35 000 x 12 / 80 = 5 250 $ ročně. První rok je zdarma.
Pro srovnání: podpora starého BMS od dodavatele stála 18 000 dolarů ročně s navyšováním částky za každé nové přidané zařízení! Společnost však neposkytovala dedikovaného manažera, veškerá komunikace probíhala přes obchodního zástupce, který byl zainteresován v našem případě jako v potenciálním zákazníkovi s odpovídajícím důrazem na zpracování požadavků.
Za méně peněz jsme získali plnou podporu produktu, s account managerem, který se podílel na vývoji produktu, s jediným vstupním bodem atd. Podpora se stala výrazně flexibilnější – díky přímému přístupu k vývojářům pro rychlé úpravy v jakýchkoli aspektech fungování systému, integraci přes API atd.
Aktualizace
Podle navrhované nabídky v novém BMS jsou všechny aktualizace zahrnuty v ceně podpory, tj. nevyžadují další platbu. Výjimku tvoří vývoj dodatečné funkčnosti nad rámec toho, co je uvedeno v Technickém zadání.
Starý systém předpokládal platbu jak za aktualizaci vestavěného bezplatného softwaru (například Java), tak za opravy chyb. Odmítnout to nebylo možné, při absenci aktualizací systém celkově ‚brzdil‘ kvůli starým verzím interních komponentů.
A samozřejmě nebylo možné aktualizovat software bez nákupu podpůrného balíčku.
Flexibilní přístup
Další zásadní požadavek se týkal rozhraní. Chtěli jsme zajistit přístup k němu přes webový prohlížeč z libovolného místa, bez povinné přítomnosti technika na území datového centra. Kromě toho jsme usilovali o vytvoření animovaného rozhraní, aby byla dynamika fungování infrastruktury přehlednější pro dispečerské inženýry.
Také v novém systému bylo nutné zajistit podporu vzorců pro výpočet práce virtuálních senzorů v inženýrských systémech – například pro optimální rozdělení elektrických výkonů mezi stojany s vybavením. K tomu je třeba mít k dispozici všechny běžné matematické operace aplikovatelné na ukazatele senzorů.
Dále byla potřeba přístup k databázi SQL, která by umožnila získávat potřebná data o provozu zařízení – konkrétně všechny záznamy o monitorování dvou tisíc zařízení a dvou tisíc virtuálních senzorů, generujících přibližně 20 tisíc proměnných.
Také byl potřeba modul pro evidenci zařízení v racku, který by poskytoval grafické zobrazení umístění zařízení v každé jednotce s výpočtem celkové hmotnosti „železa“, vedením knihovny zařízení a podrobnými informacemi o každém prvku.
Schválení technické specifikace a podpis smlouvy
V době, kdy bylo nezbytné začít pracovat na novém systému, byla korespondence s „velkými“ společnostmi stále velmi daleko od diskuse o ceně jejich nabídek, proto jsme porovnali obdrženou nabídku s náklady na aktualizaci staré BMS (viz. ), a výsledek se ukázal být cenově výhodnější a odpovídající našim požadavkům.
Byl učiněn výběr.
Po výběru dodavatele začali právníci sepisovat smlouvu a technické týmy z obou stran vypracovávat technickou specifikaci. Jak je známo, podrobná a správně formulovaná technická specifikace je základem úspěchu jakékoli práce. Čím více konkrétních informací v technické specifikaci, tím méně zklamání, jako například „my jsme chtěli jinak“.
Uvedu dva příklady úrovně detailnosti požadavků v technické specifikaci:
- Operační centra datových center mají pravomoc přidávat nová zařízení do BMS, nejčastěji se jedná o PDU. Ve staré BMS to byla úroveň „administrátora“, která také umožňovala měnit nastavení proměnných všech zařízení, a rozdělení funkcí bylo nemožné. To nám nevyhovovalo. Ve stávající základní verzi nové platformy byla schéma obdobná. Okamžitě jsme uvedli do technické specifikace, že chceme rozdělit tyto role: nastavení by měl měnit pouze oprávněný zaměstnanec, ale operačníci by měli i nadále mít možnost přidávat zařízení. Tento schéma byla přijata k realizaci.
- V každém standardním BMS existují tři typové kategorie upozornění: ČERVENÁ – je třeba okamžitě reagovat, ŽLUTÁ – lze sledovat, MODRÁ – „Informační“. Tradičně jsme používali „modrá“ upozornění pro sledování překročení obchodních parametrů, například překročení limitu výkonu skříně zákazníka. Tento typ upozornění byl v našem případě určen manažerům a nebyl zajímavý pro provozní službu, ale ve starém BMS pravidelně zahlcoval seznam aktivních incidentů a bránil operativní práci. Samotnou logiku a barevné diferencování upozornění jsme považovali za úspěšné a zachovali jsme ji, ovšem v technické specifikaci jsme speciálně uvedli, že „modrá“ upozornění by měla, aniž by rozptylovala pohotovostní personál, tiše „padat“ do samostatné sekce, kde se jimi budou zabývat obchodní specialisté.
S obdobnou mírou podrobnosti byly stanoveny formáty pro vytváření grafů a generování reportů, obrysy rozhraní, seznam zařízení, která bylo třeba sledovat, a také množství dalších věcí.
Byla to skutečně tvůrčí práce tří pracovních skupin – služby objednatele, která diktovala své požadavky a podmínky; technických specialistů z obou stran, jejichž úkolem bylo převést tyto podmínky do technické dokumentace; týmu programátorů dodavatele, kteří realizovali požadavky objednatele podle vypracované technické dokumentace... Nakonec jsme některé z našich méně zásadních požadavků přizpůsobili funkčnosti již existující platformy, něco dodavatel slíbil doplnit pro nás.
Paralelní provoz dvou systémů
Nastal čas realizace. V praxi to znamenalo, že dáváme dodavateli možnost nasadit prototyp BMS v našem virtuálním cloudu a poskytujeme síťový přístup ke všem zařízením, která vyžadují sledování.
Nový systém však ještě nebyl připraven k provozu. V tomto okamžiku bylo pro nás důležité zachovat sledování ve starém systému a zároveň poskytnout přístup k zařízením novému systému. Není možné normálně vybudovat systém, aniž bychom viděli v něm zařízení, která nelze odpojit od sledování starým systémem.
Bylo nejasné, zda zařízení zvládnou současný dotaz od dvou systémů bez skutečných testů. Existovala pravděpodobnost, že dvojí současný dotaz povede k častým selháním odpovědí od zařízení a my obdržíme množství chyb kvůli nedostupnosti zařízení, což naopak zablokuje fungování starého monitorovacího systému.
Síťové oddělení zprovoznilo virtuální trasy od prototypu nové BMS nasazené v cloudu k zařízením, a my jsme získali výsledky:
- zařízení připojená prostřednictvím protokolu SNMP téměř nevypadávala z připojení kvůli současným požadavkům,
- zařízení připojená přes brány pomocí protokolů modbus-TCP měla problémy, které byly vyřešeny rozumným snížením frekvence jejich dotazování.
A pak jsme začali sledovat, jak se před našima očima buduje nový systém, v němž se objevují nám už známá zařízení, ale v jiném rozhraní – pohodlném, rychlém, dostupném i z telefonu.
O tom, co se nakonec podařilo, se zmíníme ve třetí části našeho článku.
Zdroj: habr.com
