បញ្ហាចំនួនប្រាំនៅក្នុងដំណើរការនៃប្រតិបត្តិការ និងការគាំទ្រប្រព័ន្ធ IT កម្រិតខ្ពស់

សួស្តី ហាប! ខ្ញុំបានគាំទ្រប្រព័ន្ធ Highload IT អស់រយៈពេលដប់ឆ្នាំមកហើយ។ ខ្ញុំនឹងមិនសរសេរនៅក្នុងអត្ថបទនេះអំពីបញ្ហានៃការដំឡើង nginx ដើម្បីដំណើរការក្នុងរបៀប 1000+ RPS ឬរឿងបច្ចេកទេសផ្សេងទៀតទេ។ ខ្ញុំនឹងចែករំលែកការសង្កេតរបស់ខ្ញុំអំពីបញ្ហានៅក្នុងដំណើរការដែលកើតឡើងនៅក្នុងការគាំទ្រ និងប្រតិបត្តិការនៃប្រព័ន្ធបែបនេះ។

ការត្រួតពិនិត្យ

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

អ្វីដែលត្រូវធ្វើជាមួយស្ថានភាពនៅពេលដែលទំនិញដែលនៅសល់នៃហាងអនឡាញលែងមកដល់ប្រព័ន្ធ ERP? ឬប្រព័ន្ធ CRM ដែលគណនាការបញ្ចុះតម្លៃសម្រាប់អតិថិជនឈប់ឆ្លើយតប? គេហទំព័រនេះហាក់ដូចជាកំពុងដំណើរការ។ លក្ខខណ្ឌ Zabbix ទទួលបានការឆ្លើយតប 200 របស់ខ្លួន។ ការផ្លាស់ប្តូរកាតព្វកិច្ចមិនបានទទួលការជូនដំណឹងណាមួយពីការត្រួតពិនិត្យនោះទេ ហើយកំពុងមើលវគ្គដំបូងនៃ Game of Thrones រដូវកាលថ្មីដោយរីករាយ។

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

ដូច្នេះ បន្ថែមពីលើការត្រួតពិនិត្យប៉ារ៉ាម៉ែត្របច្ចេកទេសនៃប្រព័ន្ធប្រតិបត្តិការនៅលើម៉ាស៊ីនមេ អ្នកត្រូវកំណត់រចនាសម្ព័ន្ធម៉ែត្រពាណិជ្ជកម្ម។ រង្វាស់ដែលប៉ះពាល់ផ្ទាល់លុយ។ អន្តរកម្មផ្សេងៗគ្នាជាមួយប្រព័ន្ធខាងក្រៅ (CRM, ERP និងផ្សេងទៀត) ។ ចំនួននៃការបញ្ជាទិញសម្រាប់រយៈពេលជាក់លាក់មួយ។ ការអនុញ្ញាតរបស់អតិថិជនជោគជ័យ ឬមិនជោគជ័យ និងរង្វាស់ផ្សេងទៀត។

អន្តរកម្មជាមួយប្រព័ន្ធខាងក្រៅ

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

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

ដំណោះស្រាយដ៏ល្អបំផុតចំពោះបញ្ហានេះគឺបង្កើតកន្លែងតែមួយសម្រាប់ការទំនាក់ទំនង ឧទាហរណ៍នៅក្នុង Slack ។ ការអញ្ជើញអ្នកចូលរួមទាំងអស់នៅក្នុងដំណើរការនៃប្រតិបត្តិការប្រព័ន្ធខាងក្រៅដើម្បីចូលរួម។ ហើយក៏ជាកម្មវិធីតាមដានតែមួយផងដែរ ដើម្បីកុំឱ្យកម្មវិធីស្ទួន។ កម្មវិធីគួរតែត្រូវបានតាមដាននៅកន្លែងតែមួយ ចាប់ពីការត្រួតពិនិត្យការជូនដំណឹងរហូតដល់លទ្ធផលនៃដំណោះស្រាយបញ្ហានាពេលអនាគត។ អ្នក​នឹង​និយាយ​ថា​នេះ​គឺ​ជា​រឿង​មិន​ពិត​ហើយ​វា​បាន​កើត​ឡើង​ជា​ប្រវត្តិសាស្ត្រ​ដែល​យើង​ធ្វើ​ការ​ក្នុង​កម្មវិធី​តាមដាន​មួយ ហើយ​ពួកគេ​ធ្វើ​ការ​ក្នុង​កម្មវិធី​មួយ​ផ្សេង​ទៀត។ ប្រព័ន្ធផ្សេងៗគ្នាបានបង្ហាញខ្លួន ពួកគេមានក្រុម IT ផ្ទាល់ខ្លួនរបស់ពួកគេ។ ខ្ញុំយល់ស្រប ហើយដូច្នេះបញ្ហាចាំបាច់ត្រូវដោះស្រាយពីខាងលើនៅកម្រិត CIO ឬម្ចាស់ផលិតផល។

