Канферэнцыя Хабра - гісторыя не дэбютная. Раней мы праводзілі даволі буйныя мерапрыемствы Тостар на 300-400 чалавек, а зараз вырашылі, што актуальнымі будуць невялікія тэматычныя сустрэчы, кірунак якіх можаце задаваць і вы - напрыклад, у каментарах. Першая канферэнцыя такога фармату прайшла ў ліпені і была прысвечана бэкэнд-распрацоўцы. Удзельнікі слухалі даклады аб асаблівасцях пераходу з бэкенда ў ML і аб прыладзе сэрвісу «Квадрупель» на партале «Дзяржпаслугі», а таксама прынялі ўдзел у круглым стале, прысвечаным Serverless. Тым, хто не змог наведаць мерапрыемства асабіста, у гэтым пасце мы расказваем самае цікавае.
З бэкэнд-распрацоўкі ў машыннае навучанне
Чым займаюцца дата-інжынеры ў ML? Чым падобныя і чым адрозніваюцца задачы бэкэнд-распрацоўніка і ML-інжынера? Які шлях трэба прайсці, каб змяніць першую прафесію на другую? Пра гэта распавёў Аляксандр Парын, які сышоў у машыннае навучанне пасля 10 гадоў бэкенда.
Аляксандр Парынаў
Сёння Аляксандр працуе архітэктарам сістэм кампутарнага зроку ў X5 Retail Group і кантрыб'ют у Open Source праекты, звязаныя з кампутарным зрокам і глыбокім навучаннем (github.com/creafz). Яго скілы пацвярджае ўдзел у топ-100 сусветнага рэйтынгу Kaggle Master (kaggle.com/creafz) - самай папулярнай платформы, якая праводзіць спаборніцтвы па машынным навучанні.
Навошта пераходзіць на машыннае навучанне
Паўтара гады назад Джэф Дын, раздзелы Google Brain – праекту Google па даследаванні штучнага інтэлекту на аснове глыбокага навучання – распавёў, як паўмільёна радкоў кода ў Google Translate замянілі нейронавай сеткай на Tensor Flow, якая складаецца ўсяго з 500 радкоў. Пасля навучання сеткі якасць даных вырасла, а інфраструктура спрасцілася. Здавалася б, вось наша светлая будучыня: больш не давядзецца пісаць код, дастаткова рабіць нейронкі і закідваць іх дадзенымі. Але на практыцы ўсё больш складана.
ML-інфраструктура ў Google
Нейронныя сеткі – гэта толькі невялікая частка інфраструктуры (маленькі чорны квадрацік на малюнку вышэй). Патрабуецца яшчэ шмат дапаможных сістэм, каб атрымліваць дадзеныя, апрацоўваць іх, захоўваць, правяраць якасць і т. д., патрэбна інфраструктура для навучання, разгортванні кода машыннага навучання ў прадакшэне, тэставанні гэтага кода. Усе гэтыя задачы якраз падобныя на тое, чым займаюцца бэкэнд-распрацоўшчыкі.
Працэс машыннага навучання
Чым адрозніваецца ML ад бэкенда
У класічным праграмаванні мы пішам код, і гэта дыктуе паводзіны праграмы. У ML у нас ёсць невялікі код мадэлі і шмат дадзеных, якімі мы закідвае мадэль. Дадзеныя ў ML вельмі важныя: адна і тая ж мадэль, навучаная рознымі дадзенымі, можа паказваць зусім розныя вынікі. Праблема складаецца ў тым, што амаль заўсёды дадзеныя разрозненыя і ляжаць у розных сістэмах (рэляцыйныя базы дадзеных, NoSQL-базы, логі, файлы).
Версіянаванне дадзеных
ML патрабуе версіявання не толькі кода, як у класічнай распрацоўцы, але і дадзеных: неабходна дакладна разумець, на чым навучалася мадэль. Для гэтага можна скарыстацца папулярнай бібліятэкай Data Science Version Control (dvc.org).
Разметка дадзеных
Наступная задача - разметка дадзеных. Напрыклад, адзначыць усе прадметы на малюнку або сказаць, да якога класа яна належыць. Гэтым займаюцца спецыяльныя сэрвісы накшталт "Яндэкс.Талакі", працу з якімі моцна спрашчае наяўнасць API. Складанасці ўзнікаюць з-за "чалавечага фактару": павысіць якасць дадзеных і звесці памылкі да мінімуму можна, даручаючы адно і тое ж заданне некалькім выканаўцам.
Візуалізацыя ў Tensor Board
Лагаванне эксперыментаў неабходна для параўнання вынікаў, выбару лепшай па нейкіх метрыках мадэлі. Для візуалізацыі ёсць вялікі набор сродкаў - напрыклад, Tensor Board. Але для захоўвання эксперыментаў нейкіх ідэальных спосабаў няма. У маленькіх кампаніях часцяком абыходзяцца excel-таблічкай, у буйных выкарыстоўваюць спецыяльныя платформы для захоўвання вынікаў у БД.
Платформ для машыннага навучання мноства, але ні адна з іх не закрывае і 70% запатрабаванняў
Першая праблема, з якой даводзіцца сутыкацца пры вывадзе навучанай мадэлі ў прадакшн, звязана з любімым інструментам дата-саенцістаў - Jupyter Notebook. У ім няма мадулярнасці, гэта значыць на вынахадзе атрымліваецца такая парцянка кода, не пабітага на лагічныя кавалкі модулі. Усё перамяшана: класы, функцыі, канфігурацыі і т. д. Гэты код цяжка версіяваць і тэставаць.
Як з гэтым дужацца? Можна змірыцца, як Netflix, і стварыць сваю платформу, якая дазваляе прама ў прадакшэне запускаць гэтыя наўтбукі, перадаваць ім на ўваход дадзеныя і атрымліваць вынік. Можна прымусіць распрацоўшчыкаў, якія коцяць мадэль у прадакшн, перапісаць код нармальна, разбіць на модулі. Але пры такім падыходзе лёгка памыліцца, і мадэль будзе працаваць не так, як задумвалася. Таму ідэальны варыянт - забараніць выкарыстоўваць Jupyter Notebook для кода мадэляў. Калі, зразумела, дата-саентісты на гэта пагодзяцца.
Мадэль як чорная скрыня
Самы просты спосаб вывесці мадэль у прадакшн – выкарыстоўваць яе як чорную скрыню. У вас ёсць нейкі клас мадэлі, вам перадалі вагі мадэлі (параметры нейронаў навучанай сеткі), і калі вы гэты клас ініцыялізуеце (выклічце метад predict, падасце на яго карцінку), то на выхадзе атрымаеце нейкі прадказанне. Што адбываецца ўнутры - не мае значэння.
Асобны працэс-сервер з мадэллю
Можна таксама падняць нейкі асобны працэс і засылаць яго праз чаргу RPC (з малюначкамі ці іншымі зыходнымі дадзенымі. На вынахадзе мы будзем атрымліваць прэдыкты.
Прыклад выкарыстання мадэлі ва Flask:
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
Праблема такога падыходу - абмежаванне прадукцыйнасці. Дапусцім, у нас ёсць код на Phyton, напісаны дата-саенцістамі, які тармозіць, а мы хочам выціснуць максімальную прадукцыйнасць. Для гэтага можна выкарыстоўваць прылады, якія пераўтвараюць код у натыўны ці канвертуюць яго ў іншы фрэймворк, заменчаны пад прадакшн. Такія прылады ёсць для кожнага фрэймворка, але ідэальных не існуе, прыйдзецца дапілоўваць самастойна.
Інфраструктура ў ML такая ж, як у звычайным бэкендзе. Ёсць Docker і Kubernetes, толькі для Docker трэба паставіць рантайм ад NVIDIA, які дазваляе працэсам усярэдзіне кантэйнера атрымаць доступ да відэакарт у хасце. Для Kubernetes патрэбен убудова, каб ён мог менеджіць серверы з відэакартамі.
У адрозненне ад класічнага праграмавання, у выпадку з ML у інфраструктуры з'яўляецца шмат розных рухомых элементаў, якія трэба правяраць і тэставаць - напрыклад, код апрацоўкі дадзеных, пайплайн навучання мадэлі і прадакшн (гл. схему вышэй). Важна пратэставаць код, які злучае розныя кавалкі пайплайнаў: кавалкаў шмат, і праблемы вельмі часта ўзнікаюць на межах модуляў.
Як працуе AutoML
Сэрвісы AutoML абяцаюць падабраць аптымальную для вашых мэт мадэль і навучыць яе. Але трэба разумець: у ML вельмі важныя даныя, вынік залежыць ад іх падрыхтоўкі. Разметкай займаюцца людзі, што багата памылкамі. Без жорсткага кантролю можа атрымацца смецце, а аўтаматызаваць працэс пакуль не выходзіць, патрэбна праверка з боку спецыялістаў - дата-саенцістаў. Вось на гэтым месцы і ламаецца AutoML. Але ён можа быць карысны для падбору архітэктуры - калі вы ўжо падрыхтавалі дадзеныя і жадаеце правесці серыю эксперыментаў для пошуку лепшай мадэлі.
Як патрапіць у машыннае навучанне
Патрапіць у ML прасцей за ўсё, калі вы распрацоўваеце на Python, які выкарыстоўваецца ва ўсіх фрэймворках для глыбокага навучання (і звычайных фрэймворках). Гэта мова практычна абавязковая для дадзенай сферы дзейнасці. З++ ужываецца для некаторых задач з кампутарным зрокам - напрыклад, у сістэмах кіравання беспілотнымі аўтамабілямі. JavaScript і Shell - для візуалізацыі і такіх дзіўных рэчаў, як запуск нейронкі ў браўзэры. Java і Scala выкарыстоўваецца пры працы з Big Data і для машыннага навучання. R і Julia любяць людзі, якія займаюцца матстатыстыкай.
Атрымліваць практычны досвед для пачатку зручней за ўсё на Kaggle, удзел у адным з конкурсаў платформы дае больш, чым год вывучэння тэорыі. На гэтай платформе вы можаце ўзяць чыйсьці выкладзены і пракаментаваны код і паспрабаваць яго палепшыць, аптымізаваць пад свае мэты. Бонус - ранг на Kaggle ўплывае на ваш заробак.
Іншы варыянт - пайсці бэкенд-распрацоўшчыкам у ML-каманду. Цяпер шмат стартапаў, якія займаюцца машынным навучаннем, у якіх вы набярэцеся досведу, дапамагаючы калегам у рашэнні іх задач. Нарэшце, можна ўступіць у адну з супольнасцяў дата-саенцістаў – Open Data Science (ods.ai) і іншыя.
Дадатковую інфармацыю па тэме дакладчык размясціў па спасылцы
«Квадрупель» — сэрвіс таргетаваных апавяшчэнняў партала «Дзяржпаслугі»
Яўген Смірноў
Наступным выступаў начальнік аддзела распрацоўкі інфраструктуры электроннага ўрада Яўген Смірноў, які распавёў аб «Квадрупелі». Гэта сэрвіс таргетаваных апавяшчэнняў партала «Дзяржпаслугі» (gosuslugi.ru) – самага наведвальнага дзяржаўнага рэсурсу Рунэту. Дзённая аўдыторыя складае 2,6 млн, усяго ж на сайце зарэгістравана 90 млн карыстальнікаў, з іх 60 млн - пацверджаныя. Нагрузка на API партала – 30 тыс. RPS.
Тэхналогіі, якія выкарыстоўваюцца ў бэкендзе «Дзяржпаслуг»
«Квадрупель» — сэрвіс адраснай абвесткі, з дапамогай якога карыстач атрымлівае прапанову аб паслузе ў найболей падыходны для яго момант шляхам налады адмысловых правіл інфармаванні. Асноўнымі патрабаваннямі пры распрацоўцы сэрвісу былі гнуткія наладкі і адэкватны час на рассылкі.
Як працуе Квадрупель
На схеме вышэй паказана адно з правілаў працы «Квадрупеля» на прыкладзе сітуацыі з неабходнасцю замены правоў кіроўцы. Спачатку сэрвіс шукае карыстальнікаў, у якіх тэрмін прыдатнасці заканчваецца праз месяц. Ім выстаўляецца банэр з прапановай атрымаць адпаведную паслугу і адпраўляецца паведамленне на электронную пошту. Для тых карыстальнікаў, у якіх тэрмін ужо скончыўся, банэр і email мяняюцца. Пасля паспяховага абмену правоў карыстальнік атрымлівае іншыя апавяшчэнні - з прапановай абнавіць дадзеныя ў пасведчанні.
З тэхнічнага пункта гледжання гэта groovy-скрыпты, у якіх напісаны код. На ўваходзе - дадзеныя, на выхадзе - true / false, супала / не супала. Усяго больш за 50 правілаў - ад вызначэння дня нараджэння карыстальніка (бягучая дата роўная даце нараджэння карыстальніка) да складаных сітуацый. Штодня па гэтых правілах вызначаецца каля мільёна супадзенняў - людзей, якіх трэба апавясціць.
Каналы апавяшчэнняў «Квадрупеля»
Пад капотам «Квадрупеля» знаходзіцца БД, у якой захоўваюцца дадзеныя карыстальнікаў, і тры прыкладанні:
- Працоўны прызначаны для абнаўлення дадзеных.
- API адпачынку забірае і аддае на партал і на мабільнае прыкладанне самі банеры.
- Планавальнік запускае працы па пераліку банэраў або масавай рассылкі.
Для абнаўлення дадзеных бэкенд падзейна арыентаваны. Два інтэрфейсу - рэст або JMS. Падзеяў шмат, перад захаваннем і апрацоўкай яны агрэгуюцца, каб не рабіць лішніх запытаў. Сама БД, таблічка, у якой захоўваюцца дадзеныя, выглядае як key value сховішча - ключ карыстальніка і само значэнне: сцяжкі, якія абазначаюць наяўнасць або адсутнасць адпаведных дакументаў, іх тэрмін дзеяння, агрэгаваная статыстыка па замове паслуг гэтым карыстальнікам і іншае.
Пасля захавання дадзеных ставіцца задача ў JMS, каб неадкладна пералічыліся банеры - гэта трэба адразу адлюстроўваць на вэбе. Сістэма запускаецца па начах: у JMS накідваюцца задачы з інтэрваламі карыстальнікаў, па якіх трэба пералічыць правілы. Гэта падхапляюць апрацоўшчыкі, занятыя пералікам. Далей вынікі апрацоўкі пападаюць у наступную чаргу, якая альбо захоўвае банеры ў БД, альбо адпраўляе ў сэрвіс задачы на натыфікацыю карыстача. Працэс займае 5-7 гадзін, ён лёгка маштабуецца за кошт таго, што можна заўсёды альбо дакінуць апрацоўшчыкаў, альбо падняць інстансы з новымі апрацоўшчыкамі.
Сэрвіс працуе дастаткова добра. Але аб'ём дадзеных расце, паколькі карыстальнікаў становіцца больш. Гэта прыводзіць да павелічэння нагрузкі на базу - нават з улікам таго, што Rest API глядзіць у рэпліку. Другі момант – JMS, які, як высветлілася, не вельмі падыходзіць з-за вялікага спажывання памяці. Высокая рызыка перапаўнення чаргі з падзеннем JMS і прыпынкам апрацоўкі. Падняць JMS пасля гэтага без ачысткі логаў немагчыма.
Вырашаць праблемы плануецца пры дапамозе шаліравання, што дазволіць балансаваць нагрузку на базу. Таксама ў планах змяніць схему захоўвання дадзеных, а JMS памяняць на Kafka - больш адмоваўстойлівае рашэнне, якое ўрэгулюе праблемы з памяццю.
Backend-as-a-Service Vs. Serverless
Злева направа: Аляксандр Боргарт, Андрэй Таміленка, Мікалай Маркаў, Ара Ісраелян
Бэкенд як сэрвіс або Serverless-рашэнне? У абмеркаванні гэтага актуальнага пытання на круглым стале ўдзельнічалі:
- Ара Ісраелян, тэхнічны дырэктар CTO і заснавальнік Scorocode.
- Мікалай Маркаў, Senior Data Engineer у кампаніі Aligned Research Group.
- Андрэй Таміленка, кіраўнік аддзела распрацоўкі RUVDS.
Мадэратарам гутаркі стаў старэйшы распрацоўшчык Аляксандр Боргарт. Мы прыводзім дэбаты, у якіх удзельнічалі і слухачы, у скарочаным варыянце.
- Што такое Serverless ў вашым разуменні?
Андрэй: Гэта мадэль вылічэнняў - Lambda-функцыя, якая павінна апрацоўваць дадзеныя так, каб вынік залежаў толькі ад дадзеных. Тэрмін пайшоў ці то ад Гугла, ці то ад Амазона і яго сэрвісу AWS Lambda. Правайдэру прасцей апрацоўваць такую функцыю, вылучыўшы пад гэта пул магутнасцяў. Розныя карыстачы могуць незалежна лічыцца на адных і тых жа серверах.
Мікалай: Калі проста - мы пераносім нейкую частку сваёй IT-інфраструктуры, бізнес-логікі ў воблака, на аўтсорс.
ара: З боку распрацоўшчыкаў - нядрэнная спроба зэканоміць рэсурсы, з боку маркетолагаў - зарабіць пабольш грошай.
- Serverless - тое ж, што і мікрасэрвісы?
Мікалай: Не, Serverless - гэта больш арганізацыя архітэктуры. Мікрасэрвіс – атамарная адзінка нейкай логікі. Serverless - падыход, а не "асобная сутнасць".
ара: Функцыю Serverless можна спакаваць у мікрасэрвіс, але ад гэтага яна перастане быць Serverless, перастане быць Lambda-функцыяй. У Serverless праца функцыі пачынаецца толькі ў той момант, калі яе запытваюць.
Андрэй: Яны адрозніваюцца часам жыцця. Lambda-функцыю мы запусцілі і забыліся. Яна адпрацавала пару секунд, і наступны кліент можа апрацаваць свой запыт на іншы фізічнай машыне.
- Што лепш маштабуецца?
ара: Пры гарызантальным маштабаванні Lambda-функцыі паводзяць сябе абсалютна гэтак жа, як мікрасэрвісы.
Мікалай: Якую задасі колькасць рэплік - столькі іх і будзе, няма ніякіх праблем з маштабаваннем у Serverless. У Kubernetes зрабіў рэпліка-сэт, запусціў 20 інстансаў "дзе-небудзь", і табе вярнулася 20 абязлічаных спасылак. Наперад!
- Ці можна пісаць бэкэнд на Serverless?
Андрэй: Тэарэтычна, але сэнсу ў гэтым няма. Lambda-функцыі будуць упірацца ў адзінае сховішча нам жа трэба забяспечыць гарантаванасць. Напрыклад, калі карыстальнік правёў нейкую транзакцыю, то пры наступным звароце ён павінен убачыць: транзакцыя праведзена, сродкі залічаны. Усе Lambda-функцыі будуць блакавацца на гэтым выкліку. Па факце куча Serverless-функцый ператворыцца ў адзіны сэрвіс з адной вузкай кропкай звароту да базы дадзеных.
- У якіх сітуацыях ёсць сэнс прымянення бессервернай архітэктуры?
Андрэй: Задачы, у якіх не патрабуецца агульнае сховішча - той жа майнінг, блокчэйн. Тамака, дзе трэба шмат лічыць. Калі ў вас куча вылічальных магутнасцяў, тыя вы можаце вызначыць функцыю тыпу «палічы хэш чагосьці тамака…» Але вы можаце вырашыць праблему з захоўваннем дадзеных, узяўшы, напрыклад, ад Амазона і Lambda-функцыі, і іх размеркаванае сховішча. І атрымаецца, што вы пішаце нармальны сэрвіс. Lambda-функцыі будуць звяртацца да сховішча і выдаваць нейкі адказ карыстачу.
Мікалай: Кантэйнерчыкі, якія запускаюцца ў Serverless, вельмі абмежаваныя па рэсурсах. Там мала памяці і ўсяго астатняга. Але калі ў вас уся інфраструктура разгорнута цалкам на нейкім воблаку - Google, Амазон - і ў вас з імі пастаянны кантракт, ёсць бюджэт на ўсё гэта, тады для нейкіх задач можна выкарыстоўваць Serverless-кантэйнеры. Неабходна знаходзіцца менавіта ўнутры гэтай інфраструктуры, таму што ўсё заменчана пад выкарыстанне ў канкрэтным асяроддзі. Гэта значыць калі вы гатовыя завязаць усё на інфраструктуру аблокі - можаце паэксперыментаваць. Плюс у тым, што не давядзецца мянячыць гэтую інфраструктуру.
ара: Што Serverless не патрабуе ад вас мяняваць Kubernetes, Docker, ставіць Kafka і гэтак далей - гэта самападман. Тыя ж Амазон і Гугл гэта менеджаюць і ставяць. Іншая справа, што ў вас есць SLA. З тым жа поспехам можна аддаць усё на аўтсорсінг, а не праграмаваць самастойна.
Андрэй: Сам Serverless недарагі, але даводзіцца шмат плаціць за астатнія амазонаўскія сэрвісы - напрыклад, базу дадзеных. З імі народ ужо судзіўся, за тое, што яны дралі шалёныя грошы за API gate.
ара: Калі казаць пра грошы, то трэба ўлічваць такі момант: вам давядзецца разгарнуць на 180 градусаў усю метадалогію распрацоўкі ў кампаніі, каб перавесці ўвесь код на Serverless. На гэта спатрэбіцца шмат часу і сродкаў.
- Ці ёсць годныя альтэрнатывы платным Serverless Амазона і Гугла?
Мікалай: У Kubernetes вы запускаеце нейкі job, ён адпрацоўвае і памірае - гэта цалкам сабе Serverless з пункту гледжання архітэктуры. Калі хочацца рэальна цікавую бізнес-логіку стварыць з чэргамі, з базамі, то трэба крыху больш над гэтым падумаць. Гэта ўсё вырашаецца, не выходзячы з Kubernetes. Цягнуць дадатковую рэалізацыю я б не стаў.
- Наколькі важна маніторыць тое, што адбываецца ў Serverless?
ара: Залежыць ад архітэктуры сістэмы і патрабаванняў бізнесу. Па сутнасці, правайдэр павінен падаваць справаздачнасць, якая дапаможа дэвапсу разабрацца ў магчымых праблемах.
Мікалай: У Амазоне ёсць CloudWatch, куды стрымаюцца ўсе логі, у тым ліку і з Lambda. Інтэгруйце перасылку логаў і выкарыстоўвайце нейкую асобную прыладу для прагляду, алертынгу і гэтак далей. У кантэйнеры, якія вы стартуеце, можна напіхаць агентаў.
- Давайце падвядзем вынік.
Андрэй: Думаць аб Lambda-функцыях карысна. Калі вы ствараеце сэрвіс на каленцы – не мікрасэрвіс, а такі, які піша запыт, звяртаецца да БД і дасылае адказ – Lambda-функцыя вырашае цэлы шэраг праблем: са шматструменнасцю, маштабаванасцю і іншым. Калі ў вас логіка пабудавана падобнай выявай, то ў будучыні вы зможаце гэтыя Lambda перанесці ў мікрасэрвісы або скарыстацца іншымі сэрвісамі накшталт Амазона. Тэхналогія карысная, ідэя цікавая. Наколькі яна апраўдана для бізнесу - гэта пакуль адкрытае пытанне.
Мікалай: Serverless лепш ужываць для operation-задач, чым для разліку нейкай бізнэс-логікі. Я заўжды ўспрымаю гэта як event processing. Калі ў вас у Амазоне ён ёсць, калі вы ў Kubernetes - так. Інакш вам давядзецца даволі шмат намаганняў прыкласці, каб падняць Serverless самастойна. Неабходна глядзець канкрэтны бізнэс-кейс. Напрыклад, у мяне зараз адна з задач: калі з'яўляюцца файлы на дыску ў пэўным фармаце - трэба іх заліваць у Kafka. Я гэта магу выкарыстоўваць WatchDog ці Lambda. З пункту гледжання логікі падыходзяць абодва варыянты, але па рэалізацыі Serverless складаней, і я аддаю перавагу прасцейшы шлях, без Lambda.
ара: Serverless - ідэя цікавая, дастасавальная, вельмі тэхнічна прыгожая. Рана ці позна тэхналогіі дойдуць да таго, што любая функцыя будзе паднімацца менш, чым за 100 мілісекунд. Тады ў прынцыпе адпадзе пытанне аб тым, ці крытычна для карыстача час чакання. Пры гэтым дастасавальнасць Serverless, як ужо казалі калегі, цалкам залежыць ад бізнэс-задачы.
Мы дзякуем нашым спонсарам, якія нам вельмі дапамаглі:
- Прастора IT-канферэнцый «» за пляцоўку для канферэнцыі.
- Каляндар IT-мерапрыемстваў і выданне «» за інфармацыйную падтрымку і навіны.
- «» за падарункі.
- за сатворчасць.
- "Асацыяцыю электронных камунікацый" за ўцягнутасць і вопыт.
- Галоўнага фундатара - за ўсё!
Крыніца: habr.com