ឧបករណ៍វាស់ស្ទង់ DevOps - កន្លែងដែលត្រូវយកទិន្នន័យសម្រាប់ការគណនា

និយាយឱ្យត្រង់ទៅ Ivan តែងតែសើចចំអកចំពោះការខិតខំប្រឹងប្រែងឥតប្រយោជន៍របស់សហសេវិករបស់គាត់ពីនាយកដ្ឋានត្រួតពិនិត្យ។ ពួកគេបានខិតខំប្រឹងប្រែងយ៉ាងខ្លាំងដើម្បីអនុវត្តការវាស់វែងដែលអ្នកគ្រប់គ្រងរបស់ក្រុមហ៊ុនបានបញ្ជាឱ្យពួកគេសម្រេចបាន។ ពួក​គេ​រវល់​ខ្លាំង​ពេក​មិន​ចង់​ឲ្យ​អ្នក​ផ្សេង​ធ្វើ​អ្វី​ឡើយ។

ប៉ុន្តែវាមិនគ្រប់គ្រាន់សម្រាប់ការគ្រប់គ្រងនោះទេ ពួកគេបានបញ្ជារវាស់ស្ទង់ថ្មីៗកាន់តែច្រើនឡើងៗជាបន្តបន្ទាប់ ដោយឈប់ប្រើប្រាស់នូវអ្វីដែលបានធ្វើពីមុនមកយ៉ាងឆាប់រហ័ស។

ថ្មីៗនេះ អ្នករាល់គ្នាបាននិយាយអំពី LeadTime ដែលជាពេលវេលាសម្រាប់ការចែកចាយមុខងារអាជីវកម្ម។ ម៉ែត្របានបង្ហាញចំនួនឆ្កួត - 200 ថ្ងៃដើម្បីប្រគល់ភារកិច្ចមួយ។ ធ្វើ​ម៉េច​អ្នក​រាល់​គ្នា​ស្រែក​ហ៊ោ ហើយ​លើក​ដៃ​ឡើង​លើ​មេឃ!

មួយរយៈក្រោយមក សំឡេងរំខានបានធ្លាក់ចុះបន្តិចម្តងៗ ហើយអ្នកគ្រប់គ្រងបានទទួលបញ្ជាឱ្យបង្កើតម៉ែត្រមួយផ្សេងទៀត។

វាច្បាស់ណាស់សម្រាប់ Ivan ថាម៉ែត្រថ្មីនឹងស្លាប់ដោយស្ងៀមស្ងាត់នៅក្នុងជ្រុងងងឹតមួយ។

ពិតប្រាកដណាស់ អ៊ីវ៉ានគិតថា ការដឹងលេខមិនប្រាប់នរណាម្នាក់អ្វីទាំងអស់។ 200 ថ្ងៃឬ 2 ថ្ងៃ - មិនមានភាពខុសប្លែកគ្នាទេព្រោះវាមិនអាចទៅរួចទេក្នុងការកំណត់ហេតុផលដោយលេខហើយយល់ថាវាល្អឬអាក្រក់។

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

សម្រាប់ Ivan នេះគឺជាដំណាក់កាលឆ្លងកាត់។ គាត់បានយល់ពីរឿងនោះ។ ម៉ែត្រគឺគ្រាន់តែជាបន្ទាត់ឈើធម្មតា។ សម្រាប់ការវាស់វែង ហើយអាថ៌កំបាំងទាំងអស់ត្រូវតែស្វែងរក វត្ថុនៃឥទ្ធិពល, i.e. គឺថាម៉ែត្រនេះត្រូវបានបង្កើតឡើង។

សម្រាប់ហាងអនឡាញ វត្ថុនៃឥទ្ធិពលនឹងជាអតិថិជនរបស់ខ្លួនដែលនាំយកប្រាក់ ហើយសម្រាប់ DevOps វានឹងក្លាយជាក្រុមដែលបង្កើត និងផ្សព្វផ្សាយការចែកចាយដោយប្រើបំពង់។

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

គោលបំណងនៃ DevOps Metrics

វាច្បាស់ណាស់ថាមនុស្សគ្រប់គ្នាចង់កាត់បន្ថយពេលវេលាដឹកជញ្ជូន។ ពិតណាស់ 200 ថ្ងៃគឺមិនល្អទេ។

ប៉ុន្តែតើនោះជាសំណួរដោយរបៀបណា?

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

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

"គោលបំណងនៃប្រព័ន្ធនឹងជ្រើសរើសក្រុមដោយផ្អែកលើពេលវេលាដែលពួកគេឆ្លងកាត់តារាង ពោលគឺឧ។ ជាលទ្ធផល យើងគួរតែទទួលបានបញ្ជីពាក្យបញ្ជាជាមួយនឹងពេលវេលាដែលបានជ្រើសរើស មិនមែនលេខទេ។

ប្រសិនបើយើងរកឃើញថាតើពេលវេលាត្រូវបានចំណាយលើការឈរសរុបចំនួនប៉ុន្មាន និងចំនួនពេលវេលាដែលត្រូវចំណាយលើការឈប់សម្រាករវាងកន្លែងឈរ យើងអាចស្វែងរកក្រុម ហៅពួកគេ និងស្វែងយល់ពីហេតុផលឱ្យបានលម្អិតបន្ថែមទៀត និងលុបបំបាត់ពួកគេ”។

របៀបគណនាពេលវេលាដឹកជញ្ជូនសម្រាប់ DevOps

