តើ DevOps ជាអ្វី?

និយមន័យនៃ DevOps គឺស្មុគស្មាញណាស់ ដូច្នេះយើងត្រូវចាប់ផ្តើមការពិភាក្សាអំពីវាម្តងទៀតរាល់ពេល។ មានការបោះពុម្ពផ្សាយរាប់ពាន់លើប្រធានបទនេះនៅលើ Habre តែម្នាក់ឯង។ ប៉ុន្តែប្រសិនបើអ្នកកំពុងអានរឿងនេះ អ្នកប្រហែលជាដឹងថា DevOps ជាអ្វី។ ព្រោះខ្ញុំមិនមែនទេ។ សួរ​ស្ដី​ឈ្មោះ​របស់ខ្ញុំ​គឺ Alexander Titov (@osminog) ហើយយើងនឹងនិយាយអំពី DevOps ហើយខ្ញុំនឹងចែករំលែកបទពិសោធន៍របស់ខ្ញុំ។

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

នៅពេលមួយខ្ញុំកំពុងជិះរលកនៃការរួមបញ្ចូលគ្នា និងការទិញយក។ ដំបូង ខ្ញុំបានធ្វើការឱ្យក្រុមហ៊ុនតូចមួយហៅថា Qik បន្ទាប់មកវាត្រូវបានទិញដោយក្រុមហ៊ុនធំជាងបន្តិចហៅថា Skype ដែលបន្ទាប់មកត្រូវបានទិញដោយក្រុមហ៊ុនធំជាងបន្តិចហៅថា Microsoft ។ នៅពេលនោះ ខ្ញុំចាប់ផ្តើមឃើញពីរបៀបដែលគំនិតរបស់ DevOps កំពុងផ្លាស់ប្តូរនៅក្នុងក្រុមហ៊ុនដែលមានទំហំខុសៗគ្នា។ បន្ទាប់ពីនោះមក ខ្ញុំបានចាប់អារម្មណ៍ក្នុងការសម្លឹងមើល DevOps តាមទស្សនៈទីផ្សារ ហើយសហការីរបស់ខ្ញុំ និងខ្ញុំបានបង្កើតក្រុមហ៊ុន Express 42។ អស់រយៈពេល 6 ឆ្នាំហើយ ពួកយើងបាននិងកំពុងធ្វើដំណើរតាមរលកនៃទីផ្សារ។

ក្នុងចំណោមរបស់ផ្សេងទៀត ខ្ញុំគឺជាអ្នករៀបចំម្នាក់នៃសហគមន៍ DevOps Moscow និងជាអ្នករៀបចំ DevOps-Days 2017 ប៉ុន្តែខ្ញុំមិនបានរៀបចំឆ្នាំ 2018 ទេ។ Express 42 ធ្វើការជាមួយក្រុមហ៊ុនជាច្រើន។ យើងរីកចម្រើន DevOps នៅទីនោះ មើលពីរបៀបដែលវាកើតឡើង ទាញការសន្និដ្ឋាន វិភាគ ប្រាប់អ្នកគ្រប់គ្នានូវការសន្និដ្ឋានរបស់យើង និងបណ្តុះបណ្តាលមនុស្សនៅក្នុងការអនុវត្ត DevOps ។ ជាទូទៅ យើងកំពុងប្រឹងប្រែងអស់ពីសមត្ថភាពដើម្បីបង្កើនបទពិសោធន៍ និងជំនាញរបស់យើងក្នុងរឿងនេះ។

ហេតុអ្វីបានជា DevOps

សំណួរ​ដំបូង​ដែល​តែង​តែ​លង​បន្លាច​អ្នក​រាល់​គ្នា​គឺ ហេតុអ្វី? មនុស្សជាច្រើនគិតថា DevOps គ្រាន់តែជាស្វ័យប្រវត្តិកម្ម ឬជារបស់ស្រដៀងគ្នាដែលគ្រប់ក្រុមហ៊ុនមានរួចហើយ។

- យើងមានការរួមបញ្ចូលជាបន្តបន្ទាប់ - នេះមានន័យថាយើងមាន DevOps រួចហើយ ហើយហេតុអ្វីបានជាអ្វីៗទាំងអស់នេះត្រូវការ? គេ​ទៅ​លេង​នៅ​បរទេស តែ​គេ​ហាម​យើង​មិន​ឲ្យ​ធ្វើ​ការ!

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

ទាំងអស់នេះគឺដោយសារតែការពិតដែលថាពិភពលោកកំពុងផ្លាស់ប្តូរ។ គាត់បានផ្លាស់ទីឆ្ងាយពីវិធីសាស្រ្តសហគ្រាស នៅពេលដែលក្រុមហ៊ុនផ្លាស់ទីត្រង់ឆ្ពោះទៅរកក្តីសុបិនដូចដែលសាំងពេទឺប៊ឺគបុរាណបានច្រៀងពីចំណុច A ដល់ចំណុច B តាមយុទ្ធសាស្ត្រជាក់លាក់ ជាមួយនឹងរចនាសម្ព័ន្ធជាក់លាក់មួយដែលត្រូវបានបង្កើតឡើងសម្រាប់រឿងនេះ។

ជាគោលការណ៍ អ្វីគ្រប់យ៉ាងនៅក្នុង IT គួរតែត្រូវបានសាងសង់ឡើងតាមវិធីសាស្រ្តនេះ។ នៅទីនេះ IT ត្រូវបានប្រើទាំងស្រុងដើម្បីធ្វើស្វ័យប្រវត្តិកម្មដំណើរការ។

ស្វ័យប្រវត្តិកម្មមិនផ្លាស់ប្តូរញឹកញាប់ទេ ព្រោះនៅពេលដែលក្រុមហ៊ុនមួយធ្លាក់ផ្លូវល្អ តើត្រូវផ្លាស់ប្តូរអ្វីខ្លះ? វាដំណើរការ - កុំប៉ះវា។ ឥឡូវនេះ វិធីសាស្រ្តក្នុងពិភពលោកកំពុងផ្លាស់ប្តូរ ហើយអ្វីដែលហៅថា Agile បង្ហាញថា ចំណុចបញ្ចប់ B មិនអាចមើលឃើញភ្លាមៗនោះទេ។

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

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

ផលិតផលនេះត្រូវបានទិញដោយក្រុមហ៊ុន Unilever ក្នុងតម្លៃ 1 ពាន់លានដុល្លារ។ ឥឡូវនេះវាប្រកួតប្រជែងជាមួយ Gillette ហើយបានដកហូតចំណែកដ៏សំខាន់នៃអ្នកប្រើប្រាស់នៅក្នុងទីផ្សារអាមេរិក។ One Box Shave និយាយថា៖

