🥇Біз өндірісте сынап жатырмыз: Canary Deployment

Канария - үнемі ән салатын кішкентай құс. Бұл құстар метан мен көміртегі тотығына сезімтал. Ауадағы артық газдардың шағын концентрациясынан да олар есін жоғалтады немесе өледі. Алтын қазушылар мен кеншілер құстарды шахтаға алып кетті: канарейлер ән айтып жатқанда, сіз жұмыс істей аласыз, егер сіз үндемей отырсаңыз - шахтада газ бар және кететін уақыт келді. Кеншілер шахталардан тірі шығу үшін кішкентай құсты құрбандыққа шалды.

Ұқсас тәжірибе IT саласында да табылды. Мысалы, қызметтің немесе қолданбаның жаңа нұсқасын оның алдында тестілеу арқылы өндіріске орналастырудың стандартты тапсырмасында. Сынақ ортасы тым қымбат болуы мүмкін, автоматтандырылған сынақтар сіз қалағанның бәрін қамтымайды және сынамау және сапаны құрбан етпеу қауіпті. Дәл осы жерде Canary Deployment тәсілі пайдалы болады, мұнда нақты өндірістік трафик жаңа нұсқаға бағытталған. Тәсіл көмектеседі қауіпсіз жаңа нұсқаны тексеріңіз өндіріс үшін, үлкен мақсат үшін аздап құрбандық. Тәсіл қалай жұмыс істейтіні, не пайдалы және оны қалай жүзеге асыру керектігі туралы толығырақ айтып береді Андрей Маркелов (Андрей_В_Маркелов), Infobip компаниясында енгізу мысалында.

Андрей Маркелов - Infobip компаниясының жетекші бағдарламалық қамтамасыз ету инженері, 11 жыл бойы қаржы және телекоммуникация саласында Java қосымшаларын әзірлеумен айналысады. Ашық бастапқы өнімдерді әзірлейді, Atlassian қауымдастығына белсенді қатысады және Atlassian өнімдері үшін плагиндерді жазады. Прометей, Докер және Редистің евангелисті.

Infobip туралы

Бұл банктерге, бөлшек саудагерлерге, интернет-дүкендер мен көлік компанияларына өз клиенттеріне SMS, push, хаттар және дауыстық хабарламалар арқылы хабарлама жіберуге мүмкіндік беретін жаһандық телекоммуникациялық платформа. Мұндай бизнесте тұтынушылар хабарламаларды уақытында алу үшін тұрақтылық пен сенімділік маңызды.

Infobip IT инфрақұрылымы сандармен:

Дүние жүзіндегі 15 деректер орталығы;
500 бірегей қызмет жұмыс істейді;
2500 қызмет данасы, бұл командалардан әлдеқайда көп;
4,5 ТБ ай сайынғы трафик;
4,5 миллиард телефон нөмірі;

Бизнес өсіп келеді және онымен бірге шығарылымдар саны да артып келеді. жұмсаймыз Күніне 60 шығарылымөйткені тұтынушылар көбірек мүмкіндіктер мен қуатты қалайды. Бірақ бұл қиын - қызметтер көп, бірақ командалар аз. Өндірісте қатесіз жұмыс істейтін кодты жылдам жазу керек.

Шығарылымдар

Әдеттегі шығарылым осылай болады. Мысалы, A, B, C, D және E қызметтері бар, олардың әрқайсысын жеке команда әзірлейді.

Белгілі бір сәтте А сервисінің командасы жаңа нұсқаны қолдануды шешеді, бірақ B, C, D және E қызметтерінің командалары бұл туралы білмейді. А қызмет көрсету тобының әрекет етуінің екі нұсқасы бар.

ұстайды қосымша шығару: алдымен бір нұсқаны, содан кейін екіншісін ауыстырыңыз.

Бірақ екінші нұсқа бар: команда қосымша қуаттар мен машиналарды табады, жаңа нұсқаны орналастырыңыз, содан кейін маршрутизаторды ауыстырыңыз, сонда нұсқа өндіріс үшін жұмыс істей бастайды.

