ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ៖ អ្នកស្គាល់គ្នាដំបូង

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

ការបន្តនៃស៊េរីនៃអត្ថបទដែលបានសរសេរដោយផ្អែកលើសុន្ទរកថានៅឯព្រឹត្តិការណ៍ផ្ទៃក្នុងរបស់យើង។ DevForum:

1. ឆ្មា Schrödinger ដោយគ្មានប្រអប់មួយ: បញ្ហានៃការយល់ស្របនៅក្នុងប្រព័ន្ធចែកចាយ។
2. ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ។ (អ្នកនៅទីនេះ)
3. ការបង្កើតកិច្ចសន្យា Typescript ដោយប្រើគំរូ C# ។ (កំពុង​ដំណើរការ...)
4. ការណែនាំអំពីក្បួនដោះស្រាយការយល់ស្របរបស់ Raft ។ (កំពុង​ដំណើរការ...)
...

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

ក្រុមការងារមានភារកិច្ចបណ្តុះបណ្តាលដូចខាងក្រោមៈ

• ពិពណ៌នាអំពីហេដ្ឋារចនាសម្ព័ន្ធរបស់យើង ដែលភាគច្រើននៅក្នុង Microsoft Azure ក្នុងទម្រង់ជាកូដ (Terraform និងអ្វីៗគ្រប់យ៉ាងនៅជុំវិញ)។
• បង្រៀនអ្នកអភិវឌ្ឍន៍ពីរបៀបធ្វើការជាមួយហេដ្ឋារចនាសម្ព័ន្ធ។
• រៀបចំអ្នកអភិវឌ្ឍន៍សម្រាប់កាតព្វកិច្ច។

យើងណែនាំគោលគំនិតនៃហេដ្ឋារចនាសម្ព័ន្ធជាកូដ

នៅក្នុងគំរូធម្មតានៃពិភពលោក (ការគ្រប់គ្រងបុរាណ) ចំណេះដឹងអំពីហេដ្ឋារចនាសម្ព័ន្ធមានទីតាំងនៅពីរកន្លែង៖

1. ឬនៅក្នុងទម្រង់នៃចំណេះដឹងនៅក្នុងក្បាលរបស់អ្នកជំនាញ។
2. ឬព័ត៌មាននេះគឺនៅលើម៉ាស៊ីនអង្គុលីលេខមួយចំនួនដែលអ្នកជំនាញដឹង។ ប៉ុន្តែវាមិនមែនជាការពិតដែលថាអ្នកខាងក្រៅ (ក្នុងករណីដែលក្រុមទាំងមូលរបស់យើងស្លាប់ភ្លាមៗ) នឹងអាចដឹងថាតើវាដំណើរការអ្វី និងរបៀបដែលវាដំណើរការនោះទេ។ វាអាចមានព័ត៌មានជាច្រើននៅលើម៉ាស៊ីន៖ គ្រឿងបន្ថែម ការបំភិតបំភ័យ (សូមមើល។ ការដំឡើងថាស) ថាស និងគ្រាន់តែជាបញ្ជីគ្មានទីបញ្ចប់នៃអ្វីដែលអាចកើតឡើង។ វាពិបាកក្នុងការយល់ពីអ្វីដែលកំពុងកើតឡើង។

ក្នុង​ករណី​ទាំង​ពីរ​នេះ យើង​ឃើញ​ថា​ខ្លួន​យើង​ជាប់​ក្នុង​ការ​ក្លាយ​ជា​អ្នក​ពឹង​ផ្អែក៖

• ឬពីមនុស្សម្នាក់ដែលមានជីវិតរមែងស្លាប់, ទទួលរងនូវជំងឺ, ធ្លាក់ក្នុងអន្លង់ស្នេហ៍, ការផ្លាស់ប្តូរអារម្មណ៍និងការបញ្ឈប់ជាធម្មតា;
• ឬពីម៉ាស៊ីនដែលកំពុងដំណើរការ ដែលធ្លាក់ ត្រូវបានគេលួច និងបង្ហាញពីការភ្ញាក់ផ្អើល និងភាពរអាក់រអួល។

