របៀបដែលខ្ញុំបានចំណាយពេលមួយសប្តាហ៍ជាអ្នកហាត់ការវិស្វករ SRE ។ កាតព្វកិច្ចតាមរយៈភ្នែករបស់វិស្វករកម្មវិធី

វិស្វករ SRE - សិក្ខាកាម

ដំបូងខ្ញុំសូមណែនាំខ្លួនខ្ញុំ។ ខ្ញុំ - @tristan.អាន, វិស្វករជួរមុខនៅក្នុងក្រុម តាមដាន៖: សុខភាព GitLab ។ កាល​ពី​សប្តាហ៍​មុន ខ្ញុំ​មាន​កិត្តិយស​ក្នុង​ការ​ធ្វើ​កម្មសិក្សា​ជាមួយ​វិស្វករ SRE ម្នាក់​ដែល​យើង​ហៅ​មក។ គោលដៅគឺដើម្បីសង្កេតមើលពីរបៀបដែលមន្ត្រីជាប់កាតព្វកិច្ចឆ្លើយតបចំពោះឧប្បត្តិហេតុប្រចាំថ្ងៃ និងទទួលបានបទពិសោធន៍ជីវិតពិតលើការងារ។ យើងចង់ឱ្យវិស្វកររបស់យើងយល់កាន់តែច្បាស់អំពីតម្រូវការរបស់អ្នកប្រើប្រាស់ មុខងារ។ តាមដាន៖: សុខភាព។

ខ្ញុំត្រូវដើរតាមវិស្វករ SRE គ្រប់ទីកន្លែងរយៈពេលមួយសប្តាហ៍។ នោះគឺខ្ញុំមានវត្តមាននៅឯការប្រគល់នេះ ត្រួតពិនិត្យបណ្តាញជូនដំណឹងដូចគ្នា និងបានឆ្លើយតបទៅនឹងឧប្បត្តិហេតុប្រសិនបើ និងនៅពេលដែលវាកើតឡើង។

ឧប្បត្តិហេតុ

មានឧបទ្ទវហេតុចំនួន 2 ក្នុងមួយសប្តាហ៍។

1. Cryptominer

GitLab.com បានឃើញការកើនឡើងនៃការប្រើប្រាស់កាលពីថ្ងៃពុធ អ្នករត់ GitLab'a បណ្តាលមកពីការព្យាយាមប្រើនាទីរបស់អ្នករត់ដើម្បីជីកយករូបិយប័ណ្ណគ្រីបតូ។ ឧប្បត្តិហេតុនេះត្រូវបានដោះស្រាយដោយប្រើឧបករណ៍អព្យាក្រឹតការបំពានផ្ទាល់ខ្លួនរបស់យើង ដែលបញ្ឈប់កិច្ចការរបស់អ្នករត់ការ និងលុបគម្រោង និងគណនីដែលពាក់ព័ន្ធជាមួយវា។

ប្រសិនបើព្រឹត្តិការណ៍នេះមិនត្រូវបានគេកត់សំគាល់ទេ ឧបករណ៍ស្វ័យប្រវត្តិនឹងចាប់វាបាន ប៉ុន្តែក្នុងករណីនេះ វិស្វករ SRE បានកត់សម្គាល់ការបំពានជាមុនសិន។ កិច្ចការឧប្បត្តិហេតុមួយត្រូវបានបង្កើតឡើង ប៉ុន្តែព័ត៌មាននៅលើវាត្រូវបានបិទ។

2. ការថយចុះការអនុវត្តនៃកម្មវិធី Canary និង Main

ឧប្បត្តិហេតុនេះត្រូវបានបង្កឡើងដោយការយឺតយ៉ាវ និងការកើនឡើងនៃភាពញឹកញាប់នៃកំហុសនៅក្នុងកម្មវិធី Canary និងគេហទំព័រសំខាន់ៗនៅលើ Gitlab.com ។ តម្លៃ Apdex ជាច្រើនត្រូវបានបំពាន។

បើកភារកិច្ច៖ https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

