ជាថ្មីម្តងទៀតអំពី DevOps និង SRE

ផ្អែកលើការជជែកពិភាក្សា សហគមន៍ AWS Minsk

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

សម័យបុរេប្រវត្តិសាស្ត្រ

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

កំណើតនៃការអនុវត្ត DevOps

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

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

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

ហើយពួកគេបានសម្រេចចិត្តហៅពួកគេថាការអនុវត្ត DevOps - ខ្ញុំគិតថាពួកគេមានន័យថាពីការអភិវឌ្ឍន៍ទៅប្រតិបត្តិការ។ យើងបានបង្កើតឡើងនូវអ្វីដែលឆ្លាតវៃជាច្រើន - ការអនុវត្ត CI/CD ការអនុវត្តដោយផ្អែកលើគោលការណ៍ IaC រាប់ពាន់នាក់។ ហើយយើងទៅ អ្នកអភិវឌ្ឍន៍សរសេរកូដ វិស្វករ DevOps បំប្លែងការពិពណ៌នានៃប្រព័ន្ធក្នុងទម្រង់ជាកូដទៅជាប្រព័ន្ធការងារ (បាទ កូដគ្រាន់តែជាការពិពណ៌នា ប៉ុន្តែមិនមែនជាតំណាងនៃប្រព័ន្ធទេ) ការដឹកជញ្ជូននៅតែបន្ត ហើយដូច្នេះនៅលើ . អ្នកគ្រប់គ្រងកាលពីម្សិលមិញ ដោយបានស្ទាត់ជំនាញការអនុវត្តថ្មី បានបង្ហាត់ដោយមោទនភាពក្នុងនាមជាវិស្វករ DevOps ហើយអ្វីៗគ្រប់យ៉ាងបានមកពីទីនោះ។ ហើយមានល្ងាច ហើយមានព្រឹក... សុំទោស មិនមែនមកពីទីនោះទេ។

វាមិនល្អម្តងទៀតទេ អរគុណព្រះជាម្ចាស់

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

SRE ដោយ Google

Google បានមក ញ៉ាំ cacti ធំជាងគេ ហើយសម្រេចចិត្ត - យើងមិនត្រូវការវាទេ យើងត្រូវការភាពជឿជាក់។ និងភាពជឿជាក់ត្រូវតែត្រូវបានគ្រប់គ្រង។ ហើយខ្ញុំបានសម្រេចចិត្តថាយើងត្រូវការអ្នកឯកទេសដែលនឹងគ្រប់គ្រងភាពជឿជាក់។ ខ្ញុំបានហៅពួកគេថាវិស្វករ SR ហើយនិយាយថា នោះហើយជាវាសម្រាប់អ្នក ធ្វើវាឱ្យបានល្អដូចធម្មតា។ នេះ​ជា SLI, នេះ​ជា SLO, នេះ​ជា​ការ​ត្រួត​ពិនិត្យ។ ហើយគាត់បានច្របាច់ច្រមុះរបស់គាត់ទៅជាការវះកាត់។ ហើយគាត់បានហៅ SRE "DevOps ដែលអាចទុកចិត្តបាន" របស់គាត់។ អ្វីៗហាក់ដូចជាល្អ ប៉ុន្តែមានការ hack ដ៏កខ្វក់មួយដែល Google អាចទិញបាន - សម្រាប់មុខតំណែងវិស្វករ SR ជួលមនុស្សដែលមានលក្ខណៈសម្បត្តិគ្រប់គ្រាន់ជាអ្នកអភិវឌ្ឍន៍ ហើយបានធ្វើកិច្ចការផ្ទះបន្តិចបន្តួច និងយល់ពីមុខងារនៃប្រព័ន្ធការងារ។ លើសពីនេះទៅទៀត Google ខ្លួនឯងមានបញ្ហាជាមួយនឹងការជួលមនុស្សបែបនេះ - ភាគច្រើនដោយសារតែនៅទីនេះវាប្រកួតប្រជែងជាមួយខ្លួនវា - វាចាំបាច់ក្នុងការពិពណ៌នាអំពីតក្កវិជ្ជាអាជីវកម្មដល់នរណាម្នាក់។ ការដឹកជញ្ជូនត្រូវបានចាត់តាំងឱ្យដោះលែងវិស្វករ SR - វិស្វករគ្រប់គ្រងភាពជឿជាក់ (ជាការពិតណាស់មិនមែនដោយផ្ទាល់ទេប៉ុន្តែដោយឥទ្ធិពលលើហេដ្ឋារចនាសម្ព័ន្ធការផ្លាស់ប្តូរស្ថាបត្យកម្មតាមដានការផ្លាស់ប្តូរនិងសូចនាករដោះស្រាយឧប្បត្តិហេតុ) ។ ល្អណាស់ អ្នកអាចធ្វើបាន សរសេរសៀវភៅ. ប៉ុន្តែចុះយ៉ាងណាបើអ្នកមិនមែនជា Google ប៉ុន្តែភាពជឿជាក់នៅតែជាកង្វល់?

