តើ DevOps ជានរណា?

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

យើងនៅតែស្វែងរកសហសេវិក ព្រោះនៅពីក្រោយស្លាក DevOps មានស្រទាប់វិស្វករជាច្រើនប្រភេទផ្សេងគ្នាលាក់ខ្លួន។

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

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

ដូច្នេះតើនរណាជាវិស្វករ DevOps?

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

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

រឿង "អស្ចារ្យ" បានបង្ហាញខ្លួន - docker ។ ហេតុអ្វីអស្ចារ្យ? បាទ/ចាស មានតែដោយសារតែការបង្កើតភាពឯកោនៅក្នុង chroot ឬគុក ក៏ដូចជា OpenVZ ដែលត្រូវការចំណេះដឹងមិនសំខាន់នៃ OS ផ្ទុយទៅវិញ ឧបករណ៍ប្រើប្រាស់អនុញ្ញាតឱ្យអ្នកបង្កើតបរិយាកាសកម្មវិធីដាច់ដោយឡែកនៅលើម៉ាស៊ីនជាក់លាក់មួយដែលមានអ្វីគ្រប់យ៉ាងដែលចាំបាច់នៅខាងក្នុងនិងដៃ។ លើសពីការគ្រប់គ្រងនៃការអភិវឌ្ឍន៍ម្តងទៀត ហើយអ្នកគ្រប់គ្រងប្រព័ន្ធអាចគ្រប់គ្រងបានតែជាមួយម៉ាស៊ីនតែមួយប៉ុណ្ណោះ ដែលធានាបាននូវសុវត្ថិភាព និងលទ្ធភាពខ្ពស់របស់វា ដែលជាការសម្រួលឡូជីខល។ ប៉ុន្តែវឌ្ឍនភាពមិននៅស្ងៀមទេ ហើយប្រព័ន្ធកាន់តែស្មុគ្រស្មាញម្តងទៀត មានធាតុផ្សំកាន់តែច្រើនឡើងៗ ម៉ាស៊ីនមួយលែងបំពេញតម្រូវការរបស់ប្រព័ន្ធហើយ វាចាំបាច់ក្នុងការបង្កើតចង្កោម យើងត្រលប់ទៅអ្នកគ្រប់គ្រងប្រព័ន្ធម្តងទៀតដែលមាន អាចបង្កើតប្រព័ន្ធទាំងនេះបាន។

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

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

វិស្វករសាងសង់ / វិស្វករចេញផ្សាយ

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

Ops គឺខុសគ្នាខ្លាំងណាស់

យើងបន្តទៅមុខម្តងហើយម្តងទៀត វត្តមាននៃទំនួលខុសត្រូវជាច្រើន ហើយកង្វះបុគ្គលិកដែលមានសមត្ថភាព ជំរុញឱ្យយើងឆ្ពោះទៅរកជំនាញដ៏តឹងរឹង ដូចជាផ្សិតបន្ទាប់ពីភ្លៀង ប្រតិបត្តិការផ្សេងៗលេចឡើង៖

• TechOps - អ្នកគ្រប់គ្រងប្រព័ន្ធ enikey aka HelpDesk Engineer
• LiveOps - អ្នកគ្រប់គ្រងប្រព័ន្ធទទួលខុសត្រូវជាចម្បងសម្រាប់បរិស្ថានផលិតកម្ម
• CloudOps - អ្នកគ្រប់គ្រងប្រព័ន្ធដែលមានឯកទេសលើពពកសាធារណៈ Azure, AWS, GCP ជាដើម។
• PlatOps/InfraOps/SysOps - អ្នកគ្រប់គ្រងប្រព័ន្ធហេដ្ឋារចនាសម្ព័ន្ធ។
• NetOps - អ្នកគ្រប់គ្រងបណ្តាញ
• SecOps - អ្នកគ្រប់គ្រងប្រព័ន្ធដែលមានឯកទេសខាងសន្តិសុខព័ត៌មាន - ការអនុលោមតាម PCI ការអនុលោមតាម CIS ការបំណះជាដើម។

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

