Bitrix24: "អ្វីដែលត្រូវបានលើកឡើងយ៉ាងឆាប់រហ័សមិនត្រូវបានចាត់ទុកថាត្រូវបានធ្លាក់ចុះ"

សព្វថ្ងៃនេះ សេវា Bitrix24 មិនមានចរាចរណ៍រាប់រយជីហ្គាបៃទេ ហើយក៏មិនមានម៉ាស៊ីនមេដ៏ធំដែរ (ទោះបីជាការពិតមានមួយចំនួនដែលមានស្រាប់ក៏ដោយ)។ ប៉ុន្តែសម្រាប់អតិថិជនជាច្រើន វាគឺជាឧបករណ៍សំខាន់សម្រាប់ធ្វើការនៅក្នុងក្រុមហ៊ុន វាគឺជាកម្មវិធីដ៏សំខាន់សម្រាប់អាជីវកម្មពិតប្រាកដ។ ដូច្នេះ​ហើយ​គ្មាន​ផ្លូវ​ធ្លាក់​ទេ។ ចុះ​បើ​ការ​គាំង​បាន​កើត​ឡើង ប៉ុន្តែ​សេវា "បាន​សង្គ្រោះ" យ៉ាង​លឿន​ដែល​គ្មាន​អ្នក​ណា​កត់​សម្គាល់​អ្វី​នោះ? ហើយតើអាចអនុវត្តការបរាជ័យដោយមិនបាត់បង់គុណភាពការងារ និងចំនួនអតិថិជនដោយរបៀបណា? Alexander Demidov នាយកសេវាកម្មពពកនៅ Bitrix24 បាននិយាយសម្រាប់ប្លុករបស់យើងអំពីរបៀបដែលប្រព័ន្ធកក់ទុកបានវិវត្តក្នុងរយៈពេល 7 ឆ្នាំនៃអត្ថិភាពរបស់ផលិតផល។

"យើងបានបើកដំណើរការ Bitrix24 ជា SaaS កាលពី 7 ឆ្នាំមុន។ ការលំបាកចម្បងគឺប្រហែលជាមានដូចខាងក្រោម៖ មុនពេលដែលវាត្រូវបានដាក់ឱ្យដំណើរការជាសាធារណៈក្នុងនាមជា SaaS ផលិតផលនេះមាននៅក្នុងទម្រង់នៃដំណោះស្រាយប្រអប់។ អតិថិជនបានទិញវាពីយើង បង្ហោះវានៅលើម៉ាស៊ីនមេរបស់ពួកគេ រៀបចំវិបផតថលសាជីវកម្ម - ដំណោះស្រាយទូទៅសម្រាប់ការទំនាក់ទំនងបុគ្គលិក ការផ្ទុកឯកសារ ការគ្រប់គ្រងកិច្ចការ CRM នោះជាអ្វីទាំងអស់។ ហើយនៅឆ្នាំ 2012 យើងបានសម្រេចចិត្តថាយើងចង់ដាក់ឱ្យដំណើរការវាជា SaaS ដោយគ្រប់គ្រងវាដោយខ្លួនឯង ធានានូវភាពអត់ធ្មត់ និងភាពជឿជាក់នៃកំហុស។ យើងទទួលបានបទពិសោធន៍តាមផ្លូវ ព្រោះរហូតមកដល់ពេលនោះ យើងមិនមានវាទេ យើងគ្រាន់តែជាអ្នកផលិតកម្មវិធីប៉ុណ្ណោះ មិនមែនជាអ្នកផ្តល់សេវានោះទេ។

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

Bitrix.24 ជា SaaS

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

កម្មវិធីគេហទំព័រធម្មតានៅពេលនោះគឺជាម៉ាស៊ីនមេមួយ ដែលកូដ PHP ខ្លះដំណើរការ មូលដ្ឋានទិន្នន័យ mysql ឯកសារត្រូវបានផ្ទុកឡើង ឯកសារ រូបភាពត្រូវបានដាក់ក្នុងថតផ្ទុកឡើង - ល្អ វាដំណើរការទាំងអស់។ Alas, វាមិនអាចទៅរួចទេក្នុងការបើកដំណើរការសេវាកម្មគេហទំព័រដែលមានស្ថេរភាពខ្លាំងដោយប្រើវា។ នៅទីនោះ ឃ្លាំងសម្ងាត់ដែលបានចែកចាយមិនត្រូវបានគាំទ្រទេ ការចម្លងមូលដ្ឋានទិន្នន័យមិនត្រូវបានគាំទ្រទេ។

