វិស្វកម្មភាពវឹកវរ៖ សិល្បៈនៃការបំផ្លិចបំផ្លាញដោយចេតនា។ ផ្នែកទី 2

ចំណាំ។ បកប្រែ៖ អត្ថបទនេះបន្តជាស៊េរីអត្ថបទដ៏អស្ចារ្យពីអ្នកផ្សាយដំណឹងល្អផ្នែកបច្ចេកវិទ្យា AWS Adrian Hornsby ដែលកំណត់ពន្យល់តាមរបៀបសាមញ្ញ និងច្បាស់លាស់អំពីសារៈសំខាន់នៃការពិសោធន៍ដើម្បីកាត់បន្ថយផលវិបាកនៃការបរាជ័យនៅក្នុងប្រព័ន្ធ IT ។

«​ប្រសិន​បើ​អ្នក​បរាជ័យ​ក្នុង​ការ​រៀបចំ​ផែនការ នោះ​អ្នក​នឹង​មាន​គម្រោង​បរាជ័យ​»។ - Benjamin Franklin

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

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

សំណួរដ៏អស្ចារ្យ! យ៉ាង​ណា​មិញ ហាក់​មិន​សូវ​ខ្វល់​ខ្វាយ​ពី​ខ្លា​ឃ្មុំ​ផេនដា​នេះ​ទេ…

កុំរញ៉េរញ៉ៃជាមួយខ្លាឃ្មុំផេនដា!

ចម្លើយ​ខ្លី៖ កំណត់​គោលដៅ​សេវា​សំខាន់​តាម​ផ្លូវ​សំណើ។

ចម្លើយវែងជាង ប៉ុន្តែច្បាស់ជាង៖ ដើម្បីយល់ពីកន្លែងដែលត្រូវចាប់ផ្តើមពិសោធជាមួយភាពវឹកវរ សូមយកចិត្តទុកដាក់លើផ្នែកបី៖

1. រកមើលនៅ ប្រវត្តិគាំង និងកំណត់អត្តសញ្ញាណគំរូ;
2. សម្រេចចិត្តលើ ភាពអាស្រ័យសំខាន់;
3. ប្រើអ្វីដែលគេហៅថា ឥទ្ធិពលលើសទំនុកចិត្ត.

វាគួរឱ្យអស់សំណើចណាស់ ប៉ុន្តែផ្នែកនេះអាចហៅបានយ៉ាងងាយ "ដំណើរឆ្ពោះទៅរកការរកឃើញដោយខ្លួនឯង និងការត្រាស់ដឹង". នៅក្នុងវាយើងនឹងចាប់ផ្តើម "លេង" ជាមួយនឹងឧបករណ៍ត្រជាក់មួយចំនួន។

1. ចម្លើយគឺនៅក្នុងអតីតកាល

ប្រសិនបើអ្នកចាំថានៅក្នុងផ្នែកទីមួយ ខ្ញុំបានណែនាំពីគោលគំនិតនៃការកែតម្រូវកំហុស (COE) ដែលជាវិធីសាស្រ្តដែលយើងវិភាគកំហុសរបស់យើង កំហុសក្នុងបច្ចេកវិទ្យា ដំណើរការ ឬអង្គការ - ដើម្បីយល់ពីមូលហេតុរបស់វា និងការពារ ការកើតឡើងវិញនាពេលអនាគត។ ជាទូទៅនេះគឺជាកន្លែងដែលអ្នកគួរតែចាប់ផ្តើម។

"ដើម្បីយល់ពីបច្ចុប្បន្ន អ្នកត្រូវដឹងពីអតីតកាល"។ - លោក Carl Sagan

សូមក្រឡេកមើលប្រវត្តិនៃការបរាជ័យ ដាក់ស្លាកពួកគេនៅក្នុង COE ឬ postmortems ហើយចាត់ថ្នាក់ពួកគេ។ កំណត់អត្តសញ្ញាណគំរូទូទៅដែលជារឿយៗនាំឱ្យមានបញ្ហា ហើយសម្រាប់ COE នីមួយៗ សូមសួរខ្លួនឯងនូវសំណួរខាងក្រោម៖

