ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ៖ របៀបជម្នះបញ្ហាដោយប្រើ XP

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

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

តើយើងជានរណា កន្លែងណា ហើយយើងមានបញ្ហាអ្វី

បច្ចុប្បន្នយើងស្ថិតនៅក្នុងក្រុម Sre Onboarding Team ដែលមានអ្នកសរសេរកម្មវិធីចំនួន 6 នាក់ និងវិស្វករហេដ្ឋារចនាសម្ព័ន្ធបីនាក់។ យើងទាំងអស់គ្នាកំពុងព្យាយាមសរសេរ Infrastructure ជាកូដ (IaC)។ យើង​ធ្វើ​ដូច្នេះ​ដោយ​សារ​តែ​យើង​ដឹង​ពី​របៀប​សរសេរ​កូដ​ជា​មូលដ្ឋាន ហើយ​មាន​ប្រវត្តិ​នៃ​ការ​ក្លាយ​ជា​អ្នក​អភិវឌ្ឍន៍ "លើស​មធ្យម"។

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

ជង់បច្ចេកវិទ្យាដែលយើងប្រើនៅក្នុង IaC របស់យើង។

• Terraform សម្រាប់បង្កើតធនធាន។
• កញ្ចប់សម្រាប់ដំឡើងរូបភាព។ ទាំងនេះគឺជារូបភាពរបស់ Windows, CentOS 7 ។
• Jsonnet ដើម្បីបង្កើតការស្ថាបនាដ៏មានឥទ្ធិពលនៅក្នុង drone.io ក៏ដូចជាដើម្បីបង្កើត packer json និងម៉ូឌុល terraform របស់យើង។
• Azure ។
• អាចយល់បាននៅពេលរៀបចំរូបភាព។
• Python សម្រាប់សេវាកម្មជំនួយ និងការផ្តល់ស្គ្រីប។
• ហើយទាំងអស់នេះនៅក្នុង VSCode ជាមួយនឹងកម្មវិធីជំនួយដែលបានចែករំលែករវាងសមាជិកក្រុម។

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

បច្ចុប្បន្នយើងកំពុងជួបបញ្ហា IaC ខាងក្រោម៖

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

កម្មវិធី Extreme Programming (XP) ដើម្បីជួយសង្គ្រោះ

អ្នកអភិវឌ្ឍន៍ទាំងអស់ស្គាល់កម្មវិធី Extreme Programming (XP) និងការអនុវត្តដែលនៅពីក្រោយវា។ ពួកយើងជាច្រើនបានធ្វើការជាមួយវិធីសាស្រ្តនេះ ហើយវាបានទទួលជោគជ័យ។ ដូច្នេះ ហេតុអ្វី​បាន​ជា​មិន​ប្រើ​គោលការណ៍ និង​ការអនុវត្ត​ដែល​បាន​ដាក់​នៅ​ទីនោះ ដើម្បី​ជម្នះ​បញ្ហា​ប្រឈម​ផ្នែក​ហេដ្ឋារចនាសម្ព័ន្ធ? យើងបានសម្រេចចិត្តទទួលយកវិធីសាស្រ្តនេះ ហើយមើលថាតើមានអ្វីកើតឡើង។

ពិនិត្យមើលការអនុវត្តនៃវិធីសាស្រ្ត XP ចំពោះឧស្សាហកម្មរបស់អ្នក។នេះគឺជាការពិពណ៌នាអំពីបរិស្ថានដែល XP ស័ក្តិសមសម្រាប់ និងរបៀបដែលវាទាក់ទងនឹងយើង៖

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

2. ហានិភ័យដែលបណ្តាលមកពីគម្រោងពេលវេលាថេរដោយប្រើបច្ចេកវិទ្យាថ្មី។ យើង​អាច​នឹង​ជួប​ប្រទះ​នឹង​ហានិភ័យ​ពេល​ប្រើ​របស់​ខ្លះ​ដែល​យើង​មិន​ស្គាល់។ ហើយនេះគឺជាករណីរបស់យើង 100% ។ គម្រោងទាំងមូលរបស់យើងគឺការប្រើប្រាស់បច្ចេកវិទ្យាដែលយើងមិនសូវស្គាល់។ ជាទូទៅ នេះ​ជា​បញ្ហា​មិន​ឈប់ឈរ​ព្រោះ​... មាន​បច្ចេកវិទ្យា​ថ្មីៗ​ជា​ច្រើន​បាន​លេច​ចេញ​ក្នុង​វិស័យ​ហេដ្ឋារចនាសម្ព័ន្ធ​គ្រប់​ពេល​វេលា។