យើងបានបង្កើតតម្រូវការ៖ នេះគឺជាលទ្ធភាពដែលមានទីតាំងនៅទីតាំងផ្សេងៗគ្នា គាំទ្រការចម្លង ហើយតាមឧត្ដមគតិមានទីតាំងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យដែលបានចែកចាយតាមភូមិសាស្រ្តផ្សេងៗគ្នា។ បំបែកតក្កវិជ្ជាផលិតផល និងតាមការពិត ការផ្ទុកទិន្នន័យ។ អាច​ធ្វើ​មាត្រដ្ឋាន​ថាមវន្ត​ដោយ​យោង​ទៅ​តាម​បន្ទុក និង​អាច​ទ្រាំទ្រ​នឹង​ឋិតិវន្ត​បាន​ទាំង​ស្រុង។ ពីការពិចារណាទាំងនេះ តាមពិតតម្រូវការសម្រាប់ផលិតផលបានលេចចេញមក ដែលយើងចម្រាញ់ពេញមួយឆ្នាំ។ ក្នុងអំឡុងពេលនេះ នៅក្នុងវេទិកាដែលប្រែទៅជាការបង្រួបបង្រួម - សម្រាប់ដំណោះស្រាយប្រអប់សម្រាប់សេវាកម្មផ្ទាល់ខ្លួនរបស់យើង - យើងបានធ្វើការគាំទ្រសម្រាប់អ្វីដែលយើងត្រូវការ។ ការគាំទ្រសម្រាប់ការចម្លង mysql នៅកម្រិតនៃផលិតផលខ្លួនវា: នោះគឺអ្នកអភិវឌ្ឍន៍ដែលសរសេរកូដមិនគិតពីរបៀបដែលសំណើរបស់គាត់នឹងត្រូវបានចែកចាយគាត់ប្រើ api របស់យើងហើយយើងដឹងពីរបៀបចែកចាយការសរសេរនិងអានសំណើរវាងចៅហ្វាយនាយឱ្យបានត្រឹមត្រូវ។ និងទាសករ។

យើងបានធ្វើការគាំទ្រនៅកម្រិតផលិតផលសម្រាប់ការផ្ទុកវត្ថុពពកផ្សេងៗ៖ ឃ្លាំងផ្ទុកទិន្នន័យ google, Amazon s3 បូករួមទាំងការគាំទ្រសម្រាប់ការបើកជង់រហ័ស។ ដូច្នេះ វាងាយស្រួលសម្រាប់យើងជាសេវាកម្ម និងអ្នកអភិវឌ្ឍន៍ដែលធ្វើការជាមួយដំណោះស្រាយកញ្ចប់៖ ប្រសិនបើពួកគេគ្រាន់តែប្រើ API របស់យើងសម្រាប់ការងារ ពួកគេមិនគិតពីកន្លែងដែលឯកសារនឹងត្រូវរក្សាទុកនៅទីបំផុតនៅលើប្រព័ន្ធឯកសារ ឬ នៅក្នុងកន្លែងផ្ទុកឯកសារវត្ថុ។

ជាលទ្ធផល យើងបានសម្រេចចិត្តភ្លាមៗថា យើងនឹងកក់ទុកនៅកម្រិតនៃមជ្ឈមណ្ឌលទិន្នន័យទាំងមូល។ ក្នុងឆ្នាំ 2012 យើងបានបើកដំណើរការទាំងស្រុងនៅលើ Amazon AWS ដោយសារតែយើងមានបទពិសោធន៍ជាមួយវេទិកានេះរួចហើយ គេហទំព័ររបស់យើងផ្ទាល់ត្រូវបានបង្ហោះនៅទីនោះ។ យើងត្រូវបានគេទាក់ទាញដោយការពិតដែលថានៅក្នុងតំបន់នីមួយៗ Amazon មានតំបន់ដែលអាចរកបានជាច្រើន - តាមពិត (នៅក្នុងវាក្យស័ព្ទរបស់ពួកគេ) មជ្ឈមណ្ឌលទិន្នន័យជាច្រើនដែលមានភាពឯករាជ្យតិចឬច្រើនពីគ្នាទៅវិញទៅមកហើយអនុញ្ញាតឱ្យយើងកក់ទុកនៅកម្រិតនៃមជ្ឈមណ្ឌលទិន្នន័យទាំងមូល: ប្រសិនបើភ្លាមៗនោះវាបរាជ័យ មូលដ្ឋានទិន្នន័យត្រូវបានចម្លង master-master ម៉ាស៊ីនមេកម្មវិធីបណ្តាញត្រូវបានបម្រុងទុក ហើយទិន្នន័យឋិតិវន្តត្រូវបានផ្លាស់ទីទៅកន្លែងផ្ទុកវត្ថុ s3 ។ បន្ទុកមានតុល្យភាព - នៅពេលនោះដោយ Amazon elb ប៉ុន្តែបន្តិចក្រោយមក យើងបានមករកតុល្យភាពបន្ទុករបស់យើង ពីព្រោះយើងត្រូវការតក្កវិជ្ជាស្មុគស្មាញបន្ថែមទៀត។

អ្វី​ដែល​ពួក​គេ​ចង់​បាន​គឺ​ជា​អ្វី​ដែល​ពួក​គេ​បាន​ទទួល...

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

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

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