វានិយាយដោយមិននិយាយថាតាមឧត្ដមគតិអ្វីៗទាំងអស់គួរតែត្រូវបានបកប្រែទៅជាកូដដែលអាចអានបាន រក្សាបាន និងសរសេរបានល្អដោយមនុស្ស។

ដូច្នេះហេដ្ឋារចនាសម្ព័ន្ធជាកូដ (Incfastructure as Code - IaC) គឺជាការពិពណ៌នាអំពីហេដ្ឋារចនាសម្ព័ន្ធដែលមានស្រាប់ទាំងមូលក្នុងទម្រង់ជាកូដ ក៏ដូចជាឧបករណ៍ពាក់ព័ន្ធសម្រាប់ធ្វើការជាមួយវា និងអនុវត្តហេដ្ឋារចនាសម្ព័ន្ធពិតប្រាកដពីវា។

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

តើវិស្វករ SRE ថ្មីមកពីណា?ដូច្នេះ យើងបានសម្រេចចិត្តជួលវិស្វករ SRE ថ្មី ប៉ុន្តែតើត្រូវយកពួកគេមកពីណា? សៀវភៅដែលមានចម្លើយត្រឹមត្រូវ (សៀវភៅ Google SRE) ប្រាប់យើង៖ ពីអ្នកអភិវឌ្ឍន៍។ យ៉ាងណាមិញពួកគេធ្វើការជាមួយកូដហើយអ្នកសម្រេចបាននូវស្ថានភាពដ៏ល្អ។

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

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

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

កូដឧទាហរណ៍ពី Terraforma ។

កូដឧទាហរណ៍ពី Ansible ។

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

1. បញ្ហាទីមួយគឺថាក្នុងករណីភាគច្រើន IaC គឺជាប្រភេទ dsl មួយចំនួន។

ហើយ DSL គឺជាការពិពណ៌នាអំពីរចនាសម្ព័ន្ធ។ ច្បាស់ជាងនេះទៅទៀត អ្វីដែលអ្នកគួរមាន៖ Json, Yaml, ការកែប្រែពីក្រុមហ៊ុនធំៗមួយចំនួនដែលបានបង្កើត dsl ផ្ទាល់ខ្លួនរបស់ពួកគេ (HCL ត្រូវបានប្រើក្នុងទម្រង់ terraform)។

បញ្ហាគឺថា វាប្រហែលជាមិនមានអ្វីដែលធ្លាប់ស្គាល់ដូចជា៖

• អថេរ;
• លក្ខខណ្ឌ;
• កន្លែងណាមួយមិនមានមតិយោបល់ ឧទាហរណ៍នៅក្នុង Json តាមលំនាំដើម ពួកគេមិនត្រូវបានផ្តល់ឱ្យទេ។
• មុខងារ;
• ហើយ​ខ្ញុំ​ក៏​មិន​និយាយ​អំពី​រឿង​កម្រិត​ខ្ពស់​ដូច​ជា ថ្នាក់ មរតក និង​អ្វី​ទាំង​អស់​ដែរ។

2. បញ្ហាទីពីរជាមួយនឹងកូដបែបនេះគឺថា ភាគច្រើនវាជាបរិស្ថានខុសប្រក្រតី. ជាធម្មតាអ្នកអង្គុយ និងធ្វើការជាមួយ C#, i.e. ជាមួយនឹងភាសាមួយ ជង់មួយ ប្រព័ន្ធអេកូមួយ។ ហើយនៅទីនេះអ្នកមានបច្ចេកវិទ្យាជាច្រើនប្រភេទ។