៣.៤. ក្រុមអភិវឌ្ឍន៍ពង្រីកដែលមានទីតាំងរួមតូច។ បច្ចេកវិជ្ជាស្វ័យប្រវត្តិដែលអ្នកកំពុងប្រើអនុញ្ញាតឱ្យធ្វើតេស្តឯកតា និងមុខងារ។ ចំណុចទាំងពីរនេះមិនសមនឹងយើងទេ។ ទីមួយ យើងមិនមែនជាក្រុមសម្របសម្រួលទេ ហើយទីពីរមានពួកយើងប្រាំបួននាក់ ដែលអាចចាត់ទុកថាជាក្រុមធំ។ ទោះបីជាយោងទៅតាមនិយមន័យមួយចំនួននៃក្រុម "ធំ" ច្រើនគឺ 3,4+ នាក់។

សូមក្រឡេកមើលការអនុវត្ត XP មួយចំនួន និងរបៀបដែលវាប៉ះពាល់ដល់ល្បឿន និងគុណភាពនៃមតិកែលម្អ។

គោលការណ៍រង្វិលជុំមតិយោបល់ XP

តាម​ការ​យល់​ឃើញ​របស់​ខ្ញុំ មតិ​ត្រឡប់​គឺ​ជា​ចម្លើយ​ចំពោះ​សំណួរ តើ​ខ្ញុំ​ធ្វើ​រឿង​ត្រឹម​ត្រូវ តើ​យើង​ទៅ​ទី​នោះ​ទេ? XP មានគ្រោងការណ៍ដ៏ទេវភាពសម្រាប់ការនេះ: រង្វិលជុំមតិត្រឡប់ពេលវេលា។ អ្វីដែលគួរឱ្យចាប់អារម្មណ៍នោះគឺថាយើងទាបជាងយើងកាន់តែលឿនយើងអាចទទួលបាន OS ដើម្បីឆ្លើយសំណួរចាំបាច់។

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

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

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

វិធីទាញខ្លួនអ្នកចេញពីទីជ្រៅនៃភាពអស់សង្ឃឹម៖ ការអនុវត្តបី

តេស្ត។

ការធ្វើតេស្តត្រូវបានលើកឡើងពីរដងនៅក្នុងរង្វិលជុំមតិយោបល់ XP ។ វាមិនមែនគ្រាន់តែបែបនោះទេ។ ពួកវាមានសារៈសំខាន់ខ្លាំងណាស់សម្រាប់បច្ចេកទេសកម្មវិធី Extreme Programming ទាំងមូល។

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

មានពីរ៉ាមីតសាកល្បងបុរាណ ដែលបង្ហាញថាគួរតែមានការធ្វើតេស្តបន្ថែមទៀត។

តើក្របខ័ណ្ឌនេះអនុវត្តចំពោះយើងក្នុងគម្រោង IaC យ៉ាងដូចម្តេច? តាមពិត ... មិនមែនទាល់តែសោះ។

• ការធ្វើតេស្តឯកតា ទោះបីជាការពិតដែលថាវាគួរតែមានច្រើនក៏ដោយ មិនអាចមានច្រើនពេកទេ។ ឬពួកគេកំពុងសាកល្បងអ្វីមួយដោយប្រយោល។ តាមពិតយើងអាចនិយាយបានថាយើងមិនសរសេរវាទាល់តែសោះ។ ប៉ុន្តែនេះគឺជាកម្មវិធីមួយចំនួនសម្រាប់ការធ្វើតេស្តបែបនេះ ដែលយើងអាចធ្វើបាន៖
  1. ការធ្វើតេស្តកូដ jsonnet ។ ជាឧទាហរណ៍ នេះគឺជាបំពង់ផ្គុំ Drone របស់យើង ដែលមានភាពស្មុគស្មាញណាស់។ លេខកូដ jsonnet ត្រូវបានគ្របដណ្តប់យ៉ាងល្អដោយការធ្វើតេស្ត។
     យើងប្រើនេះ។ ក្របខ័ណ្ឌការធ្វើតេស្តឯកតាសម្រាប់ Jsonnet.
  2. ការធ្វើតេស្តសម្រាប់ស្គ្រីបដែលត្រូវបានប្រតិបត្តិនៅពេលដែលធនធានចាប់ផ្តើម។ ស្គ្រីបត្រូវបានសរសេរនៅក្នុង Python ដូច្នេះហើយការធ្វើតេស្តអាចត្រូវបានសរសេរនៅលើពួកវា។