តើវាដំណើរការយ៉ាងដូចម្តេច? - យើងប្តូរចរាចរណ៍ទៅមជ្ឈមណ្ឌលទិន្នន័យដែលកំពុងដំណើរការ - ប្រសិនបើមានឧបទ្ទវហេតុនៅមជ្ឈមណ្ឌលទិន្នន័យ នោះទាំងស្រុង ប្រសិនបើនេះជាការងារដែលបានគ្រោងទុករបស់យើងជាមួយមូលដ្ឋានទិន្នន័យមួយ នោះយើងប្តូរផ្នែកនៃចរាចរដែលបម្រើអតិថិជនទាំងនេះទៅមជ្ឈមណ្ឌលទិន្នន័យទីពីរ ដោយផ្អាក។ វាចម្លង។ ប្រសិនបើម៉ាស៊ីនថ្មីត្រូវការសម្រាប់កម្មវិធីបណ្តាញ ដោយសារការផ្ទុកនៅលើមជ្ឈមណ្ឌលទិន្នន័យទីពីរបានកើនឡើង ពួកគេនឹងចាប់ផ្តើមដោយស្វ័យប្រវត្តិ។ យើងបញ្ចប់ការងារ ការចម្លងត្រូវបានស្ដារឡើងវិញ ហើយយើងប្រគល់បន្ទុកទាំងមូលមកវិញ។ ប្រសិនបើយើងត្រូវការឆ្លុះមើលការងារមួយចំនួននៅក្នុង DC ទីពីរ ឧទាហរណ៍ ដំឡើងការអាប់ដេតប្រព័ន្ធ ឬផ្លាស់ប្តូរការកំណត់នៅក្នុងមូលដ្ឋានទិន្នន័យទីពីរ នោះជាទូទៅ យើងធ្វើរឿងដដែលនេះឡើងវិញក្នុងទិសដៅផ្សេងទៀត។ ហើយប្រសិនបើនេះជាឧប្បត្តិហេតុមួយ នោះយើងធ្វើអ្វីៗគ្រប់យ៉ាងដោយអចេតនា៖ យើងប្រើយន្តការដោះស្រាយព្រឹត្តិការណ៍នៅក្នុងប្រព័ន្ធត្រួតពិនិត្យ។ ប្រសិនបើការត្រួតពិនិត្យជាច្រើនត្រូវបានកេះ ហើយស្ថានភាពទៅជាសំខាន់ នោះយើងដំណើរការកម្មវិធីគ្រប់គ្រងនេះ ដែលជាឧបករណ៍ដោះស្រាយដែលអាចប្រតិបត្តិនេះ ឬតក្កវិជ្ជានោះ។ សម្រាប់មូលដ្ឋានទិន្នន័យនីមួយៗ យើងបញ្ជាក់ថាតើម៉ាស៊ីនមេមួយណាដែលបរាជ័យសម្រាប់វា ហើយកន្លែងដែលចរាចរណ៍ត្រូវប្តូរប្រសិនបើវាមិនអាចប្រើបាន។ ជាប្រវត្តិសាស្ត្រ យើងប្រើ nagios ឬសមខ្លះរបស់វាក្នុងទម្រង់មួយ ឬមួយផ្សេងទៀត។ ជាគោលការណ៍ យន្តការស្រដៀងគ្នាមាននៅក្នុងប្រព័ន្ធត្រួតពិនិត្យស្ទើរតែទាំងអស់ យើងមិនប្រើអ្វីដែលស្មុគស្មាញជាងនេះទេ ប៉ុន្តែប្រហែលជាថ្ងៃណាមួយយើងនឹង។ ឥឡូវនេះ ការត្រួតពិនិត្យត្រូវបានបង្កឡើងដោយភាពមិនមាន ហើយមានលទ្ធភាពផ្លាស់ប្តូរអ្វីមួយ។

តើ​យើង​បាន​កក់​ទុក​គ្រប់​យ៉ាង​ហើយ​ឬ​នៅ?

យើងមានអតិថិជនជាច្រើនមកពីសហរដ្ឋអាមេរិក អតិថិជនជាច្រើនមកពីអឺរ៉ុប អតិថិជនជាច្រើនដែលនៅជិតបូព៌ា - ជប៉ុន សិង្ហបុរី និងផ្សេងៗទៀត។ ជាការពិតណាស់ចំណែកដ៏ធំនៃអតិថិជនគឺនៅក្នុងប្រទេសរុស្ស៊ី។ នោះ​គឺ​ការងារ​មិន​ស្ថិត​នៅ​ក្នុង​តំបន់​មួយ​ទេ។ អ្នក​ប្រើ​ចង់​បាន​ការ​ឆ្លើយ​តប​រហ័ស មាន​តម្រូវ​ការ​ដើម្បី​អនុលោម​តាម​ច្បាប់​ក្នុង​តំបន់​ផ្សេង​ៗ ហើយ​ក្នុង​តំបន់​នីមួយៗ យើង​បម្រុង​ទុក​មជ្ឈមណ្ឌល​ទិន្នន័យ​ពីរ បូក​រួម​ទាំង​មាន​សេវាកម្ម​បន្ថែម​មួយ​ចំនួន​ទៀត ដែល​ជា​ការ​ងាយ​ស្រួល​ក្នុង​ការ​ដាក់​នៅ​ក្នុង​តំបន់​មួយ - សម្រាប់​អតិថិជន​ដែល​នៅ​ក្នុង តំបន់នេះកំពុងដំណើរការ។ REST handlers, authorization servers ពួកវាមិនសូវសំខាន់សម្រាប់ប្រតិបត្តិការរបស់អតិថិជនទាំងមូលទេ អ្នកអាចប្តូរតាមរយៈពួកវាជាមួយនឹងការពន្យាពេលដែលអាចទទួលយកបានតិចតួច ប៉ុន្តែអ្នកមិនចង់បង្កើតកង់ឡើងវិញអំពីរបៀបត្រួតពិនិត្យពួកវា និងអ្វីដែលត្រូវធ្វើ ជាមួយ​ពូក​គេ។ ដូច្នេះហើយ យើងកំពុងព្យាយាមប្រើប្រាស់ដំណោះស្រាយដែលមានស្រាប់ដល់កម្រិតអតិបរមា ជាជាងអភិវឌ្ឍសមត្ថភាពមួយចំនួននៅក្នុងផលិតផលបន្ថែម។ ហើយនៅកន្លែងណាមួយដែលយើងប្រើការប្តូរនៅកម្រិត DNS ហើយយើងកំណត់ភាពរស់រវើកនៃសេវាកម្មដោយ DNS ដូចគ្នា។ Amazon មានសេវា Route 53 ប៉ុន្តែវាមិនមែនគ្រាន់តែជា DNS ដែលអ្នកអាចធ្វើការបញ្ចូលទេ ហើយនោះហើយជាវា - វាមានភាពបត់បែន និងងាយស្រួលជាង។ តាមរយៈវា អ្នកអាចបង្កើតសេវាកម្មចែកចាយតាមភូមិសាស្ត្រជាមួយនឹងទីតាំងភូមិសាស្ត្រ នៅពេលដែលអ្នកប្រើវាដើម្បីកំណត់កន្លែងដែលអតិថិជនមកពីណា ហើយផ្តល់ឱ្យគាត់នូវកំណត់ត្រាជាក់លាក់មួយ - ដោយមានជំនួយរបស់វា អ្នកអាចបង្កើតស្ថាបត្យកម្មបរាជ័យ។ ការត្រួតពិនិត្យសុខភាពដូចគ្នាត្រូវបានកំណត់រចនាសម្ព័ន្ធនៅក្នុងផ្លូវលេខ 53 ដោយខ្លួនឯង អ្នកកំណត់ចំណុចបញ្ចប់ដែលត្រូវបានត្រួតពិនិត្យ កំណត់ម៉ែត្រ កំណត់ពិធីការណាមួយដើម្បីកំណត់ "ភាពរស់រវើក" នៃសេវាកម្ម - tcp, http, https; កំណត់ភាពញឹកញាប់នៃការត្រួតពិនិត្យដែលកំណត់ថាតើសេវាកម្មនេះនៅរស់ឬអត់។ ហើយនៅក្នុង DNS ខ្លួនវាផ្ទាល់ អ្នកបញ្ជាក់អ្វីដែលនឹងជាបឋម អ្វីដែលជាបន្ទាប់បន្សំ កន្លែងដែលត្រូវប្តូរ ប្រសិនបើការពិនិត្យសុខភាពត្រូវបានបង្កឡើងនៅក្នុងផ្លូវលេខ 53។ ទាំងអស់នេះអាចត្រូវបានធ្វើជាមួយឧបករណ៍មួយចំនួនផ្សេងទៀត ប៉ុន្តែហេតុអ្វីបានជាវាងាយស្រួល - យើងកំណត់វា ឡើងម្តង ហើយបន្ទាប់មកកុំគិតពីវាទាល់តែសោះពីរបៀបដែលយើងធ្វើការត្រួតពិនិត្យ របៀបដែលយើងប្តូរ៖ អ្វីៗដំណើរការដោយខ្លួនឯង។

