HighLoad ++, Evgeniy Kuzovlev (EcommPay IT)៖ អ្វីដែលត្រូវធ្វើនៅពេលដែលការឈប់សម្រាកមួយនាទីមានតម្លៃ $100000

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

សន្និសីទ HighLoad++ លើកក្រោយនឹងធ្វើឡើងនៅថ្ងៃទី 6 និង 7 ខែមេសា ឆ្នាំ 2020 នៅ St. ព័ត៌មានលម្អិត និងសំបុត្រសម្រាប់ តំណភ្ជាប់. ថ្ងៃទី 9 ខែវិច្ឆិកាម៉ោង 18:00 ។ HighLoad++ Moscow 2018, Delhi + Kolkata Hall។ ទាំងនេះ និង បទបង្ហាញ.

Evgeniy Kuzovlev (តទៅនេះ - EC)៖ - មិត្តភក្តិជំរាបសួរ! ឈ្មោះរបស់ខ្ញុំគឺ Kuzovlev Evgeniy ។ ខ្ញុំមកពីក្រុមហ៊ុន EcommPay ផ្នែកជាក់លាក់មួយគឺ EcommPay IT ផ្នែក IT នៃក្រុមក្រុមហ៊ុន។ ហើយថ្ងៃនេះយើងនឹងនិយាយអំពីការឈប់សម្រាក - អំពីរបៀបជៀសវាងពួកគេ អំពីរបៀបកាត់បន្ថយផលវិបាករបស់ពួកគេប្រសិនបើវាមិនអាចជៀសវាងបាន។ ប្រធានបទត្រូវបានរៀបរាប់ដូចខាងក្រោម: "តើត្រូវធ្វើអ្វីនៅពេលដែលការឈប់សម្រាកមួយនាទីមានតម្លៃ $ 100"? សម្លឹងមើលទៅមុខ លេខរបស់យើងគឺអាចប្រៀបធៀបបាន។

តើ EcommPay IT ធ្វើអ្វី?

តើយើងជានរណា? ហេតុអ្វីបានជាខ្ញុំឈរនៅទីនេះនៅមុខអ្នក? ហេតុអ្វីបានជាខ្ញុំមានសិទ្ធិប្រាប់អ្នកអ្វីមួយនៅទីនេះ? ហើយតើយើងនឹងនិយាយអំពីអ្វីបន្ថែមទៀតនៅទីនេះ?

ក្រុមក្រុមហ៊ុន EcommPay គឺជាអ្នកទិញអន្តរជាតិ។ យើងដំណើរការការទូទាត់នៅទូទាំងពិភពលោក - នៅប្រទេសរុស្ស៊ី អឺរ៉ុប អាស៊ីអាគ្នេយ៍ (ជុំវិញពិភពលោក)។ យើងមានការិយាល័យចំនួន 9 បុគ្គលិកសរុបចំនួន 500 នាក់ ហើយប្រហែលតិចជាងពាក់កណ្តាលនៃពួកគេគឺជាអ្នកជំនាញផ្នែកព័ត៌មានវិទ្យា។ អ្វី​ដែល​យើង​ធ្វើ អ្វី​គ្រប់​យ៉ាង​ដែល​យើង​រក​ប្រាក់​បាន​មក​ពី​យើង​បាន​ធ្វើ​ដោយ​ខ្លួន​ឯង​។

យើងបានសរសេរផលិតផលរបស់យើងទាំងអស់ (ហើយយើងមានវាច្រើនណាស់ - នៅក្នុងជួររបស់យើងនៃផលិតផល IT ដ៏ធំ យើងមានសមាសធាតុប្រហែល 16 ផ្សេងគ្នា) ខ្លួនយើង។ យើងសរសេរខ្លួនឯង យើងអភិវឌ្ឍខ្លួនឯង។ ហើយនៅពេលនេះ យើងធ្វើប្រតិបត្តិការប្រហែលមួយលានក្នុងមួយថ្ងៃ (រាប់លានប្រហែលជាវិធីត្រឹមត្រូវក្នុងការនិយាយវា)។ យើង​ជា​ក្រុម​ហ៊ុន​ក្មេង​គួរ​សម - យើង​មាន​អាយុ​ប្រហែល​ប្រាំមួយ​ឆ្នាំ​ប៉ុណ្ណោះ។

កាលពី 6 ឆ្នាំមុន វាគឺជាការចាប់ផ្តើមបែបនេះ នៅពេលដែលបុរសៗមកជាមួយអាជីវកម្ម។ ពួកគេត្រូវបានបង្រួបបង្រួមដោយគំនិតមួយ (គ្មានអ្វីក្រៅពីគំនិត) ហើយយើងបានរត់។ ដូចជាការចាប់ផ្ដើមអាជីវកម្មណាមួយដែរ យើងបានដំណើរការលឿនជាងមុន... សម្រាប់យើង ល្បឿនគឺសំខាន់ជាងគុណភាព។

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

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

ពេលទំនេរ។ បទបញ្ញត្តិនៃប្រតិបត្តិការ។

តែងតែជាមូលដ្ឋានគ្រឹះដ៏សំខាន់ អ្វីដែលយើងនឹងនិយាយអំពីថ្ងៃនេះ គឺពេលវេលារងចាំ។ ពាក្យដ៏អាក្រក់មួយ។ ប្រសិនបើយើងមានពេលទំនេរ អ្វីៗគឺអាក្រក់សម្រាប់យើង។ យើងកំពុងរត់ដើម្បីលើកវា អ្នកគ្រប់គ្រងកំពុងកាន់ម៉ាស៊ីនមេ - ព្រះហាមឃាត់វាមិនធ្លាក់ចុះដូចដែលពួកគេនិយាយនៅក្នុងបទចម្រៀងនោះ។ នេះជាអ្វីដែលយើងនឹងនិយាយអំពីថ្ងៃនេះ។

នៅពេល​យើង​ចាប់​ផ្តើម​ផ្លាស់ប្តូរ​វិធីសាស្រ្ត​របស់​យើង យើង​បាន​បង្កើត​បទបញ្ញត្តិ​ចំនួន 4 ។ ខ្ញុំបានបង្ហាញពួកគេនៅលើស្លាយ៖

បទបញ្ញត្តិទាំងនេះគឺសាមញ្ញណាស់៖

• កំណត់បញ្ហាឱ្យបានរហ័ស។
• កម្ចាត់វាឱ្យលឿនជាងមុន។
• ជួយយល់ពីហេតុផល (នៅពេលក្រោយសម្រាប់អ្នកអភិវឌ្ឍន៍)។
• និងវិធីសាស្រ្តស្តង់ដារ។

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

ការដោះស្រាយបញ្ហា៖ តើពួកគេកើតឡើងនៅពេលណា និងអ្វីដែលត្រូវធ្វើចំពោះពួកគេ?

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

ដើម្បីបង្កើតតម្រូវការទាំងនេះ យើងបានសម្រេចចិត្តសួរខ្លួនឯងនូវសំណួរថា "តើយើងមានបញ្ហានៅពេលណា"? ហើយបញ្ហាដូចដែលវាបានប្រែក្លាយកើតឡើងក្នុងបួនករណី៖

• ការបរាជ័យផ្នែករឹង។
• សេវាកម្មខាងក្រៅបានបរាជ័យ។
• ការផ្លាស់ប្តូរកំណែកម្មវិធី (ការដាក់ពង្រាយដូចគ្នា) ។
• ការកើនឡើងនៃបន្ទុកផ្ទុះ។

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

ទីពីរគឺការបរាជ័យនៃសេវាកម្មខាងក្រៅ។ សម្រាប់ភាគច្រើន ប្រព័ន្ធមិនមែនជាបញ្ហាទាល់តែសោះ ប៉ុន្តែមិនមែនសម្រាប់យើងទេ។ ចាប់តាំងពីយើងដំណើរការការទូទាត់ យើងជាអ្នកប្រមូលផ្តុំដែលឈររវាងអ្នកប្រើប្រាស់ (ដែលបញ្ចូលទិន្នន័យកាតរបស់គាត់) និងធនាគារ ប្រព័ន្ធទូទាត់ (Visa, MasterCard, Mira ។ល។)។ សេវាកម្មខាងក្រៅរបស់យើង (ប្រព័ន្ធទូទាត់ ធនាគារ) មាននិន្នាការបរាជ័យ។ ទាំងយើង និងអ្នក (ប្រសិនបើអ្នកមានសេវាកម្មបែបនេះ) មិនអាចមានឥទ្ធិពលលើបញ្ហានេះទេ។

តើត្រូវធ្វើអ្វីនៅពេលនោះ? មានជម្រើសពីរនៅទីនេះ។ ជាដំបូង ប្រសិនបើអ្នកអាចធ្វើបាន អ្នកគួរតែចម្លងសេវានេះតាមរបៀបណាមួយ។ ឧទាហរណ៍ ប្រសិនបើយើងអាចធ្វើបាន យើងផ្ទេរចរាចរណ៍ពីសេវាកម្មមួយទៅសេវាកម្មមួយទៀត៖ ឧទាហរណ៍ កាតត្រូវបានដំណើរការតាមរយៈ Sberbank Sberbank កំពុងមានបញ្ហា - យើងផ្ទេរចរាចរណ៍ [តាមលក្ខខណ្ឌ] ទៅ Raiffeisen ។ រឿងទីពីរដែលយើងអាចធ្វើបានគឺការកត់សម្គាល់ការបរាជ័យនៃសេវាកម្មខាងក្រៅយ៉ាងឆាប់រហ័ស ហើយដូច្នេះយើងនឹងនិយាយអំពីល្បឿនឆ្លើយតបនៅក្នុងផ្នែកបន្ទាប់នៃរបាយការណ៍។

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

ក្នុងចំណោមបញ្ហាទាំងបួននេះ មួយចំនួនត្រូវបានដោះស្រាយភ្លាមៗ ប្រសិនបើអ្នកមានពពក។ ប្រសិនបើអ្នកនៅក្នុង Microsoft Azhur, Ozone clouds ឬប្រើ clouds របស់យើងពី Yandex ឬ Mail នោះយ៉ាងហោចណាស់បញ្ហា hardware ក្លាយជាបញ្ហារបស់ពួកគេ ហើយអ្វីៗនឹងល្អសម្រាប់អ្នកភ្លាមៗនៅក្នុងបរិបទនៃបញ្ហា hardware។

យើង​ជា​ក្រុមហ៊ុន​មិន​ធម្មតា​បន្តិច។ នៅទីនេះមនុស្សគ្រប់គ្នាកំពុងនិយាយអំពី "Kubernet" អំពីពពក - យើងមិនមាន "Kubernet" ឬពពកទេ។ ប៉ុន្តែយើងមាន racks នៃ hardware នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យជាច្រើន ហើយយើងត្រូវបានគេបង្ខំឱ្យរស់នៅលើ hardware នេះ យើងបង្ខំឱ្យទទួលខុសត្រូវចំពោះវាទាំងអស់។ ដូច្នេះយើងនឹងនិយាយនៅក្នុងបរិបទនេះ។ ដូច្នេះអំពីបញ្ហា។ ពីរដំបូងត្រូវបានយកចេញពីតង្កៀប។