"តើនេះអាចត្រូវបានគេព្យាករណ៍ហើយដូច្នេះត្រូវបានរារាំងដោយការចាក់ខុស?"

ខ្ញុំចាំបានបរាជ័យមួយនៅដើមអាជីពរបស់ខ្ញុំ។ វាអាចត្រូវបានរារាំងយ៉ាងងាយស្រួល ប្រសិនបើយើងបានអនុវត្តការពិសោធន៍ភាពវឹកវរសាមញ្ញមួយចំនួន៖

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

ទោះយ៉ាងណាក៏ដោយ អ្វីៗបានល្អប្រសើរមួយរយៈ។

បន្ទាប់មក នៅក្រោមលក្ខខណ្ឌដ៏តានតឹងរួចហើយ ករណីមួយក្នុងចំណោមករណីបានចាប់ផ្តើមអនុវត្តភារកិច្ច ETL cron ធម្មតាដែលមិនសំខាន់។ ការរួមបញ្ចូលគ្នានៃចរាចរណ៍ខ្ពស់ និង cronjob បានជំរុញការប្រើប្រាស់ស៊ីភីយូដល់ជិត 100% ។ ការផ្ទុកលើសចំណុះរបស់ CPU បានធ្វើឱ្យការឆ្លើយតបយឺតយ៉ាវចំពោះការពិនិត្យសុខភាព យ៉ាងខ្លាំង ដូច្នេះហើយ ELB បានសម្រេចចិត្តថា វត្ថុនោះកំពុងជួបប្រទះបញ្ហាដំណើរការ។ ដូចដែលបានរំពឹងទុក អ្នកធ្វើសមតុល្យបានបញ្ឈប់ការចែកចាយចរាចរណ៍ទៅវា ដែលនាំឲ្យមានការកើនឡើងនៃបន្ទុកលើករណីដែលនៅសល់ក្នុងក្រុម។

ភ្លាមៗនោះ ករណីផ្សេងទៀតទាំងអស់ក៏ចាប់ផ្តើមបរាជ័យក្នុងការពិនិត្យសុខភាព។

ការចាប់ផ្តើមវត្ថុថ្មីតម្រូវឱ្យទាញយក និងដំឡើងកញ្ចប់ ហើយចំណាយពេលយូរជាងវាត្រូវការ ELB ដើម្បីបិទពួកវា - ម្តងមួយៗ - នៅក្នុងក្រុមធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ។ វាច្បាស់ណាស់ថាមិនយូរប៉ុន្មានដំណើរការទាំងមូលឈានដល់ចំណុចសំខាន់ ហើយកម្មវិធីបានគាំង។

បន្ទាប់មក យើង​យល់​ពី​ចំណុច​ខាងក្រោម​ជា​រៀងរហូត៖

• ការដំឡើងកម្មវិធីនៅពេលបង្កើតវត្ថុថ្មីត្រូវចំណាយពេលយូរ វាជាការប្រសើរក្នុងការផ្តល់នូវចំណូលចិត្តចំពោះវិធីសាស្រ្តដែលមិនអាចផ្លាស់ប្តូរបាន និង AMI មាស.
• ក្នុងស្ថានភាពស្មុគ្រស្មាញ ការឆ្លើយតបទៅនឹងការពិនិត្យសុខភាព និង ELBs គួរតែជាអាទិភាព - រឿងចុងក្រោយដែលអ្នកចង់បានគឺធ្វើឱ្យស្មុគស្មាញដល់ជីវិតសម្រាប់ករណីដែលនៅសល់។
• ការពិនិត្យសុខភាពក្នុងមូលដ្ឋានជួយបានច្រើន (សូម្បីតែពីរបីវិនាទី)។
• ក្នុងស្ថានភាពលំបាក កុំដំណើរការកិច្ចការ cron និងដំណើរការមិនសំខាន់ផ្សេងទៀត - រក្សាទុកធនធានសម្រាប់កិច្ចការសំខាន់បំផុត។
• នៅពេលធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ សូមប្រើករណីតូចជាង។ ក្រុមនៃគំរូតូចៗចំនួន 10 គឺប្រសើរជាងក្រុមធំ 4; ប្រសិនបើឧទាហរណ៍មួយបរាជ័យ ក្នុងករណីដំបូង 10% នៃចរាចរណ៍នឹងត្រូវបានចែកចាយលើសពី 9 ពិន្ទុនៅក្នុងទីពីរ - 25% នៃចរាចរណ៍លើសពី XNUMX ពិន្ទុ។

