សេវាកម្មកុមារកំព្រា៖ ការធ្លាក់ចុះនៃស្ថាបត្យកម្មសេវាកម្ម (មីក្រូ)

នាយកប្រតិបត្តិនៃវិបផតថល Banki.ru លោក Andrey Nikolsky បាននិយាយនៅក្នុងសន្និសីទកាលពីឆ្នាំមុន DevOpsDays ទីក្រុងម៉ូស្គូ អំពីសេវាកុមារកំព្រា៖ របៀបកំណត់អត្តសញ្ញាណកុមារកំព្រានៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធ ហេតុអ្វីបានជាសេវាកុមារកំព្រាមិនល្អ អ្វីដែលត្រូវធ្វើជាមួយពួកគេ និងអ្វីដែលត្រូវធ្វើប្រសិនបើគ្មានអ្វីជួយ។

ខាងក្រោមការកាត់គឺជាកំណែអត្ថបទនៃរបាយការណ៍។

សួស្តីមិត្តរួមការងារ! ឈ្មោះរបស់ខ្ញុំគឺ Andrey ខ្ញុំដឹកនាំប្រតិបត្តិការនៅ Banki.ru ។

យើងមានសេវាកម្មធំៗ ទាំងនេះគឺជាសេវាកម្មបែប monolithic មានសេវាកម្មក្នុងន័យបុរាណជាង ហើយមានសេវាកម្មតូចណាស់។ នៅក្នុងវាក្យសព្ទ កម្មករ-កសិករ របស់ខ្ញុំ ខ្ញុំនិយាយថា ប្រសិនបើសេវាមួយមានលក្ខណៈសាមញ្ញ ហើយតូច នោះវាគឺជាមីក្រូ ហើយប្រសិនបើវាមិនសាមញ្ញ និងតូចទេនោះ វាគ្រាន់តែជាសេវាកម្មប៉ុណ្ណោះ។

គុណសម្បត្តិនៃសេវាកម្ម

ខ្ញុំនឹងស្វែងយល់ពីអត្ថប្រយោជន៍នៃសេវាកម្មឱ្យបានឆាប់។

ទីមួយគឺការធ្វើមាត្រដ្ឋាន។ អ្នកអាចធ្វើអ្វីមួយបានយ៉ាងឆាប់រហ័សនៅលើសេវាកម្ម និងចាប់ផ្តើមផលិតកម្ម។ អ្នកបានទទួលចរាចរណ៍ អ្នកបានក្លូនសេវាកម្ម។ អ្នកមានចរាចរណ៍កាន់តែច្រើន អ្នកបានក្លូនវា ហើយរស់នៅជាមួយវា។ នេះគឺជាប្រាក់រង្វាន់ដ៏ល្អ ហើយជាគោលការណ៍ នៅពេលដែលយើងចាប់ផ្តើម វាត្រូវបានចាត់ទុកថាសំខាន់បំផុតសម្រាប់យើង ហេតុអ្វីបានជាយើងកំពុងធ្វើរឿងទាំងអស់នេះ។

ទីពីរ ការអភិវឌ្ឍន៍ដាច់ដោយឡែក នៅពេលដែលអ្នកមានក្រុមអភិវឌ្ឍន៍ជាច្រើន អ្នកអភិវឌ្ឍន៍ផ្សេងៗគ្នាជាច្រើននៅក្នុងក្រុមនីមួយៗ ហើយក្រុមនីមួយៗបង្កើតសេវាកម្មផ្ទាល់ខ្លួន។

ជាមួយនឹងក្រុមមានភាពខុសប្លែកគ្នា។ អ្នកអភិវឌ្ឍន៍គឺខុសគ្នា។ ហើយមានឧទាហរណ៍ មនុស្សផ្កាព្រិល. ខ្ញុំបានឃើញរឿងនេះជាលើកដំបូងជាមួយ Maxim Dorofeev ។ ពេលខ្លះមនុស្សព្រិលទឹកកកស្ថិតនៅក្នុងក្រុមខ្លះ ហើយមិនមែននៅលើក្រុមផ្សេងទៀតទេ។ នេះធ្វើឱ្យសេវាកម្មផ្សេងៗដែលប្រើនៅទូទាំងក្រុមហ៊ុនមិនស្មើគ្នាបន្តិច។

មើលរូបភាព៖ នេះគឺជាអ្នកអភិវឌ្ឍន៍ដ៏ល្អ គាត់មានដៃធំ គាត់អាចធ្វើបានច្រើន។ បញ្ហាចម្បងគឺកន្លែងដែលដៃទាំងនេះមកពី។

សេវាកម្មធ្វើឱ្យវាអាចប្រើភាសាសរសេរកម្មវិធីផ្សេងៗគ្នាដែលសមស្របជាងសម្រាប់កិច្ចការផ្សេងៗ។ សេវាកម្មខ្លះស្ថិតនៅក្នុង Go ខ្លះនៅ Erlang ខ្លះនៅ Ruby អ្វីមួយនៅក្នុង PHP អ្វីមួយនៅក្នុង Python ។ ជាទូទៅអ្នកអាចពង្រីកបានយ៉ាងទូលំទូលាយ។ មាន nuances នៅទីនេះផងដែរ។

ស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្មជាចម្បងអំពី devops ។ នោះគឺប្រសិនបើអ្នកមិនមានស្វ័យប្រវត្តិកម្មទេ វាមិនមានដំណើរការដាក់ពង្រាយទេ ប្រសិនបើអ្នកកំណត់រចនាសម្ព័ន្ធវាដោយដៃ ការកំណត់របស់អ្នកអាចផ្លាស់ប្តូរពីឧទាហរណ៍សេវាកម្មទៅជាឧទាហរណ៍ ហើយអ្នកត្រូវទៅទីនោះដើម្បីធ្វើអ្វីមួយ នោះអ្នកនៅក្នុងនរក។

ឧទាហរណ៍ អ្នកមានសេវាកម្ម 20 ហើយអ្នកត្រូវដាក់ពង្រាយដោយដៃ អ្នកមាន 20 consoles ហើយអ្នកចុច "enter" ក្នុងពេលដំណាលគ្នាដូចជា ninja ។ វាមិនល្អខ្លាំងណាស់។

