İlk bölümde veri merkezlerimizdeki eski BMS sistemini neden yenisiyle değiştirmeye karar verdiğimizi anlattık. Ve sadece değişmekle kalmayıp, gereksinimlerinize uyacak şekilde sıfırdan geliştirin. İkinci bölümde size bunu nasıl yaptığımızı anlatacağız.
Piyasa Analizi.
Yukarıda anlatılanlar dikkate alınarak İsteklerimiz ve mevcut sistemi güncellemeyi reddetme kararımız üzerine, piyasada bir çözüm bulmak için bir teknik şartname yazdık ve yalnızca endüstriyel SCADA sistemlerinin oluşturulmasıyla uğraşan birkaç büyük şirkete sorular sorduk.
Onlardan gelen ilk yanıtlar, izleme sistemleri pazarının liderlerinin öncelikle donanım sunucuları üzerinde çalışmaya devam ettiğini, ancak bu segmentte bulutlara geçiş sürecinin başlamış olduğunu gösterdi. Sanal makinelerin rezerve edilmesine gelince, hiç kimse bu seçeneği desteklemedi. Üstelik piyasada görünen geliştiricilerin hiçbirinin yedeklilik ihtiyacını anladığını bile göstermediği hissi vardı: "Bulut düşmüyor" en yaygın cevaptı. Hatta veri merkezi izlemeyi fiziksel olarak aynı veri merkezinde bulunan bir buluta yerleştirmemiz teklif edildi.
Burada müteahhit seçme sürecine dair küçük bir açıklama yapmamız gerekiyor. Fiyat elbette önemlidir, ancak karmaşık bir projenin uygulanmasına yönelik herhangi bir ihale sırasında, tedarikçilerle diyalog aşamasında, adaylardan hangisinin daha ilgili olduğunu ve bunu uygulama yeteneğine sahip olduğunu hissetmeye başlarsınız.
Bu özellikle karmaşık projelerde fark edilir.
Teknik şartnameye ilişkin soruların açıklığa kavuşturulması niteliğine göre yükleniciler, sadece satışla ilgilenenler (bir satış yöneticisinin standart baskısı hissedilir) ve bir ürün geliştirmekle ilgilenen, müşteriyi dinleyip anlayan, yapıcı hale getirenler olarak ikiye ayrılabilir. Nihai seçimden önce bile teknik özelliklerde değişiklik yapılması (bir başkasının teknik özelliklerini iyileştirme ve ihaleyi kaybetme riskine rağmen), sonunda profesyonel bir mücadeleyi kabul etmeye ve iyi bir ürün yapmaya hazırdırlar.
Tüm bunlar, gereksinimlerimizin çoğuna anında yanıt veren ve yeni BMS ile ilgili tüm ihtiyaçları uygulamaya hazır olan, nispeten küçük bir yerel geliştirici olan Sunline şirketler grubuna dikkat etmemizi sağladı.
Riskler
Büyük oyuncular bizim ne istediğimizi anlamaya çalışırken ve satış öncesi uzmanların da katılımıyla bizimle sohbetlerini sürdürürken, yerel geliştirici de teknik ekibinin katılımıyla ofisimizde bir toplantı planladı. Bu toplantıda yüklenici firma projeye katılmak istediğini bir kez daha ortaya koydu ve en önemlisi gerekli sistemin nasıl uygulanacağını anlattı.
Toplantıdan önce büyük bir ulusal veya uluslararası şirketin kaynaklarına sahip olmayan bir ekiple çalışmanın iki riskini gördük:
- Uzmanlar yeteneklerini abartabilir ve bunun sonucunda başa çıkmada başarısız olabilirler; örneğin, karmaşık yazılımlar kullanacaklar veya gerçekleştirilmesi mümkün olmayan rezervasyon algoritmaları tasarlayacaklardır.
- Proje tamamlandıktan sonra proje ekibi dağılabilir ve dolayısıyla ürün desteği tehlikeye girebilir.
Bu riskleri en aza indirmek için toplantıya kendi geliştirme uzmanlarımızı davet ettik. Potansiyel yüklenici firmanın çalışanları ile sistemin neye dayandığı, yedekliliğin nasıl uygulanmasının planlandığı ve operasyon servisi olarak yeterince yetkin olmadığımız diğer konular hakkında detaylı görüşmeler yapıldı.
Karar olumluydu: Mevcut BMS platformunun mimarisi modern, basit ve güvenilirdir, geliştirilebilir, önerilen yedeklilik ve senkronizasyon şeması mantıklı ve uygulanabilirdir.
İlk risk halledildi. İkincisi, yüklenicinin sistemin kaynak kodunu ve belgelerini bize aktarmaya hazır olduğuna dair onay aldıktan sonra ve ayrıca uzmanlarımız tarafından iyi bilinen Python programlama dilini seçerek hariç tutuldu. Bu bize, herhangi bir zorluk yaşamadan sistemi kendi başımıza sürdürme fırsatını ve geliştirme şirketinin piyasadan ayrılması durumunda uzun süreli çalışan eğitimi garantiledi.
Platformun ek bir avantajı da Docker kapsayıcılarında uygulanmasıydı: bu ortamdaki çekirdek, web arayüzü ve ürün veritabanı işlevi. Bu yaklaşım, "klasik" ve sisteme yeni cihazların kolay eklenmesiyle karşılaştırıldığında çözümün en yüksek hızda devreye alınması için önceden ayarlanmış ayarlar dahil olmak üzere birçok avantaj sağlar. "Hepsi bir arada" ilkesi, sistemin uygulanmasını mümkün olduğu kadar basitleştirir: Sistemin paketini açmanız yeterlidir ve hemen kullanmaya başlayabilirsiniz.
Bu çözümle sistemin kopyalarını oluşturmak daha kolay olur ve çözümün bir bütün olarak işleyişini durdurmadan sistemi iyileştirebilir ve ayrı bir ortamda yükseltmeleri uygulayabilirsiniz.
Her iki risk de en aza indirildikten sonra yüklenici CP'yi sağladı. Bizim için BMS sisteminin en önemli parametrelerinin tamamını kapsıyordu.
Rezervasyon
Yeni BMS sisteminin bulutta, sanal bir makinede konumlandırılması gerekiyordu.
Donanım yok, sunucu yok ve bu dağıtım modeliyle ilgili tüm zorluklar ve riskler; bulut çözümü bunlardan sonsuza kadar kurtulmamızı sağladı. Sistemin St. Petersburg ve Moskova'daki iki veri merkezi sahamızdaki bulutumuzda çalışmasına karar verildi. Bunlar, tüm yetkili uzmanların erişimine sahip, aktif bekleme modunda çalışan, tamamen işlevsel iki sistemdir.
İki sistem birbirini sigortalayarak hem bilgi işlem gücü hem de veri iletim kanallarının tam rezervini sağlıyor. Verilerin ve kanalların, sistemlerin, genel olarak sanal makinelerin yedeklenmesi ve ayda bir kez ayrı bir veritabanı yedeklemesi (yönetim ve analiz açısından en değerli kaynak) dahil olmak üzere ek güvenlik önlemleri de yapılandırılmıştır.
BMS çözümünde bir seçenek olarak yedekliliğin özel olarak isteğimiz için geliştirildiğini unutmayın. Rezervasyon şemasının kendisi şöyle görünüyordu:
Destek
Bir BMS çözümünün etkin çalışması için en önemli nokta teknik destektir.
Burada her şey basit: Bu göstergeye göre yeni bir sistem bize 35 rubleye mal olacak. SLA "000 saat içinde yanıt" için aylık, yani 8 x 35 / 000 = yıllık 12 ABD doları. İlk yıl ücretsizdir.
Karşılaştırma yapmak gerekirse, eski BMS'nin satıcıdan alınmasının maliyeti yıllık 18 $'dır ve eklenen her yeni cihaz için bu tutarda bir artış söz konusudur! Aynı zamanda, şirket özel bir yönetici sağlamadı; tüm etkileşim, potansiyel bir alıcı olarak bizimle ilgilenen ve taleplerin işlenmesine buna uygun bir vurgu yapan bir satış müdürü aracılığıyla gerçekleşti.
Daha az parayla, ürün geliştirmede yer alacak bir hesap yöneticisiyle, tek bir giriş noktasıyla vb. tam ürün desteği aldık. Destek, sistemin herhangi bir yönünde hızlı ayarlamalar için geliştiricilere doğrudan erişim, API aracılığıyla entegrasyon vb. sayesinde çok daha esnek hale geldi.
Güncellemeler
Yeni BMS'de önerilen CP'ye göre, tüm güncellemeler destek maliyetine dahildir; ek ödeme gerektirmez. Bunun istisnası, teknik özelliklerde belirtilenlerin ötesinde ek işlevselliklerin geliştirilmesidir.
Eski sistem, hem donanım yazılımı güncellemeleri (Java gibi) hem de hata düzeltmeleri için ödeme gerektiriyordu. Bunu reddetmek imkansızdı, güncellemelerin yokluğunda, dahili bileşenlerin eski sürümleri nedeniyle sistem bir bütün olarak "yavaşladı".
Ve tabii ki destek paketi satın almadan yazılımı güncellemek mümkün değildi.
Esnek yaklaşım
Bir diğer temel gereklilik arayüzle ilgiliydi. Veri merkezi bölgesinde bir mühendisin zorunlu varlığı olmadan, herhangi bir yerden bir web tarayıcısı aracılığıyla ona erişim sağlamak istedik. Ayrıca altyapı dinamiklerinin görev başındaki mühendisler tarafından daha net anlaşılabilmesi için animasyonlu bir arayüz oluşturmaya çalıştık.
Ayrıca yeni sistemde, mühendislik sistemlerindeki sanal sensörlerin çalışmasını hesaplamak için formüller için destek sağlamak gerekiyordu - örneğin, elektrik gücünün ekipman rafları arasında en uygun şekilde dağıtılması için. Bunu yapmak için sensör göstergelerine uygulanabilecek tüm olağan matematiksel işlemleri elinizin altında bulundurmanız gerekir.
Daha sonra, ekipmanın çalışmasıyla ilgili gerekli verileri, yani yaklaşık 20 bin değişken üreten iki bin cihazın ve iki bin sanal sensörün tüm izleme kayıtlarını alma becerisine sahip bir SQL veritabanına erişim gerekiyordu.
Donanımın toplam ağırlığının hesaplanmasıyla birlikte her ünitedeki cihazların düzeninin grafiksel bir temsilini sağlayan, bir cihaz kitaplığı bulunduran ve her bir öğe hakkında ayrıntılı bilgi sağlayan bir raf ekipmanı muhasebe modülüne de ihtiyaç vardı.
Teknik şartnamelerin onaylanması ve sözleşmenin imzalanması
Yeni sistem üzerinde çalışmaya başlamanın gerekli olduğu zamanlarda, "büyük" şirketlerle yazışmalar tekliflerinin maliyetini tartışmaktan hala çok uzaktı, bu nedenle alınan CP'yi eski BMS'yi güncelleme maliyetleriyle karşılaştırdık (bkz. ) ve sonuç olarak fiyat açısından daha cazip olduğu ve ihtiyaçlarımızı karşıladığı ortaya çıktı.
Seçim yapıldı.
Yükleniciyi seçtikten sonra avukatlar bir anlaşma yapmaya başladı ve her iki tarafın teknik ekipleri de teknik şartnameyi geliştirmeye başladı. Bildiğiniz gibi ayrıntılı ve yetkin teknik özellikler her işin başarısının temelidir. Teknik özelliklerde ne kadar çok ayrıntı olursa, “ama istediğimiz bu değildi” gibi hayal kırıklıkları da o kadar az olur.
Teknik şartnamedeki gereksinimlerin detay düzeyine ilişkin iki örnek vereceğim:
- Görevdeki veri merkezleri, BMS'ye yeni cihazlar ekleme yetkisine sahiptir; bunlar çoğunlukla PDU'lardır. Eski BMS'de bu, tüm cihazların değişken ayarlarının değiştirilmesine de olanak tanıyan "yönetici" seviyesiydi ve fonksiyonları ayırmak mümkün değildi. Bu bize yakışmadı. Yeni platformun mevcut temel versiyonunda şema benzerdi. Bu rolleri ayırmak istediğimizi hemen görev tanımında belirttik: Ayarları yalnızca yetkili bir çalışan değiştirmeli, ancak görevli olanlar cihaz eklemeye devam etmelidir. Bu plan uygulama için kabul edildi.
- Herhangi bir standart BMS'de üç tipik bildirim kategorisi vardır: KIRMIZI - hemen yanıt verilmelidir, SARI - gözlemlenebilir, MAVİ - “Bilgilendirici”. Müşteri rafının kapasite sınırını aşması gibi iş parametrelerinin aşıldığını izlemek için geleneksel olarak mavi uyarıları kullanırız. Bizim durumumuzda bu tür bir bildirim yöneticilere yönelikti ve operasyon hizmetinin ilgisini çekmiyordu, ancak eski BMS'de düzenli olarak aktif olaylar listesini tıkadı ve operasyonel çalışmaya müdahale etti. İhbar pantolonunun mantığını ve renk farklılaşmasını başarılı bulduk ve bunu koruduk, ancak teknik özelliklerde "mavi" bildirimlerin, görevli memurların dikkatini dağıtmadan, sessizce ayrı bir bölüme "dökülmesi" gerektiği ve burada görev yapacakları belirtildi. ticari uzmanlar tarafından ele alınacaktır.
Grafik oluşturma ve rapor oluşturma formatları, arayüzlerin ana hatları, izlenmesi gereken cihazların listesi ve daha birçok şey, benzer bir ayrıntı düzeyiyle belirlendi.
Bu, üç çalışma grubunun gerçekten yaratıcı bir çalışmasıydı: gereksinimleri ve koşulları belirleyen müşteri hizmetleri; her iki taraftan da görevi bu koşulları teknik dokümantasyona dönüştürmek olan teknik uzmanlar; Müşterinin gereksinimlerini geliştirilen teknik belgelere göre uygulayan yüklenici programcı ekipleri... Sonuç olarak, ilkesiz gereksinimlerimizden bazılarını mevcut platformun işlevselliğine uyarladık ve yüklenici bizim için bir şeyler eklemeyi üstlendi.
İki sistemin paralel çalışması
Artık uygulama zamanı geldi. Uygulamada bu, yükleniciye sanal bulutumuzda bir BMS prototipi dağıtma ve izleme gerektiren tüm cihazlara ağ erişimi sağlama fırsatı verdiğimiz anlamına geliyordu.
Ancak yeni sistem henüz işletmeye hazır değildi. Bu aşamada eski sistemde takibi sürdürmek ve aynı zamanda yeni sisteme cihazların erişimini sağlamak bizim için önemliydi. İçinde cihazları görmeden bir sistemi düzgün bir şekilde oluşturmak imkansızdır ve bu da eski sistemin izlemesini engelleyemez.
Cihazların iki sistem tarafından eşzamanlı sorgulamaya dayanıp dayanamayacağı, gerçek testler yapılmadan belli değildi. Eş zamanlı çift yoklamanın, cihazlardan yanıt vermenin sık sık reddedilmesine yol açması ve cihazların kullanılamamasıyla ilgili birçok hata almamız ve bunun da eski izleme sisteminin çalışmasını engellemesi ihtimali vardı.
Ağ departmanı, bulutta konuşlandırılan yeni BMS'nin prototipinden cihazlara sanal rotalar çalıştırdı ve sonuçları aldık:
- SNMP protokolü aracılığıyla bağlanan cihazların eş zamanlı istekler nedeniyle bağlantısı neredeyse hiç kesilmedi,
- modbas-TCP protokollerini kullanarak ağ geçitleri aracılığıyla bağlanan cihazlarda, yoklama frekanslarının akıllıca azaltılmasıyla çözülen sorunlar vardı.
Ve sonra gözlerimizin önünde yeni bir sistemin nasıl inşa edildiğini gözlemlemeye başladık, içinde zaten tanıdık olan cihazlar belirdi, ancak farklı bir arayüzde - kullanışlı, hızlı, telefondan bile erişilebilir.
Yazımızın üçüncü bölümünde sonunda yaşananları anlatacağız.
Kaynak: habr.com