ហើយដូច្នេះ, នេះអាចត្រូវបានគេមើលឃើញទុកជាមុន ហើយដូច្នេះត្រូវបានរារាំងដោយការណែនាំអំពីបញ្ហានេះ?

ថានិងតាមវិធីជាច្រើន។

ទីមួយដោយការក្លែងធ្វើការប្រើប្រាស់ CPU ខ្ពស់ដោយប្រើឧបករណ៍ដូចជា stress-ng ឬ cpuburn:

❯ stress-ng --matrix 1 -t 60s

ភាពតានតឹង

ទីពីរដោយផ្ទុកលើសទម្ងន់នៃឧទាហរណ៍ជាមួយ wrk និងឧបករណ៍ប្រើប្រាស់ស្រដៀងគ្នាផ្សេងទៀត៖

❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

ការពិសោធន៍គឺសាមញ្ញណាស់ ប៉ុន្តែអាចផ្តល់នូវអាហារល្អមួយចំនួនសម្រាប់ការគិតដោយមិនចាំបាច់ឆ្លងកាត់ភាពតានតឹងនៃការបរាជ័យពិតប្រាកដ។

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

តើ​វា​ជា​សុបិន​ឬ​វា​ពិត​ជា​បាន​កើត​ឡើង?

ដូច្នេះសិក្សាពីប្រវត្តិបរាជ័យ វិភាគ សេអ៊ីដាក់ស្លាក និងចាត់ថ្នាក់ពួកវាតាម “កាំបុក”—ឬកាន់តែត្រឹមត្រូវ ចំនួនអតិថិជនដែលរងផលប៉ះពាល់—ហើយបន្ទាប់មករកមើលគំរូ។ សួរខ្លួនឯងថាតើនេះអាចត្រូវបានទាយទុកជាមុន និងរារាំងដោយការណែនាំអំពីបញ្ហានេះដែរឬទេ។ ពិនិត្យចម្លើយរបស់អ្នក។

បន្ទាប់មកប្តូរទៅលំនាំទូទៅបំផុតដែលមានកាំខូចខាតធំបំផុត។

2. បង្កើតផែនទីអាស្រ័យ

ចំណាយពេលបន្តិចដើម្បីគិតអំពីកម្មវិធីរបស់អ្នក។ តើមានផែនទីច្បាស់លាស់នៃភាពអាស្រ័យរបស់វាទេ? តើ​អ្នក​ដឹង​ទេ​ថា​តើ​ពួកគេ​នឹង​មាន​ឥទ្ធិពល​អ្វី​ខ្លះ​ប្រសិន​បើ​មាន​ការ​បរាជ័យ?

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

ការកំណត់អត្តសញ្ញាណ និងឯកសារភាពអាស្រ័យត្រូវបានគេហៅថា "ការកសាងផែនទីភាពអាស្រ័យ» (ផែនទីភាពអាស្រ័យ). ជាធម្មតា នេះត្រូវបានធ្វើសម្រាប់កម្មវិធីដែលមានមូលដ្ឋានកូដធំ ដោយប្រើឧបករណ៍កំណត់ទម្រង់កូដ។ (ទម្រង់កូដ) និងឧបករណ៍ (ឧបករណ៍). អ្នកក៏អាចបង្កើតផែនទីដោយត្រួតពិនិត្យចរាចរណ៍បណ្តាញ។

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