ការរកឃើញសំខាន់ៗ

នេះគឺជារឿងមួយចំនួនដែលខ្ញុំបានរៀនក្នុងអំឡុងពេលសប្តាហ៍របស់ខ្ញុំនៅលើកាតព្វកិច្ច។

1. ការជូនដំណឹងមានប្រយោជន៍បំផុតនៅពេលរកឃើញគម្លាតពីបទដ្ឋាន។

ការដាស់តឿនអាចត្រូវបានបែងចែកជាប្រភេទជាច្រើន៖

• ការជូនដំណឹងផ្អែកលើតម្លៃកម្រិតជាក់លាក់មួយ ដូចជា "កំហុស 10 5xx បានកើតឡើងក្នុងមួយវិនាទី។"
• ការជូនដំណឹងដែលកម្រិតគឺជាតម្លៃភាគរយដូចជា "ប្រេកង់នៃកំហុស 5xx ក្នុង 10% នៃបរិមាណសរុបនៃសំណើនៅពេលណាមួយ" ។
• ការដាស់តឿនផ្អែកលើមធ្យមភាគប្រវត្តិសាស្រ្តដូចជា "កំហុស 5xx នៅ 90 ភាគរយ" ។

និយាយជាទូទៅ ប្រភេទទី 2 និងទី 3 មានប្រយោជន៍ជាងសម្រាប់ SREs ដែលបំពេញកាតព្វកិច្ច ដោយសារពួកគេបង្ហាញពីគម្លាតពីបទដ្ឋាននៅក្នុងដំណើរការ។

2. ការដាស់តឿនជាច្រើនមិនដែលកើនឡើងដល់ឧប្បត្តិហេតុទេ។

វិស្វករ SR ដោះស្រាយជាមួយនឹងការដាស់តឿនឥតឈប់ឈរ ដែលភាគច្រើនមិនសំខាន់ទេ។

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

ការងាររបស់ SRE ដែលកំពុងហៅគឺដើម្បីកំណត់ថាការដាស់តឿនណាមួយដែលពិតជាបង្ហាញពីអ្វីដែលធ្ងន់ធ្ងរ និងថាតើពួកគេត្រូវបង្កើន និងដោះស្រាយដែរឬទេ។ ខ្ញុំសង្ស័យថានេះក៏ដោយសារតែភាពមិនបត់បែននៃការជូនដំណឹង៖ វានឹងប្រសើរជាងប្រសិនបើមានកម្រិតជាច្រើន ឬវិធី "ឆ្លាតវៃ" ដើម្បីកំណត់រចនាសម្ព័ន្ធការជូនដំណឹងស្របតាមស្ថានភាពដែលបានពិពណ៌នាខាងលើ។

ការណែនាំអំពីមុខងារ៖ https://gitlab.com/gitlab-org/gitlab/issues/42633

3. SREs របស់យើងនៅលើកាតព្វកិច្ចប្រើប្រាស់ឧបករណ៍ជាច្រើន។

ខាងក្នុង:

• គម្រោងអ៊ីនហ្វ្រា GitLab៖ សៀវភៅរត់នៅទីនេះ ការងារផ្លាស់ប្តូរ/សប្តាហ៍ ភារកិច្ចឆ្លើយតបឧប្បត្តិហេតុ។
• បញ្ហា GitLab៖ ការស៊ើបអង្កេត ការពិនិត្យឡើងវិញ និងការថែទាំក៏ត្រូវបានតាមដានផងដែរនៅក្នុងបញ្ហា។
• ស្លាក GitLab៖ កិច្ចការស្វ័យប្រវត្តិកម្មត្រូវបានចាប់ផ្តើមដោយប្រើស្លាកជាក់លាក់ ដែល bots ប្រើដើម្បីតាមដានសកម្មភាពការងារ។

ខាងក្រៅ៖