វាគឺជាស្ថានភាពជាក់ស្តែងនៅពេលដែល bash ជាមួយ python ចាប់ផ្តើមដំណើរការមួយចំនួនដែល Json ត្រូវបានបញ្ចូល។ អ្នកវិភាគវា បន្ទាប់មកម៉ាស៊ីនភ្លើងផ្សេងទៀតបង្កើតឯកសារ 30 ផ្សេងទៀត។ សម្រាប់អ្វីៗទាំងអស់នេះ អថេរបញ្ចូលត្រូវបានទទួលពី Azure Key Vault ដែលត្រូវបានទាញរួមគ្នាដោយកម្មវិធីជំនួយសម្រាប់ drone.io ដែលសរសេរក្នុង Go ហើយអថេរទាំងនេះឆ្លងកាត់ yaml ដែលត្រូវបានបង្កើតជាលទ្ធផលនៃជំនាន់ពីម៉ាស៊ីនគំរូ jsonnet ។ វាពិតជាលំបាកណាស់ក្នុងការមានកូដពិពណ៌នាយ៉ាងតឹងរ៉ឹងនៅពេលដែលអ្នកមានបរិយាកាសចម្រុះបែបនេះ។

ការអភិវឌ្ឍន៍បែបប្រពៃណីនៅក្នុងក្របខ័ណ្ឌនៃកិច្ចការមួយមកជាមួយភាសាមួយ។ នៅទីនេះយើងធ្វើការជាមួយភាសាមួយចំនួនធំ។

3. បញ្ហាទីបីគឺការលៃតម្រូវ. យើងត្រូវបានគេប្រើដើម្បីធ្វើឱ្យអ្នកកែសម្រួលត្រជាក់ (Ms Visual Studio, Jetbrains Rider) ដែលធ្វើអ្វីគ្រប់យ៉ាងសម្រាប់យើង។ ហើយ​ទោះ​យើង​ល្ងង់​ក៏​គេ​ថា​យើង​ខុស។ វាហាក់ដូចជាធម្មតានិងធម្មជាតិ។

ប៉ុន្តែកន្លែងណាមួយនៅក្បែរនោះមាន VSCode ដែលក្នុងនោះមានកម្មវិធីជំនួយមួយចំនួនដែលត្រូវបានដំឡើង គាំទ្រ ឬមិនគាំទ្រ។ កំណែថ្មីបានចេញមក ហើយមិនត្រូវបានគាំទ្រទេ។ ការផ្លាស់ប្តូរ banal ទៅការអនុវត្តមុខងារមួយ (ទោះបីជាវាមាន) ក្លាយជាបញ្ហាស្មុគស្មាញ និងមិនមែនជារឿងតូចតាច។ ការប្តូរឈ្មោះសាមញ្ញនៃអថេរគឺជាការចាក់ឡើងវិញនៅក្នុងគម្រោងនៃឯកសាររាប់សិប។ អ្នកនឹងមានសំណាងប្រសិនបើគាត់ដាក់អ្វីដែលអ្នកត្រូវការ។ ជាការពិតណាស់ មានអំពូល Backlight នៅទីនេះ ហើយនៅទីនោះ មានការបញ្ចប់ដោយស្វ័យប្រវត្តិ កន្លែងណាមួយមានទម្រង់ (ទោះបីជាវាមិនដំណើរការសម្រាប់ខ្ញុំនៅក្នុង terraform នៅលើ Windows ក៏ដោយ)។

នៅពេលសរសេរនេះ។ កម្មវិធីជំនួយ vscode-terraform មិនទាន់ត្រូវបានចេញផ្សាយដើម្បីគាំទ្រកំណែ 0.12 ទោះបីជាវាត្រូវបានចេញផ្សាយអស់រយៈពេល 3 ខែក៏ដោយ។

ដល់ពេលត្រូវបំភ្លេច...

1. បំបាត់កំហុស។
2. ឧបករណ៍កែច្នៃឡើងវិញ។
3. ការបញ្ចប់ដោយស្វ័យប្រវត្តិ។
4. ការរកឃើញកំហុសកំឡុងពេលចងក្រង។

វាគួរឱ្យអស់សំណើច ប៉ុន្តែនេះក៏បង្កើនពេលវេលានៃការអភិវឌ្ឍន៍ និងបង្កើនចំនួននៃកំហុសដែលជៀសមិនរួច។

