Apa sing mbantu kita cepet adaptasi karo dagang online ing kahanan anyar

Hello!

Jenengku Mikhail, aku dadi Wakil Direktur IT ing perusahaan Sportmaster. Aku pengin nuduhake crita babagan carane ngatasi tantangan sing muncul nalika pandemi.

Ing dina pisanan kasunyatan anyar, format dagang offline biasa saka Sportmaster beku, lan beban ing saluran online kita, utamane babagan pangiriman menyang alamat klien, tambah kaping 10. Mung sawetara minggu, kita ngowahi bisnis offline sing gedhe-gedhe dadi online lan adaptasi layanan kasebut kanggo kabutuhan klien.

Sejatine, apa sing sejatine operasi sisih dadi bisnis inti. Pentinge saben pesenan online saya tambah akeh. Sampeyan perlu kanggo nyimpen saben rubel sing digawa klien menyang perusahaan. 

Kanggo nanggapi panjalukan pelanggan kanthi cepet, kita mbukak pusat kontak tambahan ing kantor utama perusahaan, lan saiki bisa nampa sekitar 285 ewu telpon saben minggu. Ing wektu sing padha, kita mindhah 270 toko menyang format operasi tanpa kontak lan aman anyar, sing ngidini para pelanggan nampa pesenan lan karyawan supaya bisa njaga pakaryane.

Sajrone proses transformasi, kita nemoni rong masalah utama. Kaping pisanan, beban sumber daya online saya tambah akeh (Sergey bakal menehi pitutur marang kowe carane ngatasi iki). Kapindho, aliran operasi langka (pra-COVID) saya tambah kaping pirang-pirang, sing mbutuhake otomatisasi kanthi cepet. Kanggo ngatasi masalah iki, kita kudu nransfer sumber daya kanthi cepet saka wilayah sing sadurunge dadi sing utama. Elena bakal pitutur marang kowe carane kita ditangani karo iki.

Operasi layanan online

Kolesnikov Sergey, tanggung jawab kanggo operasi toko online lan layanan mikro

Wiwit toko eceran wiwit cedhak karo pengunjung, kita wiwit ngrekam paningkatan metrik kayata jumlah pangguna, jumlah pesenan sing diselehake ing aplikasi kita, lan jumlah panjalukan kanggo aplikasi. 

Jumlah pesenan wiwit 18 Maret nganti 31 MaretJumlah panjalukan kanggo microservices pembayaran onlineJumlah pesenan diselehake ing website

Ing grafik pisanan, kita ndeleng manawa kenaikan kasebut kira-kira 14 kali, ing kaloro - 4 kali. Kita nganggep metrik wektu respon saka aplikasi kita minangka sing paling indikatif. 

Ing grafik iki kita ndeleng respon saka ngarep lan aplikasi, lan kanggo awake dhewe kita nemtokake manawa kita ora weruh wutah kaya mengkono.

Iki utamane amarga kita miwiti kerja persiapan ing pungkasan taun 2019. Saiki layanan kita dilindhungi undhang-undhang, toleransi kesalahan dijamin ing tingkat server fisik, sistem virtualisasi, docker, lan layanan ing kono. Ing wektu sing padha, kapasitas sumber daya server ngidini kita nahan macem-macem beban.

Alat utama sing mbantu kita ing crita iki yaiku sistem pemantauan. Bener, nganti bubar, kita ora duwe sistem siji sing ngidini kita ngumpulake metrik ing kabeh lapisan, saka tingkat peralatan fisik lan hardware nganti tingkat metrik bisnis. 

Secara resmi, ana pemantauan ing perusahaan, nanging minangka aturan, disebarake lan ana ing area tanggung jawab departemen tartamtu. Nyatane, nalika kedadeyan kedadeyan, kita meh ora duwe pangerten umum babagan apa sing kedadeyan, ora ana komunikasi, lan asring iki ndadékaké mlaku-mlaku ing bunderan kanggo nemokake lan ngisolasi masalah kasebut supaya bisa didandani.