ប្រសិនបើអ្នកមានសេវាកម្មបន្ទាប់ពីការសាកល្បង (ជាការពិតណាស់ប្រសិនបើមានការធ្វើតេស្ត) ហើយអ្នកនៅតែត្រូវបញ្ចប់វាដោយឯកសារដើម្បីឱ្យវាដំណើរការក្នុងផលិតកម្មខ្ញុំក៏មានព័ត៌មានអាក្រក់សម្រាប់អ្នកផងដែរ។

ប្រសិនបើអ្នកពឹងផ្អែកលើសេវាកម្ម Amazon ជាក់លាក់ និងធ្វើការនៅក្នុងប្រទេសរុស្ស៊ី បន្ទាប់មកកាលពី 2 ខែមុន អ្នកក៏មាន "អ្វីគ្រប់យ៉ាងដែលនៅជុំវិញគឺឆេះ ខ្ញុំមិនអីទេ អ្វីគ្រប់យ៉ាងគឺត្រជាក់" ។

យើងប្រើ Ansible ដើម្បីធ្វើឱ្យការដាក់ពង្រាយដោយស្វ័យប្រវត្តិ, អាយ៉ងសម្រាប់ការបញ្ចូលគ្នា, ឫស្សីដើម្បីធ្វើឱ្យការដាក់ពង្រាយដោយស្វ័យប្រវត្ត និង Confluence ដើម្បីពិពណ៌នាអំពីវាទាំងអស់។

ខ្ញុំនឹងមិននិយាយលម្អិតអំពីរឿងនេះទេ ព្រោះរបាយការណ៍នេះនិយាយអំពីការអនុវត្តអន្តរកម្ម មិនមែននិយាយអំពីការអនុវត្តបច្ចេកទេសទេ។

ឧទាហរណ៍ យើងមានបញ្ហាដែល Puppet នៅលើ server ដំណើរការជាមួយ Ruby 2 ប៉ុន្តែកម្មវិធីខ្លះត្រូវបានសរសេរសម្រាប់ Ruby 1.8 ហើយវាមិនដំណើរការជាមួយគ្នាទេ។ មានអ្វីមួយខុសនៅទីនោះ។ ហើយនៅពេលដែលអ្នកត្រូវដំណើរការកំណែជាច្រើនរបស់ Ruby នៅលើម៉ាស៊ីនតែមួយ ជាធម្មតាអ្នកចាប់ផ្តើមមានបញ្ហា។

ជាឧទាហរណ៍ យើងផ្តល់ឱ្យអ្នកអភិវឌ្ឍន៍នីមួយៗនូវវេទិកាមួយ ដែលវាមានប្រហែលអ្វីគ្រប់យ៉ាងដែលយើងមាន សេវាកម្មទាំងអស់ដែលអាចអភិវឌ្ឍបាន ដើម្បីឱ្យគាត់មានបរិយាកាសឯកោ គាត់អាចបំបែកវា ហើយសាងសង់វាតាមដែលគាត់ចង់បាន។

វាកើតឡើងដែលអ្នកត្រូវការកញ្ចប់ដែលចងក្រងជាពិសេសជាមួយនឹងការគាំទ្រសម្រាប់អ្វីមួយនៅទីនោះ។ វាពិតជាលំបាកណាស់។ ខ្ញុំបានស្តាប់របាយការណ៍មួយដែលរូបភាព Docker មានទម្ងន់ 45 GB ។ ជា​ការ​ពិត​ណាស់​នៅ​ក្នុង​លីនុច វា​សាមញ្ញ​ជាង អ្វី​គ្រប់​យ៉ាង​គឺ​តូច​ជាង​នៅ​ទីនោះ ប៉ុន្តែ​នៅ​តែ​មិន​មាន​ទំហំ​គ្រប់គ្រាន់​ទេ។

ជាការប្រសើរណាស់ មានភាពអាស្រ័យផ្ទុយគ្នា នៅពេលដែលបំណែកមួយនៃគម្រោងអាស្រ័យលើបណ្ណាល័យនៃកំណែមួយ បំណែកនៃគម្រោងមួយផ្សេងទៀតអាស្រ័យលើកំណែផ្សេងទៀត ហើយបណ្ណាល័យមិនត្រូវបានដំឡើងជាមួយគ្នាទាល់តែសោះ។

យើងមានគេហទំព័រ និងសេវាកម្មនៅក្នុង PHP 5.6 យើងខ្មាស់គេណាស់ ប៉ុន្តែតើយើងអាចធ្វើអ្វីបាន? នេះគឺជាគេហទំព័រតែមួយរបស់យើង។ មានគេហទំព័រ និងសេវាកម្មនៅលើ PHP 7 មានច្រើនជាងនេះ យើងមិនខ្មាសគេទេ។ ហើយអ្នកអភិវឌ្ឍន៍នីមួយៗមានមូលដ្ឋានផ្ទាល់ខ្លួនរបស់គាត់ដែលគាត់បានឃើញដោយរីករាយ។

ប្រសិនបើអ្នកសរសេរក្រុមហ៊ុនជាភាសាមួយ នោះម៉ាស៊ីននិម្មិតចំនួនបីក្នុងមួយអ្នកអភិវឌ្ឍន៍ស្តាប់ទៅធម្មតា។ ប្រសិនបើអ្នកមានភាសាសរសេរកម្មវិធីផ្សេងៗគ្នា នោះស្ថានភាពកាន់តែអាក្រក់ទៅៗ។

អ្នកមានគេហទំព័រ និងសេវាកម្មនៅលើនេះ បន្ទាប់មកគេហទំព័រផ្សេងទៀតសម្រាប់ Go គេហទំព័រមួយសម្រាប់ Ruby និង Redis មួយចំនួនទៀតនៅចំហៀង។ ជាលទ្ធផលទាំងអស់នេះប្រែទៅជាវាលដ៏ធំមួយសម្រាប់ការគាំទ្រហើយគ្រប់ពេលវេលាខ្លះអាចបំបែកបាន។

ដូច្នេះហើយ យើងបានជំនួសអត្ថប្រយោជន៍នៃភាសាសរសេរកម្មវិធីជាមួយនឹងការប្រើប្រាស់ក្របខ័ណ្ឌផ្សេងៗគ្នា ដោយសារក្របខ័ណ្ឌ PHP មានភាពខុសគ្នាខ្លាំង ពួកគេមានសមត្ថភាពខុសៗគ្នា សហគមន៍ផ្សេងគ្នា និងការគាំទ្រផ្សេងៗគ្នា។ ហើយ​អ្នក​អាច​សរសេរ​សេវា​មួយ​ដើម្បី​ឱ្យ​អ្នក​មាន​អ្វី​ដែល​ត្រៀម​ខ្លួន​រួច​ជា​ស្រេច​សម្រាប់​វា។