អ្វីដែលអាក្រក់បំផុតនោះគឺថាយើងបង្ខំចិត្តមិនគិតពីរបៀបរចនា រៀបចំឯកសារចូលទៅក្នុង Folder បំបែក ធ្វើឱ្យកូដរក្សាបាន អានបាន និងអ្វីៗផ្សេងទៀត ប៉ុន្តែអំពីរបៀបដែលខ្ញុំអាចសរសេរពាក្យបញ្ជានេះបានត្រឹមត្រូវ ព្រោះខ្ញុំសរសេរវាមិនត្រឹមត្រូវ។ .

ក្នុងនាមជាអ្នកចាប់ផ្តើមដំបូង អ្នកកំពុងព្យាយាមរៀន terraforms ហើយ IDE មិនជួយអ្នកទាល់តែសោះ។ ពេល​មាន​ឯកសារ​ចូល​មើល។ ប៉ុន្តែប្រសិនបើអ្នកកំពុងបញ្ចូលភាសាសរសេរកម្មវិធីថ្មី IDE នឹងប្រាប់អ្នកថាមានប្រភេទបែបនេះ ប៉ុន្តែមិនមានរឿងបែបនេះទេ។ យ៉ាងហោចណាស់នៅកម្រិត int ឬខ្សែអក្សរ។ នេះច្រើនតែមានប្រយោជន៍។

ចុះតេស្តវិញ?

អ្នកសួរថា "ចុះយ៉ាងណាចំពោះការធ្វើតេស្តអ្នកសរសេរកម្មវិធីសុភាពបុរស?" បុរស​ខ្លាំង​សាកល្បង​គ្រប់​យ៉ាង​លើ​ការ​ផលិត ហើយ​វា​ពិបាក​ណាស់។ នេះគឺជាឧទាហរណ៍នៃការធ្វើតេស្តឯកតាសម្រាប់ម៉ូឌុល terraform ពីគេហទំព័រ ក្រុមហ៊ុន Microsoft.

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

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

វាពិបាកក្នុងការញែក Json នៅក្នុង Go ។ ហើយអ្នកត្រូវសរសេរក្នុង Go ព្រោះ terraform in Go គឺជាការអនុវត្តដ៏ល្អសម្រាប់សាកល្បងជាភាសាដែលអ្នកសរសេរ។ ការរៀបចំកូដខ្លួនឯងគឺខ្សោយណាស់។ ទន្ទឹមនឹងនេះដែរនេះគឺជាបណ្ណាល័យដ៏ល្អបំផុតសម្រាប់ការសាកល្បង។

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

ការអនុវត្តល្អបំផុត ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ

តោះបន្តទៅមុខទៀត។ ប្រសិនបើមិនមានការធ្វើតេស្តនៅក្នុង IaC ទេ IDE និងការលៃតម្រូវគឺមិនល្អ នោះយ៉ាងហោចណាស់គួរតែមានការអនុវត្តល្អបំផុត។ ខ្ញុំទើបតែបានទៅ Google Analytics ហើយប្រៀបធៀបសំណួរស្វែងរកពីរ៖ ការអនុវត្តល្អបំផុត Terraform និងការអនុវត្តល្អបំផុត c# ។

តើយើងឃើញអ្វី? ស្ថិតិ​គ្មាន​មេត្តា​មិន​ពេញ​ចិត្ត​យើង​ទេ។ បរិមាណសម្ភារៈគឺដូចគ្នា។ នៅក្នុងការអភិវឌ្ឍន៍ C# យើងគ្រាន់តែស្រងូតស្រងាត់នៅក្នុងសម្ភារៈ យើងមានការអនុវត្តល្អបំផុត មានសៀវភៅសរសេរដោយអ្នកជំនាញ និងសៀវភៅដែលសរសេរលើសៀវភៅដោយអ្នកជំនាញផ្សេងទៀតដែលរិះគន់សៀវភៅទាំងនោះ។ សមុទ្រនៃឯកសារផ្លូវការ អត្ថបទ វគ្គបណ្តុះបណ្តាល ហើយឥឡូវនេះក៏មានការអភិវឌ្ឍន៍ប្រភពបើកចំហផងដែរ។