- ៤ កាំបិត? តើអ្នកធ្ងន់ធ្ងរទេ? ហេតុអ្វីបានជាអ្នកត្រូវការវា - វាមិនធ្វើអោយប្រសើរឡើងនូវគុណភាពនៃការកោរសក់នោះទេ។ ក្រែមដែលជ្រើសរើសពិសេស ក្លិនក្រអូប និងឡាមដែលមានគុណភាពខ្ពស់ជាមួយនឹងដាវពីរ ដោះស្រាយបញ្ហាបានច្រើនជាង 4 Gillette blades ឆ្កួតៗទាំងនោះទៅទៀត! តើយើងនឹងឈានដល់ 4 ឆាប់ៗនេះទេ?

នេះជារបៀបដែលពិភពលោកផ្លាស់ប្តូរ។ ក្រុមហ៊ុន Unilever អះអាង​ថា​ពួកគេ​មាន​ប្រព័ន្ធ IT ដ៏​ត្រជាក់​ដែល​អាច​ឱ្យ​អ្នក​ធ្វើ​កិច្ចការ​នេះ​បាន។ នៅទីបញ្ចប់វាមើលទៅដូចជាគំនិតមួយ។ ពេល​វេលា​ទៅ​កាន់​ទីផ្សារដែលគ្មាននរណាម្នាក់បាននិយាយរួចហើយ។

ចំនុចនៃ Time-to-market មិនមែនថាតើយើងដាក់ពង្រាយញឹកញាប់ប៉ុណ្ណានោះទេ។ ជាញឹកញាប់អ្នកអាចដាក់ពង្រាយ ប៉ុន្តែវដ្តនៃការចេញផ្សាយនឹងមានរយៈពេលយូរ។ ប្រសិនបើវដ្តនៃការចេញផ្សាយរយៈពេល 3 ខែត្រូវបានដាក់លើគ្នាទៅវិញទៅមក ដោយផ្លាស់ប្តូរវាក្នុងមួយសប្តាហ៍ វាបង្ហាញថាក្រុមហ៊ុនហាក់ដូចជាត្រូវបានដាក់ពង្រាយម្តងក្នុងមួយសប្តាហ៍។ ហើយចាប់ពីគំនិតរហូតដល់ការអនុវត្តចុងក្រោយវាត្រូវចំណាយពេល XNUMX ខែ។

Time-to-market គឺនិយាយអំពីការកាត់បន្ថយពេលវេលាពីគំនិតរហូតដល់ការអនុវត្តចុងក្រោយ។

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

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

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

នៅឆ្នាំ 1968 បុរសដែលមានចក្ខុវិស័យម្នាក់ឈ្មោះ Melvin Conway បានបង្កើតគំនិតដូចខាងក្រោម។

អង្គការដែលបង្កើតប្រព័ន្ធត្រូវបានរារាំងដោយការរចនាដែលចម្លងរចនាសម្ព័ន្ធទំនាក់ទំនងរបស់អង្គការនោះ។

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

អាន អំពីច្បាប់របស់ Conway អាចធ្វើបាន តាមរយៈតំណភ្ជាប់. វាមានសារៈសំខាន់សម្រាប់ការយល់ដឹងអំពីវប្បធម៌ ឬទស្សនវិជ្ជារបស់ DevOps ពីព្រោះ រឿងតែមួយគត់ដែលផ្លាស់ប្តូរជាមូលដ្ឋាននៅក្នុង DevOps គឺរចនាសម្ព័ន្ធនៃការទំនាក់ទំនងរវាងក្រុម.

តាមទស្សនៈនៃដំណើរការ មុននឹង DevOps គ្រប់ដំណាក់កាលទាំងអស់៖ ការវិភាគ ការអភិវឌ្ឍន៍ ការធ្វើតេស្ត ប្រតិបត្តិការ គឺជាលីនេអ៊ែរ។
ក្នុងករណី DevOps ដំណើរការទាំងអស់នេះកើតឡើងក្នុងពេលដំណាលគ្នា។

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

ដូច្នេះហេតុអ្វីបានជាអ្នកត្រូវការ DevOps?

សម្រាប់ការអភិវឌ្ឍន៍ផលិតផលឌីជីថល. ប្រសិនបើក្រុមហ៊ុនរបស់អ្នកមិនមានផលិតផលឌីជីថលទេ DevOps មិនចាំបាច់ទេ - វាមានសារៈសំខាន់ខ្លាំងណាស់។

DevOps យកឈ្នះលើដែនកំណត់ល្បឿននៃការផលិតកម្មវិធីជាបន្តបន្ទាប់. នៅក្នុងវាដំណើរការទាំងអស់កើតឡើងក្នុងពេលដំណាលគ្នា។

ភាពលំបាកកើនឡើង។ នៅពេលដែលអ្នកផ្សាយដំណឹងល្អ DevOps ប្រាប់អ្នកថា វានឹងធ្វើឱ្យអ្នកងាយស្រួលបញ្ចេញកម្មវិធី នេះមិនមែនជារឿងសមហេតុសមផលទេ។

ជាមួយនឹង DevOps អ្វីៗនឹងកាន់តែស្មុគស្មាញ។

នៅក្នុងសន្និសិទនៅទីតាំង Avito អ្នកអាចមើលឃើញថាតើវាមានលក្ខណៈដូចម្តេចក្នុងការដាក់ពង្រាយ Docker container ដែលជាកិច្ចការមិនប្រាកដប្រជា។ ការលំបាកក្លាយជាការហាមឃាត់ អ្នកត្រូវតែវាយកូនបាល់ជាច្រើនក្នុងពេលតែមួយ។

DevOps ផ្លាស់ប្តូរទាំងស្រុងនូវដំណើរការ និងស្ថាប័ននៅក្នុងក្រុមហ៊ុន — ច្បាស់ជាងនេះទៅទៀត វាមិនមែនជា DevOps ដែលផ្លាស់ប្តូរនោះទេ ប៉ុន្តែជាផលិតផលឌីជីថល។ ដើម្បីមកកាន់ DevOps អ្នកនៅតែត្រូវផ្លាស់ប្តូរដំណើរការនេះទាំងស្រុង។

សំណួរសម្រាប់អ្នកឯកទេស

តើ​អ្នក​មាន​អ្វី? សំណួរ​ដែល​អ្នក​អាច​សួរ​ខ្លួន​ឯង​ពេល​កំពុង​ធ្វើ​ការ​ក្នុង​ក្រុមហ៊ុន​និង​ការ​អភិវឌ្ឍ​ជា​អ្នក​ជំនាញ។