• វាអាចទៅរួចក្នុងការត្រួតពិនិត្យការកំណត់រចនាសម្ព័ន្ធនៅក្នុងការធ្វើតេស្ត ប៉ុន្តែយើងមិនធ្វើដូច្នោះទេ។ វាក៏អាចធ្វើទៅបានដើម្បីកំណត់រចនាសម្ព័ន្ធការត្រួតពិនិត្យការកំណត់រចនាសម្ព័ន្ធធនធានតាមរយៈ tflint. ទោះជាយ៉ាងណាក៏ដោយ ការត្រួតពិនិត្យនៅទីនោះគឺសាមញ្ញពេកសម្រាប់ terraform ប៉ុន្តែស្គ្រីបសាកល្បងជាច្រើនត្រូវបានសរសេរសម្រាប់ AWS ។ ហើយយើងនៅលើ Azure ដូច្នេះវាមិនត្រូវបានអនុវត្តម្តងទៀតទេ។
• ការធ្វើតេស្តរួមបញ្ចូលសមាសធាតុ៖ វាអាស្រ័យលើរបៀបដែលអ្នកចាត់ថ្នាក់ពួកវា និងកន្លែងដែលអ្នកដាក់វា។ ប៉ុន្តែពួកគេធ្វើការជាមូលដ្ឋាន។

  នេះគឺជាអ្វីដែលការធ្វើតេស្តរួមបញ្ចូលមើលទៅដូច។

  
  
  នេះជាឧទាហរណ៍នៅពេលបង្កើតរូបភាពនៅក្នុង Drone CI ។ ដើម្បីទៅដល់ពួកគេ អ្នកត្រូវរង់ចាំ 30 នាទីដើម្បីឱ្យរូបភាព Packer បង្កើត បន្ទាប់មករង់ចាំ 15 នាទីទៀតដើម្បីឱ្យពួកគេឆ្លងកាត់។ ប៉ុន្តែពួកគេមាន!

  ក្បួនដោះស្រាយការផ្ទៀងផ្ទាត់រូបភាព

  1. ដំបូងអ្នកវេចខ្ចប់ត្រូវរៀបចំរូបភាពទាំងស្រុង។
  2. បន្ទាប់​ពី​ការ​ធ្វើ​តេស្ដ​មាន​ផ្ទៃ​ដី​ដែល​មាន​រដ្ឋ​មូលដ្ឋាន​ដែល​យើង​ប្រើ​ដើម្បី​ដាក់​ពង្រាយ​រូបភាព​នេះ។
  3. នៅពេលលាតត្រដាង ម៉ូឌុលតូចមួយដែលនៅក្បែរនោះត្រូវបានប្រើ ដើម្បីធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការធ្វើការជាមួយរូបភាព។
  4. នៅពេលដែល VM ត្រូវបានដាក់ពង្រាយពីរូបភាព ការត្រួតពិនិត្យអាចចាប់ផ្តើម។ ជាទូទៅការត្រួតពិនិត្យត្រូវបានអនុវត្តដោយឡាន។ វាពិនិត្យពីរបៀបដែលស្គ្រីបដំណើរការនៅពេលចាប់ផ្តើម និងរបៀបដែលដេមិនដំណើរការ។ ដើម្បីធ្វើដូចនេះតាមរយៈ ssh ឬ winrm យើងចូលទៅក្នុងម៉ាស៊ីនដែលបានលើកឡើងថ្មី ហើយពិនិត្យមើលស្ថានភាពនៃការកំណត់រចនាសម្ព័ន្ធ ឬថាតើសេវាកម្មឡើងឬអត់។

