🥇រដ្ឋ DevOps នៅប្រទេសរុស្ស៊ីឆ្នាំ ២០២០

តើធ្វើដូចម្តេចដើម្បីយល់ពីស្ថានភាពនៃអ្វីមួយ?

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

ប៉ុន្តែថ្ងៃបានមកដល់ហើយដែលការសិក្សាបែបនេះត្រូវបានធ្វើឡើងហើយថ្ងៃនេះយើងនឹងនិយាយអំពីលទ្ធផល។ ស្ថានភាព DevOps នៅប្រទេសរុស្ស៊ីត្រូវបានសិក្សារួមគ្នាដោយក្រុមហ៊ុន "អ៊ិចប្រេស ៤២"ហើយ"អនទីកូ"។ Express 42 ជួយក្រុមហ៊ុនបច្ចេកវិទ្យាអនុវត្ត និងអភិវឌ្ឍការអនុវត្ត និងឧបករណ៍ DevOps ហើយជាក្រុមហ៊ុនដំបូងគេដែលនិយាយអំពី DevOps នៅក្នុងប្រទេសរុស្ស៊ី។ អ្នកនិពន្ធនៃការសិក្សា Igor Kurochkin និង Vitaly Khabarov ត្រូវបានចូលរួមនៅក្នុងការវិភាគ និងប្រឹក្សាយោបល់នៅ Express 42 ខណៈពេលដែលមានប្រវត្តិបច្ចេកទេសពីប្រតិបត្តិការ និងបទពិសោធន៍នៅក្នុងក្រុមហ៊ុនផ្សេងៗគ្នា។ អស់រយៈពេល 8 ឆ្នាំមកហើយ សហសេវិកបានមើលក្រុមហ៊ុន និងគម្រោងរាប់សិប - ពីការចាប់ផ្តើមអាជីវកម្មរហូតដល់សហគ្រាស - ដោយមានបញ្ហាផ្សេងៗគ្នា ក៏ដូចជាភាពចាស់ទុំខាងវប្បធម៌ និងវិស្វកម្មផ្សេងៗគ្នា។

នៅក្នុងរបាយការណ៍របស់ពួកគេ Igor និង Vitaly បានប្រាប់ពីបញ្ហានៅក្នុងដំណើរការនៃការស្រាវជ្រាវ របៀបដែលពួកគេបានដោះស្រាយ ក៏ដូចជារបៀបដែលការស្រាវជ្រាវ DevOps ត្រូវបានធ្វើឡើងជាគោលការណ៍ និងហេតុអ្វីបានជា Express 42 សម្រេចចិត្តធ្វើដោយខ្លួនឯង។ របាយការណ៍របស់ពួកគេអាចត្រូវបានមើល នៅទីនេះ.

ការស្រាវជ្រាវ DevOps

ការសន្ទនាត្រូវបានចាប់ផ្តើមដោយ Igor Kurochkin ។

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

នៅទីនេះយើងមានបញ្ហាទីមួយ ហើយបន្ទាប់ពីវាពីរទៀត៖

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

តោះមើលពីរបៀបដែលការវិភាគរដ្ឋរបស់ DevOps ត្រូវបានធ្វើនៅជុំវិញពិភពលោក។

ប្រវត្តិសាស្រ្ត

ការស្រាវជ្រាវ DevOps ត្រូវបានធ្វើឡើងតាំងពីឆ្នាំ 2011។ Puppet ដែលជាអ្នកបង្កើតប្រព័ន្ធគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធ គឺជាអ្នកដំបូងដែលដឹកនាំពួកគេ។ នៅពេលនោះ វាគឺជាឧបករណ៍សំខាន់មួយសម្រាប់ពិពណ៌នាអំពីហេដ្ឋារចនាសម្ព័ន្ធក្នុងទម្រង់ជាកូដ។ រហូតមកដល់ឆ្នាំ 2013 ការសិក្សាទាំងនេះគ្រាន់តែជាការស្ទង់មតិដែលត្រូវបានបិទ ហើយមិនមានរបាយការណ៍សាធារណៈទេ។

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

ក្នុងឆ្នាំ 2016 អ្នកនិពន្ធនៃការសិក្សាបានបង្កើតក្រុមហ៊ុនផ្ទាល់ខ្លួន DORA (DevOps Research and Assessment) បានបោះពុម្ពរបាយការណ៍ប្រចាំឆ្នាំ។ នៅឆ្នាំបន្ទាប់ DORA និង Puppet បានចេញផ្សាយរបាយការណ៍រួមចុងក្រោយរបស់ពួកគេ។

