DUMP ညီလာခံ | grep 'backend|devops'

ပြီးခဲ့သည့်အပတ်က Yekaterinburg ရှိ DUMP IT ကွန်ဖရင့် (https://dump-ekb.ru/) သို့ ကျွန်ုပ်သွားခဲ့ပြီး Backend နှင့် Devops ကဏ္ဍများတွင် ဆွေးနွေးခဲ့သည်များကို ပြောပြလိုသည်၊၊ ဒေသဆိုင်ရာ အိုင်တီကွန်ဖရင့်များသည် အာရုံစိုက်သင့်သည်ဖြစ်စေ၊

Serverless အကြောင်း Evil Martians မှ Nikolay Sverchkov

အဲဒီမှာ ဘာရှိလဲ။

စုစုပေါင်း၊ ညီလာခံတွင် အပိုင်း ၈ ပိုင်းပါရှိသည်- Backend၊ Frontend၊ Mobile၊ Testing နှင့် QA၊ Devops၊ Design၊ Science နှင့် Management။

အကြီးဆုံးခန်းမများသည် Science and Management တွင်ဖြစ်သည်)) တစ်ဦးလျှင် 350 ယောက်အတွက်။ Backend နှင့် Frontend သည် သိပ်မသေးငယ်ပါ။ Devops အခန်းသည် အသေးဆုံးဖြစ်သော်လည်း တက်ကြွသည်။

Devops နှင့် Backend ကဏ္ဍများရှိ အစီရင်ခံစာများကို နားထောင်ပြီး စပီကာများနှင့် အနည်းငယ်ပြောခဲ့သည်။ ဆွေးနွေးပွဲမှာ ပါဝင်တဲ့ အကြောင်းအရာတွေကို ဆွေးနွေးပြီး အဲဒီအပိုင်းတွေကို ပြန်လည်သုံးသပ်ချင်ပါတယ်။

SKB-Kontur၊ DataArt၊ Evil Martians၊ Ekaterinburg ဝဘ်စတူဒီယို Flag၊ Miro (RealTimeBoard) ၏ ကိုယ်စားလှယ်များသည် Devops နှင့် Backend ကဏ္ဍများတွင် ဟောပြောခဲ့သည်။ CI/CD နှင့် အကျုံးဝင်သော ခေါင်းစဉ်များ၊ တန်းစီခြင်းဝန်ဆောင်မှုများနှင့် လုပ်ဆောင်ခြင်း၊ မှတ်တမ်းမှတ်ခြင်းများ၊ ဆာဗာမဲ့အကြောင်းအရာများနှင့် Go ရှိ PostgreSQL နှင့် လုပ်ဆောင်ခြင်းတို့ကို ကောင်းမွန်စွာ ခြုံငုံမိပါသည်။

Avito၊ Tinkoff၊ Yandex၊ Jetstyle၊ Megafon၊ Ak Bars Bank တို့မှ အစီရင်ခံစာများပါရှိသော်လည်း ၎င်းတို့အား ကာယကံမြောက်တက်ရောက်ရန် အချိန်မရှိပါ (အစီရင်ခံစာများ၏ ဗီဒီယိုမှတ်တမ်းများနှင့် ဆလိုက်များကို မရရှိနိုင်သေးပါ၊ ၎င်းတို့ကို ၂ ပတ်အတွင်း တင်ပေးမည်ဟု ကတိပြုပါသည်။ dump-ekb.ru တွင်)။

Devops ကဏ္ဍ

အံ့သြစရာကောင်းတာက အခန်းကို အသေးဆုံးခန်းမထဲမှာ ထိုင်ခုံ ၅၀ လောက်နဲ့ ကျင်းပခဲ့တာပါ။ လူတွေက အတန်းထဲမှာတောင် ရပ်နေကြတယ် :) ငါ နားထောင်နိုင်ခဲ့တဲ့ အစီရင်ခံစာတွေအကြောင်း မင်းကို ပြောပြမယ်။

တစ်ပေတာဘိုက်အလေးချိန်ရှိသော Elastic