ទីមួយ "ប៉ុន្តែ"៖ តើត្រូវកក់ផ្លូវលេខ ៥៣ ដោយរបៀបណា? អ្នកណាដឹង ចុះបើមានអ្វីកើតឡើងចំពោះគាត់? ជាសំណាងល្អ យើងមិនដែលដើរលើតុងរួចនេះទេ ប៉ុន្តែម្តងទៀត ខ្ញុំនឹងប្រាប់រឿងមួយជាមុនអំពីមូលហេតុដែលយើងគិតថាយើងនៅតែត្រូវការកក់ទុក។ នៅទីនេះយើងបានដាក់ចំបើងសម្រាប់ខ្លួនយើងជាមុន។ ជាច្រើនដងក្នុងមួយថ្ងៃ យើងធ្វើការដកទាំងស្រុងនៃតំបន់ទាំងអស់ដែលយើងមាននៅក្នុងផ្លូវលេខ 53 ។ API របស់ Amazon អនុញ្ញាតឱ្យអ្នកងាយស្រួលផ្ញើពួកវានៅក្នុង JSON ហើយយើងមានម៉ាស៊ីនមេបម្រុងទុកជាច្រើនដែលយើងបំលែងវា ផ្ទុកវាឡើងក្នុងទម្រង់នៃការកំណត់ ហើយមានការកំណត់រចនាសម្ព័ន្ធបម្រុងទុក។ ប្រសិនបើមានអ្វីមួយកើតឡើង យើងអាចដាក់ពង្រាយវាដោយដៃបានយ៉ាងរហ័សដោយមិនបាត់បង់ទិន្នន័យការកំណត់ DNS ។

ទីពីរ "ប៉ុន្តែ"៖ អ្វី​ដែល​ក្នុង​រូប​នេះ​មិន​ទាន់​បាន​បម្រុង? តុល្យភាពខ្លួនឯង! ការចែកចាយអតិថិជនរបស់យើងតាមតំបន់គឺសាមញ្ញណាស់។ យើងមានដែន bitrix24.ru, bitrix24.com, .de - ឥឡូវនេះមាន 13 ផ្សេងគ្នា ដែលដំណើរការនៅក្នុងតំបន់ផ្សេងៗគ្នា។ យើងបានមកដល់ដូចខាងក្រោម៖ តំបន់នីមួយៗមានតុល្យភាពផ្ទាល់ខ្លួន។ នេះធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការចែកចាយនៅទូទាំងតំបន់ អាស្រ័យលើកន្លែងដែលការផ្ទុកខ្ពស់បំផុតនៅលើបណ្តាញ។ ប្រសិនបើនេះគឺជាការបរាជ័យនៅកម្រិតនៃសមតុល្យតែមួយ នោះវាត្រូវបានដកចេញពីសេវាកម្ម ហើយដកចេញពី dns ។ ប្រសិនបើមានបញ្ហាខ្លះជាមួយក្រុមសមតុល្យ នោះពួកគេត្រូវបានបម្រុងទុកនៅលើគេហទំព័រផ្សេងទៀត ហើយការប្តូររវាងពួកវាត្រូវបានធ្វើដោយប្រើផ្លូវដូចគ្នា 53 ពីព្រោះដោយសារ TTL ខ្លី ការប្តូរកើតឡើងក្នុងរយៈពេលអតិបរមា 2, 3, 5 នាទី .