ការផ្លាស់ប្តូរកំណែកម្មវិធី។ មូលដ្ឋាន

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

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

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

តម្រូវការសម្រាប់ការផ្លាស់ប្តូរកំណែកម្មវិធី

មានតម្រូវការបី៖

• យើង​ត្រូវ​តែ​ត្រឡប់​ការ​ដាក់​ពង្រាយ​វិញ​យ៉ាង​ឆាប់​រហ័ស។
• យើងត្រូវតែកាត់បន្ថយផលប៉ះពាល់នៃការដាក់ពង្រាយដែលមិនជោគជ័យ។
• ហើយ​យើង​ត្រូវ​តែ​អាច​ដាក់​ពង្រាយ​ស្រប​គ្នា​បាន​យ៉ាង​ឆាប់​រហ័ស។
  តាមលំដាប់នោះ! ហេតុអ្វី? ព្រោះជាដំបូង ពេលដាក់ពង្រាយកំណែថ្មី ល្បឿនមិនសំខាន់ទេ ប៉ុន្តែវាសំខាន់សម្រាប់អ្នក បើមានអ្វីមួយខុសប្រក្រតី ត្រូវរំកិលថយក្រោយយ៉ាងឆាប់រហ័ស និងមានផលប៉ះពាល់តិចតួចបំផុត។ ប៉ុន្តែប្រសិនបើអ្នកមានសំណុំនៃកំណែនៅក្នុងផលិតកម្មដែលវាបង្ហាញថាមានកំហុស (ចេញពីពណ៌ខៀវមិនមានការដាក់ពង្រាយទេប៉ុន្តែមានកំហុស) - ល្បឿននៃការដាក់ពង្រាយជាបន្តបន្ទាប់គឺសំខាន់សម្រាប់អ្នក។ តើយើងបានធ្វើអ្វីដើម្បីបំពេញតម្រូវការទាំងនេះ? យើងបានប្រើវិធីសាស្រ្តដូចខាងក្រោមៈ

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

  នៅទីនេះដំណោះស្រាយចំពោះសំណួរទីពីរគឺការបង្រួមអប្បបរមា៖ អ្នកអាចផ្ញើតែផ្នែកនៃចរាចរណ៍របស់អ្នកទៅកាន់បន្ទាត់ថ្មី ទៅកាន់បន្ទាត់ដែលមានលេខកូដថ្មី (អនុញ្ញាតឱ្យវាជាឧទាហរណ៍ 2%) ។ ហើយ 2% នេះមិនមែន 100% ទេ! ប្រសិនបើអ្នកបាត់បង់ 100% នៃចរាចរណ៍របស់អ្នកដោយសារតែការដាក់ពង្រាយមិនជោគជ័យ នោះជាការគួរឱ្យភ័យខ្លាច ប្រសិនបើអ្នកបាត់បង់ 2% នៃចរាចរណ៍របស់អ្នក នោះជារឿងមិនល្អ ប៉ុន្តែវាមិនគួរឱ្យខ្លាចនោះទេ។ ជាងនេះទៅទៀត អ្នកប្រើប្រាស់ទំនងជាមិនកត់សំគាល់រឿងនេះទេ ព្រោះក្នុងករណីខ្លះ (មិនមែនទាំងអស់) អ្នកប្រើប្រាស់ដូចគ្នាដោយចុច F5 នឹងត្រូវយកទៅប្រើកំណែមួយផ្សេងទៀត។

  ខៀវ/បៃតង ដាក់ពង្រាយ។ ការនាំផ្លូវ

  ទោះយ៉ាងណាក៏ដោយ មិនមែនអ្វីៗទាំងអស់គឺសាមញ្ញទេ "ការដាក់ពង្រាយពណ៌ខៀវ/បៃតង"... សមាសធាតុទាំងអស់របស់យើងអាចបែងចែកជាបីក្រុម៖

  • នេះគឺជាផ្នែកខាងមុខ (ទំព័រទូទាត់ដែលអតិថិជនរបស់យើងឃើញ);
  • ស្នូលដំណើរការ;
  • អាដាប់ទ័រសម្រាប់ធ្វើការជាមួយប្រព័ន្ធទូទាត់ (ធនាគារ ម៉ាស្ទ័រកាត វីសា...)។

  ហើយមានភាពខុសប្លែកគ្នានៅទីនេះ - nuance ស្ថិតនៅក្នុងការនាំផ្លូវរវាងបន្ទាត់។ ប្រសិនបើអ្នកគ្រាន់តែប្តូរ 100% នៃចរាចរណ៍ នោះអ្នកមិនមានបញ្ហាទាំងនេះទេ។ ប៉ុន្តែប្រសិនបើអ្នកចង់ប្តូរ 2% អ្នកចាប់ផ្តើមសួរសំណួរ: "តើធ្វើដូចម្តេចដើម្បីធ្វើវា?" អ្វីដែលសាមញ្ញបំផុតគឺត្រង់ទៅមុខ៖ អ្នកអាចដំឡើង Round Robin ក្នុង nginx ដោយជម្រើសចៃដន្យ ហើយអ្នកមាន 2% ទៅខាងឆ្វេង 98% ទៅខាងស្តាំ។ ប៉ុន្តែនេះមិនតែងតែសមរម្យទេ។

  ឧទាហរណ៍ ក្នុងករណីរបស់យើង អ្នកប្រើប្រាស់ធ្វើអន្តរកម្មជាមួយប្រព័ន្ធដោយមានសំណើច្រើនជាងមួយ។ នេះគឺជារឿងធម្មតា៖ សំណើ 2, 3, 4, 5 - ប្រព័ន្ធរបស់អ្នកប្រហែលជាដូចគ្នា។ ហើយប្រសិនបើវាមានសារៈសំខាន់សម្រាប់អ្នកដែលសំណើរបស់អ្នកប្រើទាំងអស់មកបន្ទាត់ដូចគ្នាដែលសំណើដំបូងបានមក ឬ (ចំណុចទីពីរ) សំណើរបស់អ្នកប្រើទាំងអស់មកបន្ទាត់ថ្មីបន្ទាប់ពីការប្តូរ (គាត់អាចចាប់ផ្តើមដំណើរការមុននេះជាមួយ ប្រព័ន្ធមុនពេលប្តូរ) - បន្ទាប់មកការចែកចាយចៃដន្យនេះមិនសមនឹងអ្នកទេ។ បន្ទាប់មកមានជម្រើសដូចខាងក្រោមៈ

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

  ប្រសិនបើហេតុផលមួយចំនួនវាមិនសមនឹងអ្នក ហើយអ្នកត្រូវតែផ្ញើសំណើទៅកាន់បន្ទាត់ដែលសំណើដំបូងរបស់អ្នកប្រើប្រាស់បានមក នោះអ្នកមានជម្រើសពីរ...
  ជម្រើសដំបូង៖ អ្នកអាចទិញ nginx+ ដែលបានបង់។ មានយន្តការ Sticky sessions ដែលតាមការស្នើសុំដំបូងរបស់អ្នកប្រើ កំណត់វគ្គមួយទៅអ្នកប្រើប្រាស់ ហើយចងវាទៅមួយ ឬមួយបន្តបន្ទាប់ទៀត។ សំណើរបស់អ្នកប្រើប្រាស់ជាបន្តបន្ទាប់ទាំងអស់ក្នុងរយៈពេលពេញមួយវគ្គ នឹងត្រូវបានផ្ញើទៅកាន់ចរន្តដូចគ្នាដែលវគ្គនេះត្រូវបានបង្ហោះ។

  វាមិនសមនឹងយើងទេព្រោះយើងមាន nginx ធម្មតារួចហើយ។ ការប្តូរទៅ nginx+ មិនមែនថាវាថ្លៃទេ វាគ្រាន់តែថាវាឈឺចាប់បន្តិចសម្រាប់យើង និងមិនត្រឹមត្រូវខ្លាំងណាស់។ ឧទាហរណ៍ "Sticks Sessions" មិនដំណើរការសម្រាប់យើងសម្រាប់ហេតុផលសាមញ្ញថា "Sticks Sessions" មិនអនុញ្ញាតឱ្យកំណត់ផ្លូវដោយផ្អែកលើ "Oither-or"។ នៅទីនោះ អ្នកអាចបញ្ជាក់នូវអ្វីដែលយើង "Sticks Sessions" ធ្វើ ឧទាហរណ៍ តាមអាសយដ្ឋាន IP ឬដោយអាសយដ្ឋាន IP និងខូគី ឬតាមប៉ារ៉ាម៉ែត្រក្រោយ ប៉ុន្តែ "ទាំង-ឬ" មានភាពស្មុគស្មាញជាងនៅទីនោះ។

  ដូច្នេះ​ហើយ យើង​បាន​មក​ដល់​ជម្រើស​ទី​បួន។ យើងបានយក nginx លើស្តេរ៉ូអ៊ីត (នេះគឺជាការបើកចំហរ) - នេះគឺជា nginx ដូចគ្នា ដែលលើសពីនេះទៀតគាំទ្រការដាក់បញ្ចូលស្គ្រីបចុងក្រោយ។ អ្នកអាចសរសេរស្គ្រីបចុងក្រោយ ផ្តល់ឱ្យវានូវ "ការសម្រាកដោយបើកចំហ" ហើយស្គ្រីបចុងក្រោយនេះនឹងត្រូវបានប្រតិបត្តិនៅពេលដែលសំណើរបស់អ្នកប្រើប្រាស់មកដល់។

  ហើយតាមការពិត យើងបានសរសេរស្គ្រីបបែបនេះ កំណត់ខ្លួនយើងថា "openresti" ហើយនៅក្នុងស្គ្រីបនេះ យើងតម្រៀបតាមប៉ារ៉ាម៉ែត្រ 6 ផ្សេងគ្នាដោយការភ្ជាប់គ្នា "ឬ" ។ អាស្រ័យលើវត្តមាននៃប៉ារ៉ាម៉ែត្រមួយឬមួយផ្សេងទៀតយើងដឹងថាអ្នកប្រើប្រាស់បានមកទំព័រមួយឬមួយផ្សេងទៀតបន្ទាត់មួយឬមួយផ្សេងទៀត។

  ខៀវ/បៃតង ដាក់ពង្រាយ។ គុណសម្បត្តិ​និង​គុណវិបត្តិ

  ជាការពិតណាស់ វាប្រហែលជាអាចធ្វើឱ្យវាសាមញ្ញជាងនេះបន្តិច (ប្រើ "វគ្គស្អិត" ដូចគ្នា) ប៉ុន្តែយើងក៏មានភាពខុសប្លែកគ្នាផងដែរ ដែលមិនត្រឹមតែអ្នកប្រើប្រាស់ធ្វើអន្តរកម្មជាមួយយើងក្នុងក្របខ័ណ្ឌនៃដំណើរការនៃប្រតិបត្តិការមួយ... ប៉ុន្តែប្រព័ន្ធទូទាត់ក៏មានអន្តរកម្មជាមួយយើងផងដែរ៖ បន្ទាប់ពីយើងដំណើរការប្រតិបត្តិការ (ដោយការផ្ញើសំណើទៅកាន់ប្រព័ន្ធទូទាត់) យើងទទួលបាន coolback។
  ហើយឧបមាថាប្រសិនបើនៅក្នុងសៀគ្វីរបស់យើងយើងអាចបញ្ជូនអាសយដ្ឋាន IP របស់អ្នកប្រើក្នុងរាល់សំណើនិងបែងចែកអ្នកប្រើប្រាស់ដោយផ្អែកលើអាសយដ្ឋាន IP នោះយើងនឹងមិនប្រាប់ "Visa" ដូចគ្នាទេ: "លោកពូ យើងជាក្រុមហ៊ុន retro យើងហាក់ដូចជា ដើម្បីឱ្យមានលក្ខណៈអន្តរជាតិ (នៅលើគេហទំព័រ និងនៅក្នុងប្រទេសរុស្ស៊ី)... សូមផ្តល់ឱ្យយើងនូវអាសយដ្ឋាន IP របស់អ្នកប្រើនៅក្នុងវាលបន្ថែម ពិធីការរបស់អ្នកត្រូវបានធ្វើឱ្យមានលក្ខណៈស្តង់ដារ"! វាច្បាស់ណាស់ថាពួកគេនឹងមិនយល់ព្រម។

  
  
  ដូច្នេះវាមិនដំណើរការសម្រាប់យើងទេ - យើងបើកចំហរ។ ដូច្នោះហើយជាមួយនឹង routing យើងទទួលបានអ្វីមួយដូចនេះ៖

  ការដាក់ពង្រាយពណ៌ខៀវ/បៃតង មានគុណសម្បត្តិដែលខ្ញុំបានលើកឡើង និងគុណវិបត្តិ។

  គុណវិបត្តិពីរ៖

  • អ្នកត្រូវរំខានជាមួយការបញ្ជូន;
  • គុណវិបត្តិចម្បងទីពីរគឺការចំណាយ។

  អ្នក​ត្រូវ​ការ​ម៉ាស៊ីន​មេ​ច្រើន​ជាង​ពីរ​ដង អ្នក​ត្រូវ​ការ​ធនធាន​ប្រតិបត្តិការ​ច្រើន​ជាង​ពីរ​ដង អ្នក​ត្រូវ​ការ​ចំណាយ​ច្រើន​ជាង​ការ​ខិត​ខំ​ប្រឹង​ប្រែង​ទ្វេដង​ដើម្បី​រក្សា​សួន​សត្វ​ទាំង​មូល​នេះ។

  និយាយអីញ្ចឹង ក្នុងចំណោមគុណសម្បត្តិមានរឿងមួយទៀតដែលខ្ញុំមិនបានលើកឡើងពីមុនមក៖ អ្នកមានទុនបម្រុងក្នុងករណីមានការកើនឡើងនៃបន្ទុក។ ប្រសិនបើអ្នកមានការកើនឡើងយ៉ាងខ្លាំងនៅក្នុងបន្ទុក អ្នកមានអ្នកប្រើប្រាស់ច្រើន បន្ទាប់មកអ្នកគ្រាន់តែបញ្ចូលខ្សែទីពីរក្នុងការចែកចាយ 50 ទៅ 50 ហើយអ្នកមានម៉ាស៊ីនមេ x2 ភ្លាមៗនៅក្នុងចង្កោមរបស់អ្នករហូតដល់អ្នកដោះស្រាយបញ្ហានៃការមានម៉ាស៊ីនមេបន្ថែម។

  តើធ្វើដូចម្តេចដើម្បីធ្វើឱ្យការដាក់ពង្រាយរហ័ស?

  យើងបាននិយាយអំពីវិធីដោះស្រាយបញ្ហានៃការបង្រួមអប្បបរមា និងការវិលត្រលប់វិញយ៉ាងរហ័ស ប៉ុន្តែសំណួរនៅតែមាន៖ "តើត្រូវដាក់ពង្រាយឱ្យលឿនដោយរបៀបណា?"

  
  
  វាខ្លី និងសាមញ្ញនៅទីនេះ។

  • អ្នកត្រូវតែមានប្រព័ន្ធស៊ីឌី (ការចែកចាយបន្ត) - អ្នកមិនអាចរស់នៅដោយគ្មានវាបានទេ។ ប្រសិនបើអ្នកមានម៉ាស៊ីនមេតែមួយ អ្នកអាចដាក់ពង្រាយដោយដៃ។ យើងមានម៉ាស៊ីនមេប្រហែលមួយពាន់កន្លះ និងចំណុចទាញមួយពាន់កន្លះ ជាការពិត យើងអាចដាំនាយកដ្ឋានទំហំបន្ទប់នេះដើម្បីដាក់ពង្រាយ។
  • ការដាក់ពង្រាយត្រូវតែស្របគ្នា។ ប្រសិនបើការដាក់ពង្រាយរបស់អ្នកមានលក្ខណៈបន្តបន្ទាប់គ្នា នោះអ្វីៗទាំងអស់គឺមិនល្អ ម៉ាស៊ីនមេមួយគឺធម្មតា អ្នកនឹងដាក់ពង្រាយម៉ាស៊ីនមេមួយពាន់កន្លះពេញមួយថ្ងៃ។
  • ជាថ្មីម្តងទៀត សម្រាប់ការបង្កើនល្បឿន នេះប្រហែលជាមិនចាំបាច់ទៀតទេ។ ក្នុងអំឡុងពេលដាក់ពង្រាយ គម្រោងនេះត្រូវបានសាងសង់ជាធម្មតា។ អ្នកមានគម្រោងបណ្តាញ មានផ្នែកខាងមុខ (អ្នកធ្វើកញ្ចប់បណ្តាញនៅទីនោះ អ្នកចងក្រង npm - អ្វីមួយដូចនោះ) ហើយដំណើរការនេះគឺជាគោលការណ៍មានរយៈពេលខ្លី - 5 នាទី ប៉ុន្តែ 5 នាទីនេះអាច រិះគន់។ នោះហើយជាមូលហេតុដែល ជាឧទាហរណ៍ យើងមិនធ្វើដូច្នេះទេ៖ យើងដកចេញ 5 នាទីទាំងនេះ យើងដាក់ពង្រាយវត្ថុបុរាណ។

    តើវត្ថុបុរាណជាអ្វី? វត្ថុបុរាណគឺជាសំណង់ដែលផ្គុំឡើង ដែលផ្នែកដំឡើងទាំងអស់ត្រូវបានបញ្ចប់រួចហើយ។ យើងរក្សាទុកវត្ថុបុរាណនេះនៅក្នុងកន្លែងផ្ទុកវត្ថុបុរាណ។ នៅពេលមួយ យើងបានប្រើកន្លែងផ្ទុកទិន្នន័យបែបនេះចំនួនពីរ - វាគឺជា Nexus និងឥឡូវនេះ jFrog Artifactory)។ ដំបូងឡើយ យើងប្រើ "Nexus" ដោយសារតែយើងបានចាប់ផ្តើមអនុវត្តវិធីសាស្រ្តនេះនៅក្នុងកម្មវិធី java (វាសាកសមនឹងវាល្អ)។ បន្ទាប់មកពួកគេបានដាក់កម្មវិធីមួយចំនួនដែលសរសេរជា PHP នៅទីនោះ។ ហើយ "Nexus" មិនសមរម្យទៀតទេ ដូច្នេះហើយ យើងបានជ្រើសរើស jFrog Artefactory ដែលអាចបង្កើតវត្ថុបុរាណស្ទើរតែទាំងអស់។ យើង​បាន​ឈាន​ដល់​ចំណុច​ដែល​ក្នុង​ឃ្លាំង​វត្ថុ​បុរាណ​នេះ​យើង​ទុក​កញ្ចប់​គោលពីរ​ផ្ទាល់​ខ្លួន​ដែល​យើង​ប្រមូល​សម្រាប់​ម៉ាស៊ីន​មេ។

  ការកើនឡើងនៃបន្ទុកផ្ទុះ

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

  យើងបានសរសេរប្រព័ន្ធថ្មីមួយ - វាជាសេវាកម្មតម្រង់ទិស ម៉ូតទាន់សម័យ ស្រស់ស្អាត កម្មករគ្រប់ទីកន្លែង តម្រង់ជួរគ្រប់កន្លែង មិនស៊ីសង្វាក់គ្នាគ្រប់ទីកន្លែង។ ហើយនៅក្នុងប្រព័ន្ធបែបនេះ ទិន្នន័យអាចហូរតាមលំហូរផ្សេងៗគ្នា។ សម្រាប់ប្រតិបត្តិការលើកទី 1 កម្មករទី 3 ទី 10 ទី 2 អាចត្រូវបានប្រើសម្រាប់ប្រតិបត្តិការទីពីរ - ទី 4 ទី 5 ទី XNUMX ។ ហើយថ្ងៃនេះ ចូរនិយាយថានៅពេលព្រឹកអ្នកមានលំហូរទិន្នន័យដែលប្រើកម្មករបីនាក់ដំបូង ហើយនៅពេលល្ងាចវាផ្លាស់ប្តូរយ៉ាងខ្លាំង ហើយអ្វីៗទាំងអស់ប្រើកម្មករបីនាក់ផ្សេងទៀត។

  ហើយនៅទីនេះវាប្រែថាអ្នកត្រូវធ្វើមាត្រដ្ឋានកម្មករ អ្នកត្រូវធ្វើមាត្រដ្ឋានសេវាកម្មរបស់អ្នកដោយរបៀបណា ប៉ុន្តែនៅពេលជាមួយគ្នានេះការពារការហើមពោះធនធាន។

  
  
  យើងបានកំណត់តម្រូវការរបស់យើង។ តម្រូវការទាំងនេះគឺសាមញ្ញណាស់៖ មានការរកឃើញសេវាកម្ម ការកំណត់ប៉ារ៉ាម៉ែត្រ - អ្វីគ្រប់យ៉ាងគឺជាស្តង់ដារសម្រាប់ការកសាងប្រព័ន្ធដែលអាចធ្វើមាត្រដ្ឋានបាន លើកលែងតែចំណុចមួយ - ការរំលោះធនធាន។ យើងបាននិយាយថា យើងមិនទាន់ត្រៀមខ្លួនរួចជាស្រេចក្នុងការកាត់បន្ថយធនធាន ដើម្បីឱ្យម៉ាស៊ីនមេកំដៅខ្យល់។ យើងយក "កុងស៊ុល" យើងយក "ណូម៉ាដ" ដែលគ្រប់គ្រងកម្មកររបស់យើង។

  ហេតុអ្វីបានជានេះជាបញ្ហាសម្រាប់យើង? ចូរ​ថយ​ក្រោយ​បន្តិច។ ឥឡូវនេះយើងមានប្រព័ន្ធទូទាត់ប្រហែល 70 នៅពីក្រោយយើង។ នៅពេលព្រឹក ចរាចរណ៍ឆ្លងកាត់ Sberbank បន្ទាប់មក Sberbank បានធ្លាក់ចុះ ជាឧទាហរណ៍ ហើយយើងប្តូរវាទៅប្រព័ន្ធទូទាត់ផ្សេងទៀត។ យើងមានកម្មករ 100 នាក់នៅមុន Sberbank ហើយបន្ទាប់ពីនោះ យើងត្រូវបង្កើនកម្មករ 100 នាក់យ៉ាងខ្លាំងសម្រាប់ប្រព័ន្ធទូទាត់មួយផ្សេងទៀត។ ហើយវាជាការចង់ឱ្យអ្វីៗទាំងអស់នេះកើតឡើងដោយគ្មានការចូលរួមពីមនុស្ស។ ព្រោះប្រសិនបើមានការចូលរួមពីមនុស្ស គួរតែមានវិស្វករម្នាក់អង្គុយនៅទីនោះ 24/7 ដែលគួរតែធ្វើបែបនេះ ព្រោះការបរាជ័យបែបនេះ នៅពេលដែលប្រព័ន្ធ 70 នៅពីក្រោយអ្នក តែងតែកើតឡើងជាទៀងទាត់។

  ដូច្នេះហើយ យើងបានពិនិត្យមើល Nomad ដែលមាន IP បើកចំហ ហើយបានសរសេររឿងផ្ទាល់ខ្លួនរបស់យើងគឺ Scale-Nomad - ScaleNo ដែលធ្វើប្រហែលដូចខាងក្រោម៖ វាតាមដានកំណើននៃជួរ និងកាត់បន្ថយ ឬបង្កើនចំនួនកម្មករអាស្រ័យលើសក្ដានុពល។ នៃជួរ។ ពេល​យើង​ធ្វើ​វា យើង​គិត​ថា "ប្រហែល​ជា​យើង​អាច​បើក​ប្រភព​វា​បាន? បន្ទាប់មកពួកគេបានមើលនាង - នាងសាមញ្ញដូចជាពីរ kopecks ។

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

  
  
  តើវាដំណើរការយ៉ាងដូចម្តេច? តោះមើល! សម្លឹងទៅមុខ៖ នៅផ្នែកខាងឆ្វេងមានផ្នែកមួយនៃការត្រួតពិនិត្យរបស់យើង៖ នេះគឺជាបន្ទាត់មួយ នៅផ្នែកខាងលើគឺជាពេលវេលានៃដំណើរការព្រឹត្តិការណ៍ នៅកណ្តាលគឺជាចំនួនប្រតិបត្តិការ ហើយនៅខាងក្រោមគឺជាចំនួនកម្មករ។

  បើ​មើល​ទៅ​មាន​ភាព​មិន​ប្រក្រតី​ក្នុង​រូបភាព​នេះ។ នៅលើតារាងកំពូលតារាងមួយក្នុងចំណោមគំនូសតាងបានគាំងក្នុងរយៈពេល 45 វិនាទី - ប្រព័ន្ធទូទាត់មួយបានធ្លាក់ចុះ។ ភ្លាមៗនោះ ចរាចរណ៍ត្រូវបាននាំមកក្នុងរយៈពេល 2 នាទី ហើយជួរចាប់ផ្តើមកើនឡើងនៅលើប្រព័ន្ធទូទាត់មួយផ្សេងទៀត ដែលមិនមានកម្មករ (យើងមិនបានប្រើប្រាស់ធនធាន - ផ្ទុយទៅវិញ យើងបានបោះចោលធនធានត្រឹមត្រូវ)។ យើង​មិន​ចង់​កម្តៅ​ទេ - មាន​ចំនួន​តិច​តួច​គឺ​មាន​កម្មករ​ប្រហែល ៥-១០ នាក់ ប៉ុន្តែ​ពួក​គេ​មិន​អាច​ទ្រាំទ្រ​បាន។

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

  ការត្រួតពិនិត្យ។ តើធ្វើដូចម្តេចដើម្បីកំណត់បញ្ហាយ៉ាងឆាប់រហ័ស?

  ឥឡូវនេះចំណុចដំបូងគឺ "តើធ្វើដូចម្តេចដើម្បីកំណត់បញ្ហាឱ្យបានរហ័ស?" តាមដាន! យើង​ត្រូវ​តែ​យល់​ពី​រឿង​មួយ​ចំនួន​យ៉ាង​ឆាប់​រហ័ស។ តើ​យើង​គួរ​យល់​យ៉ាង​ណា​ឲ្យ​បាន​ឆាប់​រហ័ស?

  
  
  បីយ៉ាង!

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

  ខ្ញុំប្រហែលជាមិនប្រាប់អ្នកនូវអ្វីដែលឡូយនៅទីនេះទេ។ ខ្ញុំនឹងក្លាយជា Captain Obvious ។ យើងបានស្វែងរកអ្វីដែលមាននៅលើទីផ្សារ។ យើងមាន "សួនសត្វរីករាយ" ។ នេះជាប្រភេទសួនសត្វដែលយើងមានឥឡូវនេះ៖

  
  
  យើងប្រើ Zabbix ដើម្បីត្រួតពិនិត្យផ្នែករឹង ដើម្បីតាមដានសូចនាករសំខាន់ៗនៃម៉ាស៊ីនមេ។ យើងប្រើ Okmeter សម្រាប់មូលដ្ឋានទិន្នន័យ។ យើងប្រើ "Grafana" និង "Prometheus" សម្រាប់សូចនាករផ្សេងទៀតទាំងអស់ដែលមិនសមនឹងពីរដំបូង ខ្លះជាមួយ "Grafana" និង "Prometheus" និងខ្លះជាមួយ "Grafana" ជាមួយ "Influx" និង Telegraf ។

  កាលពីមួយឆ្នាំមុន ពួកយើងចង់ប្រើ New Relic។ ឡូយ វា​អាច​ធ្វើ​បាន​គ្រប់​យ៉ាង។ ប៉ុន្តែ​តាម​ដែល​នាង​អាច​ធ្វើ​បាន​គ្រប់​យ៉ាង នាង​ថ្លៃ​ណាស់​។ នៅពេលដែលយើងកើនឡើងដល់ចំនួន 1,5 ពាន់ម៉ាស៊ីនមេ អ្នកលក់ម្នាក់បានមករកយើងហើយនិយាយថា "តោះបញ្ចប់កិច្ចព្រមព្រៀងសម្រាប់ឆ្នាំក្រោយ" ។ យើង​មើល​តម្លៃ​ហើយ​ថា​ទេ យើង​មិន​ធ្វើ​បែប​នោះ​ទេ។ ឥឡូវនេះយើងកំពុងបោះបង់ចោល New Relic យើងមានម៉ាស៊ីនមេប្រហែល 15 ដែលនៅសល់ក្រោមការត្រួតពិនិត្យរបស់ New Relic ។ តម្លៃបានប្រែទៅជាព្រៃ។

  ហើយមានឧបករណ៍មួយដែលយើងអនុវត្តដោយខ្លួនឯង - នេះគឺជាកម្មវិធីបំបាត់កំហុស។ ដំបូង​ឡើយ យើង​បាន​ហៅ​វា​ថា "Bagger" ប៉ុន្តែ​បន្ទាប់​មក​មាន​គ្រូ​បង្រៀន​ភាសា​អង់គ្លេស​ម្នាក់​បាន​ដើរ​កាត់​ដោយ​សើច​យ៉ាង​ខ្លាំង ហើយ​ប្តូរ​ឈ្មោះ​វា​ថា "Debagger"។ តើ​វា​ជា​អ្វី? នេះគឺជាឧបករណ៍ដែលតាមពិតក្នុងរយៈពេល 15-30 វិនាទីលើសមាសធាតុនីមួយៗដូចជា "ប្រអប់ខ្មៅ" នៃប្រព័ន្ធដំណើរការការធ្វើតេស្តលើដំណើរការទាំងមូលនៃសមាសភាគ។

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

  តើសូចនាករអ្វីខ្លះដែលមានសារៈសំខាន់សម្រាប់ការត្រួតពិនិត្យ?

  តើយើងត្រួតពិនិត្យអ្វីជាចម្បង? តើសូចនាករអ្វីខ្លះដែលសំខាន់សម្រាប់យើង?

  
  

  • ពេលវេលាឆ្លើយតប / RPS នៅលើផ្នែកខាងមុខគឺជាសូចនាករសំខាន់ណាស់។ គាត់ឆ្លើយភ្លាមៗថាមានអ្វីមួយខុសជាមួយអ្នក។
  • ចំនួននៃសារដែលបានដំណើរការនៅក្នុងជួរទាំងអស់។
  • ចំនួនកម្មករ។
  • រង្វាស់ភាពត្រឹមត្រូវជាមូលដ្ឋាន។

  ចំណុចចុងក្រោយគឺ "ធុរកិច្ច", "ធុរកិច្ច" ម៉ែត្រ។ ប្រសិនបើអ្នកចង់ត្រួតពិនិត្យរឿងដូចគ្នា អ្នកត្រូវកំណត់ម៉ែត្រមួយ ឬពីរដែលជាសូចនាករសំខាន់សម្រាប់អ្នក។ ម៉ែត្ររបស់យើងគឺឆ្លងកាត់ (នេះគឺជាសមាមាត្រនៃចំនួនប្រតិបត្តិការជោគជ័យទៅនឹងលំហូរប្រតិបត្តិការសរុប)។ ប្រសិនបើមានអ្វីមួយផ្លាស់ប្តូរនៅក្នុងវានៅចន្លោះពេល 5-10-15 នាទីវាមានន័យថាយើងមានបញ្ហា (ប្រសិនបើវាផ្លាស់ប្តូរយ៉ាងខ្លាំង) ។

  អ្វី​ដែល​វា​មើល​ទៅ​ដូច​ជា​សម្រាប់​យើង​គឺ​ជា​ឧទាហរណ៍​នៃ​ក្រុមប្រឹក្សា​មួយ​របស់​យើង​:

  
  
  នៅផ្នែកខាងឆ្វេងមានក្រាហ្វចំនួន 6 នេះបើយោងតាមបន្ទាត់ - ចំនួនកម្មករនិងចំនួនសារនៅក្នុងជួរ។ នៅខាងស្តាំ - RPS, RTS ។ ខាងក្រោមគឺជារង្វាស់ "អាជីវកម្ម" ដូចគ្នា។ ហើយនៅក្នុងរង្វាស់ "អាជីវកម្ម" យើងអាចមើលឃើញភ្លាមៗថាមានអ្វីមួយខុសប្រក្រតីនៅក្នុងក្រាហ្វកណ្តាលពីរ... នេះគ្រាន់តែជាប្រព័ន្ធមួយផ្សេងទៀតដែលឈរនៅពីក្រោយពួកយើងដែលបានធ្លាក់ចុះ។

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

  
  
  ក្រាហ្វបង្ហាញយើងថាប្រព័ន្ធទូទាត់មួយបានចាប់ផ្តើមឆ្លើយតបក្នុងរយៈពេល 3 វិនាទី - យើងមានបញ្ហា។ លើសពីនេះទៅទៀត រឿងនេះនឹងមានប្រតិកម្មនៅពេលដែលបញ្ហាចាប់ផ្តើមនៅចន្លោះពេល 20-30 វិនាទី។

  ហើយថ្នាក់ទីបីនៃការត្រួតពិនិត្យកំហុសដែលមានគឺការត្រួតពិនិត្យឡូជីខល។

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

  
  
  តើ​ការ​ត្រួតពិនិត្យ​ឡូជីខល​មានន័យ​ដូចម្តេច​? ជាការប្រសើរណាស់, ស្រមៃ: អ្នកធ្វើឱ្យខ្លួនអ្នកជាប្រព័ន្ធមួយ (ឧទាហរណ៍, ក្លូន Tinder); អ្នកបានបង្កើតវា បើកដំណើរការវា។ អ្នកគ្រប់គ្រងជោគជ័យ Vasya Pupkin ដាក់វានៅលើទូរស័ព្ទរបស់គាត់ ឃើញក្មេងស្រីនៅទីនោះ ចូលចិត្តនាង... ហើយការចូលចិត្តមិនទៅក្មេងស្រីនោះទេ - ដូចជាទៅសន្តិសុខ Mikhalych មកពីមជ្ឈមណ្ឌលពាណិជ្ជកម្មដូចគ្នា។ អ្នកគ្រប់គ្រងចុះទៅជាន់ក្រោម ហើយបន្ទាប់មកឆ្ងល់ថា "ហេតុអ្វីបានជាសន្តិសុខ Mikhalych ញញឹមដាក់គាត់យ៉ាងរីករាយដូច្នេះ?"

  ក្នុងស្ថានភាពបែបនេះ... សម្រាប់ពួកយើង ស្ថានភាពនេះស្តាប់ទៅខុសគ្នាបន្តិចបន្តួច ពីព្រោះ (ខ្ញុំបានសរសេរ) នេះគឺជាការខាតបង់កេរ្តិ៍ឈ្មោះ ដែលនាំឱ្យមានការខាតបង់ផ្នែកហិរញ្ញវត្ថុដោយប្រយោល។ ស្ថានភាពរបស់យើងគឺផ្ទុយពីនេះ៖ យើងអាចទទួលរងការខាតបង់ផ្នែកហិរញ្ញវត្ថុដោយផ្ទាល់ - ឧទាហរណ៍ ប្រសិនបើយើងធ្វើប្រតិបត្តិការដោយជោគជ័យ ប៉ុន្តែវាមិនជោគជ័យ (ឬផ្ទុយទៅវិញ)។ ខ្ញុំត្រូវសរសេរឧបករណ៍ផ្ទាល់ខ្លួនរបស់ខ្ញុំដែលតាមដានចំនួនប្រតិបត្តិការជោគជ័យតាមពេលវេលាដោយប្រើសូចនាករអាជីវកម្ម។ រកមិនឃើញនៅលើទីផ្សារ! នេះពិតជាគំនិតដែលខ្ញុំចង់បង្ហាញ។ មិនមានអ្វីនៅលើទីផ្សារដើម្បីដោះស្រាយបញ្ហាបែបនេះទេ។

  នេះជារបៀបកំណត់បញ្ហាយ៉ាងរហ័ស។

  របៀបកំណត់មូលហេតុនៃការដាក់ពង្រាយ

  ក្រុមទី 3 នៃបញ្ហាដែលយើងដោះស្រាយគឺបន្ទាប់ពីយើងកំណត់បញ្ហាបន្ទាប់ពីយើងបានកម្ចាត់វាហើយ វាជាការល្អក្នុងការស្វែងយល់ពីហេតុផលសម្រាប់ការអភិវឌ្ឍន៍ សាកល្បង និងធ្វើអ្វីមួយអំពីវា។ អ៊ីចឹង​ត្រូវ​ស៊ើប​អង្កេត យើង​ត្រូវ​លើក​ឈើ។

  
  
  ប្រសិនបើយើងកំពុងនិយាយអំពីកំណត់ហេតុ (មូលហេតុចម្បងគឺកំណត់ហេតុ) ភាគច្រើននៃកំណត់ហេតុរបស់យើងគឺនៅក្នុង ELK Stack - ស្ទើរតែគ្រប់គ្នាមានដូចគ្នា។ សម្រាប់អ្នកខ្លះ វាប្រហែលជាមិនមាននៅក្នុង ELK ទេ ប៉ុន្តែប្រសិនបើអ្នកសរសេរកំណត់ហេតុជាជីហ្គាបៃ នោះមិនយូរមិនឆាប់ អ្នកនឹងមក ELK ។ យើងសរសេរជា terabytes ។

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

  យើងបានគិតរឿងនេះកាលពីមួយឆ្នាំមុន បង្វែរការយកចិត្តទុកដាក់របស់យើងទៅកាន់ទីផ្សារ ហើយមានឧបករណ៍ពីរនៅទីនោះ - "Zipkin" និង "Jaeger" ។ តាមពិត "Jager" គឺជាអ្នកស្នងមរតកមនោគមវិជ្ជា ដែលជាអ្នកស្នងមនោគមវិជ្ជារបស់ "Zipkin" ។ អ្វីគ្រប់យ៉ាងគឺល្អនៅក្នុង Zipkin លើកលែងតែវាមិនដឹងពីរបៀបប្រមូលផ្តុំវាមិនដឹងពីរបៀបបញ្ចូលកំណត់ហេតុនៅក្នុងដានទេមានតែដានពេលវេលាប៉ុណ្ណោះ។ ហើយ "Jager" បានគាំទ្ររឿងនេះ។

  យើងបានក្រឡេកមើល "Jager"៖ អ្នកអាចប្រើប្រាស់ឧបករណ៍ អ្នកអាចសរសេរក្នុង Api (ស្តង់ដារ Api សម្រាប់ PHP នៅពេលនោះ ទោះជាយ៉ាងណា មិនត្រូវបានអនុម័តទេ - នេះគឺកាលពីមួយឆ្នាំមុន ប៉ុន្តែឥឡូវនេះវាត្រូវបានអនុម័តរួចហើយ) ប៉ុន្តែនៅទីនោះ គឺពិតជាគ្មានអតិថិជនទេ។ “មិនអីទេ” យើងគិត ហើយសរសេរអតិថិជនរបស់យើងផ្ទាល់។ តើយើងទទួលបានអ្វីខ្លះ? នេះ​ជា​រូបរាង​ប្រហែល៖

  
  
  នៅក្នុង Jaeger វិសាលភាពត្រូវបានបង្កើតឡើងសម្រាប់សារនីមួយៗ។ នោះគឺនៅពេលដែលអ្នកប្រើបើកប្រព័ន្ធគាត់ឃើញប្លុកមួយឬពីរសម្រាប់សំណើចូលនីមួយៗ (1-2-3 - ចំនួនសំណើចូលពីអ្នកប្រើប្រាស់ចំនួនប្លុក) ។ ដើម្បីធ្វើឱ្យវាកាន់តែងាយស្រួលសម្រាប់អ្នកប្រើប្រាស់ យើងបានបន្ថែមស្លាកទៅក្នុងកំណត់ហេតុ និងដានពេលវេលា។ ដូច្នោះហើយ ក្នុងករណីមានកំហុស កម្មវិធីរបស់យើងនឹងសម្គាល់កំណត់ហេតុជាមួយនឹងស្លាកកំហុសសមស្រប។ អ្នកអាចត្រងដោយស្លាកកំហុស ហើយមានតែវិសាលភាពដែលមានប្លុកនេះដែលមានកំហុសនឹងត្រូវបានបង្ហាញ។ នេះជារបៀបដែលវាមើលទៅប្រសិនបើយើងពង្រីកវិសាលភាព៖

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

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

  
  
  យើងមានផ្នែកបន្ថែមនេះ - វាគឺជាអតិថិជនសម្រាប់ OpenTracing Api វាត្រូវបានបង្កើតឡើងជា php-extention ពោលគឺអ្នកនឹងត្រូវប្រមូលផ្តុំវា ហើយដំឡើងវានៅលើប្រព័ន្ធ។ កាលពីមួយឆ្នាំមុនមិនមានអ្វីប្លែកទេ។ ឥឡូវនេះមានអតិថិជនផ្សេងទៀតដែលដូចជាសមាសភាគ។ វាអាស្រ័យលើអ្នក៖ ទាំងអ្នកបូមចេញសមាសធាតុដោយប្រើកម្មវិធីតែង ឬអ្នកប្រើផ្នែកបន្ថែមអាស្រ័យលើអ្នក។

  ស្តង់ដារសាជីវកម្ម

  យើងបាននិយាយអំពីបញ្ញត្តិទាំងបី។ បញ្ញត្តិទីបួនគឺដើម្បីស្តង់ដារវិធីសាស្រ្ត។ តើនេះនិយាយអំពីអ្វី? វាគឺអំពីរឿងនេះ៖

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

  
  

  • យើងមានច្បាប់ដាក់ពង្រាយ។ យើង​មិន​ទៅ​ណា​ទេ​បើ​គ្មាន​គាត់ យើង​មិន​អាច​ទៅ​រួច​ទេ។ យើងដាក់ពង្រាយប្រហែល 60 ដងក្នុងមួយសប្តាហ៍ ពោលគឺយើងដាក់ពង្រាយស្ទើរតែឥតឈប់ឈរ។ ក្នុងពេលជាមួយគ្នានេះ យើងមានឧទាហរណ៍នៅក្នុងបទប្បញ្ញត្តិការដាក់ពង្រាយបម្រាមមួយស្តីពីការដាក់ពង្រាយនៅថ្ងៃសុក្រ - ជាគោលការណ៍យើងមិនដាក់ពង្រាយទេ។
  • យើងត្រូវការឯកសារ។ មិនមានសមាសធាតុថ្មីតែមួយចូលផលិតកម្មទេ ប្រសិនបើមិនមានឯកសារសម្រាប់វា បើទោះបីជាវាបានកើតនៅក្រោមប៊ិចរបស់អ្នកឯកទេស RnD របស់យើងក៏ដោយ។ យើងទាមទារពីពួកគេនូវការណែនាំអំពីការដាក់ពង្រាយ ផែនទីត្រួតពិនិត្យ និងការពិពណ៌នារដុប (ដូចដែលអ្នកសរសេរកម្មវិធីអាចសរសេរបាន) អំពីរបៀបដែលសមាសធាតុនេះដំណើរការ របៀបដោះស្រាយបញ្ហា។
  • យើង​ដោះស្រាយ​មិន​មែន​មូលហេតុ​នៃ​បញ្ហា​ទេ ប៉ុន្តែ​ជា​បញ្ហា​ដែល​ខ្ញុំ​បាន​និយាយ​រួច​ហើយ។ វាមានសារៈសំខាន់សម្រាប់យើងក្នុងការការពារអ្នកប្រើប្រាស់ពីបញ្ហា។
  • យើងមានការបោសសំអាត។ ជាឧទាហរណ៍ យើងមិនចាត់ទុកវាជាពេលវេលារងចាំទេ ប្រសិនបើយើងបាត់បង់ 2% នៃចរាចរណ៍ក្នុងរយៈពេលពីរនាទី។ នេះជាមូលដ្ឋានមិនត្រូវបានរួមបញ្ចូលនៅក្នុងស្ថិតិរបស់យើងទេ។ ប្រសិនបើវាច្រើនក្នុងលក្ខខណ្ឌភាគរយ ឬបណ្តោះអាសន្ន យើងរាប់រួចហើយ។
  • ហើយ​យើង​តែង​តែ​សរសេរ​ការ​ធ្វើ​អត្តឃាត។ អ្វីក៏ដោយដែលកើតឡើងចំពោះយើង ស្ថានភាពណាមួយដែលនរណាម្នាក់មានអាកប្បកិរិយាមិនប្រក្រតីនៅក្នុងផលិតកម្ម នឹងត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុងសាកសព។ postmortem គឺជាឯកសារដែលអ្នកសរសេរនូវអ្វីដែលបានកើតឡើងចំពោះអ្នក ពេលវេលាលម្អិត អ្វីដែលអ្នកបានធ្វើដើម្បីកែវា និង (នេះគឺជាប្លុកចាំបាច់!) អ្វីដែលអ្នកនឹងធ្វើដើម្បីការពារកុំឱ្យវាកើតឡើងនៅពេលអនាគត។ នេះគឺជាកាតព្វកិច្ច និងចាំបាច់សម្រាប់ការវិភាគជាបន្តបន្ទាប់។

  អ្វី​ទៅ​ដែល​ត្រូវ​បាន​គេ​ចាត់​ទុក​ថា​ជា​ការ​ឈប់​សម្រាក?

  
  
  តើទាំងអស់នេះនាំអោយមានអ្វីខ្លះ?

  នេះនាំឱ្យមានការពិតដែលថា (យើងមានបញ្ហាជាក់លាក់ជាមួយស្ថេរភាព វាមិនសមនឹងអតិថិជន ឬយើងទេ) ក្នុងរយៈពេល 6 ខែកន្លងមកនេះ សូចនាករស្ថេរភាពរបស់យើងគឺ 99,97 ។ យើងអាចនិយាយបានថា នេះមិនច្រើនទេ។ បាទ យើងមានអ្វីដែលត្រូវខិតខំ។ នៃសូចនាករនេះ ប្រហែលពាក់កណ្តាលគឺជាស្ថេរភាព ដូចដែលវាមិនមែនជារបស់យើងទេ ប៉ុន្តែជាជញ្ជាំងភ្លើងកម្មវិធីបណ្ដាញរបស់យើង ដែលឈរនៅពីមុខយើង ហើយត្រូវបានប្រើប្រាស់ជាសេវាកម្ម ប៉ុន្តែអតិថិជនមិនខ្វល់អំពីបញ្ហានេះទេ។

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

  អស់ហើយ! សំណួររបស់អ្នក។

  
  

  អំពីតុល្យភាព និងការផ្លាស់ប្តូរមូលដ្ឋានទិន្នន័យ

  សំណួរពីទស្សនិកជន (តទៅនេះ - ខ)៖ - រាត្រីសួស្តី។ អរគុណ​ច្រើន​ចំពោះ​ការ​រាយការណ៍​បែប​នេះ​របស់ Admin! សំណួរខ្លីៗអំពីសមតុល្យរបស់អ្នក។ អ្នកបាននិយាយថាអ្នកមាន WAF នោះគឺដូចដែលខ្ញុំយល់វាអ្នកប្រើប្រភេទនៃតុល្យភាពខាងក្រៅមួយចំនួន ...

  អ៊ីខេ៖ - ទេ យើងប្រើប្រាស់សេវាកម្មរបស់យើងជាអ្នកផ្តល់តុល្យភាព។ ក្នុងករណីនេះ WAF គឺជាឧបករណ៍ការពារ DDoS ទាំងស្រុងសម្រាប់យើង។

  ក្នុង៖ - តើអ្នកអាចនិយាយពាក្យពីរបីអំពីតុល្យភាពបានទេ?

  អ៊ីខេ៖ - ដូចដែលខ្ញុំបាននិយាយរួចហើយ នេះគឺជាក្រុមនៃ servers នៅក្នុងការបើកចំហរ។ ឥឡូវនេះ យើងមានក្រុមបំរុងចំនួន 5 ដែលឆ្លើយតបទាំងស្រុង... នោះគឺជាម៉ាស៊ីនមេដែលដំណើរការការបើកចំហទាំងស្រុង វាគ្រាន់តែចរាចរប្រូកស៊ីប៉ុណ្ណោះ។ ដូច្នោះហើយ ដើម្បីយល់ពីចំនួនដែលយើងកាន់៖ ឥឡូវនេះ យើងមានលំហូរចរាចរណ៍ទៀងទាត់ជាច្រើនរយមេហ្គាប៊ីត។ ពួកគេស៊ូទ្រាំ ពួកគេមានអារម្មណ៍ល្អ ពួកគេមិនទាំងបង្ខំខ្លួនឯង។

  ក្នុង៖ - សំណួរសាមញ្ញផងដែរ។ នេះគឺជាការដាក់ពង្រាយពណ៌ខៀវ/បៃតង។ តើអ្នកធ្វើអ្វីជាឧទាហរណ៍ជាមួយការធ្វើចំណាកស្រុកមូលដ្ឋានទិន្នន័យ?

  អ៊ីខេ៖ - សំណួរ​ល្អ! រកមើលនៅក្នុងការដាក់ពង្រាយពណ៌ខៀវ/បៃតង យើងមានជួរដាច់ដោយឡែកសម្រាប់បន្ទាត់នីមួយៗ។ នោះគឺប្រសិនបើយើងកំពុងនិយាយអំពីជួរព្រឹត្តិការណ៍ដែលត្រូវបានបញ្ជូនពីកម្មករទៅកម្មករនោះ មានជួរដាច់ដោយឡែកសម្រាប់ខ្សែពណ៌ខៀវ និងសម្រាប់បន្ទាត់ពណ៌បៃតង។ ប្រសិនបើយើងកំពុងនិយាយអំពីមូលដ្ឋានទិន្នន័យខ្លួនឯង នោះយើងបានបង្រួមវាដោយចេតនាឱ្យបានច្រើនតាមតែអាចធ្វើទៅបាន ដោយបានផ្លាស់ប្តូរអ្វីៗគ្រប់យ៉ាងទៅជាជួរ ហើយនៅក្នុងមូលដ្ឋានទិន្នន័យយើងរក្សាទុកតែប្រតិបត្តិការបណ្តុំប៉ុណ្ណោះ។ ហើយជង់ប្រតិបត្តិការរបស់យើងគឺដូចគ្នាសម្រាប់បន្ទាត់ទាំងអស់។ ជាមួយនឹងមូលដ្ឋានទិន្នន័យនៅក្នុងបរិបទនេះ៖ យើងមិនបែងចែកវាទៅជាពណ៌ខៀវ និងបៃតងទេ ព្រោះកូដទាំងពីរត្រូវតែដឹងពីអ្វីដែលកំពុងកើតឡើងជាមួយប្រតិបត្តិការ។

  មិត្តភ័ក្តិ ខ្ញុំមានរង្វាន់តូចមួយដើម្បីជំរុញអ្នក - សៀវភៅមួយ។ ហើយខ្ញុំគួរតែទទួលបានរង្វាន់សម្រាប់សំណួរដ៏ល្អបំផុត។

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

  អ៊ីខេ៖ - "ពាណិជ្ជករ" សម្រាប់ពួកយើងក្នុងករណីនេះគឺពិតជាសេវាកម្មខាងក្រៅដូចគ្នាទៅនឹងប្រព័ន្ធទូទាត់។ យើងតាមដានល្បឿនឆ្លើយតបរបស់អ្នកជំនួញ។

  អំពីការអ៊ិនគ្រីបមូលដ្ឋានទិន្នន័យ

  ក្នុង៖ - ជំរាបសួរ។ ខ្ញុំមានសំណួរពាក់ព័ន្ធបន្តិច។ អ្នកមានទិន្នន័យរសើប PCI DSS ។ ខ្ញុំចង់ដឹងពីរបៀបដែលអ្នករក្សាទុក PAN នៅក្នុងជួរដែលអ្នកត្រូវការផ្ទេរទៅ? តើអ្នកប្រើការអ៊ិនគ្រីបណាមួយទេ? ហើយនេះនាំឱ្យមានសំណួរទីពីរ៖ យោងតាម ​​PCI DSS វាចាំបាច់ក្នុងការអ៊ិនគ្រីបមូលដ្ឋានទិន្នន័យឡើងវិញជាទៀងទាត់ក្នុងករណីមានការផ្លាស់ប្តូរ (ការបណ្តេញអ្នកគ្រប់គ្រង។ ល។ ) - តើមានអ្វីកើតឡើងចំពោះភាពងាយស្រួលក្នុងករណីនេះ?

  
  
  អ៊ីខេ៖ - សំណួរដ៏អស្ចារ្យ! ទីមួយ យើងមិនរក្សាទុក PAN ក្នុងជួរទេ។ យើងមិនមានសិទ្ធិរក្សាទុក PAN គ្រប់ទីកន្លែងក្នុងទម្រង់ច្បាស់លាស់ទេ ជាគោលការណ៍ ដូច្នេះយើងប្រើសេវាកម្មពិសេស (យើងហៅវាថា "Kademon") - នេះគឺជាសេវាកម្មដែលធ្វើតែមួយមុខគត់៖ វាទទួលសារជាការបញ្ចូល និងផ្ញើ ចេញសារដែលបានអ៊ិនគ្រីប។ ហើយយើងរក្សាទុកអ្វីៗគ្រប់យ៉ាងជាមួយនឹងសារដែលបានអ៊ិនគ្រីបនេះ។ ដូច្នោះហើយ ប្រវែងគន្លឹះរបស់យើងគឺស្ថិតនៅក្រោមគីឡូបៃ ដូច្នេះថាវាធ្ងន់ធ្ងរ និងអាចទុកចិត្តបាន។

  ក្នុង៖ - តើអ្នកត្រូវការ 2 គីឡូបៃឥឡូវនេះទេ?

  អ៊ីខេ៖ - វាហាក់ដូចជាកាលពីម្សិលមិញវាគឺ 256 ... មែនហើយតើកន្លែងណាទៀត?!

  ដូច្នោះហើយនេះគឺជាលើកទីមួយ។ ហើយទីពីរ ដំណោះស្រាយដែលមាន វាគាំទ្រនីតិវិធីនៃការអ៊ិនគ្រីបឡើងវិញ - មានពីរគូនៃ "keks" (កូនសោ) ដែលផ្តល់ឱ្យ "decks" ដែលអ៊ិនគ្រីប (កូនសោគឺជាកូនសោ, dek គឺជាដេរីវេនៃសោដែលអ៊ិនគ្រីប) . ហើយប្រសិនបើនីតិវិធីត្រូវបានផ្តួចផ្តើម (វាកើតឡើងជាទៀងទាត់ចាប់ពី 3 ខែដល់±ខ្លះ) យើងទាញយក "នំ" គូថ្មី ហើយយើងអ៊ិនគ្រីបទិន្នន័យឡើងវិញ។ យើង​មាន​សេវា​ដាច់​ដោយ​ឡែក​ដែល​ហែក​ចេញ​ទិន្នន័យ​ទាំង​អស់ ហើយ​អ៊ិនគ្រីប​វា​តាម​វិធី​ថ្មី ទិន្នន័យត្រូវបានរក្សាទុកនៅជាប់នឹងឧបករណ៍កំណត់អត្តសញ្ញាណនៃសោដែលវាត្រូវបានអ៊ិនគ្រីប។ ដូច្នោះហើយ ដរាបណាយើងអ៊ិនគ្រីបទិន្នន័យដោយប្រើសោថ្មី យើងលុបសោចាស់។

  ពេលខ្លះការបង់ប្រាក់ត្រូវធ្វើដោយដៃ...

  ក្នុង៖ - នោះគឺប្រសិនបើការបង្វិលសងបានមកដល់សម្រាប់ប្រតិបត្តិការមួយចំនួន តើអ្នកនឹងនៅតែឌិគ្រីបវាដោយប្រើសោចាស់ដែរឬទេ?

  អ៊ីខេ៖ - បាទ។

  ក្នុង៖ - បន្ទាប់មកសំណួរតូចមួយទៀត។ នៅពេលដែលប្រភេទនៃការបរាជ័យ ការដួលរលំ ឬឧបទ្ទវហេតុណាមួយកើតឡើង វាចាំបាច់ក្នុងការជំរុញប្រតិបត្តិការដោយដៃ។ មានស្ថានភាពបែបនេះ។

  អ៊ីខេ៖ - បាទ​ពេល​ខ្លះ។

  ក្នុង៖ - តើអ្នកទទួលបានទិន្នន័យនេះពីណា? ឬអ្នកទៅកន្លែងផ្ទុកនេះដោយខ្លួនឯង?

  អ៊ីខេ៖ - ទេ ពិតណាស់ យើងមានប្រព័ន្ធ back-office មួយចំនួនដែលមានចំណុចប្រទាក់សម្រាប់ការគាំទ្ររបស់យើង។ ប្រសិនបើយើងមិនដឹងថាប្រតិបត្តិការស្ថិតក្នុងស្ថានភាពបែបណា (ឧទាហរណ៍ រហូតដល់ប្រព័ន្ធទូទាត់ឆ្លើយតបជាមួយនឹងការអស់ពេល) យើងមិនដឹងថាអ្វីជាអាទិភាពនោះទេ ពោលគឺយើងកំណត់ស្ថានភាពចុងក្រោយដោយទំនុកចិត្តពេញលេញប៉ុណ្ណោះ។ ក្នុងករណីនេះ យើងកំណត់ប្រតិបត្តិការទៅស្ថានភាពពិសេសសម្រាប់ដំណើរការដោយដៃ។ នៅពេលព្រឹក នៅថ្ងៃបន្ទាប់ ដរាបណាការគាំទ្រទទួលបានព័ត៌មានថាប្រតិបត្តិការបែបនេះ និងបែបនេះនៅតែមាននៅក្នុងប្រព័ន្ធទូទាត់ ពួកគេដំណើរការវាដោយដៃនៅក្នុងចំណុចប្រទាក់នេះ។

  
  
  ក្នុង៖ - ខ្ញុំមានសំណួរពីរបី។ មួយក្នុងចំណោមពួកគេគឺជាការបន្តនៃតំបន់ PCI DSS: តើអ្នកចូលសៀគ្វីរបស់ពួកគេដោយរបៀបណា? សំណួរនេះគឺដោយសារតែអ្នកអភិវឌ្ឍន៍អាចដាក់អ្វីទាំងអស់នៅក្នុងកំណត់ហេតុ! សំណួរទីពីរ៖ តើអ្នកដាក់ចេញ hotfix យ៉ាងដូចម្តេច? ចំណុចទាញនៅក្នុងមូលដ្ឋានទិន្នន័យគឺជាជម្រើសមួយ ប៉ុន្តែអាចមានការដោះស្រាយបញ្ហាក្តៅដោយឥតគិតថ្លៃ - តើមាននីតិវិធីអ្វីនៅទីនោះ? ហើយសំណួរទីបីគឺប្រហែលជាទាក់ទងនឹង RTO, RPO ។ ភាពអាចរកបានរបស់អ្នកគឺ 99,97 ស្ទើរតែបួនប្រាំបួន ប៉ុន្តែតាមខ្ញុំយល់ អ្នកមានមជ្ឈមណ្ឌលទិន្នន័យទីពីរ មជ្ឈមណ្ឌលទិន្នន័យទីបី និងមជ្ឈមណ្ឌលទិន្នន័យទីប្រាំ... តើអ្នកធ្វើសមកាលកម្មពួកវា ចម្លងពួកវា និងអ្វីៗផ្សេងទៀតដោយរបៀបណា?

  អ៊ីខេ៖ - តោះចាប់ផ្តើមជាមួយទីមួយ។ ជាសំណួរដំបូងអំពីកំណត់ហេតុ? នៅពេលយើងសរសេរកំណត់ហេតុ យើងមានស្រទាប់ដែលបិទបាំងទិន្នន័យរសើបទាំងអស់។ នាងមើលរបាំងមុខនិងវាលបន្ថែម។ ដូច្នោះ កំណត់ហេតុរបស់យើងចេញមកជាមួយនឹងទិន្នន័យដែលបានបិទបាំងរួចហើយ និងសៀគ្វី PCI DSS ។ នេះ​ជា​កិច្ចការ​មួយ​ក្នុង​ចំណោម​កិច្ចការ​ធម្មតា​ដែល​ត្រូវ​បាន​ប្រគល់​ឱ្យ​នាយកដ្ឋាន​សាកល្បង។ ពួកគេត្រូវបានគេតម្រូវឱ្យពិនិត្យមើលកិច្ចការនីមួយៗ រួមទាំងកំណត់ហេតុដែលពួកគេសរសេរ ហើយនេះគឺជាកិច្ចការធម្មតាមួយក្នុងអំឡុងពេលពិនិត្យកូដ ដើម្បីគ្រប់គ្រងថាអ្នកអភិវឌ្ឍន៍មិនបានសរសេរអ្វីមួយ។ ការត្រួតពិនិត្យជាបន្តបន្ទាប់នេះត្រូវបានអនុវត្តជាទៀងទាត់ដោយនាយកដ្ឋានសន្តិសុខព័ត៌មានប្រហែលមួយដងក្នុងមួយសប្តាហ៍៖ កំណត់ហេតុសម្រាប់ថ្ងៃចុងក្រោយត្រូវបានជ្រើសរើស ហើយពួកគេត្រូវបានដំណើរការតាមរយៈម៉ាស៊ីនស្កេនពិសេស-វិភាគពីម៉ាស៊ីនមេសាកល្បងដើម្បីពិនិត្យអ្វីៗគ្រប់យ៉ាង។
  អំពីដំណោះស្រាយក្តៅ។ នេះត្រូវបានរួមបញ្ចូលនៅក្នុងបទប្បញ្ញត្តិនៃការដាក់ពង្រាយរបស់យើង។ យើង​មាន​ឃ្លា​ដាច់​ដោយ​ឡែក​អំពី hotfixes ។ យើងជឿថាយើងដាក់ពង្រាយ hotfix ជុំវិញនាឡិកា នៅពេលដែលយើងត្រូវការវា។ ដរាបណាកំណែត្រូវបានផ្គុំ ដរាបណាវាដំណើរការ ដរាបណាយើងមានវត្ថុបុរាណ យើងមានអ្នកគ្រប់គ្រងប្រព័ន្ធដែលទទួលខុសត្រូវលើការហៅទូរស័ព្ទពីជំនួយ ហើយគាត់ដាក់ពង្រាយវានៅពេលចាំបាច់។

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

  ក្នុង៖ - ប្រសិនបើអ្នកទទួលបានទីពីរ ហេតុអ្វីបានជាអ្នកមិនទទួលបានទីបី? ព្រោះ​មិន​ទាន់​មាន​អ្នក​ណា​បែក​ខួរ​...

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

  ក្នុង៖ - រាត្រីសួស្តី។ អរគុណសម្រាប់របាយការណ៍។ អ្នកបាននិយាយអំពីកម្មវិធីបំបាត់កំហុសរបស់អ្នក ដែលដំណើរការប្រតិបត្តិការសាកល្បងមួយចំនួននៅក្នុងផលិតកម្ម។ ប៉ុន្តែប្រាប់យើងអំពីប្រតិបត្តិការសាកល្បង! តើវាចូលជ្រៅប៉ុណ្ណា?

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

  ក្នុង៖ - តើអ្នកកាត់វានៅឯណា? នៅទីនេះ Core បានផ្ញើ ...

  អ៊ីខេ៖ - យើងនៅពីក្រោយ "Kor" ក្នុងករណីនេះសម្រាប់ប្រតិបត្តិការសាកល្បង... យើងមានរឿងដូចជា routing: "Kor" ដឹងពីប្រព័ន្ធទូទាត់ដែលត្រូវផ្ញើទៅ - យើងផ្ញើទៅប្រព័ន្ធទូទាត់ក្លែងក្លាយ ដែលគ្រាន់តែផ្តល់សញ្ញា http និង អស់ហើយ។

  ក្នុង៖ - សូមប្រាប់ខ្ញុំផង តើកម្មវិធីរបស់អ្នកត្រូវបានសរសេរក្នុង monolith ដ៏ធំមួយ ឬតើអ្នកបានកាត់វាចូលទៅក្នុងសេវាកម្មខ្លះ ឬសូម្បីតែ microservice?

  អ៊ីខេ៖ - យើងមិនមាន monolith ទេ យើងមានកម្មវិធីតម្រង់ទិសសេវាកម្ម។ យើងនិយាយលេងថាសេវារបស់យើងគឺធ្វើពី monoliths - ពួកគេពិតជាមានទំហំធំណាស់។ វាពិបាកក្នុងការហៅវាថាសេវាមីក្រូ ប៉ុន្តែទាំងនេះគឺជាសេវាកម្មដែលកម្មករនៃម៉ាស៊ីនចែកចាយដំណើរការ។

  ប្រសិនបើសេវាកម្មនៅលើ server ត្រូវបានសម្របសម្រួល...

  ក្នុង៖ - បន្ទាប់មកខ្ញុំមានសំណួរបន្ទាប់។ ទោះបីជាវាជា monolith ក៏ដោយ អ្នកនៅតែនិយាយថាអ្នកមាន instant servers ជាច្រើន ពួកវាទាំងអស់ដំណើរការទិន្នន័យជាមូលដ្ឋាន ហើយសំណួរគឺ៖ "ក្នុងករណីមានការសម្របសម្រួលនៃ instant servers ឬកម្មវិធី តំណភ្ជាប់បុគ្គលណាមួយ តើពួកគេមានប្រភេទនៃការគ្រប់គ្រងការចូលប្រើដែរឬទេ? តើពួកគេមួយណាអាចធ្វើអ្វីបាន? តើខ្ញុំគួរទាក់ទងអ្នកណាសម្រាប់ព័ត៌មានអ្វី?

  
  
  អ៊ីខេ៖ - ចា​ឬ​បាទ​វា​ច្បាស់លាស់​ណាស់។ តម្រូវការសុវត្ថិភាពគឺធ្ងន់ធ្ងរណាស់។ ទីមួយ យើង​មាន​ចលនា​ទិន្នន័យ​បើក​ចំហ ហើយ​ច្រក​គឺ​ជា​ច្រក​ដែល​យើង​ប្រមើល​មើល​ចលនា​ចរាចរណ៍​ជាមុន​ប៉ុណ្ណោះ។ ប្រសិនបើសមាសធាតុទំនាក់ទំនងជាមួយមូលដ្ឋានទិន្នន័យ (និយាយជាមួយ Muskul) តាមរយៈ 5-4-3-2 នោះមានតែ 5-4-3-2 ប៉ុណ្ណោះដែលនឹងបើកសម្រាប់វា ហើយច្រកផ្សេងទៀត និងទិសដៅចរាចរណ៍ផ្សេងទៀតនឹងមិនមានទេ។ លើសពីនេះទៀតអ្នកត្រូវយល់ថានៅក្នុងផលិតកម្មរបស់យើងមានរង្វិលជុំសុវត្ថិភាពប្រហែល 10 ខុសៗគ្នា។ ហើយទោះបីជាកម្មវិធីត្រូវបានសម្របសម្រួលយ៉ាងណាក៏ដោយ ក៏ព្រះជាម្ចាស់ហាមឃាត់ដែរ អ្នកវាយប្រហារនឹងមិនអាចចូលប្រើកុងសូលគ្រប់គ្រងម៉ាស៊ីនមេបានទេ ព្រោះនេះជាតំបន់សុវត្ថិភាពបណ្តាញផ្សេងគ្នា។

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

  អ៊ីខេ៖ - ខ្ញុំ​យល់។ ប្រសិនបើនៅក្នុងស្ថានភាពធម្មតាជាមួយនឹងការប្រាស្រ័យទាក់ទងជាមួយម៉ាស៊ីនមេផ្សេងទៀតត្រូវបានអនុញ្ញាតទាំងស្រុង នោះបាទ។ យោងតាមកិច្ចសន្យា SLA យើងមិនត្រួតពិនិត្យថាអ្នកត្រូវបានអនុញ្ញាតត្រឹមតែ "សកម្មភាព" 3 ដំបូងប៉ុណ្ណោះ ហើយអ្នកមិនត្រូវបានអនុញ្ញាត 4 "សកម្មភាព" នោះទេ។ នេះប្រហែលជាមិនអាចខ្វះបានសម្រាប់យើងទេ ព្រោះយើងមានប្រព័ន្ធការពារ 4 កម្រិតរួចហើយ ជាគោលការណ៍សម្រាប់សៀគ្វី។ យើងចូលចិត្តការពារខ្លួនយើងដោយប្រើវណ្ឌវង្ក ជាជាងនៅកម្រិតខាងក្នុង។

  របៀបដែល Visa, MasterCard និង Sberbank ដំណើរការ

  ក្នុង៖ – ខ្ញុំចង់បញ្ជាក់ចំណុចមួយអំពីការប្តូរអ្នកប្រើប្រាស់ពីមជ្ឈមណ្ឌលទិន្នន័យមួយទៅមជ្ឈមណ្ឌលទិន្នន័យមួយទៀត។ តាមដែលខ្ញុំដឹង Visa និង MasterCard ដំណើរការដោយប្រើ 8583 binary synchronous protocol ហើយមានការលាយបញ្ចូលគ្នានៅទីនោះ។ ហើយ​ខ្ញុំ​ចង់ដឹង​ថា ឥឡូវនេះ​យើង​មាន​ន័យ​ថា​ប្តូរ – តើ​វា​ផ្ទាល់ “Visa” និង “MasterCard” ឬ​មុន​ប្រព័ន្ធ​ទូទាត់ មុន​ដំណើរការ​?

  អ៊ីខេ៖ - នេះគឺមុនពេលលាយ។ ល្បាយរបស់យើងមានទីតាំងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យដូចគ្នា។

  ក្នុង៖ - និយាយឱ្យចំទៅ តើអ្នកមានចំណុចតភ្ជាប់មួយទេ?

  អ៊ីខេ៖ - "Visa" និង "MasterCard" - បាទ។ ជាឧទាហរណ៍ ដោយសារ Visa និង MasterCard ទាមទារការវិនិយោគយ៉ាងធ្ងន់ធ្ងរនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធ ដើម្បីបញ្ចប់កិច្ចសន្យាដាច់ដោយឡែកដើម្បីទទួលបានគូទីពីរ។ ពួកគេត្រូវបានបម្រុងទុកនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យតែមួយ ប៉ុន្តែប្រសិនបើព្រះជាម្ចាស់ហាមឃាត់ មជ្ឈមណ្ឌលទិន្នន័យរបស់យើងដែលមានការលាយបញ្ចូលគ្នាសម្រាប់ភ្ជាប់ទៅ Visa និង MasterCard បានស្លាប់ នោះយើងនឹងមានការតភ្ជាប់ជាមួយ Visa និង MasterCard បាត់បង់...

  ក្នុង៖ - តើគេអាចកក់ទុកបានដោយរបៀបណា? ខ្ញុំដឹងថា Visa អនុញ្ញាតឱ្យមានការតភ្ជាប់តែមួយជាគោលការណ៍!

  អ៊ីខេ៖ - ពួកគេផ្គត់ផ្គង់ឧបករណ៍ដោយខ្លួនឯង។ ក្នុងករណីណាក៏ដោយ យើងបានទទួលគ្រឿងបរិក្ខារដែលប្រើប្រាស់ឡើងវិញទាំងស្រុងនៅខាងក្នុង។

  ក្នុង៖ - ដូច្នេះជំហរគឺមកពី Connects Orange របស់ពួកគេ? ..

  អ៊ីខេ៖ - បាទ។

  ក្នុង៖ - ប៉ុន្តែចុះយ៉ាងណាចំពោះករណីនេះ៖ ប្រសិនបើមជ្ឈមណ្ឌលទិន្នន័យរបស់អ្នកបាត់ តើអ្នកអាចបន្តប្រើប្រាស់វាដោយរបៀបណា? ឬ​ក៏​ស្ទះ​ចរាចរណ៍?

  អ៊ីខេ៖ - ទេ។ ក្នុងករណីនេះ យើងនឹងប្តូរចរាចរណ៍ទៅប៉ុស្តិ៍មួយផ្សេងទៀត ដែលតាមធម្មជាតិ វាមានតម្លៃថ្លៃជាងសម្រាប់យើង និងថ្លៃជាងសម្រាប់អតិថិជនរបស់យើង។ ប៉ុន្តែចរាចរណ៍នឹងមិនឆ្លងកាត់ការតភ្ជាប់ដោយផ្ទាល់របស់យើងទៅ Visa, MasterCard នោះទេ ប៉ុន្តែតាមរយៈ Sberbank ដែលមានលក្ខខណ្ឌ (និយាយបំផ្លើសខ្លាំង)។

  ខ្ញុំសុំទោសជាខ្លាំង ប្រសិនបើខ្ញុំធ្វើបាបបុគ្គលិក Sberbank ។ ប៉ុន្តែយោងទៅតាមស្ថិតិរបស់យើងក្នុងចំណោមធនាគាររុស្ស៊ី Sberbank ធ្លាក់ចុះញឹកញាប់បំផុត។ មួយខែមិនកន្លងផុតទៅដោយគ្មានអ្វីមួយធ្លាក់នៅ Sberbank ។

  
  
  

  ការផ្សាយពាណិជ្ជកម្មមួយចំនួន🙂

  សូមអរគុណចំពោះការស្នាក់នៅជាមួយពួកយើង។ តើអ្នកចូលចិត្តអត្ថបទរបស់យើងទេ? ចង់មើលខ្លឹមសារគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតទេ? គាំទ្រយើងដោយការបញ្ជាទិញឬណែនាំដល់មិត្តភក្តិ, cloud VPS សម្រាប់អ្នកអភិវឌ្ឍន៍ចាប់ពី $4.99, analogue តែមួយគត់នៃម៉ាស៊ីនមេកម្រិតធាតុ ដែលត្រូវបានបង្កើតឡើងដោយពួកយើងសម្រាប់អ្នក៖ ការពិតទាំងមូលអំពី VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ចាប់ពី $19 ឬរបៀបចែករំលែកម៉ាស៊ីនមេ? (អាចប្រើបានជាមួយ RAID1 និង RAID10 រហូតដល់ 24 cores និងរហូតដល់ 40GB DDR4)។

  Dell R730xd 2x ថោកជាងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ Equinix Tier IV នៅទីក្រុង Amsterdam? នៅទីនេះ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ចាប់ពី $199 នៅប្រទេសហូឡង់! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ចាប់ពី $99! អាន​អំពី របៀបបង្កើតក្រុមហ៊ុនហេដ្ឋារចនាសម្ព័ន្ធ ថ្នាក់ជាមួយនឹងការប្រើប្រាស់ម៉ាស៊ីនមេ Dell R730xd E5-2650 v4 ដែលមានតម្លៃ 9000 អឺរ៉ូសម្រាប់មួយកាក់?

ប្រភព: www.habr.com