Habré hakkındaki yayınlarımda ekibimle ortaklık kurma deneyimim hakkında zaten yazmıştım ( yeni bir işe başlarken işin dağılmaması için bir ortaklık sözleşmesinin nasıl hazırlanacağını anlatıyor). Ve şimdi müşterilerle nasıl ortaklık kurulacağı hakkında konuşmak istiyorum, çünkü onlar olmadan dağılacak hiçbir şey olmayacak. Bu makalenin, ürünlerini büyük işletmelere satmaya başlayan startup'lara faydalı olacağını umuyorum.
Şu anda ekibimle birlikte kurumsal BT'yi destekleme ve çalıştırma süreçlerini otomatikleştirmek için bir ürün geliştirdiğimiz MONQ Digital laboratuvarı adında bir girişimin başındayım. Pazara girmek kolay bir iş değil ve biz de küçük bir ödevle başladık, pazar uzmanlarından ve ortaklarımızdan geçerek pazar bölümlendirmesini gerçekleştirdik. Asıl soru “kimin acılarını en iyi şekilde iyileştirebiliriz?” sorusunu anlamaktı.
Bankalar ilk 3 segmente girdi. Ve elbette listenin ilk sıralarında Tinkoff ve Sberbank vardı. Bankacılık piyasası uzmanlarını ziyaret ettiğimizde şöyle dediler: Ürününüzü orada tanıtın, bankacılık piyasasının yolu açılır. Hem oraya hem de oraya girmeye çalıştık, ancak Sberbank'ta başarısızlık bizi bekliyordu ve Tinkoff'lu adamlar Rus girişimlerle verimli iletişime çok daha açık çıktılar (belki de o sırada Sber'in olması nedeniyle) neredeyse bir milyar Batılı rakibimiz). Bir ay içinde pilot projeye başladık. Nasıl oldu, okumaya devam edin.
Uzun yıllardır operasyon ve izleme konularıyla uğraşıyoruz, şimdi kamuda, sigortada, bankalarda, telekom şirketlerinde ürünümüzü hayata geçiriyoruz, bir uygulama da havayolu şirketiyle oldu (projeden önce bunu bile yapmıyorduk). havacılığın BT'ye çok bağımlı bir endüstri olduğunu düşünüyorum ve Şimdi, COVID'e rağmen şirketin ortaya çıkıp yükselişe geçeceğini gerçekten umuyoruz).
Yaptığımız ürün, kurumsal yazılım olan AIOps (BT Operasyonları için Yapay Zeka veya ITOps) segmentine aittir. Şirkette süreç olgunluk düzeyi arttıkça bu tür sistemlerin uygulanmasındaki temel hedefler:
- Yangınları söndürün: arızaları tespit edin, uyarı akışını enkazdan temizleyin, görevleri ve olayları sorumlulara atayın;
- BT hizmetinin verimliliğini artırın: olayları çözme süresini kısaltın, arızaların nedenlerini belirtin, BT durumunun şeffaflığını artırın;
- İş verimliliğini artırın: El emeği miktarını azaltın, riskleri azaltın, müşteri sadakatini artırın.
Deneyimlerimize göre bankaların izleme konusunda tüm büyük BT altyapılarında ortak olarak aşağıdaki "sorunları" vardır:
- “Kim bilir ne”: çok sayıda teknik departman var, neredeyse herkesin en az bir izleme sistemi var ve çoğunda birden fazla izleme sistemi var;
- Uyarıların “sivrisinek sürüsü”: her sistem yüzlerce uyarı üretir ve bunlardan sorumlu olan herkesi (bazen bölümler arasında da) bombalar. Her bildirim üzerinde sürekli kontrol odağı sağlamak zordur, sayıların çokluğu nedeniyle aciliyetleri ve önemleri aynı düzeydedir;
- Büyük bankalar - sektör liderleri yalnızca sistemlerini sürekli olarak izlemek, arızaların nerede olduğunu bilmek değil, aynı zamanda yapay zekanın gerçek büyüsünü de - sistemlerin kendi kendini izlemesini, kendi kendini tahmin etmesini ve kendi kendini düzeltmesini sağlamak istiyor.
Tinkoff'taki ilk toplantıya geldiğimizde bize hemen izleme konusunda herhangi bir sorunlarının olmadığı ve hiçbir şeyin onlara zarar vermediği söylendi ve asıl soru şuydu: "Zaten durumu iyi olanlara ne sunabiliriz?"
Sohbet uzun sürdü, mikroservislerinin nasıl oluşturulduğunu, departmanların nasıl çalıştığını, hangi altyapı sorunlarının daha hassas, hangilerinin kullanıcılar açısından daha az hassas olduğunu, “kör noktaların” nerede olduğunu, hedeflerinin ve SLA’larının neler olduğunu konuştuk.
Bu arada bankanın SLA'ları gerçekten etkileyici. Örneğin, öncelik XNUMX olan bir ağ kullanılabilirliği olayının çözülmesi yalnızca birkaç dakika sürebilir. Burada hatanın ve aksama süresinin maliyeti elbette etkileyicidir.
Sonuç olarak, çeşitli işbirliği alanları belirledik:
- ilk aşama, olayın çözüm hızını artırmak için şemsiye izlemedir
- ikinci aşama, BT departmanının ölçeklendirilmesine yönelik riskleri azaltmak ve maliyetleri azaltmak için süreç otomasyonudur.
Ölçümleri doğrudan almak imkansız olduğundan, yalnızca birkaç izleme sisteminden gelen bilgilerin işlenmesiyle uyarıların parlak renklerine birkaç "beyaz nokta" boyanabilirdi; aynı zamanda farklı izleme sistemlerinden gelen verileri "tek ekran" üzerinde merkezileştirmek de gerekliydi. olup bitenlerin genel resmini anlamak için. “Şemsiyeler” bu göreve uygundur ve o zaman bu gereksinimleri karşılamıştık.
Bize göre müşterilerle ilişkilerde çok önemli bir şey dürüstlüktür. İlk konuşma ve lisans maliyetinin hesaplanmasından sonra, maliyet çok düşük olduğundan, hemen bir lisans satın almaya değer olabileceği söylendi (Yeşil bankayla ilgili yukarıdaki makaledeki Dynatrace Klyuch-Astrom ile karşılaştırıldığında, bizim) lisansın maliyeti bir milyarın üçte biri değil, 12 gigabayt için ayda 1 bin ruble, Sber için birkaç kat daha ucuza mal olacak). Ama biz onlara hemen sahip olduklarımızı ve sahip olmadıklarımızı anlattık. Belki büyük bir entegratörün satış temsilcisi “evet, her şeyi yapabiliriz, tabii ki lisansımızı alırız” diyebilir ama biz tüm kartlarımızı masaya yatırmaya karar verdik. Lansman sırasında kutumuzun Prometheus ile entegrasyonu yoktu ve otomasyon alt sistemli yeni bir versiyon çıkmak üzereydi ancak henüz müşterilerimize ulaştırmadık.
Pilot proje başladı, sınırları belirlendi ve bize 2 ay süre verildi. Ana görevler şunlardı:
- Platformun yeni bir versiyonunun hazırlanması ve bankanın altyapısında devreye alınması
- 2 izleme sistemini (Zabbix ve Prometheus) bağlayın;
- Slack'te ve SMS yoluyla sorumlulara bildirim göndermek;
- otomatik iyileştirme komut dosyalarını çalıştırın.
Pilot projenin ilk ayı, pilot projenin ihtiyaçlarına uygun olarak platformun süper hızlı modda yeni bir versiyonunun hazırlanmasıyla geçti. Yeni sürüm, Prometheus ile entegrasyonu ve otomatik iyileştirmeyi hemen içeriyor. Geliştirme ekibimiz sayesinde birkaç gece uyumadılar ancak daha önce verdikleri diğer taahhütlerin son tarihlerini kaçırmadan söz verdiklerini yerine getirdiler.
Pilotu ayarlarken projeyi planlanandan önce kapatabilecek yeni bir sorunla karşılaştık: anlık mesajlaşma programlarına ve SMS yoluyla uyarı göndermek için Microsoft Azure sunucularına gelen ve giden bağlantılara ihtiyacımız vardı (o zamanlar bu platformu kullanıyorduk) Slack'e uyarı göndermek için) ve harici bir gönderme hizmeti SMS'i. Ancak bu projede güvenlik özel bir odak noktasıydı. Banka politikası gereği bu tür “delikler” hiçbir durumda açılamamaktadır. Her şeyin kapalı bir döngüden çalışması gerekiyordu. Slack'e ve SMS yoluyla uyarı gönderen kendi dahili hizmetlerimizin API'sini kullanmamız teklif edildi, ancak bu tür hizmetleri kutudan çıktığı gibi bağlama fırsatımız olmadı.
Geliştirme ekibiyle yapılan tartışma akşamı, başarılı bir çözüm arayışıyla sona erdi. Birikmiş yığını karıştırdıktan sonra hiçbir zaman yeterli zamanımız ve önceliğimiz olmayan bir görev bulduk: uygulama ekiplerinin veya müşterinin eklentileri kendileri yazabilmesi ve platformun yeteneklerini genişletebilmesi için bir eklenti sistemi oluşturmak.
Ancak tam olarak bir ayımız kaldı; bu süre zarfında her şeyi kurmamız, otomasyonu yapılandırmamız ve dağıtmamız gerekiyordu.
Baş mimarımız Sergei'ye göre eklenti sisteminin hayata geçirilmesi en az bir ay sürüyor.
Zamanımız yoktu...
Tek bir çözüm vardı; müşteriye gidip her şeyi olduğu gibi anlatmak. Son teslim tarihi değişikliğini birlikte tartışın. Ve işe yaradı. Bize 2 hafta daha süre tanındı. Ayrıca sonuçları göstermek için kendi son tarihleri ve dahili yükümlülükleri vardı, ancak 2 yedek haftaları vardı. Sonunda her şeyi riske atıyoruz. Ortalığı karıştırmak imkansızdı. Dürüstlük ve ortaklık yaklaşımı yine meyvesini verdi.
Pilot uygulamanın sonucunda birçok önemli teknik sonuç ve sonuç elde edildi:
Uyarıları işlemeye yönelik yeni işlevselliği test ettik
Konuşlandırılan sistem, Prometheus'tan uyarıları doğru bir şekilde almaya ve bunları gruplandırmaya başladı. Prometheus istemcisinden gelen sorunla ilgili uyarılar her 30 saniyede bir uçuyordu (zamana göre gruplandırma etkin değil) ve biz bunları "şemsiyenin" kendisinde gruplamanın mümkün olup olmadığını merak ediyorduk. Bunun mümkün olduğu ortaya çıktı - platformdaki uyarıların işlenmesinin ayarlanması bir komut dosyası tarafından uygulandı. Bu, bunları işlemek için hemen hemen her mantığın uygulanmasını mümkün kılar. Platformda standart mantığı zaten şablonlar biçiminde uyguladık - kendinize ait bir şey bulmak istemiyorsanız hazır olanı kullanabilirsiniz.
“Sentetik tetikleyici” arayüzü. Bağlı izleme sistemlerinden gelen uyarıların işlenmesini ayarlama
Sistemin “sağlıklı” durumunu oluşturdu
Uyarılara dayanarak, yapılandırma birimlerinin (CU'lar) durumunu etkileyen izleme olayları oluşturuldu. Dahili bir CMDB kullanabilen veya harici bir CMDB'ye bağlanabilen bir kaynak hizmet modeli (RSM) uyguluyoruz; pilot proje sırasında müşteri kendi CMDB'sini bağlamadı.
Kaynak-hizmet modeliyle çalışmaya yönelik arayüz. Pilot RSM.
Aslında istemcinin sonunda farklı sistemlerden gelen olayların görülebildiği tek bir izleme ekranı var. Şu anda “şemsiyeye” iki sistem bağlı: Zabbix ve Prometheus ve platformun dahili izleme sistemi.
Analitik arayüzü. Tek izleme ekranı.
Süreç otomasyonu başlatıldı
Olayların izlenmesi önceden yapılandırılmış eylemlerin (uyarı gönderme, komut dosyaları çalıştırma, olayları kaydetme/zenginleştirme) başlatılmasını tetikledi; ikincisi bu özel istemciyle denenmedi çünkü pilot projede hizmet masasıyla entegrasyon yoktu.
Eylem ayarları arayüzü. Slack'e uyarı gönderin ve sunucuyu yeniden başlatın.
Genişletilmiş ürün işlevselliği
Otomasyon komut dosyalarını tartışırken müşteri, bash desteği ve bu komut dosyalarının uygun şekilde yapılandırılabileceği bir arayüz istedi. Yeni sürüm biraz daha fazlasını yaptı (cURL, SSH ve SNMP desteğiyle Lua'da tam teşekküllü mantıksal yapılar yazma yeteneği) ve bir betiğin yaşam döngüsünü yönetmenize olanak tanıyan işlevsellik uyguladı (oluşturma, düzenleme, sürüm kontrolü) , silin ve arşivleyin).
Otomatik iyileştirme komut dosyalarıyla çalışmak için arayüz. SSH aracılığıyla sunucu yeniden başlatma komut dosyası.
Ana sonuçlar
Pilot uygulama sırasında mevcut işlevselliği iyileştiren ve müşteri için değeri artıran kullanıcı hikayeleri de oluşturuldu; işte bunlardan bazıları:
- değişkenleri doğrudan uyarıdan otomatik iyileştirme komut dosyasına iletme yeteneğini uygulayın;
- Active Directory aracılığıyla platforma yetkilendirme ekleyin.
Ürünü diğer yeteneklerle "geliştirmek" için daha fazla küresel zorlukla karşılaştık:
- kurallar ve aracılar yerine makine öğrenimine dayalı bir kaynak hizmet modelinin otomatik olarak oluşturulması (muhtemelen şu andaki ana zorluk);
- ek kodlama ve mantık dilleri desteği (ve bu JavaScript olacaktır).
Benim düşünceme göre, en önemli şeyBu pilotun gösterdiği iki şey var:
- Etkili iletişim dürüstlük ve açıklık temelinde kurulduğunda ve müşteri kısa sürede önemli sonuçlar elde eden bir ekibin parçası haline geldiğinde, müşteri ile ortaklıklar etkililiğin anahtarıdır.
- Hiçbir koşulda "koltuk değneği" "kişiselleştirmeye" ve oluşturmaya gerek yoktur - yalnızca sistem çözümleri. Biraz daha zaman harcamak daha iyidir, ancak diğer müşteriler tarafından kullanılacak bir sistem çözümü oluşturmak daha iyidir. Bu arada olan bu, eklenti sistemi ve Azure'a bağımlılığın ortadan kaldırılması diğer istemcilere ek değer sağladı (merhaba, Federal Kanun 152).
Kaynak: habr.com