Ing sawetara titik, kita mikir lan mutusake yen kita wis cukup nandhang iki - kita butuh sistem terpadu kanggo ndeleng kabeh gambar kanthi lengkap. Teknologi utama sing kalebu ing tumpukan kita yaiku Zabbix minangka pusat panyimpenan lan metrik, Prometheus kanggo ngumpulake lan nyimpen metrik aplikasi, Stack ELK kanggo logging lan nyimpen data saka kabeh sistem pemantauan, uga Grafana kanggo visualisasi, Swagger, Docker lan liyane migunani lan bab sing menowo kanggo sampeyan.

Ing wektu sing padha, kita ora mung nggunakake teknologi sing kasedhiya ing pasar, nanging uga ngembangake sawetara teknologi dhewe. Contone, kita nggawe layanan kanggo nggabungake sistem siji liyane, yaiku, sawetara jenis API kanggo ngumpulake metrik. Kajaba iku, kita nggarap sistem pemantauan dhewe - ing tingkat metrik bisnis, kita nggunakake tes UI. Lan uga bot ing Telegram kanggo ngabari tim.

Kita uga nyoba nggawe sistem pemantauan bisa diakses dening tim supaya bisa nyimpen lan nggarap metrik kanthi mandiri, kalebu nyetel tandha kanggo sawetara metrik sempit sing ora umum digunakake. 

Saindhenging sistem, kita ngupayakake proaktivitas lan lokalisasi kedadeyan kanthi cepet. Kajaba iku, jumlah layanan mikro lan sistem saya tambah akeh, lan jumlah integrasi saya tambah akeh. Lan minangka bagéan saka ngoptimalake proses diagnosa kedadosan ing tingkat integrasi, kita ngembangaken sistem sing ngijini sampeyan kanggo nindakake mriksa salib-sistem lan nampilake asil, sing ngijini sampeyan kanggo nemokake masalah utama sing ana gandhengane karo impor lan interaksi sistem karo saben liyane. 

Mesthi, kita isih duwe ruang kanggo tuwuh lan berkembang ing babagan sistem operasi, lan kita aktif nggarap iki. Sampeyan bisa maca liyane babagan sistem ngawasi kita kene. 

Tes teknis 

Orlov Sergey, kepala pusat kompetensi kanggo pangembangan web lan seluler

Wiwit penutupan toko fisik wiwit, kita wis ngadhepi macem-macem tantangan saka perspektif pembangunan. Kaping pisanan, beban mundhak kaya ngono. Cetha yen langkah-langkah sing cocog ora ditindakake, mula nalika beban dhuwur ditrapake ing sistem kasebut, bisa dadi waluh kanthi sedhih, utawa nyuda kinerja, utawa malah ilang fungsine.

Aspek kapindho, sing rada kurang jelas, yaiku sistem kanthi beban dhuwur kudu diganti kanthi cepet, adaptasi karo owah-owahan ing proses bisnis. Kadhang kaping pirang-pirang dina. Akeh perusahaan duwe aturan yen ana akeh kegiatan marketing, ora perlu ngowahi sistem kasebut. Ora ana apa-apa, ayo mlaku anggere bisa.

Lan kita ateges duwe Black Friday tanpa wates, sajrone kudu ngganti sistem kasebut. Lan kesalahan, masalah, utawa kegagalan ing sistem bakal larang banget kanggo bisnis kasebut.

Ing ngarep, aku bakal ujar manawa kita bisa ngatasi tes kasebut, kabeh sistem nahan beban, gampang diukur, lan kita ora ngalami kegagalan teknis global.

Ana papat pilar ing ngendi kemampuan sistem kanggo nahan beban lonjakan dhuwur. Sing pertama yaiku ngawasi, sing diwaca ing ndhuwur. Tanpa sistem ngawasi sing dibangun, meh ora bisa nemokake bottlenecks sistem. Sistem pemantauan sing apik kaya sandhangan omah; kudu nyaman lan cocog karo sampeyan.

Aspek kapindho yaiku tes. Kita njupuk titik iki kanthi serius: kita nulis unit klasik, tes integrasi, tes beban lan liya-liyane kanggo saben sistem. Kita uga nulis strategi testing, lan ing wektu sing padha nyoba kanggo nambah tingkat testing kanggo titik sing kita ora perlu maneh mriksa manual.