តើអ្នកមានយុទ្ធសាស្ត្របង្កើតផលិតផលឌីជីថលទេ? ប្រសិនបើមាន នោះជាការល្អរួចទៅហើយ។ នេះមានន័យថាក្រុមហ៊ុនរបស់អ្នកកំពុងឆ្ពោះទៅរក DevOps ។

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

តើ​ក្រុមហ៊ុន​របស់​អ្នក​ជា​ក្រុមហ៊ុន​មួយ​ក្នុង​ចំណោម​អ្នក​នាំមុខ​ទីផ្សារ​ក្នុង​ទីផ្សារ​ផលិតផល​ឌីជីថល​ឬ? Spotify, Yandex, Uber គឺជាក្រុមហ៊ុនដែលស្ថិតក្នុងកម្រិតកំពូលនៃវឌ្ឍនភាពបច្ចេកវិទ្យាឥឡូវនេះ។

សួរខ្លួនឯងនូវសំណួរទាំងនេះ ហើយប្រសិនបើចម្លើយទាំងអស់គឺទេ នោះប្រហែលជាអ្នកមិនគួរធ្វើ DevOps នៅក្រុមហ៊ុននេះទេ។ ប្រសិនបើប្រធានបទរបស់ DevOps ពិតជាគួរឱ្យចាប់អារម្មណ៍សម្រាប់អ្នក ប្រហែលជា... អ្នកគួរតែផ្លាស់ទៅក្រុមហ៊ុនផ្សេង? ប្រសិនបើក្រុមហ៊ុនរបស់អ្នកចង់ចូលទៅក្នុង DevOps ប៉ុន្តែអ្នកបានឆ្លើយថា "ទេ" ចំពោះសំណួរទាំងអស់ នោះវាដូចជាសត្វរមាសដ៏ស្រស់ស្អាតដែលនឹងមិនផ្លាស់ប្តូរ។

អង្គការ

ដូចដែលខ្ញុំបាននិយាយ យោងទៅតាមច្បាប់របស់ Conway អង្គការនៃក្រុមហ៊ុនផ្លាស់ប្តូរ។ ខ្ញុំនឹងចាប់ផ្តើមជាមួយនឹងអ្វីដែលរារាំង DevOps ពីការជ្រៀតចូលទៅក្នុងក្រុមហ៊ុនពីទស្សនៈរបស់អង្គការ។

បញ្ហានៃ "អណ្តូង"

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

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

DevOps ស្នើឱ្យឆ្លងកាត់គ្រានៃការរំខាននេះ ហើយនាយកដ្ឋានទាំងអស់ធ្វើការរួមគ្នាដើម្បីបង្កើតផែនទីអន្តរកម្មរួមមួយ។

កត្តាពីរដែលរារាំងរឿងនេះ។

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

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

- យើងគ្រាន់តែចង់បើកដំណើរការ CI ប៉ុន្តែវាបានប្រែក្លាយថាការគ្រប់គ្រងមិនត្រូវការវាទេ។

នេះកើតឡើងយ៉ាងជាក់លាក់ដោយសារតែ CI и ដំណើរការចែកចាយបន្ត ស្ថិតនៅលើព្រំដែននៃការប្រឡងជាច្រើន។ ដោយសាមញ្ញដោយមិនយកឈ្នះលើបញ្ហា "អណ្តូង" នៅកម្រិតស្ថាប័ន អ្នកនឹងមិនអាចឆ្ពោះទៅមុខបានឡើយ ទោះបីជាអ្នកធ្វើអ្វីក៏ដោយ ហើយទោះបីជាវាសោកសៅយ៉ាងណាក៏ដោយ។

អ្នកចូលរួមម្នាក់ៗនៅក្នុងដំណើរការនៅក្នុងក្រុមហ៊ុន៖ អ្នកអភិវឌ្ឍន៍ផ្នែកខាងក្រោយ និងអ្នកអភិវឌ្ឍន៍ផ្នែកខាងមុខ ការធ្វើតេស្ត DBA ប្រតិបត្តិការ បណ្តាញ ជីកតាមទិសដៅរបស់ពួកគេ ហើយគ្មាននរណាម្នាក់មានផែនទីធម្មតាទេ លើកលែងតែអ្នកគ្រប់គ្រង ដែលតាមមើលពួកគេ និងគ្រប់គ្រងពួកគេដោយប្រើ "ការបែងចែក និង​យក​ឈ្នះ​»​។

មនុស្ស​កំពុង​តែ​តស៊ូ​ដើម្បី​ផ្កាយ​ឬ​ទង់ជាតិ​មួយ​ចំនួន​អ្នក​រាល់​គ្នា​កំពុង​ជីក​យក​ជំនាញ​របស់​ខ្លួន​។

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

តើវាដូចគ្នានៅក្នុងក្រុមហ៊ុនរបស់អ្នកទេ?

ដើម្បីពិនិត្យបញ្ហានេះ អ្នកអាចសួរខ្លួនឯងនូវសំណួរខាងក្រោម។

តើក្រុមប្រើប្រាស់ឧបករណ៍ទូទៅ និងរួមចំណែកក្នុងការផ្លាស់ប្តូរឧបករណ៍ទូទៅទាំងនោះដែរឬទេ?

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

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

តើវាមានសារៈសំខាន់ប៉ុណ្ណាសម្រាប់អ្នកគ្រប់គ្រងដើម្បីទទួលបានសមិទ្ធផលផ្ទាល់ខ្លួនដោយមិនគិតពីសមិទ្ធផលរបស់ក្រុមហ៊ុន?

ប្រសិនបើអ្នកឆ្លើយសំណួរទាំងនេះដោយខ្លួនឯង វានឹងកាន់តែច្បាស់ថាតើអ្នកមានបញ្ហាបែបនេះនៅក្នុងក្រុមហ៊ុនរបស់អ្នកដែរឬទេ។

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

បន្ទាប់ពីបញ្ហានេះត្រូវបានកន្លងផុតទៅ ការអនុវត្តសំខាន់ដំបូង ដោយគ្មានការលំបាកក្នុងការឈានទៅមុខបន្ថែមទៀតនៅក្នុង DevOps គឺ ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ.

ភាគច្រើនជាញឹកញាប់ ហេដ្ឋារចនាសម្ព័ន្ធជាកូដត្រូវបានយល់ឃើញដូចខាងក្រោម៖

