ត្រឡប់ទៅប្លុក

វាយតម្លៃថ្លៃដើមមុនផ្លាស់ប្តូរឧបករណ៍៖ ៦ ចំណុចត្រូវពិនិត្យ និងការផ្លាស់ប្តូរ ៣ ដំណាក់កាល

ថ្លៃដើមពិតប្រាកដនៃការផ្លាស់ទៅឧបករណ៍ថ្មី ជាញឹកញាប់ទើបបង្ហាញច្បាស់បន្ទាប់ពីចាប់ផ្តើម migration។ ការផ្គូផ្គងគណនី ការកំណត់ environment ច្រកចេញបណ្ដាញ សិទ្ធិក្រុម និងការរក្សា environment ចាស់ ជាអ្វីដែលកំណត់ថាការផ្លាស់ប្តូរនឹងរលូន ឬត្រូវធ្វើការឡើងវិញ។

ការប្តូរឧបករណ៍គ្រប់គ្រង environment មើលទៅសាមញ្ញនៅលើផ្ទៃ៖ ដំឡើងកម្មវិធី ហើយ export ទិន្នន័យមួយចំនួន។

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

ដំបូងត្រូវបញ្ជាក់ថាគណនី និង environment អាចផ្គូផ្គងគ្នាបានត្រឹមត្រូវ

អ្វីដែលត្រូវផ្លាស់មិនមែនគ្រាន់តែគណនី និងពាក្យសម្ងាត់ទេ ប៉ុន្តែជាផែនទីទំនាក់ទំនងទាំងមូលថា គណនីណាដំណើរការនៅ environment ណា ហើយ environment នោះភ្ជាប់នឹងច្រកចេញបណ្ដាញណា។ បើ map នេះមិនអាច export បាន migration មានន័យថាត្រូវបង្កើតវាឡើងវិញដោយដៃ។ ពេលមានគណនីរាប់សិប ឬរាប់រយ កំហុសស្ទើរតែមិនអាចជៀសវាងបាន។

វិធីពិនិត្យគឺត្រង់ៗ៖ បើកមុខងារ export ក្នុងឧបករណ៍ចាស់ ហើយមើលថាតើ field ដែលបាន export មានសញ្ញាសម្គាល់ environment និងការកំណត់បណ្ដាញឬអត់។ បើ export បានតែគណនី និងពាក្យសម្ងាត់ បើនិយាយតាមការអនុវត្ត វានៅតែមិនគ្រប់គ្រាន់។

ការកំណត់ environment ត្រូវបង្កើតឡើងវិញ មិនមែនចម្លងតាមទេ

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

វិធីដែលអនុវត្តបានជាង គឺកត់ត្រាគោលបំណងនៃការកំណត់ ដូចជា តំបន់សហរដ្ឋអាមេរិក ប្រព័ន្ធ Windows និងកម្រិត hardware មួយ ហើយបង្កើត environment ថ្មីតាមគោលបំណងនោះនៅក្នុងឧបករណ៍ថ្មី។ គោលដៅគឺ environment ដែលមានភាពស្របគ្នា និងអាចប្រើបាន មិនមែនច្បាប់ចម្លងដូចគ្នាទាំងស្រុងនៃ environment ចាស់ទេ។

Cookies និងស្ថានភាព login

សម្រាប់គណនីដែលត្រូវរក្សាស្ថានភាព login ការអាចផ្ទេរ session state បានឬអត់ នឹងកំណត់ថាបន្ទាប់ពី migration តើត្រូវ login ម្តងទៀតគ្រប់គណនីឬទេ។ មានចំណុចមួយងាយមើលរំលង៖ គណនីរាប់សិប login ម្តងទៀតក្នុងថ្ងៃតែមួយ គឺជាសញ្ញាមិនធម្មតាមួយដោយខ្លួនឯង។ ដូច្នេះគួរបែងចែកពេលវេលា មិនមែនប្តូរទាំងអស់ក្នុងពេលតែមួយទេ។

វិធីភ្ជាប់ច្រកចេញបណ្ដាញត្រូវគ្នាឬទេ?

បើច្រកចេញត្រូវបានភ្ជាប់តាម environment ត្រូវបញ្ជាក់ថាឧបករណ៍ថ្មីគាំទ្រ protocol និងវិធី binding ដូចគ្នា។ បើមិនគាំទ្រ ការកំណត់បណ្ដាញទាំងមូលត្រូវធ្វើឡើងវិញ ហើយបរិមាណការងារនេះត្រូវគិតបញ្ចូលជាមុន។

ទម្លាប់ការងាររបស់ក្រុមនឹងត្រូវរំខានឬទេ?