ទីបី "ប៉ុន្តែ"៖ អ្វី​ដែល​មិន​ទាន់​បាន​បម្រុង? S3 ត្រឹមត្រូវ។ នៅពេលដែលយើងដាក់ឯកសារដែលយើងរក្សាទុកសម្រាប់អ្នកប្រើប្រាស់នៅក្នុង s3 យើងជឿដោយស្មោះថាវាជាពាសដែក ហើយមិនចាំបាច់កក់អ្វីនៅទីនោះទេ។ ប៉ុន្តែ​ប្រវត្តិសាស្ត្រ​បង្ហាញ​ថា​អ្វី​ៗ​កើត​ឡើង​ខុស​គ្នា​។ ជាទូទៅ Amazon ពិពណ៌នា S3 ជាសេវាកម្មមូលដ្ឋាន ព្រោះ Amazon ខ្លួនឯងប្រើ S3 ដើម្បីរក្សាទុករូបភាពម៉ាស៊ីន ការកំណត់រចនាសម្ព័ន្ធ រូបភាព AMI រូបថត... ហើយប្រសិនបើ s3 គាំងដូចដែលបានកើតឡើងម្តងក្នុងអំឡុងពេល 7 ឆ្នាំនេះ ដរាបណាយើងប្រើប្រាស់ bitrix24 វាធ្វើតាមវាដូចជាអ្នកគាំទ្រ មានរឿងជាច្រើនដែលកើតឡើង - អសមត្ថភាពក្នុងការចាប់ផ្តើមម៉ាស៊ីននិម្មិត ការបរាជ័យ api និងអ្វីៗផ្សេងទៀត។

ហើយ S3 អាចធ្លាក់ចុះ - វាបានកើតឡើងម្តង។ ដូច្នេះហើយ យើងបានមកដល់គ្រោងការណ៍ខាងក្រោម៖ ពីរបីឆ្នាំមុនមិនមានកន្លែងផ្ទុកវត្ថុសាធារណៈធ្ងន់ធ្ងរនៅក្នុងប្រទេសរុស្ស៊ីទេ ហើយយើងបានពិចារណាជម្រើសនៃការធ្វើអ្វីមួយដោយខ្លួនឯង... ជាសំណាងល្អ យើងមិនបានចាប់ផ្តើមធ្វើវាទេ ព្រោះយើងនឹង បានជីកចូលទៅក្នុងជំនាញដែលយើងមិនមាន យើងមាន ហើយប្រហែលជារញ៉េរញ៉ៃ។ ឥឡូវនេះ Mail.ru មានកន្លែងផ្ទុកដែលត្រូវគ្នាជាមួយ s3 Yandex មានវា ហើយអ្នកផ្តល់សេវាមួយចំនួនទៀតមានវា។ នៅទីបំផុតយើងបានឈានដល់គំនិតដែលយើងចង់មាន ទីមួយ ការបម្រុងទុក និងទីពីរ សមត្ថភាពក្នុងការធ្វើការជាមួយច្បាប់ចម្លងក្នុងស្រុក។ សម្រាប់តំបន់រុស្ស៊ីជាពិសេស យើងប្រើប្រាស់សេវាកម្ម Mail.ru Hotbox ដែលជា API ដែលត្រូវគ្នាជាមួយ s3។ យើងមិនត្រូវការការកែប្រែសំខាន់ៗណាមួយចំពោះកូដនៅក្នុងកម្មវិធីនោះទេ ហើយយើងបង្កើតយន្តការដូចខាងក្រោម៖ នៅក្នុង s3 មានកេះដែលបង្កឱ្យមានការបង្កើត/លុបវត្ថុ Amazon មានសេវាកម្មមួយហៅថា Lambda - នេះគឺជាការបើកដំណើរការកូដដោយគ្មានម៉ាស៊ីនមេ។ ដែលនឹងត្រូវបានប្រតិបត្តិនៅពេលដែលកេះជាក់លាក់ត្រូវបានកេះ។

