ອາທິດທີ່ຜ່ານມາຂ້າພະເຈົ້າໄດ້ໄປກອງປະຊຸມ DUMP IT (https://dump-ekb.ru/) ໃນ Yekaterinburg ແລະຂ້າພະເຈົ້າຢາກບອກທ່ານກ່ຽວກັບສິ່ງທີ່ໄດ້ສົນທະນາຢູ່ໃນພາກ Backend ແລະ Devops, ແລະວ່າກອງປະຊຸມ IT ພາກພື້ນແມ່ນມີມູນຄ່າຄວາມສົນໃຈ.
Nikolay Sverchkov ຈາກ Evil Martians ກ່ຽວກັບ Serverless
ອັນໃດຢູ່ທີ່ນັ້ນ?
ໃນຈໍານວນທັງຫມົດ, ກອງປະຊຸມມີ 8 ພາກສ່ວນ: Backend, Frontend, ມືຖື, ການທົດສອບແລະ QA, Devops, ການອອກແບບ, ວິທະຍາສາດແລະການຄຸ້ມຄອງ.
ໂດຍວິທີທາງການ, ຫ້ອງໂຖງທີ່ໃຫຍ່ທີ່ສຸດແມ່ນຢູ່ທີ່ວິທະຍາສາດແລະການຄຸ້ມຄອງ)) ສໍາລັບຄົນລະ 350 ຄົນ. Backend ແລະ Frontend ບໍ່ນ້ອຍກວ່າຫຼາຍ. ຫ້ອງ Devops ເປັນຫ້ອງນ້ອຍທີ່ສຸດ, ແຕ່ມີການເຄື່ອນໄຫວ.
ຂ້າພະເຈົ້າໄດ້ຟັງບົດລາຍງານໃນພາກ Devops ແລະ Backend ແລະສົນທະນາເລັກນ້ອຍກັບລໍາໂພງ. ຂ້າພະເຈົ້າຢາກຈະສົນທະນາກ່ຽວກັບຫົວຂໍ້ທີ່ກວມເອົາແລະການທົບທວນຄືນພາກສ່ວນເຫຼົ່ານີ້ໃນກອງປະຊຸມ.
ຜູ້ຕາງຫນ້າຂອງ SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) ເວົ້າຢູ່ໃນພາກສ່ວນ Devops ແລະ Backend. ຫົວຂໍ້ທີ່ກວມເອົາ CI / CD, ເຮັດວຽກກັບການບໍລິການຄິວ, ບັນທຶກຫົວຂໍ້ Serverless ແລະການເຮັດວຽກກັບ PostgreSQL ໃນ Go ໄດ້ຖືກຄຸ້ມຄອງໄດ້ດີ.
ນອກຈາກນີ້ຍັງມີລາຍງານໂດຍ Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, ແຕ່ຂ້ອຍບໍ່ມີເວລາທີ່ຈະເຂົ້າຮ່ວມພວກເຂົາ (ບັນທຶກວິດີໂອແລະແຜ່ນສະໄລ້ຂອງບົດລາຍງານຍັງບໍ່ທັນມີ, ພວກເຂົາສັນຍາວ່າຈະລົງໃນ dump- ekb.ru ພາຍໃນ 2 ອາທິດ).
ພາກສ່ວນ Devops
ສິ່ງທີ່ແປກໃຈແມ່ນພາກສ່ວນດັ່ງກ່າວໄດ້ຈັດຂຶ້ນໃນຫ້ອງໂຖງຂະຫນາດນ້ອຍທີ່ສຸດ, ປະມານ 50 ບ່ອນນັ່ງ. ຄົນທັງຫຼາຍຢືນຢູ່ໃນທາງຍ່າງ :) ຂ້ອຍຈະບອກເຈົ້າກ່ຽວກັບບົດລາຍງານທີ່ຂ້ອຍໄດ້ຟັງ.
ຢືດຢຸ່ນມີນໍ້າໜັກເປັນ petabyte
ພາກສ່ວນໄດ້ເລີ່ມຕົ້ນດ້ວຍບົດລາຍງານໂດຍ Vladimir Lil (SKB-Kontur) ກ່ຽວກັບ Elasticsearch ໃນ Kontur. ພວກເຂົາມີ Elastic ໃຫຍ່ພໍສົມຄວນແລະໂຫຼດໄດ້ (~800 TB ຂອງຂໍ້ມູນ, ~ 1.3 petabytes ພິຈາລະນາການຊ້ໍາຊ້ອນ). Elasticsearch ສໍາລັບການບໍລິການ Kontur ທັງຫມົດແມ່ນດຽວ, ປະກອບດ້ວຍ 2 ກຸ່ມ (ຂອງ 7 ແລະ 9 ເຄື່ອງແມ່ຂ່າຍ), ແລະເປັນສິ່ງສໍາຄັນຫຼາຍທີ່ Kontur ມີວິສະວະກອນ Elasticsearch ພິເສດ (ໃນຄວາມເປັນຈິງ, Vladimir ເອງ).
Vladimir ຍັງໄດ້ແບ່ງປັນຄວາມຄິດຂອງລາວກ່ຽວກັບຜົນປະໂຫຍດຂອງ Elasticsearch ແລະບັນຫາທີ່ມັນນໍາມາ.
ຜົນປະໂຫຍດ:
- ບັນທຶກທັງຫມົດຢູ່ໃນສະຖານທີ່ດຽວ, ເຂົ້າເຖິງໄດ້ງ່າຍ
- ການເກັບຮັກສາບັນທຶກສໍາລັບປີແລະໄດ້ຢ່າງງ່າຍດາຍວິເຄາະໃຫ້ເຂົາເຈົ້າ
- ຄວາມໄວສູງຂອງການເຮັດວຽກກັບໄມ້ທ່ອນ
- ການເບິ່ງເຫັນຂໍ້ມູນເຢັນໆອອກຈາກກ່ອງ
ບັນຫາ:
- ນາຍຫນ້າຂໍ້ຄວາມແມ່ນຕ້ອງມີ (ສໍາລັບ Kontur ບົດບາດຂອງມັນແມ່ນຫຼິ້ນໂດຍ Kafka)
- ຄຸນນະສົມບັດຂອງການເຮັດວຽກກັບ Elasticsearch Curator (ແຕ່ລະໄລຍະການໂຫຼດສູງຈາກວຽກງານປົກກະຕິໃນ Curator)
- ບໍ່ມີການອະນຸຍາດໃນຕົວ (ພຽງແຕ່ສໍາລັບການແຍກຕ່າງຫາກ, ເງິນທີ່ຂ້ອນຂ້າງຫຼາຍ, ຫຼືເປັນ plugins open source ຂອງລະດັບທີ່ແຕກຕ່າງກັນຂອງຄວາມພ້ອມສໍາລັບການຜະລິດ)
ມີພຽງແຕ່ການທົບທວນຄືນໃນທາງບວກກ່ຽວກັບ Open Distro ສໍາລັບ Elasticsearch :) ບັນຫາດຽວກັນຂອງການອະນຸຍາດໄດ້ຖືກແກ້ໄຂຢູ່ທີ່ນັ້ນ.
petabyte ມາຈາກໃສ?nodes ຂອງເຂົາເຈົ້າປະກອບດ້ວຍເຄື່ອງແມ່ຂ່າຍທີ່ມີ 12*8 Tb SATA + 2*2 Tb SSD. ການເກັບຮັກສາເຢັນໃນ SATA, SSD ພຽງແຕ່ສໍາລັບ cache ຮ້ອນ (ການເກັບຮັກສາຮ້ອນ).
7+9 ເຄື່ອງແມ່ຂ່າຍ, (7 + 9) * 12 * 8 = 1536 Tb.
ບາງສ່ວນຂອງພື້ນທີ່ແມ່ນຢູ່ໃນສະຫງວນ, ຫລີກໄປທາງຫນຶ່ງສໍາລັບການຊ້ໍາຊ້ອນ, ແລະອື່ນໆ.
ບັນທຶກຈາກປະມານ 90 ແອັບພລິເຄຊັນຖືກສົ່ງໄປຫາ Elasticsearch, ລວມທັງການບໍລິການລາຍງານທັງຫມົດຂອງ Kontur, Elba, ແລະອື່ນໆ.
ຄຸນສົມບັດຂອງການພັດທະນາໃນ Serverless
ຕໍ່ໄປແມ່ນບົດລາຍງານໂດຍ Ruslan Serkin ຈາກ DataArt ກ່ຽວກັບ Serverless.
Ruslan ເວົ້າກ່ຽວກັບການພັດທະນາກັບວິທີການ Serverless ໂດຍທົ່ວໄປ, ແລະລັກສະນະຂອງມັນແມ່ນຫຍັງ.
Serverless ແມ່ນວິທີການພັດທະນາທີ່ນັກພັດທະນາບໍ່ໄດ້ແຕະຕ້ອງໂຄງສ້າງພື້ນຖານໃນທາງໃດກໍ່ຕາມ. ຕົວຢ່າງ - AWS Lambda Serverless, Kubeless.io (Serverless ພາຍໃນ Kubernetes), Google Cloud Functions.
ຄໍາຮ້ອງສະຫມັກ Serverless ທີ່ເຫມາະສົມແມ່ນພຽງແຕ່ຫນ້າທີ່ສົ່ງຄໍາຮ້ອງຂໍໃຫ້ຜູ້ໃຫ້ບໍລິການ Serverless ຜ່ານ API Gateway ພິເສດ. ການບໍລິການຈຸລະພາກທີ່ເຫມາະສົມ, ໃນຂະນະທີ່ AWS Lambda ຍັງສະຫນັບສະຫນູນພາສາການຂຽນໂປຼແກຼມທີ່ທັນສະໄຫມຈໍານວນຫລາຍ. ຄ່າໃຊ້ຈ່າຍໃນການຮັກສາແລະການນໍາໃຊ້ໂຄງສ້າງພື້ນຖານຈະກາຍເປັນສູນໃນກໍລະນີຂອງຜູ້ໃຫ້ບໍລິການຟັງ, ການສະຫນັບສະຫນູນຄໍາຮ້ອງສະຫມັກຂະຫນາດນ້ອຍຍັງຈະມີລາຄາຖືກຫຼາຍ (AWS Lambda - $ 0.2 / 1 ລ້ານຄໍາຮ້ອງຂໍງ່າຍດາຍ).
ຄວາມສາມາດໃນການຂະຫຍາຍຂອງລະບົບດັ່ງກ່າວແມ່ນເກືອບເປັນທີ່ເຫມາະສົມ - ຜູ້ໃຫ້ບໍລິການຟັງໄດ້ດູແລຕົວເອງ, Kubeless scales ອັດຕະໂນມັດພາຍໃນກຸ່ມ Kubernetes.
ມີຂໍ້ເສຍ:
- ການພັດທະນາຄໍາຮ້ອງສະຫມັກຂະຫນາດໃຫຍ່ແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍ
- ມີຄວາມຫຍຸ້ງຍາກກັບຄໍາຮ້ອງສະຫມັກ profileing (ມີພຽງແຕ່ບັນທຶກທີ່ມີສໍາລັບທ່ານ, ແຕ່ບໍ່ profileing ໃນຄວາມຫມາຍປົກກະຕິ)
- ບໍ່ມີສະບັບ
ດ້ວຍຄວາມຊື່ສັດ, ຂ້ອຍໄດ້ຍິນກ່ຽວກັບ Serverless ສອງສາມປີກ່ອນ, ແຕ່ປີທັງຫມົດນີ້ມັນບໍ່ຊັດເຈນສໍາລັບຂ້ອຍກ່ຽວກັບວິທີການໃຊ້ມັນຢ່າງຖືກຕ້ອງ. ຫຼັງຈາກບົດລາຍງານຂອງ Ruslan, ຄວາມເຂົ້າໃຈປາກົດ, ແລະຫຼັງຈາກບົດລາຍງານຂອງ Nikolai Sverchkov (Evil Martians) ຈາກພາກ Backend, ມັນໄດ້ຖືກລວມເຂົ້າກັນ. ມັນບໍ່ມີປະໂຫຍດຫຍັງທີ່ຂ້ອຍໄປປະຊຸມ :)
CI ແມ່ນສໍາລັບຜູ້ທຸກຍາກ, ຫຼືມັນຄຸ້ມຄ່າທີ່ຈະຂຽນ CI ຂອງທ່ານເອງສໍາລັບ web studio?
Mikhail Radionov, ຫົວຫນ້າຂອງ Flag web studio ຈາກ Yekaterinburg, ເວົ້າກ່ຽວກັບ CI / CD ທີ່ຂຽນດ້ວຍຕົນເອງ.
ສະຕູດິໂອຂອງລາວໄດ້ໄປຈາກ "ຄູ່ມື CI / CD" (ເຂົ້າສູ່ລະບົບເຄື່ອງແມ່ຂ່າຍຜ່ານ SSH, ເຮັດ git pull, ເຮັດຊ້ໍາ 100 ເທື່ອຕໍ່ມື້) ກັບ Jenkins ແລະເຄື່ອງມືທີ່ຂຽນດ້ວຍຕົນເອງທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດຕິດຕາມລະຫັດແລະປະຕິບັດການເປີດຕົວທີ່ເອີ້ນວ່າ Pullkins. .
ເປັນຫຍັງ Jenkins ບໍ່ເຮັດວຽກ? ມັນບໍ່ໄດ້ສະຫນອງຄວາມຍືດຫຍຸ່ນພຽງພໍໂດຍຄ່າເລີ່ມຕົ້ນແລະມີຄວາມຫຍຸ້ງຍາກເກີນໄປທີ່ຈະປັບແຕ່ງ.
"ທຸງ" ພັດທະນາໃນ Laravel (ກອບ PHP). ເມື່ອພັດທະນາເຊີບເວີ CI/CD, Mikhail ແລະເພື່ອນຮ່ວມງານຂອງລາວໄດ້ໃຊ້ກົນໄກໃນຕົວຂອງ Laravel ທີ່ເອີ້ນວ່າ Telescope and Envoy. ຜົນໄດ້ຮັບແມ່ນເຄື່ອງແມ່ຂ່າຍໃນ PHP (ກະລຸນາສັງເກດ) ທີ່ດໍາເນີນການຄໍາຮ້ອງຂໍ webhook ທີ່ເຂົ້າມາ, ສາມາດສ້າງຫນ້າແລະ backend, ນໍາໃຊ້ກັບເຄື່ອງແມ່ຂ່າຍທີ່ແຕກຕ່າງກັນ, ແລະລາຍງານໃຫ້ Slack.
ຫຼັງຈາກນັ້ນ, ເພື່ອໃຫ້ສາມາດປະຕິບັດການປັບໃຊ້ສີຟ້າ / ສີຂຽວແລະມີການຕັ້ງຄ່າທີ່ເປັນເອກະພາບໃນສະພາບແວດລ້ອມ dev-stage-prod, ພວກເຂົາປ່ຽນໄປ Docker. ຂໍ້ໄດ້ປຽບຍັງຄົງຢູ່ຄືເກົ່າ, ຄວາມເປັນໄປໄດ້ຂອງການເຮັດໃຫ້ສະພາບແວດລ້ອມທີ່ສອດຄ່ອງກັນແລະການນໍາໃຊ້ seamless ໄດ້ຖືກເພີ່ມ, ແລະຄວາມຕ້ອງການທີ່ຈະຮຽນຮູ້ Docker ເພື່ອເຮັດວຽກກັບມັນຢ່າງຖືກຕ້ອງໄດ້ຖືກເພີ່ມ.
ເຮັດແນວໃດພວກເຮົາຫຼຸດຜ່ອນຈໍານວນການ rollbacks ການປ່ອຍເຄື່ອງແມ່ຂ່າຍໂດຍ 99%
ບົດລາຍງານສຸດທ້າຍໃນພາກ Devops ແມ່ນມາຈາກ Viktor Eremchenko, ວິສະວະກອນ Lead devops ຢູ່ Miro.com (ອະດີດ RealTimeBoard).
RealTimeBoard, ຜະລິດຕະພັນເຮືອທຸງຂອງທີມງານ Miro, ແມ່ນອີງໃສ່ຄໍາຮ້ອງສະຫມັກ Java monolithic. ການເກັບກໍາ, ການທົດສອບແລະການນໍາໃຊ້ມັນໂດຍບໍ່ມີການ downtime ເປັນວຽກງານທີ່ຫຍຸ້ງຍາກ. ໃນກໍລະນີນີ້, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະນໍາໃຊ້ລະຫັດສະບັບດັ່ງກ່າວເພື່ອວ່າມັນບໍ່ຈໍາເປັນຕ້ອງຖືກມ້ວນຄືນ (ມັນເປັນ monolith ຫນັກ).
ກ່ຽວກັບວິທີການສ້າງລະບົບທີ່ຊ່ວຍໃຫ້ທ່ານເຮັດສິ່ງນີ້, Miro ໄດ້ຜ່ານເສັ້ນທາງທີ່ປະກອບມີການເຮັດວຽກກ່ຽວກັບສະຖາປັດຕະຍະກໍາ, ເຄື່ອງມືທີ່ໃຊ້ (Atlassian Bamboo, Ansible, ແລະອື່ນໆ), ແລະເຮັດວຽກກ່ຽວກັບໂຄງສ້າງຂອງທີມງານ (ປະຈຸບັນພວກເຂົາມີ. ທີມງານ Devops ທີ່ອຸທິດຕົນ + ທີມ Scrum ແຍກຕ່າງຫາກຈໍານວນຫຼາຍຈາກນັກພັດທະນາຂອງໂປໄຟທີ່ແຕກຕ່າງກັນ).
ເສັ້ນທາງໄດ້ກາຍເປັນຄວາມຫຍຸ້ງຍາກແລະເປັນ thorny, ແລະ Victor ໄດ້ແບ່ງປັນຄວາມເຈັບປວດທີ່ສະສົມແລະ optimism ທີ່ບໍ່ສິ້ນສຸດຢູ່ທີ່ນັ້ນ.
ໄດ້ຮັບປື້ມສໍາລັບຄໍາຖາມ
ພາກສ່ວນດ້ານຫຼັງ
ຂ້າພະເຈົ້າໄດ້ຈັດການເຂົ້າຮ່ວມ 2 ບົດລາຍງານ - ຈາກ Nikolay Sverchkov (Evil Martians), ຍັງກ່ຽວກັບ Serverless, ແລະຈາກ Grigory Koshelev (ບໍລິສັດ Kontur) ກ່ຽວກັບ telemetry.
Serverless ສໍາລັບພຽງແຕ່ມະຕະ
ຖ້າ Ruslan Sirkin ເວົ້າກ່ຽວກັບສິ່ງທີ່ Serverless ແມ່ນຫຍັງ, Nikolay ສະແດງໃຫ້ເຫັນຄໍາຮ້ອງສະຫມັກທີ່ງ່າຍດາຍໂດຍໃຊ້ Serverless, ແລະເວົ້າກ່ຽວກັບລາຍລະອຽດທີ່ມີຜົນກະທົບຕໍ່ຄ່າໃຊ້ຈ່າຍແລະຄວາມໄວຂອງແອັບພລິເຄຊັນໃນ AWS Lambda.
ລາຍລະອຽດທີ່ຫນ້າສົນໃຈ: ອົງປະກອບທີ່ຈ່າຍຕໍ່າສຸດແມ່ນ 128 Mb ຂອງຫນ່ວຍຄວາມຈໍາແລະ 100 ms CPU, ມັນມີລາຄາ $ 0,000000208. ຍິ່ງໄປກວ່ານັ້ນ, 1 ລ້ານຄໍາຮ້ອງຂໍດັ່ງກ່າວຕໍ່ເດືອນແມ່ນບໍ່ເສຍຄ່າ.
ບາງຫນ້າທີ່ຂອງ Nikolai ມັກຈະເກີນຂອບເຂດຈໍາກັດ 100 ms (ຄໍາຮ້ອງສະຫມັກຕົ້ນຕໍແມ່ນຂຽນໃນ Ruby), ດັ່ງນັ້ນການຂຽນຄືນໃຫມ່ໃນ Go ສະຫນອງການປະຫຍັດທີ່ດີເລີດ.
Vostok Hercules — ເຮັດໃຫ້ telemetry ທີ່ຍິ່ງໃຫຍ່ອີກເທື່ອຫນຶ່ງ!
ບົດລາຍງານຫລ້າສຸດຂອງພາກ Backend ຈາກ Grigory Koshelev (ບໍລິສັດ Kontur) ກ່ຽວກັບ telemetry. Telemetry ຫມາຍຄວາມວ່າບັນທຶກ, metrics, ການຕິດຕາມຄໍາຮ້ອງສະຫມັກ.
ສໍາລັບຈຸດປະສົງນີ້, Contour ໃຊ້ເຄື່ອງມືທີ່ຂຽນດ້ວຍຕົນເອງທີ່ຈັດພີມມາຢູ່ໃນ Github. ເຄື່ອງມືຈາກບົດລາຍງານ - Hercules, , ຖືກນໍາໃຊ້ເພື່ອສົ່ງຂໍ້ມູນ telemetry.
ບົດລາຍງານຂອງ Vladimir Lila ໃນພາກ Devops ໄດ້ປຶກສາຫາລືກ່ຽວກັບການເກັບຮັກສາແລະການປຸງແຕ່ງບັນທຶກໃນ Elasticsearch, ແຕ່ຍັງມີຫນ້າທີ່ສົ່ງບັນທຶກຈາກຫລາຍພັນອຸປະກອນແລະແອັບພລິເຄຊັນ, ແລະເຄື່ອງມືເຊັ່ນ Vostok Hercules ແກ້ໄຂພວກມັນ.
ວົງຈອນໄດ້ປະຕິບັດຕາມເສັ້ນທາງທີ່ຮູ້ຈັກກັບຫຼາຍຄົນ - ຈາກ RabbitMQ ເຖິງ Apache Kafka, ແຕ່ບໍ່ແມ່ນທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍຫຼາຍ)) ພວກເຂົາຕ້ອງເພີ່ມ Zookeeper, Cassandra ແລະ Graphite ໃນວົງຈອນ. ຂ້າພະເຈົ້າຈະບໍ່ເປີດເຜີຍຢ່າງເຕັມທີ່ກ່ຽວກັບບົດລາຍງານນີ້ (ບໍ່ແມ່ນໂປຼໄຟລ໌ຂອງຂ້ອຍ), ຖ້າທ່ານສົນໃຈ, ທ່ານສາມາດລໍຖ້າ slides ແລະວິດີໂອຢູ່ໃນເວັບໄຊທ໌ຂອງກອງປະຊຸມ.
ມັນປຽບທຽບກັບກອງປະຊຸມອື່ນໆແນວໃດ?
ຂ້ອຍບໍ່ສາມາດປຽບທຽບກັບກອງປະຊຸມໃນ Moscow ແລະ St. Petersburg, ຂ້ອຍສາມາດປຽບທຽບກັບເຫດການອື່ນໆໃນ Urals ແລະກັບ 404fest ໃນ Samara.
DAMP ແມ່ນຈັດຂຶ້ນໃນ 8 ພາກ, ນີ້ແມ່ນບັນທຶກສໍາລັບກອງປະຊຸມ Ural. ພາກສ່ວນວິທະຍາສາດແລະການຄຸ້ມຄອງຂະຫນາດໃຫຍ່ຫຼາຍ, ນີ້ແມ່ນຜິດປົກກະຕິ. ຜູ້ຊົມໃນ Yekaterinburg ແມ່ນຂ້ອນຂ້າງມີໂຄງສ້າງ - ເມືອງມີພະແນກການພັດທະນາຂະຫນາດໃຫຍ່ສໍາລັບ Yandex, Kontur, Tinkoff, ແລະນີ້ເຮັດໃຫ້ເຄື່ອງຫມາຍຂອງຕົນຢູ່ໃນບົດລາຍງານ.
ຈຸດທີ່ຫນ້າສົນໃຈອີກອັນຫນຶ່ງແມ່ນວ່າບໍລິສັດຈໍານວນຫຼາຍມີ 3-4 ລໍາໂພງຢູ່ໃນກອງປະຊຸມຄັ້ງດຽວ (ນີ້ແມ່ນກໍລະນີຂອງ Kontur, Evil Martians, Tinkoff). ຈໍານວນຫຼາຍຂອງພວກເຂົາເປັນຜູ້ສະຫນັບສະຫນູນ, ແຕ່ບົດລາຍງານແມ່ນຂ້ອນຂ້າງທຽບກັບຄົນອື່ນ, ເຫຼົ່ານີ້ບໍ່ແມ່ນບົດລາຍງານການໂຄສະນາ.
ໄປ ຫຼື ບໍ່ ໄປ? ຖ້າທ່ານອາໄສຢູ່ໃນ Urals ຫຼືໃກ້ຄຽງ, ທ່ານມີໂອກາດແລະມີຄວາມສົນໃຈໃນຫົວຂໍ້ - ແມ່ນ, ແນ່ນອນ. ຖ້າເຈົ້າຄິດກ່ຽວກັບການເດີນທາງໄກ, ຂ້ອຍຈະເບິ່ງຫົວຂໍ້ຂອງບົດລາຍງານແລະບົດລາຍງານວິດີໂອຈາກປີທີ່ຜ່ານມາ ແລະໄດ້ຕັດສິນໃຈ.
ປະໂຫຍດອີກອັນຫນຶ່ງຂອງກອງປະຊຸມໃນພາກພື້ນ, ຕາມກົດລະບຽບ, ແມ່ນວ່າມັນງ່າຍຕໍ່ການຕິດຕໍ່ກັບຜູ້ເວົ້າຫຼັງຈາກບົດລາຍງານ;
ຂໍຂອບໃຈກັບ Dump ແລະ Ekaterinburg! )
ແຫຼ່ງຂໍ້ມູນ: www.habr.com
