ការធ្វើមាត្រដ្ឋានកម្មវិធីទូរស័ព្ទដោយមិនមានការគាំង៖ គន្លឹះពីអ្នកជំនាញ

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

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

តើ​ការ​ធ្វើ​មាត្រដ្ឋាន​កម្មវិធី​ទូរស័ព្ទ​ជា​អ្វី?

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

បញ្ជីត្រួតពិនិត្យ "ផែនការរហ័ស"

ផែនការរហ័សសម្រាប់ធ្វើមាត្រដ្ឋានកម្មវិធីទូរស័ព្ទដោយមិនមានការគាំង៖

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

តើ "ការធ្វើមាត្រដ្ឋានដោយគ្មានការគាំង" មានន័យយ៉ាងណា?

១. កំណត់ "មាត្រដ្ឋាន" ថាច្រើនជាងចរាចរណ៍

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

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

នៅពេលដែលអ្នកដាក់ឈ្មោះកម្លាំងទាំងនេះរួចហើយ អ្នកអាចរចនាជុំវិញពួកវាបាន។ អ្នកក៏ជៀសវាងអន្ទាក់នៃ "យើងបានបន្ថែមម៉ាស៊ីនមេ ហើយនៅតែគាំង"។

2. ប្រើប្រាស់ថវិកាកំហុសដើម្បីធ្វើឱ្យមានតុល្យភាពរវាងល្បឿន និងសុវត្ថិភាព

ក្រុមការងារច្រើនតែឈ្លោះប្រកែកគ្នាអំពីការចេញផ្សាយ។ ផលិតផលចង់បានល្បឿន។ វិស្វកម្មចង់បានស្ថេរភាព។ ថវិកាកំហុសកាត់បន្ថយជម្លោះនោះ ពីព្រោះវាបង្កើតតារាងពិន្ទុរួមមួយ៖ ផលប៉ះពាល់អ្នកប្រើប្រាស់។

ការណែនាំ SRE របស់ Google ចង្អុលបង្ហាញថាការផ្លាស់ប្តូរការជំរុញ ប្រហែល 70% នៃការដាច់ចរន្តអគ្គិសនីរបស់យើងដូច្នេះអ្នកគួរតែចាត់ទុកការចេញផ្សាយជាហានិភ័យនៃភាពជឿជាក់តាមលំនាំដើម។ នោះមិនមានន័យថាអ្នកគួរតែបញ្ឈប់ការដឹកជញ្ជូននោះទេ។ វាមានន័យថាអ្នកគួរតែដឹកជញ្ជូនជាមួយនឹងការគ្រប់គ្រង។

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

៣. រក្សាស្ថេរភាពទៅនឹងអ្វីដែលអ្នកប្រើប្រាស់មានអារម្មណ៍

អត្រាគាំង និងការបង្កកមានសារៈសំខាន់ ពីព្រោះអ្នកប្រើប្រាស់មានអារម្មណ៍ភ្លាមៗ។ វេទិកាហាងក៏តាមដានពួកវាផងដែរ។ ប្រសិនបើអ្នកបោះពុម្ពផ្សាយនៅលើ Google Play នោះ Android vitals ផ្តល់សញ្ញាគុណភាពច្បាស់លាស់។ ឧទាហរណ៍ Google បង្ហាញពីកម្រិតនៃអាកប្បកិរិយាមិនល្អជារួមនៃ អត្រាគាំងដែលអ្នកប្រើប្រាស់យល់ឃើញ ១,០៩%ដែលជួយអ្នកបកប្រែពាក្យ «ស្ថិរភាព» ទៅជាគោលដៅដែលអាចវាស់វែងបាន។

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

ការសិក្សាករណីខ្នាតតូចសម្រាប់ការធ្វើមាត្រដ្ឋានកម្មវិធីទូរស័ព្ទ

១. សេណារីយ៉ូ ក៖ សាកល្បងព្យុះម្តងទៀតបន្ទាប់ពីចរាចរណ៍កើនឡើងខ្លាំង

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

២. សេណារីយ៉ូ ខ៖ ការកើនឡើងយ៉ាងខ្លាំងនៃការធ្លាក់ចុះពីការផ្លាស់ប្តូរការឆ្លើយតប "តិចតួច"