សេវាកម្មនីមួយៗមានក្រុមផ្ទាល់ខ្លួន

អត្ថប្រយោជន៍ចម្បងរបស់យើង ដែលបានក្លាយជាគ្រីស្តាល់ក្នុងរយៈពេលជាច្រើនឆ្នាំ គឺថាសេវាកម្មនីមួយៗមានក្រុមផ្ទាល់ខ្លួន។ នេះងាយស្រួលសម្រាប់គម្រោងធំ អ្នកអាចសន្សំពេលវេលាលើឯកសារ អ្នកគ្រប់គ្រងដឹងពីគម្រោងរបស់ពួកគេបានល្អ។

អ្នកអាចដាក់ស្នើកិច្ចការបានយ៉ាងងាយស្រួលពីជំនួយ។ ឧទាហរណ៍ សេវាធានារ៉ាប់រងបានខូច។ ហើយភ្លាមៗក្រុមដែលទាក់ទងនឹងការធានារ៉ាប់រងទៅជួសជុលវា។

មុខងារថ្មីកំពុងត្រូវបានបង្កើតយ៉ាងឆាប់រហ័ស ពីព្រោះនៅពេលដែលអ្នកមានសេវាអាតូមិកមួយ អ្នកអាចដាក់អ្វីមួយចូលទៅក្នុងវាបានយ៉ាងលឿន។

ហើយនៅពេលដែលអ្នកបំបែកសេវាកម្មរបស់អ្នក ហើយរឿងនេះកើតឡើងដោយជៀសមិនរួច អ្នកមិនបានប៉ះពាល់ដល់សេវាកម្មរបស់អ្នកដ៏ទៃទេ ហើយអ្នកអភិវឌ្ឍន៍មកពីក្រុមផ្សេងទៀតមិនមករកអ្នកដោយប្រយោល ហើយនិយាយថា៖ “Ay-ay កុំធ្វើវាអី”។

ដូចដែលតែងតែមាន nuances ។ យើង​មាន​ក្រុម​ដែល​មាន​ស្ថិរភាព អ្នក​គ្រប់​គ្រង​ត្រូវ​បាន​ដាក់​ឲ្យ​ជាប់​ក្នុង​ក្រុម។ មានឯកសារច្បាស់លាស់ អ្នកគ្រប់គ្រងតាមដានយ៉ាងដិតដល់។ ក្រុមនីមួយៗដែលមានអ្នកគ្រប់គ្រងមានសេវាកម្មជាច្រើន ហើយមានចំណុចជាក់លាក់នៃសមត្ថភាព។

ប្រសិនបើក្រុមកំពុងអណ្តែត (ជួនកាលយើងក៏ប្រើវាផងដែរ) មានវិធីសាស្រ្តដ៏ល្អមួយហៅថា "ផែនទីផ្កាយ" ។

អ្នកមានបញ្ជីសេវាកម្ម និងមនុស្ស។ សញ្ញាផ្កាយមានន័យថាបុគ្គលនោះជាអ្នកជំនាញក្នុងសេវាកម្មនេះ សៀវភៅមានន័យថាបុគ្គលនោះកំពុងសិក្សាសេវាកម្មនេះ។ ភារកិច្ចរបស់មនុស្សគឺផ្លាស់ប្តូរកូនសៀវភៅសម្រាប់សញ្ញាផ្កាយ។ ហើយប្រសិនបើគ្មានអ្វីត្រូវបានសរសេរនៅពីមុខសេវាកម្មទេនោះបញ្ហានឹងចាប់ផ្តើមដែលខ្ញុំនឹងនិយាយបន្ថែមទៀត។

តើសេវាកុមារកំព្រាលេចឡើងយ៉ាងដូចម្តេច?

បញ្ហាទីមួយ វិធីដំបូងដើម្បីទទួលបានសេវាកុមារកំព្រានៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកគឺការបណ្តេញមនុស្សចេញ។ តើមាននរណាម្នាក់ធ្លាប់ធ្វើអាជីវកម្មតាមកាលកំណត់មុនពេលធ្វើការវាយតម្លៃទេ? ពេលខ្លះវាកើតឡើងដែលថាកាលបរិច្ឆេទកំណត់គឺតឹងតែង ហើយមិនមានពេលគ្រប់គ្រាន់សម្រាប់ឯកសារ។ "យើង​ត្រូវ​ប្រគល់​សេវាកម្ម​ទៅ​ផលិតកម្ម បន្ទាប់​មក​យើង​នឹង​បន្ថែម​វា"។

ប្រសិនបើក្រុមតូច វាកើតឡើងថាមានអ្នកអភិវឌ្ឍន៍ម្នាក់ដែលសរសេរអ្វីគ្រប់យ៉ាង នៅសល់គឺនៅក្នុងស្លាប។ "ខ្ញុំសរសេរស្ថាបត្យកម្មមូលដ្ឋាន តោះបន្ថែមចំណុចប្រទាក់។" បន្ទាប់មកនៅចំណុចខ្លះអ្នកគ្រប់គ្រងឧទាហរណ៍ចាកចេញ។ ហើយក្នុងអំឡុងពេលនេះ នៅពេលដែលអ្នកគ្រប់គ្រងបានចាកចេញ ហើយអ្នកថ្មីមិនទាន់ត្រូវបានតែងតាំង អ្នកអភិវឌ្ឍន៍ខ្លួនឯងសម្រេចចិត្តថាសេវាកម្មនឹងទៅណា និងអ្វីដែលកំពុងកើតឡើងនៅទីនោះ។ ហើយដូចដែលយើងដឹង (សូមត្រលប់ទៅស្លាយមួយចំនួន) នៅក្នុងក្រុមខ្លះមានមនុស្សព្រិលទឹកកក ជួនកាលជាប្រធានក្រុមនៃផ្កាព្រិល។ បន្ទាប់​មក​គាត់​ឈប់ ហើយ​យើង​ទទួល​សេវា​កំព្រា។

ក្នុងពេលជាមួយគ្នានេះ ការងារពីការគាំទ្រ និងពីអាជីវកម្មមិនរលាយបាត់ឡើយ។ ប្រសិនបើមានកំហុសផ្នែកស្ថាបត្យកម្មកំឡុងពេលអភិវឌ្ឍសេវាកម្ម នោះពួកគេក៏ត្រូវបញ្ចប់នៅក្នុង backlog ផងដែរ។ សេវាកាន់តែយ៉ាប់យ៉ឺនបន្តិចម្តងៗ។