ហើយបន្ទាប់មកអ្វីដែលគួរឱ្យចាប់អារម្មណ៍បានចាប់ផ្តើម:

នៅឆ្នាំ 2018 ក្រុមហ៊ុនបានបែកបាក់គ្នា ហើយរបាយការណ៍ឯករាជ្យពីរត្រូវបានចេញផ្សាយ៖ មួយពី Puppet ទីពីរមកពី DORA រួមគ្នាជាមួយ Google ។ DORA បានបន្តប្រើប្រាស់វិធីសាស្រ្តរបស់ខ្លួនជាមួយនឹងរង្វាស់សំខាន់ៗ ទម្រង់ប្រតិបត្តិការ និងការអនុវត្តផ្នែកវិស្វកម្មដែលជះឥទ្ធិពលដល់រង្វាស់សំខាន់ៗ និងដំណើរការរបស់ក្រុមហ៊ុនទាំងមូល។ ហើយ Puppet បានផ្តល់វិធីសាស្រ្តផ្ទាល់ខ្លួនជាមួយនឹងការពិពណ៌នាអំពីដំណើរការ និងការវិវត្តនៃ DevOps ។ ប៉ុន្តែរឿងនេះមិនបានចាក់ឬសទេ នៅឆ្នាំ 2019 អាយ៉ងបានបោះបង់ចោលវិធីសាស្រ្តនេះហើយបានចេញផ្សាយរបាយការណ៍កំណែថ្មី ដែលរាយបញ្ជីការអនុវត្តសំខាន់ៗ និងរបៀបដែលវាប៉ះពាល់ដល់ DevOps តាមទស្សនៈរបស់ពួកគេ។ បន្ទាប់មកព្រឹត្តិការណ៍មួយទៀតបានកើតឡើង៖ Google បានទិញ DORA ហើយពួកគេបានចេញរបាយការណ៍មួយផ្សេងទៀត។ អ្នកប្រហែលជាធ្លាប់ឃើញគាត់ហើយ។

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

ប៉ុន្តែនៅមិនទាន់មានការប្រកាសពី DORA និង Google ទេ។ នៅក្នុងខែឧសភា នៅពេលដែលការស្ទង់មតិបានចាប់ផ្តើមជាធម្មតា មានព័ត៌មានថា Nicole Forsgren ដែលជាស្ថាបនិកម្នាក់នៃ DORA បានផ្លាស់ទៅក្រុមហ៊ុនមួយផ្សេងទៀត។ ដូច្នេះហើយ យើងសន្មត់ថានឹងមិនមានការស្រាវជ្រាវ និងរបាយការណ៍ពី DORA នៅឆ្នាំនេះទេ។

តើអ្វីៗនៅរុស្ស៊ីយ៉ាងម៉េចដែរ?

យើងមិនទាន់បានធ្វើការស្រាវជ្រាវ DevOps ទេ។ យើងបាននិយាយនៅក្នុងសន្និសិទ ដោយប្រាប់ពីការរកឃើញរបស់អ្នកដទៃឡើងវិញ ហើយ Raiffeisenbank បានបកប្រែ "State of DevOps" សម្រាប់ឆ្នាំ 2019 (អ្នកអាចស្វែងរកការប្រកាសរបស់ពួកគេនៅលើHabré) អរគុណច្រើនចំពោះពួកគេ។ ហើយវាទាំងអស់។

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

ដំណើរការស្រាវជ្រាវ

របាយការណ៍នេះគ្រាន់តែជាផ្នែកចុងក្រោយប៉ុណ្ណោះ។ ដំណើរការស្រាវជ្រាវទាំងមូលមានបួនជំហានធំៗ៖

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

អ្នកចូលរួម

របាយការណ៍បរទេសទាំងអស់ចាប់ផ្តើមដោយរូបភាពនៃអ្នកចូលរួម ហើយភាគច្រើនមិនមែនមកពីប្រទេសរុស្ស៊ីទេ។ ភាគរយនៃអ្នកឆ្លើយសំណួររុស្ស៊ីប្រែប្រួលពី 5 ទៅ 1% ពីមួយឆ្នាំទៅមួយឆ្នាំ ហើយនេះមិនអនុញ្ញាតឱ្យមានការសន្និដ្ឋានណាមួយឡើយ។