ការអាប់ដេតកម្មវិធីខាងក្រោយបានបញ្ជូនវាលឆ្លើយតបជាទទេសម្រាប់អ្នកប្រើប្រាស់មួយចំនួនតូច។ កំណែកម្មវិធីចាស់ៗសន្មតថាវាលនេះតែងតែមានវត្តមាន ហើយគាំងអំឡុងពេលវិភាគ។ ការជួសជុលនេះបានរួមបញ្ចូលគ្នានូវការធ្វើតេស្តកិច្ចសន្យាផ្នែកម៉ាស៊ីនមេ ការវិភាគការពារផ្នែកអតិថិជន (លំនាំដើមដែលមានសុវត្ថិភាព) និងច្បាប់ភាពឆបគ្នា៖ ការផ្លាស់ប្តូរ API ត្រូវតែគាំទ្រកំណែកម្មវិធី N ចុងក្រោយរហូតដល់ការអនុម័តឈានដល់កម្រិតសុវត្ថិភាព។

៣. សេណារីយ៉ូ គ៖ ការតំរែតំរង់ភាពយឺតយ៉ាវត្រូវបានលាក់រហូតដល់ការដាក់ឱ្យប្រើប្រាស់ឈានដល់ 50%

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

៤. សេណារីយ៉ូ D៖ ចំណុចក្តៅមូលដ្ឋានទិន្នន័យបង្កើតភាពយឺតយ៉ាវនៃកម្មវិធី "ចៃដន្យ"

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

រចនា Backend សម្រាប់ Spikes មិនមែនសម្រាប់ Averages ទេ

១. ធ្វើឱ្យសេវាកម្មស្នូលរបស់អ្នកគ្មានរដ្ឋ និងអាចធ្វើមាត្រដ្ឋានផ្ដេកបាន

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

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

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

• ចូលចិត្តថូខឹនដែលមានអាយុកាលខ្លីជាងវគ្គស្អិត
• ប្រើរបាំងការពារដើម្បីញែកបន្ទុកការងារដែលមានហានិភ័យខ្ពស់
• ការពារផ្លូវសំខាន់ៗពីការងារ "ល្អដែលត្រូវមាន"

២. ចាត់ទុកស្រទាប់ទិន្នន័យជាផលិតផល មិនមែនជាព័ត៌មានលម្អិតទេ

កំណើនទូរស័ព្ទចល័តច្រើនតែបំបែកមូលដ្ឋានទិន្នន័យជាមុនសិន។ វាកើតឡើងដោយសារតែការអានពង្រីកលឿនជាងការរំពឹងទុក ហើយការសរសេរមកដល់ជាបណ្តើរៗ។ ដូច្នេះ អ្នកត្រូវការផែនការទិន្នន័យមុនពេលដែលអ្នកត្រូវការមាត្រដ្ឋាន។

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

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

៣. សន្មតថាប្រព័ន្ធភាគីទីបីនឹងបរាជ័យ ហើយរៀបចំផែនការសម្រាប់វា

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

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

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

ធ្វើឱ្យអតិថិជនទូរស័ព្ទចល័តមានភាពធន់ក្រោមលក្ខខណ្ឌពិភពលោកពិត

១. បង្កើតបណ្តាញដែលអាចរស់រានមានជីវិតពីការតភ្ជាប់មិនល្អ

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

ប្រើការព្យាយាមឡើងវិញដោយប្រុងប្រយ័ត្ន។ ការព្យាយាមឡើងវិញជួយសម្រាប់ការបរាជ័យបណ្តោះអាសន្ន ប៉ុន្តែពួកវាអាចបង្កើនបន្ទុកក្នុងអំឡុងពេលមានឧប្បត្តិហេតុ។ បន្ថែមភាពញ័រដើម្បីរាលដាលព្យុះនៃការព្យាយាមឡើងវិញ (spread retry storm)។ ទប់ស្កាត់ការប៉ុនប៉ងព្យាយាមឡើងវិញ។ ដូចគ្នានេះដែរ សូមព្យាយាមឡើងវិញតែនៅពេលដែលប្រតិបត្តិការមានសុវត្ថិភាពក្នុងការធ្វើម្តងទៀត។ សម្រាប់ប្រតិបត្តិការដែលមិនមានសុវត្ថិភាព សូមប្រើសោ idempotency ដើម្បីឱ្យម៉ាស៊ីនមេអាចលុបទិន្នន័យស្ទួនចេញ។