តើធ្វើដូចម្តេចដើម្បីកំណត់អត្តសញ្ញាណក្មេងកំព្រា?

បញ្ជីនេះពិពណ៌នាអំពីស្ថានភាពបានយ៉ាងល្អ។ តើអ្នកណាបានរៀនអ្វីអំពីហេដ្ឋារចនាសម្ព័ន្ធរបស់ពួកគេ?

អំពីការងារដែលបានចងក្រងជាឯកសារ៖ មានសេវាកម្មមួយ ហើយជាទូទៅវាដំណើរការ វាមានសៀវភៅណែនាំពីរទំព័រអំពីរបៀបធ្វើការជាមួយវា ប៉ុន្តែគ្មាននរណាម្នាក់ដឹងពីរបៀបដែលវាដំណើរការនៅខាងក្នុងនោះទេ។

ឬ ជាឧទាហរណ៍ មានប្រភេទនៃតំណភ្ជាប់ខ្លី។ ជាឧទាហរណ៍ បច្ចុប្បន្នយើងមានតំណភ្ជាប់ខ្លីចំនួនបីដែលកំពុងប្រើប្រាស់សម្រាប់គោលបំណងផ្សេងៗគ្នានៅក្នុងសេវាកម្មផ្សេងៗគ្នា។ ទាំងនេះគ្រាន់តែជាផលវិបាកប៉ុណ្ណោះ។

ឥឡូវនេះខ្ញុំនឹងក្លាយជាប្រធានក្រុមជាក់ស្តែង។ អ្វីដែលត្រូវធ្វើ? ដំបូងយើងត្រូវផ្ទេរសេវាកម្មទៅអ្នកគ្រប់គ្រងផ្សេងទៀត ក្រុមផ្សេងទៀត។ ប្រសិនបើប្រធានក្រុមរបស់អ្នកមិនទាន់លាឈប់ទេ នោះនៅក្នុងក្រុមផ្សេងទៀត នៅពេលដែលអ្នកយល់ថាសេវាកម្មគឺដូចជាក្មេងកំព្រា អ្នកត្រូវបញ្ចូលអ្នកដែលយល់យ៉ាងហោចណាស់អ្វីមួយអំពីវា។

រឿងចំបង៖ អ្នកត្រូវតែមាននីតិវិធីផ្ទេរប្រាក់ដែលសរសេរជាឈាម។ ក្នុងករណីរបស់យើង ជាធម្មតាខ្ញុំតាមដានរឿងនេះ ព្រោះខ្ញុំត្រូវការវាទាំងអស់ដើម្បីដំណើរការ។ អ្នកគ្រប់គ្រងត្រូវការបញ្ជូនវាឱ្យលឿន ហើយអ្វីដែលកើតឡើងនៅពេលក្រោយគឺមិនសំខាន់សម្រាប់ពួកគេទៀតទេ។

មធ្យោបាយបន្ទាប់ដើម្បីបង្កើតកុមារកំព្រាគឺ "យើងនឹងធ្វើវាដោយប្រភពខាងក្រៅ វានឹងកាន់តែលឿន ហើយបន្ទាប់មកយើងនឹងប្រគល់វាទៅឱ្យក្រុម"។ វាច្បាស់ណាស់ថាអ្នកគ្រប់គ្នាមានផែនការមួយចំនួននៅក្នុងក្រុមដែលជាវេនមួយ។ ជារឿយៗអតិថិជនអាជីវកម្មគិតថាអ្នកផ្គត់ផ្គង់ខាងក្រៅនឹងធ្វើដូចគ្នានឹងផ្នែកបច្ចេកទេសដែលក្រុមហ៊ុនមាន។ ទោះបីជាការលើកទឹកចិត្តរបស់ពួកគេខុសគ្នាក៏ដោយ។ មានដំណោះស្រាយបច្ចេកវិជ្ជាចម្លែកៗ និងដំណោះស្រាយក្បួនដោះស្រាយចម្លែកៗក្នុងការចេញក្រៅ។

ជាឧទាហរណ៍ យើងមានសេវាកម្មដែលមាន Sphinx នៅកន្លែងផ្សេងៗដែលមិននឹកស្មានដល់។ ខ្ញុំនឹងប្រាប់អ្នកពីអ្វីដែលខ្ញុំត្រូវធ្វើនៅពេលក្រោយ។

Outsourcers មានក្របខណ្ឌសរសេរដោយខ្លួនឯង។ នេះគ្រាន់តែជា PHP ទទេជាមួយការចម្លង-បិទភ្ជាប់ពីគម្រោងមុន ដែលអ្នកអាចស្វែងរកអ្វីៗគ្រប់យ៉ាង។ ស្គ្រីបដាក់ពង្រាយគឺជាគុណវិបត្តិដ៏ធំមួយនៅពេលដែលអ្នកត្រូវការប្រើស្គ្រីប Bash ស្មុគស្មាញមួយចំនួនដើម្បីផ្លាស់ប្តូរបន្ទាត់ជាច្រើននៅក្នុងឯកសារមួយចំនួន ហើយស្គ្រីបដាក់ពង្រាយទាំងនេះត្រូវបានហៅដោយស្គ្រីបទីបីមួយចំនួន។ ជាលទ្ធផល អ្នកផ្លាស់ប្តូរប្រព័ន្ធដាក់ឱ្យប្រើប្រាស់ ជ្រើសរើសអ្វីផ្សេងទៀត លោត ប៉ុន្តែសេវាកម្មរបស់អ្នកមិនដំណើរការទេ។ ដោយសារតែនៅទីនោះវាចាំបាច់ដើម្បីដាក់តំណភ្ជាប់ចំនួន 8 បន្ថែមទៀតរវាងថតផ្សេងៗគ្នា។ ឬវាកើតឡើងថាកំណត់ត្រាមួយពាន់ដំណើរការ ប៉ុន្តែមួយរយពាន់លែងដំណើរការទៀតហើយ។

