ប្រតិចារិកនៃសិក្ខាសាលាបណ្តាញ "SRE - ឃោសនាបំផ្លើស ឬអនាគត?"

webinar មាន​សំឡេង​មិន​ល្អ ដូច្នេះ​យើង​បាន​ចម្លង​វា។

ឈ្មោះរបស់ខ្ញុំគឺ Medvedev Eduard ។ ថ្ងៃនេះខ្ញុំនឹងនិយាយអំពីអ្វីជា SRE របៀបដែល SRE បានបង្ហាញខ្លួន លក្ខណៈវិនិច្ឆ័យការងារអ្វីខ្លះសម្រាប់វិស្វករ SRE បន្តិចអំពីលក្ខណៈវិនិច្ឆ័យភាពជឿជាក់ បន្តិចអំពីការត្រួតពិនិត្យរបស់វា។ យើងនឹងដើរនៅលើកំពូល ព្រោះអ្នកមិនអាចប្រាប់ច្រើនក្នុងមួយម៉ោង ប៉ុន្តែខ្ញុំនឹងផ្តល់សម្ភារៈសម្រាប់ការត្រួតពិនិត្យបន្ថែម ហើយយើងទាំងអស់គ្នាកំពុងរង់ចាំអ្នកនៅលើ Slurme SRE. នៅទីក្រុងមូស្គូនៅចុងខែមករា។

ជាដំបូងសូមនិយាយអំពីអ្វីដែល SRE គឺ - Site Reliability Engineering ។ និងរបៀបដែលវាបានបង្ហាញខ្លួនជាទីតាំងដាច់ដោយឡែក, ជាទិសដៅដាច់ដោយឡែកមួយ។ វាទាំងអស់បានចាប់ផ្តើមជាមួយនឹងការពិតដែលថានៅក្នុងរង្វង់អភិវឌ្ឍន៍បែបប្រពៃណី Dev និង Ops គឺជាក្រុមពីរផ្សេងគ្នាទាំងស្រុង ដែលជាធម្មតាមានគោលដៅពីរខុសគ្នាទាំងស្រុង។ គោលដៅរបស់ក្រុមអភិវឌ្ឍន៍គឺដើម្បីបញ្ចេញមុខងារថ្មីៗ និងបំពេញតម្រូវការរបស់អាជីវកម្ម។ គោលដៅរបស់ក្រុម Ops គឺធ្វើឱ្យប្រាកដថាអ្វីៗដំណើរការបាន ហើយមិនមានអ្វីខូចឡើយ។ ជាក់ស្តែង គោលដៅទាំងនេះផ្ទុយស្រឡះពីគ្នាទៅវិញទៅមក៖ ដើម្បីឱ្យអ្វីៗដំណើរការបាន និងមិនមានអ្វីត្រូវបំបែក សូមបញ្ចេញមុខងារថ្មីៗឱ្យបានតិចបំផុតតាមដែលអាចធ្វើទៅបាន។ ដោយសារតែបញ្ហានេះមានជម្លោះផ្ទៃក្នុងជាច្រើនដែលវិធីសាស្រ្តដែលឥឡូវនេះត្រូវបានគេហៅថា DevOps កំពុងព្យាយាមដោះស្រាយ។

បញ្ហាគឺថាយើងមិនមាននិយមន័យច្បាស់លាស់នៃ DevOps និងការអនុវត្តច្បាស់លាស់នៃ DevOps ។ ខ្ញុំបាននិយាយនៅក្នុងសន្និសីទមួយនៅ Yekaterinburg កាលពី 2 ឆ្នាំមុន ហើយរហូតមកដល់ពេលនេះ ផ្នែក DevOps បានចាប់ផ្តើមជាមួយនឹងរបាយការណ៍ "DevOps គឺជាអ្វី" ។ នៅឆ្នាំ 2017 Devops មានអាយុជិត 10 ឆ្នាំហើយ ប៉ុន្តែយើងនៅតែប្រកែកថាវាជាអ្វី។ ហើយ​នេះ​ជា​ស្ថានភាព​ចម្លែក​ណាស់​ដែល Google បាន​ព្យាយាម​ដោះស្រាយ​កាលពី​ប៉ុន្មាន​ឆ្នាំមុន។

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

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

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

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

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

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

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

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

នេះពិតជាខុសទាំងអស់។ ហើយមនុស្សទាំងនេះត្រូវបានខាំជាញឹកញាប់ដោយកូដបែបនេះនៅក្នុងការអនុវត្ត, ដោយសារតែអ្វីៗខូច។ ពេលខ្លះអ្វីៗបែកបាក់តាមរបៀបដែលមិនអាចទាយទុកជាមុនបាន។ ពេលខ្លះមនុស្សនិយាយថាទេ វានឹងមិនកើតឡើងទេ។ ហើយវាកើតឡើងគ្រប់ពេលវេលា។ វាកើតឡើងជាញឹកញាប់គ្រប់គ្រាន់។ ហើយនោះហើយជាមូលហេតុដែលគ្មាននរណាម្នាក់ព្យាយាមសម្រាប់ភាពអាចរកបាន 100% នោះទេព្រោះភាពអាចរកបាន 100% មិនដែលកើតឡើងទេ។ នេះគឺជាបទដ្ឋាន។ ដូច្នេះហើយ នៅពេលដែលយើងនិយាយអំពីភាពអាចរកបាននៃសេវាកម្មមួយ យើងតែងតែនិយាយអំពីប្រាំបួន។ 2 ប្រាំបួន, 3 ប្រាំបួន, 4 ប្រាំបួន, 5 ប្រាំបួន។ ប្រសិនបើយើងបកប្រែវាទៅជាពេលវេលារងចាំ នោះឧទាហរណ៍ 5 nine បន្ទាប់មកនេះគឺតិចជាង 5 នាទីនៃពេលវេលារងចាំក្នុងមួយឆ្នាំ 2 nine គឺ 3,5 ថ្ងៃនៃពេលវេលារងចាំ។

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

