តើ DevOps ជានរណា ហើយនៅពេលណាដែលវាមិនត្រូវការ?

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

មនុស្សមួយចំនួនរាយឈ្មោះ DevOps នៅលើប្រវត្តិរូបរបស់ពួកគេ ទោះបីជាពួកគេមិនតែងតែដឹង ឬយល់ពីខ្លឹមសារនៃពាក្យក៏ដោយ។ មនុស្សមួយចំនួនគិតថាបន្ទាប់ពីសិក្សា Ansible, GitLab, Jenkins, Terraform និងផ្សេងទៀត (បញ្ជីអាចត្រូវបានបន្តយោងទៅតាមរសជាតិរបស់អ្នក) អ្នកនឹងក្លាយជា "អ្នកលះបង់" ភ្លាមៗ។ នេះជាការពិតមិនពិតទេ។

ប៉ុន្មានឆ្នាំចុងក្រោយនេះ ខ្ញុំបានចូលរួមជាចម្បងក្នុងការអនុវត្ត DevOps នៅក្នុងក្រុមហ៊ុនផ្សេងៗ។ មុន​នោះ​លោក​បាន​ធ្វើ​ការ​ជាង​២០​ឆ្នាំ​ក្នុង​មុខ​តំណែង​រាប់​ចាប់ពី​អ្នកគ្រប់គ្រង​ប្រព័ន្ធ​ដល់​នាយក​ផ្នែក​ព័ត៌មានវិទ្យា។ បច្ចុប្បន្ន DevOps Lead Engineer នៅ Playgendary ។

តើ DevOps ជានរណា

គំនិតក្នុងការសរសេរអត្ថបទមួយបានកើតឡើងបន្ទាប់ពីសំណួរមួយទៀត: "តើ DevOps ជានរណា?" នៅ​មិន​ទាន់​មាន​ពាក្យ​កំណត់​ថា​ជា​នរណា ឬ​ជា​នរណា​ទេ។ ចំលើយមួយចំនួនមានរួចហើយនៅក្នុងនេះ។ видео. ដំបូង ខ្ញុំនឹងលើកយកចំណុចសំខាន់ៗពីវា ហើយបន្ទាប់មកខ្ញុំនឹងចែករំលែកការសង្កេត និងគំនិតរបស់ខ្ញុំ។

DevOps មិនមែនជាអ្នកឯកទេសដែលអាចត្រូវបានជួល មិនមែនជាឧបករណ៍ប្រើប្រាស់ និងមិនមែនជាផ្នែកនៃអ្នកអភិវឌ្ឍន៍ជាមួយវិស្វករនោះទេ។

DevOps គឺជាទស្សនវិជ្ជា និងវិធីសាស្រ្ត។

ម្យ៉ាងវិញទៀត វាគឺជាសំណុំនៃការអនុវត្តដែលជួយអ្នកអភិវឌ្ឍន៍ធ្វើអន្តរកម្មយ៉ាងសកម្មជាមួយអ្នកគ្រប់គ្រងប្រព័ន្ធ។ នោះ​គឺ​ការ​តភ្ជាប់​និង​បញ្ចូល​ដំណើរការ​ការងារ​ទៅ​គ្នា​ទៅ​វិញ​ទៅ​មក។

ជាមួយនឹងវត្តមានរបស់ DevOps រចនាសម្ព័ន្ធ និងតួនាទីរបស់អ្នកឯកទេសនៅតែដដែល (មានអ្នកអភិវឌ្ឍន៍ មានវិស្វករ) ប៉ុន្តែច្បាប់នៃអន្តរកម្មបានផ្លាស់ប្តូរ។ ព្រំដែនរវាងនាយកដ្ឋានបានធ្វើឱ្យព្រិលៗ។

គោលដៅរបស់ DevOps អាចត្រូវបានពិពណ៌នាជាបីចំណុច៖

