ΠΡΠΈΠ²Π΅Ρ!
Ang pangalan ko ay Mikhail, ako ang Deputy Director ng IT sa kumpanya ng Sportmaster. Nais kong ibahagi ang kwento kung paano natin hinarap ang mga hamon na lumitaw sa panahon ng pandemya.
Sa mga unang araw ng mga bagong katotohanan, ang karaniwang offline na format ng kalakalan ng Sportmaster ay natigil, at ang pag-load sa aming online na channel, pangunahin sa mga tuntunin ng paghahatid sa address ng kliyente, ay tumaas ng 10 beses. Sa loob lamang ng ilang linggo, ginawa naming online ang isang napakalaking offline na negosyo at inangkop ang serbisyo sa mga pangangailangan ng aming mga kliyente.
Karaniwan, kung ano ang mahalagang bahagi ng aming operasyon ay naging aming pangunahing negosyo. Ang kahalagahan ng bawat online na order ay tumaas nang labis. Kinakailangang i-save ang bawat ruble na dinala ng kliyente sa kumpanya.
Upang mabilis na tumugon sa mga kahilingan ng customer, nagbukas kami ng karagdagang contact center sa pangunahing opisina ng kumpanya, at maaari na ngayong tumanggap ng humigit-kumulang 285 libong mga tawag bawat linggo. Kasabay nito, inilipat namin ang 270 na tindahan sa isang bagong contactless at ligtas na format ng pagpapatakbo, na nagpapahintulot sa mga customer na makatanggap ng mga order at empleyado upang mapanatili ang kanilang mga trabaho.
Sa panahon ng proseso ng pagbabago, nakatagpo kami ng dalawang pangunahing problema. Una, ang pag-load sa aming mga online na mapagkukunan ay tumaas nang malaki (sasabihin sa iyo ni Sergey kung paano namin ito hinarap). Pangalawa, ang daloy ng mga bihirang (pre-COVID) na operasyon ay tumaas nang maraming beses, na nangangailangan naman ng malaking halaga ng mabilis na automation. Upang malutas ang problemang ito, kinailangan naming mabilis na maglipat ng mga mapagkukunan mula sa mga lugar na dati ay pangunahing. Sasabihin sa iyo ni Elena kung paano namin ito hinarap.
Pagpapatakbo ng mga serbisyong online
Kolesnikov Sergey, responsable para sa pagpapatakbo ng online na tindahan at mga microservice
Mula sa sandaling nagsimulang magsara ang aming mga retail na tindahan sa mga bisita, nagsimula kaming magtala ng pagtaas sa mga sukatan gaya ng bilang ng mga user, ang bilang ng mga order na inilagay sa aming application, at ang bilang ng mga kahilingan sa mga application.
Bilang ng mga order mula Marso 18 hanggang Marso 31Bilang ng mga kahilingan sa mga microservice sa online na pagbabayadBilang ng mga order na inilagay sa website
Sa unang graph nakita namin na ang pagtaas ay humigit-kumulang 14 na beses, sa pangalawa - 4 na beses. Isinasaalang-alang namin ang sukatan ng oras ng pagtugon ng aming mga aplikasyon bilang ang pinakanagpapahiwatig.
Sa graph na ito nakita namin ang tugon ng mga front at application, at para sa aming sarili namin natukoy na hindi namin napansin ang anumang paglago tulad nito.
Pangunahing ito ay dahil sa ang katunayan na sinimulan namin ang paghahanda sa pagtatapos ng 2019. Ngayon ang aming mga serbisyo ay nakalaan, ang fault tolerance ay sinisiguro sa antas ng mga pisikal na server, virtualization system, docker, at mga serbisyo sa mga ito. Kasabay nito, ang kapasidad ng aming mga mapagkukunan ng server ay nagbibigay-daan sa amin na makatiis ng maraming pag-load.
Ang pangunahing tool na tumulong sa amin sa buong kwentong ito ay ang aming monitoring system. Totoo, hanggang kamakailan lamang ay wala kaming isang sistema na magbibigay-daan sa aming mangolekta ng mga sukatan sa lahat ng mga layer, mula sa antas ng pisikal na kagamitan at hardware hanggang sa antas ng mga sukatan ng negosyo.
Pormal, mayroong pagsubaybay sa kumpanya, ngunit bilang isang patakaran, ito ay nakakalat at nasa lugar ng responsibilidad ng mga partikular na departamento. Sa katunayan, kapag naganap ang isang insidente, halos hindi kami nagkakaintindihan kung ano ang eksaktong nangyari, walang komunikasyon, at madalas na humantong ito sa pagtakbo sa mga bilog upang hanapin at ihiwalay ang problema upang ito ay maayos.
Sa ilang mga punto, naisip namin at nagpasya na sapat na ang aming pagtitiis dito - kailangan namin ng isang pinag-isang sistema upang makita ang buong larawan nang buo. Ang mga pangunahing teknolohiya na kasama sa aming stack ay ang Zabbix bilang isang alerting at metrics storage center, Prometheus para sa pagkolekta at pag-iimbak ng mga sukatan ng application, Stack ELK para sa pag-log at pag-iimbak ng data mula sa buong monitoring system, pati na rin ang Grafana para sa visualization, Swagger, Docker at iba pang kapaki-pakinabang at mga bagay na pamilyar sa iyo.
Kasabay nito, ginagamit namin hindi lamang ang mga teknolohiyang magagamit sa merkado, ngunit din bumuo ng ilan sa aming sarili. Halimbawa, gumagawa kami ng mga serbisyo para sa pagsasama-sama ng mga system sa isa't isa, iyon ay, ilang uri ng API para sa pagkolekta ng mga sukatan. Dagdag pa, nagtatrabaho kami sa aming sariling mga sistema ng pagsubaybay - sa antas ng mga sukatan ng negosyo ginagamit namin ang mga pagsubok sa UI. At isang bot din sa Telegram upang ipaalam sa mga koponan.
Sinusubukan din naming gawing accessible ang monitoring system sa mga team para makapag-iisa silang makapag-imbak at makapagtrabaho sa kanilang mga sukatan, kabilang ang pag-set up ng mga alerto para sa ilang makitid na sukatan na hindi gaanong ginagamit.
Sa buong sistema, nagsusumikap kami para sa pagiging maagap at lokalisasyon ng mga insidente sa lalong madaling panahon. Bilang karagdagan, ang bilang ng aming mga microservice at system ay lumaki nang malaki kamakailan, at ang bilang ng mga pagsasama ay lumaki nang naaayon. At bilang bahagi ng pag-optimize sa proseso ng pag-diagnose ng mga insidente sa antas ng pagsasama, kami ay bumubuo ng isang sistema na nagbibigay-daan sa iyong magsagawa ng mga cross-system na pagsusuri at ipakita ang resulta, na nagbibigay-daan sa iyo upang mahanap ang mga pangunahing problema na nauugnay sa mga pag-import at pakikipag-ugnayan ng mga system sa isa't isa.
Siyempre, mayroon pa kaming puwang upang lumago at umunlad sa mga tuntunin ng mga operating system, at aktibong ginagawa namin ito. Maaari kang magbasa nang higit pa tungkol sa aming sistema ng pagsubaybay .
Mga teknikal na pagsubok
Orlov Sergey, ang pinuno ng competence center para sa web at mobile development
Mula nang magsimula ang pagsasara ng pisikal na tindahan, nakaharap kami sa iba't ibang hamon mula sa pananaw ng pag-unlad. Una sa lahat, ang load surge tulad nito. Malinaw na kung ang mga naaangkop na hakbang ay hindi ginawa, kung gayon kapag ang isang mataas na pag-load ay inilapat sa system, maaari itong maging isang kalabasa na may malungkot na putok, o ganap na pababain ang pagganap, o kahit na mawala ang pag-andar nito.
Ang pangalawang aspeto, medyo hindi gaanong halata, ay ang sistema sa ilalim ng mataas na pagkarga ay kailangang baguhin nang napakabilis, umangkop sa mga pagbabago sa mga proseso ng negosyo. Minsan ilang beses sa isang araw. Maraming mga kumpanya ang may panuntunan na kung mayroong maraming aktibidad sa marketing, hindi na kailangang gumawa ng anumang mga pagbabago sa system. Wala naman, hayaan itong gumana hangga't gumagana.
At talagang nagkaroon kami ng walang katapusang Black Friday, kung saan kinakailangan na baguhin ang system. At ang anumang error, problema, o pagkabigo sa system ay magiging napakamahal para sa negosyo.
Sa hinaharap, sasabihin ko na nakayanan namin ang mga pagsubok na ito, lahat ng mga sistema ay nakatiis sa pagkarga, madaling na-scale, at hindi kami nakaranas ng anumang pandaigdigang teknikal na pagkabigo.
Mayroong apat na haligi kung saan nakasalalay ang kakayahan ng system na makatiis sa mataas na surge load. Ang una sa mga ito ay pagsubaybay, na nabasa mo tungkol sa itaas lamang. Kung walang built-in na monitoring system, halos imposibleng makahanap ng mga bottleneck ng system. Ang isang mahusay na sistema ng pagsubaybay ay tulad ng mga damit sa bahay; ito ay dapat na kumportable at iniayon sa iyo.
Ang pangalawang aspeto ay pagsubok. Sineseryoso namin ang puntong ito: nagsusulat kami ng mga klasikong unit, mga pagsubok sa pagsasama, mga pagsubok sa pag-load at marami pang iba para sa bawat system. Nagsusulat din kami ng diskarte sa pagsubok, at kasabay nito ay sinusubukang taasan ang antas ng pagsubok hanggang sa punto na hindi na namin kailangan ng mga manu-manong pagsusuri.
Ang ikatlong haligi ay CI/CD Pipeline. Ang mga proseso ng pagbuo, pagsubok, at pag-deploy ng isang application ay dapat na awtomatiko hangga't maaari; walang dapat manu-manong interbensyon. Ang paksa ng CI/CD Pipeline ay medyo malalim, at tatalakayin ko lang ito saglit. Nararapat lamang na banggitin na mayroon kaming CI/CD Pipeline checklist, na pinagdadaanan ng bawat pangkat ng produkto sa tulong ng mga competency center.
At narito ang checklist
Sa ganitong paraan, maraming mga layunin ang nakakamit. Ito ay API versioning at feature toggle upang maiwasan ang pagpapakawala ng tren, at pagkamit ng saklaw ng iba't ibang pagsubok sa antas na ganap na awtomatiko ang pagsubok, tuluy-tuloy ang mga deployment, at iba pa.
Ang ikaapat na haligi ay ang mga prinsipyo sa arkitektura at mga teknikal na solusyon. Marami tayong maaring pag-usapan tungkol sa arkitektura sa mahabang panahon, ngunit gusto kong bigyang-diin ang ilang mga prinsipyo na gusto kong pagtuunan ng pansin.
Una, kailangan mong pumili ng mga espesyal na tool para sa mga partikular na gawain. Oo, parang halata, at malinaw na ang mga pako ay dapat ipasok gamit ang martilyo, at ang mga wristwatches ay dapat i-disassemble gamit ang mga espesyal na screwdriver. Ngunit sa ating edad, maraming tool ang nagsusumikap para sa universalization upang masakop ang maximum na segment ng mga user: mga database, cache, frameworks at iba pa. Halimbawa, kung kukuha ka ng database ng MongoDB, gumagana ito sa mga transaksyong maraming dokumento, at gumagana ang database ng Oracle sa json. At tila lahat ay magagamit para sa lahat. Ngunit kung manindigan tayo para sa pagiging produktibo, kailangan nating malinaw na maunawaan ang mga kalakasan at kahinaan ng bawat tool at gamitin ang mga kailangan natin para sa ating klase ng mga gawain.
Pangalawa, kapag nagdidisenyo ng mga sistema, ang bawat pagtaas sa pagiging kumplikado ay dapat na makatwiran. Dapat nating palaging isaisip ito; ang prinsipyo ng mababang pagkabit ay alam ng lahat. Naniniwala ako na dapat itong ilapat sa antas ng isang partikular na serbisyo, at sa antas ng buong sistema, at sa antas ng landscape ng arkitektura. Mahalaga rin ang kakayahang pahalang na sukatin ang bawat bahagi ng system kasama ang landas ng pagkarga. Kung mayroon kang ganitong kakayahan, hindi magiging mahirap ang pag-scale.
Sa pagsasalita tungkol sa mga teknikal na solusyon, hiniling namin sa mga team ng produkto na maghanda ng bagong hanay ng mga rekomendasyon, ideya at solusyon, na ipinatupad nila bilang paghahanda para sa susunod na wave ng workload.
Keshi
Kinakailangan na sinasadya na lapitan ang pagpili ng mga lokal at ipinamamahagi na mga cache. Minsan makatuwirang gamitin ang pareho sa loob ng iisang system. Halimbawa, mayroon kaming mga system kung saan ang ilan sa data ay isang showcase cache, ibig sabihin, ang pinagmulan ng mga update ay nasa likod mismo ng system, at hindi nagbabago ang mga system ang datos na ito. Para sa diskarteng ito gumagamit kami ng lokal na Caffeine Cache.
At mayroong data na aktibong nagbabago ang system sa panahon ng operasyon, at narito na kami ay gumagamit ng isang ipinamamahagi na cache kasama ang Hazelcast. Binibigyang-daan kami ng diskarteng ito na gamitin ang mga benepisyo ng isang naka-distribute na cache kung saan talagang kailangan ang mga ito, at bawasan ang mga gastos sa serbisyo ng pagpapalipat-lipat ng data ng cluster ng Hazelcast kung saan magagawa namin nang wala ito. Marami na kaming naisulat tungkol sa mga cache. ΠΈ .
Bilang karagdagan, ang pagpapalit ng serializer sa Kryo sa Hazelcast ay nagbigay sa amin ng magandang tulong. At ang paglipat mula sa ReplicatedMap patungong IMap + Near Cache sa Hazelcast ay nagbigay-daan sa amin na bawasan ang paggalaw ng data sa buong cluster.
Isang maliit na payo: sa kaso ng mass cache invalidation, ang taktika ng pag-init ng pangalawang cache at pagkatapos ay lumipat dito ay minsan naaangkop. Tila na sa pamamaraang ito ay dapat tayong makakuha ng dobleng pagkonsumo ng memorya, ngunit sa pagsasagawa, sa mga sistema kung saan ito ginawa, bumababa ang pagkonsumo ng memorya.
Reaktibong stack
Ginagamit namin ang reactive stack sa medyo malaking bilang ng mga system. Sa aming kaso, ito ay Webflux o Kotlin na may mga coroutine. Ang reactive stack ay lalong maganda kung saan inaasahan namin ang mabagal na input-output operations. Halimbawa, ang mga tawag sa mabagal na serbisyo, nagtatrabaho sa file system o storage system.
Ang pinakamahalagang prinsipyo ay upang maiwasan ang pagharang ng mga tawag. Ang mga reaktibong framework ay may maliit na bilang ng mga live na thread ng serbisyo na tumatakbo sa ilalim ng hood. Kung pabayaan natin ang ating sarili na gumawa ng direktang pagharang na tawag, tulad ng tawag sa driver ng JDBC, hihinto lang ang system.
Subukang gawing iyong sariling runtime exception ang mga error. Ang aktwal na daloy ng pagpapatupad ng programa ay lumilipat sa mga reaktibong framework, at ang code execution ay nagiging nonlinear. Bilang resulta, napakahirap mag-diagnose ng mga problema gamit ang mga stack traces. At ang solusyon dito ay ang lumikha ng malinaw, layunin na runtime exception para sa bawat error.
Elasticsearch
Kapag gumagamit ng Elasticsearch, huwag pumili ng hindi nagamit na data. Ito, sa prinsipyo, ay napakasimpleng payo din, ngunit kadalasan ito ang nakalimutan. Kung kailangan mong pumili ng higit sa 10 libong mga tala sa isang pagkakataon, kailangan mong gumamit ng Scroll. Upang gumamit ng isang pagkakatulad, ito ay medyo tulad ng isang cursor sa isang relational database.
Huwag gumamit ng postfilter maliban kung kinakailangan. Sa malaking data sa pangunahing sample, ang operasyong ito ay lubos na naglo-load sa database.
Gumamit ng maramihang pagpapatakbo kung saan naaangkop.
API
Kapag nagdidisenyo ng API, isama ang mga kinakailangan para sa pagliit ng ipinadalang data. Ito ay totoo lalo na kaugnay sa harap: sa junction na ito kami ay lumalampas sa mga channel ng aming mga data center at nagtatrabaho na sa channel na nagkokonekta sa amin sa kliyente. Kung ito ay may kaunting problema, masyadong maraming trapiko ay nagdudulot ng negatibong karanasan ng user.
At sa wakas, huwag magtapon ng isang buong bungkos ng data, maging malinaw tungkol sa kontrata sa pagitan ng mga consumer at supplier.
Pagbabago ng organisasyon
Eroshkina Elena, Deputy Director para sa IT
Sa sandaling nangyari ang kuwarentenas, at ang pangangailangan ay lumitaw upang mabilis na pataasin ang bilis ng online na pag-unlad at ipakilala ang mga serbisyo ng omnichannel, nasa proseso na tayo ng pagbabagong organisasyon.
Ang bahagi ng aming istraktura ay inilipat sa trabaho ayon sa mga prinsipyo at kasanayan ng diskarte sa produkto. Ang mga koponan ay nabuo na ngayon ay responsable para sa pagpapatakbo at pagbuo ng bawat produkto. Ang mga empleyado sa naturang mga team ay 100% na kasangkot at binubuo ang kanilang trabaho gamit ang Scrum o Kanban, depende sa kung ano ang mas gusto sa kanila, pag-set up ng pipeline ng deployment, pagpapatupad ng mga teknikal na kasanayan, mga kasanayan sa pagtiyak ng kalidad, at marami pa.
Sa kabutihang palad, ang karamihan sa aming mga pangkat ng produkto ay nasa lugar ng mga serbisyong online at omnichannel. Nagpahintulot ito sa amin na lumipat sa remote work mode sa pinakamaikling posibleng oras (seryoso, literal sa loob ng dalawang araw) nang walang pagkawala ng kahusayan. Ang customized na proseso ay nagbigay-daan sa amin na mabilis na umangkop sa mga bagong kondisyon sa pagtatrabaho at mapanatili ang medyo mataas na bilis ng paghahatid ng bagong functionality.
Bilang karagdagan, kailangan nating palakasin ang mga koponan na nasa hangganan ng online na negosyo. Sa sandaling iyon ay naging malinaw na magagawa lamang natin ito gamit ang mga panloob na mapagkukunan. At humigit-kumulang 50 tao sa loob ng dalawang linggo ang nagbago sa lugar kung saan sila nagtrabaho noon at nasangkot sa paggawa sa isang produkto na bago sa kanila.
Hindi ito nangangailangan ng anumang espesyal na pagsusumikap sa pamamahala, dahil kasama ang pag-aayos ng sarili naming proseso, teknikal na pagpapabuti ng produkto, at mga kasanayan sa pagtitiyak ng kalidad, tinuturuan namin ang aming mga koponan na ayusin ang sarili - upang pamahalaan ang kanilang sariling proseso ng produksyon nang hindi kinasasangkutan ng mga mapagkukunang pang-administratibo.
Nagawa naming ituon ang aming mga mapagkukunan ng pamamahala nang eksakto kung saan ito kinakailangan sa sandaling iyon - sa pakikipag-ugnayan kasama ang negosyo: Ano ang mahalaga para sa aming kliyente sa ngayon, kung anong functionality ang dapat unang ipatupad, kung ano ang kailangang gawin upang mapataas ang aming kakayahan sa throughput para maghatid at magproseso ng mga order. Ang lahat ng ito at ang isang malinaw na modelo ng papel ay naging posible sa panahong ito na i-load ang aming mga stream ng halaga ng produksyon ng kung ano ang talagang mahalaga at kailangan.
Malinaw na sa malayong trabaho at isang mataas na bilis ng pagbabago, kapag ang mga tagapagpahiwatig ng negosyo ay nakasalalay sa pakikilahok ng lahat, hindi ka maaaring umasa lamang sa mga panloob na damdamin mula sa seryeng "Ang lahat ba ay maayos sa amin? Oo, mukhang masarap." Ang mga layunin na sukatan ng proseso ng produksyon ay kinakailangan. Mayroon kaming mga ito, magagamit ang mga ito sa sinumang interesado sa mga sukatan ng mga pangkat ng produkto. Una sa lahat, ang koponan mismo, ang negosyo, mga subcontractor at pamamahala.
Minsan bawat dalawang linggo, may idinaraos na status sa bawat team, kung saan sinusuri ang mga sukatan sa loob ng 10 minuto, natukoy ang mga bottleneck sa proseso ng produksyon at nabuo ang isang pinagsamang solusyon: kung ano ang maaaring gawin upang maalis ang mga bottleneck na ito. Dito maaari kang agad na humingi ng tulong mula sa pamamahala kung ang anumang natukoy na problema ay nasa labas ng zone of influence ng mga koponan, o ang kadalubhasaan ng mga kasamahan na maaaring nakatagpo na ng katulad na problema.
Gayunpaman, naiintindihan namin na upang mapabilis nang maraming beses (at ito mismo ang layunin na itinakda namin para sa aming sarili), kailangan pa rin naming matutunan ang maraming at ipatupad ito sa aming pang-araw-araw na gawain. Sa ngayon ay patuloy naming pinapalaki ang aming diskarte sa produkto sa iba pang mga koponan at mga bagong produkto. Upang gawin ito, kailangan naming makabisado ang isang bagong format para sa amin - isang online na paaralan ng mga metodologo.
Ang mga metodologo, mga taong tumutulong sa mga koponan na bumuo ng isang proseso, magtatag ng mga komunikasyon, at mapabuti ang kahusayan sa trabaho, ay mahalagang mga ahente ng pagbabago. Sa ngayon, ang mga nagtapos sa aming unang cohort ay nakikipagtulungan sa mga koponan at tinutulungan silang maging matagumpay.
Sa tingin ko, ang kasalukuyang sitwasyon ay nagbubukas ng mga pagkakataon at mga prospect para sa atin na marahil ay hindi pa natin lubos na nalalaman. Ngunit ang karanasan at kasanayan na natatamo natin ngayon ay nagpapatunay na pinili natin ang tamang landas ng pag-unlad, hindi natin palalampasin ang mga bagong pagkakataong ito sa hinaharap at magagawa nating tumugon nang kasing epektibo sa mga hamon na haharapin ng Sportmaster.
Natuklasan
Sa mahirap na oras na ito, nabuo namin ang mga pangunahing prinsipyo kung saan nakasalalay ang pagbuo ng software, na, sa palagay ko, ay magiging may-katuturan para sa bawat kumpanya na tumatalakay dito.
Mga tao. Dito nakasalalay ang lahat. Dapat tangkilikin ng mga empleyado ang kanilang trabaho at maunawaan ang mga layunin ng kumpanya at ang mga layunin ng mga produkto na kanilang pinagtatrabahuhan. At, siyempre, maaari silang bumuo ng propesyonal.
Π’Π΅Ρ Π½ΠΎΠ»ΠΎΠ³ΠΈΡ. Ito ay kinakailangan para sa kumpanya na kumuha ng isang mature na diskarte sa pagtatrabaho sa kanyang teknolohiya stack at bumuo ng mga kakayahan kung saan ito ay talagang kinakailangan. Ito ay napaka-simple at halata. At madalas na hindi pinapansin.
Ang mga proseso. Mahalagang maayos na ayusin ang gawain ng mga pangkat ng produkto at mga sentro ng kakayahan, upang magtatag ng pakikipag-ugnayan sa negosyo upang makatrabaho ito bilang isang kasosyo.
Sa pangkalahatan, iyan ay halos kung paano kami nakaligtas. Ang pangunahing tesis ng ating panahon ay muling nakumpirma, na may isang matunog na pag-click sa noo
Kahit na ikaw ay isang malaking offline na negosyo na may maraming mga tindahan at isang grupo ng mga lungsod kung saan ka nagpapatakbo, bumuo ng iyong online na negosyo. Ito ay hindi lamang isang karagdagang channel sa pagbebenta o isang magandang application kung saan maaari ka ring bumili ng isang bagay (at dahil din sa mga kakumpitensya ay mayroon ding magaganda). Hindi ito basta-basta na ekstrang gulong para tulungan kang madaig ang bagyo.
Ito ay isang ganap na pangangailangan. Para sa kung saan hindi lamang ang iyong mga teknikal na kakayahan at imprastraktura ay dapat na ihanda, kundi pati na rin ang iyong mga tao at proseso. Pagkatapos ng lahat, mabilis kang makakabili ng karagdagang memorya, espasyo, mag-deploy ng mga bagong pagkakataon, atbp. sa loob ng ilang oras. Ngunit ang mga tao at proseso ay kailangang maging handa para dito nang maaga.
Pinagmulan: www.habr.com