DevOps LEGO: របៀបដែលយើងដាក់បំពង់បង្ហូរចូលទៅក្នុងគូប

យើងធ្លាប់បានផ្គត់ផ្គង់ប្រព័ន្ធគ្រប់គ្រងឯកសារអេឡិចត្រូនិកដល់អតិថិជននៅកន្លែងតែមួយ។ ហើយបន្ទាប់មកទៅវត្ថុមួយទៀត។ និងមួយទៀត។ ហើយនៅថ្ងៃទីបួននិងថ្ងៃទីប្រាំ។ យើង​បាន​យក​ទៅ​ឆ្ងាយ​រហូត​ដល់​ទៅ​ដល់ ១០ វត្ថុ​ដែល​បាន​ចែកចាយ។ វាមានថាមពលខ្លាំង... ជាពិសេសនៅពេលដែលយើងឈានដល់ចំណុចនៃការផ្លាស់ប្តូរ។ ជាផ្នែកមួយនៃការបញ្ជូនទៅកាន់សៀគ្វីផលិតកម្ម 10 សេណារីយ៉ូនៃប្រព័ន្ធសាកល្បងនៅទីបំផុតតម្រូវឱ្យបុគ្គលិក 5 ម៉ោង និង 10-6 នាក់។ ការចំណាយបែបនេះបានបង្ខំឱ្យយើងធ្វើការចែកចាយយ៉ាងកម្រតាមដែលអាចធ្វើទៅបាន។ បន្ទាប់ពីប្រតិបត្តិការរយៈពេល 7 ឆ្នាំ យើងមិនអាចទ្រាំទ្របាន ហើយសម្រេចចិត្តធ្វើឱ្យគម្រោងនេះកាន់តែមានភាពទាក់ទាញជាមួយនឹង DevOps ។

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

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

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

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

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

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

ការបង្កើត DevOps constructor

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

ជាសំណាងល្អក្រុមហ៊ុនល្បីឈ្មោះ Gartner ក្នុងឆ្នាំ 2014 ប្រមូលបាន។ និងបានវិភាគការអនុវត្តសំខាន់ៗរបស់ DevOps និងទំនាក់ទំនងរវាងពួកគេ។ ដោយ​ផ្អែក​លើ​នេះ​ខ្ញុំ​បាន​ចេញ​ផ្សាយ infographic មួយ​:

យើងបានយកវាជាមូលដ្ឋានសម្រាប់របស់យើង។ អ្នករចនា. តំបន់នីមួយៗក្នុងចំណោមតំបន់ទាំងបួនមានឧបករណ៍មួយ - យើងបានប្រមូលពួកវាទៅក្នុងមូលដ្ឋានទិន្នន័យ កំណត់អត្តសញ្ញាណពេញនិយមបំផុត កំណត់ចំណុចរួមបញ្ចូល និងយន្តការបង្កើនប្រសិទ្ធភាពសមរម្យ។ សរុបមកវាបានប្រែក្លាយ ការអនុវត្តចំនួន ៣៦ និងឧបករណ៍ចំនួន ១១៥ដែលមួយភាគបួនជាប្រភពបើកចំហ ឬកម្មវិធីឥតគិតថ្លៃ។ បន្ទាប់ យើងនឹងនិយាយអំពីអ្វីដែលយើងសម្រេចបាននៅក្នុងតំបន់នីមួយៗ ហើយជាឧទាហរណ៍អំពីរបៀបដែលវាត្រូវបានអនុវត្តនៅក្នុងគម្រោងដើម្បីបង្កើតការគ្រប់គ្រងឯកសារបច្ចេកទេសដែលយើងបានចាប់ផ្តើមប្រកាស។

ដំណើរការ

នៅក្នុងគម្រោង EDMS ដ៏ល្បីល្បាញ ប្រព័ន្ធគ្រប់គ្រងឯកសារបច្ចេកទេសត្រូវបានដាក់ពង្រាយតាមគ្រោងការណ៍ដូចគ្នានៅវត្ថុនីមួយៗក្នុងចំណោមវត្ថុទាំង 10 ។ ការដំឡើងរួមមាន 4 servers: database server, application server, full-text indexing and content management. នៅក្នុងការដំឡើង ពួកវាដំណើរការនៅក្នុង node តែមួយ ហើយមានទីតាំងនៅក្នុង data center នៅតាមកន្លែងនានា។ វត្ថុទាំងអស់មានភាពខុសប្លែកគ្នាបន្តិចបន្តួចនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធ ប៉ុន្តែនេះមិនរំខានដល់អន្តរកម្មសកលទេ។

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

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

វប្បធម៌

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

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

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

ប្រជាជន

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

បច្ចេកវិទ្យា

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

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

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

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

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

ការបញ្ជូនបន្ត និងការត្រួតពិនិត្យ

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

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

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

តើអ្នកណានឹងត្រូវការរបស់យើង។ អ្នករចនា DevOps?

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

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

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

ប្រភព: www.habr.com