ផែនទីពីរបាយការណ៍ Accelerate State of DevOps 2019៖

នៅក្នុងការសិក្សារបស់យើង យើងបានធ្វើការសម្ភាសន៍មនុស្ស 889 នាក់ - នេះគឺច្រើនណាស់ (ការស្ទង់មតិរបស់ DORA អំពីមនុស្សមួយពាន់នាក់ក្នុងមួយឆ្នាំនៅក្នុងរបាយការណ៍របស់វា) ហើយនៅទីនេះយើងបានសម្រេចគោលដៅ:

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

មុខតំណែង និងឧស្សាហកម្ម

អ្នកឆ្លើយសំណួររបស់យើងតំណាងឱ្យឧស្សាហកម្មរាប់សិប។ ការងារពាក់កណ្តាលនៃបច្ចេកវិទ្យាព័ត៌មាន។ វាត្រូវបានបន្តដោយសេវាកម្មហិរញ្ញវត្ថុ ពាណិជ្ជកម្ម ទូរគមនាគមន៍ និងផ្សេងៗទៀត។ ក្នុងចំណោមមុខតំណែងមាន អ្នកឯកទេស (អ្នកអភិវឌ្ឍន៍ អ្នកសាកល្បង វិស្វករប្រតិបត្តិការ) និងបុគ្គលិកគ្រប់គ្រង (ប្រធានក្រុម ក្រុមតំបន់ នាយក):

ម្នាក់ក្នុងចំណោមពីរនាក់ធ្វើការឱ្យក្រុមហ៊ុនខ្នាតមធ្យម។ រាល់អ្នកទីបីធ្វើការនៅក្នុងក្រុមហ៊ុនធំ ៗ ។ ភាគច្រើនធ្វើការជាក្រុមរហូតដល់ 9 នាក់។ ដោយឡែកពីគ្នា យើងបានសួរអំពីសកម្មភាពសំខាន់ៗ ហើយភាគច្រើនគឺទាក់ទងទៅនឹងប្រតិបត្តិការ ហើយប្រហែល 40% ត្រូវបានចូលរួមនៅក្នុងការអភិវឌ្ឍន៍៖

ដូច្នេះយើងបានប្រមូលព័ត៌មានសម្រាប់ការប្រៀបធៀបនិងការវិភាគរបស់អ្នកតំណាងនៃឧស្សាហកម្ម ក្រុមហ៊ុន ក្រុមផ្សេងៗ។ សហសេវិករបស់ខ្ញុំ Vitaly Khabarov នឹងប្រាប់អំពីការវិភាគ។

ការវិភាគនិងប្រៀបធៀប

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

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

សូចនាករសំខាន់ៗ

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

សូចនាករសំខាន់ៗ៖

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

DORA នៅក្នុងការស្រាវជ្រាវរបស់ខ្លួនបានរកឃើញទំនាក់ទំនងរវាងរង្វាស់ទាំងនេះ និងការអនុវត្តរបស់អង្គការ។ យើងក៏សាកល្បងវានៅក្នុងការសិក្សារបស់យើងដែរ។

ប៉ុន្តែដើម្បីប្រាកដថា រង្វាស់សំខាន់ៗទាំងបួនអាចមានឥទ្ធិពលលើអ្វីមួយ អ្នកត្រូវយល់ - តើវាទាក់ទងគ្នាដូចម្ដេច? DORA បានឆ្លើយនៅក្នុងការបញ្ជាក់ជាមួយនឹងការព្រមានមួយ: ទំនាក់ទំនងរវាងការផ្លាស់ប្តូរដែលមិនជោគជ័យ (Change Failure Rate) និងម៉ែត្របីផ្សេងទៀតគឺខ្សោយជាងបន្តិច។ យើងទទួលបានរូបភាពដូចគ្នា។ ប្រសិនបើពេលវេលាចែកចាយ ភាពញឹកញាប់នៃការដាក់ពង្រាយ និងពេលវេលានៃការស្តារឡើងវិញមានទំនាក់ទំនងគ្នាទៅវិញទៅមក (យើងបានបង្កើតទំនាក់ទំនងនេះតាមរយៈទំនាក់ទំនង Pearson និងតាមរយៈមាត្រដ្ឋាន Chaddock) នោះមិនមានទំនាក់ទំនងខ្លាំងបែបនេះជាមួយនឹងការផ្លាស់ប្តូរដែលមិនជោគជ័យនោះទេ។

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

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