• ស្ថានភាពគឺស្រដៀងគ្នាជាមួយនឹងការធ្វើតេស្តរួមបញ្ចូលនៅក្នុងម៉ូឌុលសម្រាប់ terraform ។ នេះគឺជាតារាងខ្លីមួយដែលពន្យល់ពីលក្ខណៈពិសេសនៃការធ្វើតេស្តបែបនេះ។

  
  
  មតិយោបល់លើបំពង់បង្ហូរប្រេងគឺប្រហែល 40 នាទី។ អ្វីគ្រប់យ៉ាងកើតឡើងក្នុងរយៈពេលយូរ។ វាអាចត្រូវបានប្រើសម្រាប់ការតំរែតំរង់ប៉ុន្តែសម្រាប់ការអភិវឌ្ឍន៍ថ្មីវាជាទូទៅមិនប្រាកដនិយម។ ប្រសិនបើអ្នកត្រៀមខ្លួនខ្លាំងណាស់សម្រាប់ការនេះ រៀបចំស្គ្រីបដែលកំពុងដំណើរការ បន្ទាប់មកអ្នកអាចកាត់បន្ថយវាមកត្រឹម 10 នាទី។ ប៉ុន្តែទាំងនេះនៅតែមិនមែនជាការធ្វើតេស្តឯកតាដែលធ្វើ 5 បំណែកក្នុងរយៈពេល 100 វិនាទី។

អវត្ដមាននៃការធ្វើតេស្តឯកតានៅពេលដំឡើងរូបភាព ឬម៉ូឌុល terraform លើកទឹកចិត្តឱ្យផ្លាស់ប្តូរការងារទៅសេវាកម្មដាច់ដោយឡែកដែលអាចដំណើរការបានយ៉ាងសាមញ្ញតាមរយៈ REST ឬទៅស្គ្រីប Python ។

ឧទាហរណ៍ យើងត្រូវប្រាកដថា នៅពេលដែលម៉ាស៊ីននិម្មិតចាប់ផ្តើម វាចុះឈ្មោះខ្លួនវានៅក្នុងសេវាកម្ម មាត្រដ្ឋានFTហើយនៅពេលដែលម៉ាស៊ីននិម្មិតត្រូវបានបំផ្លាញ វាបានលុបខ្លួនឯង។

ដោយសារយើងមាន ScaleFT ជាសេវាកម្មមួយ យើងបង្ខំឱ្យធ្វើការជាមួយវាតាមរយៈ API ។ មាន​ក្រដាស​រុំ​មួយ​ដែល​អ្នក​អាច​ទាញ​បាន ហើយ​និយាយ​ថា​៖ ​«​ចូល​ទៅ​លុប​វា​ហើយ​នោះ​ចេញ​»។ វារក្សាទុកការកំណត់ និងការចូលប្រើប្រាស់ចាំបាច់ទាំងអស់។

យើង​អាច​សរសេរ​ការ​ធ្វើ​តេស្ត​ធម្មតា​សម្រាប់​វា​រួច​ហើយ ព្រោះ​វា​មិន​ខុស​ពី​កម្មវិធី​ធម្មតា​ទេ៖ ប្រភេទ​នៃ apiha មួយ​ចំនួន​ត្រូវ​បាន​គេ​ចំអក អ្នក​ទាញ​វា ហើយ​មើល​ថា​មាន​អ្វី​កើត​ឡើង។

លទ្ធផលនៃការធ្វើតេស្ត៖ ការធ្វើតេស្តឯកតា ដែលគួរតែផ្តល់ឱ្យ OS ក្នុងរយៈពេលមួយនាទី មិនផ្តល់ឱ្យវាទេ។ ហើយប្រភេទនៃការធ្វើតេស្តខ្ពស់ជាងនៅក្នុងសាជីជ្រុងមានប្រសិទ្ធភាព ប៉ុន្តែគ្របដណ្តប់តែផ្នែកនៃបញ្ហាប៉ុណ្ណោះ។

ផ្គូផ្គងកម្មវិធី

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

