Привет!
Mənim adım Mixail, mən Sportmaster şirkətində İT üzrə direktor müaviniyəm. Mən pandemiya zamanı yaranan çətinliklərlə necə məşğul olduğumuzun hekayəsini bölüşmək istəyirəm.
Yeni reallıqların ilk günlərində Sportmaster-in adi oflayn ticarət formatı dondu və onlayn kanalımızdakı yük, ilk növbədə müştərinin ünvanına çatdırılma baxımından 10 dəfə artdı. Cəmi bir neçə həftə ərzində biz nəhəng oflayn biznesi onlayn biznesə çevirdik və xidməti müştərilərimizin ehtiyaclarına uyğunlaşdırdıq.
Əsasən, bizim yan əməliyyatımız olan şey bizim əsas işimizə çevrildi. Hər bir onlayn sifarişin əhəmiyyəti son dərəcə artdı. Müştərinin şirkətə gətirdiyi hər rubla qənaət etmək lazım idi.
Müştəri müraciətlərinə operativ cavab vermək üçün şirkətin baş ofisində əlavə əlaqə mərkəzi açdıq və indi həftədə 285 minə yaxın zəng qəbul edə bilirik. Eyni zamanda, biz 270 mağazanı yeni kontaktsız və təhlükəsiz əməliyyat formatına keçirdik ki, bu da müştərilərə sifarişlər qəbul etməyə və işçilərə iş yerlərini saxlamaq imkanı verdi.
Transformasiya prosesi zamanı biz iki əsas problemlə qarşılaşdıq. Birincisi, onlayn resurslarımıza yük xeyli artdı (Sergey bununla necə məşğul olduğumuzu sizə xəbər verəcəkdir). İkincisi, nadir (COVID-dən əvvəl) əməliyyatların axını dəfələrlə artıb ki, bu da öz növbəsində böyük miqdarda sürətli avtomatlaşdırma tələb edir. Bu problemi həll etmək üçün biz əvvəllər əsas olan ərazilərdən resursları sürətlə köçürməli olduq. Elena sizə bununla necə məşğul olduğumuzu söyləyəcək.
Onlayn xidmətlərin istismarı
Kolesnikov Sergey, onlayn mağazanın və mikroservislərin işinə cavabdehdir
Pərakəndə mağazalarımız ziyarətçilərə yaxınlaşmağa başladığı andan istifadəçilərin sayı, tətbiqimizə verilən sifarişlərin sayı və tətbiqlərə edilən sorğuların sayı kimi göstəricilərdə artım qeydə almağa başladıq.
Martın 18-dən 31-dək olan sifarişlərin sayıOnlayn ödəniş mikroxidmətlərinə müraciətlərin sayıSaytda verilən sifarişlərin sayı
Birinci qrafikdə artımın təxminən 14 dəfə, ikincidə isə 4 dəfə olduğunu görürük. Tətbiqlərimizin cavab müddəti ölçüsünü ən göstərici hesab edirik.
Bu qrafikdə cəbhələrin və tətbiqlərin cavabını görürük və özümüz üçün müəyyən etdik ki, belə bir artım müşahidə etmədik.
Bu, ilk növbədə onunla bağlıdır ki, biz 2019-cu ilin sonunda hazırlıq işlərinə başlamışıq. İndi xidmətlərimiz qorunur, fiziki serverlər, virtualizasiya sistemləri, dokerlər və onlarda olan xidmətlər səviyyəsində nasazlıqlara dözümlülük təmin edilir. Eyni zamanda, server resurslarımızın tutumu bizə çoxsaylı yüklərə tab gətirməyə imkan verir.
Bütün bu hekayədə bizə kömək edən əsas vasitə monitorinq sistemimiz idi. Düzdür, son vaxtlara qədər fiziki avadanlıq və aparat səviyyəsindən tutmuş biznes ölçüləri səviyyəsinə qədər bütün səviyyələrdə ölçüləri toplamağa imkan verən vahid sistemimiz yox idi.
Formal olaraq, şirkətdə monitorinq var idi, lakin bir qayda olaraq, səpələnmiş və konkret departamentlərin məsuliyyəti zonasında idi. Əslində, bir hadisə baş verəndə, demək olar ki, heç vaxt tam olaraq nə baş verdiyini ümumi bir şəkildə başa düşmədik, ünsiyyət yox idi və tez-tez bu, problemi həll etmək üçün onu tapmaq və təcrid etmək üçün dairələrdə qaçmağa səbəb olurdu.
Nə vaxtsa biz düşündük və qərara gəldik ki, buna kifayət qədər dözə bildik - bütün mənzərəni tam şəkildə görmək üçün bizə vahid sistem lazım idi. Bizim yığınımıza daxil olan əsas texnologiyalar xəbərdarlıq və ölçülərin saxlanması mərkəzi kimi Zabbix, tətbiq ölçülərini toplamaq və saxlamaq üçün Prometheus, bütün monitorinq sistemindən məlumatların daxil edilməsi və saxlanılması üçün Stack ELK, həmçinin vizuallaşdırma üçün Grafana, Swagger, Docker-dir. və digər faydalı və sizə tanış olan şeylər.
Eyni zamanda, biz yalnız bazarda mövcud olan texnologiyalardan istifadə etmirik, həm də özümüzün bəzilərini inkişaf etdiririk. Məsələn, biz sistemlərin bir-biri ilə inteqrasiyası üçün xidmətlər edirik, yəni ölçüləri toplamaq üçün bir növ API. Üstəlik biz öz monitorinq sistemlərimiz üzərində işləyirik - biznes ölçüləri səviyyəsində biz UI testlərindən istifadə edirik. Həm də komandaları xəbərdar etmək üçün Telegram-da bir bot.
Biz həmçinin monitorinq sistemini komandalar üçün əlçatan etməyə çalışırıq ki, onlar müstəqil şəkildə öz ölçülərini saxlaya və işləyə bilsinlər, o cümlədən geniş istifadə olunmayan bəzi dar ölçülər üçün xəbərdarlıqlar qura bilsinlər.
Bütün sistemdə biz mümkün qədər tez hadisələrin proaktivliyinə və lokallaşdırılmasına çalışırıq. Bundan əlavə, son vaxtlar mikroservis və sistemlərimizin sayı əhəmiyyətli dərəcədə artıb və müvafiq olaraq inteqrasiyaların sayı da artıb. İnteqrasiya səviyyəsində insidentlərin diaqnostikası prosesinin optimallaşdırılması çərçivəsində biz sistemlərarası yoxlamalar aparmağa və nəticəni göstərməyə imkan verən sistem hazırlayırıq ki, bu da idxal və sistemlərin qarşılıqlı əlaqəsi ilə bağlı əsas problemləri tapmağa imkan verir. bir-birinə.
Əlbəttə ki, əməliyyat sistemləri baxımından böyümək və inkişaf etmək üçün hələ imkanlarımız var və biz bunun üzərində fəal işləyirik. Monitorinq sistemimiz haqqında ətraflı oxuya bilərsiniz .
Texniki testlər
Orlov Sergey, veb və mobil inkişaf üzrə səriştə mərkəzinə rəhbərlik edir
Fiziki mağazanın bağlanması başlayandan bəri biz inkişaf baxımından müxtəlif çətinliklərlə üzləşmişik. Hər şeydən əvvəl, yük artımı belədir. Aydındır ki, müvafiq tədbirlər görülməzsə, o zaman sistemə yüksək yük tətbiq edildikdə, o, kədərli bir partlayışla balqabaq halına gələ bilər və ya performansını tamamilə pisləşdirə bilər, hətta funksionallığını itirə bilər.
Bir az daha aydın görünən ikinci cəhət odur ki, yüksək yük altında olan sistem biznes proseslərindəki dəyişikliklərə uyğunlaşaraq çox tez dəyişdirilməli idi. Bəzən gündə bir neçə dəfə. Bir çox şirkətlərdə belə bir qayda var ki, marketinq fəaliyyəti çox olarsa, sistemdə heç bir dəyişiklik etməyə ehtiyac yoxdur. Heç biri, işlədiyi müddətcə işləsin.
Və mahiyyətcə sonsuz bir Qara Cümə keçirdik, bu müddət ərzində sistemi dəyişdirmək lazım idi. Və sistemdəki hər hansı bir səhv, problem və ya uğursuzluq biznes üçün çox baha başa gələcək.
İrəliyə baxaraq deyəcəm ki, biz bu sınaqların öhdəsindən gələ bildik, bütün sistemlər yükə tab gətirdi, asanlıqla miqyaslandı və heç bir qlobal texniki nasazlıq yaşamadıq.
Sistemin yüksək dalğalı yüklərə tab gətirmək qabiliyyətinin dayandığı dörd sütun var. Bunlardan birincisi, yuxarıda oxuduğunuz monitorinqdir. Daxili monitorinq sistemi olmadan sistem darboğazlarını tapmaq demək olar ki, mümkün deyil. Yaxşı bir monitorinq sistemi ev paltarı kimidir, rahat və sizə uyğun olmalıdır.
İkinci aspekt sınaqdır. Biz bu nöqtəyə çox ciddi yanaşırıq: hər bir sistem üçün klassik vahidlər, inteqrasiya testləri, yük testləri və bir çox başqaları yazırıq. Biz həm də sınaq strategiyası yazırıq və eyni zamanda testin səviyyəsini o qədər artırmağa çalışırıq ki, artıq əllə yoxlamalara ehtiyacımız yoxdur.
Üçüncü sütun CI/CD Boru Kəməridir. Tətbiqin qurulması, sınaqdan keçirilməsi və yerləşdirilməsi prosesləri mümkün qədər avtomatlaşdırılmalı, əl ilə müdaxilə olmamalıdır. CI/CD Boru Kəmərinin mövzusu olduqca dərindir və mən ona yalnız qısaca toxunacağam. Yalnız qeyd etmək lazımdır ki, bizdə hər bir məhsul komandası səriştə mərkəzlərinin köməyi ilə keçdiyi CI/CD Boru Kəməri yoxlama siyahısına malikdir.
Və burada yoxlama siyahısı
Bu yolla bir çox məqsədlərə nail olunur. Bu, buraxılış qatarının qarşısını almaq üçün API versiyası və funksiya keçididir və testin tam avtomatlaşdırıldığı, yerləşdirmələrin qüsursuz olduğu və s. səviyyədə müxtəlif testlərin əhatə olunmasına nail olmaqdır.
Dördüncü sütun memarlıq prinsipləri və texniki həllərdir. Uzun müddət memarlıq haqqında çox danışmaq olar, lakin mən diqqət yetirmək istədiyim bir neçə prinsipi vurğulamaq istəyirəm.
Birincisi, xüsusi tapşırıqlar üçün xüsusi alətlər seçməlisiniz. Bəli, açıq-aydın səslənir və aydındır ki, mismarlar çəkiclə vurulmalı, qol saatları isə xüsusi tornavidalarla sökülməlidir. Ancaq bizim dövrümüzdə bir çox alətlər istifadəçilərin maksimum seqmentini əhatə etmək üçün universallaşmaya çalışır: verilənlər bazası, keşlər, çərçivələr və qalanları. Məsələn, MongoDB verilənlər bazasını götürsəniz, o, çox sənədli əməliyyatlarla, Oracle verilənlər bazası isə json ilə işləyir. Və belə görünür ki, hər şey hər şey üçün istifadə edilə bilər. Ancaq məhsuldarlığın tərəfdarıyıqsa, onda hər bir alətin güclü və zəif tərəflərini aydın şəkildə başa düşməli və tapşırıqlar sinfimiz üçün lazım olanlardan istifadə etməliyik.
İkincisi, sistemlərin layihələndirilməsi zamanı mürəkkəbliyin hər artımı əsaslandırılmalıdır. Bunu daim diqqətdə saxlamalıyıq, aşağı birləşmə prinsipi hər kəsə məlumdur. Hesab edirəm ki, bu, konkret xidmət səviyyəsində və bütün sistem səviyyəsində və memarlıq mənzərəsi səviyyəsində tətbiq edilməlidir. Yük yolu boyunca hər bir sistem komponentini üfüqi miqyasda ölçmək imkanı da vacibdir. Əgər bu qabiliyyətiniz varsa, miqyasını dəyişdirmək çətin olmayacaq.
Texniki həllərdən danışarkən, biz məhsul komandalarından növbəti iş yükü dalğasına hazırlıq üçün həyata keçirdikləri yeni tövsiyələr, ideyalar və həllər dəsti hazırlamağı xahiş etdik.
Keşi
Yerli və paylanmış keşlərin seçiminə şüurlu yanaşmaq lazımdır. Bəzən hər ikisini eyni sistem daxilində istifadə etmək məna kəsb edir.Məsələn, bizdə verilənlərin bir hissəsi mahiyyətcə vitrin keşidir, yəni yeniləmələrin mənbəyi sistemin özünün arxasında yerləşir və sistemlər dəyişmir. bu məlumatlar. Bu yanaşma üçün yerli Caffeine Cache istifadə edirik.
Sistemin əməliyyat zamanı aktiv şəkildə dəyişdiyinə dair məlumatlar var və burada biz artıq Hazelcast ilə paylanmış keşdən istifadə edirik. Bu yanaşma bizə paylanmış keşin faydalarından həqiqətən ehtiyac duyulan yerlərdə istifadə etməyə və onsuz edə biləcəyimiz Hazelcast klaster məlumatlarının dövriyyəsi üçün xidmət xərclərini minimuma endirməyə imkan verir. Keşlər haqqında çox yazmışıq. и .
Bundan əlavə, Hazelcast-da serializatorun Kryo-ya dəyişdirilməsi bizə yaxşı təkan verdi. Və Hazelcast-da ReplicatedMap-dən IMap + Near Cache-ə keçid bizə klaster üzrə məlumatların hərəkətini minimuma endirməyə imkan verdi.
Kiçik bir məsləhət: kütləvi önbelleğin etibarsız olması halında, ikinci önbelleği istiləşdirmək və sonra ona keçmək taktikası bəzən tətbiq olunur. Görünür ki, bu yanaşma ilə ikiqat yaddaş istehlakı əldə etməliyik, lakin praktikada bunun tətbiq edildiyi sistemlərdə yaddaş istehlakı azaldı.
Reaktiv yığın
Biz kifayət qədər çox sayda sistemdə reaktiv yığından istifadə edirik. Bizim vəziyyətimizdə bu Webflux və ya koroutinləri olan Kotlindir. Yavaş giriş-çıxış əməliyyatlarını gözlədiyimiz yerlərdə reaktiv yığın xüsusilə yaxşıdır. Məsələn, yavaş xidmətlərə zənglər, fayl sistemi və ya saxlama sistemləri ilə işləmək.
Ən vacib prinsip zəngləri bloklamaqdan çəkinməkdir. Reaktiv çərçivələrdə başlıq altında işləyən az sayda canlı xidmət ipləri var. Ehtiyatsızlıqla özümüzə JDBC sürücüsü zəngi kimi birbaşa bloklama zəngi etməyə icazə versək, sistem sadəcə dayanacaq.
Səhvləri öz iş vaxtı istisnanıza çevirməyə çalışın. Proqramın icrasının faktiki axını reaktiv çərçivələrə keçir və kodun icrası qeyri-xətti olur. Nəticədə, yığın izlərindən istifadə edərək problemlərin diaqnozu çox çətindir. Və burada həll yolu hər bir səhv üçün aydın, obyektiv iş vaxtı istisnaları yaratmaq olardı.
Elasticsearch
Elasticsearch istifadə edərkən istifadə olunmamış məlumatları seçməyin. Bu, prinsipcə, çox sadə bir məsləhətdir, lakin çox vaxt unudulan budur. Bir anda 10 mindən çox qeyd seçmək lazımdırsa, Scroll istifadə etməlisiniz. Bənzətmədən istifadə etmək üçün, bu, bir az əlaqəli verilənlər bazasındakı kursora bənzəyir.
Lazım olmadıqca postfiltrdən istifadə etməyin. Əsas nümunədə böyük verilənlərlə bu əməliyyat verilənlər bazasını çox yükləyir.
Mümkün olduqda toplu əməliyyatlardan istifadə edin.
API
API dizayn edərkən, ötürülən məlumatların minimuma endirilməsi üçün tələbləri daxil edin. Bu, xüsusilə cəbhə ilə əlaqəlidir: məhz bu qovşaqda biz məlumat mərkəzlərimizin kanallarından kənara çıxırıq və artıq bizi müştəri ilə birləşdirən kanal üzərində işləyirik. Ən kiçik bir problemi varsa, çox trafik mənfi istifadəçi təcrübəsinə səbəb olur.
Və nəhayət, bir çox məlumatı atmayın, istehlakçılar və təchizatçılar arasındakı müqavilə haqqında aydın olun.
Təşkilati transformasiya
Eroshkina Elena, İT üzrə direktor müavini
Karantinin baş verdiyi və onlayn inkişaf tempini kəskin şəkildə artırmaq və omnichannel xidmətlərin tətbiqinə ehtiyac yarandığı anda biz artıq təşkilati transformasiya prosesində idik.
Strukturumuzun bir hissəsi məhsul yanaşması prinsiplərinə və təcrübələrinə uyğun olaraq işə köçürüldü. İndi hər bir məhsulun istismarı və inkişafı üçün cavabdeh olan komandalar formalaşdırılıb. Bu cür komandalardakı işçilər 100% iştirak edir və öz işlərini Scrum və ya Kanban istifadə edərək strukturlaşdırırlar, onlar üçün nəyin daha üstün olmasından, yerləşdirmə boru kəmərinin qurulmasından, texniki təcrübələrin həyata keçirilməsindən, keyfiyyətin təminatı təcrübələrindən və s.
Xoşbəxtlikdən, məhsul komandalarımızın əsas hissəsi onlayn və çox kanallı xidmətlər sahəsində idi. Bu, səmərəliliyi itirmədən ən qısa müddətdə (ciddi, sözün həqiqi mənasında iki gün ərzində) uzaqdan işləmə rejiminə keçməyə imkan verdi. Fərdiləşdirilmiş proses bizə yeni iş şəraitinə tez uyğunlaşmağa və yeni funksionallıqların çatdırılmasında kifayət qədər yüksək tempi saxlamağa imkan verdi.
Bundan əlavə, onlayn biznesin sərhəddində olan komandaları gücləndirməyə ehtiyacımız var. O an aydın oldu ki, biz bunu ancaq daxili imkanlardan istifadə etməklə edə bilərik. Və iki həftə ərzində təxminən 50 nəfər əvvəllər işlədikləri sahəni dəyişdilər və onlar üçün yeni olan bir məhsul üzərində işləməyə başladılar.
Bunun üçün heç bir xüsusi idarəetmə səyləri tələb olunmurdu, çünki öz prosesimizi təşkil etməklə, məhsulun texniki təkmilləşdirilməsi və keyfiyyətin təminatı təcrübələri ilə yanaşı, biz komandalarımıza özünü təşkil etməyi - inzibati resursları cəlb etmədən öz istehsal prosesini idarə etməyi öyrədirik.
Biz idarəetmə resurslarımızı məhz həmin anda lazım olan yerə - bizneslə koordinasiyaya yönəldə bildik: Müştərimiz üçün hazırda nə vacibdir, ilk növbədə hansı funksionallıq tətbiq edilməlidir, ötürmə qabiliyyətimizi artırmaq üçün nələr edilməlidir. sifarişləri çatdırmaq və emal etmək. Bütün bunlar və aydın rol modeli bu müddət ərzində istehsal dəyər axınımızı həqiqətən vacib və zəruri olanlarla yükləməyə imkan verdi.
Aydındır ki, uzaqdan işləmə və yüksək dəyişiklik tempi ilə, biznes göstəriciləri hər kəsin iştirakından asılı olduqda, “Bizimlə hər şey yaxşı gedirmi? Bəli, yaxşı görünür”. İstehsal prosesinin obyektiv ölçüləri lazımdır. Bunlar bizdə var, onlar məhsul komandalarının ölçüləri ilə maraqlanan hər kəs üçün əlçatandır. İlk növbədə komandanın özü, biznes, subpodratçılar və rəhbərlik.
Hər iki həftədə bir dəfə hər bir komanda ilə status keçirilir, burada 10 dəqiqə ərzində göstəricilər təhlil edilir, istehsal prosesindəki darboğazlar müəyyən edilir və birgə həll yolu hazırlanır: bu darboğazları aradan qaldırmaq üçün nə etmək olar. Müəyyən edilmiş hər hansı problem komandaların təsir zonasından və ya oxşar problemlə qarşılaşmış həmkarların təcrübəsindən kənarda olarsa, burada dərhal rəhbərlikdən kömək istəyə bilərsiniz.
Bununla belə, başa düşürük ki, dəfələrlə sürətləndirmək üçün (və bu, bizim qarşımıza qoyduğumuz məqsəddir) hələ də çox şey öyrənməli və gündəlik işimizdə tətbiq etməliyik. Hazırda biz məhsul yanaşmamızı digər komandalara və yeni məhsullara genişləndirməyə davam edirik. Bunun üçün bizim üçün yeni formata - onlayn metodistlər məktəbinə yiyələnməli olduq.
Metodoloqlar, komandalara proses qurmağa, kommunikasiyalar qurmağa və işin səmərəliliyini artırmağa kömək edən insanlar mahiyyətcə dəyişikliyin agentləridir. Hazırda birinci kohortumuzun məzunları komandalarla işləyir və onlara uğur qazanmağa kömək edirlər.
Hesab edirəm ki, indiki vəziyyət bizim üçün bəlkə də özümüzün hələ tam dərk etmədiyimiz imkanlar və perspektivlər açır. Lakin hazırda əldə etdiyimiz təcrübə və təcrübə təsdiq edir ki, biz düzgün inkişaf yolunu seçmişik, biz gələcəkdə bu yeni imkanları əldən verməyəcəyik və Sportmaster-in qarşılaşacağı çağırışlara eyni dərəcədə effektiv cavab verə biləcəyik.
Tapıntılar
Bu çətin dövrdə biz proqram təminatının inkişafının dayandığı əsas prinsipləri formalaşdırmışıq ki, bu, məncə, bununla məşğul olan hər bir şirkət üçün aktual olacaqdır.
Xalq. Hər şeyin üzərində dayandığı budur. İşçilər işlərindən həzz almalı və şirkətin məqsədlərini və üzərində işlədikləri məhsulların məqsədlərini başa düşməlidirlər. Və təbii ki, onlar peşəkar şəkildə inkişaf edə bilərdilər.
Технология. Şirkətin öz texnoloji yığını ilə işləməyə yetkin yanaşması və həqiqətən ehtiyac duyulan yerdə səriştələr yaratması lazımdır. Çox sadə və aydın səslənir. Və çox vaxt göz ardı edilir.
Proseslər. Məhsul qruplarının və səriştə mərkəzlərinin işini düzgün təşkil etmək, onunla tərəfdaş kimi işləmək üçün bizneslə qarşılıqlı əlaqə yaratmaq vacibdir.
Ümumiyyətlə, biz sağ qalmışıq. Dövrümüzün əsas tezisi alnına çınqıl vurmaqla bir daha təsdiqləndi
Bir çox mağazası və fəaliyyət göstərdiyiniz bir çox şəhəri olan nəhəng oflayn biznesiniz olsa belə, onlayn biznesinizi inkişaf etdirin. Bu sadəcə əlavə satış kanalı və ya gözəl proqram deyil ki, onun vasitəsilə siz də nəsə ala bilərsiniz (həmçinin rəqiblərin də gözəlləri var). Bu, fırtınanın qarşısını almağa kömək edəcək ehtiyat təkər deyil.
Bu mütləq zərurətdir. Bunun üçün təkcə sizin texniki imkanlarınız və infrastrukturunuz deyil, həm də işçiləriniz və prosesləriniz hazırlanmalıdır. Axı siz bir neçə saat ərzində tez bir zamanda əlavə yaddaş, yer ala, yeni nümunələr yerləşdirə və s. Amma insanlar və proseslər buna əvvəlcədən hazırlanmalıdır.
Mənbə: www.habr.com