ប្រព័ន្ធនីមួយៗដែលអ្នកធ្វើអន្តរកម្មជាមួយគួរតែផ្តល់ការគាំទ្រជាសេវាកម្មមួយដែលមាន SLA ច្បាស់លាស់ដើម្បីដោះស្រាយបញ្ហាតាមអាទិភាព។ ហើយមិនមែននៅពេលដែលអ្នកគ្រប់គ្រងតាមលក្ខខណ្ឌ Andrey មាននាទីសម្រាប់អ្នកទេ។

បុរសកដប

តើមនុស្សគ្រប់គ្នានៅក្នុងគម្រោង (ឬផលិតផល) មានមនុស្សម្នាក់ដែលទៅវិស្សមកាលបណ្តាលឱ្យប្រកាច់ក្នុងចំណោមថ្នាក់លើរបស់ពួកគេទេ? នេះអាចជាវិស្វករ អ្នកវិភាគ ឬអ្នកអភិវឌ្ឍន៍ devops ។ យ៉ាងណាមិញ មានតែវិស្វករ devops ម្នាក់ប៉ុណ្ណោះដែលដឹងថាតើម៉ាស៊ីនមេណាខ្លះមានកុងតឺន័រដែលបានដំឡើង របៀបចាប់ផ្ដើមកុងតឺន័រឡើងវិញក្នុងករណីមានបញ្ហា ហើយជាទូទៅបញ្ហាស្មុគស្មាញមិនអាចដោះស្រាយបានដោយគ្មានគាត់ទេ។ អ្នកវិភាគគឺជាមនុស្សតែម្នាក់គត់ដែលដឹងពីរបៀបដែលយន្តការស្មុគស្មាញរបស់អ្នកដំណើរការ។ តើស្ទ្រីមទិន្នន័យទៅណា។ នៅក្រោមប៉ារ៉ាម៉ែត្រនៃសំណើចំពោះសេវាកម្មមួយណា ដែលយើងនឹងទទួលការឆ្លើយតប។
តើអ្នកណានឹងយល់បានយ៉ាងឆាប់រហ័សថាហេតុអ្វីបានជាមានកំហុសនៅក្នុងកំណត់ហេតុ ហើយជួសជុលកំហុសធ្ងន់ធ្ងរនៅក្នុងផលិតផលភ្លាមៗ? ជាការពិតណាស់អ្នកអភិវឌ្ឍន៍ដូចគ្នា។ មានខ្លះទៀត ប៉ុន្តែសម្រាប់ហេតុផលខ្លះមានតែគាត់ទេដែលយល់ពីរបៀបដែលម៉ូឌុលផ្សេងៗនៃប្រព័ន្ធដំណើរការ។

ឫសគល់នៃបញ្ហានេះគឺកង្វះឯកសារ. យ៉ាងណាមិញ ប្រសិនបើសេវាកម្មទាំងអស់នៃប្រព័ន្ធរបស់អ្នកត្រូវបានពិពណ៌នា នោះវានឹងអាចដោះស្រាយបញ្ហាដោយគ្មានអ្នកវិភាគ។ ប្រសិនបើ devops បានចំណាយពេលពីរបីថ្ងៃចេញពីកាលវិភាគដ៏មមាញឹករបស់គាត់ ហើយបានពិពណ៌នាអំពីម៉ាស៊ីនមេ សេវាកម្ម និងការណែនាំទាំងអស់សម្រាប់ការដោះស្រាយបញ្ហាធម្មតានោះ បញ្ហានៅក្នុងការអវត្តមានរបស់គាត់អាចត្រូវបានដោះស្រាយដោយគ្មានគាត់។ អ្នក​មិន​ចាំ​បាច់​បញ្ចប់​ស្រាបៀរ​របស់​អ្នក​នៅ​លើ​ឆ្នេរ​យ៉ាង​ឆាប់​រហ័ស​ពេល​វិស្សមកាល ហើយ​ស្វែង​រក Wi-Fi ដើម្បី​ដោះស្រាយ​បញ្ហា។

សមត្ថភាព និងការទទួលខុសត្រូវរបស់បុគ្គលិកគាំទ្រ