ដើម្បីអនុវត្តការងារ និងទំនួលខុសត្រូវប្រភេទនេះ បុគ្គលនេះត្រូវតែមានមធ្យោបាយគ្រប់គ្រងមិនត្រឹមតែដំណើរការអភិវឌ្ឍ និងការធ្វើតេស្តប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធផលិតផល ក៏ដូចជាការធ្វើផែនការធនធានផងដែរ។ DevOps នៅក្នុងការយល់ដឹងនេះមិនអាចមានទីតាំងនៅ IT ឬនៅក្នុង R&D ឬសូម្បីតែនៅក្នុង PMO វាត្រូវតែមានឥទ្ធិពលនៅក្នុងគ្រប់ផ្នែកទាំងនេះ - នាយកបច្ចេកទេសរបស់ក្រុមហ៊ុន ប្រធានផ្នែកបច្ចេកទេស។

តើនេះជាការពិតនៅក្នុងក្រុមហ៊ុនរបស់អ្នកទេ? - ខ្ញុំ​សង្ស័យ។ ក្នុងករណីភាគច្រើន វាជា IT ឬ R&D ។

កង្វះមូលនិធិ និងសមត្ថភាពក្នុងការជះឥទ្ធិពលយ៉ាងហោចណាស់ផ្នែកមួយនៃសកម្មភាពទាំងបីនេះនឹងផ្លាស់ប្តូរទម្ងន់នៃបញ្ហាឆ្ពោះទៅរកកន្លែងដែលការផ្លាស់ប្តូរទាំងនេះងាយស្រួលអនុវត្ត ដូចជាការអនុវត្តការរឹតបន្តឹងបច្ចេកទេសលើការចេញផ្សាយទាក់ទងនឹងកូដ "កខ្វក់" យោងទៅតាមឋិតិវន្ត។ ប្រព័ន្ធវិភាគ។ នោះគឺនៅពេលដែល PMO កំណត់ពេលវេលាកំណត់យ៉ាងតឹងរ៉ឹងសម្រាប់ការចេញផ្សាយមុខងារ R&D មិនអាចបង្កើតលទ្ធផលដែលមានគុណភាពខ្ពស់ក្នុងរយៈពេលកំណត់ទាំងនេះ ហើយផលិតវាឱ្យល្អបំផុតដែលវាអាចធ្វើបាន ដោយទុកការកែលម្អសម្រាប់ពេលក្រោយ DevOps ទាក់ទងនឹង IT រារាំងការចេញផ្សាយដោយមធ្យោបាយបច្ចេកទេស។ . កង្វះសិទ្ធិអំណាចក្នុងការផ្លាស់ប្តូរស្ថានភាព ក្នុងករណីបុគ្គលិកដែលមានទំនួលខុសត្រូវ នាំឱ្យមានការបង្ហាញពីការទទួលខុសត្រូវខ្ពស់ចំពោះអ្វីដែលពួកគេមិនអាចមានឥទ្ធិពល ជាពិសេសប្រសិនបើបុគ្គលិកទាំងនេះយល់ និងឃើញកំហុស និងរបៀបកែតម្រូវពួកគេ - "សុភមង្គលគឺភាពល្ងង់ខ្លៅ", ហើយជាផលវិបាកដល់ការអស់កម្លាំង និងការបាត់បង់បុគ្គលិកទាំងនេះ។

ទីផ្សារធនធាន DevOps

សូមក្រឡេកមើលកន្លែងទំនេរជាច្រើនសម្រាប់មុខតំណែង DevOps ពីក្រុមហ៊ុនផ្សេងៗគ្នា។

យើងត្រៀមខ្លួនជួបជាមួយអ្នក ប្រសិនបើអ្នក៖

1. អ្នកជាម្ចាស់ Zabbix ហើយដឹងថា Prometheus ជាអ្វី។
2. Iptables;
3. និស្សិតបណ្ឌិត BASH;
4. សាស្រ្តាចារ្យ Ansible;
5. លីនុច Guru;
6. ដឹងពីរបៀបប្រើការបំបាត់កំហុស និងស្វែងរកបញ្ហាកម្មវិធីរួមគ្នាជាមួយអ្នកអភិវឌ្ឍន៍ (php/java/python);
7. ផ្លូវមិនធ្វើឱ្យអ្នក hysterical;
8. យកចិត្តទុកដាក់យ៉ាងខ្លាំងចំពោះសុវត្ថិភាពប្រព័ន្ធ;
9. បម្រុងទុក "អ្វីទាំងអស់ និងអ្វីៗគ្រប់យ៉ាង" ហើយក៏អាចស្តារ "អ្វីទាំងអស់ និងអ្វីៗទាំងអស់" នេះដោយជោគជ័យផងដែរ។
10. អ្នកដឹងពីរបៀបកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធក្នុងវិធីមួយដើម្បីទទួលបានអតិបរមាចេញពីអប្បបរមា។
11. រៀបចំការចម្លងមុនពេលចូលគេងនៅលើ Postgres និង MySQL;
12. ការដំឡើង និងកែតម្រូវ CI/CD គឺចាំបាច់សម្រាប់អ្នកដូចជាអាហារពេលព្រឹក/អាហារថ្ងៃត្រង់/អាហារពេលល្ងាច។
13. មានបទពិសោធន៍ជាមួយ AWS;
14. ត្រៀមខ្លួនដើម្បីអភិវឌ្ឍជាមួយក្រុមហ៊ុន;