សំណួរសំខាន់មួយនៅទីនេះគឺអ្វីដែលជាភាពជឿជាក់នៃសមាសធាតុដែលនៅសល់។ ដោយសារតែភាពខុសគ្នារវាង 4 និង 5 nine នឹងមិនអាចមើលឃើញនៅលើស្មាតហ្វូនដែលមាន 2 nine នៃភាពជឿជាក់។ និយាយឱ្យចំទៅ ប្រសិនបើអ្វីមួយខូចនៅលើស្មាតហ្វូននៅក្នុងសេវាកម្មរបស់អ្នក 10 ដងក្នុងមួយឆ្នាំ ភាគច្រើនទំនងជា 8 ដងការបែកបាក់បានកើតឡើងនៅលើផ្នែក OS ។ អ្នក​ប្រើ​ត្រូវ​បាន​ប្រើ​ដើម្បី​នេះ ហើយ​នឹង​មិន​យក​ចិត្ត​ទុក​ដាក់​ទៅ​មួយ​ដង​ទៀត​ក្នុង​មួយ​ឆ្នាំ​។ វាចាំបាច់ក្នុងការកែតម្រូវតម្លៃនៃការបង្កើនភាពជឿជាក់និងការបង្កើនប្រាក់ចំណេញ។
គ្រាន់តែនៅក្នុងសៀវភៅស្តីពី SRE មានឧទាហរណ៍ដ៏ល្អនៃការបង្កើនដល់ 4 ប្រាំបួន ពី 3 ប្រាំបួន។ វាប្រែថាការកើនឡើងនៃភាពអាចរកបានគឺតិចជាង 0,1% បន្តិច។ ហើយប្រសិនបើប្រាក់ចំណូលនៃសេវាកម្មគឺ 1 លានដុល្លារក្នុងមួយឆ្នាំនោះការកើនឡើងនៃប្រាក់ចំណូលគឺ 900 ដុល្លារ។ ប្រសិនបើវាចំណាយយើងតិចជាង $900 ក្នុងមួយឆ្នាំ ដើម្បីបង្កើនលទ្ធភាពទទួលបានត្រឹមប្រាំបួន ការកើនឡើងនេះធ្វើឱ្យយល់អំពីហិរញ្ញវត្ថុ។ ប្រសិនបើវាមានតម្លៃលើសពី 900 ដុល្លារក្នុងមួយឆ្នាំ វាលែងមានន័យទៀតហើយ ពីព្រោះការកើនឡើងនៃប្រាក់ចំណូលគ្រាន់តែមិនប៉ះប៉ូវថ្លៃពលកម្ម ថ្លៃធនធាន។ ហើយ 3 ប្រាំបួននឹងគ្រប់គ្រាន់សម្រាប់យើង។

នេះ​ជា​ការ​ពិត​ណាស់​ឧទាហរណ៍​សាមញ្ញ​ដែល​សំណើ​ទាំង​អស់​គឺ​ស្មើ​គ្នា។ ហើយការទៅពី 3 ប្រាំបួន ទៅ 4 ប្រាំបួន គឺងាយស្រួលគ្រប់គ្រាន់ ប៉ុន្តែនៅពេលជាមួយគ្នា ឧទាហរណ៍ ពី 2 ប្រាំបួន ទៅ 3 នេះគឺជាការសន្សំរួចហើយ 9 ពាន់ដុល្លារ វាអាចមានន័យផ្នែកហិរញ្ញវត្ថុ។ តាមការពិត ការបរាជ័យនៃសំណើចុះឈ្មោះគឺអាក្រក់ជាងការមិនបង្ហាញទំព័រ សំណើមានទម្ងន់ខុសៗគ្នា។ ពួកគេអាចមានលក្ខណៈវិនិច្ឆ័យខុសគ្នាទាំងស្រុងពីទស្សនៈអាជីវកម្ម ប៉ុន្តែទោះជាយ៉ាងណា តាមក្បួនមួយ ប្រសិនបើយើងមិននិយាយអំពីសេវាកម្មជាក់លាក់មួយចំនួន នេះគឺជាការប៉ាន់ស្មានដែលអាចទុកចិត្តបាន។
យើងបានទទួលសំណួរថាតើ SRE គឺជាអ្នកសម្របសម្រួលម្នាក់នៅពេលជ្រើសរើសដំណោះស្រាយស្ថាបត្យកម្មសម្រាប់សេវាកម្ម។ ចូរនិយាយនៅក្នុងលក្ខខណ្ឌនៃការធ្វើសមាហរណកម្មចូលទៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធដែលមានស្រាប់ដូច្នេះថាមិនមានការបាត់បង់នៅក្នុងស្ថិរភាពរបស់ខ្លួន។ បាទ/ចាស៎ SREs តាមរបៀបដូចគ្នាដែលទាញសំណើ ការប្តេជ្ញាចិត្ត ការចេញផ្សាយប៉ះពាល់ដល់ស្ថាបត្យកម្ម ការណែនាំនៃសេវាកម្មថ្មី សេវាមីក្រូ ការអនុវត្តដំណោះស្រាយថ្មី។ ហេតុអ្វី​បាន​ជា​ខ្ញុំ​និយាយ​មុន​ពេល​មាន​បទ​ពិសោធ​នោះ​ចាំបាច់​ត្រូវ​មាន​គុណវុឌ្ឍិ។ តាមពិត SRE គឺជាសំឡេងរារាំងមួយនៅក្នុងដំណោះស្រាយស្ថាបត្យកម្ម និងសូហ្វវែរណាមួយ។ ដូច្នោះហើយ SRE ជាវិស្វករត្រូវតែយល់ជាដំបូង មិនត្រឹមតែយល់ប៉ុណ្ណោះទេ ប៉ុន្តែក៏ត្រូវយល់ពីរបៀបដែលការសម្រេចចិត្តជាក់លាក់មួយចំនួននឹងប៉ះពាល់ដល់ភាពជឿជាក់ ស្ថេរភាព និងយល់ពីរបៀបដែលវាទាក់ទងទៅនឹងតម្រូវការអាជីវកម្ម ហើយតាមទស្សនៈដែលវាអាចទទួលយកបាន និង ដែលមិនមែន