ជាចុងក្រោយ សូមចាត់ទុកការផ្អាកដំណើរការជាជម្រើសផលិតផល។ ការផ្អាកដំណើរការយូរអាចមានអារម្មណ៍ថា "អាចទុកចិត្តបាន" ប៉ុន្តែជារឿយៗវាបង្កើនការខកចិត្តរបស់អ្នកប្រើប្រាស់។ វាក៏បង្កើនសម្ពាធផ្នែកខាងក្រោយផងដែរ។ ជ្រើសរើសការផ្អាកដំណើរការដែលត្រូវនឹងចេតនារបស់អ្នកប្រើប្រាស់។ ឧទាហរណ៍ អ្នកប្រើប្រាស់អត់ធ្មត់នឹងការរង់ចាំយូរជាងមុនសម្រាប់ការផ្ទុកឡើងឯកសារជាងការបើកព័ត៌មាន។

2. បន្ថែមផ្លូវ Offline-First សម្រាប់លំហូរអ្នកប្រើប្រាស់សំខាន់ៗ

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

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

រក្សាការដោះស្រាយជម្លោះឱ្យសាមញ្ញ។ ចូលចិត្តព្រឹត្តិការណ៍ "append-only" និងការរួមបញ្ចូលគ្នានៅខាងម៉ាស៊ីនមេតាមដែលអាចធ្វើទៅបាន។ ប្រសិនបើអ្នកបង្ខំអ្នកប្រើប្រាស់ឱ្យដោះស្រាយជម្លោះស្មុគស្មាញ អ្នកនឹងបាត់បង់ទំនុកចិត្ត និងពេលវេលាគាំទ្រ។

៣. គ្រប់គ្រងអង្គចងចាំ ការចាប់ផ្តើម និងការងារផ្ទៃខាងក្រោយដូចជាថវិកា

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

កាត់បន្ថយការងារលើការបើកដំណើរការកម្មវិធី។ ពន្យារពេលការចាប់ផ្តើមដែលមិនចាំបាច់។ ផ្ទុក UI លឿន បន្ទាប់មកបន្ថែមទិន្នន័យ។ ដូចគ្នានេះដែរ រក្សាការគ្រប់គ្រងរូបភាពឱ្យមានវិន័យ។ ឌិគ្រីបរូបភាពធំៗចេញពីខ្សែស្រឡាយមេ។ ប្រើការ caching ដែលគោរពដែនកំណត់ឧបករណ៍។ នៅពេលអ្នកស្ទ្រីមមាតិកា សូមជ្រើសរើសយុទ្ធសាស្ត្រសម្របខ្លួនជាជាង "ទាញយកអ្វីគ្រប់យ៉ាងឥឡូវនេះ"។

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

វិស្វកម្មចេញផ្សាយដែលការពារឧប្បត្តិហេតុ "យប់ថ្ងៃសុក្រ"

១. ដឹកជញ្ជូនជាមួយការដឹកជញ្ជូនជឿនលឿន និងការត្រឡប់មកវិញលឿន

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

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

ជាងនេះទៅទៀត សូមរៀបចំផែនការ rollback មុនពេលអ្នកផ្ញើ។ សរសេរចុះនូវអត្ថន័យនៃ rollback សម្រាប់អតិថិជន ម៉ាស៊ីនមេ និងមូលដ្ឋានទិន្នន័យ។ ប្រសិនបើការធ្វើចំណាកស្រុក schema រារាំង rollback អ្នកត្រូវការយុទ្ធសាស្ត្រធ្វើចំណាកស្រុកដែលមានសុវត្ថិភាពជាង។

2. សាកល្បងប្រព័ន្ធ មិនមែនគ្រាន់តែសាកល្បងកូដនោះទេ

ការធ្វើតេស្តឯកតាការពារតក្កវិជ្ជា។ ពួកវាមិនការពារប្រព័ន្ធផលិតកម្មទេ។ ការធ្វើមាត្រដ្ឋានកម្មវិធីទូរស័ព្ទដោយសុវត្ថិភាពតម្រូវឱ្យមានការធ្វើតេស្តកម្រិតប្រព័ន្ធដែលឆ្លុះបញ្ចាំងពីការរឹតបន្តឹងពិតប្រាកដ។

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

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

៣. គោរពការពិតនៃការពិនិត្យហាង និងការរំពឹងទុកនៃការគាំង

ហាងកម្មវិធីដើរតួជាអ្នកយាមទ្វារ។ ពួកគេផ្តល់រង្វាន់ដល់ស្ថិរភាព និងដាក់ទណ្ឌកម្មចំពោះការបែកបាក់ជាក់ស្តែង។ របាយការណ៍តម្លាភាពរបស់ Apple បង្ហាញពីទំហំនៃបំពង់ពិនិត្យឡើងវិញនោះ រួមទាំង បានពិនិត្យការដាក់ស្នើកម្មវិធីចំនួន 7,771,599 ដងដូច្នេះអ្នកគួរតែសន្មតថាការសាងសង់របស់អ្នកត្រូវមានឥរិយាបថល្អក្រោមការត្រួតពិនិត្យយ៉ាងម៉ត់ចត់។

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

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