• កម្មវិធីត្រូវតែធ្វើបច្ចុប្បន្នភាពជាទៀងទាត់។
• កម្មវិធីត្រូវធ្វើយ៉ាងឆាប់រហ័ស។
• កម្មវិធីគួរតែត្រូវបានដាក់ឱ្យប្រើប្រាស់យ៉ាងងាយស្រួល និងក្នុងរយៈពេលដ៏ខ្លី។

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

ហើយនេះគ្រាន់តែជាផ្នែកនៃឧបករណ៍ DevOps ប៉ុណ្ណោះ។

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

តាមបទពិសោធន៍នៃការសម្ភាសន៍ ខ្ញុំឃើញរូបភាពខាងក្រោម៖ អ្នកឯកទេសដែលចាត់ទុក DevOps ជាចំណងជើងការងារជាធម្មតាមានការយល់ច្រឡំជាមួយមិត្តរួមការងារ.

មានឧទាហរណ៍ដ៏គួរឱ្យចាប់អារម្មណ៍មួយ។ យុវជន​ម្នាក់​បាន​មក​សម្ភាសន៍​ជាមួយ​ពាក្យ​ឆ្លាត​ៗ​ជា​ច្រើន​នៅ​លើ​ប្រវត្តិរូប​របស់​ខ្លួន។ នៅការងារបីចុងក្រោយរបស់គាត់គាត់មានបទពិសោធន៍ 5-6 ខែ។ ខ្ញុំ​បាន​ចាក​ចេញ​ពី​ការ​ចាប់​ផ្តើម​អាជីវកម្ម​ពីរ​ដោយ​សារ​ពួក​គេ "មិន​បាន​ដក​ខ្លួន​ចេញ"។ ប៉ុន្តែអំពីក្រុមហ៊ុនទី XNUMX គាត់បាននិយាយថាគ្មាននរណាម្នាក់យល់ពីគាត់នៅទីនោះទេ: អ្នកអភិវឌ្ឍន៍សរសេរកូដនៅលើ Windows ហើយនាយកបង្ខំឱ្យកូដនេះ "រុំ" នៅក្នុង Docker ធម្មតាហើយត្រូវបានបង្កើតឡើងនៅក្នុងបំពង់ CI / CD ។ បុរសនោះបាននិយាយរឿងអវិជ្ជមានជាច្រើនអំពីកន្លែងធ្វើការបច្ចុប្បន្នរបស់គាត់ និងមិត្តរួមការងាររបស់គាត់ - ខ្ញុំគ្រាន់តែចង់ឆ្លើយថា "ដូច្នេះអ្នកនឹងមិនលក់ដំរីទេ" ។

បន្ទាប់​មក​ខ្ញុំ​បាន​សួរ​គាត់​នូវ​សំណួរ​មួយ​ដែល​ខ្ពស់​ក្នុង​បញ្ជី​របស់​ខ្ញុំ​សម្រាប់​បេក្ខជន​គ្រប់​រូប។

- តើ DevOps មានន័យយ៉ាងណាចំពោះអ្នកផ្ទាល់?
- ជាទូទៅឬតើខ្ញុំយល់យ៉ាងណា?

ខ្ញុំចាប់អារម្មណ៍លើគំនិតផ្ទាល់ខ្លួនរបស់គាត់។ គាត់ដឹងពីទ្រឹស្តី និងប្រភពដើមនៃពាក្យនេះ ប៉ុន្តែគាត់មិនយល់ស្របនឹងពួកគេយ៉ាងខ្លាំង។ គាត់ជឿថា DevOps គឺជាចំណងជើងការងារ។ នេះគឺជាកន្លែងដែលឫសគល់នៃបញ្ហារបស់គាត់។ ក៏ដូចជាអ្នកឯកទេសដទៃទៀតដែលមានមតិដូចគ្នា។

