Merhaba!
Adım Mikhail, Sportmaster şirketinde BT Direktör Yardımcısıyım. Pandemi sırasında ortaya çıkan zorluklarla nasıl başa çıktığımızın hikayesini paylaşmak istiyorum.
Yeni gerçekliklerin ilk günlerinde Sportmaster'ın olağan çevrimdışı ticaret formatı dondu ve çevrimiçi kanalımızdaki yük, özellikle müşterinin adresine teslimat açısından 10 kat arttı. Sadece birkaç hafta içinde devasa bir çevrimdışı işletmeyi çevrimiçi bir işletmeye dönüştürdük ve hizmeti müşterilerimizin ihtiyaçlarına göre uyarladık.
Temel olarak, aslında yan faaliyetimiz olan şey, ana işimiz haline geldi. Her online siparişin önemi son derece arttı. Müşterinin şirkete getirdiği her rubleyi kurtarmak gerekiyordu.
Müşteri taleplerine hızlı yanıt verebilmek için şirketin merkez ofisinde ek bir iletişim merkezi açtık ve şu anda haftada yaklaşık 285 bin çağrı alabiliyoruz. Aynı zamanda 270 mağazamızı, müşterilerin sipariş alabilmesine ve çalışanların işlerini sürdürebilmesine olanak tanıyan, temassız ve güvenli yeni bir çalışma formatına taşıdık.
Dönüşüm sürecinde iki temel sorunla karşılaştık. Öncelikle çevrimiçi kaynaklarımızın üzerindeki yük önemli ölçüde arttı (Sergey size bununla nasıl başa çıktığımızı anlatacak). İkinci olarak, nadir (COVID öncesi) operasyonların akışı birçok kez arttı ve bu da büyük miktarda hızlı otomasyon gerektirdi. Bu sorunu çözmek için, daha önce ana alanlardan hızla kaynak aktarmamız gerekiyordu. Elena sana bununla nasıl başa çıktığımızı anlatacak.
Çevrimiçi hizmetlerin işleyişi
Çevrimiçi mağazanın ve mikro hizmetlerin işletilmesinden sorumlu Kolesnikov Sergey
Perakende mağazalarımız ziyaretçilere kapanmaya başladığı andan itibaren kullanıcı sayısı, uygulamamıza verilen sipariş sayısı, başvurulara gelen talep sayısı gibi metriklerde artış kaydetmeye başladık.
18 Mart'tan 31 Mart'a kadar sipariş sayısıÇevrimiçi ödeme mikro hizmetlerine yönelik taleplerin sayısıWeb sitesine verilen sipariş sayısı
İlk grafikte artışın yaklaşık 14 kat, ikinci grafikte ise 4 kat olduğunu görüyoruz. Uygulamalarımızın yanıt süresi metriğinin en gösterge niteliğinde olduğunu düşünüyoruz.
Bu grafikte cephelerin ve başvuruların tepkisini görüyoruz ve kendi açımızdan böyle bir büyüme görmediğimizi tespit ettik.
Bunun en önemli nedeni hazırlık çalışmalarına 2019 yılı sonunda başlamış olmamızdır. Artık hizmetlerimiz rezerve edilmiş olup, fiziksel sunucular, sanallaştırma sistemleri, docker'lar ve bunların içindeki hizmetler düzeyinde hata toleransı sağlanmaktadır. Aynı zamanda sunucu kaynaklarımızın kapasitesi birden fazla yüke dayanabilmemizi sağlar.
Tüm bu hikayede bize yardımcı olan ana araç izleme sistemimizdi. Doğru, yakın zamana kadar fiziksel ekipman ve donanım düzeyinden iş metrikleri düzeyine kadar tüm katmanlarda metrikleri toplamamıza izin verecek tek bir sistemimiz yoktu.
Şirkette resmi olarak izleme vardı, ancak kural olarak dağınıktı ve belirli departmanların sorumluluk alanındaydı. Aslında, bir olay meydana geldiğinde, tam olarak ne olduğuna dair neredeyse hiçbir zaman ortak bir anlayışa sahip olmuyorduk, hiçbir iletişim yoktu ve çoğu zaman bu, çözülebilmesi için sorunu bulmak ve izole etmek için daireler çizerek koşmamıza yol açıyordu.
Bir noktada düşündük ve buna yeterince dayandığımıza karar verdik; resmin tamamını tam olarak görmek için birleşik bir sisteme ihtiyacımız vardı. Yığınımıza dahil edilen ana teknolojiler, metrikleri uyarmak ve depolamak için bir merkez olarak Zabbix, uygulama metriklerini toplamak ve depolamak için Prometheus, tüm izleme sistemindeki verileri günlüğe kaydetmek ve depolamak için Stack ELK'nin yanı sıra görselleştirme için Grafana, Swagger, Docker ve diğer yararlı ve size tanıdık gelen şeyler.
Aynı zamanda sadece piyasada mevcut olan teknolojileri kullanmakla kalmıyor, aynı zamanda kendi teknolojilerimizi de geliştiriyoruz. Örneğin, sistemlerin birbiriyle entegrasyonuna yönelik hizmetler, yani metriklerin toplanmasına yönelik bir tür API yapıyoruz. Ayrıca kendi izleme sistemlerimiz üzerinde çalışıyoruz; iş ölçümleri düzeyinde kullanıcı arayüzü testleri kullanıyoruz. Ayrıca Telegram'da ekiplere bildirim gönderen bir bot var.
Ayrıca, yaygın olarak kullanılmayan bazı dar metrikler için uyarılar ayarlamak da dahil olmak üzere, metriklerini bağımsız olarak depolayabilmeleri ve bunlarla çalışabilmeleri için izleme sistemini ekipler için erişilebilir hale getirmeye çalışıyoruz.
Sistem genelinde proaktif davranmaya ve olayların mümkün olan en kısa sürede yerelleştirilmesine çalışıyoruz. Ayrıca son zamanlarda mikro hizmet ve sistemlerimizin sayısı önemli ölçüde arttı ve buna bağlı olarak entegrasyon sayısı da arttı. Entegrasyon düzeyinde olayları teşhis etme sürecini optimize etmenin bir parçası olarak, sistemler arası kontroller yapmanıza ve sonuçları görüntülemenize olanak tanıyan, ithalat ve sistemlerin etkileşimi ile ilgili ana sorunları bulmanıza olanak tanıyan bir sistem geliştiriyoruz. birbirine göre.
Elbette işletim sistemleri açısından hala büyüme ve gelişme alanımız var ve bu konuda aktif olarak çalışıyoruz. İzleme sistemimiz hakkında daha fazlasını okuyabilirsiniz .
Teknik testler
Orlov Sergey, web ve mobil geliştirme yeterlilik merkezinin başkanı
Fiziksel mağazaların kapanması başladığından beri geliştirme açısından çeşitli zorluklarla karşılaştık. Her şeyden önce, yük bu şekilde artar. Gerekli önlemler alınmadığı takdirde sisteme yüksek yük uygulandığında hüzünlü bir balkabağına dönüşebileceği, performansının tamamen düşebileceği, hatta işlevselliğini kaybedebileceği açıktır.
Biraz daha az belirgin olan ikinci husus, yüksek yük altındaki sistemin iş süreçlerindeki değişikliklere uyum sağlayacak şekilde çok hızlı bir şekilde değiştirilmesi gerektiğidir. Bazen günde birkaç kez. Birçok şirketin, çok fazla pazarlama faaliyeti varsa sistemde herhangi bir değişiklik yapmaya gerek olmadığı yönünde bir kuralı vardır. Hiç, çalıştığı sürece çalışsın.
Ve aslında sistemi değiştirmenin gerekli olduğu sonsuz bir Kara Cuma yaşadık. Ve sistemdeki herhangi bir hata, sorun veya arıza, işletme için çok maliyetli olacaktır.
İleriye baktığımızda bu testlerin üstesinden gelmeyi başardığımızı, tüm sistemlerin yüke dayandığını, kolayca ölçeklenebildiğimizi ve global anlamda herhangi bir teknik arıza yaşamadığımızı söyleyeceğim.
Sistemin yüksek dalgalanma yüklerine dayanma yeteneğinin dayandığı dört sütun vardır. Bunlardan ilki, hemen yukarıda okuduğunuz izlemedir. Yerleşik bir izleme sistemi olmadan sistemdeki darboğazları bulmak neredeyse imkansızdır. İyi bir izleme sistemi ev kıyafetleri gibidir; rahat olmalı ve size özel olmalıdır.
İkinci husus test etmektir. Bu noktayı çok ciddiye alıyoruz: Her sistem için klasik birimler, entegrasyon testleri, yük testleri ve daha pek çok şey yazıyoruz. Aynı zamanda bir test stratejisi de yazıyoruz ve aynı zamanda test seviyesini artık manuel kontrollere ihtiyaç duymayacak noktaya kadar yükseltmeye çalışıyoruz.
Üçüncü sütun CI/CD Pipeline'dır. Bir uygulamayı oluşturma, test etme ve dağıtma süreçleri mümkün olduğunca otomatikleştirilmeli; manuel müdahale olmamalıdır. CI/CD Pipeline konusu oldukça derin, bu konuya sadece kısaca değineceğim. Her ürün ekibinin uzmanlık merkezlerinin yardımıyla üzerinden geçtiği bir CI/CD Pipeline kontrol listemiz olduğunu belirtmekte fayda var.
Ve işte kontrol listesi
Bu şekilde birçok hedefe ulaşılır. Bu, sürüm dizisinden kaçınmak için API sürüm oluşturma ve özellik geçişidir ve çeşitli testlerin, testlerin tamamen otomatikleştirildiği, dağıtımların sorunsuz olduğu vb. bir düzeyde kapsanmasını sağlar.
Dördüncü sütun mimari ilkeler ve teknik çözümlerdir. Mimarlık üzerine uzun uzun konuşabiliriz ama üzerinde durmak istediğim birkaç ilkeyi vurgulamak istiyorum.
Öncelikle belirli görevler için özel araçlar seçmeniz gerekir. Evet, kulağa çok açık geliyor ve çivilerin çekiçle çakılması ve kol saatlerinin özel tornavidalarla sökülmesi gerektiği açık. Ancak çağımızda birçok araç, maksimum kullanıcı segmentini kapsamak için evrenselleşmeye çalışmaktadır: veritabanları, önbellekler, çerçeveler ve diğerleri. Örneğin MongoDB veritabanını alırsanız çoklu belge işlemleriyle çalışır, Oracle veritabanı ise json ile çalışır. Ve öyle görünüyor ki her şey her şey için kullanılabilir. Ancak üretkenliği savunuyorsak, her bir aracın güçlü ve zayıf yönlerini açıkça anlamamız ve görev sınıfımız için ihtiyaç duyduğumuz araçları kullanmamız gerekir.
İkinci olarak, sistemleri tasarlarken karmaşıklıktaki her artışın gerekçelendirilmesi gerekir. Bunu sürekli aklımızda tutmalıyız; düşük bağlantı prensibi herkes tarafından bilinmektedir. Belirli bir hizmet düzeyinde, tüm sistem düzeyinde ve mimari peyzaj düzeyinde uygulanması gerektiğine inanıyorum. Her sistem bileşenini yük yolu boyunca yatay olarak ölçeklendirme yeteneği de önemlidir. Eğer bu yeteneğe sahipseniz ölçeklendirmek zor olmayacaktır.
Teknik çözümlerden bahsetmişken, ürün ekiplerinden bir sonraki iş yükü dalgasına hazırlık olarak uyguladıkları bir dizi yeni öneri, fikir ve çözüm hazırlamalarını istedik.
Keshi
Yerel ve dağıtılmış önbellek seçimine bilinçli olarak yaklaşmak gerekir. Bazen her ikisini de aynı sistem içerisinde kullanmak mantıklı olabilir.Örneğin, bazı verilerin aslında vitrin önbelleği olduğu, yani güncellemelerin kaynağının sistemin arkasında yer aldığı ve sistemlerin değişmediği sistemlerimiz var. bu veri. Bu yaklaşım için yerel Kafein Önbelleğini kullanıyoruz.
Ve sistemin çalışma sırasında aktif olarak değiştirdiği veriler var ve burada zaten Hazelcast ile dağıtılmış bir önbellek kullanıyoruz. Bu yaklaşım, dağıtılmış önbelleğin avantajlarını gerçekten ihtiyaç duyulan yerde kullanmamıza ve Hazelcast küme verilerinin dolaşımına ilişkin hizmet maliyetlerini, onsuz yapabileceğimiz durumlarda en aza indirmemize olanak tanıyor. Önbellekler hakkında çok şey yazdık. и .
Ayrıca Hazelcast'te seri hale getiriciyi Kryo olarak değiştirmek bize güzel bir ivme kazandırdı. Hazelcast'te ReplicatedMap'ten IMap + Near Cache'e geçiş, verilerin küme boyunca hareketini en aza indirmemize olanak sağladı.
Küçük bir tavsiye: Toplu önbellek geçersiz kılınması durumunda, ikinci önbelleği ısıtma ve ardından ona geçme taktiği bazen uygulanabilir. Görünüşe göre bu yaklaşımla çift bellek tüketimi elde etmeliyiz, ancak pratikte bunun uygulandığı sistemlerde bellek tüketimi azaldı.
Reaktif yığın
Reaktif yığını oldukça fazla sayıda sistemde kullanıyoruz. Bizim durumumuzda bu, eşyordamlı Webflux veya Kotlin'dir. Reaktif yığın, özellikle giriş-çıkış işlemlerinin yavaş olmasını beklediğimiz durumlarda iyidir. Örneğin, yavaş hizmetlere yapılan çağrılar, dosya sistemi veya depolama sistemleriyle çalışma.
En önemli prensip çağrıları engellemekten kaçınmaktır. Reaktif çerçevelerin altında çalışan az sayıda canlı hizmet iş parçacığı bulunur. Eğer dikkatsizce JDBC sürücü çağrısı gibi doğrudan engelleme çağrısı yapmamıza izin verirsek sistem durma noktasına gelecektir.
Hataları kendi çalışma zamanı istisnanıza dönüştürmeye çalışın. Program yürütmenin gerçek akışı reaktif çerçevelere kayar ve kod yürütme doğrusal olmayan hale gelir. Sonuç olarak yığın izlemeleri kullanarak sorunları teşhis etmek çok zordur. Ve buradaki çözüm, her hata için net, objektif çalışma zamanı istisnaları oluşturmak olacaktır.
Elasticsearch
Elasticsearch'ü kullanırken kullanılmayan verileri seçmeyin. Prensip olarak bu da çok basit bir tavsiyedir, ancak çoğu zaman unutulan şey budur. Eğer tek seferde 10 binden fazla kayıt seçmeniz gerekiyorsa Scroll kullanmanız gerekiyor. Bir benzetme yapmak gerekirse, bu biraz ilişkisel bir veritabanındaki imlece benzer.
Gerekmedikçe son filtreyi kullanmayın. Ana örnekteki büyük verilerle bu işlem, veritabanını büyük ölçüde yükler.
Mümkün olduğunda toplu işlemleri kullanın.
API
Bir API tasarlarken iletilen verileri en aza indirmeye yönelik gereksinimleri ekleyin. Bu özellikle cepheyle bağlantılı olarak doğrudur: veri merkezlerimizin kanallarının ötesine geçtiğimiz bu kavşaktadır ve halihazırda bizi müşteriye bağlayan kanal üzerinde çalışıyoruz. En ufak bir sorun varsa çok fazla trafik olumsuz bir kullanıcı deneyimine neden olur.
Ve son olarak, bir sürü veriyi atmayın, tüketicilerle tedarikçiler arasındaki sözleşme konusunda net olun.
Organizasyonel dönüşüm
Eroshkina Elena, BT Direktör Yardımcısı
Karantinanın gerçekleştiği ve çevrimiçi gelişimin hızını keskin bir şekilde artırma ve çok kanallı hizmetleri tanıtma ihtiyacının ortaya çıktığı anda, biz zaten kurumsal dönüşüm sürecindeydik.
Yapımızın bir kısmı ürün yaklaşımı ilke ve uygulamalarına göre çalışmaya aktarıldı. Artık her ürünün işleyişinden ve geliştirilmesinden sorumlu ekipler oluşturuldu. Bu tür ekiplerdeki çalışanlar %100 katılım gösterir ve işlerini Scrum veya Kanban kullanarak, kendileri için neyin tercih edildiğine, dağıtım hattını kurmaya, teknik uygulamaları uygulamaya, kalite güvence uygulamalarına ve çok daha fazlasına bağlı olarak yapılandırırlar.
Şans eseri ürün ekiplerimizin büyük bir kısmı çevrimiçi ve çok kanallı hizmetler alanındaydı. Bu, verimlilik kaybı olmadan mümkün olan en kısa sürede (ciddi anlamda iki gün içinde) uzaktan çalışma moduna geçmemizi sağladı. Özelleştirilmiş süreç, yeni çalışma koşullarına hızla uyum sağlamamıza ve yeni işlevleri oldukça yüksek bir hızda sunmamıza olanak sağladı.
Ayrıca, çevrimiçi ticarette öncü olan ekipleri güçlendirmemiz gerekiyor. O anda bunu ancak iç kaynaklarla yapabileceğimiz ortaya çıktı. Ve iki hafta içinde yaklaşık 50 kişi daha önce çalıştıkları alanı değiştirdiler ve kendileri için yeni olan bir ürün üzerinde çalışmaya başladılar.
Bu herhangi bir özel yönetim çabası gerektirmedi çünkü kendi sürecimizi organize etme, ürünün teknik olarak iyileştirilmesi ve kalite güvence uygulamalarının yanı sıra ekiplerimize kendi kendini organize etmeyi, idari kaynakları dahil etmeden kendi üretim süreçlerini yönetmeyi öğretiyoruz.
Yönetim kaynaklarımızı tam olarak o anda ihtiyaç duyulan yere, yani iş ile birlikte koordine etmeye odaklayabildik: Şu anda müşterimiz için önemli olan şey, ilk önce hangi işlevselliğin uygulanması gerektiği, üretim yeteneğimizi artırmak için ne yapılması gerektiği Siparişleri teslim etmek ve işlemek. Tüm bunlar ve net bir rol modeli, bu dönemde üretim değer akışlarımıza gerçekten önemli ve gerekli olan şeyleri yüklememizi mümkün kıldı.
Uzaktan çalışma ve yüksek değişim hızıyla, iş göstergeleri herkesin katılımına bağlıyken, yalnızca "Bizde her şey yolunda mı gidiyor?" dizisindeki içsel duygulara güvenemeyeceğiniz açık. Evet, iyi görünüyor.” Üretim sürecinin objektif ölçümlerine ihtiyaç vardır. Bunlara sahibiz ve ürün ekiplerinin metrikleriyle ilgilenen herkesin kullanımına açıktır. Her şeyden önce ekibin kendisi, işletme, taşeronlar ve yönetim.
Her iki haftada bir, her ekiple 10 dakika boyunca metriklerin analiz edildiği, üretim sürecindeki darboğazların belirlendiği ve ortak bir çözüm geliştirildiği bir durum toplantısı yapılıyor: bu darboğazları ortadan kaldırmak için neler yapılabilir? Burada, tespit edilen herhangi bir sorunun ekiplerin veya benzer bir sorunla daha önce karşılaşmış olabilecek meslektaşlarınızın uzmanlığının etki alanı dışında olması durumunda derhal yönetimden yardım isteyebilirsiniz.
Ancak, birden çok kez hızlanmak için (ve bu tam olarak kendimiz için belirlediğimiz hedeftir), yine de çok şey öğrenmemiz ve bunu günlük işlerimizde uygulamamız gerektiğinin farkındayız. Şu anda ürün yaklaşımımızı diğer ekiplere ve yeni ürünlere ölçeklendirmeye devam ediyoruz. Bunu yapmak için, bizim için yeni bir formatta uzmanlaşmamız gerekiyordu: çevrimiçi metodolojistler okulu.
Ekiplerin bir süreç oluşturmasına, iletişim kurmasına ve iş verimliliğini artırmasına yardımcı olan kişiler olan metodolojistler, esasen değişimin temsilcileridir. Şu anda ilk grubumuzun mezunları ekiplerle çalışıyor ve onların başarılı olmasına yardımcı oluyor.
Mevcut durumun bizim için belki de henüz tam olarak farkında olmadığımız fırsatların ve beklentilerin önünü açtığını düşünüyorum. Ancak şu anda kazandığımız deneyim ve uygulama, gelişim için doğru yolu seçtiğimizi, gelecekte bu yeni fırsatları kaçırmayacağımızı ve Sportmaster'ın karşılaşacağı zorluklara aynı derecede etkili bir şekilde yanıt verebileceğimizi doğruluyor.
Bulgular
Bu zor dönemde, yazılım geliştirmenin dayandığı ana ilkeleri formüle ettik ve bunun bununla ilgilenen her şirket için geçerli olacağını düşünüyorum.
Insanlar. Her şey buna dayanıyor. Çalışanlar işlerinden keyif almalı, şirketin hedeflerini ve üzerinde çalıştıkları ürünlerin hedeflerini anlamalıdır. Ve elbette profesyonel olarak gelişebilirler.
Teknoloji. Şirketin teknoloji yığınıyla çalışma konusunda olgun bir yaklaşım benimsemesi ve gerçekten ihtiyaç duyulan yerlerde yetkinlikler geliştirmesi gerekiyor. Kulağa çok basit ve açık geliyor. Ve çoğu zaman göz ardı ediliyor.
süreçler. Ürün ekiplerinin ve yetkinlik merkezlerinin çalışmalarını doğru bir şekilde organize etmek, işletmeyle ortak olarak çalışabilmek için etkileşim kurmak önemlidir.
Genel olarak bu şekilde hayatta kaldık. Zamanımızın ana tezi, alnında yankılanan bir tıklamayla bir kez daha doğrulandı.
Çok sayıda mağazası ve faaliyet gösterdiğiniz birçok şehri olan büyük bir çevrimdışı işletme olsanız bile, çevrimiçi işinizi geliştirin. Bu sadece ek bir satış kanalı ya da bir şeyler satın alabileceğiniz güzel bir uygulama değildir (ve rakiplerin de güzel uygulamaları olduğu için). Bu, fırtınayı atlatmanıza yardımcı olacak her ihtimale karşı yedek lastik değildir.
Bu mutlak bir zorunluluktur. Bunun için sadece teknik yeteneklerinizin ve altyapınızın değil, aynı zamanda çalışanlarınızın ve süreçlerinizin de hazırlanması gerekir. Sonuçta, birkaç saat içinde hızlı bir şekilde ek bellek, alan satın alabilir, yeni örnekleri dağıtabilirsiniz vb. Ancak kişilerin ve süreçlerin buna önceden hazırlanması gerekiyor.
Kaynak: habr.com