នៅពេលសរសេរកូដ អ្នកចង់ទទួលបានមតិកែលម្អអំពីគុណភាពរបស់វាឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន។ បាទ / ចាស អ្នកអាចសរសេរអ្វីគ្រប់យ៉ាងនៅក្នុងផ្នែកលក្ខណៈពិសេសមួយ (ដើម្បីកុំឱ្យខូចអ្វីសម្រាប់នរណាម្នាក់) ធ្វើសំណើរទាញនៅក្នុង Github ប្រគល់វាទៅឱ្យនរណាម្នាក់ដែលមានគំនិតមានទម្ងន់ ហើយរង់ចាំការឆ្លើយតប។

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

ខាង​ក្រោម​នេះ​គឺ​ជា​រចនាប័ទ្ម​កម្មវិធី​ជា​គូ និង​ការ​អនុវត្ត​របស់​វា​ក្នុង​ការ​ធ្វើ​ការ​លើ IaC៖

1. បុរាណ បទពិសោធន៍ + បទពិសោធន៍ ប្តូរតាមម៉ោងកំណត់។ តួនាទីពីរ - អ្នកបើកបរនិងអ្នករុករក។ មនុស្ស​ពីរ​នាក់។ ពួកគេធ្វើការលើកូដដូចគ្នា និងប្តូរតួនាទីបន្ទាប់ពីរយៈពេលកំណត់ទុកជាមុនជាក់លាក់មួយ។

ចូរយើងពិចារណាពីភាពឆបគ្នានៃបញ្ហារបស់យើងជាមួយនឹងរចនាប័ទ្ម៖

• បញ្ហា៖ ភាពមិនល្អឥតខ្ចោះនៃឧបករណ៍ និងឧបករណ៍សម្រាប់ការអភិវឌ្ឍន៍កូដ។
  ផល​ប៉ះពាល់​អវិជ្ជមាន៖ វា​ត្រូវ​ចំណាយ​ពេល​យូរ​ក្នុង​ការ​អភិវឌ្ឍ យើង​ថយ​ចុះ ល្បឿន/ចង្វាក់​នៃ​ការ​ងារ​ត្រូវ​បាន​បាត់បង់។
  របៀបដែលយើងប្រយុទ្ធ៖ យើងប្រើឧបករណ៍ផ្សេងគ្នា IDE ទូទៅ និងរៀនផ្លូវកាត់ផងដែរ។
• បញ្ហា៖ ការដាក់ពង្រាយយឺត។
  ផលប៉ះពាល់អវិជ្ជមាន៖ បង្កើនពេលវេលាដែលវាត្រូវការដើម្បីបង្កើតបំណែកនៃកូដ។ យើង​ធុញ​ទ្រាន់​ពេល​កំពុង​រង់ចាំ ដៃ​យើង​ឈោង​ទៅ​ធ្វើ​អ្វី​ផ្សេង​ពេល​កំពុង​រង់ចាំ។
  របៀបដែលយើងប្រយុទ្ធ៖ យើងមិនបានយកឈ្នះវាទេ។
• បញ្ហា៖ កង្វះវិធីសាស្រ្ត និងការអនុវត្ត។
  ផល​ប៉ះ​ពាល់​អវិជ្ជមាន៖ មិន​មាន​ចំណេះ​ដឹង​ពី​របៀប​ធ្វើ​វា​ឲ្យ​បាន​ល្អ និង​របៀប​ធ្វើ​វា​មិន​ល្អ​នោះ​ទេ។ ពង្រីកការទទួលមតិកែលម្អ។
  របៀបដែលយើងប្រយុទ្ធគ្នា៖ ការផ្លាស់ប្តូរយោបល់គ្នាទៅវិញទៅមក និងការអនុវត្តការងារជាគូ ស្ទើរតែដោះស្រាយបញ្ហាបាន។