ដូច្នេះហើយ ឥឡូវនេះយើងអាចនិយាយអំពីលក្ខណៈវិនិច្ឆ័យភាពអាចជឿជាក់បាន ដែលត្រូវបានកំណត់ជាប្រពៃណីនៅក្នុង SRE ជា SLA (កិច្ចព្រមព្រៀងកម្រិតសេវាកម្ម)។ ភាគច្រើនទំនងជាពាក្យដែលធ្លាប់ស្គាល់។ SLI (សូចនាករកម្រិតសេវាកម្ម) ។ SLO (គោលបំណងកម្រិតសេវាកម្ម) ។ កិច្ចព្រមព្រៀងកម្រិតសេវាកម្មប្រហែលជាពាក្យនិមិត្តសញ្ញា ជាពិសេសប្រសិនបើអ្នកបានធ្វើការជាមួយបណ្តាញ ជាមួយអ្នកផ្តល់សេវា ជាមួយនឹងការបង្ហោះ។ នេះគឺជាកិច្ចព្រមព្រៀងទូទៅដែលពិពណ៌នាអំពីការអនុវត្តសេវាកម្មទាំងមូលរបស់អ្នក ការពិន័យ ការពិន័យមួយចំនួនចំពោះកំហុស មាត្រដ្ឋាន លក្ខណៈវិនិច្ឆ័យ។ ហើយ SLI គឺជាមាត្រដ្ឋានដែលអាចរកបានដោយខ្លួនឯង។ នោះហើយជាអ្វីដែល SLI អាចជា: ពេលវេលាឆ្លើយតបពីសេវាកម្មចំនួននៃកំហុសជាភាគរយ។ វាអាចជាកម្រិតបញ្ជូន ប្រសិនបើវាជាប្រភេទនៃការបង្ហោះឯកសារមួយចំនួន។ នៅពេលដែលវាមកដល់ក្បួនដោះស្រាយការទទួលស្គាល់ សូចនាករអាចជាឧទាហរណ៍ សូម្បីតែភាពត្រឹមត្រូវនៃចម្លើយ។ SLO (គោលបំណងកម្រិតសេវាកម្ម) គឺជាការរួមបញ្ចូលគ្នានៃសូចនាករ SLI តម្លៃ និងរយៈពេលរបស់វា។

ចូរនិយាយថា SLA អាចជាដូចនេះ។ សេវាកម្មនេះមាន 99,95% នៃពេលវេលាពេញមួយឆ្នាំ។ ឬសំបុត្រគាំទ្រសំខាន់ៗចំនួន 99 នឹងត្រូវបិទក្នុងរយៈពេល 3 ម៉ោងក្នុងមួយត្រីមាស។ ឬ 85% នៃសំណួរនឹងទទួលបានការឆ្លើយតបក្នុងរយៈពេល 1,5 វិនាទីរៀងរាល់ខែ។ នោះ​គឺ​យើង​យល់​បន្តិច​ម្ដងៗ​ថា កំហុស​និង​ការ​បរាជ័យ​គឺ​ជា​រឿង​ធម្មតា​ហើយ។ នេះគឺជាស្ថានភាពដែលអាចទទួលយកបាន យើងកំពុងរៀបចំផែនការ យើងថែមទាំងពឹងផ្អែកលើវាដល់កម្រិតខ្លះ។ នោះគឺ SRE បង្កើតប្រព័ន្ធដែលអាចធ្វើឱ្យមានកំហុស ដែលត្រូវតែឆ្លើយតបជាធម្មតាចំពោះកំហុស ដែលត្រូវតែយកមកពិចារណា។ ហើយនៅពេលណាដែលអាចធ្វើទៅបាន ពួកគេគួរតែដោះស្រាយកំហុសតាមរបៀបដែលអ្នកប្រើប្រាស់មិនបានកត់សម្គាល់ ឬជូនដំណឹង ប៉ុន្តែមានវិធីដោះស្រាយមួយចំនួន អរគុណដែលអ្វីៗនឹងមិនធ្លាក់ចុះទាំងស្រុង។

ឧទាហរណ៍ ប្រសិនបើអ្នកបង្ហោះវីដេអូទៅ YouTube ហើយ YouTube មិនអាចបំប្លែងវាភ្លាមៗបានទេ ប្រសិនបើវីដេអូមានទំហំធំពេក ប្រសិនបើទម្រង់មិនត្រឹមត្រូវ នោះសំណើនឹងមិនបរាជ័យជាធម្មជាតិជាមួយនឹងពេលវេលាកំណត់នោះទេ YouTube នឹងមិនផ្តល់កំហុស 502 ទេ។ YouTube នឹងនិយាយថា៖ “យើងបានបង្កើតអ្វីៗគ្រប់យ៉ាង វីដេអូរបស់អ្នកកំពុងដំណើរការ។ វានឹងរួចរាល់ក្នុងរយៈពេលប្រហែល 10 នាទី" ។ នេះគឺជាគោលការណ៍នៃការរិចរិលប្រកបដោយគុណធម៌ ដែលធ្លាប់ស្គាល់ ជាឧទាហរណ៍ ពីការអភិវឌ្ឍន៍ផ្នែកខាងមុខ ប្រសិនបើអ្នកធ្លាប់ធ្វើបែបនេះ។

ពាក្យបន្ទាប់ដែលយើងនឹងនិយាយអំពី ដែលមានសារៈសំខាន់ខ្លាំងណាស់សម្រាប់ធ្វើការជាមួយភាពអាចជឿជាក់បាន ជាមួយនឹងកំហុស ជាមួយនឹងការរំពឹងទុកគឺ MTBF និង MTTR ។ MTBF គឺជាពេលវេលាមធ្យមរវាងការបរាជ័យ។ MTTR Mean Time To Recovery ពេលវេលាជាមធ្យមក្នុងការងើបឡើងវិញ។ នោះគឺថាតើពេលវេលាបានកន្លងផុតទៅប៉ុន្មានពីពេលដែលកំហុសត្រូវបានរកឃើញ ចាប់ពីពេលដែលកំហុសលេចឡើងរហូតដល់ពេលដែលសេវាកម្មត្រូវបានស្ដារឡើងវិញនូវប្រតិបត្តិការធម្មតាពេញលេញ។ MTBF ត្រូវបានជួសជុលជាចម្បងដោយការងារលើគុណភាពកូដ។ នោះគឺជាការពិតដែលថា SREs អាចនិយាយថា "ទេ" ។ ហើយអ្នកត្រូវការការយល់ដឹងពីក្រុមទាំងមូលថានៅពេលដែល SRE និយាយថា "ទេ" គាត់និយាយថាមិនមែនដោយសារតែគាត់មានគ្រោះថ្នាក់ មិនមែនដោយសារតែគាត់អាក្រក់ទេ ប៉ុន្តែដោយសារតែបើមិនដូច្នេះទេអ្នកគ្រប់គ្នានឹងរងទុក្ខ។