ការអភិវឌ្ឍន៍គំនិត DevOps

ភ្លាមៗនោះ Docker បានមកដល់ ដែលរីកចម្រើនចេញពី lxc ហើយបន្ទាប់មកប្រព័ន្ធរៀបចំផ្សេងៗដូចជា Docker Swarm និង Kubernetes ហើយវិស្វករ DevOps បានដកដង្ហើមចេញ - ការបង្រួបបង្រួមនៃការអនុវត្តបានធ្វើឱ្យមានភាពងាយស្រួលក្នុងការចែកចាយ។ វាបានសម្រួលវាដល់កម្រិតមួយដែលវាអាចទៅរួចសូម្បីតែការផ្តល់ប្រភពខាងក្រៅទៅកាន់អ្នកអភិវឌ្ឍន៍ - អ្វីទៅជា deployment.yaml ។ ការវេចខ្ចប់ដោះស្រាយបញ្ហា។ ហើយភាពចាស់ទុំនៃប្រព័ន្ធ CI/CD គឺស្ថិតក្នុងកម្រិតនៃការសរសេរឯកសារមួយរួចហើយ ហើយយើងទៅ - អ្នកអភិវឌ្ឍន៍អាចដោះស្រាយវាបានដោយខ្លួនឯង។ ហើយបន្ទាប់មកយើងចាប់ផ្តើមនិយាយអំពីរបៀបដែលយើងអាចបង្កើត SRE របស់យើងជាមួយ ... ឬយ៉ាងហោចណាស់ជាមួយនរណាម្នាក់។

SRE មិនមាននៅលើ Google ទេ។

ជាការប្រសើរណាស់ ពួកយើងបានធ្វើការចែកចាយ វាហាក់បីដូចជាយើងអាចដកដង្ហើមបាន ត្រឡប់ទៅថ្ងៃចាស់វិញ នៅពេលដែលអ្នកគ្រប់គ្រងមើលការផ្ទុក processor លៃតម្រូវប្រព័ន្ធ ហើយស្ងាត់ស្ងៀម ញ៉ាំអ្វីដែលមិនអាចយល់បានពីពែងដោយសន្តិភាព និងស្ងប់ស្ងាត់... ឈប់។ នេះ​មិន​មែន​ជា​មូល​ហេតុ​ដែល​យើង​ចាប់​ផ្តើ​ម​អ្វី​គ្រប់​យ៉ាង (ដែល​ជា​ការ​អាណិត​មួយ!) ភ្លាមៗនោះ វាប្រែថានៅក្នុងវិធីសាស្រ្តរបស់ Google យើងអាចទទួលយកការអនុវត្តដ៏ល្អឥតខ្ចោះបានយ៉ាងងាយស្រួល - វាមិនមែនជាបន្ទុកដំណើរការដែលសំខាន់នោះទេ ហើយមិនមែនញឹកញាប់ប៉ុណ្ណាដែលយើងផ្លាស់ប្តូរថាសនៅទីនោះ ឬបង្កើនប្រសិទ្ធភាពតម្លៃនៅក្នុងពពក ប៉ុន្តែការវាស់វែងអាជីវកម្មគឺមានភាពល្បីល្បាញដូចគ្នា SLx ។ ហើយគ្មាននរណាម្នាក់បានដកការគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធចេញពីពួកគេទេ ហើយពួកគេត្រូវដោះស្រាយឧប្បត្តិហេតុ ហើយត្រូវបំពេញកាតព្វកិច្ចតាមកាលកំណត់ ហើយជាទូទៅស្ថិតនៅលើកំពូលនៃដំណើរការអាជីវកម្ម។ ហើយបុរស ចាប់ផ្តើមសរសេរកម្មវិធីបន្តិចម្តងៗក្នុងកម្រិតដ៏ល្អ Google កំពុងរង់ចាំអ្នករួចហើយ។

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

ប្រភព: www.habr.com