အပိုင်းသည် Kontur ရှိ Elasticsearch အကြောင်း ဗလာဒီမာလီ (SKB-Kontur) မှ အစီရင်ခံစာဖြင့် စတင်ခဲ့သည်။ ၎င်းတို့တွင် အလွန်ကြီးမားပြီး တင်ဆောင်ထားသော Elastic (ဒေတာ ~ 800 TB၊ ~ 1.3 ပီတာဘိုက်) တွင် မလိုအပ်တော့ပါ။ Kontur ဝန်ဆောင်မှုအားလုံးအတွက် Elasticsearch သည် တစ်ခုတည်းဖြစ်ပြီး အစုအဝေး 2 ခု (ဆာဗာ 7 နှင့် 9 ၏) ပါ၀င်ပြီး Kontur တွင် အထူး Elasticsearch အင်ဂျင်နီယာ (တကယ်တော့ ဗလာဒီမာကိုယ်တိုင်) ပါရှိပါသည်။

ဗလာဒီမာသည် Elasticsearch ၏အကျိုးကျေးဇူးများနှင့်၎င်း၏ပြဿနာများကိုမျှဝေခဲ့သည်။

အကျိုးကျေးဇူး-

• မှတ်တမ်းများအားလုံးကို တစ်နေရာတည်းတွင် အလွယ်တကူ ဝင်ရောက်နိုင်သည်။
• မှတ်တမ်းများကို တစ်နှစ်ကြာ သိမ်းဆည်းပြီး ၎င်းတို့ကို အလွယ်တကူ ခွဲခြမ်းစိတ်ဖြာပါ။
• သစ်လုံးများဖြင့် အလုပ်လုပ်ရာတွင် အရှိန်အဟုန်မြင့်သည်။
• အမိုက်စား ဒေတာ စိတ်ကူးပုံဖော်မှု ဘောက်စ်ထဲက

ပြနာများ -

• မက်ဆေ့ချ်ပွဲစားသည် မရှိမဖြစ် (Kontur အတွက် ၎င်း၏အခန်းကဏ္ဍကို Kafka မှကစားသည်)
• Elasticsearch Curator နှင့် လုပ်ဆောင်ခြင်း၏ အင်္ဂါရပ်များ ( Curator တွင် ပုံမှန်အလုပ်များမှ အချိန်အခါအလိုက် မြင့်မားသောဝန်ထုပ်ဝန်ပိုးကို ဖန်တီးထားသည်)
• Built-in ခွင့်ပြုချက်မရှိပါ (သီးခြား၊ အလွန်ကြီးမားသော ငွေကြေးအတွက်သာ သို့မဟုတ် ထုတ်လုပ်ရန်အတွက် အဆင်သင့်ဖြစ်မှုဒီဂရီအမျိုးမျိုးရှိသော open source ပလပ်အင်များအဖြစ်)

Elasticsearch အတွက် Open Distro နှင့် ပတ်သက်၍ အပြုသဘောဆောင်သော သုံးသပ်ချက်များသာ ရှိခဲ့သည် ။ :) အလားတူ ခွင့်ပြုချက် ကိစ္စကို ဖြေရှင်းပြီးပါပြီ။

petabyte က ဘယ်ကလာတာလဲ။၎င်းတို့၏ ဆုံမှတ်များတွင် 12*8 Tb SATA + 2*2 Tb SSD ပါရှိသော ဆာဗာများ ပါဝင်သည်။ SATA တွင် အအေးခန်းသိုလှောင်မှု၊ ပူသောကက်ရှ် (hot storage) အတွက်သာ SSD။
7+9 ဆာဗာများ၊ (7 + 9) * 12 * 8 = 1536 Tb ။
နေရာ၏တစ်စိတ်တစ်ပိုင်းကို အရံထားရှိထားပြီး၊ ထပ်နေသောနေရာများအတွက် ဘေးဖယ်ထားရန်၊
အပလီကေးရှင်း 90 ခန့်မှ မှတ်တမ်းများကို Kontur၊ Elba စသည်တို့၏ အစီရင်ခံခြင်းဝန်ဆောင်မှုအားလုံးအပါအဝင် Elasticsearch သို့ ပေးပို့ပါသည်။

Serverless တွင် ဖွံ့ဖြိုးတိုးတက်မှုဆိုင်ရာ အင်္ဂါရပ်များ

နောက်တစ်ခုသည် Serverless အကြောင်း DataArt မှ Ruslan Serkin ၏အစီရင်ခံစာဖြစ်သည်။

Ruslan သည် Serverless ချဉ်းကပ်မှုတွင် ယေဘုယျအားဖြင့် မည်သည့်တိုးတက်မှုနှင့် ၎င်း၏အင်္ဂါရပ်များအကြောင်း ဆွေးနွေးခဲ့သည်။