ជាថ្មីម្តងទៀត មានអត្ថបទជាច្រើន វិធីសាស្រ្តជាច្រើន វិធីជាច្រើន សូម្បីតែនៅក្នុងសៀវភៅដែលខ្ញុំលើកឡើងជាញឹកញាប់ របៀបធ្វើឱ្យប្រាកដថា អ្នកអភិវឌ្ឍន៍ផ្សេងទៀតមិនចាប់ផ្តើមស្អប់ SRE ។ ម៉្យាងវិញទៀត MTTR គឺនិយាយអំពីការធ្វើការលើ SLOs របស់អ្នក (គោលបំណងកម្រិតសេវាកម្ម)។ ហើយភាគច្រើនជាស្វ័យប្រវត្តិកម្ម។ ពីព្រោះជាឧទាហរណ៍ SLO របស់យើងគឺជាម៉ោងដំណើរការ 4 ប្រាំបួនក្នុងមួយត្រីមាស។ នេះ​មាន​ន័យ​ថា​ក្នុង​រយៈ​ពេល 3 ខែ​យើង​អាច​អនុញ្ញាត​ឱ្យ​មាន​ការ​ឈប់​សម្រាក 13 នាទី​។ ហើយវាប្រែថា MTTR មិនអាចលើសពី 13 នាទីបានទេ។ ប្រសិនបើយើងឆ្លើយតបទៅនឹងពេលវេលារងចាំយ៉ាងហោចណាស់ 13 ដងក្នុងរយៈពេល 1 នាទី នេះមានន័យថាយើងបានអស់ថវិកាទាំងស្រុងសម្រាប់ត្រីមាសរួចហើយ។ យើងកំពុងបំបែក SLO ។ 13 នាទីដើម្បីប្រតិកម្ម និងជួសជុលការគាំងគឺច្រើនសម្រាប់ម៉ាស៊ីន ប៉ុន្តែខ្លីណាស់សម្រាប់មនុស្ស។ ព្រោះ​ទាល់​តែ​មនុស្ស​ម្នាក់​ទទួល​បាន​ការ​ជូន​ដំណឹង ទាល់​តែ​គាត់​ប្រតិកម្ម ទាល់​តែ​គាត់​យល់​ពី​កំហុស​នោះ វា​ច្រើន​នាទី​ហើយ។ ទាល់តែ​មនុស្ស​ម្នាក់​យល់​ពី​វិធី​ជួសជុល​នោះ តើ​ត្រូវ​ជួសជុល​អ្វី​ឱ្យ​ប្រាកដ អ្វីដែលត្រូវធ្វើ នោះ​គឺ​ប៉ុន្មាន​នាទី​ទៀត។ ហើយតាមពិតទៅ ទោះបីជាអ្នកគ្រាន់តែត្រូវចាប់ផ្តើមម៉ាស៊ីនមេឡើងវិញ ដូចដែលវាប្រែចេញ ឬដំឡើងថ្នាំងថ្មីក៏ដោយ បន្ទាប់មក MTTR ដោយដៃគឺប្រហែល 7-8 នាទីរួចទៅហើយ។ នៅពេលដំណើរការដោយស្វ័យប្រវត្តិ MTTR ច្រើនតែឈានដល់មួយវិនាទី ជួនកាលមិល្លីវិនាទី។ ជាធម្មតា Google និយាយអំពីមីលីវិនាទី ប៉ុន្តែតាមពិតទៅ អ្វីៗគឺមិនល្អទាល់តែសោះ។

តាមឧត្ដមគតិ SRE គួរតែធ្វើស្វ័យប្រវត្តិកម្មការងាររបស់ខ្លួនស្ទើរតែទាំងស្រុង ពីព្រោះវាប៉ះពាល់ដោយផ្ទាល់ដល់ MTTR រង្វាស់របស់វា SLO នៃសេវាកម្មទាំងមូល ហើយតាមនោះ ប្រាក់ចំណេញអាជីវកម្ម។ ប្រសិនបើពេលវេលាលើស យើងត្រូវបានសួរថាតើ SRE មានកំហុសដែរឬទេ។ ជាសំណាងល្អគ្មាននរណាម្នាក់ត្រូវស្តីបន្ទោសទេ។ ហើយនេះគឺជាវប្បធម៌ដាច់ដោយឡែកមួយហៅថា balmeless postmortem ដែលយើងនឹងមិននិយាយអំពីថ្ងៃនេះ ប៉ុន្តែយើងនឹងវិភាគវានៅលើ Slurm ។ នេះ​ជា​ប្រធាន​បទ​ដ៏​គួរ​ឱ្យ​ចាប់​អារម្មណ៍​មួយ​ដែល​អាច​និយាយ​បាន​ច្រើន។ និយាយដោយប្រយោល ប្រសិនបើពេលវេលាកំណត់ក្នុងមួយត្រីមាសលើសពីនេះ អ្នកត្រូវស្តីបន្ទោសបន្តិច មានន័យថា បន្ទោសអ្នកគ្រប់គ្នាគ្មានផលិតភាពទេ ផ្ទុយទៅវិញ ប្រហែលជាមិនបន្ទោសអ្នកណាទេ ប៉ុន្តែកែតម្រូវស្ថានភាព និងធ្វើការជាមួយអ្វីដែលយើងមាន។ តាមបទពិសោធន៍របស់ខ្ញុំ វិធីសាស្រ្តនេះគឺចម្លែកបន្តិចសម្រាប់ក្រុមភាគច្រើន ជាពិសេសនៅក្នុងប្រទេសរុស្ស៊ី ប៉ុន្តែវាសមហេតុផល និងដំណើរការល្អណាស់។ ដូច្នេះខ្ញុំនឹងណែនាំនៅចុងបញ្ចប់នៃអត្ថបទនិងអក្សរសិល្ប៍ដែលអ្នកអាចអានលើប្រធានបទនេះ។ ឬមកកាន់ Slurm SRE។

