În prima parte am povestit despre motivele pentru care am decis să schimbăm vechea sistem BMS din centrele noastre de date cu unul nou. Și nu doar să schimbăm, ci să dezvoltăm unul de la zero, conform cerințelor noastre. În a doua parte, discutăm despre cum am realizat acest lucru.
Analiza pieței
Ținând cont de cele menționate în cerințele și decizia de a renunța la actualizarea sistemului existent, am redactat un caiet de sarcini pentru a căuta soluții pe piață și am trimis solicitări către mai multe companii mari care se ocupă exclusiv cu crearea de sisteme SCADA industriale.
Primele răspunsuri de la acestea au arătat că liderii pieței sistemelor de monitorizare continuă să lucreze predominant pe servere fizice, deși procesul de migrare în cloud în acest segment a început deja. În ceea ce privește rezervarea mașinilor virtuale, această opțiune nu era susținută de nimeni. Mai mult, exista senzația că niciunul dintre dezvoltatorii notabili de pe piață nu a demonstrat chiar și înțelegerea necesității rezervării: „cloud-ul nu pică” a fost cel mai frecvent răspuns. Practic, ni s-a propus să plasăm monitorizarea centrului de date în cloud, aflat fizic în același centru de date.
Aici trebuie să facem o mică digresiune despre procesul de alegere a contractorului. Prețul, desigur, contează, dar în timpul oricărei licitații pentru implementarea unui proiect complex, în etapa de dialog cu furnizorii, începi să simți cine dintre candidați este mai interesat și capabil să îl realizeze.
Aceasta este deosebit de evidentă în cazul proiectelor complexe.
După natura întrebărilor suplimentare la caietul de sarcini, se pot împărți contractorii în cei care sunt interesați doar să vândă (se simte o presiune standard din partea managerului de vânzări) și cei care sunt interesați să dezvolte un produs, ascultând și înțelegând clientul, contribuind cu corecții constructive la caietul de sarcini înainte de selecția finală (chiar și în ciuda riscului real de a îmbunătăți caietul de sarcini al altcuiva și a pierde licitația), în cele din urmă fiind pur și simplu dispuși să accepte o provocare profesională și să creeze un produs de calitate.
Toate acestea ne-au determinat să ne îndreptăm atenția către un dezvoltator local relativ mic – grupul de companii „Sanline”, care a răspuns la majoritatea cerințelor noastre de la început și a fost pregătit să realizeze toate nevoile legate de noul BMS.
Riscuri
În timp ce marii jucători încercau să înțeleagă ce dorim și purtau o corespondență lentă cu noi, atrăgând specialiști de nivel presale, un dezvoltator local a programat o întâlnire la biroul nostru, implicând echipa sa tehnică. La această întâlnire, contractorul a reafirmat dorința de a participa la proiect și, mai important, a explicat cum va fi implementat sistemul solicitat.
Înainte de întâlnire, am identificat două riscuri asociate lucrului cu o echipă care nu are în spate resursa unei mari companii naționale sau internaționale:
- Specialiștii ar putea suprestima capabilitățile lor și, prin urmare, pur și simplu nu ar reuși; de exemplu, ar putea folosi software complicat sau să proiecteze algoritmi de rezervare imposibili de realizat.
- După implementarea proiectului, echipa ar putea să se destrame, iar, prin urmare, suportul pentru produs ar fi în pericol.
Pentru a minimiza aceste riscuri, am invitat specialiștii noștri în dezvoltare la întâlnire. Angajații potențialului contractor au fost interogați cu atenție cu privire la modul în care este construit sistemul, cum se planifică realizarea rezervării și asupra altor probleme în care, ca serviciu operațional, nu suntem suficient de competenți.
Verdictul a fost pozitiv: arhitectura platformei BMS existente este modernă, simplă și fiabilă, poate fi completată, iar schema de rezervare și sincronizare propusă este logică și funcțională.
Am gestionat primul risc. Al doilea a fost exclus, obținând de la contractor confirmarea că sunt pregătiți să ne transfere codul sursă al sistemului și documentația, alegând, de asemenea, limbajul de programare Python, bine cunoscut de specialiștii noștri. Acest lucru ne-a garantat posibilitatea de a susține sistemul cu propriile forțe, fără nicio dificultate și fără o perioadă lungă de învățare pentru angajați în caz de retragere a companiei dezvoltatoare de pe piață.
Un alt avantaj al platformei a fost implementarea acesteia în containere Docker: în acest mediu funcționează nucleul, interfața web și baza de date a produsului. Această abordare oferă numeroase beneficii, inclusiv configurarea prestabilită pentru o viteză de desfășurare a soluției mai mare comparativ cu „clasicul” și adăugarea simplă de noi dispozitive în sistem. Principiul „totul împreună” simplifică la maxim implementarea sistemului: este suficient să despachetezi sistemul și se poate începe imediat exploatarea acestuia.
Cu o astfel de soluție, este mai ușor să faci copii ale sistemului, iar îmbunătățirile și upgrade-urile pot fi realizate într-un mediu separat, fără a opri funcționarea soluției în ansamblu.
După ce am minimizat ambele riscuri, contractorul a prezentat un deviz. Acesta a detaliat toate cele mai importante parametrii ai sistemului BMS pentru noi.
Rezervare
Noua sistemă BMS trebuia să fie în cloud, pe o mașină virtuală.
Fără hardware, fără servere și inconveniente și riscuri asociate cu acest model de desfășurare – soluția cloud ne-a permis să scăpăm complet de acestea. S-a decis că sistemul va funcționa în cloud-ul nostru pe două locații de datacentere în Sankt Petersburg și Moscova. Acestea sunt două sisteme complet funcționale, operând în modul activ standby, cu acces pentru toți specialiștii autorizați.
Cele două sisteme se asigură reciproc, oferind o rezervă completă atât de puterea de calcul, cât și de canalele de transmisie a datelor. De asemenea, au fost configurate măsuri suplimentare de securitate, inclusiv backup-uri ale datelor și canalelor, sistemelor, mașinilor virtuale în ansamblu și backup-uri separate ale bazei de date o dată pe lună (cea mai valoroasă resursă în perspectiva managementului și analizei).
Să menționăm că opțiunea de rezervare ca parte a soluției BMS a fost dezvoltată special pentru cerințele noastre. Schema de rezervare arăta astfel:
Asistență
Un aspect esențial pentru exploatarea eficientă a soluției BMS – suportul tehnic.
Aici totul este simplu: noul sistem ne-ar costa 35 000 ruble pe lună pentru SLA ‘reacție în termen de 8 ore’, adică 35 000 x 12 / 80 = 5 250 $ pe an. Primul an – gratuit.
Pentru comparație: suportul vechii BMS de la furnizor costa $18,000 pe an, cu o creștere a sumei pentru fiecare dispozitiv nou adăugat! În plus, compania nu oferea un manager dedicat; toate interacțiunile se desfășurau prin intermediul unui manager de vânzări, care era interesat de noi ca de un potențial client, cu un accent corespunzător în gestionarea solicitărilor.
Pentru o sumă mai mică, am primit un suport complet al produsului, cu un account manager care să participe la dezvoltarea acestuia, cu un punct de contact unic etc. Suportul a devenit mult mai flexibil – datorită accesului direct la dezvoltatori pentru ajustări rapide în legătură cu orice aspect al funcționării sistemului, integrarea prin API etc.
Actualizări
În oferta propusă în noua BMS, toate actualizările sunt incluse în costul suportului, adică nu necesită o plată suplimentară. Excepția o constituie dezvoltarea funcționalității suplimentare, peste ceea ce este specificat în specificațiile tehnice.
Vechea sistem presupunea plata atât pentru actualizarea software-ului gratuit integrat (de tip Java), cât și pentru corectarea erorilor. Renunțarea la aceasta nu era posibilă; în absența actualizărilor, sistemul în ansamblu 'încetinea' din cauza versiunilor vechi ale componentelor interne.
Și, desigur, nu era posibil să actualizăm software-ul fără achiziționarea pachetului de suport.
Abordare flexibilă
O altă cerință esențială se referea la interfață. Vream să asigurăm accesul la aceasta prin intermediul unui browser web din orice loc, fără a necesita prezența obligatorie a unui inginer în zona centrului de date. În plus, ne-am propus să creăm o interfață animată, astfel încât dinamica funcționării infrastructurii să fie mai vizibilă pentru inginerii de serviciu.
De asemenea, în noul sistem trebuia să asigurăm suport pentru formulele necesare calculării funcționării senzorilor virtuali în sistemele de inginerie – de exemplu, pentru distribuirea optimă a puterii electrice pe rack-urile cu echipamente. Pentru aceasta, este necesar să avem la dispoziție toate operațiile matematice obișnuite aplicabile indicatorilor senzorilor.
Apoi, era necesar accesul la baza de date SQL, cu posibilitatea de a extrage datele necesare despre activitatea echipamentelor – mai precis, toate înregistrările privind monitorizarea a două mii de dispozitive și două mii de senzori virtuali, generând aproximativ 20 de mii de variabile.
De asemenea, era necesar un modul de gestionare a echipamentului în rack, care să ofere o reprezentare grafică a amplasării dispozitivelor în fiecare unitate, cu calculul greutății totale a „hardului”, menținerea unei biblioteci de echipamente și informații detaliate despre fiecare element.
Aprobarea specificațiilor tehnice și semnarea contractului
În acel moment, când era necesar să începem lucrul la noul sistem, corespondența cu 'companiile mari' era încă foarte departe de discutarea costurilor propunerilor lor, așa că am comparat oferta primită cu cheltuielile pentru actualizarea vechii BMS (vezi. ), iar în rezultatul ei s-a dovedit a fi mai atractivă din punct de vedere al prețului și conformă cerințelor noastre.
A fost făcută alegerea.
După alegerea contractorului, avocații au început să redacteze contractul, iar echipele tehnice de ambele părți au rafinat specificațiile tehnice. După cum se știe, un document tehnic detaliat și bine fundamentat este baza succesului oricărei lucrări. Cu cât sunt mai concrete specificațiile tehnice, cu atât sunt mai puține delocări de genul „noi nu am vrut așa”.
Voi da două exemple de nivelul de detaliere a cerințelor în specificațiile tehnice:
- Centralele de date de carantină au fost împuternicite să adauge noi dispozitive în BMS, cele mai frecvente fiind PDU. În vechiul BMS, acest lucru era la nivelul „administratorului”, permițând inclusiv schimbarea setărilor variabilelor pentru toate dispozitivele, iar separarea funcțiilor era imposibilă. Acest lucru nu ne-a mulțumit. În versiunea de bază existentă a noii platforme, schema era similară. Am specificat imediat în TDR că dorim să separăm aceste roluri: setările ar trebui să fie schimbate doar de un angajat autorizat, dar personalul de la pază ar trebui să aibă în continuare posibilitatea de a adăuga dispozitive. Această schemă a fost acceptată pentru implementare.
- În orice BMS standard, există trei categorii tipice de notificări: ROȘIE – trebuie reacționat imediat, GALBENĂ – se poate observa, ALBASTRĂ – „Informațională”. Am folosit tradițional notificările „albastre” pentru monitorizarea depășirii parametrilor comerciali, de exemplu, depășirea limitei de capacitate a rack-ului clientului. Acest tip de notificări, în cazul nostru, era destinat managerilor și nu era de interes pentru serviciul de operare, dar în vechea BMS cu regularitate aglomera lista incidentelor active și îngreuna munca operativă. Am considerat logică și reușită diferențierea culorii notificărilor, dar în caietul de sarcini am precizat că notificările „albastre” ar trebui, fără a distrage atenția celor de serviciu, să „cadă” silențios într-o secțiune separată, unde vor fi gestionate de specialiști comerciali.
Cu un grad similar de detaliere, au fost descrise formatele de construire a graficelor și generarea rapoartelor, contururile interfețelor, lista dispozitivelor care trebuiau monitorizate și multe alte aspecte.
A fost o muncă cu adevărat creativă a trei grupuri de lucru – a serviciului clientului, care și-a dictat cerințele și condițiile; a specialiștilor tehnici de ambele părți, care aveau sarcina de a transforma aceste condiții în documentație tehnică; și a echipei de programatori ai contractorului, care implementau cerințele clientului conform documentației tehnice elaborate... În cele din urmă, am adaptat unele dintre cerințele noastre neesențiale la funcționalitățile deja existente ale platformei, iar contractorul s-a angajat să complecteze pentru noi.
Funcționarea paralelă a două sisteme
A sosit momentul implementării. În practică, aceasta însemna că oferim contractorului posibilitatea de a desfășura prototipul BMS în cloudul nostru virtual și îi oferim acces la rețea la toate dispozitivele ce necesită monitorizare.
Cu toate acestea, noul sistem încă nu era pregătit pentru operare. În această etapă, era important pentru noi să menținem monitorizarea în vechiul sistem și în același timp să oferim acces la dispozitive pentru noul sistem. Nu este posibil să construiești un sistem normal fără a vedea dispozitivele din el, care la rândul lor nu pot fi deconectate de la monitorizarea vechiului sistem.
A fost neclar dacă dispozitivele vor suporta interogarea simultană de către două sisteme fără teste reale. Existau șanse ca interogarea dublă să ducă la frecvente eșecuri în răspunsurile dispozitivelor și să obținem multe erori de inaccesibilitate, ceea ce ar bloca funcționarea vechiului sistem de monitorizare.
Departamentul de rețea a conectat rutele virtuale de la prototipul noii BMS implementat în cloud către dispozitive, iar noi am obținut rezultatele:
- dispozitivele conectate prin protocolul SNMP practic nu erau deconectate din cauza accesărilor simultane,
- dispozitivele conectate prin gateway-uri prin protocoalele modbus-TCP au întâmpinat probleme care au fost rezolvate printr-o reducere rezonabilă a frecvenței de interogare.
Apoi am început să observăm cum, sub ochii noștri, se construiește un nou sistem, în care apar deja dispozitivele cunoscute, dar într-o altă interfață – comodă, rapidă, accesibilă chiar și de pe telefon.
Despre ceea ce am obținut în final, vom povesti în a treia parte a articolului nostru.
Sursa: habr.com