Serverless သည် ဆော့ဖ်ဝဲအင်ဂျင်နီယာများသည် အခြေခံအဆောက်အအုံကို မည်သည့်နည်းနှင့်မျှ မထိမခိုက်နိုင်သော ဖွံ့ဖြိုးတိုးတက်မှုအတွက် ချဉ်းကပ်မှုတစ်ခုဖြစ်သည်။ ဥပမာ - AWS Lambda Serverless၊ Kubeless.io ( Kubernetes အတွင်းရှိ ဆာဗာမဲ့)၊ Google Cloud Functions။

စံပြ serverless application သည် အထူး API Gateway မှတဆင့် Serverless ဝန်ဆောင်မှုပေးသူထံ တောင်းဆိုချက်တစ်ခုပေးပို့သည့် လုပ်ဆောင်ချက်တစ်ခုဖြစ်သည်။ AWS Lambda သည် ခေတ်မီပရိုဂရမ်းမင်းဘာသာစကားများစွာကို ပံ့ပိုးပေးသော်လည်း စံပြအသေးစားဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ အခြေခံအဆောက်အဦ ထိန်းသိမ်းခြင်းနှင့် အသုံးချခြင်းအတွက် ကုန်ကျစရိတ်သည် cloud ပံ့ပိုးပေးသူများ၏ အခြေအနေတွင် သုညဖြစ်သွားသည်၊၊ အသေးစား အပလီကေးရှင်းများကို ပံ့ပိုးပေးခြင်းသည်လည်း အလွန်စျေးသက်သာလိမ့်မည် (AWS Lambda - $0.2 / 1 million ရိုးရှင်းသော တောင်းဆိုမှုများ)။

ထိုစနစ်၏ အတိုင်းအတာသည် အကောင်းဆုံးနီးပါးဖြစ်သည် - cloud ဝန်ဆောင်မှုပေးသူက ၎င်းကို သူ့ဘာသာသူဂရုစိုက်သည်၊ Kubeless သည် Kubernetes အစုအဝေးအတွင်း အလိုအလျောက် ချိန်ညှိပေးသည်။

အားနည်းချက်များရှိသည်-

• ကြီးမားသော အပလီကေးရှင်းများကို တီထွင်ရန်မှာ ပိုမိုခက်ခဲလာသည်။
• ပရိုဖိုင်အပလီကေးရှင်းများကို ရေးသွင်းရာတွင် အခက်အခဲရှိပါသည် (မှတ်တမ်းများသာ သင့်အတွက် ရနိုင်သော်လည်း ပုံမှန်သဘောအရ ပရိုဖိုင်ပြုလုပ်ခြင်းမဟုတ်ပါ)
• ဗားရှင်းမရှိပါ။

ရိုးရိုးသားသားပြောရရင် Serverless အကြောင်းကို လွန်ခဲ့တဲ့နှစ်အနည်းငယ်က ကျွန်တော်ကြားဖူးပေမယ့် ဒီနှစ်တွေအကုန်လုံး အဲဒါကို ဘယ်လိုမှန်မှန်ကန်ကန်သုံးရမလဲဆိုတာ ကျွန်တော့်အတွက် မရှင်းလင်းပါဘူး။ Ruslan ၏အစီရင်ခံစာပြီးနောက်၊ နားလည်မှုပေါ်လာပြီး Backend ကဏ္ဍမှ Nikolai Sverchkov (Evil Martians) ၏အစီရင်ခံစာအပြီးတွင်၎င်းကိုပေါင်းစည်းခဲ့သည်။ ညီလာခံတက်ရတာ အလကားမဟုတ်ဘူး :)

CI သည် ဆင်းရဲသူများအတွက်ဖြစ်သည် သို့မဟုတ် ဝဘ်စတူဒီယိုအတွက် သင့်ကိုယ်ပိုင် CI ကို ရေးသင့်ပါသလား။

Yekaterinburg မှ Flag ဝဘ်စတူဒီယို၏အကြီးအကဲ Mikhail Radionov က ကိုယ်တိုင်ရေးထားသော CI/CD အကြောင်းပြောခဲ့သည်။

သူ၏စတူဒီယိုသည် "လက်စွဲ CI/CD" (SSH မှတဆင့် ဆာဗာသို့ဝင်ရောက်ပါ၊ git ဆွဲပါ၊ တစ်နေ့လျှင် အကြိမ် 100 ပြန်လုပ်ပါ) Jenkins နှင့် Pullkins ဟုခေါ်သော ကုဒ်များကို စောင့်ကြည့်ရန်နှင့် ထုတ်ဝေမှုများကို လုပ်ဆောင်နိုင်စေမည့် ကိုယ်တိုင်ရေးထားသော ကိရိယာသို့ သွားပြီဖြစ်သည်။ .