និយោជកដោយបានលឺច្រើនអំពី "វេទមន្តនៃ DevOps" ចង់ស្វែងរកមនុស្សម្នាក់ដែលនឹងមកបង្កើត "វេទមន្ត" នេះ។ ហើយអ្នកដាក់ពាក្យមកពីប្រភេទ "DevOps is a job" មិនយល់ថាជាមួយនឹងវិធីសាស្រ្តនេះ ពួកគេនឹងមិនអាចបំពេញតាមការរំពឹងទុកបានទេ។ ហើយជាទូទៅពួកគេបានសរសេរ DevOps នៅលើប្រវត្តិរូបរបស់ពួកគេព្រោះវាជានិន្នាការមួយ ហើយពួកគេចំណាយច្រើនសម្រាប់វា។

វិធីសាស្រ្ត និងទស្សនវិជ្ជា DevOps

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

វិធីសាស្រ្ត DevOps គ្រាន់តែជាមធ្យោបាយដើម្បីសម្រេចបាននូវគោលដៅប៉ុណ្ណោះ។

ឥឡូវនេះអំពីអ្វីដែលទស្សនវិជ្ជា DevOps ។ ហើយនេះប្រហែលជាសំណួរពិបាកបំផុត។

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

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

ដោយ​ប្រើ​បទពិសោធន៍​ផ្ទាល់​ខ្លួន​របស់​ខ្ញុំ ខ្ញុំ​បាន​ព្យាយាម​ធ្វើ​ជា​ផ្លូវ​ការ​មួយ​ចំនួន​នៃ "គោល​ការណ៍" នៃ​ទស្សនវិជ្ជា​នេះ។ លទ្ធផលមានដូចខាងក្រោម៖

• DevOps មិន​មែន​ជា​អ្វី​ដែល​ឯករាជ្យ​ដែល​អាច​ត្រូវ​បាន​បំបែក​ជា​ផ្នែក​នៃ​ចំណេះដឹង​ឬ​សកម្មភាព​ដោយ​ឡែក​ពី​គ្នា​នោះ​ទេ។
• បុគ្គលិកក្រុមហ៊ុនទាំងអស់គួរតែត្រូវបានណែនាំដោយវិធីសាស្រ្ត DevOps នៅពេលរៀបចំផែនការសកម្មភាពរបស់ពួកគេ។
• DevOps ប៉ះពាល់ដល់ដំណើរការទាំងអស់នៅក្នុងក្រុមហ៊ុនមួយ។
• DevOps មានដើម្បីកាត់បន្ថយការចំណាយពេលវេលាសម្រាប់ដំណើរការណាមួយនៅក្នុងក្រុមហ៊ុនដើម្បីធានាបាននូវការអភិវឌ្ឍន៍សេវាកម្មរបស់ខ្លួន និងការលួងលោមអតិបរមារបស់អតិថិជន។
• DevOps ជាភាសាទំនើប គឺជាមុខតំណែងសកម្មរបស់បុគ្គលិកគ្រប់រូបរបស់ក្រុមហ៊ុន ក្នុងគោលបំណងកាត់បន្ថយការចំណាយពេលវេលា និងការកែលម្អគុណភាពនៃផលិតផល IT នៅជុំវិញយើង។

ខ្ញុំ​គិត​ថា “ការ​លើក​ឡើង” របស់​ខ្ញុំ​គឺ​ជា​ប្រធាន​បទ​ដោយ​ឡែក​សម្រាប់​ការ​ពិភាក្សា។ ប៉ុន្តែ​ឥឡូវ​មាន​អ្វី​ដែល​ត្រូវ​កសាង​ឡើង។

អ្វីដែល DevOps ធ្វើ

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

ខ្ញុំមិនអាចនិយាយដោយមានទំនុកចិត្ត 100% អំពីទីផ្សារការងារលោកខាងលិចទេ។ ប៉ុន្តែខ្ញុំដឹងច្រើនអំពីទីផ្សារ DevOps នៅក្នុងប្រទេសរុស្ស៊ី។ បន្ថែមពីលើការសម្ភាសន៍រាប់រយនាក់ ក្នុងរយៈពេលមួយឆ្នាំកន្លះកន្លងមកនេះ ខ្ញុំបានចូលរួមក្នុងការលក់ផ្នែកបច្ចេកទេសរាប់រយសម្រាប់សេវាកម្ម "ការអនុវត្ត DevOps" សម្រាប់ក្រុមហ៊ុន និងធនាគារធំៗរបស់រុស្ស៊ី។