— សូម​ធ្វើ​ឱ្យ​គ្រប់​យ៉ាង​ដោយ​ស្វ័យ​ប្រវត្តិ​ជា​ភាសា​បាស គ្រប​ដណ្ដប់​ខ្លួន​យើង​ដោយ​ស្គ្រីប ដើម្បី​ឱ្យ​អ្នក​គ្រប់គ្រង​មាន​ការងារ​ធ្វើ​ដោយ​ដៃ​តិច!

ប៉ុន្តែនោះមិនមែនជាការពិតទេ។

ហេដ្ឋារចនាសម្ព័ន្ធជាកូដមានន័យថាអ្នកពិពណ៌នាអំពីប្រព័ន្ធ IT ដែលអ្នកធ្វើការជាមួយក្នុងទម្រង់ជាកូដ ដើម្បីយល់ពីស្ថានភាពរបស់វាជានិច្ច។

រួមគ្នាជាមួយក្រុមផ្សេងទៀត អ្នកបង្កើតផែនទីក្នុងទម្រង់ជាកូដដែលគ្រប់គ្នាអាចយល់ និងអាចរុករក និងរុករកបាន។ វាមិនមានបញ្ហាអ្វីដែលវាត្រូវបានធ្វើនៅលើ - មេចុងភៅ Ansible អំបិលឬការប្រើប្រាស់ឯកសារ YAML នៅក្នុង Kubernetes - វាមិនមានភាពខុសគ្នាទេ។

នៅក្នុងសន្និសិទ សហសេវិកម្នាក់មកពី 2GIS បានប្រាប់ពីរបៀបដែលពួកគេបង្កើតរឿងផ្ទៃក្នុងរបស់ពួកគេសម្រាប់ Kubernetes ដែលពិពណ៌នាអំពីរចនាសម្ព័ន្ធនៃប្រព័ន្ធបុគ្គល។ ដើម្បីពិពណ៌នាអំពីប្រព័ន្ធ 500 ពួកគេត្រូវការឧបករណ៍ដាច់ដោយឡែកដែលបង្កើតការពិពណ៌នានេះ។ នៅពេលដែលមានការពិពណ៌នានេះ អ្នកគ្រប់គ្នាអាចពិនិត្យមើលគ្នាទៅវិញទៅមក តាមដានការផ្លាស់ប្តូរ របៀបផ្លាស់ប្តូរវា និងកែលម្អវា អ្វីដែលបាត់។

យល់ស្រប ស្គ្រីប bash នីមួយៗជាធម្មតាមិនផ្តល់ការយល់ដឹងនេះទេ។ នៅក្នុងក្រុមហ៊ុនមួយដែលខ្ញុំធ្វើការ មានសូម្បីតែឈ្មោះសម្រាប់ "សរសេរតែប៉ុណ្ណោះ" ស្គ្រីប - នៅពេលដែលស្គ្រីបត្រូវបានសរសេរប៉ុន្តែវាមិនអាចអានវាទៀតទេ។ ខ្ញុំ​គិត​ថា​នេះ​ក៏​ស្គាល់​អ្នក​ដែរ។

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

កូដ​ត្រូវ​បាន​រក្សា​ដោយ​យោង​តាម​ការ​អនុវត្ត​កូដ​ល្អ​បំផុត​៖ ការអភិវឌ្ឍន៍រួមគ្នា ការពិនិត្យមើលកូដ ការសរសេរកម្មវិធី XP ការធ្វើតេស្ត ទាញសំណើ CI សម្រាប់ហេដ្ឋារចនាសម្ព័ន្ធកូដ - ទាំងអស់នេះសមរម្យ និងអាចប្រើប្រាស់បាន។

កូដក្លាយជាភាសាទូទៅសម្រាប់វិស្វករទាំងអស់។

ការផ្លាស់ប្តូរហេដ្ឋារចនាសម្ព័ន្ធនៅក្នុងកូដមិនចំណាយពេលច្រើនទេ។. បាទ កូដហេដ្ឋារចនាសម្ព័ន្ធក៏អាចមានបំណុលបច្ចេកទេសផងដែរ។ ជាធម្មតាក្រុមជួបប្រទះវាមួយឆ្នាំកន្លះបន្ទាប់ពីពួកគេបានចាប់ផ្តើមអនុវត្ត "ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ" ក្នុងទម្រង់ជាស្គ្រីបមួយក្រុម ឬសូម្បីតែ Ansible ដែលពួកគេសរសេរដូចជាកូដ spaghetti ហើយពួកគេក៏បោះ bash scripts ទៅក្នុងល្បាយផងដែរ។

សំខាន់៖ ប្រសិនបើអ្នកមិនទាន់បានសាកល្បងវត្ថុនេះនៅឡើយទេ សូមចាំថាវា។ Ansible មិនមែនជារឿងអាស្រូវទេ។! អានឯកសារដោយប្រុងប្រយ័ត្ន សិក្សាពីអ្វីដែលពួកគេសរសេរអំពីវា។

Infrastructure as code គឺជាការបំបែកកូដហេដ្ឋារចនាសម្ព័ន្ធទៅជាស្រទាប់ដាច់ដោយឡែក។

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


ស្រទាប់មូលដ្ឋាន - នេះជារបៀបដែលប្រព័ន្ធប្រតិបត្តិការ ការបម្រុងទុក និងរបស់កម្រិតទាបផ្សេងទៀតត្រូវបានកំណត់រចនាសម្ព័ន្ធ ឧទាហរណ៍ របៀបដែល Kubernetes ត្រូវបានដាក់ពង្រាយនៅកម្រិតមូលដ្ឋាន។

កម្រិតសេវាកម្ម - ទាំងនេះគឺជាសេវាកម្មដែលអ្នកផ្តល់ជូនអ្នកអភិវឌ្ឍន៍៖ កត់ត្រាជាសេវាកម្ម ការត្រួតពិនិត្យជាសេវាកម្ម មូលដ្ឋានទិន្នន័យជាសេវាកម្ម តុល្យភាពជាសេវាកម្ម ជួរជាសេវាកម្ម ការដឹកជញ្ជូនបន្តជាសេវាកម្ម - សេវាកម្មជាច្រើនដែលក្រុមនីមួយៗ អាចផ្តល់ដល់ការអភិវឌ្ឍន៍។ ទាំងអស់នេះត្រូវតែត្រូវបានពិពណ៌នានៅក្នុងម៉ូឌុលដាច់ដោយឡែកនៅក្នុងប្រព័ន្ធគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធរបស់អ្នក។