Jenkins ဘာကြောင့် အလုပ်မလုပ်တာလဲ။ ၎င်းသည် ပုံမှန်အားဖြင့် လုံလောက်သော ပြောင်းလွယ်ပြင်လွယ်ကို မပေးစွမ်းဘဲ စိတ်ကြိုက်ပြင်ဆင်ရန် အလွန်ခက်ခဲသည်။

“အလံ” သည် Laravel (PHP မူဘောင်) တွင် ဖွံ့ဖြိုးသည်။ CI/CD ဆာဗာကို တီထွင်သောအခါတွင်၊ Mikhail နှင့် သူ၏လုပ်ဖော်ကိုင်ဖက်များသည် Laravel ၏ တပ်ဆင်ထားသော ယန္တရားများကို Telescope and Envoy ဟုခေါ်သည်။ ရလဒ်သည် ဝင်လာသော webhook တောင်းဆိုမှုများကို လုပ်ဆောင်ပေးသည့် PHP ရှိ ဆာဗာတစ်ခုဖြစ်ပြီး ရှေ့တန်းနှင့် နောက်ကွယ်တွင် တည်ဆောက်နိုင်သည်၊ မတူညီသော ဆာဗာများသို့ အသုံးချကာ Slack သို့ သတင်းပို့နိုင်သည်။

ထို့နောက်၊ အပြာ/အစိမ်း deploy ကို လုပ်ဆောင်နိုင်ပြီး dev-stage-prod ပတ်၀န်းကျင်တွင် တူညီသောဆက်တင်များရှိနေစေရန်၊ ၎င်းတို့သည် Docker သို့ ပြောင်းခဲ့သည်။ အားသာချက်များသည် အတူတူပင်ဖြစ်သည်၊ ပတ်ဝန်းကျင်ကို တစ်သားတည်းဖြစ်စေရန် နှင့် ချောမွေ့စွာ အသုံးချနိုင်မှုတို့ကို ပေါင်းထည့်ခဲ့ပြီး ၎င်းနှင့် မှန်ကန်စွာလုပ်ဆောင်ရန် Docker ကို လေ့လာရန် လိုအပ်ကြောင်း ထပ်လောင်းပြောကြားခဲ့သည်။

ပရောဂျက်သည် Github တွင်ရှိသည်။

ကျွန်ုပ်တို့သည် ဆာဗာထုတ်လွှတ်မှု နောက်ပြန်ဆုတ်ခြင်းအရေအတွက်ကို 99% လျှော့ချနည်း

Devops ကဏ္ဍရှိ နောက်ဆုံးအစီရင်ခံစာမှာ Miro.com (ယခင် RealTimeBoard) မှ Lead devops အင်ဂျင်နီယာ Viktor Eremchenko ထံမှဖြစ်သည်။

Miro အဖွဲ့၏ အထင်ကရ ထုတ်ကုန်ဖြစ်သော RealTimeBoard သည် monolithic Java အပလီကေးရှင်းကို အခြေခံထားသည်။ အချိန်မဆွဲဘဲ စုဆောင်းခြင်း၊ စမ်းသပ်ခြင်းနှင့် အသုံးပြုခြင်းသည် ခက်ခဲသော အလုပ်ဖြစ်သည်။ ဤကိစ္စတွင်၊ ၎င်းသည် နောက်ပြန်လှည့်ရန် မလိုအပ်စေရန် (၎င်းသည် လေးလံသော monolith ဖြစ်သည်)။

ဒီလိုလုပ်ဆောင်နိုင်စေမယ့် စနစ်တစ်ခုကို တည်ဆောက်ဖို့လမ်းမှာ Miro ဟာ ဗိသုကာလက်ရာတွေ၊ အသုံးပြုတဲ့ကိရိယာတွေ (Atlassian Bamboo၊ Ansible စသည်ဖြင့်) နဲ့ အဖွဲ့တွေရဲ့ ဖွဲ့စည်းပုံကို လုပ်ဆောင်တဲ့ လမ်းကြောင်းကို ဖြတ်သွားခဲ့တယ် (အခု သူတို့မှာ သီးသန့် Devops အဖွဲ့ + ကွဲပြားသော ပရိုဖိုင်များကို developer များမှ သီးခြား Scrum အဖွဲ့များစွာ)။

