Дырэктар па эксплуатацыі партала Banki.ru Андрэй Нікольскі расказаў на леташняй канферэнцыі пра сэрвісы-сіроты: як апазнаць сірату ў інфраструктуры, чым дрэнныя сэрвісы-сіроты, што з імі рабіць, і як быць, калі нічога не дапамагае.
Пад катам тэкставая версія даклада.
Добры дзень, калегі! Мяне клічуць Андрэй, я кірую эксплуатацыяй у кампаніі Banki.ru.
У нас ёсць вялікія сэрвісы, гэта такія маналітасэрвісы, ёсць сэрвісы ў больш класічным разуменні, ёсць зусім маленькія. Я ў сваёй працоўна-сялянскай тэрміналогіі кажу, што калі сэрвіс просты і маленькі, то ён мікра, а калі ён не вельмі просты і не маленькі, то ён проста сэрвіс.
Плюсы сэрвісаў
Прабегуся хуценька па плюсах сэрвісаў.
Першае - маштабаванне. Вы можаце хутка зрабіць што-небудзь на сэрвісе і стартаваць у прадакшн. У вас прыехаў трафік, вы сэрвіс скланавалі. У вас прыехаў яшчэ трафік, вы яшчэ скланавалі і з гэтым жывяце. Гэта добры бонус, і, у прынцыпе, калі мы пачыналі, ён лічыўся ў нас найважнейшым, навошта мы наогул усё гэта які робіцца.
Па-другое, ізаляваная распрацоўка, калі ў вас некалькі каманд распрацоўкі, некалькі розных распрацоўшчыкаў у кожнай камандзе, і кожная каманда пілуе нейкі свой сэрвіс.
З камандамі ўзнікае нюанс. Распрацоўнікі бываюць розныя. І існуюць, напрыклад, . Я ўпершыню ўбачыў гэта ў Максіма Дарафеева. Часам людзі-сняжынкі ёсць у некаторых камандах, а ў некаторых іх няма. Гэта робіць розныя сэрвісы, якія выкарыстоўваюцца ў кампаніі, крыху нераўнамернымі.
Паглядзіце на карцінку: гэта добры распрацоўшчык, у яго вялікія рукі, ён можа шмат што рабіць. Галоўная праблема - адкуль гэтыя рукі растуць.
Сэрвісы даюць магчымасць выкарыстоўваць розныя мовы праграмавання, больш прыдатныя для розных задач. Нейкі сэрвіс на Go, нейкі на Erlang, нейкі на Ruby, нешта на PHP, нешта на Python. Увогуле, можна разгарнуцца вельмі шырока. Тут таксама ёсьць нюансы.
Сэрвіс-арыентаваная архітэктура - гэта першым чынам пра devops. Гэта значыць калі ў вас няма аўтаматызацыі, няма працэсу дэплою, калі вы наладжваеце рукамі, у вас канфігурацыі могуць мяняцца ад інстансу сэрвісу да інстанса, і вам даводзіцца туды хадзіць нешта рабіць, то вы ў пекле.
Напрыклад, у вас ёсць 20 сэрвісаў, і вам трэба дэплоіць рукамі, у вас 20 кансоляў, і вы адначасова цісне «enter», як ніндзя. Гэта ня вельмі добра.
Калі ў вас сэрвіс пасля тэставання (калі ёсць тэставанне, вядома), і трэба яшчэ дапілаваць напільнікам, каб ён працаваў у прадакшэне, у мяне таксама для вас дрэнныя навіны.
Калі вы належыце на спецыфічныя сэрвісы Амазона і працуеце пры гэтым у Расіі, то два месяцы таму ў вас таксама было «Усё вакол гарыць, i'm fine, усё класна».
Мы выкарыстоўваем Ansible для аўтаматызацыі разгортвання, Puppet для збежнасці, Bamboo для аўтаматызацыі дэплою, Confluence для таго, каб усё гэта неяк апісваць.
Падрабязна на гэтым спыняцца не буду, таму што даклад хутчэй пра практыкі ўзаемадзеянняў, а не пра тэхнічную рэалізацыю.
У нас бывалі, напрыклад, праблемы, што Puppet на серверы працуе з Ruby 2, а нейкі дадатак напісана пад Ruby 1.8, і разам яны не працуюць. Там нейкі вушак здараецца. А калі вам трэба на адной машыне трымаць некалькі вэрсіяў Ruby, у вас звычайна пачынаюцца праблемы.
У нас, напрыклад, кожнаму распрацоўніку мы выдаем пляцоўку, на якой ёсць прыкладна ўсё, што ў нас ёсць, усе сэрвісы, якія можна распрацоўваць, каб у яго было ізаляванае асяроддзе, ён мог ламаць яго і будаваць, як яму жадаецца.
Бывае, патрэбен нейкі спецыяльна скампіляваны пакет з падтрымкай чагосьці там. Гэта дастаткова жорстка. Я вось паслухаў даклад, дзе докер-вобраз важыць па 45 Гб. У лінуксе, вядома, прасцей, тамака паменш усё, але ўсё роўна, ніякіх месцаў не хопіць.
Ну, і бываюць супярэчлівыя залежнасці, калі ў вас адзін кавалак праекту залежыць ад бібліятэкі адной версіі, іншы кавалак праекту ад іншай версіі, а бібліятэкі разам не ставяцца наогул ніяк.
У нас ёсьць сайты і сэрвісы на PHP 5.6, нам за іх сорамна, але што рабіць. Гэта ў нас адна пляцоўка. Ёсць сайты і сэрвісы на PHP 7, іх больш, за іх нам не сорамна. І ў кожнага распрацоўшчыка ёсць свая базачка, дзе ён радасна пілуе.
Калі вы пішаце ў кампаніі на адной мове, то тры віртуалкі на распрацоўшчыка - гэта нармальна гучыць. Калі ў вас розныя мовы праграмавання, то сітуацыя становіцца горшай.
У вас з'яўляюцца сайты і сэрвісы на гэтым, на гэтым, потым яшчэ адна пляцоўка для Go, адна пляцоўка для Ruby, яшчэ які-небудзь Redis узбоч. У выніку ўсё гэта ператвараецца ў вялікае поле для падтрымкі, і ўвесь час нешта з гэтага можа ламацца.
Таму мы замянілі плюшкі мовы праграмавання на выкарыстанне розных фрэймворкаў, паколькі фрэймворкі на PHP досыць розныя, у іх ёсць розныя магчымасці, рознае кам'юніці, розная падтрымка. І можна пісаць сэрвіс так, каб у вас ужо было нешта гатовае пад яго.
У кожнага сэрвісу - свая каманда
Наш галоўны плюс, які выкрышталізаваўся за некалькі гадоў, - у кожнага сэрвісу ёсць свая каманда. Гэта зручна для вялікага праекту, можна зэканоміць час на дакументацыі, менеджэры добра ведаюць свой праект.
Задачы з падтрымкі можна добра закідваць. Напрыклад, зламаўся сэрвіс страхавання. І адразу каманда, якая займаецца страхаваннем, ідзе правіць.
Хутка робяцца новыя фічы, таму што калі ў вас адзін нейкі атамарны сэрвіс, у яго можна аператыўна што-небудзь укруціць.
І калі вы зламалі свой сэрвіс, а гэта непазбежна здараецца, вы не зачапілі чужыя сэрвісы, і да вас не звяртаюцца распрацоўшчыкі з бітамі з іншых каманд і не кажуць: "Ай-ай, не трэба так".
Як заўжды, ёсць нюансы. У нас стабільныя каманды, да каманды менеджэры прыбітыя цвікамі. Ёсць дакладныя дакументы, менеджэры шчыльна за гэтым усім сочаць. У кожнай каманды з мэнэджэрам ёсць па некалькі сэрвісаў, і ёсць канкрэтны пункт кампетэнцыі.
Калі каманды плывучыя (такое таксама ў нас часам выкарыстоўваецца), ёсць добры метад, які завецца "зорная карта".
У вас ёсць спіс сэрвісаў і людзі. Зорачка азначае, што чалавек - эксперт у гэтым сэрвісе, кніжка азначае, што чалавек вывучае гэты сэрвіс. Задача чалавека - памяняць кніжачку на зорачку. А калі насупраць сэрвісу нічога не напісана, то пачынаюцца праблемы, пра якія я буду далей расказваць.
Як з'яўляюцца сэрвісы-сіроты?
Першая праблема, першы спосаб, атрымаць у сябе ў інфраструктуры сэрвіс-сіроту - гэта звальнення людзей. У каго-небудзь хаджала, калі з бізнэсу прылятаюць тэрміны да таго, як ацанілі задачы? Часам бывае, што тэрміны жорсткія і на дакументацыю проста не хапае часу. «Трэба здаваць сэрвіс у прадакшн, потым дапішам».
Калі каманда невялікая, бывае, што ў ёй адзін распрацоўшчык, які піша ўсё, астатнія на падхваце. "Я напісаў асноўную архітэктуру, ты давай інтэрфейсы накідай". Потым у нейкі момант мэнэджар, напрыклад, сыходзіць. І ў гэты перыяд, калі менеджэр сышоў, а новага яшчэ не прызначылі, распрацоўшчыкі самі вырашаюць, куды сэрвіс рухаецца, што там адбываецца. А як мы ведаем (вернемся на некалькі слайдаў назад), у некаторых камандах ёсць людзі-сняжынкі, часам сняжынка-цімлід. Потым ён звальняецца, і мы атрымліваем сервіс-сіроту.
Пры гэтым задачы ад падтрымкі і ад бізнэсу нікуды не дзяюцца, яны асядаюць у бэклог. Калі пры распрацоўцы сэрвісу былі нейкія архітэктурныя памылкі, яны таксама абсоўваюцца ў бэклогу. Сэрвіс павольна дэградуе.
Як апазнаць сірату?
Гэты спіс нядрэнна апісвае сітуацыю. Хто даведаўся ў сябе што-небудзь у інфраструктуры?
Пра задакументаваныя work-around'ы: ёсць сэрвіс і, у цэлым, ён працуе, у яго ёсць мануал на дзве старонкі, як з ім працаваць, але як ён працуе ўсярэдзіне, ніхто не ведае.
Ці, напрыклад, ёсць які-небудзь скарашчатар спасылак. У нас, напрыклад, цяпер у ходзе тры скарашчатары спасылак для розных мэт у розных сэрвісах. Гэта наступствы якраз.
Цяпер я буду капітанам відавочнасць. Што трэба рабіць? Па-першае, трэба перадаць сэрвіс іншаму мэнэджэра, іншай камандзе. Калі ў вас тымлід яшчэ не звольніўся, то ў гэтую іншую каманду, калі вы разумееце, што сэрвіс падобны на сірату, трэба ўключаць кагосьці, хто хоць нешта ў ім разумее.
Галоўная рэч: у вас павінны быць напісаныя крывёй працэдуры перадачы. У нашым выпадку, сачу за гэтым звычайна я, бо мне трэба, каб гэта ўсё працавала. Мэнэджарам трэба, каб гэта было хутка здадзена, а што з ім потым будзе, ім ужо не так важна.
Наступны спосаб зрабіць сірату - "Зробім на аўтсорсе, так будзе хутчэй, а потым перададзім у каманду". Зразумела, што ва ўсіх ёсць нейкія планы ў камандзе, чарга. Часта бізнес-заказчык думае, што на аўтсорсеры зробяць гэтак жа, як і тэхаддзел, які ёсць у кампаніі. Хаця матыватары ў іх розныя. На аўтсорсе бываюць дзіўныя тэхналагічныя рашэнні і дзіўныя алгарытмічныя рашэнні.
У нас, напрыклад, быў сэрвіс, у якім быў Sphinx у розных нечаканых месцах. Я пазней раскажу, што прыйшлося зрабіць.
У аўтсорсераў бываюць самапісныя фрэймворкі. Гэта проста голы PHP з капіпастам з папярэдняга праекта, дзе можна знайсці ўсякае. Вялікія мыліцы ў дэплой-скрыптах, калі вам трэба нейкімі складанымі Bash-скрыптамі памяняць некалькі радкоў у нейкім файліку, пры гэтым гэтыя дэплой-скрыпты выклікаюцца нейкім трэцім скрыптам. У выніку вы мяняеце сістэму дэплою, выбіраеце нешта іншае, хоп, а ў вас сэрвіс не працуе. Бо там трэба было яшчэ 8 спасылак паставіць паміж рознымі татачкамі. Або бывае, што тысяча запісаў працуе, а сто тысяч ужо няма.
Працягну капітаніць. Прыёмка сэрвісу з аўтсорса - гэта працэдура, якая абавязковая. У каго бывала, што сервіс з аўтсорса прыязджае, а яго нікуды не прымаюць? Гэта не так, вядома, папулярна, як сэрвіс-сірата, але ўсё ж.
Сэрвіс трэба правяраць, сэрвіс трэба ревьюить, трэба мяняць паролі. У нас быў выпадак, калі нам падкінулі сэрвіс, там адмінка "if login == 'admin' && password == 'admin'…", прамы ў кодзе напісана. Мы сядзім і думаем, і гэта пішуць людзі ў 2018 годзе?
Тэставанне аб'ёму сховішча - таксама патрэбная штука. Трэба глядзець, што будзе на ста тысячах запісах, яшчэ да таго, як вы гэты сэрвіс кудысьці ў прадакшн пусціце.
Адпраўляць сэрвіс на дапрацоўку павінна быць не сорамна. Калі вы кажаце: "Мы гэты сэрвіс не прымем, у нас ёсць 20 задач, зрабіце іх, тады прымем", гэта нармальна. Сумленне не павінна хварэць ад таго, што вы падставіце мэнэджара ці што бізнэс выдаткуе грошы. Бізнес потым больш патраціць.
У нас быў выпадак, калі мы вырашылі зрабіць пілотны праект на аўтсорсе.
Ён быў здадзены своечасова, і гэта быў адзіны крытэр якасці. Таму зрабілі яшчэ адзін пілотны праект, ужо нават не зусім пілотны. Гэтыя сэрвісы прынялі, адміністрацыйнымі спосабамі сказалі, вось ваш код, вось каманда, вось ваш мэнэджар. Сэрвісы рэальна пачалі ўжо прыносіць прыбытак. Пры гэтым па факце яны засталіся па-ранейшаму сіротамі, ніхто не разумее, як яны працуюць, і менеджэры ўсяляк ад іх задач адхрышчваюцца.
Ёсць яшчэ адно выдатнае паняцце - партызанская распрацоўка. Калі нейкі аддзел, як правіла, гэта аддзел маркетынгу, жадаюць праверыць гіпотэзу, і заказваюць сэрвіс цалкам на аўтсорсе. На яго пачынае ліцца трафік, яны закрываюць дакументы, падпісваюць акты з падрадчыкам, прыходзяць у эксплуатацыю і кажуць: "Чувакі, у нас тут ёсць сэрвіс, на ім ужо ёсць трафік, ён нам прыносіць грошы, давайце яго прымаць". Мы такія: "Опа, як жа так".
І яшчэ адзін спосаб атрымання сэрвісу-сіроты: калі нейкая каманда раптам аказваецца нагружанай, кіраўніцтва кажа: "Давайце мы перадамо сэрвіс гэтай каманды іншай камандзе, у яе нагрузка паменш". А потым перададзім трэцяй камандзе, і мэнэджара памяняем. І ў выніку ў нас зноў сірата.
У чым праблема з сіротамі?
Хто не ведае, гэта падняты ў Швецыі лінейны карабель Wasa, знакаміты тым, што ён патануў праз 5 хвілін пасля спуску на ваду. І кароль Швецыі, дарэчы, нікога за гэта не пакараў смерцю. Ён будаваўся двума пакаленнямі інжынераў, якія не ўмелі будаваць такія караблі. Заканамерны эфект.
Карабель мог патануць, дарэчы, значна горш, напрыклад, калі на ім ужо ехаў бы кароль кудысьці ў шторм. А так, патануў адразу, па аджайлу гэта добра - праваліцца рана.
Калі мы праваліліся рана, звычайна праблем не бывае. Напрыклад, падчас прыёмкі адправілі на дапрацоўку. А калі мы праваліліся ўжо ў прадакшэне, калі ўкладзены грошы, то могуць быць праблемы. Наступствы, як іх называюць у бізнэсе.
Чым небяспечныя сэрвісы-сіроты:
- Сэрвіс можа зламацца раптоўна.
- Сэрвіс доўга чыніцца ці не чыніцца наогул.
- Праблемы з бяспекай.
- Праблемы з дапрацоўкамі і абнаўленнямі.
- Калі ламаецца важны сэрвіс, пакутуе рэпутацыя кампаніі.
Што рабіць з сэрвісамі-сіротамі?
Яшчэ раз паўтаруся, што рабіць. Па-першае, павінна быць дакументацыя. 7 гадоў у Banki.ru мяне навучылі, што тэсціроўшчыкі не павінны верыць на слова распрацоўшчыкам, а эксплуатацыя не павінна верыць на слова ўсім. Трэба правяраць.
Па-другое, трэба пісаць схемы ўзаемадзеянняў, таму што бывае, што сэрвісы, якія прыняты не вельмі добра, утрымоўваюць залежнасці, аб якіх ніхто не сказаў. Напрыклад, распрацоўшчыкі паставілі сэрвіс на свой ключ да якіх-небудзь Яндекс.Карт або да Dadata. У вас скончыўся бясплатны ліміт, усё зламалася, і вы не ведаеце, што здарылася ўвогуле. Усе такія граблі павінны быць апісаны: у сэрвісе выкарыстоўваецца Dadata, Sms, яшчэ нешта.
Па-трэцяе, праца з тэхдоўгам. Калі вы робіце нейкія мыліцы ці прымаеце сэрвіс і кажыце, што нешта трэба зрабіць, трэба сачыць, каб гэта рабілі. Таму што потым можа аказацца, што маленькая ямка не такая маленькая, і вы туды праваліцеся.
З архітэктурнымі задачамі ў нас была гісторыя як раз пра Sphinx. У адным са сэрвісаў Sphinx выкарыстоўваўся для таго, каб уводзіць спісы. Проста спіс з пагінацыяй, але пры гэтым ён пераіндэксаваўся кожную ноч. Ён быў сабраны з двух індэксаў: адзін індэксаваўся кожную ноч вялікі, і быў яшчэ маленькі індэкс, які да яго прыкручваўся. Кожны дзень, з верагоднасцю 50% або бамбіць, або не, пры выкладцы індэкс біўся, і навіны ў нас пераставалі абнаўляцца на галоўнай старонцы. Спачатку гэта было 5 хвілін, пакуль індэкс пераіндэксаваўся, потым індэкс разросся, і ў нейкі момант ён пачаў пераіндэксавацца 40 хвілін. Калі мы гэта выпілавалі, мы ўздыхнулі з палёгкай, таму што было зразумела, што пройдзе яшчэ крыху часу, і ў нас індэкс будзе пераіндэксавацца поўны працоўны дзень. Гэта будзе фейл для нашага партала, восем гадзін няма навін - усё, бізнэс устаў.
План працы з сэрвісам-сіратой
Насамрэч, гэта вельмі цяжка рабіць, таму што дэвопс - гэта пра зносіны. Жадаецца быць у добрых адносінах са сваімі калегамі, а калі ты калегаў і мэнэджараў б'еш рэгламентамі па галаве, яны могуць выпрабоўваць супярэчлівыя пачуцці да тых людзей, якія так робяць.
Апроч усіх гэтых пунктаў, ёсць яшчэ важная штука: за кожны пэўны сэрвіс, за кожны пэўны ўчастак працэдуры дэплою, павінны адказваць пэўныя людзі. Калі людзей няма і даводзіцца прыцягваць нейкіх іншых людзей, вывучаць усю гэтую справу, становіцца цяжка.
Калі ўсё гэта не дапамагло, і сэрвіс-сірата ў вас па-ранейшаму застаўся сіратой, яго ніхто не хоча да сябе браць, дакументацыя не пішацца, каманда, якую ў гэты сэрвіс заклікалі, адмаўляецца нешта рабіць, ёсць просты спосаб - усё перарабіць .
Гэта значыць вы бераце патрабаванні да сэрвісу нанова і пішаце новы сэрвіс, лепшы, на лепшай платформе, без дзіўных тэхналагічных рашэнняў. І мігруеце на яго ў баі.
У нас была сітуацыя, калі мы ўзялі сэрвіс на Yii 1 і зразумелі, што мы не можам яго далей развіваць, таму што ў нас скончыліся распрацоўшчыкі, якія ўмеюць добра пісаць на Yii 1. Усе распрацоўшчыкі добра пішуць на трэцім Symfony. Што рабіць? Вылучылі час, вылучылі каманду, вылучылі мэнэджара, перапісалі праект і плаўна пераключылі на яго трафік.
Пасля гэтага стары сэрвіс можна выдаліць. Гэта мая любімая працэдура, калі з сістэмы кіравання канфігурацыямі трэба ўзяць і вычысціць нейкі сэрвіс і потым прайсціся паглядзець, каб усе тачкі на прадакшэне былі пагашаны, каб у распрацоўшчыкаў ніякіх слядоў не засталося. Рэпазітар у гіце застаецца.
Гэта ўсё, пра што я хацеў расказаць, гатовы падыскутаваць, тэма халіварная, многія ў ёй плавалі.
На слайдах было пра тое, што вы уніфікавалі мовы. У якасці прыкладу быў рэсайзінг карцінак. А ці сапраўды трэба жорстка да адной мовы? Таму што рэсайз карцінкі на PHP, ну, можна было сапраўды і на Golang зрабіць.
Насамрэч, гэта неабавязкова, як і ўсе практыкі. Можа, у нейкіх выпадках нават непажадана. Але трэба разумець, што калі ў вас у кампаніі 50 чалавек тэхаддзел, з іх 45 – PHP-шнікі, яшчэ 3 – дэвопсы, якія ўмеюць у Python, Ansible, Puppet і што-небудзь такое, і толькі адзін з іх піша на якім- небудзь Go сэрвіс рэсайзу карцінак, то, калі ён сыходзіць, экспертыза сыходзіць разам з ім. І пры гэтым вам трэба будзе шукаць спецыфічнага на рынку распрацоўніка, які ведае гэту мову, асабліва, калі яна рэдкая. Гэта значыць з арганізацыйнага пункта гледжання, гэта праблемна. З пункту гледжання дэвопсу, вам спатрэбіцца не проста схіляваць нейкі гатовы набор плэйбукаў, якія вы карыстаецеся для таго, каб разгортваць сэрвісы, а давядзецца іх пісаць нанова.
Мы зараз пілуем сэрвіс на Node.js, і гэта будзе як раз пляцоўка побач для кожнага распрацоўніка з асобнай мовай. Але мы пасядзелі падумалі, што гульня стаіць свечак. Гэта значыць, тут пытанне на пасядзець і падумаць.
Як вы маніторыце вашыя сэрвісы? Як збіраеце і адсочваеце логі?
Логі мы збіраем у Elasticsearch і кладзем у Kibana, а ў залежнасці ад таго, прадакшн гэта ці тэставыя асяроддзі, там выкарыстоўваюцца розныя зборшчыкі. Недзе Lumberjack, недзе яшчэ нешта, я ўжо не памятаю. І ёсць яшчэ некаторыя месцы ў пэўных сэрвісах, дзе мы ставім Telegraf і куляем яшчэ некуды асобна.
Як жыць з Puppet і Ansible у адным асяроддзі?
Насамрэч, у нас цяпер дзве асяроддзя, адна – Puppet, іншая Ansible. Мы працуем над тым, каб іх гібрыдызаваць. Ansible – гэта добрае асяроддзе для першапачатковай наладкі, Puppet – гэта дрэнная штука для першапачатковай налады, таму што патрабуе працы рукамі непасрэдна з пляцоўкай, і Puppet забяспечвае збежнасць канфігурацыі. Гэта значыць, што пляцоўка сама сябе падтрымлівае ў актуальным стане, а для таго, каб ансіблізаваная машына падтрымлівалася ў актуальным стане, трэба на ёй увесь час ганяць плейбукі з якой-небудзь перыядычнасцю. Вось такая вось розніца.
Як вы падтрымліваеце сумяшчальнасць? У вас ёсць канфігі і ў Ansible, і ў Puppet?
Гэта наш вялікі боль, мы падтрымліваем сумяшчальнасць рукамі і думаем, як бы зараз ад усяго гэтага кудысьці перайсці. У нас атрымліваецца, што Puppet накатвае пакеты і падтрымлівае там нейкія спасылкі, а Ansible у нас, напрыклад, накатвае код і падганяе туды свежыя канфігі прыкладанняў.
У прэзентацыі было пра розныя версіі Ruby. Якое рашэнне?
Мы ў адным месцы з гэтым сутыкнуліся, і нам даводзіцца ўвесь час трымаць гэта ў галаве. Мы проста выключылі тую частку, якая працавала на тым Ruby, які быў несумяшчальны з праграмамі, і трымалі яе асобна.
У гэтым годзе канферэнцыя пройдзе 7 снежня ў «Тэхнапалісе». Да 11 лістапада мы прымаем заяўкі на даклады. нам, калі вы хочаце выступіць.
Рэгістрацыя для ўдзельнікаў адкрыта, далучайцеся!
Крыніца: habr.com