អនុញ្ញាតឱ្យខ្ញុំពន្យល់។ ប្រសិនបើម៉ោង SLO ក្នុងមួយត្រីមាសគឺលើស ប្រសិនបើម៉ោងឈប់សម្រាកមិនមែន 13 នាទី ប៉ុន្តែ 15 តើនរណាអាចត្រូវស្តីបន្ទោសចំពោះបញ្ហានេះ? ជាការពិតណាស់ SRE ប្រហែលជាត្រូវស្តីបន្ទោស ពីព្រោះគាត់បានប្រព្រឹត្តិអំពើអាក្រក់ ឬការដាក់ពង្រាយយ៉ាងច្បាស់លាស់។ អ្នកគ្រប់គ្រងមជ្ឈមណ្ឌលទិន្នន័យអាចនឹងត្រូវស្តីបន្ទោសចំពោះបញ្ហានេះ ពីព្រោះគាត់ប្រហែលជាបានអនុវត្តប្រភេទនៃការថែទាំដែលមិនបានគ្រោងទុក។ ប្រសិនបើអ្នកគ្រប់គ្រងមជ្ឈមណ្ឌលទិន្នន័យត្រូវស្តីបន្ទោសចំពោះបញ្ហានេះ នោះអ្នកដែលមកពី Ops ត្រូវស្តីបន្ទោសចំពោះបញ្ហានេះ ដែលមិនបានគណនាការថែទាំនៅពេលដែលគាត់បានសម្របសម្រួល SLO ។ អ្នកគ្រប់គ្រង នាយកបច្ចេកទេស ឬនរណាម្នាក់ដែលបានចុះហត្ថលេខាលើកិច្ចសន្យាមជ្ឈមណ្ឌលទិន្នន័យ ហើយមិនបានយកចិត្តទុកដាក់ចំពោះការពិតដែលថា SLA នៃមជ្ឈមណ្ឌលទិន្នន័យមិនត្រូវបានរចនាឡើងសម្រាប់ពេលវេលារងចាំដែលត្រូវការគឺត្រូវស្តីបន្ទោសចំពោះបញ្ហានេះ។ ដូច្នោះហើយបន្តិចម្តង ៗ ក្នុងស្ថានភាពនេះគឺត្រូវស្តីបន្ទោស។ ហើយ​វា​មាន​ន័យ​ថា​គ្មាន​ចំណុច​ណា​មួយ​ក្នុង​ការ​បន្ទោស​អ្នក​ណា​ម្នាក់​ក្នុង​ស្ថានភាព​នេះ​ទេ។ ប៉ុន្តែ​ជា​ការ​ពិត​ណាស់ វា​ត្រូវ​តែ​កែ​តម្រូវ។ ហេតុ​ដូច្នេះ​ហើយ​ទើប​មាន​ការ​ធ្វើ​កោសល្យវិច័យ។ ហើយប្រសិនបើអ្នកអានឧទាហរណ៍ GitHub postmortems ហើយនេះតែងតែជារឿងគួរឱ្យចាប់អារម្មណ៍ តូច និងមិននឹកស្មានដល់ក្នុងករណីនីមួយៗ អ្នកអាចជំនួសបានថាគ្មាននរណាម្នាក់ដែលនិយាយថាមនុស្សពិសេសនេះត្រូវស្តីបន្ទោសនោះទេ។ ការស្តីបន្ទោសតែងតែត្រូវបានដាក់លើដំណើរការមិនល្អឥតខ្ចោះជាក់លាក់។

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

តាមការពិត វាស្ទើរតែតែងតែមាន ហើយមានករណីតិចតួចណាស់ដែលអ្វីមួយដែលមិនគួរត្រូវបានស្វ័យប្រវត្តិក្នុងតួនាទីរបស់ SRE ។ បន្ទាប់យើងនឹងនិយាយអំពីអ្វីដែលគេហៅថា ថវិកាកំហុស ថវិកាសម្រាប់កំហុស។ តាមពិតទៅ វាប្រែថាប្រសិនបើអ្វីៗគ្រប់យ៉ាងល្អសម្រាប់អ្នកជាង SLO ដែលអ្នកកំណត់សម្រាប់ខ្លួនអ្នក នោះក៏មិនល្អខ្លាំងដែរ។ នេះគឺអាក្រក់ជាងព្រោះ SLO ធ្វើការមិនត្រឹមតែជាកម្រិតទាបប៉ុណ្ណោះទេប៉ុន្តែក៏ជាព្រំដែនខាងលើប្រហាក់ប្រហែលផងដែរ។ នៅពេលអ្នកកំណត់ខ្លួនអ្នកនូវភាពអាចរកបាន 99% ហើយតាមពិតអ្នកមាន 99,99% វាប្រែថាអ្នកមានកន្លែងខ្លះសម្រាប់ការពិសោធន៍ដែលនឹងមិនប៉ះពាល់ដល់អាជីវកម្មទាល់តែសោះ ពីព្រោះអ្នកខ្លួនឯងបានកំណត់វាទាំងអស់គ្នា ហើយអ្នកគឺជាអ្នក កន្លែងនេះមិនប្រើទេ។ អ្នកមានថវិកាសម្រាប់កំហុស ដែលក្នុងករណីរបស់អ្នកមិនត្រូវបានប្រើប្រាស់។

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

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

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

វាប្រែថាការពិសោធន៍ក្នុងផលិតកម្មពិតជាផ្នែកសំខាន់ និងស្ទើរតែសំខាន់នៃ SRE នៅក្នុងក្រុមធំ។ ហើយជាធម្មតាវាត្រូវបានគេហៅថាវិស្វកម្មភាពវឹកវរ ដែលមកពីក្រុមនៅក្រុមហ៊ុន Netflix ដែលបានចេញផ្សាយឧបករណ៍ប្រើប្រាស់មួយឈ្មោះថា Chaos Monkey។
Chaos Monkey ភ្ជាប់ទៅបំពង់ CI/CD ហើយគាំងម៉ាស៊ីនមេនៅក្នុងផលិតកម្មដោយចៃដន្យ។ ជាថ្មីម្តងទៀតនៅក្នុងរចនាសម្ព័ន្ធ SRE យើងកំពុងនិយាយអំពីការពិតដែលថាម៉ាស៊ីនមេដែលបានធ្លាក់ចុះគឺមិនអាក្រក់នៅក្នុងខ្លួនវាទេវាត្រូវបានរំពឹងទុក។ ហើយ​ប្រសិន​បើ​វា​ស្ថិត​នៅ​ក្នុង​ថវិកា​គឺ​អាច​ទទួល​យក​បាន​ហើយ​មិន​ប៉ះពាល់​ដល់​អាជីវកម្ម​នោះ​ទេ។ ជាការពិតណាស់ក្រុមហ៊ុន Netflix មានម៉ាស៊ីនមេដែលលែងត្រូវការតទៅទៀត ការចម្លងគ្រប់គ្រាន់ ដូច្នេះអ្វីៗទាំងអស់នេះអាចត្រូវបានជួសជុល ហើយដូច្នេះអ្នកប្រើប្រាស់ទាំងមូលមិនកត់សំគាល់ ហើយសូម្បីតែច្រើនទៀតដូច្នេះគ្មាននរណាម្នាក់ចាកចេញពីម៉ាស៊ីនមេសម្រាប់ថវិកាណាមួយឡើយ។