လမ်းကြောင်းသည် ခက်ခဲပြီး ဆူးများဖြစ်လာကာ Victor သည် ထိုနေရာတွင် အဆုံးမသတ်ဘဲ စုဆောင်းထားသော နာကျင်မှုနှင့် အကောင်းမြင်မှုကို မျှဝေခဲ့သည်။

မေးခွန်းများမေးရန် စာအုပ်တစ်အုပ် ရရှိခဲ့သည်။

နောက်ခံအပိုင်း

ကျွန်တော်သည် Nikolay Sverchkov (Evil Martians) မှ Serverless အကြောင်းနှင့် Grigory Koshelev (Kontur ကုမ္ပဏီ) တို့မှ အစီရင်ခံစာ ၂ ခုကို တက်ရောက်နိုင်ခဲ့သည်။

အသေအချာမျှသာဖြစ်သည်။

Ruslan Sirkin က Serverless ဆိုတာကို ပြောခဲ့မယ်ဆိုရင်၊ Nikolay က Serverless ကို အသုံးပြုပြီး ရိုးရှင်းတဲ့ Application တွေကို ပြသခဲ့ပြီး AWS Lambda မှာရှိတဲ့ Application တွေရဲ့ ကုန်ကျစရိတ်နဲ့ မြန်နှုန်းကို ထိခိုက်စေတဲ့ အသေးစိတ်အချက်အလက်တွေကို ပြောပြခဲ့ပါတယ်။

စိတ်ဝင်စားစရာကောင်းသောအသေးစိတ်အချက်- အနည်းဆုံးအခပေးဒြပ်စင်သည် 128 Mb မမ်မိုရီနှင့် 100 ms CPU ဖြစ်ပြီး၊ ၎င်းသည် $0,000000208 ကုန်ကျသည်။ ထို့အပြင် တစ်လလျှင် ယင်းသို့တောင်းဆိုမှု ၁ သန်းသည် အခမဲ့ဖြစ်သည်။

Nikolai ၏လုပ်ဆောင်ချက်အချို့သည် 100 ms ကန့်သတ်ချက်ကို ကျော်လွန်လေ့ရှိသည် (ပင်မအပလီကေးရှင်းကို Ruby ဖြင့်ရေးသားထားသည်)၊ ထို့ကြောင့် Go တွင် ၎င်းတို့ကို ပြန်လည်ရေးသားခြင်းသည် အလွန်ကောင်းမွန်သော စုဆောင်းမှုဖြစ်စေပါသည်။

Vostok Hercules - တယ်လီမီတာကို တစ်ဖန်ပြန်ကောင်းအောင်လုပ်ပါ။

တယ်လီမီတာအကြောင်း Grigory Koshelev (Kontur ကုမ္ပဏီ) မှ Backend ကဏ္ဍ၏ နောက်ဆုံးအစီရင်ခံစာ။ Telemetry ဆိုသည်မှာ မှတ်တမ်းများ၊ တိုင်းတာမှုများ၊ အပလီကေးရှင်းခြေရာခံများကို ဆိုလိုသည်။

ဤရည်ရွယ်ချက်အတွက်၊ Contour သည် Github တွင် တင်ထားသော ကိုယ်တိုင်ရေးကိရိယာများကို အသုံးပြုသည်။ တူးလ်တင်း- ဟာကြူလီ၊ github.com/vostok/herculestelemetry ဒေတာပေးပို့ရန်အသုံးပြုသည်။

Devops ကဏ္ဍရှိ ဗလာဒီမာလီလာ၏ အစီရင်ခံစာသည် Elasticsearch တွင် မှတ်တမ်းများ သိမ်းဆည်းခြင်းနှင့် လုပ်ဆောင်ခြင်းတို့ကို ဆွေးနွေးထားသော်လည်း ထောင်ပေါင်းများစွာသော စက်များနှင့် အပလီကေးရှင်းများမှ မှတ်တမ်းများ ပေးပို့ခြင်းနှင့် Vostok Hercules ကဲ့သို့သော ကိရိယာများက ၎င်းတို့ကို ဖြေရှင်းပေးရမည့်တာဝန်ရှိသေးသည်။