ស្រទាប់ដែលកម្មវិធីត្រូវបានបង្កើតឡើង និងពណ៌នាពីរបៀបដែលពួកវានឹងលាតនៅលើកំពូលនៃស្រទាប់ពីរមុន។

ត្រួតពិនិត្យសំណួរ

តើក្រុមហ៊ុនរបស់អ្នកមានឃ្លាំងហេដ្ឋារចនាសម្ព័ន្ធទូទៅដែរឬទេ? តើអ្នកគ្រប់គ្រងបំណុលបច្ចេកទេសនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកទេ? តើអ្នកប្រើការអនុវត្តការអភិវឌ្ឍន៍នៅក្នុងឃ្លាំងហេដ្ឋារចនាសម្ព័ន្ធទេ? តើហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកត្រូវបានកាត់ជាស្រទាប់ៗទេ? អ្នកអាចពិនិត្យមើលដ្យាក្រាម Base-service-APP ។ តើ​ការ​ផ្លាស់​ប្តូរ​មាន​ការ​លំបាក​យ៉ាង​ណា?

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

ការចែកចាយបន្ត

ចូរប្រៀបធៀបឥណពន្ធជាមួយឥណទាន។ ដំបូងមកការពិពណ៌នាអំពីហេដ្ឋារចនាសម្ព័ន្ធ ដែលអាចជាមូលដ្ឋាន។ អ្នក​មិន​ចាំបាច់​ពណ៌នា​គ្រប់​យ៉ាង​ឲ្យ​លម្អិត​នោះ​ទេ ប៉ុន្តែ​ការ​ពិពណ៌នា​ជា​មូលដ្ឋាន​មួយ​ចំនួន​ត្រូវ​បាន​ទាមទារ ដូច្នេះ​អ្នក​អាច​ធ្វើ​ការ​ជាមួយ​វា។ បើមិនដូច្នោះទេ វាមិនច្បាស់ថាត្រូវធ្វើអ្វីជាមួយការចែកចាយបន្តបន្ទាប់ទៀត។ ការអនុវត្តទាំងអស់នេះកើតឡើងក្នុងពេលដំណាលគ្នានៅពេលអ្នកមក DevOps ប៉ុន្តែវាចាប់ផ្តើមដោយការយល់ដឹងពីអ្វីដែលអ្នកមាន និងរបៀបគ្រប់គ្រងវា។ នេះ​ជា​ការ​អនុវត្ត​ហេដ្ឋារចនាសម្ព័ន្ធ​ជា​កូដ​យ៉ាង​ជាក់លាក់។

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

នៅពេលដែលយើងនៅជាមួយ Vanya Evtukhovich បានឃើញសៀវភៅដំបូង Jez Humble និងក្រុមអ្នកនិពន្ធ "ការចែកចាយបន្ត"ដែលត្រូវបានចេញផ្សាយក្នុងឆ្នាំ 2009 យើងបានគិតជាយូរមកហើយអំពីរបៀបបកប្រែចំណងជើងរបស់វាទៅជាភាសារុស្សី។ ពួកគេចង់បកប្រែវាថាជា “ការចែកចាយបន្ត” ប៉ុន្តែជាអកុសលវាត្រូវបានបកប្រែជា “ការចែកចាយបន្ត”។ វាហាក់ដូចជាខ្ញុំថាមានអ្វីមួយជាភាសារុស្សីនៅក្នុងឈ្មោះរបស់យើងជាមួយនឹងសម្ពាធ។

ការផ្តល់មធ្យោបាយឥតឈប់ឈរ

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

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

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

នេះគឺជាការនឹកឃើញខ្លះៗនៃហ្គេម Pac-Man ដែលជាវត្ថុបុរាណឆ្លងកាត់រឿងមួយចំនួន។ ក្នុងពេលជាមួយគ្នានេះ វាជារឿងសំខាន់ក្នុងការគ្រប់គ្រងថាតើកូដពិតជាឆ្លងកាត់សាច់រឿង និងថាតើវាទាក់ទងនឹងការផលិតរបស់អ្នកដែរឬទេ។ រឿងរ៉ាវពីផលិតកម្មអាចត្រូវបានអូសចូលទៅក្នុងដំណើរការចែកចាយបន្ត៖ វាគឺដូចនេះនៅពេលដែលមានអ្វីមួយធ្លាក់ចុះ ឥឡូវនេះយើងគ្រាន់តែរៀបចំសេណារីយ៉ូនេះនៅក្នុងប្រព័ន្ធ។ រាល់ពេលដែលលេខកូដនឹងឆ្លងកាត់សេណារីយ៉ូនេះផងដែរ ហើយអ្នកនឹងមិនជួបប្រទះបញ្ហានេះនៅពេលក្រោយទេ។ អ្នកនឹងរៀនអំពីវាលឿនជាងវាទៅដល់អតិថិជនរបស់អ្នក។

យុទ្ធសាស្ត្រដាក់ពង្រាយផ្សេងៗគ្នា។ ឧទាហរណ៍ អ្នកប្រើការសាកល្បង AB ឬការដាក់ពង្រាយ Canary ដើម្បីសាកល្បងកូដខុសៗគ្នាលើអតិថិជនផ្សេងៗគ្នា ទទួលបានព័ត៌មានអំពីរបៀបដែលកូដដំណើរការ និងលឿនជាងពេលដែលវាត្រូវបានដាក់ឱ្យប្រើប្រាស់ដល់អ្នកប្រើប្រាស់ 100 លាននាក់។

"ចែកចាយដោយឥតឈប់ឈរ" មើលទៅដូចនេះ។

ដំណើរការចែកចាយ Dev, CI, Test, PreProd, Prod មិនមែនជាបរិយាកាសដាច់ដោយឡែកទេ ទាំងនេះគឺជាដំណាក់កាល ឬស្ថានីយ៍ដែលមានផលបូកការពារភ្លើងដែលវត្ថុបុរាណរបស់អ្នកឆ្លងកាត់។

ប្រសិនបើអ្នកមានកូដហេដ្ឋារចនាសម្ព័ន្ធដែលត្រូវបានពិពណ៌នាថាជា Base Service APP នោះវាអាចជួយបាន។ កុំភ្លេចស្គ្រីបទាំងអស់។ហើយសរសេរពួកវាជាកូដសម្រាប់វត្ថុបុរាណនេះ ផ្សព្វផ្សាយវត្ថុបុរាណ ហើយផ្លាស់ប្តូរវានៅពេលអ្នកទៅ។

សំណួរសាកល្បងខ្លួនឯង