យើងធ្វើវាយ៉ាងសាមញ្ញ៖ ប្រសិនបើកេះរបស់យើងឆេះ យើងប្រតិបត្តិកូដដែលនឹងចម្លងវត្ថុទៅកន្លែងផ្ទុក Mail.ru ។ ដើម្បីចាប់ផ្តើមការងារពេញលេញជាមួយនឹងច្បាប់ចម្លងទិន្នន័យក្នុងស្រុក យើងក៏ត្រូវការការធ្វើសមកាលកម្មបញ្ច្រាសផងដែរ ដើម្បីឱ្យអតិថិជនដែលស្ថិតនៅក្នុងផ្នែករុស្ស៊ីអាចធ្វើការជាមួយទំហំផ្ទុកដែលនៅជិតពួកគេ។ សំបុត្រហៀបនឹងបញ្ចប់ការកេះនៅក្នុងកន្លែងផ្ទុករបស់វា - វានឹងអាចធ្វើសមកាលកម្មបញ្ច្រាសនៅកម្រិតហេដ្ឋារចនាសម្ព័ន្ធ ប៉ុន្តែសម្រាប់ពេលនេះយើងកំពុងធ្វើវានៅកម្រិតនៃកូដរបស់យើងផ្ទាល់។ ប្រសិនបើយើងឃើញថាអតិថិជនបានបង្ហោះឯកសារ នោះនៅកម្រិតកូដ យើងដាក់ព្រឹត្តិការណ៍ក្នុងជួរមួយ ដំណើរការវា ហើយធ្វើការចម្លងបញ្ច្រាស។ ហេតុអ្វីបានជាវាអាក្រក់៖ ប្រសិនបើយើងធ្វើការងារមួយចំនួនជាមួយវត្ថុរបស់យើងនៅខាងក្រៅផលិតផលរបស់យើង នោះមានន័យថា តាមរយៈមធ្យោបាយខាងក្រៅមួយចំនួន យើងនឹងមិនគិតពីវាទេ។ ដូច្នេះហើយ យើងរង់ចាំរហូតដល់ទីបញ្ចប់ នៅពេលដែលកេះលេចឡើងនៅកម្រិតផ្ទុក ដូច្នេះមិនថាយើងប្រតិបត្តិកូដពីកន្លែងណានោះទេ វត្ថុដែលមករកយើងត្រូវបានចម្លងតាមទិសផ្សេង។

នៅកម្រិតកូដ យើងចុះឈ្មោះកន្លែងផ្ទុកទាំងពីរសម្រាប់អតិថិជននីមួយៗ៖ មួយត្រូវបានចាត់ទុកថាសំខាន់ មួយទៀតត្រូវបានចាត់ទុកថាជាការបម្រុងទុក។ ប្រសិនបើអ្វីៗដំណើរការល្អ យើងធ្វើការជាមួយកន្លែងផ្ទុកដែលនៅជិតយើង៖ នោះគឺអតិថិជនរបស់យើងដែលនៅក្នុង Amazon ពួកគេធ្វើការជាមួយ S3 ហើយអ្នកដែលធ្វើការនៅប្រទេសរុស្ស៊ីពួកគេធ្វើការជាមួយ Hotbox ។ ប្រសិនបើទង់ត្រូវបានកេះ នោះការខកខានគួរតែត្រូវបានភ្ជាប់ ហើយយើងប្តូរអតិថិជនទៅកន្លែងផ្ទុកផ្សេងទៀត។ យើងអាចធីកប្រអប់នេះដោយឯករាជ្យតាមតំបន់ និងអាចប្តូរពួកវាទៅក្រោយ។ យើងមិនទាន់បានប្រើវានៅក្នុងការអនុវត្តនៅឡើយទេ ប៉ុន្តែយើងបានផ្តល់សម្រាប់យន្តការនេះហើយ យើងគិតថាថ្ងៃណាមួយយើងនឹងត្រូវការឧបករណ៍ប្តូរនេះ ហើយមានប្រយោជន៍។ រឿងនេះបានកើតឡើងម្តងរួចមកហើយ។

អូហើយ Amazon បានរត់ចេញ ...

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

ប្រសិនបើក្រុមហ៊ុនមានលក្ខណៈសកលហើយប្រទេសរុស្ស៊ីគឺជាផ្នែកតូចមួយសម្រាប់វា 3-5% - ល្អវិធីមួយឬផ្សេងទៀតអ្នកអាចលះបង់ពួកគេ។

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

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

នៅចុងខែមីនាឆ្នាំ 2018 Roskomnadzor បានផ្ញើលិខិតមួយទៅកាន់ប្រតិបត្តិករធំបំផុតដោយបញ្ជាក់ថាពួកគេមានគម្រោងបិទ Amazon IPs ជាច្រើនលានដើម្បីទប់ស្កាត់... អ្នកនាំសារ Zello ។ សូមអរគុណដល់អ្នកផ្តល់សេវាដូចគ្នាទាំងនេះ - ពួកគេបានលេចធ្លាយសំបុត្រដោយជោគជ័យដល់មនុស្សគ្រប់គ្នា ហើយមានការយល់ថាការតភ្ជាប់ជាមួយ Amazon អាចនឹងដាច់។ វាជាថ្ងៃសុក្រ យើងបានរត់ដោយការភ័យស្លន់ស្លោទៅកាន់សហសេវិករបស់យើងពី servers.ru ដោយនិយាយថា "មិត្តភ័ក្តិ យើងត្រូវការម៉ាស៊ីនមេជាច្រើនដែលនឹងមានទីតាំងនៅមិនមែននៅក្នុងប្រទេសរុស្ស៊ី មិនមែននៅក្នុង Amazon ទេ ប៉ុន្តែឧទាហរណ៍កន្លែងណាមួយនៅទីក្រុង Amsterdam" ជាលំដាប់។ ដើម្បីយ៉ាងហោចណាស់អាចដំឡើង VPN និងប្រូកស៊ីផ្ទាល់ខ្លួនរបស់យើងនៅទីនោះសម្រាប់ចំណុចបញ្ចប់មួយចំនួនដែលយើងមិនអាចមានឥទ្ធិពលក្នុងមធ្យោបាយណាមួយឧទាហរណ៍ endponts នៃ s3 ដូចគ្នា - យើងមិនអាចព្យាយាមដំឡើងសេវាថ្មី និងទទួលបាន ip ផ្សេងទេ យើងនៅតែត្រូវទៅទីនោះ។ ក្នុងរយៈពេលតែប៉ុន្មានថ្ងៃប៉ុណ្ណោះ យើងបានដំឡើងម៉ាស៊ីនមេទាំងនេះ ធ្វើឱ្យពួកវាដំណើរការ ហើយជាទូទៅ បានរៀបចំសម្រាប់ពេលដែលការទប់ស្កាត់បានចាប់ផ្តើម។ វាជាការចង់ដឹងចង់ឃើញដែល RKN សម្លឹងមើលការច្របូកច្របល់ និងភ័យស្លន់ស្លោ បាននិយាយថា "ទេ យើងនឹងមិនរារាំងអ្វីទេឥឡូវនេះ" ។ (ប៉ុន្តែនេះគឺពិតជារហូតដល់ពេលដែល Telegram ចាប់ផ្តើមត្រូវបានរារាំង។) ដោយបានដំឡើងសមត្ថភាពផ្លូវវាង និងដឹងថាការទប់ស្កាត់នេះមិនត្រូវបានណែនាំ ទោះជាយ៉ាងណាក៏ដោយ យើងមិនបានចាប់ផ្តើមដោះស្រាយបញ្ហាទាំងមូលនោះទេ។ បាទ, គ្រាន់តែក្នុងករណី។