នៅលើគម្រោងធំៗ ក្រុមហ៊ុនមិនរំលងប្រាក់ខែអ្នកអភិវឌ្ឍន៍ទេ។ ពួកគេកំពុងស្វែងរកមនុស្សវ័យកណ្តាល ឬមនុស្សចាស់ដែលមានតម្លៃថ្លៃពីគម្រោងស្រដៀងគ្នា។ ជាមួយនឹងការគាំទ្រស្ថានភាពគឺខុសគ្នាបន្តិចបន្តួច។ ពួកគេកំពុងព្យាយាមកាត់បន្ថយការចំណាយទាំងនេះតាមគ្រប់មធ្យោបាយដែលអាចធ្វើទៅបាន។ ក្រុមហ៊ុនជួលកម្មករ Enikey ក្នុងតម្លៃថោកកាលពីម្សិលមិញ ហើយចូលប្រយុទ្ធយ៉ាងក្លាហាន។ យុទ្ធសាស្រ្តនេះគឺអាចធ្វើទៅបានប្រសិនបើយើងកំពុងនិយាយអំពីគេហទំព័រកាតអាជីវកម្មរបស់រោងចក្រនៅ Zelenograd ។

ប្រសិនបើយើងកំពុងនិយាយអំពីហាងអនឡាញដ៏ធំមួយ នោះរាល់ម៉ោងនៃការឈប់សម្រាកចំណាយច្រើនជាងប្រាក់ខែប្រចាំខែរបស់អ្នកគ្រប់គ្រង Enikey ។ ចូរយើងយក 1 ពាន់លានរូប្លិ៍នៃចំណូលប្រចាំឆ្នាំជាចំណុចចាប់ផ្តើម។ នេះគឺជាចំណូលអប្បបរមានៃហាងអនឡាញណាមួយពីការវាយតម្លៃ TOP 100 សម្រាប់ឆ្នាំ 2018. បែងចែកចំនួននេះដោយចំនួនម៉ោងក្នុងមួយឆ្នាំ ហើយទទួលបានច្រើនជាង 100 rubles នៃការខាតបង់សុទ្ធ។ ហើយប្រសិនបើអ្នកមិនរាប់ម៉ោងពេលយប់ទេ អ្នកអាចបង្កើនចំនួនទ្វេដងដោយសុវត្ថិភាព។

ប៉ុន្តែលុយមិនមែនជារឿងសំខាន់ទេ? (ទេ ពិតណាស់រឿងសំខាន់) វាក៏មានការបាត់បង់កេរ្តិ៍ឈ្មោះផងដែរ។ ការធ្លាក់ចុះនៃហាងអនឡាញដ៏ល្បីមួយអាចបណ្តាលឱ្យមានរលកនៃការពិនិត្យឡើងវិញនៅលើបណ្តាញសង្គម និងការបោះពុម្ពផ្សាយនៅក្នុងប្រព័ន្ធផ្សព្វផ្សាយប្រធានបទ។ ហើយការសន្ទនារបស់មិត្តភក្តិនៅក្នុងផ្ទះបាយក្នុងរចនាប័ទ្ម "កុំទិញអ្វីនៅទីនោះ គេហទំព័ររបស់ពួកគេតែងតែធ្លាក់ចុះ" មិនអាចវាស់វែងបានទាល់តែសោះ។

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

ទំនួលខុសត្រូវគឺជាជំនាញដ៏លំបាកក្នុងការអភិវឌ្ឍន៍។ ទាំងមនុស្សមានឬអត់។ ដូច្នេះហើយ ក្នុងអំឡុងពេលសម្ភាសន៍ ខ្ញុំព្យាយាមកំណត់វត្តមានរបស់វាជាមួយនឹងសំណួរផ្សេងៗ ដែលបង្ហាញដោយប្រយោលថាតើបុគ្គលម្នាក់មានទម្លាប់ទទួលខុសត្រូវដែរឬទេ។ ប្រសិនបើមនុស្សម្នាក់ឆ្លើយថាគាត់ជ្រើសរើសសាកលវិទ្យាល័យដោយសារតែឪពុកម្តាយរបស់គាត់និយាយដូច្នេះ ឬផ្លាស់ប្តូរការងារដោយសារតែប្រពន្ធរបស់គាត់និយាយថាគាត់រកប្រាក់ចំណូលមិនគ្រប់គ្រាន់ នោះជាការប្រសើរជាងកុំចូលរួមជាមួយមនុស្សបែបនេះ។

អន្តរកម្មជាមួយក្រុមអភិវឌ្ឍន៍

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

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

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

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

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

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

ប្រភព: www.habr.com