Pilar katelu yaiku CI/CD Pipeline. Proses mbangun, nguji, lan nyebarake aplikasi kudu otomatis sabisane; ora ana intervensi manual. Topik CI / CD Pipeline cukup jero, lan aku mung bakal ndemek sedhela. Iku mung worth sebutno sing kita duwe CI / CD Pipeline checklist, kang saben tim produk dadi liwat karo bantuan saka pusat kompetensi.

Lan iki dhaptar priksa

Kanthi cara iki, akeh gol sing digayuh. Iki minangka versi API lan pilihan fitur kanggo ngindhari sepur rilis, lan entuk jangkoan macem-macem tes ing tingkat sing tes otomatis kanthi otomatis, panyebaran lancar, lan liya-liyane.

Pilar kaping papat yaiku prinsip arsitektur lan solusi teknis. Kita bisa ngomong akeh babagan arsitektur kanggo dangu, nanging aku pengin nandheske saperangan saka prinsip sing aku kaya kanggo fokus ing.

Pisanan, sampeyan kudu milih alat khusus kanggo tugas tartamtu. Ya, iku muni ketok, lan iku cetha yen paku kudu mimpin ing karo Pethel, lan wristwatches kudu disassembled karo screwdrivers khusus. Nanging ing jaman saiki, akeh alat sing ngupayakake universalisasi supaya bisa nutupi segmen maksimal pangguna: database, cache, kerangka kerja lan liya-liyane. Contone, yen sampeyan njupuk database MongoDB, bisa digunakake karo transaksi multi-dokumen, lan database Oracle dianggo karo json. Lan koyone kabeh bisa digunakake kanggo kabeh. Nanging yen kita ngadeg kanggo produktivitas, mula kita kudu ngerti kanthi jelas kekuwatan lan kelemahane saben alat lan nggunakake sing dibutuhake kanggo tugas kelas. 

Kapindho, nalika ngrancang sistem, saben tambah kerumitan kudu dibenerake. Kita kudu terus-terusan ngelingi iki; prinsip kopling kurang dikenal kabeh wong. Aku percaya yen kudu ditrapake ing tingkat layanan tartamtu, lan ing tingkat kabeh sistem, lan ing tingkat lanskap arsitektur. Kemampuan kanggo skala horisontal saben komponen sistem ing sadawane jalur muatan uga penting. Yen sampeyan duwe kemampuan iki, scaling ora bakal angel.

Ngomong babagan solusi teknis, kita njaluk tim produk nyiyapake rekomendasi, ide lan solusi sing anyar, sing ditindakake kanggo nyiapake gelombang kerja sabanjure.

Keshi

Sampeyan perlu kanthi sengaja nyedhaki pilihan cache lokal lan disebarake. Kadhangkala ana gunane nggunakake loro ing sistem sing padha. Contone, kita duwe sistem sing sawetara data kasebut minangka cache showcase, yaiku, sumber nganyari ana ing mburi sistem kasebut, lan sistem kasebut ora owah. data iki. Kanggo pendekatan iki kita nggunakake Cache Kafein lokal. 

Lan ana data sing sistem aktif diganti sajrone operasi, lan ing kene kita wis nggunakake cache sing disebarake karo Hazelcast. Pendekatan iki ngidini kita nggunakake keuntungan saka cache mbagekke ngendi padha pancene needed, lan nyilikake biaya layanan saka sirkulasi data kluster Hazelcast ngendi kita bisa nindakake tanpa iku. Kita wis nulis akeh babagan cache. kene и kene.

Kajaba iku, ngganti serializer kanggo Kryo ing Hazelcast menehi kita ngedongkrak apik. Lan transisi saka ReplicatedMap menyang IMap + Cedhak Cache ing Hazelcast ngidini kita nyilikake gerakan data ing kluster kasebut. 

Saran sethitik: ing kasus invalidation cache massa, taktik anget munggah cache kapindho lan banjur ngalih menyang iku kadhangkala bisa ditrapake. Katon yen pendekatan iki kudu entuk konsumsi memori kaping pindho, nanging ing praktik kasebut, ing sistem kasebut, konsumsi memori mudhun.

Tumpukan reaktif