ហើយនៅឆ្នាំ 2019 យើងនៅតែរស់នៅក្នុងលក្ខខណ្ឌនៃការទប់ស្កាត់។ ខ្ញុំបានមើលកាលពីយប់មិញ៖ ប្រហែលមួយលាន IPs បន្តត្រូវបានរារាំង។ ពិត Amazon ស្ទើរតែត្រូវបានបិទទាំងស្រុង ហើយនៅកម្រិតកំពូលរបស់វា វាបានឈានដល់ 20 លានអាសយដ្ឋាន... ជាទូទៅ ការពិតគឺថាប្រហែលជាមិនមានការស៊ីសង្វាក់គ្នាទេ ការចុះសម្រុងគ្នាដ៏ល្អ។ ភ្លាមៗ។ វាប្រហែលជាមិនមានសម្រាប់ហេតុផលបច្ចេកទេស - អគ្គីភ័យ, ជីក, ទាំងអស់។ ឬដូចដែលយើងបានឃើញ មិនមែនបច្ចេកទេសទាំងស្រុងនោះទេ។ ដូច្នេះហើយ អ្នកណាម្នាក់ធំ និងធំ ជាមួយនឹង ASs ផ្ទាល់របស់ពួកគេ ប្រហែលជាអាចគ្រប់គ្រងវាតាមវិធីផ្សេងទៀត - ការតភ្ជាប់ដោយផ្ទាល់ និងរបស់ផ្សេងទៀតគឺនៅកម្រិត l2 រួចហើយ។ ប៉ុន្តែនៅក្នុងកំណែសាមញ្ញមួយ ដូចជារបស់យើង ឬសូម្បីតែតូចជាងនេះ អ្នកអាចក្នុងករណីដែលលែងត្រូវការតទៅទៀតនៅកម្រិតនៃម៉ាស៊ីនមេដែលបានលើកឡើងនៅកន្លែងផ្សេងទៀត កំណត់រចនាសម្ព័ន្ធជាមុន vpn ប្រូកស៊ី ជាមួយនឹងសមត្ថភាពក្នុងការប្តូរការកំណត់រចនាសម្ព័ន្ធទៅពួកវាក្នុងផ្នែកទាំងនោះយ៉ាងឆាប់រហ័ស។ ដែលមានសារៈសំខាន់សម្រាប់ការតភ្ជាប់របស់អ្នក។ វាមានប្រយោជន៍សម្រាប់យើងច្រើនជាងមួយដង នៅពេលដែលការទប់ស្កាត់របស់ Amazon បានចាប់ផ្តើម នៅក្នុងករណីដ៏អាក្រក់បំផុត យើងបានអនុញ្ញាតឱ្យចរាចរណ៍ S3 ឆ្លងកាត់ពួកវាប៉ុណ្ណោះ ប៉ុន្តែបន្តិចម្តងៗអ្វីៗទាំងអស់ត្រូវបានដោះស្រាយ។

តើធ្វើដូចម្តេចដើម្បីកក់ ... អ្នកផ្តល់សេវាទាំងមូល?

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

តាមសម្មតិកម្ម សម្រាប់ Amazon យើងកំពុងពិចារណាពីលទ្ធភាពនៃការកក់ទុកនៅកម្រិតនៃអ្នកផ្តល់សេវាផ្សេងទៀត; ប្រហែលជា Google ប្រហែលជាអ្នកផ្សេង... ប៉ុន្តែរហូតមកដល់ពេលនេះ យើងបានសង្កេតឃើញនៅក្នុងការអនុវត្តថា ខណៈពេលដែលក្រុមហ៊ុន Amazon មានឧបទ្ទវហេតុនៅកម្រិតនៃតំបន់ដែលមានតែមួយ គ្រោះថ្នាក់នៅកម្រិតនៃតំបន់ទាំងមូលគឺកម្រណាស់។ ដូច្នេះតាមទ្រឹស្តី យើងមានគំនិតដែលថាយើងអាចធ្វើការកក់ទុក “Amazon មិនមែនជា Amazon” ប៉ុន្តែនៅក្នុងការអនុវត្តជាក់ស្តែង វាមិនទាន់ជាករណីនោះទេ។

ពាក្យពីរបីអំពីស្វ័យប្រវត្តិកម្ម