បញ្ហាចម្បងនៃការប្រើប្រាស់រចនាប័ទ្មនេះនៅក្នុង IaC គឺល្បឿនការងារមិនស្មើគ្នា។ នៅក្នុងការអភិវឌ្ឍន៍កម្មវិធីបែបប្រពៃណី អ្នកមានចលនាឯកសណ្ឋានខ្លាំង។ អ្នកអាចចំណាយពេល 10 នាទីហើយសរសេរ N. ចំណាយពេល 2 នាទីហើយសរសេរ 15N, 3 នាទី - 30N ។ នៅទីនេះអ្នកអាចចំណាយពេលប្រាំនាទីហើយសរសេរ N ហើយបន្ទាប់មកចំណាយពេល XNUMX នាទីទៀតហើយសរសេរ N មួយភាគដប់។ នៅទីនេះអ្នកមិនដឹងអ្វីទាំងអស់ អ្នកកំពុងជាប់គាំង ឆោតល្ងង់។ ការស៊ើបអង្កេតត្រូវការពេលវេលា និងរំខានពីការសរសេរកម្មវិធីខ្លួនឯង។

សេចក្តីសន្និដ្ឋាន៖ ក្នុងទម្រង់ដ៏បរិសុទ្ធរបស់វា វាមិនសមនឹងយើងទេ។

2. ប៉េងប៉ុង។ វិធីសាស្រ្តនេះពាក់ព័ន្ធនឹងមនុស្សម្នាក់សរសេរការសាកល្បង និងម្នាក់ទៀតធ្វើការអនុវត្តសម្រាប់វា។ ដោយគិតពីការពិតដែលថាអ្វីៗទាំងអស់មានភាពស្មុគស្មាញជាមួយនឹងការធ្វើតេស្តឯកតា ហើយអ្នកត្រូវសរសេរការធ្វើតេស្តរួមបញ្ចូលដែលចំណាយពេលយូរក្នុងការសរសេរកម្មវិធី នោះភាពងាយស្រួលទាំងអស់នៃ ping-pong នឹងបាត់ទៅវិញ។

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

សេចក្តីសន្និដ្ឋាន៖ អាហ្នឹង ល្បឿននៃការងារមិនអនុញ្ញាតឱ្យប្រើ ping-pong ជាការអនុវត្តកម្មវិធីគូនៅក្នុង IaC ទេ។

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

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

សេចក្តីសន្និដ្ឋាន៖ វាអាចប្រើប្រាស់បាន យើងមិនបោះបង់ការព្យាយាមឡើយ។

4. ការវាយលុក ការវាយលុក និងរចនាប័ទ្មដែលគេស្គាល់ទាំងអស់ ប៉ុន្តែមិនត្រូវបានរាយបញ្ជី យើង​មិន​ពិចារណា​ទេ ព្រោះ យើងមិនបានសាកល្បងវាទេ ហើយវាមិនអាចទៅរួចទេក្នុងការនិយាយអំពីវានៅក្នុងបរិបទនៃការងាររបស់យើង។

លទ្ធផលទូទៅនៃការប្រើប្រាស់កម្មវិធីគូ៖

• យើង​មាន​ល្បឿន​ការងារ​មិន​ស្មើ​គ្នា ដែល​ជា​ការ​ច្របូកច្របល់។
• យើងបានរត់ចូលទៅក្នុងជំនាញទន់ល្អមិនគ្រប់គ្រាន់។ ហើយ​មុខវិជ្ជា​មិន​អាច​ជួយ​ជម្នះ​ចំណុច​ខ្វះខាត​ទាំងនេះ​របស់​យើង​បាន​ឡើយ។
• ការធ្វើតេស្តយូរ និងបញ្ហាជាមួយឧបករណ៍ធ្វើឱ្យមានការលំបាកក្នុងការអភិវឌ្ឍន៍ជាគូ។

5. បើទោះជាយ៉ាងនេះក៏ដោយ ក៏មានការជោគជ័យដែរ។ យើងបានបង្កើតវិធីសាស្រ្តផ្ទាល់ខ្លួនរបស់យើង "ការបញ្ចូលគ្នា - ភាពខុសគ្នា" ។ ខ្ញុំនឹងរៀបរាប់ដោយសង្ខេបពីរបៀបដែលវាដំណើរការ។