ពេលវេលាពីការពិពណ៌នាលក្ខណៈពិសេសដើម្បីបញ្ចេញទៅក្នុងផលិតកម្មក្នុង 95% នៃករណីគឺតិចជាងមួយសប្តាហ៍? តើគុណភាពនៃវត្ថុបុរាណមានភាពប្រសើរឡើងនៅដំណាក់កាលនីមួយៗនៃបំពង់បង្ហូរប្រេងដែរឬទេ? តើ​មាន​រឿង​ដែល​វា​ឆ្លង​កាត់​ទេ? តើអ្នកប្រើយុទ្ធសាស្ត្រដាក់ពង្រាយផ្សេងគ្នាទេ?

បើ​ចម្លើយ​ទាំង​អស់​គឺ​បាទ នោះ​អ្នក​ពិតជា​ឡូយ​មិន​គួរ​ឱ្យ​ជឿ! សរសេរចម្លើយរបស់អ្នកនៅក្នុងមតិយោបល់ - ខ្ញុំនឹងរីករាយ) ។

Обратнаясвязь

នេះគឺជាការអនុវត្តដ៏លំបាកបំផុតទាំងអស់។ នៅក្នុងសន្និសិទ DevOpsConf សហសេវិកមកពី Infobip ដែលនិយាយអំពីវាមានការភាន់ច្រលំបន្តិចនៅក្នុងពាក្យរបស់គាត់ព្រោះនេះពិតជាការអនុវត្តដ៏ស្មុគស្មាញអំពីការពិតដែលថាអ្នកត្រូវតាមដានអ្វីៗគ្រប់យ៉ាង!

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

- បុរស ហេតុអ្វីបានជាអ្នករំលោភលើម៉ាស៊ីនមេដោយអ្វីដែលមិនច្បាស់លាស់?

ប៉ុន្តែបន្ទាប់មកឧបទ្ទវហេតុមួយបានកើតឡើងដែលបង្ហាញថានេះពិតជាយុទ្ធសាស្ត្រដ៏ត្រជាក់បំផុត។

សេវាកម្មមួយក្នុងចំណោមសេវាកម្មចាប់ផ្តើមគាំងឥតឈប់ឈរ។ ដំបូងវាមិនគាំងទេដែលគួរឱ្យចាប់អារម្មណ៍លេខកូដមិនត្រូវបានបន្ថែមនៅទីនោះទេព្រោះវាជាឈ្មួញកណ្តាលដែលមិនមានមុខងារអាជីវកម្ម - វាគ្រាន់តែផ្ញើសាររវាងសេវាកម្មបុគ្គល។ សេវាកម្មនេះមិនបានផ្លាស់ប្តូរអស់រយៈពេល 4 ខែ ហើយភ្លាមៗនោះវាបានចាប់ផ្តើមគាំងជាមួយនឹងកំហុស "Segmentation fault" ។

យើងមានការភ្ញាក់ផ្អើល បានបើកតារាងរបស់យើងនៅក្នុង Zabbix ហើយវាបានប្រែក្លាយថាមួយសប្តាហ៍កន្លះមុន អាកប្បកិរិយានៃសំណើនៅក្នុងសេវាកម្ម API ដែលឈ្មួញកណ្តាលនេះប្រើបានផ្លាស់ប្តូរយ៉ាងខ្លាំង។ បន្ទាប់​មក យើង​បាន​ឃើញ​ថា​ភាព​ញឹកញាប់​នៃ​ការ​ផ្ញើ​ប្រភេទ​សារ​មួយ​ចំនួន​បាន​ផ្លាស់ប្ដូរ។ ក្រោយមក យើងបានរកឃើញថា ទាំងនេះគឺជាអតិថិជន Android ។ យើងបានសួរថា:

- បុរសតើមានអ្វីកើតឡើងចំពោះអ្នកកាលពីមួយសប្តាហ៍កន្លះមុន?

ជាការឆ្លើយតប យើងបានឮរឿងគួរឱ្យចាប់អារម្មណ៍មួយអំពីរបៀបដែលពួកគេរចនា UI ឡើងវិញ។ វាមិនទំនងដែលនរណាម្នាក់នឹងនិយាយភ្លាមៗថាពួកគេបានផ្លាស់ប្តូរបណ្ណាល័យ HTTP នោះទេ។ សម្រាប់អតិថិជន Android វាដូចជាការផ្លាស់ប្តូរសាប៊ូនៅក្នុងបន្ទប់ទឹក - ពួកគេគ្រាន់តែមិនចាំ។ ជាលទ្ធផល បន្ទាប់ពី 40 នាទីនៃការសន្ទនា យើងបានរកឃើញថាពួកគេបានផ្លាស់ប្តូរបណ្ណាល័យ HTTP ហើយពេលវេលាលំនាំដើមរបស់វាបានផ្លាស់ប្តូរ។ នេះបាននាំឱ្យមានការផ្លាស់ប្តូរឥរិយាបថចរាចរនៅលើម៉ាស៊ីនមេ API ដែលនាំឱ្យមានស្ថានភាពដែលបណ្តាលឱ្យមានការប្រណាំងនៅក្នុងឈ្មួញកណ្តាល ហើយវាបានចាប់ផ្តើមគាំង។

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

ប្រមូលព័ត៌មានទាំងអស់អំពីអ្វីដែលកើតឡើងចំពោះវត្ថុបុរាណនៅដំណាក់កាលនីមួយៗនៃដំណើរការចែកចាយ មិនមែននៅក្នុងផលិតកម្មទេ។

បង្ហោះការត្រួតពិនិត្យទៅ CI ហើយរឿងជាមូលដ្ឋានមួយចំនួននឹងអាចមើលឃើញនៅទីនោះរួចហើយ។ ពេលក្រោយ អ្នកនឹងឃើញពួកវានៅក្នុង Test, PredProd និង load testing។ ប្រមូលព័ត៌មាននៅគ្រប់ដំណាក់កាល មិនត្រឹមតែម៉ែត្រ ស្ថិតិប៉ុណ្ណោះទេ ថែមទាំងកត់ត្រាផងដែរ៖ របៀបដែលកម្មវិធីបានដំណើរការ ភាពមិនប្រក្រតី - ប្រមូលអ្វីៗគ្រប់យ៉ាង។

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

សំណួរសម្រាប់ការគ្រប់គ្រងខ្លួនឯង

តើការត្រួតពិនិត្យ និងការកត់ត្រារបស់អ្នកជាឧបករណ៍អភិវឌ្ឍន៍សម្រាប់អ្នកទេ? នៅពេលសរសេរកូដ តើអ្នកអភិវឌ្ឍន៍របស់អ្នក រួមទាំងអ្នកគិតពីរបៀបត្រួតពិនិត្យវាដែរឬទេ?