បើគ្មានភាពអាស្រ័យសំខាន់ សេវាកម្មមិនអាចដំណើរការបានទេ។ ភាពអាស្រ័យមិនសំខាន់ "មិន​គួរ» មានឥទ្ធិពលលើសេវាកម្មក្នុងករណីមានការដួលរលំ។ ដើម្បីយល់ពីភាពអាស្រ័យ អ្នកត្រូវមានការយល់ដឹងច្បាស់លាស់អំពី APIs ដែលប្រើដោយកម្មវិធីរបស់អ្នក។ នេះអាចជាការលំបាកជាងវាហាក់ដូចជា - យ៉ាងហោចណាស់សម្រាប់កម្មវិធីធំ។

ចាប់ផ្តើមដោយឆ្លងកាត់ APIs ទាំងអស់។ បន្លិចច្រើនបំផុត សំខាន់និងសំខាន់. យក ផ្កាយរណប ពីឃ្លាំងកូដ សូមពិនិត្យមើលវាចេញ កំណត់ហេតុនៃការតភ្ជាប់បន្ទាប់មកមើល ឯកសារ (ជាការពិតណាស់ប្រសិនបើវាមាន - បើមិនដូច្នេះទេអ្នកនៅតែមានоបញ្ហាធំជាង) ។ ប្រើឧបករណ៍ដើម្បី ប្រវត្តិរូប និងការតាមដាន, ត្រងការហៅចេញខាងក្រៅ។

អ្នកអាចប្រើកម្មវិធីដូចជា netstat - ឧបករណ៍ប្រើប្រាស់បន្ទាត់ពាក្យបញ្ជាដែលបង្ហាញបញ្ជីនៃការតភ្ជាប់បណ្តាញទាំងអស់ (រន្ធសកម្ម) នៅក្នុងប្រព័ន្ធ។ ឧទាហរណ៍ ដើម្បីរាយការភ្ជាប់បច្ចុប្បន្នទាំងអស់ សូមវាយ៖

❯ netstat -a | more 

នៅក្នុង AWS អ្នកអាចប្រើ កំណត់ហេតុលំហូរ (កំណត់ហេតុលំហូរ) VPC គឺជាវិធីសាស្ត្រដែលអនុញ្ញាតឱ្យអ្នកប្រមូលព័ត៌មានអំពីចរាចរ IP ដែលទៅ ឬពីចំណុចប្រទាក់បណ្តាញនៅក្នុង VPC ។ កំណត់ហេតុបែបនេះក៏អាចជួយដល់កិច្ចការផ្សេងទៀតផងដែរ - ឧទាហរណ៍ ការស្វែងរកចម្លើយចំពោះសំណួរថាហេតុអ្វីបានជាចរាចរណ៍មួយចំនួនមិនទៅដល់វត្ថុនោះ។

អ្នកក៏អាចប្រើផងដែរ។ AWS X-Ray. កាំរស្មីអ៊ិចអនុញ្ញាតឱ្យអ្នកទទួលបានព័ត៌មានលម្អិត "ចុងក្រោយ" (ចប់​ដល់​ចប់) ទិដ្ឋភាពទូទៅនៃសំណើនៅពេលពួកគេផ្លាស់ទីតាមរយៈកម្មវិធី ហើយថែមទាំងបង្កើតផែនទីនៃសមាសធាតុមូលដ្ឋានរបស់កម្មវិធីផងដែរ។ ងាយស្រួលណាស់ ប្រសិនបើអ្នកត្រូវការកំណត់អត្តសញ្ញាណភាពអាស្រ័យ។

AWS X-Ray Console

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

កម្មវិធីជាច្រើនប្រើ DNS ដើម្បីភ្ជាប់ទៅភាពអាស្រ័យ ខណៈពេលដែលកម្មវិធីផ្សេងទៀតអាចប្រើការរកឃើញសេវាកម្ម ឬសូម្បីតែអាសយដ្ឋាន IP ដែលពិបាកសរសេរកូដនៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធ (ឧ. /etc/hosts).