ដូច្នេះ:

• ពី 1 ទៅ 6 - អ្នកគ្រប់គ្រងប្រព័ន្ធ
• 7 - ការគ្រប់គ្រងបណ្តាញតិចតួចដែលសមនឹងអ្នកគ្រប់គ្រងប្រព័ន្ធកម្រិតកណ្តាល
• 8 - សុវត្ថិភាពតិចតួច ដែលជាកាតព្វកិច្ចសម្រាប់អ្នកគ្រប់គ្រងប្រព័ន្ធកម្រិតកណ្តាល
• 9-11 - អ្នកគ្រប់គ្រងប្រព័ន្ធកណ្តាល
• 12 - អាស្រ័យលើភារកិច្ចដែលបានកំណត់ ទាំងអ្នកគ្រប់គ្រងប្រព័ន្ធកណ្តាល ឬវិស្វករសាងសង់
• 13 - Virtualization - Middle System Administrator ឬគេហៅថា CloudOps ចំណេះដឹងកម្រិតខ្ពស់នៃសេវាកម្មនៃគេហទំព័របង្ហោះជាក់លាក់មួយ សម្រាប់ការប្រើប្រាស់មូលនិធិប្រកបដោយប្រសិទ្ធភាព និងកាត់បន្ថយបន្ទុកលើការថែទាំ

សរុបមក កន្លែងទំនេរនេះ យើងអាចនិយាយបានថា Middle/Senior System Administrator គឺគ្រប់គ្រាន់សម្រាប់បុរស។

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

តោះពិចារណាកន្លែងទំនេរមួយទៀត៖