តើអ្នកឮពីបញ្ហាពីអតិថិជនទេ? តើ​អ្នក​យល់​ពី​ការ​ត្រួត​ពិនិត្យ និង​កត់​ត្រា​អតិថិជន​កាន់​តែ​ច្បាស់​ទេ? តើ​អ្នក​យល់​ពី​ប្រព័ន្ធ​បាន​ល្អ​ជាង​ពី​ការ​ត្រួត​ពិនិត្យ​និង​ការ​កត់ត្រា​ទេ? តើអ្នកផ្លាស់ប្តូរប្រព័ន្ធដោយគ្រាន់តែអ្នកឃើញថានិន្នាការនៅក្នុងប្រព័ន្ធកំពុងកើនឡើង ហើយអ្នកយល់ថាក្នុងរយៈពេល 3 សប្តាហ៍ទៀតអ្វីៗនឹងស្លាប់មែនទេ?

នៅពេលដែលអ្នកមានសមាសភាគទាំងបីនេះ អ្នកអាចគិតអំពីប្រភេទនៃវេទិកាហេដ្ឋារចនាសម្ព័ន្ធដែលអ្នកមាននៅក្នុងក្រុមហ៊ុនរបស់អ្នក។

វេទិកាហេដ្ឋារចនាសម្ព័ន្ធ

ចំណុច​មិន​មែន​ថា​វា​ជា​សំណុំ​ឧបករណ៍​ខុស​គ្នា​ដែល​គ្រប់​ក្រុមហ៊ុន​មាន​នោះ​ទេ។

ចំណុចនៃវេទិកាហេដ្ឋារចនាសម្ព័ន្ធគឺក្រុមទាំងអស់ប្រើប្រាស់ឧបករណ៍ទាំងនេះ និងអភិវឌ្ឍពួកវាជាមួយគ្នា។

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

ក្រុមទាំងអស់បង្កើតវេទិកាហេដ្ឋារចនាសម្ព័ន្ធ ហើយចាត់ទុកវាដោយយកចិត្តទុកដាក់ជា IDE ផ្ទាល់ខ្លួនរបស់ពួកគេ។. នៅក្នុង IDE របស់អ្នក អ្នកដំឡើងកម្មវិធីជំនួយផ្សេងៗដើម្បីធ្វើឱ្យអ្វីៗទាំងអស់ស្អាត និងលឿន ហើយកំណត់រចនាសម្ព័ន្ធ hotkeys។ នៅពេលអ្នកបើក Sublime, Atom ឬ Visual Studio Code កំហុសកូដកំពុងហូរចូល ហើយអ្នកដឹងថាវាមិនអាចដំណើរការបានទេ អ្នកមានអារម្មណ៍ក្រៀមក្រំភ្លាមៗ ហើយអ្នករត់ទៅជួសជុល IDE របស់អ្នក។

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

វេទិកាហេដ្ឋារចនាសម្ព័ន្ធធានានូវការផ្ទេរវត្ថុបុរាណពីការអភិវឌ្ឍន៍ទៅអតិថិជន ជាមួយនឹងការកែលម្អគុណភាពជាបន្តបន្ទាប់. IP ត្រូវបានកម្មវិធីជាមួយនឹងសំណុំនៃរឿងដែលកើតឡើងចំពោះកូដនៅក្នុងផលិតកម្ម។ ក្នុងរយៈពេលជាច្រើនឆ្នាំនៃការអភិវឌ្ឍន៍ មានរឿងទាំងនេះជាច្រើន ដែលរឿងខ្លះមានលក្ខណៈប្លែក និងទាក់ទងតែអ្នកប៉ុណ្ណោះ ពួកវាមិនអាច Googled បានទេ។

នៅចំណុចនេះ វេទិកាហេដ្ឋារចនាសម្ព័ន្ធក្លាយជាអត្ថប្រយោជន៍ប្រកួតប្រជែងរបស់អ្នក។ព្រោះវាមានអ្វីនៅក្នុងវា ដែលមិនមាននៅក្នុងឧបករណ៍របស់អ្នកប្រកួតប្រជែង។ IP របស់អ្នកកាន់តែស៊ីជម្រៅ អត្ថប្រយោជន៍ប្រកួតប្រជែងរបស់អ្នកកាន់តែច្រើននៅក្នុងលក្ខខណ្ឌនៃ Time-to-market ។ លេចឡើងនៅទីនេះ បញ្ហាចាក់សោអ្នកលក់៖ អ្នក​អាច​យក​វេទិកា​របស់​អ្នក​ផ្សេង ប៉ុន្តែ​ការ​ប្រើ​បទពិសោធន៍​របស់​អ្នក​ផ្សេង អ្នក​នឹង​មិន​យល់​ថា​វា​ពាក់ព័ន្ធ​នឹង​អ្នក​កម្រិត​ណា​ទេ។ បាទ មិនមែនគ្រប់ក្រុមហ៊ុនទាំងអស់អាចបង្កើតវេទិកាដូច Amazon នោះទេ។ នេះគឺជាបន្ទាត់ដ៏លំបាកមួយដែលបទពិសោធន៍របស់ក្រុមហ៊ុនពាក់ព័ន្ធនឹងទីតាំងរបស់ខ្លួននៅក្នុងទីផ្សារ ហើយអ្នកមិនអាចប្រើសោអ្នកលក់នៅទីនោះបានទេ។ នេះក៏សំខាន់ផងដែរក្នុងការគិត។

គម្រោងនេះ

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

សូមក្រឡេកមើលអ្វីដែលវាមាន។

ប្រព័ន្ធរៀបចំធនធានដែលផ្តល់ស៊ីភីយូ អង្គចងចាំ ថាស ដល់កម្មវិធី និងសេវាកម្មផ្សេងទៀត។ នៅលើនេះ - សេវាកម្មកម្រិតទាប៖ ការត្រួតពិនិត្យ ការកត់ត្រា ម៉ាស៊ីន CI/CD ម៉ាស៊ីនផ្ទុកវត្ថុបុរាណ ហេដ្ឋារចនាសម្ព័ន្ធជាកូដប្រព័ន្ធ។

សេវាកម្មកម្រិតខ្ពស់។ នៅលើនេះ - បំពង់ដែលផ្តល់លេខកូដកែប្រែឥតឈប់ឈរដល់អតិថិជនរបស់អ្នក។.