Кез келген жағдайда, нұсқа сыналған болса да, орналастырудан кейін дерлік дерлік проблемалар туындайды. Сіз қолмен тексере аласыз, оны автоматты түрде жасай аласыз, сынай алмайсыз - кез келген жағдайда проблемалар туындайды. Оларды шешудің ең оңай және дұрыс жолы - жұмыс нұсқасына оралу. Сонда ғана сіз зақымданумен, себептерімен күресіп, оларды түзете аласыз.

Сонымен, біз не қалаймыз?

Бізге проблемалар қажет емес. Егер тұтынушылар оларды бізден тезірек тауып алса, бұл олардың беделіне нұқсан келтіреді. Сондықтан біз керек тұтынушыларға қарағанда мәселелерді тезірек табады. Проактивті жұмыс жасай отырып, біз зиянды азайтамыз.

Сонымен бірге біз қалаймыз орналастыруды жеделдетуол тез, оңай, табиғи және команданың қысымынсыз жүзеге асуы үшін. Инженерлер, DevOps инженерлері және бағдарламашылары қорғалуы керек - жаңа нұсқаны шығару стрессті тудырады. Команда шығынсыз емес, біз ұмтыламыз адам ресурстарын ұтымды пайдалану.

Орналастыру проблемалары

Клиент трафигін болжау мүмкін емес. Клиент трафигі қашан ең аз болатынын болжау мүмкін емес. Біз клиенттердің науқандарын қай жерде және қашан бастайтынын білмейміз - мүмкін бүгін түнде Үндістанда, ертең Гонконгта. Үлкен уақыт айырмашылығын ескере отырып, тіпті түнгі сағат 2-де орналастыру тұтынушыларға әсер етпейтініне кепілдік бермейді.

Провайдер проблемалары. Хабаршылар мен провайдерлер біздің серіктестеріміз. Кейде оларда жаңа нұсқаларды орналастыру кезінде қателер тудыратын апаттар болады.

Бөлінген командалар. Клиенттік жағы мен бэкендті дамытатын топтар әртүрлі уақыт белдеуінде. Осыған байланысты олар жиі өзара келісе алмайды.

Деректер орталықтарын сахнада қайталау мүмкін емес. Бір деректер орталығында 200 тірек бар - сіз оны құм жәшігінде шамамен қайталай алмайсыз.

Тоқтауларқабылданбайды! Мысалы, біз уақыттың 99,99% жұмыс істеген кезде қате бюджетіміз бар, ал қалған пайызы «қателік маржа». 100% сенімділікке қол жеткізу мүмкін емес, бірақ құлдырау мен тоқтау уақытын үнемі бақылау маңызды.

Классикалық шешімдер

Қателерсіз кодты жазыңыз. Мен жас әзірлеуші кезімде менеджерлер қатесіз шығаруды өтінді, бірақ бұл әрқашан мүмкін емес.

Тесттер жазу. Тесттер жұмыс істейді, бірақ кейде бизнес қалағандай емес. Ақша табу сынақтың жұмысы емес.

Сахнадағы сынақ. Infobip-те жұмыс істеген 3,5 жыл ішінде мен сахнаның күйі өндіріспен жартылай сәйкес келетінін ешқашан көрген емеспін.

Біз тіпті осы идеяны дамытуға тырыстық: алдымен бізде сахна, содан кейін алдын-ала өндіріс, содан кейін алдын-ала өндіріс болды. Бірақ бұл да көмектеспеді - олар тіпті билікке сәйкес келмеді. Кезең арқылы біз негізгі функционалдылыққа кепілдік бере аламыз, бірақ оның жүктеме кезінде қалай жұмыс істейтінін білмейміз.

Шығарылымды оны әзірлеген адам жасайды. Бұл жақсы тәжірибе: біреу түсініктеменің атын өзгертсе де, оны бірден өндіріске қосады. Бұл жауапкершілікті дамытуға және енгізілген өзгерістерді ұмытпауға көмектеседі.

Қосымша асқынулар да бар. Әзірлеушіге бәрін қолмен тексеруге көп уақыт жұмсау стрессті тудырады.

Келісілген шығарылымдар. Бұл опцияны әдетте басшылық ұсынады: «Күн сайын жаңа нұсқаларды сынап, қосатыныңызға келістік». Бұл жұмыс істемейді: әрқашан басқаларды күтіп тұрған команда бар немесе керісінше.

Түтін сынақтары

