ចម្រៀងទឹកកក (សហគ្រាសបង្ហូរឈាម) និងភ្លើង (DevOps និង IaC)

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

ដោយសារចំណងជើងនៃអត្ថបទគឺដូចនេះ Daenerys ដែលបានទៅម្ខាងនៃសហគ្រាសនឹងដើរតួជាឆ្មា។

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

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

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

ដូច្នេះ អ្នកយក jenkins, មេចុងភៅ, terraform, nexus ជាដើម ហើយដាក់ពង្រាយវាទាំងអស់ដោយរីករាយទៅកាន់អ្នកអភិវឌ្ឍន៍របស់អ្នក។ ប៉ុន្តែពេលវេលាមកដល់ដើម្បីផ្ញើវាទៅ QA, UAT និង PROD ។ អ្នកមានវត្ថុបុរាណ Nexus ហើយអ្នកទទួលបានសំបុត្រពី DBA ជាមួយនឹងអ្វីមួយដូចនេះ៖

សូមគោរព

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

សូមគោរព DBA របស់អ្នកដែលបានធ្វើការនៅទីនេះចាប់តាំងពីថ្ងៃនៃ mainframe ។

តើ​អ្នក​ដឹង​ថា​អ្វី​ដែល​ធ្វើ​ឲ្យ​ខ្ញុំ​នឹក​ឃើញ​ទេ? ពាក់កណ្តាលស្វ័យប្រវត្តិ៖ មនុស្សយន្តកាន់ស៊ុម ហើយកម្មករវាយវាដោយញញួរ។ ជាការប្រសើរណាស់, តើអ្វីជាចំណុចនៃ Nexus នេះប្រសិនបើបន្ទាប់មកអ្វីគ្រប់យ៉ាងត្រូវបានធ្វើដោយដៃទាំងស្រុង?

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

និយាយអីញ្ចឹង ពេលមួយខ្ញុំបានព្យាយាមបង្កើតឯកសារសម្រាប់ terraform ប៉ុន្តែវាមិនដំណើរការទេ។ ខ្ញុំបានជំពប់ដួលលើអត្ថន័យនៃស្លាក 'កូដវិក្កយបត្រគណនេយ្យគម្រោង' ដែលខ្ញុំមិនដែលបានរកឃើញទេ - ខ្ញុំមិនមានជំនាញទន់គ្រប់គ្រាន់ទេ។

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

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

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

ប្រភព: www.habr.com