ចំពោះសំណើរបស់ IaC៖ នៅទីនេះអ្នកកំពុងព្យាយាមប្រមូលព័ត៌មានបន្តិចម្តងៗពី highload ឬរបាយការណ៍ HashiConf ពីឯកសារផ្លូវការ និងបញ្ហាជាច្រើននៅលើ Github ។ តើធ្វើដូចម្តេចដើម្បីចែកចាយម៉ូឌុលទាំងនេះជាទូទៅអ្វីដែលត្រូវធ្វើជាមួយពួកគេ? វាហាក់ដូចជាថានេះគឺជាបញ្ហាពិតប្រាកដ... មានសហគមន៍មួយសុភាពបុរស ដែលជាកន្លែងដែលសម្រាប់សំណួរណាមួយដែលអ្នកនឹងត្រូវបានផ្តល់យោបល់ 10 នៅលើ Github ។ ប៉ុន្តែវាមិនពិតប្រាកដទេ។

ជាអកុសល នៅពេលនេះ អ្នកជំនាញទើបតែចាប់ផ្តើមលេចឡើង។ មានពួកគេតិចពេករហូតមកដល់ពេលនេះ។ ហើយសហគមន៍ខ្លួនឯងកំពុងដើរលេងនៅកម្រិតមូលដ្ឋាន។

តើអ្វីៗទាំងអស់នេះទៅទីណា ហើយត្រូវធ្វើអ្វី

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

ដោយផ្ទាល់ ខ្ញុំកំពុងភ្នាល់លើរឿងមួយចំនួន៖

1. ការអភិវឌ្ឍន៍នៅតំបន់នេះកំពុងកើតឡើងយ៉ាងលឿន។ នេះគឺជាកាលវិភាគនៃសំណើសម្រាប់ DevOps ។

   
   
   ប្រធានបទអាចមានការបំផ្លើស ប៉ុន្តែការពិតដែលថាវិស័យកំពុងរីកចម្រើនផ្តល់ក្តីសង្ឃឹមខ្លះៗ។

   ប្រសិនបើមានអ្វីមួយរីកចម្រើនយ៉ាងឆាប់រហ័ស នោះមនុស្សឆ្លាតនឹងលេចឡើងដែលនឹងប្រាប់អ្នកពីអ្វីដែលត្រូវធ្វើ និងអ្វីដែលមិនគួរធ្វើ។ ការកើនឡើងនៃប្រជាប្រិយភាពនាំឱ្យការពិតដែលថាប្រហែលជានរណាម្នាក់នឹងមានពេលវេលាដើម្បីបន្ថែមកម្មវិធីជំនួយទៅ jsonnet សម្រាប់ vscode ដែលនឹងអនុញ្ញាតឱ្យអ្នកបន្តទៅការអនុវត្តមុខងារជាជាងការស្វែងរកវាតាមរយៈ ctrl+shift+f ។ នៅពេលដែលអ្វីៗមានការវិវឌ្ឍន៍ សម្ភារៈកាន់តែច្រើនលេចឡើង។ ការចេញផ្សាយសៀវភៅពី Google អំពី SRE គឺជាឧទាហរណ៍ដ៏ល្អនៃរឿងនេះ។

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

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

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

សេចក្តីសន្និដ្ឋាន

ទោះបីជាការពិតដែលថាការវែកញែករបស់ខ្ញុំហាក់ដូចជាទុទិដ្ឋិនិយមក៏ដោយ ក៏ខ្ញុំមើលទៅអនាគតដោយក្តីសង្ឃឹម ហើយសង្ឃឹមដោយស្មោះថាអ្វីៗនឹងដំណើរការសម្រាប់យើង (និងអ្នក)។

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

ប្រភព: www.habr.com