តើ permission model ដូចគ្នាឬស្រដៀងគ្នា? តើសមាជិកអាចធ្វើការដោយមិនចាំបាច់ប្រគល់ពាក្យសម្ងាត់ឱ្យគ្នាឬទេ? តើ operation logs នៅតែអាចមើលបានទេ? ចំណុចទាំងបីនេះកំណត់ថាក្រុមត្រូវរៀនឡើងវិញច្រើនប៉ុណ្ណា។ ក្រុមកាន់តែធំ ថ្លៃដើមកាន់តែខ្ពស់។

តើគួររក្សា environment ចាស់មួយរយៈទៀតឬទេ?

Migration មិនចាំបាច់បញ្ចប់ក្នុងជំហានតែមួយទេ។ ការរក្សា environment ចាស់បន្ថែមពីរបីសប្ដាហ៍ មានប្រយោជន៍ជាងដែលគិត៖ អាចប្រៀបធៀបជាមួយ environment ថ្មី ដោះស្រាយគណនីដែលមានបញ្ហាក្នុងអំឡុង migration និងមានកន្លែងត្រឡប់ទៅវិញ បើឧបករណ៍ថ្មីមានបញ្ហាដែលមិនបានរំពឹងទុក។

តើត្រូវរៀបចំដំណាក់កាលផ្លាស់ប្តូរយ៉ាងដូចម្តេច?

មុន migration ឧបករណ៍ ត្រូវបញ្ជាក់ account mapping គោលបំណងនៃ configuration ស្ថានភាព login ការភ្ជាប់បណ្ដាញ workflow របស់ក្រុម និង rollback window ហើយបន្តតាម pilot migration ការសង្កេត និង migration ជាដំណាក់កាល

ក្នុងមួយទៅពីរសប្ដាហ៍ដំបូង ចាប់ផ្តើម pilot migration តូចមួយ ដោយជ្រើសរើសគណនីដែលមិនសូវសំខាន់ពី ៥ ទៅ ១០ ហើយដំណើរការ workflow អាជីវកម្មពេញលេញ។ អ្វីដែលត្រូវសាកល្បងគឺថាឧបករណ៍ថ្មីអាចទ្រាំទ្រការងារពិតបានឬអត់ មិនមែនថាបញ្ជីមុខងាររបស់វាវែងប៉ុណ្ណាទេ។

បន្ទាប់មកជាដំណាក់កាលសង្កេតពី ២ ទៅ ៤ សប្ដាហ៍។ រក្សារបៀបប្រតិបត្តិឱ្យជិតស្និទ្ធនឹងរបៀបចាស់ ហើយប្រៀបធៀបស្ថិរភាពគណនី ប្រេកង់នៃការធ្វើ verification និងអត្រាជោគជ័យនៃ task នៅទាំងពីរផ្នែក។ បើ environment ថ្មីអន់ជាងយ៉ាងច្បាស់នៅពេលនេះ ថ្លៃដើមនៃ rollback នៅតែទាប។

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

កំហុសក្នុងការវិនិច្ឆ័យដែលជួបញឹកញាប់

សម្រេចចិត្ត migrate ដោយមើលតែតម្លៃ software គឺយកថ្លៃដើមដែលមើលឃើញមកចាត់ទុកជាថ្លៃដើមសរុប។ កម្លាំងមនុស្ស ភាពប្រែប្រួលនៃអាជីវកម្មក្នុងដំណាក់កាលផ្លាស់ប្តូរ និងការបាត់បង់គណនីដែលអាចកើតមាន ជាញឹកញាប់សរុបលើសប្រាក់ដែលសន្សំបានពី software ឆ្ងាយណាស់។

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

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

មុនសម្រេចចិត្ត ត្រូវឆ្លើយសំណួរ ៣ យ៉ាង

បញ្ហាជាក់លាក់របស់ឧបករណ៍បច្ចុប្បន្នគឺអ្វី? ត្រូវបញ្ជាក់ជាស្ថានការណ៍ជាក់ស្តែង មិនមែនគ្រាន់តែមានអារម្មណ៍ថាពិបាកប្រើទេ។ តើឧបករណ៍ថ្មីអាចដោះស្រាយបញ្ហាទាំងនេះបានប្រាកដឬទេ ហើយល្អបំផុតគឺអាចបញ្ជាក់បានក្នុង pilot migration? បើ migration បរាជ័យ តើថ្លៃដើមគឺអ្វី អាច rollback បានឬទេ ហើយចំណាយពេលប៉ុន្មាន?

ចាប់ផ្តើមតែបន្ទាប់ពីសំណួរទាំង ៣ មានចម្លើយច្បាស់លាស់។