ចំណុចសំខាន់នៅទីនេះគឺថា យើងបានរកឃើញការជាប់ទាក់ទងគ្នាយ៉ាងសំខាន់រវាងពេលវេលាចែកចាយ ពេលវេលានៃការស្តារឡើងវិញ និងប្រេកង់ដាក់ឱ្យប្រើប្រាស់។ ដូច្នេះហើយ យើងបានយករង្វាស់ទាំងបីនេះ ដើម្បីបែងចែកអ្នកឆ្លើយសំណួរជាក្រុមអនុវត្ត។

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

យើងបានប្រើការវិភាគតាមលំដាប់លំដោយ៖

យើងចែកចាយអ្នកឆ្លើយឆ្លងតាមលំហ n-dimensional ដែលសំរបសំរួលនៃអ្នកឆ្លើយនីមួយៗគឺជាចម្លើយរបស់ពួកគេចំពោះសំណួរ។
អ្នកឆ្លើយតបនីមួយៗត្រូវបានប្រកាសថាជាក្រុមតូចមួយ។
យើងផ្សំចង្កោមទាំងពីរដែលនៅជិតគ្នាបំផុតទៅជាចង្កោមធំមួយ។
យើងរកឃើញគូបន្ទាប់នៃចង្កោម ហើយបញ្ចូលពួកវាទៅក្នុងចង្កោមធំជាង។

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

ប៉ុន្តែមានបញ្ហាលាក់នៅទីនេះ៖ យើងមិនមានការរឹតបន្តឹងលើចំនួនចង្កោមទេ យើងអាចទទួលបាន 2, 3, 4, 10 ចង្កោម។ ហើយគំនិតដំបូងគឺ - ហេតុអ្វីមិនបែងចែកអ្នកឆ្លើយសំណួររបស់យើងទាំងអស់ជា 4 ក្រុម ដូច DORA ធ្វើ។ ប៉ុន្តែយើងបានរកឃើញថា ភាពខុសប្លែកគ្នារវាងក្រុមទាំងនេះក្លាយទៅជាមិនសំខាន់ ហើយយើងមិនអាចប្រាកដថាអ្នកឆ្លើយតបពិតជារបស់ក្រុមរបស់គាត់ មិនមែនសម្រាប់អ្នកជិតខាងនោះទេ។ យើងមិនទាន់អាចបែងចែកទីផ្សាររុស្ស៊ីជាបួនក្រុមបានទេ។ ដូច្នេះហើយ យើងបានដោះស្រាយលើទម្រង់បី ដែលមានភាពខុសប្លែកគ្នាយ៉ាងសំខាន់តាមស្ថិតិ៖

បន្ទាប់មក យើងកំណត់ទម្រង់ដោយក្រុម៖ យើងយកមធ្យមភាគសម្រាប់ម៉ែត្រនីមួយៗសម្រាប់ក្រុមនីមួយៗ ហើយចងក្រងតារាងនៃទម្រង់ប្រតិបត្តិការ។ តាមពិតទៅ យើងទទួលបានទម្រង់នៃការសម្តែងរបស់អ្នកចូលរួមជាមធ្យមនៅក្នុងក្រុមនីមួយៗ។ យើងបានកំណត់ទម្រង់ប្រសិទ្ធភាពចំនួនបី៖ ទាប មធ្យម ខ្ពស់៖

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

បន្ទាប់មកសំណួរកើតឡើង: របៀបប្រើទាំងអស់នេះ?

របៀបប្រើ

ប្រសិនបើយើងយកក្រុមណាមួយ 4 គន្លឹះសំខាន់ៗ ហើយអនុវត្តវាទៅក្នុងតារាង នោះក្នុង 85% នៃករណី យើងនឹងមិនអាចទទួលបានការប្រកួតពេញលេញនោះទេ - នេះគ្រាន់តែជាអ្នកចូលរួមជាមធ្យមប៉ុណ្ណោះ ហើយមិនមែនជាអ្វីដែលជាការពិតនោះទេ។ យើងទាំងអស់គ្នា (និងក្រុមនីមួយៗ) ខុសគ្នាបន្តិចបន្តួច។