Орналастыру мәселелерін шешудің тағы бір жолы. А тобы жаңа нұсқаны қолданғысы келгенде, алдыңғы мысалда түтін сынақтарының қалай жұмыс істейтінін қарастырыңыз.

Біріншіден, топ өндіріске бір дананы қолданады. Мысықтардан данаға хабарлар нақты трафикті модельдейдіқалыпты күнделікті трафикті сәйкестендіру үшін. Егер бәрі жақсы болса, команда жаңа нұсқаны пайдаланушы трафигіне ауыстырады.

Екінші нұсқа - орналастыру қосымша темірмен. Команда оны өндіріске тексереді, содан кейін ауыстырады және бәрі жұмыс істейді.

Түтін сынақтарының кемшіліктері:

Тесттерге сенуге болмайды. Өндірістегідей трафикті қайдан алуға болады? Сіз кеше немесе бір апта бұрын пайдалана аласыз, бірақ ол әрқашан қазіргіге сәйкес келмейді.
Күту қиын. Белсенді жазбалар репозиторийге жіберілген кезде, сынақ тіркелгілерін жүргізуге, әрбір орналастыру алдында оларды үнемі қалпына келтіруге тура келеді. Бұл өз құм жәшігінде сынақ жазудан қиынырақ.

Мұндағы жалғыз бонус өнімділігін тексеруге болады.

Канария шығарады

Түтін сынақтарының кемшіліктеріне байланысты біз канарей шығарылымдарын пайдалана бастадық.

Кеншілердің газ деңгейін көрсету үшін канареяларды қалай пайдаланғанына ұқсас тәжірибе IT-ға жол тапты. Біз рұқсат етеміз жаңа нұсқаға нақты өндірістік трафикҚызмет көрсету деңгейі келісімін (SLA) орындауға тырысқанда. SLA - бұл біз жылына бір рет (немесе басқа уақыт кезеңінде) пайдалана алатын «қате жасау құқығымыз». Егер бәрі жақсы болса, біз көбірек трафик қосамыз. Олай болмаса, біз алдыңғы нұсқаларды қайтарамыз.

Іске асыру және нюанстар

Канар шығаруды қалай жүзеге асырдық? Мысалы, клиенттер тобы біздің қызметіміз арқылы хабарламалар жібереді.

Орналастыру келесідей болады: біз балансизатордың астынан бір түйінді алып тастаймыз (1), нұсқаны өзгертеміз (2) және кейбір трафикті бөлек жібереміз (3).

Жалпы, бір қолданушы көңілсіз болса да, топтағылардың бәрі бақытты болады. Егер бәрі жақсы болса, біз барлық нұсқаларды өзгертеміз.

Мен көп жағдайда микросервистерді қалай іздейтінін схемалық түрде көрсетемін.

Service Discovery және тағы екі қызмет бар: S1N1 және S2. Бірінші қызмет (S1N1) іске қосылғанда Service Discovery туралы хабарлайды және Service Discovery оны есте сақтайды. Екі түйіні бар екінші қызмет (S2N1 және S2N2) іске қосылғанда Service Discovery туралы хабарлайды.

Біріншісі үшін екінші қызмет сервер ретінде жұмыс істейді. Біріншісі Service Discovery қызметінен серверлері туралы ақпаратты сұрайды және оны алған кезде оларды іздейді және тексереді («денсаулығын тексеру»). Тексергенде, ол оларға хабарламалар жібереді.

Біреу екінші қызметтің жаңа нұсқасын қолданғысы келгенде, ол Service Discovery-ге екінші түйін канар түйіні болатынын айтады: оған трафик азырақ жіберіледі, себебі орналастыру қазір орын алады. Канар түйінін балансизатордың астынан алып тастаймыз және бірінші қызмет оған трафик жібермейді.

Біз нұсқаны өзгертеміз және Service Discovery екінші түйін енді канариялық екенін біледі - сіз оған аз жүктеме (5%) бере аласыз. Егер бәрі жақсы болса, біз нұсқаны өзгертеміз, жүктемелерді қайтарамыз және жұмыс істейміз.

Мұның бәрін жүзеге асыру үшін бізге қажет:

теңгеру;
мониторингөйткені әрбір пайдаланушы не күтетінін және біздің қызметтеріміздің қалай жұмыс істейтінін егжей-тегжейлі білу маңызды;
нұсқасын талдаужаңа нұсқаның өндірісте қаншалықты жақсы жұмыс істейтінін түсіну;
автоматтандыру - орналастыру ретін жазамыз (орналастыру құбыры).