ပတ်လမ်းသည် RabbitMQ မှ Apache Kafka သို့ လူအများသိထားသော လမ်းကြောင်းအတိုင်း လိုက်သွားသည်၊ သို့သော် အရာအားလုံးသည် ဤမျှရိုးရှင်းသည်မဟုတ်ပါ)) ၎င်းတို့သည် Zookeeper၊ Cassandra နှင့် Graphite တို့ကို circuit ထဲသို့ ထည့်ခဲ့ရသည်။ ဤအစီရင်ခံစာပါအချက်အလက်များကို ကျွန်ုပ်အပြည့်အဝထုတ်ဖော်မည်မဟုတ်ပါ (ကျွန်ုပ်၏ပရိုဖိုင်မဟုတ်ပါ)၊ သင်စိတ်ဝင်စားပါက၊ အစည်းအဝေးဝဘ်ဆိုဒ်ရှိ ဆလိုက်များနှင့် ဗီဒီယိုများကို စောင့်နိုင်ပါသည်။

အခြားအစည်းအဝေးများနှင့် မည်သို့နှိုင်းယှဉ်သနည်း။

မော်စကိုနှင့် စိန့်ပီတာစဘတ်ရှိ ကွန်ဖရင့်များနှင့် နှိုင်းယှဉ်၍မရပါ၊ ၎င်းကို Urals ရှိ အခြားပွဲများနှင့် Samara ရှိ 404fest တို့နှင့် နှိုင်းယှဉ်နိုင်သည်။

DAMP ကို ​​အပိုင်း ၈ ပိုင်းဖြင့် ကျင်းပသည်၊ ၎င်းသည် Ural ညီလာခံများအတွက် မှတ်တမ်းတစ်ခုဖြစ်သည်။ အလွန်ကြီးမားသော သိပ္ပံနှင့် စီမံခန့်ခွဲမှုအပိုင်း၊ ဒါကလည်း အထူးအဆန်းပါပဲ။ Yekaterinburg ရှိပရိသတ်သည်အတော်လေးဖွဲ့စည်းပုံဖြစ်သည် - မြို့သည် Yandex၊ Kontur၊ Tinkoff အတွက်ကြီးမားသောဖွံ့ဖြိုးတိုးတက်ရေးဌာနများရှိပြီး၎င်းသည်အစီရင်ခံစာများတွင်၎င်း၏အမှတ်အသားကိုထားခဲ့ပါ။

အခြားစိတ်ဝင်စားစရာကောင်းသည့်အချက်မှာ ကုမ္ပဏီများစွာသည် ညီလာခံတွင် စပီကာ ၃-၄ လုံးကို တစ်ပြိုင်နက်တည်း ရှိသည် (၎င်းမှာ Kontur၊ Evil Martians၊ Tinkoff တို့နှင့် သက်ဆိုင်သည်)။ ၎င်းတို့ထဲမှ အများစုသည် စပွန်ဆာများ ဖြစ်ကြသော်လည်း အစီရင်ခံစာများသည် အခြားသူများနှင့် တူညီသည်၊ ၎င်းတို့သည် ကြော်ငြာအစီရင်ခံစာများ မဟုတ်ပေ။

သွားဖို့လား မသွားဘူးလား။ အကယ်၍ သင်သည် Urals သို့မဟုတ် အနီးနားတွင် နေထိုင်ပါက သင့်တွင် အခွင့်အရေးရှိပြီး အကြောင်းအရာများကို စိတ်ဝင်စားသည် - ဟုတ်ပါတယ်၊ ဟုတ်ပါတယ်။ ခရီးရှည်ကြီးအကြောင်းတွေးရင်၊ အရင်နှစ်တွေက အစီရင်ခံစာတွေနဲ့ ဗီဒီယိုအစီရင်ခံစာတွေရဲ့ အကြောင်းအရာတွေကို ကြည့်မယ်။ www.youtube.com/user/videoitpeople/videos ဆုံးဖြတ်ချက်တစ်ခုချခဲ့သည်။
စည်းကမ်းအနေဖြင့် ဒေသများရှိ ညီလာခံများ၏ နောက်ထပ်အားသာချက်တစ်ခုမှာ အစီရင်ခံစာများအပြီးတွင် ဟောပြောသူနှင့် ဆက်သွယ်ရန် လွယ်ကူကြောင်း၊ ယင်းကဲ့သို့ ဆက်သွယ်မှုအတွက် လျှောက်ထားသူ အနည်းငယ်သာရှိသည်။

Dump နှင့် Ekaterinburg တို့ကို ကျေးဇူးတင်ပါသည်။ )

source: www.habr.com