ក្រុមហ៊ុន Netflix មានឈុតទាំងមូលនៃឧបករណ៍ប្រើប្រាស់បែបនេះអស់មួយរយៈ ដែលមួយក្នុងចំណោមនោះ Chaos Gorilla បានបិទទាំងស្រុងនូវតំបន់ដែលមានលក់របស់ Amazon ។ ហើយរឿងបែបនេះជួយបង្ហាញឱ្យឃើញ ជាដំបូង ភាពអាស្រ័យដែលលាក់កំបាំង នៅពេលដែលវាមិនច្បាស់ទាំងស្រុងថាតើអ្វីប៉ះពាល់ដល់អ្វី អ្វីអាស្រ័យលើអ្វី។ ហើយនេះ ប្រសិនបើអ្នកកំពុងធ្វើការជាមួយសេវាមីក្រូ ហើយឯកសារមិនល្អឥតខ្ចោះទេ នេះប្រហែលជាស្គាល់អ្នក។ ហើយម្តងទៀត នេះជួយបានច្រើនក្នុងការចាប់កំហុសនៅក្នុងកូដដែលអ្នកមិនអាចចាប់បាននៅលើឆាក ព្រោះដំណាក់កាលណាមួយមិនមែនជាការក្លែងធ្វើពិតប្រាកដនោះទេ ដោយសារតែទំហំផ្ទុកខុសគ្នា លំនាំនៃការផ្ទុកគឺខុសគ្នា ឧបករណ៍គឺ ផងដែរ, ភាគច្រើនទំនងជា, ផ្សេងទៀត។ ការផ្ទុកខ្ពស់បំផុតក៏អាចជាការរំពឹងទុក និងមិនអាចទាយទុកជាមុនបាន។ ហើយការសាកល្បងបែបនេះ ដែលម្តងទៀតមិនហួសពីថវិកា ជួយបានយ៉ាងល្អក្នុងការចាប់កំហុសក្នុងហេដ្ឋារចនាសម្ព័ន្ធដែលដំណើរការ ការធ្វើតេស្តស្វ័យប្រវត្តិ បំពង់បង្ហូរ CI/CD នឹងមិនចាប់បានទេ។ ហើយដរាបណាវារួមបញ្ចូលទាំងអស់នៅក្នុងថវិការបស់អ្នក វាមិនមានបញ្ហាទេដែលសេវាកម្មរបស់អ្នកបានធ្លាក់ចុះនៅទីនោះ ទោះបីជាវាហាក់ដូចជាគួរឱ្យខ្លាចណាស់ ម៉ាស៊ីនមេបានធ្លាក់ចុះ អ្វីដែលជាសុបិន្តអាក្រក់។ ទេ វាជារឿងធម្មតា នោះជាការល្អ ដែលជួយចាប់កំហុស។ ប្រសិនបើអ្នកមានថវិកា នោះអ្នកអាចចំណាយវាបាន។

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

ដូចគ្នាដែរចំពោះគម្រោងតូច អង្គការតូច ព្រោះក្រុមហ៊ុនធំៗមានថវិកា និងកន្លែងសម្រាប់ពិសោធន៍។ ប៉ុន្តែនៅពេលជាមួយគ្នានោះ ផ្លែឈើនៃការពិសោធន៍ទាំងអស់នេះអាចប្រើប្រាស់បានគ្រប់ទីកន្លែង នោះគឺ SRE ពិតណាស់បានបង្ហាញខ្លួននៅក្នុង Google ក្នុង Netflix ក្នុង Dropbox ។ ប៉ុន្តែក្នុងពេលជាមួយគ្នានេះ ក្រុមហ៊ុនតូចៗ និងអ្នកចាប់ផ្តើមអាជីវកម្មអាចអានឯកសារ អានសៀវភៅ មើលរបាយការណ៍រួចហើយ។ ពួកគេចាប់ផ្តើមឮអំពីវាកាន់តែញឹកញាប់ ពួកគេមើលឧទាហរណ៍ជាក់លាក់ ខ្ញុំគិតថាវាមិនអីទេ វាពិតជាអាចមានប្រយោជន៍ យើងក៏ត្រូវការវាផងដែរ វាល្អណាស់។

នោះគឺការងារសំខាន់ៗទាំងអស់លើការធ្វើស្តង់ដារដំណើរការទាំងនេះត្រូវបានធ្វើរួចសម្រាប់អ្នក។ វានៅសល់សម្រាប់អ្នកដើម្បីកំណត់តួនាទីរបស់ SRE ជាពិសេសនៅក្នុងក្រុមហ៊ុនរបស់អ្នក ហើយចាប់ផ្តើមអនុវត្តជាក់ស្តែងនូវការអនុវត្តទាំងអស់នេះ ដែលជាថ្មីម្តងទៀតត្រូវបានពិពណ៌នារួចហើយ។ នោះគឺពីគោលការណ៍មានប្រយោជន៍សម្រាប់ក្រុមហ៊ុនតូចៗ នេះតែងតែជានិយមន័យនៃ SLA, SLI, SLO ។ ប្រសិនបើអ្នកមិនចូលរួមក្នុងកម្មវិធីទេនោះ ទាំងនេះនឹងជា SLAs ខាងក្នុង និង SLOs ខាងក្នុង ដែលជាថវិកាខាងក្នុងសម្រាប់កំហុស។ នេះស្ទើរតែតែងតែនាំឱ្យមានការពិភាក្សាគួរឱ្យចាប់អារម្មណ៍មួយចំនួននៅក្នុងក្រុម និងនៅក្នុងអាជីវកម្ម ព្រោះវាអាចនឹងបង្ហាញថាអ្នកចំណាយលើហេដ្ឋារចនាសម្ព័ន្ធ លើប្រភេទនៃការរៀបចំដំណើរការដ៏ល្អ បំពង់បង្ហូរប្រេងដ៏ល្អគឺលើសពីការចាំបាច់។ ហើយទាំង 4 នេះដែលអ្នកមាននៅក្នុងផ្នែក IT អ្នកពិតជាមិនត្រូវការវាឥឡូវនេះទេ។ ប៉ុន្តែនៅពេលជាមួយគ្នានេះ អ្នកអាចចំណាយពេលវេលា ចំណាយថវិកាសម្រាប់កំហុសលើអ្វីផ្សេងទៀត។

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