1. បទពិសោធន៍ក្នុងការសាងសង់ប្រព័ន្ធផ្ទុកខ្ពស់;
2. ចំនេះដឹងដ៏ល្អនៃប្រព័ន្ធប្រតិបត្តិការលីនុច កម្មវិធីប្រព័ន្ធទូទៅ និងជង់គេហទំព័រ (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. បទពិសោធន៍ជាមួយប្រព័ន្ធនិម្មិត (KVM, VMWare, LXC/Docker);
4. ជំនាញភាសាស្គ្រីប;
5. ការយល់ដឹងអំពីគោលការណ៍ប្រតិបត្តិការនៃបណ្តាញពិធីការបណ្តាញ;
6. ការយល់ដឹងអំពីគោលការណ៍នៃការកសាងប្រព័ន្ធដែលអត់ឱនចំពោះកំហុស;
7. ឯករាជ្យភាពនិងគំនិតផ្តួចផ្តើម;

តោះមើល៖

• 1 - អ្នកគ្រប់គ្រងប្រព័ន្ធជាន់ខ្ពស់
• 2 - អាស្រ័យលើអត្ថន័យដែលបានដាក់ក្នុងជង់នេះ - អ្នកគ្រប់គ្រងប្រព័ន្ធមជ្ឈិម/ជាន់ខ្ពស់
• 3 - បទពិសោធន៍ការងារ រួមទាំងអាចមានន័យថា - "ចង្កោមមិនបានលើកឡើងទេ ប៉ុន្តែបានបង្កើត និងគ្រប់គ្រងម៉ាស៊ីននិម្មិត មាន Docker host មួយ ការចូលប្រើកុងតឺន័រមិនអាចប្រើបានទេ" - Middle System Administrator
• 4 - អ្នកគ្រប់គ្រងប្រព័ន្ធ Junior - បាទ អ្នកគ្រប់គ្រងដែលមិនចេះសរសេរស្គ្រីបស្វ័យប្រវត្តិកម្មមូលដ្ឋាន ដោយមិនគិតពីភាសា មិនមែនជាអ្នកគ្រប់គ្រង - enikey ។
• 5 - អ្នកគ្រប់គ្រងប្រព័ន្ធកណ្តាល
• 6 - អ្នកគ្រប់គ្រងប្រព័ន្ធជាន់ខ្ពស់

ដើម្បីសង្ខេប - អ្នកគ្រប់គ្រងប្រព័ន្ធកណ្តាល / ជាន់ខ្ពស់

មួយ​ផ្សេង​ទៀត:

1. អភិវឌ្ឍបទពិសោធន៍;
2. មានបទពិសោធន៍ក្នុងការប្រើប្រាស់ផលិតផលមួយ ឬច្រើនដើម្បីបង្កើតដំណើរការ CI/CD។ Gitlab CI នឹងក្លាយជាអត្ថប្រយោជន៍មួយ;
3. ធ្វើការជាមួយធុងនិងនិម្មិត; បើធ្លាប់ Docker ល្អ តែបើប្រើ k8s ល្អមើល!
4. បទពិសោធន៍ការងារក្នុងក្រុមរហ័សរហួន;
5. ចំណេះដឹងនៃភាសាសរសេរកម្មវិធីណាមួយ;

សូម​មើល:

• 1 - ហ៊ឺ... តើបុរសមានន័យយ៉ាងណា? =) ភាគច្រើនទំនងជាពួកគេមិនដឹងថាមានអ្វីលាក់បាំងនៅពីក្រោយវាទេ។
• ២- វិស្វករសំណង់
• 3 - អ្នកគ្រប់គ្រងប្រព័ន្ធកណ្តាល
• 4 - ជំនាញទន់ យើងនឹងមិនពិចារណាវាសម្រាប់ពេលនេះទេ ទោះបីជា Agile គឺជារឿងមួយផ្សេងទៀតដែលត្រូវបានបកស្រាយតាមរបៀបដែលងាយស្រួលក៏ដោយ។
• 5 - ពាក្យសំដីពេក - វាអាចជាភាសាស្គ្រីប ឬចងក្រងមួយ។ ខ្ញុំឆ្ងល់ថាតើការសរសេរ Pascal និង Basic នៅសាលានឹងសមនឹងពួកគេទេ? =)

ខ្ញុំក៏ចង់ទុកចំណាំទាក់ទងនឹងចំណុចទី 3 ដើម្បីពង្រឹងការយល់ដឹងអំពីមូលហេតុដែលចំណុចនេះត្រូវបានគ្របដណ្តប់ដោយអ្នកគ្រប់គ្រងប្រព័ន្ធ។ Kubernetes គឺគ្រាន់តែជាការ orchestration ដែលជាឧបករណ៍ដែលភ្ជាប់ពាក្យបញ្ជាដោយផ្ទាល់ទៅកាន់កម្មវិធីបញ្ជាបណ្តាញ និងម៉ាស៊ីននិម្មិត/ឯកោនិម្មិតនៅក្នុងពាក្យបញ្ជាមួយចំនួន ហើយអនុញ្ញាតឱ្យអ្នកធ្វើការទំនាក់ទំនងជាមួយពួកគេដោយអរូបី នោះជាអ្វីទាំងអស់។ ជាឧទាហរណ៍ ចូរយើងយក 'build framework' Make ដែលតាមវិធីនេះ ខ្ញុំមិនចាត់ទុក framework ទេ។ បាទ/ចាស ខ្ញុំដឹងអំពីម៉ូដនៃការ shoving Make គ្រប់ទីកន្លែង ដែលវាចាំបាច់ និងមិនត្រូវការ - រុំ Maven ក្នុង Make ជាឧទាហរណ៍ ធ្ងន់ធ្ងរ?
សំខាន់ Make គឺគ្រាន់តែជាការរុំពីលើសែល ដែលធ្វើអោយការចងក្រង ការភ្ជាប់ និងការចងក្រងពាក្យបញ្ជាបរិស្ថានដូច k8s ដែរ។