យើងមានដៃគូអចិន្ត្រៃយ៍សម្រាប់ពីរបីថ្ងៃ (តិចជាងមួយសប្តាហ៍)។ យើងធ្វើកិច្ចការមួយជាមួយគ្នា។ យើងអង្គុយជាមួយគ្នាមួយសន្ទុះ៖ ម្នាក់សរសេរ ម្នាក់ទៀតអង្គុយមើលក្រុមគាំទ្រ។ បន្ទាប់​មក​យើង​បែក​គ្នា​មួយ​រយៈ គ្នា​ធ្វើ​រឿង​ឯករាជ្យ​ខ្លះ រួច​មក​ជួប​គ្នា​ម្ដង​ទៀត ធ្វើ​សមកាលកម្ម​យ៉ាង​លឿន ធ្វើ​អ្វី​មួយ​ជាមួយ​គ្នា ហើយ​បែក​គ្នា​ម្ដង​ទៀត។

ការធ្វើផែនការ និងការទំនាក់ទំនង

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

1. គោលបំណងតាមរយៈមែកធាងគោលដៅ។ យើងបានរៀបចំការគ្រប់គ្រងរួមនៃគម្រោងតាមរយៈមែកធាងដែលបន្តទៅអនាគតគ្មានទីបញ្ចប់។ តាមបច្ចេកទេស ការតាមដានត្រូវបានធ្វើឡើងនៅ Miro ។ មានភារកិច្ចមួយ - វាជាគោលដៅមធ្យម។ ពីវាទៅទាំងគោលដៅតូចជាងឬក្រុមនៃកិច្ចការ។ ភារកិច្ចខ្លួនឯងគឺមកពីពួកគេ។ កិច្ចការទាំងអស់ត្រូវបានបង្កើត និងថែទាំនៅលើក្តារនេះ។

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

គុណសម្បត្តិនៃចក្ខុវិស័យដែលមើលឃើញនៃភារកិច្ច:

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

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

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

3. ការបង្ហាញផ្ទៃក្នុង។ ជំនួយក្នុងការដោះស្រាយបញ្ហាពីការសរសេរកម្មវិធីជាគូ ការមើលឃើញនៅលើមែកធាងបញ្ហា និងជំនួយក្នុងការប្រជុំ scrum នៅពេលព្រឹកគឺល្អ ប៉ុន្តែមិនមែនល្អទេ។ ក្នុង​នាម​ជា​គូស្នេហ៍ អ្នក​ត្រូវ​បាន​កំណត់​ត្រឹម​តែ​ចំណេះដឹង​របស់​អ្នក​ប៉ុណ្ណោះ។ មែកធាងភារកិច្ចជួយឱ្យពិភពលោកយល់ថាតើអ្នកណាកំពុងធ្វើអ្វី។ ហើយអ្នកធ្វើបទបង្ហាញ និងសហការីនៅឯកិច្ចប្រជុំពេលព្រឹកនឹងមិនចូលជ្រៅទៅក្នុងបញ្ហារបស់អ្នកឡើយ។ ពួកគេប្រាកដជានឹកអ្វីមួយ។

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

ក្នុងអំឡុងពេលធ្វើបាតុកម្ម ចាំបាច់ត្រូវបង្ហាញព័ត៌មានលម្អិតនៃភារកិច្ច ហើយត្រូវប្រាកដថាបង្ហាញពីប្រតិបត្តិការរបស់វា។

របាយការណ៍អាចត្រូវបានធ្វើឡើងដោយប្រើបញ្ជីត្រួតពិនិត្យ។1. ចូលទៅក្នុងបរិបទ។ តើកិច្ចការនោះមកពីណា ហេតុអ្វីចាំបាច់?

2. តើបញ្ហាត្រូវបានដោះស្រាយដោយរបៀបណា? ជាឧទាហរណ៍ ការចុចកណ្ដុរដ៏ធំត្រូវបានទាមទារ ឬវាមិនអាចទៅរួចទេក្នុងការធ្វើអ្វីទាំងអស់។

3. របៀបដែលយើងកែលម្អវា។ ឧទាហរណ៍៖ "មើល ឥឡូវ​មាន scriptosik នេះ​ជា readme"។