ភាពអាចសង្កេតបាន និងការឆ្លើយតបនៃឧប្បត្តិហេតុដែលបិទរង្វិលជុំ

១. តាមដានដំណើររបស់អ្នកប្រើប្រាស់ មិនមែនគ្រាន់តែតារាងម៉ាស៊ីនបម្រើនោះទេ

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

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

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

២. ដំណើរការឧប្បត្តិហេតុជាមួយនឹងតួនាទីច្បាស់លាស់ និងសៀវភៅណែនាំសាមញ្ញៗ

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

សរសេរសៀវភៅណែនាំសម្រាប់ការបរាជ័យទូទៅបំផុតរបស់អ្នក។ សរសេរវាឱ្យខ្លី។ រួមបញ្ចូលការត្រួតពិនិត្យលឿនបំផុតជាមុនសិន។ ឧទាហរណ៍ "តើការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវមិនដំណើរការទេ?" "តើការផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធថ្មីៗនេះត្រូវបានបញ្ជូនទេ?" "តើការពឹងផ្អែកអស់ពេលហើយឬនៅ?" បន្ទាប់មករួមបញ្ចូលជំហានកាត់បន្ថយសុវត្ថិភាពដូចជាការបិទទង់លក្ខណៈពិសេស ការធ្វើមាត្រដ្ឋានសេវាកម្ម ឬការបង្ហូរការដាក់ពង្រាយមិនល្អ។

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

៣. ចាត់ទុកការស្លាប់ក្រោយការស្លាប់ជាវដ្តកែលម្អផលិតផល

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

ទិន្នន័យឧស្សាហកម្មបានពង្រឹងហានិភ័យ។ វិទ្យាស្ថាន Uptime រាយការណ៍ថា អ្នកឆ្លើយតបចំនួន 54% នៃការស្ទង់មតិប្រចាំឆ្នាំរបស់ Uptime និយាយថា ការដាច់ចរន្តអគ្គិសនីដ៏សំខាន់បំផុតរបស់ពួកគេបានធ្វើឱ្យខាតបង់ជាង 100,000 ដុល្លារ។ដែលធ្វើឱ្យភាពជឿជាក់ក្លាយជាបញ្ហាអាជីវកម្ម មិនមែនគ្រាន់តែជាចំណង់ចំណូលចិត្តផ្នែកវិស្វកម្មនោះទេ។

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

ការពង្រីកក្រុមវេទិកា និងឧបករណ៍

១. ធ្វើឱ្យវេទិកាពេលដំណើរការរបស់អ្នកមានស្តង់ដារដើម្បីកាត់បន្ថយភាពខុសគ្នា

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

អង្គការជាច្រើនឥឡូវនេះពឹងផ្អែកលើវេទិកាកុងតឺន័រសម្រាប់ការធ្វើស្តង់ដារនីយកម្មនោះ។ ការស្រាវជ្រាវរបស់ CNCF បានបង្ហាញពីរបៀបដែលរឿងនេះបានក្លាយជារឿងធម្មតា ៨០% នៃអង្គការដែលកំពុងដំណើរការ Kubernetes ក្នុងផលិតកម្មដែលបង្ហាញថាក្រុមការងារឱ្យតម្លៃលើការរៀបចំ និងស្វ័យប្រវត្តិកម្មដ៏ស៊ីសង្វាក់គ្នាក្នុងទ្រង់ទ្រាយធំ។

ប្រសិនបើអ្នកមិនដំណើរការ Kubernetes ទេ មេរៀននៅតែអាចអនុវត្តបាន។ ធ្វើឱ្យការដាក់ពង្រាយ ការកំណត់រចនាសម្ព័ន្ធ ការដោះស្រាយអាថ៌កំបាំង និងលទ្ធភាពសង្កេតមានលក្ខណៈស្តង់ដារ។ ធ្វើឱ្យផ្លូវក្រាលកៅស៊ូមានភាពងាយស្រួល។ បន្ទាប់មកក្រុមនានានឹងធ្វើតាមវា។

២. បង្កើតវេទិកាអ្នកអភិវឌ្ឍន៍ផ្ទៃក្នុងដែលបង្កើនល្បឿនការងារប្រកបដោយសុវត្ថិភាព

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

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