មានពេលមួយ ខ្ញុំបានសម្ភាសបុរសម្នាក់ដែលប្រើ k8s នៅក្នុងការងាររបស់គាត់នៅលើ OpenStack ហើយគាត់បាននិយាយអំពីរបៀបដែលគាត់ដាក់ឱ្យប្រើប្រាស់សេវាកម្មនៅលើវា ប៉ុន្តែនៅពេលដែលខ្ញុំសួរអំពី OpenStack វាប្រែថាវាត្រូវបានគ្រប់គ្រង ក៏ដូចជាលើកឡើងដោយប្រព័ន្ធ។ អ្នកគ្រប់គ្រង។ តើ​អ្នក​ពិត​ជា​គិត​ថា​អ្នក​ដែល​បាន​ដំឡើង OpenStack មិន​ថា​គាត់​ប្រើ​វេទិកា​អ្វី​នៅ​ពី​ក្រោយ​គាត់​នោះ​គឺ​មិន​អាច​ប្រើ k8s ទេ?
បេក្ខជននេះមិនមែនជា DevOps ទេ ប៉ុន្តែជាអ្នកគ្រប់គ្រងប្រព័ន្ធ ហើយដើម្បីឱ្យកាន់តែច្បាស់លាស់ អ្នកគ្រប់គ្រង Kubernetes ។

អនុញ្ញាតឱ្យយើងសង្ខេបម្តងទៀត - អ្នកគ្រប់គ្រងប្រព័ន្ធកណ្តាល / ជាន់ខ្ពស់នឹងគ្រប់គ្រាន់សម្រាប់ពួកគេ។

តើត្រូវថ្លឹងទម្ងន់ប៉ុន្មានក្រាម

ជួរនៃប្រាក់បៀវត្សរ៍ដែលបានស្នើឡើងសម្រាប់តំណែងទំនេរដែលបានចង្អុលបង្ហាញគឺ 90k-200k
ឥឡូវនេះខ្ញុំចង់គូរស្របគ្នារវាងរង្វាន់រូបិយវត្ថុរបស់អ្នកគ្រប់គ្រងប្រព័ន្ធ និងវិស្វករ DevOps ។

ជាគោលការណ៍ ដើម្បីធ្វើឱ្យរឿងសាមញ្ញៗ អ្នកអាចបែងចែកចំណាត់ថ្នាក់ដោយផ្អែកលើបទពិសោធន៍ការងារ ទោះបីជាវាមិនពិតប្រាកដក៏ដោយ ប៉ុន្តែសម្រាប់គោលបំណងនៃអត្ថបទវានឹងគ្រប់គ្រាន់។

បទពិសោធន៍មួយ៖

1. រហូតដល់ 3 ឆ្នាំ - យុវជន
2. រហូតដល់ 6 ឆ្នាំ - កណ្តាល
3. ច្រើនជាង 6 - ជាន់ខ្ពស់

គេហទំព័រស្វែងរកបុគ្គលិកផ្តល់ជូន៖
អ្នកគ្រប់គ្រងប្រព័ន្ធ៖

1. ក្មេងអាយុ 2 ឆ្នាំ - 50k ជូត។
2. មធ្យម - 5 ឆ្នាំ - 70k ជូត។
3. ជាន់ខ្ពស់ - 11 ឆ្នាំ - 100k ជូត។

វិស្វករ DevOps៖

1. ក្មេងអាយុ 2 ឆ្នាំ - 100k ជូត។
2. មធ្យម - 3 ឆ្នាំ - 160k ជូត។
3. ជាន់ខ្ពស់ - 6 ឆ្នាំ - 220k ជូត។

យោងតាមបទពិសោធន៍នៃ "DevOps" បទពិសោធន៍ត្រូវបានប្រើដែលយ៉ាងហោចណាស់ប៉ះពាល់ដល់ SDLC ។

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

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

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

ដូច្នេះតើពួកគេជានរណា? DevOps ឬអ្នកគ្រប់គ្រងប្រព័ន្ធលោភលន់? =)

តើធ្វើដូចម្តេចដើម្បីបន្តរស់នៅ?

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

កម្មករ - រៀន។ កែលម្អចំណេះដឹងរបស់អ្នកជានិច្ច មើលរូបភាពទូទៅនៃដំណើរការ និងតាមដានផ្លូវទៅកាន់គោលដៅរបស់អ្នក។ អ្នកអាចក្លាយជាអ្នកណាដែលអ្នកចង់បាន អ្នកគ្រាន់តែព្យាយាម។

ប្រភព: www.habr.com