4. បង្ហាញពីរបៀបដែលវាដំណើរការ។ វាត្រូវបានណែនាំឱ្យអនុវត្តដោយផ្ទាល់នូវសេណារីយ៉ូអ្នកប្រើប្រាស់មួយចំនួន។ ខ្ញុំចង់ X ខ្ញុំធ្វើ Y ខ្ញុំឃើញ Y (ឬ Z) ។ ឧទាហរណ៍ ខ្ញុំដាក់ពង្រាយ NGINX ជក់បារី url ហើយទទួលបាន 200 យល់ព្រម។ ប្រសិនបើសកម្មភាពមានរយៈពេលយូរ សូមរៀបចំវាជាមុន ដូច្នេះអ្នកអាចបង្ហាញវានៅពេលក្រោយ។ គួរតែកុំបំបែកវាច្រើនពេកមួយម៉ោងមុនការបង្ហាញ ប្រសិនបើវាផុយស្រួយ។

5. ពន្យល់ពីរបៀបដែលបញ្ហាត្រូវបានដោះស្រាយដោយជោគជ័យ ភាពលំបាកណាដែលនៅសេសសល់ អ្វីមិនទាន់បញ្ចប់ តើការកែលម្អអ្វីដែលអាចធ្វើទៅបាននាពេលអនាគត។ ឧទាហរណ៍ឥឡូវនេះ CLI បន្ទាប់មកនឹងមានស្វ័យប្រវត្តិកម្មពេញលេញនៅក្នុង CI ។

វាត្រូវបានណែនាំឱ្យអ្នកនិយាយនីមួយៗរក្សាវាឱ្យដល់ 5-10 នាទី។ ប្រសិនបើសុន្ទរកថារបស់អ្នកពិតជាមានសារៈសំខាន់ ហើយនឹងចំណាយពេលយូរជាងនេះ សូមសម្របសម្រួលវាជាមុននៅក្នុងប៉ុស្តិ៍ sre-takeover ។

បន្ទាប់ពីផ្នែកទល់មុខគ្នា វាតែងតែមានការពិភាក្សានៅក្នុងខ្សែស្រឡាយ។ នេះគឺជាកន្លែងដែលមតិកែលម្អដែលយើងត្រូវការលើកិច្ចការរបស់យើងលេចឡើង។

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

ការ​សន្និដ្ឋាន​វែង​ឆ្ងាយ​និង​អ្វី​ដែល​ជា​បន្ទាប់​

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

ការធ្វើតេស្តនៅក្នុងទម្រង់បច្ចុប្បន្នរបស់ពួកគេ ផ្តល់នូវការគ្របដណ្តប់លេខកូដផ្នែកប៉ុណ្ណោះ។ មុខងារកំណត់រចនាសម្ព័ន្ធជាច្រើនបញ្ចប់ដោយមិនបានសាកល្បង។ ឥទ្ធិពលរបស់ពួកគេលើការងារជាក់ស្តែងនៅពេលសរសេរកូដមានកម្រិតទាប។ ទោះយ៉ាងណាក៏ដោយ មានប្រសិទ្ធិភាពពីការធ្វើតេស្តសមាហរណកម្ម ហើយពួកគេអនុញ្ញាតឱ្យអ្នកអនុវត្ត refactorings ដោយមិនភ័យខ្លាច។ នេះគឺជាសមិទ្ធិផលដ៏អស្ចារ្យមួយ។ ដូចគ្នានេះផងដែរជាមួយនឹងការផ្លាស់ប្តូរនៃការផ្តោតទៅលើការអភិវឌ្ឍនៅក្នុងភាសាកម្រិតខ្ពស់ (យើងមាន python, ទៅ) បញ្ហានឹងទៅឆ្ងាយ។ ហើយអ្នកមិនត្រូវការការត្រួតពិនិត្យច្រើនសម្រាប់ "កាវ" ទេ ការត្រួតពិនិត្យការរួមបញ្ចូលទូទៅគឺគ្រប់គ្រាន់ហើយ។

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

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

ការសន្និដ្ឋានខ្លីៗក្នុងមួយជួរ

• អ្នកអនុវត្តធនធានមនុស្សធ្វើការនៅក្នុង IaC ប៉ុន្តែមានប្រសិទ្ធភាពតិចជាង។
• ពង្រឹងអ្វីដែលដំណើរការ។
• មកជាមួយយន្តការ និងការអនុវត្តសំណងផ្ទាល់ខ្លួនរបស់អ្នក។

ប្រភព: www.habr.com