យើងបានពិនិត្យ៖ យើងបានយកអ្នកឆ្លើយសំណួររបស់យើង និងទម្រង់ប្រតិបត្តិការរបស់ DORA ហើយមើលថាតើអ្នកឆ្លើយតបប៉ុន្មាននាក់សមនឹងទម្រង់នេះ ឬទម្រង់នោះ។ យើងបានរកឃើញថាមានតែ 16% នៃអ្នកឆ្លើយសំណួរច្បាស់ជាធ្លាក់ចូលទៅក្នុងទម្រង់មួយ។ នៅសល់ទាំងអស់ត្រូវបានរាយប៉ាយនៅកន្លែងណាមួយនៅចន្លោះ:

នេះមានន័យថាទម្រង់ប្រសិទ្ធភាពមានវិសាលភាពកំណត់។ ដើម្បីយល់ថាអ្នកនៅកន្លែងណាក្នុងការប៉ាន់ស្មានដំបូង អ្នកអាចប្រើតារាងនេះ៖ "អូ វាហាក់ដូចជាយើងខិតទៅជិតមធ្យម ឬខ្ពស់!" ប្រសិនបើអ្នកយល់ពីកន្លែងដែលត្រូវទៅបន្ទាប់ នេះប្រហែលជាគ្រប់គ្រាន់ហើយ។ ប៉ុន្តែប្រសិនបើគោលដៅរបស់អ្នកគឺថេរ ការកែលម្អជាបន្តបន្ទាប់ ហើយអ្នកចង់ដឹងកាន់តែច្បាស់ពីកន្លែងដែលត្រូវអភិវឌ្ឍ និងអ្វីដែលត្រូវធ្វើ នោះត្រូវការមូលនិធិបន្ថែម។ យើងហៅពួកគេថាម៉ាស៊ីនគិតលេខ៖

ម៉ាស៊ីនគិតលេខ DORA
ម៉ាស៊ីនគិតលេខ Express 42* (កំពុងអភិវឌ្ឍន៍)
ការអភិវឌ្ឍន៍ផ្ទាល់ខ្លួន (អ្នកអាចបង្កើតម៉ាស៊ីនគិតលេខខាងក្នុងផ្ទាល់ខ្លួនរបស់អ្នក) ។

តើពួកគេត្រូវការអ្វីខ្លះ? ដើម្បីយល់ដឹង:

តើក្រុមក្នុងស្ថាប័នរបស់យើងមានស្តង់ដាររបស់យើងឬទេ?
បើមិនអ៊ីចឹងទេ តើយើងអាចជួយវាលឿនក្នុងក្របខ័ណ្ឌជំនាញដែលក្រុមហ៊ុនយើងមានដែរឬទេ?
បើអញ្ចឹង តើយើងអាចធ្វើបានល្អជាងនេះទេ?

អ្នកក៏អាចប្រើពួកវាដើម្បីប្រមូលស្ថិតិនៅក្នុងក្រុមហ៊ុនផងដែរ៖

តើយើងមានក្រុមអ្វីខ្លះ?
បែងចែកក្រុមទៅជាទម្រង់;
សូមមើល៖ អូ ពាក្យបញ្ជាទាំងនេះមិនដំណើរការទេ (ពួកគេមិនដកខ្លួនចេញបន្តិចទេ) ប៉ុន្តែទាំងនេះគឺត្រជាក់ណាស់៖ ពួកគេដាក់ពង្រាយជារៀងរាល់ថ្ងៃដោយគ្មានកំហុស ពួកគេមានពេលវេលានាំមុខតិចជាងមួយម៉ោង។

ហើយបន្ទាប់មកអ្នកអាចដឹងថានៅក្នុងក្រុមហ៊ុនរបស់យើងមានជំនាញ និងឧបករណ៍ចាំបាច់សម្រាប់ក្រុមទាំងនោះដែលមិនទាន់មានកម្រិត។

ឬប្រសិនបើអ្នកយល់ថាអ្នកមានអារម្មណ៍អស្ចារ្យនៅក្នុងក្រុមហ៊ុន អ្នកល្អជាងមនុស្សជាច្រើន បន្ទាប់មកអ្នកអាចមើលទៅកាន់តែទូលំទូលាយបន្តិច។ នេះគ្រាន់តែជាឧស្សាហកម្មរុស្ស៊ីប៉ុណ្ណោះ៖ តើយើងអាចទទួលបានជំនាញចាំបាច់ក្នុងឧស្សាហកម្មរុស្ស៊ីដើម្បីពន្លឿនខ្លួនឯងបានទេ? ម៉ាស៊ីនគិតលេខ Express 42 នឹងជួយនៅទីនេះ (វាកំពុងស្ថិតក្រោមការអភិវឌ្ឍន៍)។ ប្រសិនបើអ្នកបាន outgrown ទីផ្សាររុស្ស៊ី, បន្ទាប់មកមើល ម៉ាស៊ីនគិតលេខ DORA និងទៅកាន់ទីផ្សារពិភពលោក។

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