ឧទាហរណ៍អ្នកអាចបង្កើត DNS blackhole ដោយមានជំនួយ iptables ហើយមើលថាតើមានការសម្រាកអ្វីខ្លះ ដើម្បីធ្វើដូចនេះបញ្ចូលពាក្យបញ្ជាខាងក្រោម:

❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

ប្រហោងខ្មៅ DNS

ប្រសិនបើនៅក្នុង /etc/hosts ឬឯកសារកំណត់រចនាសម្ព័ន្ធផ្សេងទៀត អ្នកនឹងរកឃើញអាសយដ្ឋាន IP ដែលអ្នកមិនដឹងអ្វីទាំងអស់ (បាទ ជាអកុសលវាក៏កើតឡើងផងដែរ) អ្នកអាចមកជួយសង្គ្រោះម្តងទៀត iptables. ចូរនិយាយថាអ្នកបានរកឃើញ 8.8.8.8 ហើយមិនដឹងថានេះជាអាសយដ្ឋានម៉ាស៊ីនមេ DNS សាធារណៈរបស់ Google ទេ។ ដោយប្រើ iptables អ្នកអាចទប់ស្កាត់ចរាចរណ៍ចូល និងចេញទៅកាន់អាសយដ្ឋាននេះដោយប្រើពាក្យបញ្ជាខាងក្រោម៖

❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"

បិទការចូលប្រើប្រាស់

ច្បាប់ទីមួយទម្លាក់កញ្ចប់ទាំងអស់ពី DNS សាធារណៈរបស់ Google៖ ping ដំណើរការ ប៉ុន្តែកញ្ចប់មិនត្រូវបានប្រគល់មកវិញទេ។ ច្បាប់ទីពីរទម្លាក់កញ្ចប់ព័ត៌មានទាំងអស់ដែលមានប្រភពចេញពីប្រព័ន្ធរបស់អ្នកឆ្ពោះទៅរក DNS សាធារណៈរបស់ Google - ជាការឆ្លើយតប ping យើង​ទទួល​បាន ប្រតិបត្តិការមិនត្រូវបានអនុញ្ញាត.

ចំណាំ៖ ក្នុងករណីពិសេសនេះ វាជាការប្រសើរក្នុងការប្រើប្រាស់ whois 8.8.8.8ប៉ុន្តែនេះគ្រាន់តែជាឧទាហរណ៍ប៉ុណ្ណោះ។

យើងអាចចូលទៅកាន់តែជ្រៅទៅក្នុងរន្ធទន្សាយ ពីព្រោះអ្វីគ្រប់យ៉ាងដែលប្រើ TCP និង UDP ពិតជាអាស្រ័យលើ IP ផងដែរ។ ក្នុងករណីភាគច្រើន IP ត្រូវបានភ្ជាប់ជាមួយ ARP ។ កុំភ្លេចអំពីជញ្ជាំងភ្លើង...

ប្រសិនបើអ្នកលេបថ្នាំក្រហម អ្នកស្នាក់នៅ Wonderland ហើយខ្ញុំនឹងបង្ហាញអ្នកថាតើរន្ធទន្សាយទៅជ្រៅប៉ុណ្ណា។

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

ការកសាងផែនទីអាស្រ័យ ជារឿយៗជាកិច្ចការដ៏វែងឆ្ងាយ។ ថ្មីៗនេះខ្ញុំបាននិយាយជាមួយអតិថិជនម្នាក់ដែលបានចំណាយពេលជិត 2 ឆ្នាំដើម្បីបង្កើតឧបករណ៍ដែលបង្កើតផែនទីភាពអាស្រ័យពាក់កណ្តាលដោយស្វ័យប្រវត្តិសម្រាប់ microservices និង commands រាប់រយ។

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