អ្នកទទួលបានព័ត៌មានអំពីរបៀបដែលកម្មវិធីរបស់អ្នកដំណើរការសម្រាប់អតិថិជន ផ្លាស់ប្តូរវា ផ្គត់ផ្គង់កូដនេះម្តងទៀត ទទួលព័ត៌មាន ហើយដូច្នេះអ្នកតែងតែអភិវឌ្ឍទាំងវេទិកាហេដ្ឋារចនាសម្ព័ន្ធ និងកម្មវិធីរបស់អ្នក។

នៅក្នុងដ្យាក្រាមបំពង់ចែកចាយមានដំណាក់កាលជាច្រើន។ ប៉ុន្តែនេះគឺជាដ្យាក្រាមគ្រោងការណ៍ដែលត្រូវបានផ្តល់ជាឧទាហរណ៍មួយ - មិនចាំបាច់ធ្វើវាម្តងមួយៗទេ។ ដំណាក់កាលអន្តរកម្មជាមួយសេវាកម្មដូចជាសេវាកម្ម — ដុំឥដ្ឋនីមួយៗនៃវេទិកាដំណើរការរឿងផ្ទាល់ខ្លួនរបស់វា៖ របៀបបែងចែកធនធាន របៀបដែលកម្មវិធីត្រូវបានបើកដំណើរការ ធ្វើការជាមួយធនធាន ការត្រួតពិនិត្យ និងការផ្លាស់ប្តូរ។

វាជាការសំខាន់ណាស់ដែលត្រូវយល់ថាផ្នែកនីមួយៗនៃវេទិកាមានរឿងមួយ ហើយសួរខ្លួនឯងថាតើរឿងមួយណាដែលឥដ្ឋនេះដឹក ប្រហែលជាវាគួរតែត្រូវបានបោះចោល ហើយជំនួសដោយសេវាកម្មភាគីទីបី។ ឧទាហរណ៍ តើអាចដំឡើង Okmeter ជំនួសឥដ្ឋបានទេ? ប្រហែល​ជា​បុរស​បាន​អភិវឌ្ឍ​ជំនាញ​នេះ​ច្រើន​ជាង​យើង​ទៅ​ទៀត។ ប៉ុន្តែប្រហែលជាមិនមែនទេ - ប្រហែលជាយើងមានជំនាញពិសេស យើងត្រូវដំឡើង Prometheus ហើយអភិវឌ្ឍវាបន្ថែមទៀត។

ការបង្កើតវេទិកា

នេះគឺជាដំណើរការទំនាក់ទំនងដ៏ស្មុគស្មាញ។ នៅពេលដែលអ្នកមានការអនុវត្តជាមូលដ្ឋាន អ្នកចាប់ផ្តើមទំនាក់ទំនងរវាងវិស្វករ និងអ្នកឯកទេសផ្សេងៗគ្នា ដែលបង្កើតតម្រូវការ និងស្តង់ដារ ហើយផ្លាស់ប្តូរវាជានិច្ចទៅឧបករណ៍ និងវិធីសាស្រ្តផ្សេងៗ។ វប្បធម៌ដែលយើងមាននៅក្នុង DevOps គឺសំខាន់នៅទីនេះ។

ជាមួយនឹងវប្បធម៌អ្វីគ្រប់យ៉ាងគឺសាមញ្ញណាស់ - វានិយាយអំពីកិច្ចសហប្រតិបត្តិការ និងការទំនាក់ទំនងពោលគឺ បំណងប្រាថ្នាដើម្បីធ្វើការក្នុងវិស័យរួមជាមួយគ្នាទៅវិញទៅមក បំណងប្រាថ្នាដើម្បីកាន់ឧបករណ៍មួយជាមួយគ្នា។ មិនមានវិទ្យាសាស្ត្ររ៉ុក្កែតនៅទីនេះទេ - អ្វីគ្រប់យ៉ាងគឺសាមញ្ញណាស់ banal ។ ជាឧទាហរណ៍ យើងទាំងអស់គ្នារស់នៅក្នុងច្រកចូល ហើយរក្សាវាឱ្យស្អាត - កម្រិតវប្បធម៌បែបនេះ។

តើ​អ្នក​មាន​អ្វី?

ជាថ្មីម្តងទៀត សំណួរដែលអ្នកអាចសួរខ្លួនឯងបាន។

តើវេទិកាហេដ្ឋារចនាសម្ព័ន្ធត្រូវបានឧទ្ទិសទេ? តើអ្នកណាជាអ្នកទទួលខុសត្រូវចំពោះការអភិវឌ្ឍន៍របស់ខ្លួន? តើអ្នកយល់ពីគុណសម្បត្តិប្រកួតប្រជែងនៃវេទិកាហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកទេ?

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

ដូច្នេះ DevOps...

... នេះជាប្រព័ន្ធស្មុគស្មាញ វាត្រូវតែមាន៖

• ផលិតផលឌីជីថល។
• ម៉ូឌុលអាជីវកម្មដែលអភិវឌ្ឍផលិតផលឌីជីថលនេះ។
• ក្រុមផលិតផលដែលសរសេរកូដ។
• ការអនុវត្តការចែកចាយបន្ត។
• វេទិកាជាសេវាកម្ម។
• ហេដ្ឋារចនាសម្ព័ន្ធជាសេវាកម្ម។
• ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ។
• ការអនុវត្តដាច់ដោយឡែកសម្រាប់ការរក្សាភាពជឿជាក់បានបង្កើតឡើងនៅក្នុង DevOps ។
• ការអនុវត្តមតិកែលម្អដែលពិពណ៌នាអំពីវាទាំងអស់។

អ្នកអាចប្រើដ្យាក្រាមនេះ ដោយបន្លិចនៅក្នុងវានូវអ្វីដែលអ្នកមានរួចហើយនៅក្នុងក្រុមហ៊ុនរបស់អ្នកក្នុងទម្រង់មួយចំនួន៖ តើវាអភិវឌ្ឍហើយឬនៅត្រូវការការអភិវឌ្ឍន៍។

វានឹងចប់ក្នុងរយៈពេលពីរបីសប្តាហ៍ទៀត។ DevOpsConf ឆ្នាំ 2019. ជាផ្នែកមួយនៃ RIT ++ ។ សូមអញ្ជើញមកសន្និសីទ ដែលអ្នកនឹងឃើញរបាយការណ៍ល្អៗជាច្រើនអំពីការចែកចាយបន្ត ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ និងការផ្លាស់ប្តូរ DevOps ។ កក់សំបុត្ររបស់អ្នក។ថ្ងៃផុតកំណត់តម្លៃចុងក្រោយគឺថ្ងៃទី 20 ឧសភា

ប្រភព: www.habr.com