ចូរបន្តទៅភាពផ្អែមល្ហែមបំផុត - ការប្រៀបធៀប។

ប្រៀបធៀប

ដំបូងឡើយ យើងចង់ប្រៀបធៀបឧស្សាហកម្មរុស្ស៊ីជាមួយឧស្សាហកម្មលោកខាងលិច។ បើយើងប្រៀបធៀបដោយផ្ទាល់ យើងឃើញថាយើងមានកម្រងព័ត៌មានតិចជាង ហើយពួកវាមានលាយឡំគ្នាច្រើនបន្តិច ព្រំប្រទល់កាន់តែច្បាស់បន្តិច៖

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

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

ប៉ុន្តែនៅឆ្នាំនេះគឺពិសេស ហើយយើងបានសម្រេចចិត្តពិនិត្យមើលថាតើក្រុមហ៊ុនកំពុងដំណើរការយ៉ាងដូចម្តេចនៅក្នុងជំងឺរាតត្បាត៖ ក្រុមដែលមានទម្រង់ខ្ពស់កំពុងធ្វើបានល្អជាងមុន និងមានអារម្មណ៍ប្រសើរជាងមធ្យមភាគឧស្សាហកម្ម៖

1,5-2 ដងទំនងជានឹងចេញផលិតផលថ្មី,
ទំនងជា 2 ដងក្នុងការធ្វើឱ្យប្រសើរឡើងនូវភាពជឿជាក់ និង/ឬដំណើរការនៃហេដ្ឋារចនាសម្ព័ន្ធកម្មវិធី។

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

តើមានអ្វីផ្សេងទៀតបានជួយក្រុមរបស់យើង?

ការអនុវត្តវិស្វកម្ម

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

វេទិកាជាសេវាកម្ម

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

ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ

អ្វីគ្រប់យ៉ាងគឺពិតជាស្តង់ដារនៅទីនេះ។ យើងបានរកឃើញទំនាក់ទំនងរវាងការធ្វើស្វ័យប្រវត្តិកម្មនៃកូដហេដ្ឋារចនាសម្ព័ន្ធ និងចំនួនព័ត៌មានដែលត្រូវបានរក្សាទុកនៅក្នុងឃ្លាំងហេដ្ឋារចនាសម្ព័ន្ធ។ ពាក្យបញ្ជាទម្រង់ខ្ពស់រក្សាទុកព័ត៌មានបន្ថែមនៅក្នុងឃ្លាំង៖ នេះគឺជាការកំណត់រចនាសម្ព័ន្ធ បំពង់បង្ហូរ CI/CD ការកំណត់បរិស្ថាន និងប៉ារ៉ាម៉ែត្រសាងសង់។ ពួកគេរក្សាទុកព័ត៌មាននេះកាន់តែញឹកញាប់ ដំណើរការកាន់តែល្អជាមួយកូដហេដ្ឋារចនាសម្ព័ន្ធ និងធ្វើឱ្យដំណើរការ និងភារកិច្ចកាន់តែច្រើនដោយស្វ័យប្រវត្តិសម្រាប់ធ្វើការជាមួយកូដហេដ្ឋារចនាសម្ព័ន្ធ។

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

ការរួមបញ្ចូលនិងការដឹកជញ្ជូន

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

ស្ថាបត្យកម្ម

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

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

តើយើងរកឃើញទាំងអស់នេះដោយរបៀបណា?

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

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

សម្រាប់ការផ្លាស់ប្តូរ ចូរយើងប្តូរពីស្ថិតិស្មុគស្មាញទៅសាមញ្ញ។

តើយើងបានរកឃើញអ្វីទៀត?

ឧបករណ៍

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

ក្នុងចំណោមក្រុមតន្រ្តីករ វាមិនមែនជាអាថ៌កំបាំងសម្រាប់នរណាម្នាក់នោះទេ Kubernetes គឺនាំមុខគេ (52%)។ អ្នករៀបចំជួរបន្ទាប់គឺ Docker Swarm (ប្រហែល 12%) ។ ប្រព័ន្ធ CI ពេញនិយមបំផុតគឺ Jenkins និង GitLab ។ ប្រព័ន្ធគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធពេញនិយមបំផុតគឺ Ansible បន្ទាប់មក Shell ជាទីស្រឡាញ់របស់យើង។