ជាងនេះទៅទៀត ចូរចាត់ទុក “បទពិសោធន៍អ្នកប្រើប្រាស់លើវេទិកា” ឲ្យបានម៉ត់ចត់។ ប្រសិនបើវេទិកាមានអារម្មណ៍ថាយឺត ឬរឹតត្បិត ក្រុមការងារនឹងរំលងវា។ ដូច្នេះ ចូរវិនិយោគលើឯកសារ ឧទាហរណ៍ និងរង្វិលជុំមតិប្រតិកម្មរហ័ស។ ក្រុមការងារវេទិកាទទួលបានជោគជ័យ នៅពេលដែលក្រុមផលិតផលដំណើរការលឿនជាងមុន ជាមួយនឹងឧប្បត្តិហេតុតិចជាងមុន។

៣. ភ្ជាប់ភាពជឿជាក់ទៅនឹងយុទ្ធសាស្ត្រចំណូលដោយគ្មានការភ័យខ្លាច

ការពិភាក្សាអំពីភាពជឿជាក់ជារឿយៗជាប់គាំងព្រោះវាស្តាប់ទៅដូចជាអរូបី។ ភ្ជាប់វាទៅនឹងលទ្ធផលពិតប្រាកដវិញ។ សម្រាប់កម្មវិធីអ្នកប្រើប្រាស់ ទិន្នន័យប្រាក់ចំណូលបង្ហាញពីអ្វីដែលស្ថេរភាពការពារ។ របាយការណ៍របស់ Sensor Tower $ 150 កោដិដុល្លារក្នុង 2024 នៅក្នុងប្រាក់ចំណូលពីការទិញក្នុងកម្មវិធីទូទាំងពិភពលោកនៅទូទាំងហាងកម្មវិធីធំៗ ដែលបង្ហាញពីចំនួនទឹកប្រាក់ដែលអាស្រ័យលើបទពិសោធន៍ទូរស័ព្ទចល័តដែលមានស្ថេរភាព។

សូមប្រើប្រាស់​ស៊ុម​នោះ​ដោយប្រុងប្រយ័ត្ន។ កុំ​បំភ័យ​ក្រុម។ ផ្ទុយទៅវិញ ចូរ​បង្ហាញ​ពី​ការ​សម្របសម្រួល។ ពន្យល់​ពី​របៀប​ដែល​ការ​គាំង​ក្នុង​ការ​ចាប់ផ្តើម​ការងារ​កាត់បន្ថយ​ការ​ធ្វើឱ្យ​សកម្ម របៀប​ដែល​ការ​ទូទាត់​ប្រាក់​យឺត​កាត់បន្ថយ​ការបម្លែង និង​របៀប​ដែល​ការ​ដាច់​ចរន្ត​អគ្គិសនី​ប៉ះពាល់​ដល់​ការទុកចិត្ត។ បន្ទាប់មក​ផ្តល់​មូលនិធិ​ដល់​ការងារ​ដែល​ការពារ​លទ្ធផល​ទាំងនោះ។

នៅពេលដែលអ្នកផ្គូផ្គងស្ថិរភាពជាមួយនឹងភាពជោគជ័យនៃផលិតផល ផែនទីបង្ហាញផ្លូវនៃភាពជឿជាក់នឹងលែងមានអារម្មណ៍ដូចជាពន្ធដារទៀតហើយ។ វាក្លាយជាផ្នែកមួយនៃការរីកចម្រើន។

សំណួរដែលសួរជាញឹកញាប់

១. តើការធ្វើមាត្រដ្ឋានកម្មវិធីទូរស័ព្ទមានន័យយ៉ាងណានៅក្នុងការអនុវត្ត?

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

2. តើ​ម៉ែត្រ​ណា​ខ្លះ​ដែល​បង្ហាញ​បាន​ល្អ​បំផុត​ថា​អ្នក​កំពុង​ធ្វើ​មាត្រដ្ឋាន​ដោយ​សុវត្ថិភាព?

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

៣. តើ​អ្វី​ដែល​ជា​ធម្មតា​ខូច​មុន​គេ​នៅ​ពេល​ដែល​កម្មវិធី​ទូរស័ព្ទ​មាន​ទំហំ​ធំ?