តើស្វ័យប្រវត្តិកម្មតែងតែចាំបាច់មែនទេ? នៅទីនេះវាជាការសមរម្យក្នុងការរំលឹកឡើងវិញនូវឥទ្ធិពល Dunning-Kruger ។ នៅលើអ័ក្ស “x” គឺជាចំណេះដឹង និងបទពិសោធន៍របស់យើងដែលយើងទទួលបាន ហើយនៅលើអ័ក្ស “y” គឺជាទំនុកចិត្តលើសកម្មភាពរបស់យើង។ ដំបូងយើងមិនដឹងអ្វីទាំងអស់ ហើយមិនប្រាកដទាល់តែសោះ។ បន្ទាប់មកយើងដឹងបន្តិចហើយក្លាយជាមនុស្សដែលមានទំនុកចិត្ត - នេះគឺជាអ្វីដែលគេហៅថា "កំពូលនៃភាពល្ងង់ខ្លៅ" ដែលបង្ហាញយ៉ាងច្បាស់ដោយរូបភាព "ជំងឺវង្វេងនិងភាពក្លាហាន" ។ បន្ទាប់​មក​យើង​បាន​រៀន​បន្តិច​ហើយ​ត្រៀម​ខ្លួន​ចូល​ប្រយុទ្ធ។ បន្ទាប់​មក យើង​ឈាន​ជើង​ទៅ​លើ​កំហុស​ដ៏​ធំ​មួយ​ចំនួន ហើយ​ឃើញ​ខ្លួន​យើង​ស្ថិត​ក្នុង​ជ្រលង​នៃ​ភាព​អស់​សង្ឃឹម នៅ​ពេល​ដែល​យើង​ហាក់​ដូច​ជា​ដឹង​អ្វី​មួយ ប៉ុន្តែ​តាម​ពិត​យើង​មិន​ដឹង​ច្រើន​ទេ។ បន្ទាប់មក នៅពេលដែលយើងទទួលបានបទពិសោធន៍ យើងកាន់តែមានទំនុកចិត្ត។

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

សេចក្តីសន្និដ្ឋាន

ក្នុងរយៈពេល 7 ឆ្នាំយើងបានចេញពីការពិតដែលថានៅពេលដែលអ្វីមួយបានធ្លាក់ចុះមានការភ័យស្លន់ស្លោ - ការភ័យស្លន់ស្លោដល់ការយល់ដឹងថាបញ្ហាមិនមានទេមានតែភារកិច្ចប៉ុណ្ណោះពួកគេត្រូវតែ - ហើយអាចដោះស្រាយបាន។ នៅពេលអ្នកកំពុងសាងសង់សេវាកម្ម សូមមើលវាពីខាងលើ វាយតម្លៃហានិភ័យទាំងអស់ដែលអាចកើតឡើង។ ប្រសិនបើអ្នកឃើញពួកវាភ្លាមៗ នោះផ្តល់ការលែងត្រូវការតទៅទៀតជាមុន និងលទ្ធភាពនៃការកសាងហេដ្ឋារចនាសម្ព័ន្ធដែលអត់ឱនចំពោះកំហុស ពីព្រោះចំណុចណាមួយដែលអាចបរាជ័យ និងនាំទៅរកភាពមិនអាចដំណើរការបាននៃសេវាកម្មនេះប្រាកដជានឹងធ្វើដូច្នេះ។ ហើយទោះបីជាវាហាក់ដូចជាអ្នកថាធាតុមួយចំនួននៃហេដ្ឋារចនាសម្ព័ន្ធពិតជានឹងមិនបរាជ័យ - ដូចជា s3 ដូចគ្នាក៏ដោយ ក៏នៅតែចងចាំថាពួកគេអាចធ្វើបាន។ ហើយយ៉ាងហោចណាស់តាមទ្រឹស្ដីមានគំនិតអំពីអ្វីដែលអ្នកនឹងធ្វើជាមួយពួកគេប្រសិនបើមានអ្វីមួយកើតឡើង។ មានផែនការគ្រប់គ្រងហានិភ័យ។ នៅពេលអ្នកកំពុងគិតអំពីការធ្វើអ្វីៗគ្រប់យ៉ាងដោយស្វ័យប្រវត្តិ ឬដោយដៃ វាយតម្លៃហានិភ័យ៖ តើនឹងមានអ្វីកើតឡើង ប្រសិនបើស្វ័យប្រវត្តិកម្មចាប់ផ្តើមផ្លាស់ប្តូរអ្វីៗទាំងអស់ - តើនេះនឹងមិននាំឱ្យមានស្ថានភាពកាន់តែអាក្រក់បើប្រៀបធៀបទៅនឹងគ្រោះថ្នាក់ទេ? ប្រហែលជានៅកន្លែងណាមួយ ចាំបាច់ត្រូវប្រើការសម្របសម្រួលសមហេតុផលរវាងការប្រើប្រាស់ស្វ័យប្រវត្តិកម្ម និងប្រតិកម្មរបស់វិស្វករដែលកំពុងបំពេញកាតព្វកិច្ច ដែលនឹងវាយតម្លៃរូបភាពពិត និងយល់ថាតើអ្វីមួយត្រូវប្តូរនៅនឹងកន្លែង ឬ "បាទ/ចាស ប៉ុន្តែមិនមែនឥឡូវនេះទេ"។

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

អត្ថបទនេះគឺជាកំណែដែលបានធ្វើបច្ចុប្បន្នភាព និងពង្រីកនៃរបាយការណ៍របស់ Alexander Demidov នៅក្នុងសន្និសីទ ការងារថ្ងៃ 4.

ប្រភព: www.habr.com