បច្ចុប្បន្ន Amazon គឺជាអ្នកផ្តល់សេវាបង្ហោះពពកឈានមុខគេ។ ចំណែកនៃពពករុស្ស៊ីកំពុងកើនឡើងជាលំដាប់។ នៅឆ្នាំក្រោយវានឹងគួរឱ្យចាប់អារម្មណ៍ក្នុងការមើលពីរបៀបដែលអ្នកផ្តល់សេវាពពករុស្ស៊ីនឹងមានអារម្មណ៍ថាតើចំណែកទីផ្សាររបស់ពួកគេនឹងកើនឡើងដែរឬទេ។ ពួកវាអាចប្រើបាន ហើយវាល្អ៖

ខ្ញុំហុចជាន់ទៅ Igor ដែលនឹងផ្តល់ស្ថិតិបន្ថែមទៀត។

ការផ្សព្វផ្សាយការអនុវត្ត

Igor Kurochkin៖ ដោយឡែកពីគ្នា យើងបានសួរអ្នកឆ្លើយសំណួរឱ្យបង្ហាញពីរបៀបដែលការអនុវត្តវិស្វកម្មដែលត្រូវបានពិចារណាត្រូវបានចែកចាយនៅក្នុងក្រុមហ៊ុន។ នៅក្នុងក្រុមហ៊ុនភាគច្រើន មានវិធីសាស្រ្តចម្រុះ ដែលមានលំនាំផ្សេងៗគ្នា ហើយគម្រោងសាកល្បងគឺមានប្រជាប្រិយភាពខ្លាំងណាស់។ យើងក៏បានឃើញភាពខុសគ្នាបន្តិចបន្តួចរវាងទម្រង់។ អ្នកតំណាងនៃទម្រង់ខ្ពស់ជាញឹកញាប់ប្រើលំនាំ "គំនិតផ្តួចផ្តើមពីខាងក្រោម" នៅពេលដែលក្រុមអ្នកឯកទេសតូចៗផ្លាស់ប្តូរដំណើរការការងារ ឧបករណ៍ និងចែករំលែកការអនុវត្តជោគជ័យជាមួយក្រុមផ្សេងទៀត។ នៅ Medium នេះគឺជាគំនិតផ្តួចផ្តើមពីកំពូលចុះក្រោមដែលប៉ះពាល់ដល់ក្រុមហ៊ុនទាំងមូលតាមរយៈការបង្កើតសហគមន៍ និងមជ្ឈមណ្ឌលឧត្តមភាព៖

Agile និង DevOps

សំណួរនៃការតភ្ជាប់រវាង Agile និង DevOps ត្រូវបានពិភាក្សាជាញឹកញាប់នៅក្នុងឧស្សាហកម្មនេះ។ បញ្ហានេះក៏ត្រូវបានលើកឡើងនៅក្នុងរបាយការណ៍ State of Agile សម្រាប់ឆ្នាំ 2019/2020 ដូច្នេះហើយ យើងបានសម្រេចចិត្តប្រៀបធៀបពីរបៀបដែលសកម្មភាព Agile និង DevOps ត្រូវបានភ្ជាប់នៅក្នុងក្រុមហ៊ុន។ យើងបានរកឃើញថា DevOps ដោយគ្មាន Agile គឺកម្រណាស់។ សម្រាប់ពាក់កណ្តាលនៃអ្នកឆ្លើយសំណួរ ការរីករាលដាលនៃ Agile បានចាប់ផ្តើមច្រើនមុននេះ ហើយប្រហែល 20% បានសង្កេតឃើញការចាប់ផ្តើមដំណាលគ្នា ហើយសញ្ញាមួយក្នុងចំណោមសញ្ញានៃទម្រង់ទាបនឹងអវត្តមាននៃការអនុវត្ត Agile និង DevOps៖

ពាក្យបញ្ជា topologies

កាលពីចុងឆ្នាំមុន សៀវភៅ "គោលការណ៍ក្រុម” ដែលស្នើឡើងនូវក្របខណ្ឌសម្រាប់ការពិពណ៌នាអំពីពាក្យបញ្ជា topologies ។ វាបានក្លាយជាគួរឱ្យចាប់អារម្មណ៍ចំពោះយើងថាតើវាត្រូវបានអនុវត្តចំពោះក្រុមហ៊ុនរុស្ស៊ីដែរឬទេ។ ហើយយើងបានសួរសំណួរថា "តើអ្នករកឃើញគំរូអ្វី?" ។