• PagerDuty៖ ការជូនដំណឹង
• Slack៖ លំហូរសារ PagerDuty/AlertManager ទៅទីនេះ។ ការរួមបញ្ចូលជាមួយពាក្យបញ្ជា slash ដើម្បីអនុវត្តការងារជាច្រើនដូចជា បិទការជូនដំណឹង ឬការកើនឡើងដល់ឧប្បត្តិហេតុមួយ។
• Grafana៖ ការមើលឃើញនៃម៉ែត្រដោយផ្តោតលើនិន្នាការរយៈពេលវែង។
• Kibana៖ ផ្តល់នូវការស្វែងរករូបភាព/កំណត់ហេតុ សមត្ថភាពក្នុងការជីកជ្រៅទៅក្នុងព្រឹត្តិការណ៍ជាក់លាក់។
• ពង្រីក៖ មាន "បន្ទប់បំបែក" ដែលកំពុងដំណើរការឥតឈប់ឈរនៅក្នុង Zoom ។ នេះអនុញ្ញាតឱ្យវិស្វករ SRE ពិភាក្សាយ៉ាងឆាប់រហ័សអំពីព្រឹត្តិការណ៍ដោយមិនខ្ជះខ្ជាយពេលវេលាដ៏មានតម្លៃក្នុងការបង្កើតបន្ទប់ និងភ្ជាប់អ្នកចូលរួម។

និងអ្នកផ្សេងទៀតជាច្រើន។

4. ការត្រួតពិនិត្យ GitLab.com ជាមួយ GitLab គឺជាចំណុចតែមួយនៃការបរាជ័យ

ប្រសិនបើ GitLab.com ជួបប្រទះការដាច់សេវាកម្មធំ យើងមិនចង់ឱ្យវាប៉ះពាល់ដល់សមត្ថភាពរបស់យើងក្នុងការដោះស្រាយបញ្ហានោះទេ។ វាអាចត្រូវបានបញ្ឈប់ដោយការបើកដំណើរការឧទាហរណ៍ GitLab ទីពីរដើម្បីគ្រប់គ្រង GitLab.com ។ តាមពិត នេះដំណើរការសម្រាប់យើងរួចហើយ៖ https://ops.gitlab.net/.

5. លក្ខណៈពិសេសមួយចំនួនដើម្បីពិចារណាបន្ថែមទៅ GitLab

• ការកែសម្រួលភារកិច្ចអ្នកប្រើប្រាស់ច្រើន។ស្រដៀងទៅនឹង Google Docs។ វានឹងជួយដល់ការងារលើឧប្បត្តិហេតុក្នុងអំឡុងពេលព្រឹត្តិការណ៍មួយ ក៏ដូចជាការងារលើការពន្យល់។ ក្នុងករណីទាំងពីរ អ្នកចូលរួមជាច្រើនប្រហែលជាត្រូវបន្ថែមអ្វីមួយនៅក្នុងពេលវេលាជាក់ស្តែង។
• webhooks ច្រើនទៀតសម្រាប់កិច្ចការ។ សមត្ថភាពក្នុងការដំណើរការជំហានការងារ GitLab ផ្សេងៗគ្នាពីខាងក្នុងនឹងជួយកាត់បន្ថយការពឹងផ្អែករបស់អ្នកលើការរួមបញ្ចូល Slack ។ ឧទាហរណ៍ សមត្ថភាពក្នុងការអនុញ្ញាតឱ្យមានការជូនដំណឹងនៅក្នុង PagerDuty តាមរយៈពាក្យបញ្ជា slash នៅក្នុងបញ្ហា GitLab ។
  សេចក្តីសន្និដ្ឋាន

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

យើងកំពុងពង្រីកក្រុមនៅឆ្នាំ 2020 ដើម្បីនាំយកមុខងារដ៏អស្ចារ្យទាំងអស់នេះមកជាមួយគ្នា។ បើចាប់អារម្មណ៍សូមពិនិត្យមើល កន្លែងទំនេរហើយមានអារម្មណ៍សេរីក្នុងការទាក់ទងនរណាម្នាក់នៅក្នុងក្រុមរបស់យើងជាមួយនឹងសំណួរណាមួយ។

ប្រភព: www.habr.com