ខ្ញុំនឹងបន្តធ្វើជាប្រធានក្រុម។ ការទទួលយកសេវាកម្មខាងក្រៅគឺជានីតិវិធីចាំបាច់។ តើមាននរណាម្នាក់ធ្លាប់មានសេវាកម្មខាងក្រៅមកដល់ហើយមិនត្រូវបានទទួលយកនៅកន្លែងណាទេ? នេះ​មិន​សូវ​ពេញ​និយម​ដូច​ជា​សេវា​ក្មេង​កំព្រា​ទេ ប៉ុន្តែ​នៅ​តែ​មាន។

សេវាត្រូវពិនិត្យ សេវាត្រូវពិនិត្យ ពាក្យសម្ងាត់ត្រូវផ្លាស់ប្តូរ។ យើងមានករណីនៅពេលដែលពួកគេផ្តល់សេវាកម្មដល់យើង មានផ្ទាំងគ្រប់គ្រង “ប្រសិនបើចូល == 'admin' && password == 'admin'...” វាត្រូវបានសរសេរត្រឹមត្រូវនៅក្នុងកូដ។ យើង​អង្គុយ​គិត ហើយ​មនុស្ស​សរសេរ​នេះ​ក្នុង​ឆ្នាំ ២០១៨?

ការធ្វើតេស្តសមត្ថភាពផ្ទុកក៏ជារឿងចាំបាច់ផងដែរ។ អ្នកត្រូវមើលអ្វីដែលនឹងកើតឡើងនៅលើកំណត់ត្រាមួយរយពាន់ សូម្បីតែមុនពេលអ្នកដាក់សេវាកម្មនេះទៅក្នុងផលិតកម្មនៅកន្លែងណាមួយក៏ដោយ។

វាមិនគួរមានការខ្មាស់អៀនក្នុងការផ្ញើសេវាកម្មសម្រាប់ការកែលម្អនោះទេ។ នៅពេលអ្នកនិយាយថា "យើងនឹងមិនទទួលយកសេវាកម្មនេះទេ យើងមានកិច្ចការចំនួន 20 ធ្វើ នោះយើងនឹងទទួលយក" នេះជារឿងធម្មតា។ សតិសម្បជញ្ញៈរបស់អ្នកមិនគួររងទុក្ខដោយសារការពិតដែលអ្នកកំពុងបង្កើតអ្នកគ្រប់គ្រង ឬថាអាជីវកម្មនេះខ្ជះខ្ជាយលុយនោះទេ។ បន្ទាប់មកអាជីវកម្មនឹងចំណាយកាន់តែច្រើន។

យើង​មាន​ករណី​មួយ​នៅ​ពេល​ដែល​យើង​សម្រេច​ចិត្ត​ចេញ​ពី​គម្រោង​សាកល្បង។

វាត្រូវបានចែកចាយទាន់ពេលវេលា ហើយនេះគឺជាលក្ខណៈវិនិច្ឆ័យគុណភាពតែមួយគត់។ នោះហើយជាមូលហេតុដែលយើងបង្កើតគម្រោងសាកល្បងមួយទៀត ដែលមិនមែនជាអ្នកបើកយន្តហោះទៀតទេ។ សេវាកម្មទាំងនេះត្រូវបានទទួលយក ហើយតាមរយៈមធ្យោបាយរដ្ឋបាល ពួកគេបាននិយាយថា នេះគឺជាលេខកូដរបស់អ្នក ទីនេះជាក្រុម នេះ​ជាអ្នកគ្រប់គ្រងរបស់អ្នក។ សេវាពិតជាបានចាប់ផ្តើមរកប្រាក់ចំណេញរួចហើយ។ ទន្ទឹមនឹងនេះ ការពិតពួកគេនៅតែជាក្មេងកំព្រា គ្មានអ្នកណាយល់ពីរបៀបដែលពួកគេធ្វើការ ហើយអ្នកគ្រប់គ្រងប្រឹងប្រែងអស់ពីសមត្ថភាពដើម្បីបដិសេធការងាររបស់ពួកគេ។

មានគំនិតដ៏អស្ចារ្យមួយទៀត - ការអភិវឌ្ឍន៍ទ័ពព្រៃ។ នៅពេលដែលនាយកដ្ឋានមួយចំនួន ជាធម្មតានាយកដ្ឋានទីផ្សារចង់សាកល្បងសម្មតិកម្ម និងបញ្ជាឱ្យសេវាកម្មទាំងមូលចេញពីប្រភពខាងក្រៅ។ ចរាចរណ៍ចាប់ផ្តើមហូរចូល ពួកគេបានបិទឯកសារ ចុះហត្ថលេខាលើឯកសារជាមួយអ្នកម៉ៅការ ចាប់ផ្តើមដំណើរការ ហើយនិយាយថា៖ «លោកពូ យើងមានសេវាកម្មនៅទីនេះ វាមានចរាចរណ៍រួចហើយ វានាំលុយមកយើង យើងទទួលយកវា»។ យើងដូចជា "Oppa ម៉េចក៏អញ្ចឹងទៅ"។

និងវិធីមួយផ្សេងទៀតដើម្បីទទួលបានសេវាកុមារកំព្រា៖ នៅពេលដែលក្រុមមួយចំនួនស្រាប់តែមានបន្ទុកលើសទម្ងន់ អ្នកគ្រប់គ្រងនិយាយថា៖ "តោះផ្ទេរសេវាកម្មរបស់ក្រុមនេះទៅក្រុមមួយទៀត វាមានបន្ទុកតិចជាង"។ ហើយបន្ទាប់មកយើងនឹងផ្ទេរវាទៅក្រុមទីបី ហើយផ្លាស់ប្តូរអ្នកគ្រប់គ្រង។ ហើយនៅទីបញ្ចប់យើងមានក្មេងកំព្រាម្តងទៀត។

តើកុមារកំព្រាមានបញ្ហាអ្វី?

អ្នកណាមិនដឹង នេះជានាវាចម្បាំង Wasa ដែលលើកនៅប្រទេសស៊ុយអែត ដែលល្បីល្បាញដោយសារវាបានលិច ៥ នាទីបន្ទាប់ពីការបាញ់បង្ហោះ។ ហើយស្តេចនៃប្រទេសស៊ុយអែត ដោយវិធីនេះ មិនបានកាត់ទោសនរណាម្នាក់សម្រាប់ការនេះទេ។ វាត្រូវបានសាងសង់ដោយវិស្វករពីរជំនាន់ដែលមិនដឹងពីរបៀបសាងសង់កប៉ាល់បែបនេះ។ ឥទ្ធិពលធម្មជាតិ។