ចុងក្រោយនៃការ nuances បច្ចេកទេសដែលត្រូវនិយាយអំពីគឺការត្រួតពិនិត្យ។ ដោយសារតែប្រសិនបើយើងកំពុងនិយាយអំពី SLA, SLI, SLO នោះយើងមិនអាចយល់បានដោយមិនចាំបាច់ត្រួតពិនិត្យថាតើយើងសមនឹងថវិកា ថាតើយើងគោរពតាមគោលបំណងរបស់យើង និងរបៀបដែលយើងមានឥទ្ធិពលលើ SLA ចុងក្រោយ។ ខ្ញុំបានឃើញច្រើនដងហើយដែលការត្រួតពិនិត្យកើតឡើងដូចនេះ៖ មានតម្លៃមួយចំនួន ឧទាហរណ៍ ពេលវេលានៃការស្នើសុំទៅកាន់ម៉ាស៊ីនមេ រយៈពេលមធ្យម ឬចំនួនសំណើទៅកាន់មូលដ្ឋានទិន្នន័យ។ គាត់មានស្តង់ដារកំណត់ដោយវិស្វករ។ ប្រសិនបើម៉ែត្រគម្លាតពីបទដ្ឋាន នោះអ៊ីមែលមកដល់។ នេះពិតជាគ្មានប្រយោជន៍ទេ ជាក្បួន ព្រោះវានាំទៅរកការដាស់តឿនបែបនេះ ភាពច្របូកច្របល់នៃសារពីការត្រួតពិនិត្យ នៅពេលដែលមនុស្សម្នាក់ត្រូវតែបកស្រាយវារាល់ពេល ពោលគឺកំណត់ថាតើតម្លៃនៃម៉ែត្រមានន័យ តម្រូវការសម្រាប់សកម្មភាពមួយចំនួន។ ហើយទីពីរ គាត់គ្រាន់តែឈប់កត់សម្គាល់ការដាស់តឿនទាំងអស់នេះ នៅពេលដែលជាមូលដ្ឋានមិនតម្រូវឱ្យមានសកម្មភាពណាមួយពីគាត់។ នោះគឺជាច្បាប់ត្រួតពិនិត្យដ៏ល្អ ហើយច្បាប់ដំបូងបំផុតនៅពេលដែល SRE ត្រូវបានអនុវត្តគឺថាការជូនដំណឹងគួរតែមកនៅពេលដែលសកម្មភាពត្រូវបានទាមទារ។

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

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

ពីការត្រួតពិនិត្យ យើងបន្តទៅពាក្យដែលហៅថា Observability ។ វាក៏មានការបំផ្លើសបន្តិចជុំវិញពាក្យនេះ ក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ។ ហើយមានមនុស្សតិចណាស់ដែលយល់ថាវាមានន័យខុសពីបរិបទ។ ប៉ុន្តែចំណុចសំខាន់គឺថា Observability គឺជាម៉ែត្រសម្រាប់តម្លាភាពប្រព័ន្ធ។ ប្រសិនបើមានអ្វីមួយខុសប្រក្រតី តើអ្នកអាចកំណត់បានលឿនប៉ុណ្ណាថាមានអ្វីខុស និងស្ថានភាពនៃប្រព័ន្ធនៅពេលនោះ។ នៅក្នុងលក្ខខណ្ឌនៃកូដ៖ មុខងារណាដែលបរាជ័យ សេវាកម្មណាដែលបរាជ័យ។ តើអ្វីជាស្ថានភាពនៃឧទាហរណ៍ អថេរខាងក្នុង ការកំណត់រចនាសម្ព័ន្ធ។ នៅក្នុងលក្ខខណ្ឌនៃហេដ្ឋារចនាសម្ព័ន្ធ វាស្ថិតនៅក្នុងតំបន់ដែលអាចរកបាន ការបរាជ័យបានកើតឡើង ហើយប្រសិនបើអ្នកមាន Kubernetes ណាមួយនោះ ការបរាជ័យបានកើតឡើងនៅក្នុង pod នោះ តើអ្វីជាស្ថានភាពរបស់ pod ។ ហើយតាមនោះ Observability មានទំនាក់ទំនងផ្ទាល់ជាមួយ MTTR ។ ភាពអាចអង្កេតបានខ្ពស់នៃសេវាកម្ម វាកាន់តែងាយស្រួលក្នុងការកំណត់អត្តសញ្ញាណកំហុស វាកាន់តែងាយស្រួលក្នុងការជួសជុលកំហុស វាកាន់តែងាយស្រួលធ្វើស្វ័យប្រវត្តិកម្ម MTTR កាន់តែទាប។

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

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

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

មានសំណួរអំពីឧបករណ៍ SRE ។ នោះគឺមានអ្វីមួយជាពិសេសដែល SREs នឹងប្រើដែលអ្នកផ្សេងទៀតនឹងមិន។ តាមការពិត មានឧបករណ៍ប្រើប្រាស់ឯកទេសខ្ពស់មួយចំនួន មានប្រភេទកម្មវិធីមួយចំនួន ដែលឧទាហរណ៍ ក្លែងធ្វើការផ្ទុក ឬត្រូវបានចូលរួមនៅក្នុងការធ្វើតេស្ត Canary A/B ។ ប៉ុន្តែជាទូទៅ កញ្ចប់ឧបករណ៍ SRE គឺជាអ្វីដែលអ្នកអភិវឌ្ឍន៍កំពុងប្រើរួចហើយ។ ដោយសារតែ SRE ធ្វើអន្តរកម្មដោយផ្ទាល់ជាមួយក្រុមអភិវឌ្ឍន៍។ ហើយប្រសិនបើអ្នកមានឧបករណ៍ផ្សេងគ្នា វានឹងបង្ហាញថាវាត្រូវការពេលវេលាដើម្បីធ្វើសមកាលកម្ម។ ជាពិសេសប្រសិនបើ SREs ធ្វើការជាក្រុមធំ ក្នុងក្រុមហ៊ុនធំៗដែលអាចមានក្រុមច្រើន វាគឺជាស្តង់ដាររបស់ក្រុមហ៊ុនដែលនឹងជួយបានច្រើននៅទីនេះ ព្រោះប្រសិនបើឧបករណ៍ប្រើប្រាស់ផ្សេងៗចំនួន 50 ត្រូវបានប្រើប្រាស់ក្នុងក្រុមចំនួន 50 នោះមានន័យថា SRE ត្រូវតែស្គាល់ពួកគេ។ ទាំងអស់។ ហើយជាការពិតណាស់រឿងនេះនឹងមិនកើតឡើងទេ។ ហើយ​គុណភាព​ការងារ គុណភាព​នៃ​ការ​ត្រួត​ពិនិត្យ​យ៉ាង​ហោច​ណាស់​ក្រុម​មួយ​ចំនួន​នឹង​ថយ​ចុះ​យ៉ាង​ខ្លាំង។