Теңестіру

Бұл бірінші кезекте ойлануымыз керек. Екі теңдестіру стратегиясы бар.

Ең қарапайым нұсқа қашан бір түйін әрқашан канарей. Бұл түйін әрқашан аз трафик алады және біз одан орналастыруды бастаймыз. Мәселелер туындаған жағдайда, біз оның жұмысын орналастыруға дейін және оның барысында салыстырамыз. Мысалы, қателер 2 есе көп болса, онда зиян 2 есе өсті.

Canary түйіні орналастыру процесі кезінде орнатылады. Орналастыру аяқталып, одан канарлы түйін күйін алып тастағанда, трафик балансы қалпына келтіріледі. Көліктер аз болса, біз әділ үлестіреміз.

Бақылау

Канарияның ірге тасы шығарылады. Біз мұны не үшін істеп жатқанымызды және қандай көрсеткіштерді жинағымыз келетінін түсінуіміз керек.

Қызметтерімізден жинайтын көрсеткіштер мысалдары.

Қателер саны, олар журналдарға жазылады. Бұл барлығының өз ретімен жұмыс істеп жатқанының айқын көрсеткіші. Жалпы, бұл жақсы көрсеткіш.
Сұраудың орындалу уақыты (кідіріс). Барлығы бұл көрсеткішті бақылайды, себебі барлығы жылдам жұмыс істегісі келеді.
Кезек өлшемі (өткізу қабілеті).
Секундына сәтті жауаптар саны.
Барлық сұраныстардың 95% орындалу уақыты.
Іскерлік көрсеткіштер: белгілі бір уақыт көлемінде бизнес қанша ақша табады немесе пайдаланушының шығыны. Біздің жаңа нұсқамызға арналған бұл көрсеткіштер инженерлер қосқаннан маңыздырақ болуы мүмкін.

Ең танымал мониторинг жүйелеріндегі метрика мысалдары.

Есептегіш Бұл кейбір өсіп келе жатқан мән, мысалы, қателер саны. Бұл көрсеткішті интерполяциялау және диаграмманы зерттеу оңай: кеше 2 қате болды, ал бүгін 500, яғни бірдеңе дұрыс болмады.

Минуттағы немесе секундтағы қателер саны Counter көмегімен есептелетін ең маңызды көрсеткіш болып табылады. Бұл деректер жүйенің қашықтықта қалай жұмыс істейтіні туралы нақты суретті береді. Өндірістік жүйенің екі нұсқасы үшін секундына қателер санының графигінің мысалын қарастырыңыз.

Бірінші нұсқада қателер аз болды, мүмкін аудит жұмыс істемеді. Екінші нұсқада бәрі әлдеқайда нашар. Мәселелер бар екенін нақты айта аламыз, сондықтан бұл нұсқаны кері қайтару керек.

Өлшеуіш. Көрсеткіштер Counter-ге ұқсас, бірақ біз көбейтетін немесе азайтатын мәндерді жазамыз. Мысалы, сұраудың орындалу уақыты немесе кезек өлшемі.

График кідірістің мысалын көрсетеді. График нұсқалардың ұқсас екенін көрсетеді, олармен жұмыс істеуге болады. Бірақ мұқият қарасаңыз, мәннің қалай өзгеретінін көре аласыз. Егер пайдаланушылар қосылған кезде сұраудың орындалу уақыты артса, онда проблемалардың бар екені бірден белгілі болады - бұл бұрын болмаған.

Жиынтық. Бизнес үшін ең маңызды көрсеткіштердің бірі - пайыздық көрсеткіштер. Бұл көрсеткіш көрсетеді Жағдайлардың 95% біздің жүйе біз қалағандай жұмыс істейді. Бір жерде проблемалар болса, біз қабылдай аламыз, өйткені біз жалпы тенденцияны түсінеміз, бәрі қаншалықты жақсы немесе жаман.

Құралдар

ELK стек. Elasticsearch көмегімен канареяны жүзеге асыруға болады - оқиғалар орын алған кезде оған қателер жазамыз. Ең қарапайым API қоңырауының көмегімен кез келген уақытта қателер санын алуға және өткен сегменттермен салыстыруға болады: GET /applg/_cunt?q=level:errr.