Kita nggunakake tumpukan reaktif ing akeh sistem. Ing kasus kita, iki Webflux utawa Kotlin karo coroutines. Tumpukan reaktif utamané apik ing ngendi kita ngarepake operasi input-output sing alon. Contone, nelpon menyang layanan alon, nggarap sistem file utawa sistem panyimpenan.

Prinsip sing paling penting yaiku supaya ora mblokir telpon. Kerangka reaktif duwe sawetara benang layanan langsung sing mlaku ing sangisore hood. Yen kita ora sengaja ngijinake nelpon langsung, kayata telpon driver JDBC, sistem kasebut bakal mandheg. 

Coba ngowahi kesalahan dadi pangecualian runtime dhewe. Aliran nyata saka eksekusi program pindhah menyang kerangka reaktif, lan eksekusi kode dadi nonlinier. Akibaté, angel banget kanggo diagnosa masalah nggunakake jejak tumpukan. Lan solusi ing kene yaiku nggawe pengecualian runtime sing jelas lan objektif kanggo saben kesalahan.

Elasticsearch

Nalika nggunakake Elasticsearch, aja milih data sing ora digunakake. Iki, ing asas, uga saran banget prasaja, nanging paling asring iki lali. Yen sampeyan kudu milih luwih saka 10 ewu cathetan sekaligus, sampeyan kudu nggunakake Gulung. Kanggo nggunakake analogi, iku rada kaya kursor ing basis data relasional. 

Aja nggunakake postfilter kajaba perlu. Kanthi data gedhe ing sampel utama, operasi iki akeh banget ing database. 

Gunakake operasi akeh yen ana.

API

Nalika ngrancang API, kalebu syarat kanggo nyilikake data sing dikirim. Iki pancen bener babagan ngarep: ing persimpangan iki kita ngluwihi saluran pusat data lan wis nggarap saluran sing nyambungake kita karo klien. Yen ana masalah sing paling sithik, lalu lintas sing akeh banget nyebabake pengalaman pangguna sing negatif.

Lan pungkasane, aja mbuwang akeh data, jelas babagan kontrak antarane konsumen lan pemasok.

Transformasi organisasi

Eroshkina Elena, Wakil Direktur IT

Ing wayahe nalika karantina kedaden, lan perlu kanggo nambah cepet pembangunan online lan ngenalake layanan omnichannel, kita wis ing proses transformasi organisasi. 

Bagéyan saka struktur kita ditransfer kanggo makarya miturut prinsip lan praktik pendekatan produk. Tim wis dibentuk sing saiki tanggung jawab kanggo operasi lan pangembangan saben produk. Karyawan ing tim kasebut 100% melu lan nyusun karyane nggunakake Scrum utawa Kanban, gumantung saka apa sing luwih disenengi, nyetel pipa penyebaran, ngetrapake praktik teknis, praktik jaminan kualitas, lan liya-liyane.

Untunge, akeh tim produk kita ana ing area layanan online lan omnichannel. Iki ngidini kita ngalih menyang mode kerja remot ing wektu paling cendhak (serius, secara harfiah sajrone rong dina) tanpa mundhut efisiensi. Proses sing disesuaikan ngidini kita cepet adaptasi karo kahanan kerja anyar lan njaga kecepatan pangiriman fungsi anyar sing cukup dhuwur.

Kajaba iku, kita kudu ngiyatake tim sing ana ing wates bisnis online. Ing wayahe dadi cetha yen kita mung bisa nindakake iki nggunakake sumber daya internal. Lan udakara 50 wong ing rong minggu ngganti wilayah kerja sadurunge lan melu nggarap produk sing anyar kanggo dheweke. 

Iki ora mbutuhake upaya manajemen khusus, amarga bebarengan karo ngatur proses kita dhewe, perbaikan teknis produk, lan praktik jaminan kualitas, kita mulang tim supaya bisa ngatur dhewe - kanggo ngatur proses produksi dhewe tanpa nglibatake sumber daya administratif.

Kita bisa fokus sumber daya manajemen persis ing ngendi sing dibutuhake ing wektu iku - kanggo koordinasi bebarengan karo bisnis: Apa sing penting kanggo klien kita saiki, fungsi apa sing kudu dileksanakake dhisik, apa sing kudu ditindakake kanggo nambah kemampuan throughput. kanggo ngirim lan proses pesenan. Kabeh iki lan model peran sing jelas bisa ditindakake sajrone wektu iki kanggo ngemot aliran nilai produksi kanthi apa sing penting lan perlu. 