នៅក្នុងប្រទេសរុស្ស៊ី DevOps នៅតែជាប្រធានបទក្មេងនៅឡើយ ប៉ុន្តែមាននិន្នាការរួចទៅហើយ។ តាមខ្ញុំដឹង នៅទីក្រុងមូស្គូតែម្នាក់ឯង កង្វះអ្នកឯកទេសបែបនេះក្នុងឆ្នាំ ២០១៩ មានជាង ១០០០នាក់។ ហើយពាក្យ Kubernetes សម្រាប់និយោជកគឺស្ទើរតែដូចជាក្រណាត់ក្រហមសម្រាប់គោ។ អ្នកប្រកាន់ខ្ជាប់នូវឧបករណ៍នេះត្រៀមខ្លួនជាស្រេចក្នុងការប្រើប្រាស់វាសូម្បីតែកន្លែងដែលមិនចាំបាច់ និងចំណេញផ្នែកសេដ្ឋកិច្ចក៏ដោយ។ និយោជកមិនតែងតែយល់ថាក្នុងករណីណាដែលអ្វីដែលសមស្របជាងក្នុងការប្រើប្រាស់ ហើយជាមួយនឹងការដាក់ពង្រាយត្រឹមត្រូវ ការថែរក្សាចង្កោម Kubernetes មានតម្លៃ 2019-1000 ដងច្រើនជាងការដាក់ឱ្យប្រើប្រាស់កម្មវិធីដោយប្រើគ្រោងការណ៍ចង្កោមធម្មតា។ ប្រើវានៅកន្លែងដែលអ្នកពិតជាត្រូវការ។

ការអនុវត្ត DevOps គឺមានតម្លៃថ្លៃក្នុងលក្ខខណ្ឌនៃប្រាក់។ ហើយ​វា​មាន​ភាព​ត្រឹម​ត្រូវ​តែ​កន្លែង​ដែល​វា​នាំ​មក​នូវ​អត្ថប្រយោជន៍​សេដ្ឋកិច្ច​ក្នុង​វិស័យ​ផ្សេង​ទៀត ហើយ​មិនមែន​ដោយ​ខ្លួន​ឯង​នោះ​ទេ។

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

ដូចគ្នានេះផងដែរ វិស្វករ DevOps ត្រូវការប្រើធនធានរដ្ឋបាលពីពេលមួយទៅពេលមួយ។ ជាឧទាហរណ៍ ដើម្បីយកឈ្នះលើ "ភាពធន់នឹងបរិស្ថាន" - នៅពេលដែលក្រុមមិនទាន់ត្រៀមខ្លួនរួចរាល់ក្នុងការទទួលយកឧបករណ៍ និងវិធីសាស្រ្ត DevOps ។

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

ប៉ុន្តែមានក្រុមដែលផ្ទុយទៅវិញ សប្បាយចិត្តនឹងណែនាំឧបករណ៍ និងវិធីសាស្រ្តថ្មី ហើយចូលរួមយ៉ាងសកម្មក្នុងដំណើរការនេះ។ ទោះបីជាក្នុងករណីនេះក៏ដោយ ការទំនាក់ទំនងរវាងវិស្វករ DevOps និងក្រុមមិនត្រូវបានលុបចោលទេ។

នៅពេលដែល DevOps មិនត្រូវការ

មានស្ថានភាពនៅពេលដែល DevOps មិនត្រូវការ។ នេះគឺជាការពិត - វាចាំបាច់ត្រូវយល់និងទទួលយក។