Prometheus. Ол Infobip бағдарламасында өзін жақсы көрсетті. Ол көп өлшемді көрсеткіштерді енгізуге мүмкіндік береді, себебі белгілер пайдаланылады.

Пайдалана аламыз level, instance, service, оларды бір жүйеге біріктіріңіз. Көмегімен offset мысалы, бір апта бұрынғы мәннің мәнін тек бір пәрмен арқылы көруге болады GET /api/v1/query?query={query}қайда {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

Нұсқа талдауы

Нұсқалаудың бірнеше стратегиялары бар.

Тек канар түйіндерінің көрсеткіштерін қараңыз. Ең қарапайым нұсқалардың бірі: жаңа нұсқаны орналастыру және тек жұмысты зерттеу. Бірақ егер инженер осы уақытта журналдарды зерттей бастаса, беттерді үнемі жүйкемен қайта жүктесе, онда бұл шешім басқалардан ерекшеленбейді.

Канарлы түйін кез келген басқа түйінмен салыстырылады. Бұл толық трафикте жұмыс істейтін басқа даналармен салыстыру. Мысалы, аз трафикпен жағдайлар нашар болса немесе нақты жағдайлардан жақсы болмаса, онда бірдеңе дұрыс емес.

Канар түйіні бұрын өзімен салыстырылады. Канарияға бөлінген түйіндерді тарихи деректермен салыстыруға болады. Мысалы, бір апта бұрын бәрі жақсы болса, қазіргі жағдайды түсіну үшін осы деректерге назар аудара аламыз.

Автоматтандыру

Біз инженерлерді қолмен салыстырудан босатқымыз келеді, сондықтан автоматтандыруды енгізу маңызды. Орналастыру құбыры әдетте келесідей көрінеді:

бастаймыз;
балансирдің астынан түйінді алып тастаңыз;
канар түйінін орнату;
трафиктің шектеулі мөлшері бар балансизаторды қосыңыз;
салыстыру.

Бұл кезеңде біз жүзеге асырамыз автоматты салыстыру. Ол қалай көрінуі мүмкін және неге ол орналастырудан кейін тексеруден жақсырақ, Дженкинстің мысалын қарастырайық.

Бұл Groovy-ге баратын құбыр.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

Мұнда циклде біз жаңа түйінді бір сағатқа салыстырамыз деп белгіледік. Канарлы процесс процесті әлі аяқтамаған болса, біз функцияны шақырамыз. Ол бәрі жақсы немесе жоқ деп хабарлайды: def isOk = compare(srv, canary, time, base, offset, metrics).

Егер бәрі жақсы болса - sleep DEFAULT SLEEP, мысалы, бір секундқа және жалғастырыңыз. Олай болмаса, шығыңыз — орналастыру сәтсіз аяқталды.

Метриканың сипаттамасы. Функцияның қандай болуы мүмкін екенін көрейік compare DSL мысалында.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

Біз қателер санын салыстырып жатырмыз делік және соңғы 5 минуттағы секундына жіберілген қателер санын білгіміз келеді.

Бізде екі мән бар: негізгі және канар түйіндері. Канар түйінінің мәні ағымдағы болып табылады. Негізгі - baseValue кез келген басқа канарлық емес түйіннің мәні болып табылады. Біз мәндерді тәжірибеміз бен бақылауларымызға негізделген формула бойынша бір-бірімен салыстырамыз. Мән болса canaryValue нашар, содан кейін орналастыру сәтсіз аяқталды және біз кері ораламыз.

Мұның бәрі не үшін қажет?

Адам жүздеген және мыңдаған көрсеткіштерді тексере алмайдыәсіресе оны тез орындау үшін. Автоматты салыстыру барлық көрсеткіштерді тексеруге көмектеседі және ақаулықтар туралы жылдам хабарлайды. Ескерту уақыты өте маңызды: егер соңғы 2 секундта бірдеңе болса, залал 15 минут бұрын болғандай үлкен болмайды. Біреу мәселені байқамайынша, қолдау қызметіне жазбайынша және кері қайтару үшін бізге қолдау көрсетпейінше, тұтынушыларды жоғалтуыңыз мүмкін.

Егер процесс аяқталса және бәрі жақсы болса, біз барлық басқа түйіндерді автоматты түрде орналастырамыз. Осы уақыт ішінде инженерлер ештеңе істемейді. Олар канареяны іске қосқан кезде ғана олар қандай көрсеткіштерді алу керектігін, салыстыруды қанша уақыт жасау керектігін, қандай стратегияны қолдану керектігін шешеді.

Мәселелер туындаса, біз канарей түйінін автоматты түрде қайтарамыз, алдыңғы нұсқалармен жұмыс істейміз және біз тапқан қателерді түзетеміз. Көрсеткіштер бойынша олар жаңа нұсқадағы зақымдарды табу және көру оңай.

Кедергілер

Әрине, мұны жүзеге асыру оңай емес. Ең алдымен сізге қажет жалпы бақылау жүйесі. Инженерлердің өз көрсеткіштері бар, қолдау және талдаушыларда әртүрлі, ал бизнесте үшінші көрсеткіштер бар. Ортақ жүйе – бұл бизнес пен дамудың ортақ тілі.

Тәжірибеде сынау керек метрикалық тұрақтылық. Тексеру түсінуге көмектеседі сапаны қамтамасыз ету үшін қажетті көрсеткіштердің ең аз жиынтығы қандай.

Бұған қалай қол жеткізуге болады? Орналастыру кезінде емес canary-service пайдаланыңыз. Біз ескі нұсқаға белгілі бір қызметті қосамыз, ол кез келген уақытта кез келген арнайы түйінді қабылдай алады, орналастырусыз трафикті азайтады. Салыстырғаннан кейін: біз қателерді зерттейміз және сапаға жеткенде сол сызықты іздейміз.

Канар шығарылымдарынан қандай пайда алдық?

Қателерден болатын зиянның пайызы азайтылды. Орналастыру қателерінің көпшілігі кейбір деректердегі немесе басымдықтағы сәйкессіздіктерге байланысты. Мұндай қателер әлдеқайда аз, өйткені біз мәселені алғашқы секундтарда шеше аламыз.

Оңтайландырылған командалық жұмыс. Жаңадан бастағандардың «қателесуге құқығы» бар: олар қателесуден қорықпай өндіріске орналаса алады, қосымша бастама, жұмыс істеуге ынталандыру бар. Бірдеңені бұзса, сын көтермейді, қателескен жұмыстан шығарылмайды.

Автоматтандырылған орналастыру. Бұл бұрынғыдай қолмен орындалатын процесс емес, нағыз автоматтандырылған процесс. Бірақ бұл ұзағырақ уақыт алады.

Маңызды көрсеткіштерді атап өтті. Бизнес пен инженерлерден бастап бүкіл компания біздің өнімде шын мәнінде не маңызды екенін, қандай көрсеткіштерді, мысалы, пайдаланушылардың кетуі мен ағынын түсінеді. Біз процесті бақылаймыз: көрсеткіштерді сынаймыз, жаңаларын енгіземіз, ақшаны тиімдірек ететін жүйені құру үшін ескілерінің қаншалықты жұмыс істейтінін көреміз.

Бізде бізге көмектесетін көптеген керемет тәжірибелер мен жүйелер бар. Осыған қарамастан, бізге көмектесетін жүйе бар-жоғына қарамастан, біз кәсіби болуға және өз жұмысымызды жақсы орындауға тырысамыз.

Инженерлік тәсілдер мен тәжірибелер - TechLead Conf негізгі бағыты. Егер сіз техникалық жетістіктерге жету жолында жетістікке жеткен болсаңыз және сізге бұл жерде не көмектескенін айтуға дайын болсаңыз, — есеп беруге өтініш.

жоспарлап отырмыз Tech Lead Conf 8 маусым. Біз қазір конференцияға қатысу туралы шешім қабылдау қиын екенін түсінеміз. Бірақ сонымен бірге, біз карантин кәсіби қарым-қатынас пен дамуды тоқтатуға себеп емес деп санаймыз. Сондықтан, кез келген жағдайда, біз техникалық жетекшінің міндеттерін және оларды шешу тәсілдерін талқылаудың жолын табамыз - қажет болса, біз желіге кіріп, сол жерде желіні орнатамыз!

Ақпарат көзі: www.habr.com