Cetha yen kanthi kerja remot lan owah-owahan sing cepet, nalika indikator bisnis gumantung marang partisipasi saben wong, sampeyan ora bisa mung ngandelake perasaan internal saka seri "Apa kabeh bakal apik karo kita? Ya, katon apik. Metrik obyektif saka proses produksi dibutuhake. Kita duwe iki, kasedhiya kanggo sapa wae sing kasengsem ing metrik tim produk. Kaping pisanan, tim dhewe, bisnis, subkontraktor lan manajemen.

Sawise saben rong minggu, status dianakake karo saben tim, ing ngendi metrik dianalisis sajrone 10 menit, kemacetan ing proses produksi diidentifikasi, lan solusi gabungan dikembangake: apa sing bisa ditindakake kanggo ngilangi kemacetan kasebut. Ing kene sampeyan bisa langsung njaluk bantuan saka manajemen yen ana masalah sing diidentifikasi ing njaba zona pengaruh tim, utawa keahlian saka kolega sing bisa uga wis nemoni masalah sing padha.

Nanging, kita ngerti manawa supaya bisa nyepetake kaping pirang-pirang (lan iki persis minangka tujuan sing wis ditemtokake kanggo awake dhewe), kita isih kudu sinau akeh lan ngetrapake ing karya saben dinane. Saiki, kita terus nambah pendekatan produk menyang tim liyane lan produk anyar. Kanggo nindakake iki, kita kudu nguwasani format anyar kanggo kita - sekolah metodologi online.

Metodologi, wong sing mbantu tim mbangun proses, nggawe komunikasi, lan ningkatake efisiensi kerja, sejatine minangka agen pangowahan. Saiki, lulusan kohort pertama kita kerja bareng tim lan mbantu dheweke dadi sukses. 

Aku mikir yen kahanan saiki mbukak kesempatan lan prospek kanggo kita sing mbok menawa awake dhewe durung ngerti. Nanging pengalaman lan praktik sing kita lakoni saiki negesake manawa kita wis milih dalan pangembangan sing bener, kita ora bakal kantun kesempatan anyar iki ing mangsa ngarep lan bakal bisa nanggapi kanthi efektif kanggo tantangan sing bakal diadhepi Sportmaster.

temonan

Sajrone wektu sing angel iki, kita wis ngrumusake prinsip utama ing pangembangan piranti lunak, sing, miturutku, bakal cocog kanggo saben perusahaan sing ngurusi iki.

wong. Iki sing kabeh dumunung ing. Karyawan kudu seneng kerja lan ngerti tujuan perusahaan lan tujuan produk sing digarap. Lan, mesthi, bisa berkembang kanthi profesional. 

teknologi. Perusahaan kudu njupuk pendekatan sing diwasa kanggo nggarap tumpukan teknologi lan mbangun kompetensi sing dibutuhake. Iku muni banget prasaja lan ketok. Lan asring banget diabaikan.

Pangolahan. Penting kanggo ngatur karya tim produk lan pusat kompetensi kanthi bener, kanggo nggawe interaksi karo bisnis supaya bisa dadi mitra.

Umumé, kaya ngono kita bisa slamet. Tesis utama wektu kita dikonfirmasi maneh, kanthi klik bathuk

Sanajan sampeyan bisnis offline gedhe kanthi akeh toko lan akeh kutha sing sampeyan lakoni, kembangake bisnis online sampeyan. Iki ora mung saluran dodolan tambahan utawa aplikasi sing apik sing sampeyan uga bisa tuku barang (lan uga amarga pesaing uga duwe sing apik). Iki dudu ban serep mung kanggo mbantu sampeyan ngatasi badai.

Iki minangka kabutuhan mutlak. Sing ora mung kemampuan teknis lan infrastruktur sampeyan kudu disiapake, nanging uga wong lan proses sampeyan. Sawise kabeh, sampeyan bisa kanthi cepet tuku memori tambahan, papan, masang kedadean anyar, etc ing sawetara jam. Nanging wong lan proses kudu disiapake sadurunge.

Source: www.habr.com