ជាឧទាហរណ៍ កប៉ាល់អាចលិចក្នុងស្ថានភាពអាក្រក់ជាងនេះ ជាឧទាហរណ៍ នៅពេលដែលស្តេចកំពុងជិះលើវានៅកន្លែងណាមួយក្នុងព្យុះ។ ដូច្នេះហើយ គាត់បានលង់ទឹកស្លាប់ភ្លាមៗ យោងទៅតាម Agile វាជាការល្អក្នុងការបរាជ័យមុនកាលកំណត់។

ប្រសិនបើ​យើង​បរាជ័យ​មុន​ដំបូង នោះ​ជាធម្មតា​គ្មាន​បញ្ហា​អ្វី​ឡើយ​។ ឧទាហរណ៍ក្នុងអំឡុងពេលទទួលយកវាត្រូវបានផ្ញើសម្រាប់ការពិនិត្យឡើងវិញ។ ប៉ុន្តែ​ប្រសិន​បើ​យើង​បរាជ័យ​ក្នុង​ការ​ផលិត​រួច​ហើយ​នៅ​ពេល​ដែល​លុយ​ត្រូវ​គេ​វិនិយោគ​នោះ​អាច​នឹង​មាន​បញ្ហា។ ផលវិបាកដូចដែលពួកគេត្រូវបានគេហៅថានៅក្នុងអាជីវកម្ម។

ហេតុអ្វីបានជាសេវាកុមារកំព្រាមានគ្រោះថ្នាក់៖

• សេវាកម្មអាចខូចភ្លាមៗ។
• សេវាកម្មត្រូវចំណាយពេលយូរក្នុងការជួសជុល ឬមិនជួសជុលអ្វីទាំងអស់។
• បញ្ហាសុវត្ថិភាព។
• បញ្ហាជាមួយការកែលម្អ និងបច្ចុប្បន្នភាព។
• ប្រសិនបើសេវាកម្មសំខាន់មួយខូច កេរ្តិ៍ឈ្មោះរបស់ក្រុមហ៊ុនត្រូវរងទុក្ខ។

អ្វីដែលត្រូវធ្វើជាមួយសេវាកុមារកំព្រា?

ខ្ញុំនឹងធ្វើម្តងទៀតនូវអ្វីដែលត្រូវធ្វើម្តងទៀត។ ទីមួយត្រូវតែមានឯកសារ។ 7 ឆ្នាំនៅ Banki.ru បានបង្រៀនខ្ញុំថាអ្នកសាកល្បងមិនគួរយកពាក្យរបស់អ្នកអភិវឌ្ឍន៍ទេហើយប្រតិបត្តិការមិនគួរយកពាក្យរបស់មនុស្សគ្រប់គ្នាទេ។ យើងត្រូវពិនិត្យ។

ទីពីរ វាចាំបាច់ក្នុងការសរសេរដ្យាក្រាមអន្តរកម្ម ព្រោះវាកើតឡើងថាសេវាកម្មដែលមិនត្រូវបានទទួលយ៉ាងល្អមានផ្ទុកនូវភាពអាស្រ័យដែលគ្មាននរណាម្នាក់បាននិយាយ។ ឧទាហរណ៍ អ្នកអភិវឌ្ឍន៍បានដំឡើងសេវាកម្មនៅលើគន្លឹះរបស់ពួកគេទៅកាន់ Yandex.Maps ឬ Dadata មួយចំនួន។ អ្នកបានអស់ដែនកំណត់ដោយឥតគិតថ្លៃ អ្វីគ្រប់យ៉ាងត្រូវបានខូច ហើយអ្នកមិនដឹងថាមានអ្វីកើតឡើងទាល់តែសោះ។ តុងរួចទាំងអស់ត្រូវតែត្រូវបានពិពណ៌នា៖ សេវាកម្មប្រើប្រាស់ទិន្នន័យ ផ្ញើសារជាអក្សរ អ្វីផ្សេងទៀត។

ទីបី ធ្វើការជាមួយបំណុលបច្ចេកទេស។ នៅពេលអ្នកធ្វើឈើច្រត់ប្រភេទខ្លះ ឬទទួលយកសេវាកម្ម ហើយនិយាយថាអ្វីមួយត្រូវធ្វើ អ្នកត្រូវតែប្រាកដថាវារួចរាល់។ ដោយសារតែពេលនោះវាអាចនឹងប្រែថារន្ធតូចមិនតូចទេ ហើយអ្នកនឹងធ្លាក់តាមវា។

ជាមួយនឹងការងារស្ថាបត្យកម្ម យើងមានរឿងមួយអំពី Sphinx ។ សេវាកម្មមួយបានប្រើ Sphinx ដើម្បីបញ្ចូលបញ្ជី។ គ្រាន់​តែ​ជា​បញ្ជី paginated ប៉ុន្តែ​វា​ត្រូវ​បាន​ធ្វើ​លិបិក្រម​ឡើង​វិញ​ជា​រៀង​រាល់​យប់។ វាត្រូវបានផ្គុំចេញពីលិបិក្រមពីរ៖ មួយធំមួយត្រូវបានដាក់លិបិក្រមជារៀងរាល់យប់ ហើយក៏មានលិបិក្រមតូចមួយដែលត្រូវបានដោតជាប់នឹងវាផងដែរ។ ជារៀងរាល់ថ្ងៃ ជាមួយនឹងប្រូបាប៊ីលីតេ 50% នៃការទម្លាក់គ្រាប់បែក ឬអត់ សន្ទស្សន៍បានគាំងកំឡុងពេលគណនា ហើយព័ត៌មានរបស់យើងបានឈប់ធ្វើបច្ចុប្បន្នភាពនៅលើទំព័រមេ។ ដំបូងវាចំណាយពេល 5 នាទីដើម្បីឱ្យសន្ទស្សន៍ត្រូវបានធ្វើលិបិក្រមឡើងវិញ បន្ទាប់មកសន្ទស្សន៍បានកើនឡើង ហើយនៅចំណុចខ្លះវាចាប់ផ្តើមចំណាយពេល 40 នាទីដើម្បីដាក់លិបិក្រមឡើងវិញ។ នៅពេលដែលយើងកាត់វាចេញ យើងដកដង្ហើមធំ ព្រោះវាច្បាស់ណាស់ថាពេលវេលានឹងកន្លងផុតទៅបន្តិច ហើយសន្ទស្សន៍របស់យើងនឹងត្រូវបានធ្វើលិបិក្រមពេញម៉ោង។ នេះនឹងជាការបរាជ័យសម្រាប់វិបផតថលរបស់យើង មិនមានព័ត៌មានរយៈពេលប្រាំបីម៉ោងទេ នោះហើយជាវា អាជីវកម្មបានបញ្ឈប់។