3. ប្រយ័ត្ននឹងការជឿជាក់ហួសហេតុ

“អ្នកណាយល់សប្តិឃើញអ្វី ជឿលើវា” — Demosthenes

តើអ្នកធ្លាប់លឺទេ? ឥទ្ធិពលលើសទំនុកចិត្ត?

យោងតាមវិគីភីឌា ឥទ្ធិពលនៃទំនុកចិត្តហួសហេតុ គឺជា "ភាពលំអៀងនៃការយល់ដឹង ដែលទំនុកចិត្តរបស់បុគ្គលម្នាក់ចំពោះសកម្មភាព និងការសម្រេចចិត្តរបស់ពួកគេ គឺធំជាងភាពត្រឹមត្រូវនៃគោលបំណងនៃការវិនិច្ឆ័យទាំងនោះ ជាពិសេសនៅពេលដែលកម្រិតនៃទំនុកចិត្តខ្ពស់ទាក់ទងគ្នា" ។

ផ្អែកលើសភាវគតិ និងបទពិសោធន៍...

តាមបទពិសោធន៍របស់ខ្ញុំ ការបង្ខូចទ្រង់ទ្រាយនេះគឺជាតម្រុយដ៏អស្ចារ្យនៃកន្លែងដែលត្រូវចាប់ផ្តើមជាមួយនឹងវិស្វកម្មវឹកវរ។

ប្រយ័ត្នចំពោះប្រតិបត្តិករដែលមានទំនុកចិត្តហួសហេតុ៖

ឆាលី៖ «រឿងនេះមិនធ្លាក់ចុះទេក្នុងរយៈពេលប្រាំឆ្នាំ អ្វីៗគឺល្អ!»
គាំង៖ “ចាំ… ខ្ញុំនឹងនៅទីនោះឆាប់ៗ!”

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

សង្ខេប

ការស្វែងរកចំណុចចាប់ផ្តើមសម្រាប់វិស្វកម្មភាពច្របូកច្របល់តែងតែនាំមកនូវលទ្ធផលច្រើនជាងការរំពឹងទុក ហើយក្រុមដែលចាប់ផ្តើមបំបែករឿងលឿនពេកបាត់បង់ការមើលឃើញនូវខ្លឹមសារជាសកល និងគួរឱ្យចាប់អារម្មណ៍នៃ (វឹកវរ-)វិស្វកម្ម - ការប្រើប្រាស់ច្នៃប្រឌិត វិធីសាស្រ្តវិទ្យាសាស្ត្រ и ភស្តុតាងជាក់ស្តែង សម្រាប់ការរចនា ការអភិវឌ្ឍន៍ ប្រតិបត្តិការ ការថែទាំ និងការកែលម្អប្រព័ន្ធ (កម្មវិធី)។

នេះបញ្ចប់ផ្នែកទីពីរ។ សូមសរសេរការវាយតម្លៃ ចែករំលែកមតិ ឬគ្រាន់តែទះដៃរបស់អ្នក មធ្យម. នៅផ្នែកបន្ទាប់ I ពិតជា ខ្ញុំនឹងពិចារណាឧបករណ៍ និងវិធីសាស្រ្តសម្រាប់ណែនាំការបរាជ័យទៅក្នុងប្រព័ន្ធ។ ទាល់តែ!

PS ពីអ្នកបកប្រែ

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «វិស្វកម្មភាពវឹកវរ៖ សិល្បៈនៃការបំផ្លិចបំផ្លាញដោយចេតនា។ ផ្នែកទី 1»
• «វិធីដើម្បីសម្រេចបាននូវភាពអាចរកបានខ្ពស់នៅក្នុង Kubernetes»
• «ការត្រួតពិនិត្យ និង Kubernetes (ការពិនិត្យឡើងវិញ និងរបាយការណ៍វីដេអូ)»
• «កំពុងសាកល្បងជាមួយ kube-proxy និងភាពមិនមានថ្នាំងនៅក្នុង Kubernetes"។

ប្រភព: www.habr.com