ក្រុមហេដ្ឋារចនាសម្ព័ន្ធត្រូវបានគេសង្កេតឃើញនៅក្នុងពាក់កណ្តាលនៃអ្នកឆ្លើយសំណួរ ក៏ដូចជាក្រុមដាច់ដោយឡែកសម្រាប់ការអភិវឌ្ឍន៍ ការធ្វើតេស្ត និងប្រតិបត្តិការ។ ក្រុម DevOps ដាច់ដោយឡែកបានកត់សម្គាល់ 45% ក្នុងចំណោមអ្នកតំណាងរបស់ High គឺជារឿងធម្មតាជាង។ បន្ទាប់មកគឺជាក្រុមឆ្លងមុខងារ ដែលក៏មានច្រើនទៀតនៅ High ។ ពាក្យបញ្ជា SRE ដាច់ដោយឡែកបង្ហាញក្នុងទម្រង់ខ្ពស់ មធ្យម ហើយកម្រឃើញក្នុងទម្រង់ទាប៖

សមាមាត្រ DevQaOps

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

ផែនការសម្រាប់ឆ្នាំ 2021

នៅក្នុងផែនការសម្រាប់ឆ្នាំបន្ទាប់ អ្នកឆ្លើយសំណួរបានកត់សម្គាល់សកម្មភាពដូចខាងក្រោមៈ

នៅទីនេះអ្នកអាចមើលឃើញចំនុចប្រសព្វជាមួយសន្និសីទ DevOps Live 2020។ យើងបានពិនិត្យកម្មវិធីយ៉ាងប្រុងប្រយ័ត្ន៖

ហេដ្ឋារចនាសម្ព័ន្ធជាផលិតផល
ការផ្លាស់ប្តូរ DevOps
ការចែកចាយការអនុវត្ត DevOps
DevSecOps
ក្លឹបករណី និងការពិភាក្សា

ប៉ុន្តែពេលវេលានៃការធ្វើបទបង្ហាញរបស់យើងមិនគ្រប់គ្រាន់ដើម្បីគ្របដណ្តប់លើប្រធានបទទាំងអស់នោះទេ។ បន្សល់ទុកនៅពីក្រោយឆាក៖

វេទិកាជាសេវាកម្ម និងជាផលិតផលមួយ;
ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ បរិស្ថាន និងពពក;
សមាហរណកម្មបន្តនិងការដឹកជញ្ជូន;
ស្ថាបត្យកម្ម;
លំនាំ DevSecOps;
វេទិកា និងក្រុមឆ្លងមុខងារ។

របាយការណ៍ យើងទទួលបាន voluminous, 50 ទំព័រ, ហើយអ្នកអាចឃើញវានៅក្នុងលម្អិតបន្ថែមទៀត។

សង្ខេប

យើងសង្ឃឹមថាការស្រាវជ្រាវ និងរបាយការណ៍របស់យើងនឹងជម្រុញអ្នកឱ្យសាកល្បងវិធីសាស្រ្តថ្មីក្នុងការអភិវឌ្ឍន៍ ការធ្វើតេស្ត និងប្រតិបត្តិការ ក៏ដូចជាជួយអ្នកក្នុងការរុករក ប្រៀបធៀបខ្លួនអ្នកជាមួយអ្នកចូលរួមផ្សេងទៀតក្នុងការសិក្សា និងកំណត់តំបន់ដែលអ្នកអាចកែលម្អវិធីសាស្រ្តផ្ទាល់ខ្លួនរបស់អ្នក។

លទ្ធផលនៃការសិក្សាដំបូងនៃរដ្ឋ DevOps នៅប្រទេសរុស្ស៊ី៖

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

យើងចង់ស្តាប់មតិរបស់អ្នក រឿង មតិកែលម្អ។ យើងសូមអរគុណអ្នកគ្រប់គ្នាដែលបានចូលរួមក្នុងការសិក្សា ហើយទន្ទឹងរង់ចាំការចូលរួមរបស់អ្នកនៅឆ្នាំក្រោយ។

ប្រភព: www.habr.com

ស្ថានភាព DevOps នៅប្រទេសរុស្ស៊ីឆ្នាំ 2020