ក្រុមភាគច្រើនជួបប្រទះនឹងបញ្ហាកកស្ទះទាក់ទងនឹងភាពជឿជាក់នៃការពឹងផ្អែក (API ភាគីទីបី) ចំណុចក្តៅមូលដ្ឋានទិន្នន័យ ការព្យាយាមឡើងវិញគ្មានដែនកំណត់ សម្ពាធអង្គចងចាំលើឧបករណ៍កម្រិតមធ្យម និងភាពមិនឆបគ្នានៃការដាក់ឱ្យប្រើប្រាស់រវាងកំណែកម្មវិធី និងការផ្លាស់ប្តូរផ្នែកខាងក្រោយ។

៤. តើអ្នកជៀសវាងការបរាជ័យ "ដំណើរការលើ Wi-Fi" ក្នុងទ្រង់ទ្រាយធំដោយរបៀបណា?

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

៥. តើអ្នកត្រូវការ Kubernetes ដើម្បីធ្វើមាត្រដ្ឋានកម្មវិធីទូរស័ព្ទដែរឬទេ?

ទេ។ កម្មវិធីជាច្រើនធ្វើមាត្រដ្ឋានបានល្អជាមួយនឹងសេវាកម្មដែលបានគ្រប់គ្រងដ៏សាមញ្ញ ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ ជួរ ការរក្សាទុកក្នុងឃ្លាំងសម្ងាត់ និងការអនុវត្តការចេញផ្សាយល្អ។ ការរៀបចំកុងតឺន័រ អាចជួយនៅពេលក្រោយ ប៉ុន្តែការកែលម្អភាពជឿជាក់ និងភាពអាចសង្កេតបានច្រើនតែផ្តល់ជ័យជម្នះធំជាងមុន។

ស្វែងយល់ពីសេវាកម្មរបស់យើង។

ប្រើប្រាស់ជំនាញ Cloud Computing ដ៏រឹងមាំរបស់ 1Byte ដើម្បីជំរុញអាជីវកម្មរបស់អ្នកតាមរបៀបដ៏ធំមួយ

Domains

1Byte ផ្តល់ពេញលេញ domain សេវាកម្មចុះឈ្មោះដែលរួមមានបុគ្គលិកគាំទ្រដោយយកចិត្តទុកដាក់ ការថែទាំអតិថិជនដែលមានការអប់រំ ការចំណាយសមរម្យ ក៏ដូចជា ក domain ឧបករណ៍ស្វែងរកតម្លៃ។

ឈ្មោះដែន

វិញ្ញាបនបត្រ SSL

បង្កើនសុវត្ថិភាពលើអ៊ីនធឺណិតរបស់អ្នកជាមួយនឹងសេវាកម្ម SSL របស់ 1Byte ។ ការការពារដែលមិនអាចប្រៀបផ្ទឹមបាន ការរួមបញ្ចូលដោយគ្មានថ្នេរ និងសន្តិភាពនៃចិត្តសម្រាប់ដំណើរឌីជីថលរបស់អ្នក។

វិញ្ញាបនបត្រ SSL

Cloud Server

មិនថា cloud server កញ្ចប់ដែលអ្នកជ្រើសរើស អ្នកអាចពឹងផ្អែកលើ 1Byte សម្រាប់ភាពជឿជាក់ ភាពឯកជន សុវត្ថិភាព និងបទពិសោធន៍គ្មានភាពតានតឹង ដែលមានសារៈសំខាន់សម្រាប់អាជីវកម្មជោគជ័យ។

សេវាកម្ម Cloud Server

Shared Hosting

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

បង្ហោះចែករំលែក

Cloud Hosting

តាមរយៈកម្មវិធីដែលមានភាពបត់បែនខ្ពស់ 1Byte ដ៏ទំនើប cloud hosting ផ្តល់ដំណោះស្រាយដ៏អស្ចារ្យដល់អាជីវកម្មខ្នាតតូច និងមធ្យមលឿនជាងមុន សុវត្ថិភាពជាងមុន និងក្នុងតម្លៃកាត់បន្ថយ។

សេវាកម្ម Cloud Hosting

WordPress Hosting

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

WordPress Hosting

ភាពជាដៃគូ AWS

ក្នុងនាមជាដៃគូ AWS ផ្លូវការ ទំនួលខុសត្រូវចម្បងមួយរបស់យើងគឺជួយអាជីវកម្មក្នុងការធ្វើទំនើបកម្មប្រតិបត្តិការរបស់ពួកគេ និងប្រើប្រាស់ច្រើនបំផុតក្នុងការធ្វើដំណើររបស់ពួកគេទៅកាន់ពពកជាមួយ AWS ។

សេវាកម្ម AWS

សន្និដ្ឋាន

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

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