webinar របស់យើងជិតដល់ទីបញ្ចប់ហើយ។ ខ្ញុំ​អាច​ប្រាប់​រឿង​មូលដ្ឋាន​មួយ​ចំនួន។ ជាការពិតណាស់ គ្មានអ្វីអំពី SRE អាចត្រូវបានប្រាប់ និងយល់ក្នុងរយៈពេលមួយម៉ោង។ ប៉ុន្តែ​ខ្ញុំ​សង្ឃឹម​ថា​ខ្ញុំ​អាច​បង្ហាញ​ពី​របៀប​នៃ​ការ​គិត​នេះ​ដែល​ជា​ចំណុច​សំខាន់។ ហើយបន្ទាប់មកវានឹងអាចធ្វើទៅបាន ប្រសិនបើចាប់អារម្មណ៍ ស្វែងយល់ពីប្រធានបទ រៀនដោយខ្លួនឯង មើលពីរបៀបដែលវាត្រូវបានអនុវត្តដោយមនុស្សផ្សេងទៀត នៅក្នុងក្រុមហ៊ុនផ្សេងទៀត។ ដូច្នេះហើយ នៅដើមខែកុម្ភៈ សូមមករកយើងនៅ Slurm SRE។

Slurm SRE គឺជាវគ្គសិក្សាដែលពឹងផ្អែកខ្លាំងរយៈពេល XNUMX ថ្ងៃដែលនឹងនិយាយអំពីអ្វីដែលខ្ញុំកំពុងនិយាយឥឡូវនេះ ប៉ុន្តែកាន់តែស៊ីជម្រៅ ជាមួយនឹងករណីជាក់ស្តែង ជាមួយនឹងការអនុវត្ត ការពឹងផ្អែកទាំងមូលគឺផ្តោតលើការងារជាក់ស្តែង។ មនុស្សនឹងត្រូវបែងចែកជាក្រុម។ អ្នកទាំងអស់គ្នានឹងធ្វើការលើករណីពិត។ ដូច្នោះហើយយើងមានគ្រូបង្រៀន Booking.com Ivan Kruglov និង Ben Tyler ។ យើងមាន Eugene Barabbas ដ៏អស្ចារ្យពី Google ពី San Francisco ។ ហើយខ្ញុំនឹងប្រាប់អ្នកអ្វីមួយផងដែរ។ ដូច្នេះត្រូវប្រាកដថាមកលេងយើង។
ដូច្នេះគន្ថនិទ្ទេស។ មានឯកសារយោងលើ SRE ។ ដំបូង នៅលើសៀវភៅតែមួយ ឬជាសៀវភៅ 2 ក្បាលអំពី SRE ដែលសរសេរដោយ Google ។ មួយ​ផ្សេង​ទៀត អត្ថបទតូចមួយនៅលើ SLA, SLI, SLOដែលជាកន្លែងដែលលក្ខខណ្ឌ និងកម្មវិធីរបស់ពួកគេគឺលម្អិតជាងបន្តិច។ 3 បន្ទាប់គឺជារបាយការណ៍ស្តីពី SRE នៅក្នុងក្រុមហ៊ុនផ្សេងៗគ្នា។ ដំបូង - ពាក្យគន្លឹះទាក់ទងសម្រាប់ SREនេះ​គឺ​ជា​សុន្ទរកថា​ពី Ben Trainer នៃ Google ។ ទីពីរ - SRE នៅក្នុង Dropbox. ទីបីគឺម្តងទៀត SRE ទៅ Google. របាយការណ៍ទី ៤ ពី SRE នៅលើ Netflixដែលមានបុគ្គលិក SRE សំខាន់ៗចំនួន 5 នាក់ប៉ុណ្ណោះក្នុង 190 ប្រទេស។ វាគួរឱ្យចាប់អារម្មណ៍ណាស់ក្នុងការមើលទាំងអស់នេះ ពីព្រោះដូចដែល DevOps មានន័យខុសគ្នាខ្លាំងចំពោះក្រុមហ៊ុនផ្សេងៗគ្នា និងសូម្បីតែក្រុមផ្សេងៗគ្នា SRE មានទំនួលខុសត្រូវខុសគ្នាខ្លាំង សូម្បីតែនៅក្នុងក្រុមហ៊ុនដែលមានទំហំស្រដៀងគ្នាក៏ដោយ។

តំណភ្ជាប់ 2 បន្ថែមទៀតលើគោលការណ៍នៃវិស្វកម្មវឹកវរ: (1​), (2​). ហើយនៅចុងបញ្ចប់មានបញ្ជីចំនួន 3 ពីស៊េរី Awesome Lists អំពី វិស្វកម្មវឹកវរ, អំពី SRE និងអំពី កញ្ចប់ឧបករណ៍ SRE. បញ្ជីនៅលើ SRE គឺមានទំហំធំមិនគួរឱ្យជឿវាមិនចាំបាច់ឆ្លងកាត់វាទាំងអស់ទេមានប្រហែល 200 អត្ថបទ។ ខ្ញុំសូមផ្តល់អនុសាសន៍យ៉ាងខ្ពស់នូវអត្ថបទពីទីនោះអំពីការធ្វើផែនការសមត្ថភាព និងអំពីការធ្វើកោសល្យវិច័យដែលគ្មានកំហុស។

អត្ថបទគួរឱ្យចាប់អារម្មណ៍ៈ SRE ជាជម្រើសជីវិត

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

PS: សម្រាប់អ្នកដែលចូលចិត្តអាន Eduard បានផ្តល់បញ្ជីឯកសារយោង។ អ្នកដែលចូលចិត្តយល់ក្នុងការអនុវត្តត្រូវបានស្វាគមន៍ Slurme SRE.

ប្រភព: www.habr.com