ផែនការសម្រាប់ធ្វើការជាមួយសេវាកុមារកំព្រា

តាមពិតទៅ នេះគឺពិបាកធ្វើណាស់ ព្រោះ devops និយាយអំពីការទំនាក់ទំនង។ អ្នកចង់មានអាកប្បកិរិយាល្អជាមួយសហសេវិករបស់អ្នក ហើយនៅពេលអ្នកវាយមិត្តរួមការងារ និងអ្នកគ្រប់គ្រងរបស់អ្នកលើក្បាលដោយបទប្បញ្ញត្តិ ពួកគេអាចមានអារម្មណ៍ផ្ទុយគ្នាចំពោះមនុស្សដែលធ្វើបែបនេះ។

បន្ថែមពីលើចំណុចទាំងអស់នេះ មានចំណុចសំខាន់មួយទៀត៖ មនុស្សជាក់លាក់ត្រូវតែទទួលខុសត្រូវចំពោះសេវាកម្មជាក់លាក់នីមួយៗ សម្រាប់ផ្នែកជាក់លាក់នីមួយៗនៃនីតិវិធីដាក់ពង្រាយ។ នៅពេលដែលគ្មានមនុស្ស ហើយអ្នកត្រូវទាក់ទាញមនុស្សមួយចំនួនទៀតឱ្យសិក្សាបញ្ហានេះ វាក្លាយជាការលំបាក។

ប្រសិនបើអ្វីៗទាំងអស់នេះមិនអាចជួយបាន ហើយសេវាកុមារកំព្រារបស់អ្នកនៅតែជាក្មេងកំព្រា គ្មានអ្នកណាម្នាក់ចង់យកវាទេ ឯកសារមិនត្រូវបានសរសេរទេ ក្រុមដែលត្រូវបានហៅឱ្យចូលទៅក្នុងសេវានេះបដិសេធមិនធ្វើអ្វីនោះទេ មានវិធីសាមញ្ញមួយ - ធ្វើឡើងវិញ អ្វី គ្រប់ យ៉ាង ។

នោះគឺអ្នកទទួលយកតម្រូវការសម្រាប់សេវាកម្មម្តងទៀត ហើយសរសេរសេវាកម្មថ្មី ប្រសើរជាងនៅលើវេទិការប្រសើរជាងមុន ដោយគ្មានដំណោះស្រាយបច្ចេកវិទ្យាចម្លែក។ ហើយអ្នកធ្វើចំណាកស្រុកទៅវានៅក្នុងសមរភូមិ។

យើងមានស្ថានភាពមួយនៅពេលយើងយកសេវាកម្មនៅលើ Yii 1 ហើយដឹងថាយើងមិនអាចអភិវឌ្ឍវាបន្ថែមទៀតបានទេ ដោយសារយើងអស់អ្នកអភិវឌ្ឍន៍ដែលអាចសរសេរបានល្អនៅលើ Yii 1។ អ្នកអភិវឌ្ឍន៍ទាំងអស់សរសេរបានល្អនៅលើ Symfony XNUMX ។ អ្វី​ដែល​ត្រូវធ្វើ? យើងបានបែងចែកពេលវេលា បែងចែកក្រុម បែងចែកអ្នកគ្រប់គ្រង សរសេរគម្រោងឡើងវិញ និងផ្លាស់ប្តូរចរាចរណ៍ទៅវាដោយរលូន។

បន្ទាប់ពីនេះសេវាកម្មចាស់អាចត្រូវបានលុប។ នេះជានីតិវិធីដែលខ្ញុំចូលចិត្ត នៅពេលដែលអ្នកត្រូវការយក និងសម្អាតសេវាកម្មមួយចំនួនពីប្រព័ន្ធគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធ បន្ទាប់មកឆ្លងកាត់ ហើយឃើញថារថយន្តទាំងអស់នៅក្នុងផលិតកម្មត្រូវបានបិទ ដូច្នេះអ្នកអភិវឌ្ឍន៍មិនមានដានអ្វីដែលនៅសល់។ ឃ្លាំងនៅតែមាននៅក្នុង Git ។

នេះ​ជា​អ្វី​ដែល​ខ្ញុំ​ចង់​និយាយ ខ្ញុំ​ត្រៀម​ខ្លួន​ជា​ស្រេច​ក្នុង​ការ​ពិភាក្សា ប្រធានបទ​គឺ​ជា​រឿង​អស្ចារ្យ មាន​មនុស្ស​ជា​ច្រើន​បាន​ហែល​ចូល។

ស្លាយបាននិយាយថាអ្នកជាភាសាបង្រួបបង្រួម។ ឧទាហរណ៍មួយគឺការផ្លាស់ប្តូរទំហំរូបភាព។ តើ​វា​ពិត​ជា​ចាំបាច់​ក្នុង​ការ​ដាក់​កម្រិត​វា​យ៉ាង​តឹងរ៉ឹង​ជា​ភាសា​មួយ​ឬ? ដោយសារតែការផ្លាស់ប្តូរទំហំរូបភាពនៅក្នុង PHP, ជាការប្រសើរណាស់, ពិតជាអាចត្រូវបានធ្វើនៅក្នុង Golang ។

