Прывітанне!
Мяне клічуць Міхаіл, я намеснік дырэктара па ІТ у кампаніі «Спортмайстар». Я хачу падзяліцца гісторыяй аб тым, як мы справіліся з цяжкасцямі, якія ўзніклі падчас пандэміі.
У першыя дні новых рэалій звыклы фармат афлайн-гандлю «Спортмайстра» замёр, і нагрузка на наш анлайн-канал, у першую чаргу ў частцы дастаўкі на адрас кліенту, узрасла ў 10 разоў. За некалькі тыдняў мы трансфармавалі гіганцкі па аб'ёме афлайн-бізнэс у анлайн, адаптавалі сэрвіс пад патрэбы нашых кліентаў.
Увогуле тое, што па сутнасці было нашай другараднай аперацыяй, стала асноўным бізнесам. Важнасць кожнага інтэрнет-заказу ўзрасла экстрэмальна. Трэба было захаваць кожны рубель, які кліент прыносіў у кампанію.
Каб аператыўна рэагаваць на запыты кліентаў, мы адкрылі дадатковы кантактны цэнтр у галоўным офісе кампаніі, і зараз можам прымаць каля 285 тысяч званкоў у тыдзень. У той жа час мы перавялі 270 крам у новы фармат бескантактавай і бяспечнай працы, што дазволіла кліентам атрымліваць замовы, а супрацоўнікам захаваць працоўныя месцы.
У працэсе трансфармацыі ў нас узніклі дзве асноўныя праблемы. Па-першае, адчувальна ўзрасла нагрузка на нашы анлайн-рэсурсы (як мы змагаліся з гэтым, раскажа Сяргей). Па-другое, паток рэдкіх (да COVID) аперацый шматкроць узрос, што ў сваю чаргу запатрабавала вялікага аб'ёму хуткай аўтаматызацыі. Каб вырашыць гэтую праблему, нам прыйшлося аператыўна перакінуць рэсурсы з напрамкаў, якія былі раней асноўнымі. Як мы справіліся з гэтым - раскажа Алена.
Эксплуатацыя анлайн-сэрвісаў
Калеснікаў Сяргей, адказвае за эксплуатацыю інтэрнэт-крамы і мікрасэрвісаў
З таго моманту, як нашы рознічныя крамы пачалі зачыняцца для наведвальнікаў, мы пачалі фіксаваць рост такіх метрык, як колькасць карыстальнікаў, колькасць заказаў, якія афармляюцца ў нашым дадатку, колькасць рэквестаў да прыкладанняў.
Колькасць заказаў з 18 па 31 сакавікаКолькасць запытаў да мікрасэрвісаў анлайн-аплатыКолькасць аформленых на сайце заказаў
На першым графіку мы бачым, што прырост склаў прыкладна 14 разоў, на другім - 4 разы. Найбольш паказальнай пры гэтым мы лічым метрыку часу адказу нашых прыкладанняў.
На гэтым графіку мы бачым адказ франтоў і дадаткаў, і для сябе мы вызначылі, што як такога росту мы не заўважылі.
У першую чаргу гэта звязана з тым, што мы распачалі падрыхтоўчыя работы ў канцы 2019 года. Цяпер нашы сэрвісы зарэзерваваны, забяспечана адмоваўстойлівасць на ўзроўні фізічных сервераў, сістэм віртуалізацыі, докераў, сэрвісаў у іх. Пры гэтым магутнасці нашых серверных рэсурсаў дазваляюць перажываць шматразовую нагрузку.
Асноўнай прыладай, які дапамог нам ва ўсёй гэтай гісторыі, стала наша сістэма маніторынгу. Праўда, яшчэ зусім нядаўна ў нас не было адзінай сістэмы, якая дазваляла б збіраць метрыкі на ўсіх пластах, ад узроўня фізічнага абсталявання і апаратнага забеспячэння да ўзроўня бізнэс-метрык.
Фармальна маніторынг-то ў кампаніі быў, але як правіла ён быў раззасяроджаны і знаходзіўся ў зоне адказнасці канкрэтных падраздзяленняў. Фактычна, калі адбываўся які-небудзь інцыдэнт, у нас амаль ніколі не было адзінага разумення, што ж менавіта адбылося, не было інфармавання, і часцяком гэта прыводзіла да бегу па коле ў пошуках і лакалізацыі праблемы для наступнага ўхілення.
У нейкі момант мы падумалі і вырашылі, што хопіць гэта трываць - нам патрэбная адзіная сістэма, каб бачыць усю карціну цалкам. Асноўныя тэхналогіі, якія ўваходзяць у наш стэк, гэта Zabbix як цэнтр алертынгу і захоўвання метрык, Prometheus для збору і захоўвання метрык прыкладанняў, Stack ELK для лагавання і захоўвання дадзеных усёй сістэмы маніторынгу, а таксама Grafana для візуалізацыі, Swagger, Docker і іншыя карысныя і знаёмыя вам штукі.
Пры гэтым мы выкарыстоўваем не толькі даступныя на рынку тэхналогіі, але і распрацоўваем сёе-тое самастойна. Напрыклад, мы робім сэрвісы для інтэграцыі сістэм адзін з адным, гэта значыць нейкае API для збору метрык. Плюс працуем над уласнымі сістэмамі маніторынгу - на ўзроўні бізнес-метрык мы выкарыстоўваем UI-тэсты. А таксама бот у Telegram для абвесткі каманд.
А яшчэ мы імкнемся рабіць сістэму маніторынгу даступнай для каманд, каб яны маглі самастойна захоўваць свае метрыкі і працаваць з імі, у тым ліку настройваць алертынг у нейкіх вузкіх метрыках, якія маюць значэнне не самае шырокае прымяненне.
У рамках усёй сістэмы мы імкнемся да проактивности і максімальна хуткай лакалізацыі інцыдэнтаў. Да таго ж, колькасць нашых мікрасэрвісаў і сістэм значна вырасла за апошні час, адпаведна, расце і колькасць інтэграцый. І ў рамках аптымізацыі працэсу дыягностыкі інцыдэнтаў на ўзроўні інтэграцыі мы распрацоўваем сістэму, якая дазваляе праводзіць крос-сістэмныя праверкі і выводзіць вынік, што дазваляе знаходзіць асноўныя праблемы, злучаныя з імпартамі і ўзаемадзеяннем сістэм сябар з сябрам.
Само сабой, нам яшчэ ёсць куды расці і развівацца ў плане эксплуатацыі сістэм, і мы актыўна над гэтым працуем. Падрабязней пра нашу сістэму маніторынгу можна пачытаць .
Тэхнічныя выпрабаванні
Арлоў Сяргей, кіруе цэнтрам кампетэнцыі вэб-і мабільнай распрацоўкі
З пачатку закрыцця фізічных крам нам прыйшлося сутыкнуцца з рознымі выпрабаваннямі з пункту гледжання распрацоўкі. У першую чаргу, скачок нагрузкі як такой. Зразумела, што калі не прадпрынятыя адпаведныя меры, то пры падачы на сістэму высокай нагрузкі яна можа з сумнай бавоўнай ператварыцца ў гарбуз, альбо цалкам дэградаваць у прадукцыйнасці, альбо ўвогуле страціць сваю працаздольнасць.
Другі аспект, крыху менш відавочны, складаецца ў тым, што сістэму пад высокай нагрузкай трэба было вельмі хутка мяняць, адаптуючыся пад змены бізнес-працэсаў. Часам па некалькі разоў на дзень. У шматлікіх кампаніях ёсць правіла, што пры вялікіх маркетынгавых актыўнасцях не варта ўносіць у сістэму ніякіх змен. Наогул ніякіх, няхай працуе, раз працуе.
А ў нас па сутнасці была бясконцая чорная пятніца, у якую пры гэтым трэба было мяняць сістэму. І любая памылка, праблема, збой у сістэме вельмі дорага абыходзіліся б бізнэсу.
Забягаючы наперад, скажу, што нам удалося справіцца з гэтымі выпрабаваннямі, усе сістэмы вытрымалі нагрузку, лёгка адмаштабіраваліся і нейкіх глабальных тэхнічных збояў у нас не было.
Існуе чатыры кіта, на якіх трымаецца здольнасць сістэмы вытрымліваць высокую скачкападобна нагрузку. Першы з іх - гэта маніторынг, пра які вы чыталі крыху вышэй. Без пабудаванай сістэмы маніторынгу практычна немагчыма вызначыць вузкія месцы сістэмы. Добрая сістэма маніторынгу - гэта як хатняе адзенне, яна павінна быць зручнай і адаптаванай пад вас.
Другі аспект - гэта тэсціраванне. Мы вельмі сур'ёзна ставімся да гэтага моманту: пішам і класічныя юніты, інтэграцыйныя, нагрузачныя тэсты і многія іншыя для кожнай сістэмы. Яшчэ мы пішам стратэгію тэсціравання, і пры гэтым стараемся давесці ўзровень тэсціравання да таго, каб ручныя праверкі нам больш не былі патрэбны.
Трэці кіт - гэта CI/CD Pipeline. Працэсы зборкі, тэсціравання, разгортвання прыкладання павінны быць максімальна аўтаматызаваны, тут не павінна быць ручных умяшанняў. Тэма CI/CD Pipeline досыць глыбокая, і я закрану яе толькі мімаходзь. Варта згадаць толькі, што ў нас ёсць чэкліст CI/CD Pipeline, па якім з дапамогай цэнтраў кампетэнцыі праходзіць кожная прадуктовая каманда.
А вось і чэкліст
Такім чынам дасягаецца вельмі шмат мэт. Гэта версіяванне API, і feature toggle, каб пазбегнуць паравоза рэлізаў, і дасягненне пакрыцця розных тэстаў такога ўзроўню, каб тэсціраванне было цалкам аўтаматызавана, дэплоі былі бясшвоўнымі і іншае.
Чацвёрты кіт - гэта архітэктурныя прынцыпы і тэхнічныя рашэнні. Пра архітэктуру можна казаць шмат і доўга, але я хачу падкрэсліць пару прынцыпаў, на якіх я хацеў бы засяродзіць увагу.
Па-першае, трэба выбіраць спецыялізаваныя прылады пад пэўныя задачы. Так, гучыць відавочна, і зразумела, што цвікі забіваць варта малатком, а наручны гадзіннік разбіраць спецыяльнымі адвёрткамі. Але ў наша стагоддзе шматлікія прылады імкнуцца да ўніверсалізацыі, каб ахапіць максімальны сегмент карыстачоў: базы дадзеных, кэшы, фрэймворкі і астатняе. Вось, напрыклад, калі ўзяць базу дадзеных MongoDB, яна працуе з мультыдакументарнымі транзакцыямі, а база дадзеных Oracle працуе з json-мі. І здавалася б, што ўсё можна выкарыстоўваць для ўсяго. Але калі мы выступаем за прадукцыйнасць, то нам трэба дакладна разумець моцныя і слабыя бакі кожнага інструмента і выкарыстоўваць патрэбныя нам для нашага класа задач.
Па-другое, пры праектаванні сістэм кожнае павышэнне складанасці павінна быць абгрунтаваным. Мы павінны ўвесь час трымаць гэта ў галаве, прынцып low coupling усім вядомы. Я лічу, што яго трэба прымяняць і на ўзроўні канкрэтнага сэрвісу, і на ўзроўні ўсёй сістэмы, і на ўзроўні архітэктурнага ландшафту. Таксама важная здольнасць да гарызантальнага маштабавання кожнага кампанента сістэмы на шляхі нагрузкі. Калі валодаць гэтай здольнасцю, маштабаванне не складзе ніякай працы.
Калі казаць пра тэхнічныя рашэнні, мы папыталі прадуктовыя каманды падрыхтаваць свежы набор рэкамендацый, ідэй і рашэнняў, якія яны рэалізавалі падчас падрыхтоўкі да чарговай хвалі нагрузкі.
Кешы
Неабходна свядома падыходзіць да выбару лакальных і размеркаваных кэшаў. Часам мае сэнс выкарыстоўваць і тыя, і іншыя ў рамках адной сістэмы, Напрыклад, у нас ёсць сістэмы, у якіх частка дадзеных па сутнасці з'яўляецца вітрынным кэшам, гэта значыць крыніца абнаўленняў знаходзіцца за самой сістэмай, і сістэмы гэтыя дадзеныя не мяняюць. Для такога падыходу мы выкарыстоўваем лакальны Caffeine Cache.
А ёсць дадзеныя, якія сістэма актыўна змяняе падчас прац, і тут мы ўжо ўжываем размеркаваны кэш з Hazelcast. Такі падыход дазваляе нам выкарыстоўваць перавагі размеркаванага кэша там, дзе яны сапраўды патрэбныя, і мінімізаваць сэрвісныя выдаткі па цыркуляцыі дадзеных кластара Hazelcast там, дзе мы можам без гэтага абысціся. Пра кэшы мы шмат пісалі и .
Акрамя таго, змена серыялізатара на Kryo у Hazelcast дала нам нядрэнны прырост. А пераход ад ReplicatedMap да IMap + Near Cache у Hazelcast дазволіў нам мінімізаваць рух дадзеных па кластары.
Невялікая рада: пры масавай інвалідацыі кэша часам дастасавальная тактыка з прагрэвам другога кэша з наступным пераключэннем на яго. Здавалася б, пры такім падыходзе мы павінны атрымаць падвойнае спажыванне памяці, але на практыку, у тых сістэмах, дзе падобнае практыкавалася, спажыванне памяці памяншалася.
Рэактыўны стэк
Мы выкарыстоўваем рэактыўны стэк ва ўжо дастаткова вялікай колькасці сістэм. У нашым выпадку гэта Webflux або Kotlin з каруцінамі. Асабліва добра рэактыўны стэк заходзіць там, дзе мы чакаем павольныя input-output аперацыі. Напрыклад, выклікі павольных сэрвісаў, праца з файлавай сістэмай ці сістэмамі захоўвання.
Найбольш важны прынцып - пазбягаць блакавальных выклікаў. Пад капотам рэактыўных фрэймворкаў круціцца невялікая колькасць жывых сэрвісных патокаў. Калі мы неасцярожна дазволім сабе зрабіць прамы блакуючы выклік, як, напрыклад, выклік JDBC-драйвера, то сістэма проста спыніцца.
Імкніцеся звяртаць памылкі ва ўласныя runtime exception. Рэальны струмень выканання праграмы адыходзіць да рэактыўных фрэймворкаў, выкананне кода становіцца нелінейным. Як следства, вельмі складана дыягнаставаць праблемы па стэк-трэйсах. І рашэннем тут будзе стварэнне зразумелых аб'ектыўных runtime exception-аў на кожную памылку.
Elasticsearch
Пры выкарыстанні Elasticsearch не выбіраць невыкарыстоўваныя дадзеныя. Гэта, у прынцыпе, таксама вельмі простая рада, але часцей за ўсё менавіта пра гэта забываюць. Калі трэба за раз абраць больш за 10 тысяч запісаў, трэба выкарыстоўваць Scroll. Калі праводзіць аналогію, гэта крыху падобна на курсор у рэляцыйнай базе дадзеных.
Не выкарыстоўвайце postfilter без неабходнасці. Пры вялікіх дадзеных у асноўнай выбарцы гэтая аперацыя вельмі моцна грузіць базу дадзеных.
Выкарыстоўвайце bulk-аперацыі там, дзе гэта дастасавальна.
API
Пры праектаванні API закладвайце патрабаванні да мінімізацыі перадаваных дадзеных. Асабліва гэта актуальна на звязку з фронтам: менавіта на гэтым стыку мы выходзім за каналы нашых ЦАДаў і ўжо працуем на канале, які злучае нас з кліентам. Калі на ім ёсць найменшыя праблемы, занадта высокі трафік выклікае негатыўны user experience.
І, нарэшце, не вывальвайце ўвесь стос дадзеных, выразна падыходзьце да кантракту паміж спажыўцамі і пастаўшчыкамі.
Арганізацыйная трансфармацыя
Ярошкіна Алена, намеснік дырэктара па ІТ
У момант, калі здарыўся каранцін, і ўзнікла неабходнасць рэзка нарошчваць тэмпы развіцця анлайн і ўкараняць амніканальныя сэрвісы, мы ўжо знаходзіліся ў працэсе арганізацыйнай трансфармацыі.
Частка нашай структуры была пераведзена на працу па прынцыпах і практыкам прадуктовага падыходу. Сфармаваліся каманды, якія зараз адказваюць за функцыянаванне і развіццё кожнага прадукта. Супрацоўнікі ў такіх камандах задзейнічаны на 100% і будуюць сваю працу па скрам або канбан, у залежнасці ад таго, што для іх пераважней, наладжваюць канвеер разгортвання, укараняюць тэхнічныя практыкі, практыкі забеспячэння якасці і шматлікае іншае.
Па шчаслівай выпадковасці асноўная частка такіх прадуктовых каманд у нас як раз знаходзілася ў вобласці анлайн і амніканальных сэрвісаў. Гэта дазволіла нам у найкароткія тэрміны (сур'ёзна, літаральна за два дні) перайсці ў рэжым выдаленай працы без страты эфектыўнасці. Наладжаны працэс дазволіў хутка адаптавацца да новых умоў працы і вытрымаць дастаткова высокі тэмп пастаўкі новай функцыянальнасці.
Акрамя таго, у нас узнікла неабходнасць узмацніць тыя каманды, якія знаходзяцца на фронціры анлайн-бізнэсу. У той момант стала зразумела, што мы можам гэта зрабіць толькі за рахунак унутраных рэсурсаў. І каля 50 чалавек за два тыдні змянілі вобласць, дзе яны працавалі да гэтага, і ўбудаваліся ў працу над новым для іх прадуктам.
Для гэтага не запатрабавалася нейкіх спецыяльных кіраўніцкіх намаганняў, таму як нараўне з арганізацыяй уласнага працэсу, з тэхнічным удасканаленнем прадукта, з практыкай забеспячэння якасці, мы вучым нашы каманды самаарганізацыі - кіраваць уласным вытворчым працэсам без прыцягнення адміністрацыйнага рэсурсу.
Кіраўніцкі ж рэсурс мы змаглі сфакусаваць менавіта там, дзе гэта было неабходна ў той момант, - на каардынацыі разам з бізнесам: Што ж менавіта цяпер важна для нашага кліента, якая функцыянальнасць павінна быць рэалізавана ў першую чаргу, што неабходна зрабіць, каб павялічыць нашу прапускную здольнасць па дастаўцы і апрацоўцы заказаў. Усё гэта і выразная ролевая мадэль дазволілі ў гэты перыяд нагружаць нашыя вытворчыя струмені стварэння каштоўнасці тым, што сапраўды важна і трэба.
Зразумелая справа, што пры выдаленай працы і высокім тэмпе змен, калі ад удзелу кожнага залежаць бізнэс-паказчыкі, нельга спадзявацца толькі на ўнутраныя адчуванні з серыі «А ці ўсё ў нас ідзе добра? Ды накшталт нядрэнна». Неабходны аб'ектыўныя метрыкі вытворчага працэсу. Такія ў нас ёсць, яны даступныя кожнаму, хто цікавіцца метрыкамі прадуктовых каманд. Найперш самой камандзе, бізнэсу, сумежнікам і кіраўніцтву.
Раз на два тыдні з кожнай камандай праводзіцца статус, дзе на працягу 10 хвілін аналізуюцца метрыкі, выяўляюцца вузкія месцы вытворчага працэсу і выпрацоўваецца сумеснае рашэнне: што можна зрабіць для таго, каб гэтыя вузкія месцы ўстараніць. Тут жа можна адразу папрасіць дапамогі ў кіраўніцтва ў выпадку, калі нейкая выяўленая праблема знаходзіцца па-за зонай уплыву каманд, ці экспертызы калегаў, якія, магчыма, ужо сутыкаліся з падобнай праблемай.
Тым не менш, мы разумеем, што для кратнага паскарэння (а менавіта такую мэту мы сабе ставім) нам яшчэ шмат чаму неабходна навучыцца і ўкараніць у штодзённую працу. Прама зараз мы працягваем маштабаванне прадуктовага падыходу на іншыя каманды і на новыя прадукты. Для гэтага нам прыйшлося асвоіць новы для нас фармат анлайн-школы метадолагаў.
Метадалогі, людзі якія дапамагаюць камандам выбудоўваць працэс, наладжваць камунікацыі, павялічваць эфектыўнасць працы, па сутнасці з'яўляюцца агентамі змены. Прама зараз выпускнікі нашага першага патоку працуюць з камандамі і дапамагаюць ім стаць паспяховымі.
Я думаю, што існуючая сітуацыя адкрывае для нас такія магчымасці і перспектывы, якія, магчыма, мы і самі пакуль яшчэ да канца не ўсведамляем. Але той досвед і тая практыка, якую мы атрымліваем прама цяпер, пацвярджае, што мы абралі правільны шлях развіцця, не выпусцім у будучыні гэтыя новыя магчымасці і зможам гэтак жа эфектыўна адказваць на тыя выклікі, якія будуць стаяць перад «Спортмайстрам».
Высновы
За гэты няпросты час мы сфармулявалі галоўныя прынцыпы, на якіх трымаецца распрацоўка праграмнага забеспячэння, якія, думаю, будуць актуальныя для кожнай кампаніі, якая гэтым займаецца.
Людзі. Гэта тое, на чым усё і трымаецца. Супрацоўнікі павінны атрымліваць задавальненне ад працы, разумець мэты кампаніі і мэты прадуктаў, якімі яны займаюцца. І, канешне ж, маглі прафесійна развівацца.
Тэхналогія. Неабходна, каб кампанія спела падыходзіла да працы са сваім тэхналагічным стэкам і нарошчвала кампетэнцыі там, дзе гэта сапраўды неабходна. Гучыць вельмі проста і відавочна. І вельмі часта ігнаруецца.
працэсы. Важна правільна выбудаваць працу прадуктовых каманд і цэнтраў кампетэнцый, наладзіць узаемадзеянне з бізнесам, каб працаваць з ім як з партнёрам.
Увогуле, прыкладна так і выжылі. Асноўная тэза сучаснасці пацвердзілася яшчэ раз, звонка пстрыкнуўшы па лбе
Нават калі ты - велізарны афлайн-бізнэс са мноствам крам і кучай гарадоў прысутнасці, развівай свой анлайн. Гэта не проста дадатковы канал збыту або прыгожае прыкладанне, праз якое таксама можна нешта купіць (а яшчэ таму, што ў канкурэнтаў таксама прыгожае). Гэта не запаска на ўсялякі выпадак, якая дапаможа перачакаць буру.
Гэта неабходнасць. Да якой павінны быць гатовы не толькі вашыя тэхнічныя магутнасці і інфраструктура, але і людзі і працэсы. Бо хутка дакупіць памяць, месца, разгарнуць новыя інстансы і іншае можна за пару гадзін. А вось людзей і працэсы трэба рыхтаваць да такога загадзя.
Крыніца: habr.com