Ürün ekipleri oluşturma aşamasında bir takip sistemi oluşturmayı düşündük. İşimizin - sömürünün - bu ekiplerin eline geçmediği ortaya çıktı. Nedenmiş?
Gerçek şu ki, tüm ekiplerimiz bireysel bilgi sistemleri, mikro hizmetler ve cepheler etrafında oluşturulmuştur, dolayısıyla ekipler tüm sistemin genel durumunu bir bütün olarak görememektedir. Örneğin derin arka uçtaki küçük bir parçanın ön ucu nasıl etkilediğini bilemeyebilirler. İlgi alanları sistemlerinin entegre olduğu sistemlerle sınırlıdır. Bir takımın ve onun A servisinin B servisi ile neredeyse hiçbir bağlantısı yoksa, o zaman böyle bir servis takım için neredeyse görünmezdir.
Ekibimiz ise birbiriyle çok güçlü entegre olmuş sistemlerle çalışıyor: Aralarında çok sayıda bağlantı var, bu çok büyük bir altyapı. Ve çevrimiçi mağazanın işleyişi tüm bu sistemlere bağlıdır (bu arada, elimizde çok sayıda sistem var).
Yani bölümümüzün herhangi bir takıma ait olmadığı, biraz kenarda yer aldığı ortaya çıktı. Bütün bu hikayede görevimiz bilgi sistemlerinin nasıl çalıştığını, işlevselliğini, entegrasyonlarını, yazılımını, ağını, donanımını ve tüm bunların birbiriyle nasıl bağlantılı olduğunu kapsamlı bir şekilde anlamaktır.
Çevrimiçi mağazalarımızın faaliyet gösterdiği platform şuna benzer:
- ön
- orta ofis
- arka ofis
Ne kadar istesek de tüm sistemlerin sorunsuz ve kusursuz çalışması olmuyor. Önemli olan yine sistemlerin ve entegrasyonların sayısıdır; bizimki gibi bir şeyde, test kalitesine rağmen bazı olaylar kaçınılmazdır. Üstelik hem ayrı bir sistem içerisinde hem de entegrasyonu açısından. Ve platformun herhangi bir bölümünü değil, tüm platformun durumunu kapsamlı bir şekilde izlemeniz gerekiyor.
İdeal olarak platform çapında durum izlemenin otomatikleştirilmesi gerekir. Biz de bu sürecin kaçınılmaz bir parçası olarak izlemeye geldik. Başlangıçta yalnızca ön hat kısmı için inşa edilmişken, ağ uzmanları, yazılım ve donanım yöneticileri kendi katman katman izleme sistemlerine sahipti ve hala da sahipler. Bütün bu insanlar izlemeyi sadece kendi seviyelerinde takip ettiler; kimse de kapsamlı bir anlayışa sahip değildi.
Örneğin, bir sanal makine çökerse, çoğu durumda yalnızca donanımdan ve sanal makineden sorumlu yönetici bunu bilir. Bu gibi durumlarda, ön saflardaki ekip uygulamanın çökmesiyle ilgili gerçekleri gördü ancak sanal makinenin çökmesine ilişkin verileri yoktu. Ve yönetici, müşterinin kim olduğunu bilebilir ve bir tür büyük proje olması koşuluyla, bu sanal makinede şu anda neyin çalıştığına dair kabaca bir fikre sahip olabilir. Büyük olasılıkla küçükleri bilmiyordur. Her durumda, yöneticinin makine sahibine gitmesi ve bu makinede ne olduğunu, neyin geri yüklenmesi gerektiğini ve neyin değiştirilmesi gerektiğini sorması gerekir. Ve eğer gerçekten ciddi bir şey bozulursa, etrafta dolaşmaya başlıyorlardı çünkü kimse sistemi bir bütün olarak görmüyordu.
Sonuçta, bu tür farklı hikayeler ön yüzün tamamını, kullanıcıları ve temel iş fonksiyonumuz olan çevrimiçi satışları etkiler. Bir ekibin parçası olmadığımız ve tüm e-ticaret uygulamalarının bir online mağazanın parçası olarak işletilmesiyle uğraştığımız için, e-ticaret platformu için kapsamlı bir izleme sistemi oluşturma görevini üstlendik.
Sistem yapısı ve yığını
Sistemlerimiz için ölçümleri toplamamız gereken çeşitli izleme katmanlarını tanımlayarak başladık. Ve tüm bunların birleştirilmesi gerekiyordu, biz de ilk aşamada bunu yaptık. Şimdi bu aşamada, bir korelasyon oluşturmak ve sistemlerin birbirini nasıl etkilediğini anlamak için tüm katmanlarımızda en yüksek kalitede metrik koleksiyonunu sonlandırıyoruz.
Uygulamanın başlatılmasının ilk aşamalarında kapsamlı bir izlemenin olmaması (sistemlerin çoğu üretimdeyken uygulamayı oluşturmaya başladığımızdan beri), tüm platformun izlenmesini kurmak için önemli bir teknik borcumuz olduğu gerçeğine yol açtı. Sistemlerin geri kalanı bir süre izlemeden bırakılacağından, bir IS için izleme kurmaya ve bunun için izlemeyi ayrıntılı olarak çalıştırmaya odaklanmayı göze alamazdık. Bu sorunu çözmek için bilgi sisteminin durumunu katmanlara göre değerlendirmek için en gerekli metriklerin bir listesini belirledik ve uygulamaya başladık.
Bu nedenle fili parçalar halinde yemeye karar verdiler.
Sistemimiz şunlardan oluşur:
- donanım;
- işletim sistemi;
- Yazılım;
- İzleme uygulamasındaki kullanıcı arayüzü parçaları;
- iş ölçümleri;
- entegrasyon uygulamaları;
- bilgi Güvenliği;
- ağlar;
- trafik dengeleyici
Bu sistemin merkezinde kendini izleme yer alıyor. Genel olarak tüm sistemin durumunu anlamak için, tüm bu katmanlardaki ve tüm uygulama kümesindeki uygulamalarda neler olduğunu bilmeniz gerekir.
Yani, yığın hakkında.
Açık kaynaklı yazılım kullanıyoruz. Merkezde öncelikli olarak uyarı sistemi olarak kullandığımız Zabbix var. Herkes bunun altyapı izleme için ideal olduğunu biliyor. Bu ne anlama gelir? Tam olarak kendi veri merkezine sahip olan her şirketin sahip olduğu (ve Sportmaster'ın kendi veri merkezlerine sahip) düşük seviyeli ölçümler - sunucu sıcaklığı, bellek durumu, baskın, ağ cihazı ölçümleri.
Zabbix'i ekiplerde aktif olarak kullanılan Telegram messenger ve Microsoft Teams ile entegre ettik. Zabbix gerçek ağ katmanını, donanımı ve bazı yazılımları kapsar, ancak her derde deva değildir. Bu verileri diğer bazı hizmetlerden zenginleştiriyoruz. Örneğin donanım düzeyinde doğrudan API aracılığıyla sanallaştırma sistemimize bağlanıp veri topluyoruz.
Başka ne. Zabbix'e ek olarak dinamik ortam uygulamasında metrikleri izlememize olanak sağlayan Prometheus'u kullanıyoruz. Yani, uygulama metriklerini bir HTTP uç noktası aracılığıyla alabiliriz ve hangi metriklerin yüklenip hangilerinin yüklenmeyeceği konusunda endişelenmemize gerek kalmaz. Bu verilere dayanarak analitik sorgular geliştirilebilir.
Diğer katmanlara (örneğin iş ölçümleri) ilişkin veri kaynakları üç bileşene bölünmüştür.
Öncelikle bunlar harici iş sistemleri, Google Analytics, loglardan metrikler topluyoruz. Onlardan aktif kullanıcılar, dönüşümler ve işle ilgili diğer her şey hakkında veri alıyoruz. İkincisi, bu bir kullanıcı arayüzü izleme sistemidir. Daha ayrıntılı olarak açıklanmalıdır.
Bir zamanlar manuel testlerle başladık ve bu, otomatik işlevsellik ve entegrasyon testlerine dönüştü. Bundan yola çıkarak, yalnızca ana işlevselliği bırakarak izlemeyi yaptık ve mümkün olduğu kadar kararlı olan ve zaman içinde sık sık değişmeyen işaretleyicilere güvendik.
Yeni ekip yapısı, tüm uygulama etkinliklerinin ürün ekipleriyle sınırlı olduğu anlamına geliyor, bu nedenle yalnızca test yapmayı bıraktık. Bunun yerine Java, Selenium ve Jenkins (raporları başlatmak ve oluşturmak için bir sistem olarak kullanılır) ile yazılmış testlerden kullanıcı arayüzü izlemesi yaptık.
Bir sürü test yaptık ama sonunda ana yola, üst düzey metriğe gitmeye karar verdik. Ve eğer çok sayıda özel testimiz varsa, verileri güncel tutmak zor olacaktır. Sonraki her sürüm, tüm sistemi önemli ölçüde bozacaktır ve yapacağımız tek şey onu düzeltmektir. Bu nedenle nadiren değişen çok temel şeylere odaklandık ve bunları yalnızca takip ediyoruz.
Son olarak üçüncü olarak veri kaynağı merkezi bir kayıt sistemidir. Günlükler için Elastic Stack kullanıyoruz ve ardından bu verileri iş ölçümleri için izleme sistemimize çekebiliyoruz. Tüm bunlara ek olarak, Python ile yazılmış, API aracılığıyla herhangi bir hizmeti sorgulayan ve onlardan verileri Zabbix'e toplayan kendi Monitoring API hizmetimiz var.
İzlemenin bir diğer vazgeçilmez özelliği ise görselleştirmedir. Bizimki Grafana'ya dayanıyor. Farklı veri kaynaklarından gelen metrikleri kontrol panelinde görselleştirmenize olanak sağlamasıyla diğer görselleştirme sistemleri arasında öne çıkıyor. Bir çevrimiçi mağaza için üst düzey ölçümleri toplayabiliriz; örneğin, DBMS'den son saat içinde verilen siparişlerin sayısı, bu çevrimiçi mağazanın Zabbix'ten çalıştığı işletim sistemi için performans ölçümleri ve bu uygulamanın örneklerine ilişkin ölçümler Prometheus'tan. Ve bunların hepsi tek bir kontrol panelinde olacak. Açık ve erişilebilir.
Güvenlikle ilgili şunu belirtmek isterim; şu anda sistemi tamamlıyoruz ve bunu daha sonra küresel izleme sistemiyle entegre edeceğiz. Bana göre e-ticaretin bilgi güvenliği alanında karşılaştığı temel sorunlar botlar, ayrıştırıcılar ve kaba kuvvetle ilgilidir. Buna dikkat etmemiz gerekiyor çünkü tüm bunlar hem uygulamalarımızın işleyişini hem de iş açısından itibarımızı kritik bir şekilde etkileyebilir. Ve seçilen yığınla bu görevleri başarıyla yerine getiriyoruz.
Bir diğer önemli nokta ise uygulama katmanının Prometheus tarafından montajının yapılmasıdır. Kendisi de Zabbix ile entegredir. Ayrıca sayfamızın yükleme hızı, darboğazlar, sayfa oluşturma, komut dosyalarının yüklenmesi vb. gibi parametreleri görüntülememize olanak tanıyan bir hizmet olan site hızımız da var, aynı zamanda API entegredir. Yani metriklerimiz Zabbix’te toplanıyor ve buna göre biz de oradan uyarı yapıyoruz. Tüm uyarılar şu anda ana gönderme yöntemlerine gönderilmektedir (şimdilik e-posta ve telgraftır; MS Teams de yakın zamanda bağlanmıştır). Uyarıları, akıllı botların bir hizmet olarak çalışacağı ve ilgili tüm ürün ekiplerine izleme bilgileri sağlayacağı bir duruma yükseltme planları var.
Bizim için metrikler yalnızca bireysel bilgi sistemleri için değil, aynı zamanda uygulamaların kullandığı tüm altyapı için de genel metrikler önemlidir: üzerinde sanal makinelerin çalıştığı fiziksel sunucu kümeleri, trafik dengeleyiciler, Ağ Yük Dengeleyicileri, ağın kendisi, iletişim kanallarının kullanımı . Ayrıca kendi veri merkezlerimiz için metrikler (birkaç tane var ve altyapı oldukça büyük).
İzleme sistemimizin avantajları, onun yardımıyla tüm sistemlerin sağlık durumunu görmemiz ve bunların birbirleri ve paylaşılan kaynaklar üzerindeki etkilerini değerlendirebilmemizdir. Ve sonuçta, aynı zamanda bizim sorumluluğumuz olan kaynak planlamasına katılmamızı sağlar. Sunucu kaynaklarını yönetiyoruz - e-ticaret içindeki bir havuz, yeni ekipmanı devreye alma ve hizmetten çıkarma, ek yeni ekipman satın alma, kaynak kullanımının denetimini gerçekleştirme vb. Ekipler her yıl yeni projeler planlıyor, sistemlerini geliştiriyor ve onlara kaynak sağlamak bizim için önemli.
Metriklerin yardımıyla bilgi sistemlerimizin kaynak tüketimindeki eğilimi görüyoruz. Ve onlara dayanarak bir şeyler planlayabiliriz. Sanallaştırma düzeyinde veri topluyor ve veri merkezine göre mevcut kaynak miktarına ilişkin bilgileri görüyoruz. Ve zaten veri merkezinin içinde kaynakların geri dönüşümünü, gerçek dağıtımını ve tüketimini görebilirsiniz. Üstelik hem bağımsız sunucular hem de sanal makineler ve tüm bu sanal makinelerin üzerinde güçlü bir şekilde döndüğü fiziksel sunucu kümeleri.
Beklentiler
Artık sistemin çekirdeğini bir bütün olarak hazır hale getirdik, ancak hâlâ üzerinde çalışılması gereken pek çok şey var. Bu en azından bir bilgi güvenliği katmanıdır ancak ağa ulaşmak, uyarıları geliştirmek ve korelasyon sorununu çözmek de önemlidir. Birçok katmanımız ve sistemimiz var ve her katmanda çok daha fazla metrik var. Bir matryoshka derecesine kadar bir matryoshka olduğu ortaya çıkıyor.
Bizim görevimiz sonuçta doğru uyarıları yapmaktır. Mesela donanımda sorun varsa yine sanal makinede önemli bir uygulama varsa ve servis hiçbir şekilde yedeklenmemişse. Sanal makinenin öldüğünü öğreniyoruz. Daha sonra iş ölçümleri sizi uyaracaktır: kullanıcılar bir yerlerde kaybolmuştur, dönüşüm yoktur, arayüzdeki kullanıcı arayüzü kullanılamaz, yazılım ve hizmetler de ölmüştür.
Bu durumda, uyarılardan spam alacağız ve bu artık uygun bir izleme sisteminin formatına uymuyor. Korelasyon sorunu ortaya çıkıyor. Bu nedenle, ideal olarak, izleme sistemimiz bizi öfkeyle yüzlerce uyarı bombardımanına tutmak yerine, tek bir uyarının yardımıyla "Arkadaşlar, fiziksel makineniz öldü ve onunla birlikte bu uygulama ve bu ölçümler" demeli. Ana şeyi - yerelleştirilmesi nedeniyle sorunun hızlı bir şekilde ortadan kaldırılmasına yardımcı olan nedeni - bildirmelidir.
Bildirim sistemimiz ve uyarı işlememiz 24 saat yardım hattı hizmeti üzerine kurulmuştur. Olması gereken kabul edilen ve kontrol listesinde yer alan tüm uyarılar oraya gönderilir. Her uyarının bir açıklaması olmalıdır: ne olduğu, gerçekte ne anlama geldiği, neyi etkilediği. Ayrıca kontrol paneline bir bağlantı ve bu durumda ne yapılacağına ilişkin talimatlar.
Bunların hepsi bir uyarı oluşturma gereksinimleriyle ilgilidir. O zaman durum iki yönde gelişebilir - ya bir sorun var ve çözülmesi gerekiyor ya da izleme sisteminde bir arıza var. Ama her durumda, gidip çözmeniz gerekiyor.
Uyarıların korelasyonunun henüz doğru şekilde yapılandırılmadığı göz önüne alındığında, artık günde ortalama yüz kadar uyarı alıyoruz. Ve teknik çalışma yapmamız gerekiyorsa ve bir şeyi zorla kapatırsak sayıları önemli ölçüde artar.
İzleme sistemi, işlettiğimiz sistemleri izlemenin ve bizim açımızdan önemli görülen metrikleri toplamanın yanı sıra, ürün ekipleri için veri toplamamıza da olanak tanıyor. İzlediğimiz bilgi sistemlerindeki metriklerin bileşimini etkileyebilirler.
Meslektaşımız gelip hem bize hem de takıma faydalı olacak bazı metrikler eklemek isteyebilir. Veya, örneğin, ekip elimizdeki temel metriklerden yeterli olmayabilir; bazı spesifik metrikleri takip etmeleri gerekiyor. Grafana'da her takıma bir alan oluşturuyoruz ve yönetici hakları veriyoruz. Ayrıca, bir ekibin kontrol panellerine ihtiyacı varsa ancak kendileri bunu yapamıyorsa/nasıl yapacağını bilmiyorsa onlara yardımcı oluyoruz.
Ekibin değer yaratma, yayınlama ve planlama akışının dışında olduğumuz için yavaş yavaş tüm sistemlerin sürümlerinin sorunsuz olduğu ve bizimle koordinasyon olmadan günlük olarak kullanıma sunulabileceği sonucuna varıyoruz. Bu sürümleri izlememiz bizim için önemli çünkü bunlar potansiyel olarak uygulamanın çalışmasını etkileyebilir ve bazı şeyleri bozabilir ve bu kritik öneme sahiptir. Sürümleri yönetmek için, API aracılığıyla veri aldığımız ve hangi sürümlerin hangi bilgi sistemlerinde yayınlandığını ve durumlarını görebildiğimiz Bamboo'u kullanıyoruz. Ve en önemli şey ne zaman olduğu. Sorun durumunda görsel olarak oldukça gösterge niteliğinde olan, ana kritik ölçümlerin üzerine sürüm işaretleyicileri yerleştiririz.
Bu şekilde yeni sürümler ile ortaya çıkan sorunlar arasındaki ilişkiyi görebiliriz. Ana fikir, sistemin tüm katmanlarda nasıl çalıştığını anlamak, sorunu hızlı bir şekilde lokalize etmek ve aynı hızla düzeltmektir. Sonuçta, çoğu zaman en çok zaman alan şeyin sorunu çözmek değil, sebebini aramak olduğu görülür.
Gelecekte bu alanda proaktifliğe odaklanmak istiyoruz. İdeal olarak, yaklaşan bir sorun hakkında olaydan sonra değil, önceden bilgi sahibi olmak isterim, böylece onu çözmek yerine önleyebilirim. Bazen hem insan hatasından hem de uygulamadaki değişikliklerden dolayı izleme sisteminde yanlış alarmlar meydana gelir ve biz bunun üzerinde çalışıyoruz, hata ayıklamasını yapıyoruz ve izleme sisteminde herhangi bir manipülasyon yapılmadan önce onu bizimle kullanan kullanıcıları bu konuda uyarmaya çalışıyoruz. veya bu faaliyetleri teknik pencerede gerçekleştirin.
Böylece sistem devreye alındı ve baharın başından beri başarılı bir şekilde çalışıyor... ve oldukça gerçek karlar gösteriyor. Elbette bu onun son versiyonu değil; daha birçok kullanışlı özelliği tanıtacağız. Ancak şu anda bu kadar çok entegrasyon ve uygulama nedeniyle izleme otomasyonu gerçekten kaçınılmaz.
Ayrıca önemli sayıda entegrasyona sahip büyük projeleri de izliyorsanız, bunun için hangi sihirli çözümü bulduğunuzu yorumlara yazın.
Kaynak: habr.com