V prvním díle jsme si řekli, proč jsme se rozhodli vyměnit starý BMS systém v našich datových centrech za nový. A nejen měnit, ale vyvíjet se od nuly, aby vyhovoval vašim požadavkům. V druhé části vám řekneme, jak jsme to udělali.
Analýza trhu
S přihlédnutím k těm, které jsou popsány v přání a rozhodnutí odmítnout aktualizaci stávajícího systému, sepsali jsme technickou specifikaci, abychom našli řešení na trhu a obrátili se na několik velkých společností zabývajících se pouze tvorbou průmyslových SCADA systémů.
Hned první ohlasy od nich ukázaly, že lídři trhu monitorovacích systémů primárně pokračují v práci na hardwarových serverech, i když proces migrace do cloudu v tomto segmentu již začal. Pokud jde o rezervaci virtuálních strojů, nikdo tuto možnost nepodporoval. Navíc panoval pocit, že žádný z vývojářů viditelných na trhu ani neprokázal pochopení potřeby redundance: „cloud nepadá“ byla nejčastější odpověď. Ve skutečnosti nám bylo nabídnuto umístit monitorování datového centra do cloudu fyzicky umístěného ve stejném datovém centru.
Zde musíme udělat malou odbočku k procesu výběru dodavatele. Na ceně samozřejmě záleží, ale při jakémkoli výběrovém řízení na realizaci složitého projektu, ve fázi dialogu s dodavateli, začínáte pociťovat, kdo z kandidátů má větší zájem a je schopen jej realizovat.
To je patrné zejména u složitých projektů.
Na základě povahy objasňujících otázek k technickým specifikacím lze dodavatele rozdělit na zájemce o prostý prodej (je cítit standardní tlak obchodního manažera) a zájemce o vývoj produktu, po vyslechnutí a pochopení zákazníka, konstruktivní úpravy technických specifikací ještě před konečným výběrem (i přes reálné riziko zlepšení technických specifikací někoho jiného a prohra ve výběrovém řízení), nakonec jsou prostě připraveni přijmout profesionální výzvu a vyrobit dobrý produkt.
To vše nás přimělo věnovat pozornost relativně malému lokálnímu developerovi – skupině společností Sunline, která na většinu našich požadavků reagovala okamžitě a byla připravena realizovat veškeré potřeby ohledně nového BMS.
Rizika
Zatímco se velcí hráči snažili pochopit, co chceme, a pokračovali s námi v poklidné korespondenci se specialisty na předprodejní úroveň, místní vývojář naplánoval schůzku v naší kanceláři za účasti svého technického týmu. Na této schůzce zhotovitel opět prokázal chuť se na projektu podílet a hlavně vysvětlil, jak bude požadovaný systém implementován.
Před schůzkou jsme viděli dvě rizika práce s týmem, který za sebou nemá zdroje velké národní nebo mezinárodní společnosti:
- Specialisté by mohli přecenit své schopnosti a v důsledku toho si jednoduše nezvládnout, například použít složitý software nebo navrhnout neproveditelné rezervační algoritmy.
- Po dokončení projektu se může projektový tým rozpadnout, a proto bude ohrožena podpora produktu.
Abychom tato rizika minimalizovali, pozvali jsme na jednání vlastní vývojové specialisty. Zaměstnanci potenciálního zhotovitele byli důkladně dotazováni na to, na čem je systém založen, jak se plánuje implementace redundance a další záležitosti, ve kterých nejsme jako provozní služba dostatečně kompetentní.
Verdikt byl kladný: architektura stávající platformy BMS je moderní, jednoduchá a spolehlivá, lze ji vylepšit, navržené schéma redundance a synchronizace je logické a funkční.
První riziko bylo vyřešeno. Druhý byl vyloučen po obdržení potvrzení od dodavatele, že je připraven převést zdrojový kód systému a dokumentace k nám, a také výběrem programovacího jazyka Python, který byl našim specialistům dobře známý. To nám zaručilo možnost bezproblémové vlastní údržby systému a dlouhého školení zaměstnanců v případě odchodu developerské společnosti z trhu.
Další výhodou platformy bylo, že byla implementována v kontejnerech Docker: v tomto prostředí funguje jádro, webové rozhraní a databáze produktů. Tento přístup poskytuje mnoho výhod, včetně přednastavených nastavení pro nejvyšší rychlost nasazení řešení oproti „klasickému“ a snadnému přidávání nových zařízení do systému. Princip „všichni dohromady“ maximálně zjednodušuje implementaci systému: stačí systém rozbalit a můžete jej okamžitě používat.
S tímto řešením je snazší vytvářet kopie systému a můžete jej vylepšovat a implementovat upgrady v samostatném prostředí, aniž byste zastavili provoz řešení jako celku.
Jakmile byla obě rizika minimalizována, dodavatel poskytl CP. Pokrýval pro nás všechny nejdůležitější parametry systému BMS.
Rezervace
Nový systém BMS musel být umístěn v cloudu, na virtuálním stroji.
Žádný hardware, žádné servery a všechny nepříjemnosti a rizika spojená 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 ve dvou lokalitách datových center v Petrohradě a Moskvě. Jedná se o dva plně funkční systémy pracující v aktivním pohotovostním režimu s přístupem všem autorizovaným specialistům.
Oba systémy se vzájemně pojišťují a poskytují plnou rezervu jak výpočetního výkonu, tak kanálů přenosu dat. Byla také nakonfigurována další bezpečnostní opatření, včetně zálohování dat a kanálů, systémů, virtuálních strojů obecně a samostatné zálohy databáze jednou měsíčně (nejcennější zdroj z hlediska správy a analýzy).
Všimněte si, že redundance jako možnost v řešení BMS byla vyvinuta speciálně pro náš požadavek. Samotné rezervační schéma vypadalo takto:
Podpora
Nejdůležitějším bodem pro efektivní provoz BMS řešení je technická podpora.
Zde je vše jednoduché: nový systém by nás podle tohoto ukazatele stál 35 000 rublů. za měsíc za SLA „odpověď do 8 hodin“, to znamená 35 000 x 12 / 80 = 5 250 USD za rok. První rok je zdarma.
Pro srovnání, údržba starého BMS od dodavatele stála 18 000 $ ročně s navýšením částky za každé nové přidané zařízení! Zároveň společnost nezajistila dedikovaného manažera, veškerá interakce probíhala přes obchodního manažera, který se o nás jako potenciálního kupce zajímá s odpovídajícím důrazem na zpracování poptávek.
Za méně peněz jsme dostali plnou produktovou podporu, s account managerem, který by se podílel na vývoji produktu, s jediným vstupním bodem atd. Podpora se stala mnohem flexibilnější – díky přímému přístupu k vývojářům pro rychlé úpravy jakéhokoli aspektu systému, integraci přes API atd.
Aktualizace
Dle návrhu CP v novém BMS jsou všechny aktualizace zahrnuty v ceně podpory, tzn. nevyžadují další platbu. Výjimkou je vývoj dalších funkcí nad rámec toho, co je uvedeno v technických specifikacích.
Starý systém vyžadoval platbu jak za aktualizace firmwaru (např. Java), tak za opravy chyb. To nebylo možné odmítnout, při absenci aktualizací se systém jako celek „zpomalil“ kvůli starým verzím vnitřních součástí.
A samozřejmě nebylo možné aktualizovat software bez zakoupení balíčku podpory.
Flexibilní přístup
Další zásadní požadavek se týkal rozhraní. Chtěli jsme k němu zajistit přístup přes webový prohlížeč odkudkoli, bez povinné přítomnosti inženýra na území datového centra. Kromě toho jsme se snažili vytvořit animované rozhraní, aby byla dynamika infrastruktury pro inženýry ve službě jasnější.
Také v novém systému bylo nutné zajistit podporu vzorců pro výpočet provozu virtuálních senzorů v inženýrských systémech - například pro optimální distribuci elektrické energie mezi stojany zařízení. K tomu potřebujete mít k dispozici všechny obvyklé matematické operace platné pro senzorové indikátory.
Dále byl vyžadován přístup do SQL databáze s možností přebírat z ní potřebná data o provozu zařízení - konkrétně veškeré záznamy 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.
Potřebný byl také modul pro účtování rackových zařízení, poskytující grafické znázornění uspořádání zařízení v každé jednotce s výpočtem celkové hmotnosti hardwaru, udržování knihovny zařízení a podrobné informace o každém prvku.
Schválení technických specifikací a podpis smlouvy
V době, kdy bylo nutné zahájit práce na novém systému, byla korespondence s „velkými“ firmami ještě velmi vzdálená projednávání nákladů na jejich návrhy, proto jsme porovnali obdržené CP s náklady na aktualizaci starého BMS (viz. ), a ve výsledku se ukázalo, že je cenově atraktivnější a vyhovuje našim požadavkům.
Výběr byl proveden.
Po výběru dodavatele začali právníci sepisovat dohodu a technické týmy z obou stran začaly ladit technické specifikace. Jak víte, podrobné a kompetentní technické specifikace jsou základem úspěchu každé práce. Čím více specifik je v technických specifikacích, tím méně zklamání typu „ale to není to, co jsme chtěli“.
Uvedu dva příklady úrovně podrobnosti požadavků v technických specifikacích:
- Datová centra ve službě jsou oprávněna přidávat do BMS nová zařízení, nejčastěji se jedná o PDU. Ve starém BMS to byla „administrátorská“ úroveň, která umožňovala také měnit variabilní nastavení všech zařízení a nebylo možné oddělit funkce. Tohle nám nevyhovovalo. Ve stávající základní verzi nové platformy bylo schéma podobné. Okamžitě jsme v zadání uvedli, že chceme tyto role oddělit: nastavení by měl měnit pouze oprávněný zaměstnanec, ale ti ve službě by měli mít i nadále možnost přidávat zařízení. Toto schéma bylo přijato k realizaci.
- V každém standardním BMS existují tři typické kategorie oznámení: ČERVENÁ – je třeba na ni reagovat okamžitě, ŽLUTÁ – lze pozorovat, MODRÁ – „Informační“. Tradičně používáme modré výstrahy ke sledování překročení obchodních parametrů, jako je například překročení kapacitního limitu stojanu zákazníka. Tento typ upozornění byl v našem případě určen pro manažery a provozní službu nezajímal, ale ve starém BMS pravidelně ucpával seznam aktivních incidentů a zasahoval do operativní práce. Samotnou logiku a barevné odlišení notifikačních kalhotek jsme považovali za zdařilé a zachovali jsme je, nicméně technické specifikace konkrétně naznačovaly, že „modrá“ upozornění by se měla, aniž by odváděla pozornost strážníků, tiše „nasypat“ do samostatné sekce, kde budou řešit komerční specialisté.
S podobnou mírou detailů byly předepsány formáty pro vytváření grafů a generování reportů, obrysy rozhraní, seznam zařízení, která bylo potřeba monitorovat, a mnoho dalších věcí.
Jednalo se o skutečně kreativní práci tří pracovních skupin – zákaznického servisu, který si diktoval své požadavky a podmínky; techničtí specialisté na obou stranách, jejichž úkolem bylo převést tyto podmínky do technické dokumentace; týmy dodavatelských programátorů, kteří realizovali požadavky zákazníka podle vypracované technické dokumentace... Ve výsledku jsme některé naše bezzásadové požadavky přizpůsobili funkčnosti stávající platformy a dodavatel se zavázal, že nám něco přidá.
Paralelní provoz dvou systémů
Je čas na realizaci. V praxi to znamenalo, že dáváme dodavateli možnost nasadit prototyp BMS do našeho virtuálního cloudu a poskytujeme síťový přístup ke všem zařízením, která vyžadují monitorování.
Nový systém však ještě nebyl připraven k provozu. V této fázi pro nás bylo důležité zachovat monitoring ve starém systému a zároveň umožnit přístup k zařízením do nového systému. Je nemožné správně sestavit systém, aniž byste v něm viděli zařízení, která zase nelze zakázat sledování starým systémem.
Zda zařízení vydrží simultánní dotazování dvěma systémy, nebylo bez skutečného testování zřejmé. Existovala možnost, že dvojité simultánní dotazování by vedlo k častému odmítání odpovědi ze zařízení a dostávali bychom mnoho chyb týkajících se nedostupnosti zařízení, což by následně blokovalo provoz starého monitorovacího systému.
Síťové oddělení spustilo virtuální trasy z prototypu nového BMS nasazeného v cloudu do zařízení a my jsme dostali výsledky:
- zařízení připojená přes protokol SNMP se prakticky nikdy neodpojila kvůli souběžným požadavkům,
- zařízení připojená přes brány pomocí protokolů modbas-TCP měla problémy, které byly vyřešeny inteligentním snížením jejich frekvence dotazování.
A pak jsme začali pozorovat, jak se nám před očima buduje nový systém, objevila se v něm zařízení nám již známá, ale v jiném rozhraní - pohodlné, rychlé, dostupné i z telefonu.
Co se nakonec stalo, vám prozradíme ve třetí části našeho článku.
Zdroj: www.habr.com