ជាដំបូង នេះអនុវត្តចំពោះក្រុមហ៊ុនណាមួយ (ជាពិសេសអាជីវកម្មខ្នាតតូច) នៅពេលដែលប្រាក់ចំណេញរបស់ពួកគេមិនអាស្រ័យដោយផ្ទាល់ទៅលើវត្តមាន ឬអវត្តមាននៃផលិតផល IT ដែលផ្តល់សេវាកម្មព័ត៌មានដល់អតិថិជន។ ហើយនៅទីនេះយើងមិននិយាយអំពីគេហទំព័ររបស់ក្រុមហ៊ុនទេ ថាតើវាជា "ប័ណ្ណអាជីវកម្ម" ឋិតិវន្ត ឬជាមួយប្លុកព័ត៌មានថាមវន្ត។ល។

DevOps ត្រូវបានទាមទារនៅពេលដែលការពេញចិត្តរបស់អតិថិជនរបស់អ្នក និងបំណងប្រាថ្នារបស់គាត់ក្នុងការត្រលប់មកអ្នកម្តងទៀត អាស្រ័យលើភាពអាចរកបាននៃសេវាកម្មព័ត៌មានទាំងនេះសម្រាប់អន្តរកម្មជាមួយអតិថិជន គុណភាព និងការកំណត់គោលដៅរបស់ពួកគេ។

ឧទាហរណ៍ដ៏គួរឱ្យចាប់អារម្មណ៍មួយគឺធនាគារដ៏ល្បីមួយ។ ក្រុមហ៊ុនមិនមានការិយាល័យអតិថិជនធម្មតាទេ លំហូរឯកសារត្រូវបានអនុវត្តតាមរយៈសំបុត្រ ឬអ្នកនាំសំបុត្រ ហើយបុគ្គលិកជាច្រើនធ្វើការពីផ្ទះ។ ក្រុមហ៊ុនបានឈប់គ្រាន់តែជាធនាគារ ហើយតាមគំនិតរបស់ខ្ញុំ បានប្រែក្លាយទៅជាក្រុមហ៊ុន IT ជាមួយនឹងបច្ចេកវិទ្យា DevOps ដែលបានអភិវឌ្ឍ។

ឧទាហរណ៍ និង​ការបង្រៀន​ផ្សេងទៀត​ជាច្រើន​អាច​រកឃើញ​នៅក្នុង​ការកត់ត្រា​នៃ​ការប្រជុំ និង​សន្និសីទ​តាម​ប្រធានបទ។ ខ្ញុំបានទៅមើលពួកគេមួយចំនួនដោយផ្ទាល់ - នេះគឺជាបទពិសោធន៍ដ៏មានប្រយោជន៍សម្រាប់អ្នកដែលចង់អភិវឌ្ឍក្នុងទិសដៅនេះ។ នេះគឺជាតំណភ្ជាប់ទៅកាន់បណ្តាញ YouTube ដែលមានការបង្រៀន និងសម្ភារៈល្អៗនៅលើ DevOps៖

• DevOops
• DevOpsConf
• ការផ្ទុកខ្ពស់ ++
• ផ្លិត
• ដំណោះស្រាយ MailRu Cloud

ឥឡូវក្រឡេកមើលអាជីវកម្មរបស់អ្នក ហើយគិតអំពីរឿងនេះ៖ តើក្រុមហ៊ុនរបស់អ្នក និងប្រាក់ចំណេញប៉ុន្មានអាស្រ័យលើផលិតផល IT ដើម្បីបើកដំណើរការអន្តរកម្មជាមួយអតិថិជន?

ប្រសិនបើក្រុមហ៊ុនរបស់អ្នកលក់ត្រីនៅក្នុងហាងតូចមួយ ហើយផលិតផល IT តែមួយគត់គឺ 1C ពីរ៖ ការកំណត់រចនាសម្ព័ន្ធសហគ្រាស (គណនេយ្យ និង UNF) នោះវាពិបាកនឹងនិយាយអំពី DevOps ណាស់។

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

ទំហំ និងបរិមាណនៃចំណូលហិរញ្ញវត្ថុប្រចាំឆ្នាំមិនមែនជាលក្ខណៈវិនិច្ឆ័យចម្បងសម្រាប់កំណត់ថាតើក្រុមហ៊ុនរបស់អ្នកត្រូវការ DevOps ដែរឬទេ។

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