តាមការពិត វាគឺជាជម្រើស ដូចជាការអនុវត្តទាំងអស់។ ប្រហែលជាក្នុងករណីខ្លះ វាមិនគួរឱ្យចង់បាន។ ប៉ុន្តែអ្នកត្រូវយល់ថា ប្រសិនបើអ្នកមាននាយកដ្ឋានបច្ចេកទេសនៅក្នុងក្រុមហ៊ុនដែលមានមនុស្សចំនួន 50 នាក់ នោះ 45 នាក់ជាអ្នកឯកទេស PHP 3 នាក់ទៀតគឺជាអ្នកអភិវឌ្ឍន៍ដែលស្គាល់ Python, Ansible, Puppet និងអ្វីមួយដូចនោះ ហើយមានតែពួកគេម្នាក់ប៉ុណ្ណោះដែលសរសេរនៅក្នុងមួយចំនួន។ ប្រភេទនៃសេវាកម្មប្តូរទំហំរូបភាពទៅ ហើយបន្ទាប់មកនៅពេលដែលវាចាកចេញ ជំនាញនឹងទៅជាមួយវា។ ហើយក្នុងពេលជាមួយគ្នានេះ អ្នកនឹងត្រូវស្វែងរកអ្នកអភិវឌ្ឍន៍ទីផ្សារជាក់លាក់ដែលស្គាល់ភាសានេះ ជាពិសេសប្រសិនបើវាកម្រណាស់។ នោះ​គឺ​តាម​ទស្សនៈ​របស់​អង្គការ វា​ជា​បញ្ហា។ តាមទស្សនៈរបស់អ្នកអភិវឌ្ឍន៍ អ្នកនឹងមិនត្រឹមតែត្រូវការក្លូននូវសំណុំសៀវភៅលេងដែលត្រៀមរួចជាស្រេចមួយចំនួនដែលអ្នកប្រើដើម្បីដាក់ពង្រាយសេវាកម្មប៉ុណ្ណោះទេ ប៉ុន្តែអ្នកនឹងត្រូវសរសេរវាម្តងទៀត។

បច្ចុប្បន្នយើងកំពុងបង្កើតសេវាកម្មមួយនៅលើ Node.js ហើយនេះគ្រាន់តែជាវេទិកានៅក្បែរសម្រាប់អ្នកអភិវឌ្ឍន៍នីមួយៗដែលមានភាសាដាច់ដោយឡែក។ ប៉ុន្តែ​យើង​បាន​អង្គុយ​គិត​ថា​ការ​ប្រកួត​នេះ​មាន​តម្លៃ​ដល់​ទៀន។ នោះ​គឺ​ជា​សំណួរ​សម្រាប់​អ្នក​អង្គុយ​គិត។

តើអ្នកត្រួតពិនិត្យសេវាកម្មរបស់អ្នកដោយរបៀបណា? តើអ្នកប្រមូល និងត្រួតពិនិត្យកំណត់ហេតុដោយរបៀបណា?

យើងប្រមូលកំណត់ហេតុនៅក្នុង Elasticsearch ហើយដាក់វានៅក្នុង Kibana ហើយអាស្រ័យលើថាតើវាជាបរិយាកាសផលិតកម្ម ឬសាកល្បង អ្នកប្រមូលផ្សេងគ្នាត្រូវបានប្រើនៅទីនោះ។ កន្លែងណាមួយ Lumberjack កន្លែងផ្សេងទៀត អ្វីផ្សេងទៀត ខ្ញុំមិនចាំទេ។ ហើយនៅមានកន្លែងខ្លះនៅក្នុងសេវាកម្មមួយចំនួនដែលយើងដំឡើង Telegraf ហើយថតនៅកន្លែងផ្សេងដោយឡែកពីគ្នា។

តើធ្វើដូចម្តេចដើម្បីរស់នៅជាមួយ Puppet និង Ansible ក្នុងបរិយាកាសដូចគ្នា?

តាម​ពិត​ទៅ​ឥឡូវ​នេះ​យើង​មាន​បរិស្ថាន​ពីរ មួយ​គឺ​អាយ៉ង មួយទៀត​គឺ​អាន់ស៊ីប។ យើងកំពុងធ្វើការបង្កាត់ពួកវា។ Ansible គឺជាក្របខណ្ឌដ៏ល្អសម្រាប់ការដំឡើងដំបូង Puppet គឺជាក្របខណ្ឌមិនល្អសម្រាប់ការដំឡើងដំបូង ព្រោះវាទាមទារការងារដោយផ្ទាល់នៅលើវេទិកា ហើយ Puppet ធានាបាននូវការបញ្ចូលគ្នានៃការកំណត់រចនាសម្ព័ន្ធ។ នេះមានន័យថាវេទិកានេះរក្សាខ្លួនវានៅក្នុងស្ថានភាពទាន់សម័យ ហើយដើម្បីឱ្យម៉ាស៊ីន ansibilized មានភាពទាន់សម័យ អ្នកត្រូវដំណើរការសៀវភៅលេងនៅលើវាគ្រប់ពេលវេលាជាមួយនឹងប្រេកង់មួយចំនួន។ នោះហើយជាភាពខុសគ្នា។

តើអ្នករក្សាភាពឆបគ្នាដោយរបៀបណា? តើអ្នកមាន configs នៅក្នុង Ansible និង Puppet ទេ?

នេះគឺជាការឈឺចាប់ដ៏ធំរបស់យើង យើងរក្សាភាពឆបគ្នាជាមួយនឹងដៃរបស់យើង ហើយគិតពីរបៀបដើម្បីបន្តពីអ្វីៗទាំងអស់នេះទៅកន្លែងណាមួយឥឡូវនេះ។ វាប្រែថា Puppet បញ្ចេញកញ្ចប់ និងរក្សាតំណភ្ជាប់មួយចំនួននៅទីនោះ ហើយជាឧទាហរណ៍ Ansible រមៀលចេញកូដ ហើយកែសម្រួលការកំណត់កម្មវិធីចុងក្រោយបំផុតនៅទីនោះ។

បទបង្ហាញគឺអំពីកំណែផ្សេងៗនៃ Ruby ។ តើដំណោះស្រាយអ្វី?

យើង​ជួប​រឿង​នេះ​នៅ​កន្លែង​តែ​មួយ ហើយ​យើង​ត្រូវ​រក្សា​វា​នៅ​ក្នុង​ក្បាល​របស់​យើង​គ្រប់​ពេល។ យើងគ្រាន់តែបិទផ្នែកដែលដំណើរការលើ Ruby ដែលមិនឆបគ្នាជាមួយកម្មវិធី ហើយរក្សាទុកវាដាច់ដោយឡែក។

សន្និសីទឆ្នាំនេះ DevOpsDays ទីក្រុងម៉ូស្គូ នឹងប្រព្រឹត្តទៅនៅថ្ងៃទី 7 ខែធ្នូ នៅ Technopolis ។ យើងកំពុងទទួលពាក្យស្នើសុំរបាយការណ៍រហូតដល់ថ្ងៃទី 11 ខែវិច្ឆិកា។ សរសេរ យើងប្រសិនបើអ្នកចង់និយាយ។

ការចុះឈ្មោះសម្រាប់អ្នកចូលរួមត្រូវបានបើក សូមចូលរួមជាមួយយើង!

ប្រភព: www.habr.com