ដើម្បីគណនាវា ចាំបាច់ត្រូវស្វែងយល់ពីដំណើរការ DevOps និងខ្លឹមសាររបស់វា។

ក្រុមហ៊ុនប្រើប្រាស់ប្រព័ន្ធមួយចំនួនដែលមានកំណត់ ហើយព័ត៌មានអាចទទួលបានពីពួកគេតែប៉ុណ្ណោះ ហើយគ្មានកន្លែងណាផ្សេងទៀតឡើយ។

ការងារទាំងអស់នៅក្នុងក្រុមហ៊ុនត្រូវបានចុះបញ្ជីនៅ Jira ។ នៅពេលដែលកិច្ចការមួយត្រូវបានធ្វើឡើង សាខាមួយត្រូវបានបង្កើតឡើងសម្រាប់វា ហើយបន្ទាប់ពីការអនុវត្ត ការប្តេជ្ញាចិត្តមួយត្រូវបានធ្វើឡើងចំពោះ BitBucket និង Pull Request ។ នៅពេលដែល PR (Pull Request) ត្រូវបានទទួលយក ការចែកចាយត្រូវបានបង្កើត និងរក្សាទុកដោយស្វ័យប្រវត្តិនៅក្នុងឃ្លាំង Nexus ។

បន្ទាប់មក ការចែកចាយត្រូវបានដាក់ឱ្យដំណើរការនៅលើទីតាំងជាច្រើនដោយប្រើ Jenkins ដើម្បីពិនិត្យមើលភាពត្រឹមត្រូវនៃការដាក់ឱ្យដំណើរការ ការធ្វើតេស្តដោយស្វ័យប្រវត្តិ និងដោយដៃ៖

អ៊ីវ៉ានបានពិពណ៌នាអំពីប្រព័ន្ធណាដែលព័ត៌មានអ្វីដែលអាចត្រូវបានយកទៅគណនាពេលវេលានៅកន្លែងឈរ:

• ពី Nexus - ពេលវេលាបង្កើតការចែកចាយ និងឈ្មោះនៃថតដែលមានលេខកូដបញ្ជា
• ពី Jenkins - ពេលវេលាចាប់ផ្តើម រយៈពេល និងលទ្ធផលនៃការងារនីមួយៗ ឈ្មោះឈរ (ក្នុងប៉ារ៉ាម៉ែត្រការងារ) ដំណាក់កាល (ជំហានការងារ) ភ្ជាប់ទៅការចែកចាយនៅក្នុង Nexus ។
• Ivan បានសម្រេចចិត្តមិនបញ្ចូល Jira និង BitBucket នៅក្នុងបំពង់បង្ហូរប្រេងទេ ដោយសារតែ... ពួកគេមានទំនាក់ទំនងកាន់តែច្រើនទៅនឹងដំណាក់កាលអភិវឌ្ឍន៍ ហើយមិនដំណើរការការចែកចាយដែលបានបញ្ចប់នៅលើកន្លែងឈរនោះទេ។

ដោយផ្អែកលើព័ត៌មានដែលមាន ដ្យាក្រាមខាងក្រោមត្រូវបានគូរ៖

ដោយដឹងថាវាត្រូវការរយៈពេលប៉ុន្មានដើម្បីបង្កើតការចែកចាយ និងរយៈពេលប៉ុន្មានដែលត្រូវចំណាយលើពួកវានីមួយៗ អ្នកអាចគណនាបានយ៉ាងងាយស្រួលនូវការចំណាយសរុបនៃការឆ្លងកាត់បំពង់ DevOps ទាំងមូល (វដ្តពេញ)។

នេះគឺជារង្វាស់ DevOps ដែល Ivan បានបញ្ចប់ជាមួយ៖

• ចំនួននៃការចែកចាយត្រូវបានបង្កើតឡើង
• ការចែករំលែកនៃការចែកចាយដែល "មក" ទៅកន្លែងឈរហើយ "ឆ្លងកាត់" កន្លែងឈរ
• ពេលវេលាចំណាយលើការឈរ (វដ្តឈរ)
• វដ្តពេញលេញ (ពេលវេលាសរុបសម្រាប់ការឈរទាំងអស់)
• រយៈពេលការងារ
• ការឈប់សម្រាករវាងកន្លែងឈរ
• ពេលវេលាឈប់សម្រាករវាងការចាប់ផ្តើមការងារនៅលើទីតាំងតែមួយ

ម៉្យាងវិញទៀត រង្វាស់កំណត់លក្ខណៈនៃបំពង់ DevOps បានយ៉ាងល្អក្នុងលក្ខខណ្ឌនៃពេលវេលា ម្យ៉ាងវិញទៀតពួកគេត្រូវបានចាត់ទុកថាសាមញ្ញណាស់។

ដោយ​ពេញ​ចិត្ត​នឹង​ការងារ​ដែល​បាន​ធ្វើ​បាន​ល្អ Ivan បាន​ធ្វើ​បទ​បង្ហាញ ហើយ​បាន​ទៅ​បង្ហាញ​វា​ដល់​ថ្នាក់​គ្រប់គ្រង។

គាត់ត្រលប់មកវិញដោយអាប់អួរ ហើយយកដៃចុះ។

“នេះ​ជា​ការ​កុហក​បង​ប្អូន” មិត្ត​រួម​ការងារ​ដ៏​គួរ​ឲ្យ​ហួស​ចិត្ត​ញញឹម…

សូមអានបន្ថែមនៅក្នុងអត្ថបទ "លទ្ធផលរហ័សបានជួយ Ivan"។

ប្រភព: www.habr.com