អតិថិជន​របស់​ពួក​គេ​គឺ​ជា​បញ្ជី​មាន​កំណត់​នៃ​ក្រុមហ៊ុន​លក់​រថយន្ត។ ហើយម្នាក់ៗត្រូវបានចាត់តាំងអ្នកឯកទេសពីក្រុមហ៊ុនផលិត។ លំហូរឯកសារខាងក្នុងទាំងអស់កើតឡើងតាមរយៈ SAP ERP ។ បុគ្គលិកខាងក្នុងគឺជាអតិថិជនសំខាន់នៃប្រព័ន្ធព័ត៌មាន។ ប៉ុន្តែ IS នេះត្រូវបានគ្រប់គ្រងដោយមធ្យោបាយបុរាណនៃការគ្រប់គ្រងប្រព័ន្ធចង្កោម។ ដែលមិនរាប់បញ្ចូលលទ្ធភាពនៃការប្រើប្រាស់ការអនុវត្ត DevOps ។

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

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

លក្ខណៈវិនិច្ឆ័យចម្បងសម្រាប់ការយល់ដឹងថាតើ DevOps ត្រូវការអ្វីខ្លះ៖ តើផលិតផល IT របស់អ្នកមានតម្លៃប៉ុន្មានសម្រាប់ក្រុមហ៊ុន និងអតិថិជន។

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

ហ្គេមណាមួយមានដោយសារការផ្តល់មូលនិធិ៖ ដោយផ្ទាល់ ឬដោយប្រយោលពីអ្នកលេង។ នៅ Playgendary យើងបង្កើតហ្គេមទូរស័ព្ទឥតគិតថ្លៃដែលមានមនុស្សជាង 200 នាក់ចូលរួមដោយផ្ទាល់នៅក្នុងការបង្កើតរបស់ពួកគេ។ តើយើងប្រើ DevOps យ៉ាងដូចម្តេច?

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

ឥឡូវនេះយើងកំពុងប្រើប្រាស់ Jenkins យ៉ាងសកម្មជាឧបករណ៍បំពង់ CI/CD សម្រាប់ដំណើរការបំពង់ដំឡើងទាំងអស់ជាមួយ Unity និងការដាក់ពង្រាយជាបន្តបន្ទាប់ទៅកាន់ App Store និង Play Market ។ ច្រើនទៀតពីប្រអប់ឧបករណ៍បុរាណ៖

• អាសាណា - សម្រាប់ការគ្រប់គ្រងគម្រោង។ ការរួមបញ្ចូលជាមួយ Jenkins ត្រូវបានកំណត់រចនាសម្ព័ន្ធ។
• Google Meet - សម្រាប់ការប្រជុំជាវីដេអូ។
• Slack - សម្រាប់ការទំនាក់ទំនង និងការជូនដំណឹងផ្សេងៗ រួមទាំងការជូនដំណឹងពី Jenkins ។
• Atlassian Confluence - សម្រាប់ឯកសារ និងការងារជាក្រុម។

ផែនការភ្លាមៗរបស់យើងរួមមានការណែនាំការវិភាគកូដឋិតិវន្តដោយប្រើ SonarQube និងការធ្វើតេស្ត UI ដោយស្វ័យប្រវត្តិដោយប្រើ Selenium នៅដំណាក់កាលនៃការរួមបញ្ចូលជាបន្តបន្ទាប់។

ជំនួសឱ្យការសន្និដ្ឋានមួយ

ខ្ញុំចង់បញ្ចប់ដោយការគិតដូចតទៅ៖ ដើម្បីក្លាយជាវិស្វករ DevOps ដែលមានសមត្ថភាពខ្ពស់ វាពិតជាមានសារៈសំខាន់ណាស់ក្នុងការរៀនពីរបៀបទំនាក់ទំនងផ្ទាល់ជាមួយមនុស្ស។

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

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

ប្រភព: www.habr.com