តើការត្រួតពិនិត្យស្លាប់ទេ? - ការត្រួតពិនិត្យការរស់នៅយូរ

ចាប់តាំងពីឆ្នាំ 2008 ក្រុមហ៊ុនរបស់យើងបានចូលរួមជាចម្បងក្នុងការគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធ និងជំនួយបច្ចេកទេសពេញម៉ោងសម្រាប់គម្រោងបណ្តាញ៖ យើងមានអតិថិជនជាង 400 នាក់ ដែលស្មើនឹង 15% នៃពាណិជ្ជកម្មអេឡិចត្រូនិករបស់រុស្ស៊ី។ ដូច្នោះហើយស្ថាបត្យកម្មចម្រុះត្រូវបានគាំទ្រ។ ប្រសិនបើមានអ្វីមួយធ្លាក់ យើងមានកាតព្វកិច្ចជួសជុលវាក្នុងរយៈពេល 15 នាទី។ ប៉ុន្តែដើម្បីយល់ថាគ្រោះថ្នាក់បានកើតឡើង អ្នកត្រូវតាមដានគម្រោង និងឆ្លើយតបទៅនឹងឧប្បត្តិហេតុនានា។ តើត្រូវធ្វើដូចម្តេច?

ខ្ញុំជឿថាមានបញ្ហាក្នុងការរៀបចំប្រព័ន្ធត្រួតពិនិត្យត្រឹមត្រូវ។ ប្រសិនបើគ្មានបញ្ហាទេនោះ សុន្ទរកថារបស់ខ្ញុំនឹងមាននិក្ខេបបទមួយ៖ "សូមដំឡើង Prometheus + Grafana និងកម្មវិធីជំនួយ 1, 2, 3 ។" ជាអកុសល វាមិនដំណើរការបែបនោះទៀតទេ។ ហើយបញ្ហាចម្បងនោះគឺថាមនុស្សគ្រប់គ្នាបន្តជឿលើអ្វីមួយដែលមាននៅក្នុងឆ្នាំ 2008 ទាក់ទងនឹងសមាសធាតុកម្មវិធី។

ទាក់ទងនឹងការរៀបចំប្រព័ន្ធត្រួតពិនិត្យ ខ្ញុំចង់និយាយថា... គម្រោងដែលមានការត្រួតពិនិត្យមានសមត្ថកិច្ចមិនមានទេ។ ហើយស្ថានភាពគឺអាក្រក់ខ្លាំងណាស់ដែលប្រសិនបើមានអ្វីមួយធ្លាក់វាមានហានិភ័យដែលវានឹងមិនមាននរណាកត់សម្គាល់ - បន្ទាប់ពីទាំងអស់អ្នកគ្រប់គ្នាប្រាកដថា "អ្វីគ្រប់យ៉ាងត្រូវបានត្រួតពិនិត្យ" ។
ប្រហែលជាអ្វីៗត្រូវបានត្រួតពិនិត្យ។ ប៉ុន្តែ​ធ្វើ​យ៉ាងម៉េច?

យើងទាំងអស់គ្នាបានជួបប្រទះរឿងដូចតទៅ៖ អ្នកអភិវឌ្ឍន៍ជាក់លាក់មួយ អ្នកគ្រប់គ្រងជាក់លាក់មួយកំពុងធ្វើការ ក្រុមអភិវឌ្ឍន៍បានមករកពួកគេ ហើយនិយាយថា "យើងត្រូវបានដោះលែងហើយ ឥឡូវនេះតាមដាន" ។ តាមដានអ្វី? តើវាដំណើរការយ៉ាងដូចម្តេច?

យល់ព្រម។ យើងតាមដានវិធីចាស់។ ហើយវាកំពុងផ្លាស់ប្តូររួចហើយ ហើយវាប្រែថាអ្នកបានត្រួតពិនិត្យសេវាកម្ម A ដែលបានក្លាយជាសេវាកម្ម B ដែលមានអន្តរកម្មជាមួយសេវាកម្ម C។ ប៉ុន្តែក្រុមអភិវឌ្ឍន៍ប្រាប់អ្នកថា "ដំឡើងកម្មវិធី វាគួរតែត្រួតពិនិត្យអ្វីៗគ្រប់យ៉ាង!"

ដូច្នេះតើមានអ្វីផ្លាស់ប្តូរ? - អ្វី​គ្រប់យ៉ាង​បាន​ផ្លាស់​ប្ដូរ!

ឆ្នាំ ២០០៨ អ្វីគ្រប់យ៉ាងគឺល្អ។

មាន​អ្នក​អភិវឌ្ឍន៍​ពីរ​នាក់ ម៉ាស៊ីន​បម្រើ​មួយ ម៉ាស៊ីន​បម្រើ​មូលដ្ឋាន​ទិន្នន័យ​មួយ។ វាទាំងអស់ចេញពីទីនេះ។ យើងមានព័ត៌មានខ្លះ យើងដំឡើង zabbix, Nagios, cacti ។ ហើយ​បន្ទាប់​មក​យើង​កំណត់​ការ​ជូន​ដំណឹង​ច្បាស់​លាស់​នៅ​លើ CPU លើ​ប្រតិបត្តិការ​ថាស និង​ទំហំ​ថាស។ យើងក៏ធ្វើការត្រួតពិនិត្យដោយដៃពីរបីផងដែរ ដើម្បីធានាថាគេហទំព័រឆ្លើយតប ហើយការបញ្ជាទិញនោះកំពុងមកដល់ក្នុងមូលដ្ឋានទិន្នន័យ។ ហើយនោះហើយជាវា - យើងត្រូវបានការពារច្រើនឬតិច។

ប្រសិនបើយើងប្រៀបធៀបចំនួនការងារដែលអ្នកគ្រប់គ្រងបានធ្វើនៅពេលនោះដើម្បីផ្តល់ការត្រួតពិនិត្យ នោះ 98% នៃវាគឺដោយស្វ័យប្រវត្តិ៖ អ្នកដែលធ្វើការត្រួតពិនិត្យត្រូវតែយល់ពីរបៀបដំឡើង Zabbix របៀបកំណត់វា និងកំណត់រចនាសម្ព័ន្ធការជូនដំណឹង។ និង 2% - សម្រាប់ការត្រួតពិនិត្យខាងក្រៅ៖ ដែលគេហទំព័រឆ្លើយតប និងធ្វើការស្នើសុំទៅកាន់មូលដ្ឋានទិន្នន័យ ការបញ្ជាទិញថ្មីបានមកដល់ហើយ។

ឆ្នាំ ២០១០ បន្ទុកកំពុងកើនឡើង

យើងកំពុងចាប់ផ្តើមធ្វើមាត្រដ្ឋានគេហទំព័រ ដោយបន្ថែមម៉ាស៊ីនស្វែងរក។ យើងចង់ធ្វើឱ្យប្រាកដថាកាតាឡុកផលិតផលមានផលិតផលទាំងអស់។ ហើយការស្វែងរកផលិតផលនោះដំណើរការ។ ថាមូលដ្ឋានទិន្នន័យកំពុងដំណើរការ ការបញ្ជាទិញនោះកំពុងត្រូវបានបង្កើតឡើង ដែលគេហទំព័រឆ្លើយតបខាងក្រៅ និងឆ្លើយតបពីម៉ាស៊ីនមេពីរ ហើយអ្នកប្រើប្រាស់មិនត្រូវបានបណ្តេញចេញពីគេហទំព័រនោះទេ ខណៈពេលដែលវាត្រូវបានធ្វើសមតុល្យទៅម៉ាស៊ីនមេផ្សេងទៀត ។ល។ មានអង្គភាពជាច្រើនទៀត។

ជាងនេះទៅទៀត អង្គភាពដែលពាក់ព័ន្ធនឹងហេដ្ឋារចនាសម្ព័ន្ធនៅតែធំជាងគេនៅក្នុងប្រធានអ្នកគ្រប់គ្រង។ វានៅតែមានគំនិតមួយនៅក្នុងក្បាលរបស់ខ្ញុំថាអ្នកដែលធ្វើការត្រួតពិនិត្យគឺជាអ្នកដែលនឹងដំឡើង zabbix ហើយអាចកំណត់រចនាសម្ព័ន្ធវាបាន។

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

ចំណាំ៖ ខ្ញុំបានសរសេរ "សំណុំនៃស្គ្រីប" 3 ដង។ នោះគឺអ្នកដែលទទួលខុសត្រូវលើការត្រួតពិនិត្យមិនមែនជាអ្នកដែលគ្រាន់តែដំឡើង zabbix ទៀតទេ។ នេះគឺជាមនុស្សម្នាក់ដែលចាប់ផ្តើមសរសេរកូដ។ ប៉ុន្តែ​មិន​មាន​អ្វី​ផ្លាស់​ប្តូរ​ក្នុង​ចិត្ត​ក្រុម​នៅ​ឡើយ​ទេ។

ប៉ុន្តែពិភពលោកកំពុងផ្លាស់ប្តូរ កាន់តែស្មុគស្មាញ។ ស្រទាប់និម្មិត និងប្រព័ន្ធថ្មីជាច្រើនត្រូវបានបន្ថែម។ ពួកគេចាប់ផ្តើមទាក់ទងគ្នាទៅវិញទៅមក។ តើអ្នកណានិយាយថា "ក្លិនដូចមីក្រូសេវាកម្ម?" ប៉ុន្តែសេវាកម្មនីមួយៗនៅតែមើលទៅដូចជាគេហទំព័រផ្ទាល់ខ្លួន។ យើងអាចងាកទៅរកវា ហើយយល់ថាវាផ្តល់ព័ត៌មានចាំបាច់ និងដំណើរការដោយខ្លួនឯង។ ហើយប្រសិនបើអ្នកជាអ្នកគ្រប់គ្រងជាប់ពាក់ព័ន្ធជានិច្ចនៅក្នុងគម្រោងដែលបាននិងកំពុងអភិវឌ្ឍអស់រយៈពេល 5-7-10 ឆ្នាំ ចំណេះដឹងនេះប្រមូលផ្តុំ: កម្រិតថ្មីមួយបានលេចឡើង - អ្នកបានដឹងពីវា កម្រិតមួយផ្សេងទៀតនឹងលេចឡើង - អ្នកបានដឹងវា ...

ប៉ុន្តែកម្រមាននរណាម្នាក់រួមដំណើរជាមួយគម្រោងរយៈពេល 10 ឆ្នាំ។

ប្រវត្តិរូបសង្ខេបរបស់អ្នកត្រួតពិនិត្យ

ឧបមាថាអ្នកបានមកដល់ការចាប់ផ្ដើមថ្មីមួយដែលភ្លាមៗបានជួលអ្នកអភិវឌ្ឍន៍ចំនួន 20 នាក់ សរសេរសេវាកម្មមីក្រូចំនួន 15 ហើយអ្នកគឺជាអ្នកគ្រប់គ្រងដែលត្រូវបានប្រាប់ថា៖ "បង្កើត CI/CD ។ សូម។" អ្នកបានបង្កើត CI/CD ហើយភ្លាមៗនោះអ្នកលឺថា "វាពិបាកសម្រាប់ពួកយើងក្នុងការធ្វើការជាមួយផលិតកម្មនៅក្នុង "cube" ដោយមិនយល់ពីរបៀបដែលកម្មវិធីនឹងដំណើរការនៅក្នុងវា។ ធ្វើឱ្យយើងប្រអប់ខ្សាច់នៅក្នុង "គូប" ដូចគ្នា។
អ្នកបង្កើតប្រអប់ខ្សាច់នៅក្នុងគូបនេះ។ ពួកគេប្រាប់អ្នកភ្លាមៗថា "យើងចង់បានមូលដ្ឋានទិន្នន័យដំណាក់កាលដែលត្រូវបានធ្វើបច្ចុប្បន្នភាពជារៀងរាល់ថ្ងៃពីផលិតកម្ម ដូច្នេះយើងយល់ថាវាដំណើរការលើមូលដ្ឋានទិន្នន័យ ប៉ុន្តែក្នុងពេលតែមួយមិនធ្វើឱ្យខូចមូលដ្ឋានទិន្នន័យផលិតកម្មនោះទេ។"

អ្នករស់នៅក្នុងទាំងអស់នេះ។ នៅសល់ 2 សប្តាហ៍ទៀតមុនការចេញផ្សាយ ពួកគេប្រាប់អ្នកថា "ឥឡូវនេះ តោះតាមដានទាំងអស់គ្នា..." នោះគឺ។ ត្រួតពិនិត្យហេដ្ឋារចនាសម្ព័ន្ធចង្កោម ត្រួតពិនិត្យស្ថាបត្យកម្មមីក្រូសេវា ត្រួតពិនិត្យការងារជាមួយសេវាកម្មខាងក្រៅ...

ហើយសហសេវិករបស់ខ្ញុំបានយកគ្រោងការណ៍ធម្មតាចេញពីក្បាលរបស់ពួកគេហើយនិយាយថា: "មែនហើយអ្វីៗគឺច្បាស់នៅទីនេះ! ដំឡើងកម្មវិធីដែលនឹងត្រួតពិនិត្យទាំងអស់នេះ។" បាទ/ចាស៎៖ Prometheus + Grafana + កម្មវិធីជំនួយ។
ហើយពួកគេបន្ថែមថា "អ្នកមានពេលពីរសប្តាហ៍ សូមប្រាកដថាអ្វីៗទាំងអស់មានសុវត្ថិភាព"។

នៅក្នុងគម្រោងជាច្រើនដែលយើងឃើញ មនុស្សម្នាក់ត្រូវបានបែងចែកសម្រាប់ការត្រួតពិនិត្យ។ ស្រមៃថាយើងចង់ជួលមនុស្សម្នាក់ឱ្យធ្វើការត្រួតពិនិត្យរយៈពេល 2 សប្តាហ៍ហើយយើងសរសេរប្រវត្តិរូបឱ្យគាត់។ តើ​បុគ្គល​នេះ​គួរ​មាន​ជំនាញ​អ្វី​ខ្លះ ដែល​បាន​ផ្តល់​នូវ​អ្វី​គ្រប់​យ៉ាង​ដែល​យើង​បាន​និយាយ​មក​ទល់​ពេល​នេះ?

• គាត់ត្រូវតែយល់ពីការត្រួតពិនិត្យនិងជាក់លាក់នៃប្រតិបត្តិការនៃហេដ្ឋារចនាសម្ព័ន្ធដែក។
• គាត់ត្រូវតែយល់ពីភាពជាក់លាក់នៃការត្រួតពិនិត្យ Kubernetes (ហើយអ្នកគ្រប់គ្នាចង់ទៅ "គូប" ព្រោះអ្នកអាចអរូបីពីអ្វីៗគ្រប់យ៉ាង លាក់ខ្លួន ព្រោះអ្នកគ្រប់គ្រងនឹងដោះស្រាយជាមួយអ្វីដែលនៅសល់) - ខ្លួនវា ហេដ្ឋារចនាសម្ព័ន្ធរបស់វា និងយល់ពីរបៀបត្រួតពិនិត្យកម្មវិធី ខាងក្នុង។
• គាត់ត្រូវតែយល់ថាសេវាកម្មទាក់ទងគ្នាទៅវិញទៅមកតាមរបៀបពិសេស និងដឹងពីភាពជាក់លាក់នៃរបៀបដែលសេវាកម្មទាក់ទងគ្នាទៅវិញទៅមក។ វាពិតជាអាចទៅរួចក្នុងការមើលឃើញគម្រោងដែលសេវាកម្មមួយចំនួនទាក់ទងគ្នាក្នុងពេលដំណាលគ្នា ពីព្រោះមិនមានវិធីផ្សេងទៀតទេ។ ឧទាហរណ៍ កម្មវិធីខាងក្រោយឆ្លងកាត់ REST តាមរយៈ gRPC ទៅកាន់សេវាកម្មកាតាឡុក ទទួលបញ្ជីផលិតផល និងប្រគល់វាមកវិញ។ អ្នកមិនអាចរង់ចាំនៅទីនេះបានទេ។ ហើយជាមួយនឹងសេវាកម្មផ្សេងទៀត វាដំណើរការដោយអសមកាល។ ផ្ទេរការបញ្ជាទិញទៅសេវាកម្មដឹកជញ្ជូន ផ្ញើសំបុត្រ។ល។
  អ្នកប្រហែលជាបានហែលពីអ្វីៗទាំងអស់នេះហើយ? ហើយ Admin ដែលត្រូវតាមដានរឿងនេះ កាន់តែយល់ច្រលំ។
• គាត់ត្រូវតែអាចរៀបចំផែនការ និងរៀបចំផែនការបានត្រឹមត្រូវ - ដោយសារការងារកាន់តែមានកាន់តែច្រើន។
• ដូច្នេះគាត់ត្រូវតែបង្កើតយុទ្ធសាស្ត្រពីសេវាកម្មដែលបានបង្កើត ដើម្បីយល់ពីរបៀបត្រួតពិនិត្យជាពិសេស។ គាត់ត្រូវការការយល់ដឹងអំពីស្ថាបត្យកម្មរបស់គម្រោង និងការអភិវឌ្ឍន៍របស់វា + ការយល់ដឹងអំពីបច្ចេកវិទ្យាដែលប្រើក្នុងការអភិវឌ្ឍន៍។

ចូរយើងចងចាំនូវករណីធម្មតាមួយ៖ សេវាកម្មខ្លះស្ថិតនៅក្នុង PHP សេវាកម្មខ្លះស្ថិតនៅក្នុង Go សេវាកម្មខ្លះស្ថិតនៅក្នុង JS ។ ពួកគេធ្វើការជាមួយគ្នាដូចម្ដេច។ នេះគឺជាកន្លែងដែលពាក្យ "សេវាមីក្រូ" មកពី៖ មានប្រព័ន្ធបុគ្គលជាច្រើនដែលអ្នកអភិវឌ្ឍន៍មិនអាចយល់ពីគម្រោងទាំងមូល។ ផ្នែកមួយនៃក្រុមសរសេរសេវាកម្មនៅក្នុង JS ដែលដំណើរការដោយខ្លួនឯង ហើយមិនដឹងថាប្រព័ន្ធដែលនៅសល់ដំណើរការយ៉ាងដូចម្តេចនោះទេ។ ផ្នែកផ្សេងទៀតសរសេរសេវាកម្មនៅក្នុង Python និងមិនជ្រៀតជ្រែកជាមួយនឹងរបៀបដែលសេវាកម្មផ្សេងទៀតដំណើរការ ពួកគេត្រូវបានដាច់ដោយឡែកនៅក្នុងតំបន់របស់ពួកគេ។ ទីបីគឺការសរសេរសេវាកម្មនៅក្នុង PHP ឬអ្វីផ្សេងទៀត។
មនុស្ស​ទាំង​២០​នាក់​នេះ​ចែក​ចេញ​ជា​១៥​សេវា ហើយ​មាន​តែ​admin​ម្នាក់​គត់​ដែល​ត្រូវ​យល់​ពី​រឿង​ទាំង​អស់​នេះ។ ឈប់! យើងគ្រាន់តែបំបែកប្រព័ន្ធនេះទៅជា 20 microservices ព្រោះមនុស្ស 15 នាក់មិនអាចយល់ពីប្រព័ន្ធទាំងមូលបានទេ។

ប៉ុន្តែ​វា​ត្រូវ​តែ​ត្រួត​ពិនិត្យ​ដោយ​របៀប​ណា...

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

តើខ្ញុំអាចនិយាយអ្វីបាន... ហ៊ូស្តុន យើងមានបញ្ហា។

ការត្រួតពិនិត្យគម្រោងកម្មវិធីទំនើបគឺជាគម្រោងកម្មវិធីនៅក្នុងខ្លួនវាផ្ទាល់

ពីជំនឿមិនពិតដែលថាការត្រួតពិនិត្យគឺជាកម្មវិធី យើងបង្កើតជំនឿលើអព្ភូតហេតុ។ ប៉ុន្តែអព្ភូតហេតុ, alas, មិនកើតឡើង។ អ្នកមិនអាចដំឡើង zabbix ហើយរំពឹងថាអ្វីៗនឹងដំណើរការបានទេ។ វាគ្មានន័យទេក្នុងការដំឡើង Grafana ហើយសង្ឃឹមថាអ្វីៗនឹងល្អ ពេលវេលាភាគច្រើននឹងត្រូវចំណាយលើការរៀបចំការត្រួតពិនិត្យប្រតិបត្តិការនៃសេវាកម្ម និងអន្តរកម្មរបស់ពួកគេជាមួយគ្នាទៅវិញទៅមក ពិនិត្យមើលថាតើប្រព័ន្ធខាងក្រៅដំណើរការយ៉ាងដូចម្តេច។ ជាការពិត 90% នៃពេលវេលានឹងត្រូវចំណាយមិនមែនលើការសរសេរស្គ្រីបទេ ប៉ុន្តែសម្រាប់ការអភិវឌ្ឍន៍កម្មវិធី។ ហើយវាគួរតែត្រូវបានដោះស្រាយដោយក្រុមដែលយល់ពីការងាររបស់គម្រោង។
ប្រសិនបើ​ក្នុង​ស្ថានភាព​នេះ​មាន​មនុស្ស​ម្នាក់​ត្រូវ​បាន​គេ​ទម្លាក់​ចូល​ក្នុង​ការ​ត្រួត​ពិនិត្យ នោះ​គ្រោះ​មហន្តរាយ​នឹង​កើត​ឡើង។ ដែលជាអ្វីដែលកើតឡើងនៅគ្រប់ទីកន្លែង។

ជាឧទាហរណ៍ មានសេវាកម្មជាច្រើនដែលទាក់ទងគ្នាទៅវិញទៅមកតាមរយៈ Kafka ។ ការបញ្ជាទិញបានមកដល់ យើងបានផ្ញើសារអំពីការបញ្ជាទិញទៅ Kafka ។ មានសេវាស្តាប់ព័ត៌មានអំពីការបញ្ជាទិញ និងដឹកជញ្ជូនទំនិញ។ មានសេវាកម្មដែលស្តាប់ព័ត៌មានអំពីការបញ្ជាទិញ និងផ្ញើលិខិតទៅកាន់អ្នកប្រើប្រាស់។ ហើយ​បន្ទាប់​មក​សេវា​ច្រើន​ទៀត​លេច​ឡើង ហើយ​យើង​ចាប់​ផ្តើម​យល់​ច្រឡំ។

ហើយប្រសិនបើអ្នកក៏ផ្តល់ឱ្យវាទៅអ្នកគ្រប់គ្រង និងអ្នកអភិវឌ្ឍន៍នៅដំណាក់កាលនៅពេលដែលនៅសល់ពេលខ្លីមុនពេលការចេញផ្សាយ បុគ្គលនោះនឹងត្រូវយល់អំពីពិធីការទាំងមូលនេះ។ ទាំងនោះ។ គម្រោងនៃមាត្រដ្ឋាននេះត្រូវការពេលវេលាច្រើន ហើយនេះគួរតែត្រូវបានគេយកទៅក្នុងការអភិវឌ្ឍន៍ប្រព័ន្ធ។
ប៉ុន្តែជាញឹកញាប់ ជាពិសេសនៅក្នុងការចាប់ផ្តើមអាជីវកម្ម យើងឃើញពីរបៀបដែលការត្រួតពិនិត្យត្រូវបានពន្យារពេលរហូតដល់ពេលក្រោយ។ “ឥឡូវនេះ យើងនឹងបង្កើតភស្តុតាងនៃគោលគំនិត យើងនឹងចាប់ផ្តើមជាមួយវា ទុកឱ្យវាដួលរលំ - យើងត្រៀមខ្លួនរួចជាស្រេចដើម្បីលះបង់។ ហើយ​បន្ទាប់​មក​យើង​នឹង​ត្រួត​ពិនិត្យ​វា​ទាំង​អស់»។ នៅពេលដែល (ឬប្រសិនបើ) គម្រោងចាប់ផ្តើមរកលុយ អាជីវកម្មចង់បន្ថែមលក្ខណៈពិសេសបន្ថែមទៀត - ដោយសារតែវាបានចាប់ផ្តើមដំណើរការ ដូច្នេះវាចាំបាច់ត្រូវដាក់ឱ្យដំណើរការបន្ថែមទៀត! ហើយ​អ្នក​គឺ​នៅ​ចំណុច​ដែល​ដំបូង​អ្នក​ត្រូវ​ត្រួត​ពិនិត្យ​អ្វី​គ្រប់​យ៉ាង​មុន​ដែល​មិន​ចំណាយ​ពេល 1% នៃ​ពេល​វេលា, ប៉ុន្តែ​ជា​ច្រើន​ទៀត. ហើយដោយវិធីនេះ អ្នកអភិវឌ្ឍន៍នឹងត្រូវការចាំបាច់សម្រាប់ការត្រួតពិនិត្យ ហើយវាកាន់តែងាយស្រួលក្នុងការអនុញ្ញាតឱ្យពួកគេធ្វើការលើមុខងារថ្មីៗ។ ជាលទ្ធផល មុខងារថ្មីៗត្រូវបានសរសេរ អ្វីគ្រប់យ៉ាងត្រូវបានបិទ ហើយអ្នកស្ថិតនៅក្នុងភាពជាប់គាំងគ្មានទីបញ្ចប់។

ដូច្នេះតើធ្វើដូចម្តេចដើម្បីត្រួតពិនិត្យគម្រោងដែលចាប់ផ្តើមពីដំបូង ហើយអ្វីដែលត្រូវធ្វើប្រសិនបើអ្នកទទួលបានគម្រោងដែលត្រូវត្រួតពិនិត្យ ប៉ុន្តែអ្នកមិនដឹងថាត្រូវចាប់ផ្តើមពីណា?

ដំបូងអ្នកត្រូវរៀបចំផែនការ។

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

ជាដំបូង សម្រេចចិត្តថាតើអ្នកចង់ត្រួតពិនិត្យអ្វី និងរបៀបណា ហើយបន្ទាប់មកជ្រើសរើសឧបករណ៍ ពីព្រោះអ្នកផ្សេងទៀតមិនអាចគិតសម្រាប់អ្នកបានទេ។ ហើយតើពួកគេគួរ? មនុស្សផ្សេងទៀតបានគិតពីខ្លួនឯងអំពីប្រព័ន្ធសកល - ឬមិនបានគិតទាល់តែសោះនៅពេលដែលកម្មវិធីជំនួយនេះត្រូវបានសរសេរ។ ហើយ​ដោយសារ​តែ​កម្មវិធី​ជំនួយ​នេះ​មាន​អ្នក​ប្រើ​ចំនួន 5 ពាន់​នាក់ មិន​មាន​ន័យ​ថា​វា​មាន​ប្រយោជន៍​អ្វី​ឡើយ។ ប្រហែលជាអ្នកនឹងក្លាយជា 5001st ដោយគ្រាន់តែមានមនុស្ស 5000 នាក់នៅទីនោះរួចហើយ។

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

1. ខ្ញុំជឿថាអ្នកត្រូវចាប់ផ្តើមត្រួតពិនិត្យយ៉ាងពិតប្រាកដពីចំណុចចូលរបស់អ្នកប្រើប្រាស់។ ប្រសិនបើអ្នកប្រើមិនឃើញថាកម្មវិធីកំពុងដំណើរការទេ នោះហើយជាវា វាជាការបរាជ័យ។ ហើយប្រព័ន្ធត្រួតពិនិត្យគួរតែព្រមានអំពីរឿងនេះជាមុនសិន។
2. ហើយមានតែពេលនោះទេដែលយើងអាចត្រួតពិនិត្យហេដ្ឋារចនាសម្ព័ន្ធ។ ឬធ្វើវាស្របគ្នា។ វាកាន់តែងាយស្រួលជាមួយនឹងហេដ្ឋារចនាសម្ព័ន្ធ - ទីបំផុតយើងអាចដំឡើង zabbix នៅទីនេះ។
3. ហើយឥឡូវនេះអ្នកត្រូវចូលទៅកាន់ឫសនៃកម្មវិធីដើម្បីយល់ពីកន្លែងដែលអ្វីៗមិនដំណើរការ។

គំនិតចម្បងរបស់ខ្ញុំគឺថា ការត្រួតពិនិត្យគួរតែដំណើរការស្របគ្នាជាមួយនឹងដំណើរការអភិវឌ្ឍន៍។ ប្រសិនបើអ្នកបង្វែរក្រុមត្រួតពិនិត្យសម្រាប់កិច្ចការផ្សេងទៀត (ការបង្កើត CI/CD, sandboxing, ការរៀបចំរចនាសម្ព័ន្ធឡើងវិញ) ការត្រួតពិនិត្យនឹងចាប់ផ្តើមយឺតយ៉ាវ ហើយអ្នកប្រហែលជាមិនអាចតាមទាន់ការអភិវឌ្ឍន៍ទេ (ឬមិនយូរមិនឆាប់ អ្នកនឹងត្រូវបញ្ឈប់វា)។

អ្វីគ្រប់យ៉ាងតាមកម្រិត

នេះជារបៀបដែលខ្ញុំឃើញការរៀបចំប្រព័ន្ធត្រួតពិនិត្យ។

1) កម្រិតនៃការដាក់ពាក្យ:

• តាមដានតក្កវិជ្ជាអាជីវកម្មកម្មវិធី;
• ការត្រួតពិនិត្យសុខភាពនៃសេវា;
• ការត្រួតពិនិត្យការរួមបញ្ចូល។

២) កម្រិត​ហេដ្ឋារចនាសម្ព័ន្ធ៖

• ការត្រួតពិនិត្យកម្រិត orchestration;
• ការត្រួតពិនិត្យកម្មវិធីប្រព័ន្ធ;
• ការត្រួតពិនិត្យកម្រិតជាតិដែក។

3) ជាថ្មីម្តងទៀតកម្រិតកម្មវិធី - ប៉ុន្តែជាផលិតផលវិស្វកម្ម:

• ការប្រមូលនិងត្រួតពិនិត្យកំណត់ហេតុកម្មវិធី;
• APM;
• ការតាមដាន។

៤) ការជូនដំណឹង៖

• ការរៀបចំប្រព័ន្ធព្រមាន;
• ការរៀបចំប្រព័ន្ធកាតព្វកិច្ច;
• ការរៀបចំ "មូលដ្ឋានចំណេះដឹង" និងលំហូរការងារសម្រាប់ដំណើរការឧប្បត្តិហេតុ។

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

ស្រទាប់កម្មវិធី - ការត្រួតពិនិត្យតក្កវិជ្ជាអាជីវកម្ម

នៅទីនេះយើងកំពុងនិយាយអំពីការពិនិត្យមើលការពិតដែលកម្មវិធីដំណើរការសម្រាប់អ្នកប្រើប្រាស់។

កម្រិតនេះគួរតែត្រូវបានធ្វើក្នុងដំណាក់កាលអភិវឌ្ឍន៍។ ឧទាហរណ៍ យើងមាន Prometheus ដែលមានលក្ខខណ្ឌ៖ វាទៅម៉ាស៊ីនមេដែលធ្វើការពិនិត្យ ទាញចំណុចបញ្ចប់ ហើយចំណុចបញ្ចប់ទៅពិនិត្យ API ។

នៅពេលដែលត្រូវបានសួរជាញឹកញាប់ដើម្បីត្រួតពិនិត្យទំព័រដើមដើម្បីធ្វើឱ្យប្រាកដថាគេហទំព័រកំពុងដំណើរការ អ្នកសរសេរកម្មវិធីផ្តល់ចំណុចទាញដែលអាចទាញបានរាល់ពេលដែលពួកគេត្រូវការដើម្បីធ្វើឱ្យប្រាកដថា API ដំណើរការ។ ហើយអ្នកសរសេរកម្មវិធីនៅពេលនេះនៅតែទទួលយក និងសរសេរ /api/test/helloworld
វិធីតែមួយគត់ដើម្បីប្រាកដថាអ្វីៗដំណើរការ? – ទេ!

• ការបង្កើតការត្រួតពិនិត្យបែបនេះគឺជាកិច្ចការសំខាន់របស់អ្នកអភិវឌ្ឍន៍។ ការធ្វើតេស្តឯកតាគួរតែត្រូវបានសរសេរដោយអ្នកសរសេរកម្មវិធីដែលសរសេរកូដ។ ពីព្រោះប្រសិនបើអ្នកបែកធ្លាយវាទៅអ្នកគ្រប់គ្រង "លោក Dude នេះជាបញ្ជីនៃពិធីការ API សម្រាប់មុខងារទាំង 25 សូមតាមដានអ្វីៗទាំងអស់!" - គ្មានអ្វីនឹងដំណើរការទេ។
• ប្រសិនបើអ្នកបោះពុម្ព "ជំរាបសួរពិភពលោក" គ្មាននរណាម្នាក់នឹងដឹងថា API គួរតែនិងដំណើរការទេ។ រាល់ការផ្លាស់ប្តូរ API ត្រូវតែនាំទៅរកការផ្លាស់ប្តូរនៅក្នុងការត្រួតពិនិត្យ។
• ប្រសិនបើអ្នកមានបញ្ហាបែបនេះរួចហើយ សូមបញ្ឈប់លក្ខណៈពិសេស និងបែងចែកអ្នកអភិវឌ្ឍន៍ដែលនឹងសរសេរការត្រួតពិនិត្យទាំងនេះ ឬទទួលយកការខាតបង់ ទទួលយកថាគ្មានអ្វីត្រូវបានធីកទេ ហើយនឹងបរាជ័យ។

គន្លឹះបច្ចេកទេស៖

• ត្រូវប្រាកដថារៀបចំម៉ាស៊ីនមេខាងក្រៅដើម្បីរៀបចំការត្រួតពិនិត្យ - អ្នកត្រូវតែប្រាកដថាគម្រោងរបស់អ្នកអាចចូលទៅដល់ពិភពខាងក្រៅបាន។
• រៀបចំការត្រួតពិនិត្យលើពិធីការ API ទាំងមូល មិនត្រឹមតែចំណុចបញ្ចប់នីមួយៗប៉ុណ្ណោះទេ។
• បង្កើត prometheus-endpoint ជាមួយនឹងលទ្ធផលតេស្ត។

ស្រទាប់កម្មវិធី - ការត្រួតពិនិត្យម៉ែត្រសុខភាព

ឥឡូវនេះយើងកំពុងនិយាយអំពីរង្វាស់សុខភាពខាងក្រៅនៃសេវាកម្ម។

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

របៀបអនុវត្តវាឱ្យបានត្រឹមត្រូវតាមបច្ចេកទេស៖ សេវាកម្មនីមួយៗបង្ហាញចំណុចបញ្ចប់អំពីដំណើរការបច្ចុប្បន្នរបស់វា ហើយនៅក្នុងក្រាហ្វនៃ Grafana (ឬកម្មវិធីផ្សេងទៀត) យើងឃើញស្ថានភាពនៃសេវាកម្មទាំងអស់។

• រាល់ការផ្លាស់ប្តូរ API ត្រូវតែនាំទៅរកការផ្លាស់ប្តូរនៅក្នុងការត្រួតពិនិត្យ។
• បង្កើតសេវាកម្មថ្មីភ្លាមៗជាមួយនឹងរង្វាស់សុខភាព។
• អ្នកគ្រប់គ្រងអាចមករកអ្នកអភិវឌ្ឍន៍ ហើយសួរថា "បន្ថែមមុខងារមួយចំនួនឱ្យខ្ញុំ ដើម្បីឱ្យខ្ញុំយល់គ្រប់យ៉ាង និងបន្ថែមព័ត៌មានអំពីវាទៅក្នុងប្រព័ន្ធត្រួតពិនិត្យរបស់ខ្ញុំ"។ ប៉ុន្តែអ្នកអភិវឌ្ឍន៍ជាធម្មតាឆ្លើយថា "យើងនឹងមិនបន្ថែមអ្វីពីរសប្តាហ៍មុនការចេញផ្សាយនោះទេ។"
  ឲ្យអ្នកគ្រប់គ្រងអភិវឌ្ឍន៍ដឹងថានឹងមានការខាតបង់បែបនេះ សូមឲ្យអ្នកគ្រប់គ្រងអភិវឌ្ឍន៍បានដឹងផង។ ពីព្រោះនៅពេលដែលអ្វីៗធ្លាក់ចុះ នរណាម្នាក់នឹងនៅតែហៅ និងទាមទារឱ្យត្រួតពិនិត្យ "សេវាកម្មធ្លាក់ចុះឥតឈប់ឈរ" (គ)
• ដោយវិធីនេះ បែងចែកអ្នកអភិវឌ្ឍន៍ឱ្យសរសេរកម្មវិធីជំនួយសម្រាប់ Grafana - នេះនឹងក្លាយជាជំនួយដ៏ល្អសម្រាប់អ្នកគ្រប់គ្រង។

ស្រទាប់កម្មវិធី - ការត្រួតពិនិត្យការរួមបញ្ចូល

ការត្រួតពិនិត្យសមាហរណកម្មផ្តោតលើការតាមដានទំនាក់ទំនងរវាងប្រព័ន្ធសំខាន់ៗនៃអាជីវកម្ម។

ជាឧទាហរណ៍ មានសេវាកម្មចំនួន 15 ដែលទាក់ទងគ្នាទៅវិញទៅមក។ ទាំងនេះមិនមែនជាគេហទំព័រដាច់ដោយឡែកទៀតទេ។ ទាំងនោះ។ យើងមិនអាចទាញសេវាកម្មដោយខ្លួនឯងបានទេ ទទួលបាន /helloworld ហើយយល់ថាសេវាកម្មកំពុងដំណើរការ។ ដោយសារតែសេវាបណ្តាញបញ្ជាទិញត្រូវតែផ្ញើព័ត៌មានអំពីការបញ្ជាទិញទៅឡានក្រុង - ពីឡានក្រុង សេវាកម្មឃ្លាំងត្រូវតែទទួលសារនេះហើយធ្វើការជាមួយវាបន្ថែមទៀត។ ហើយសេវាចែកចាយអ៊ីមែលត្រូវតែដំណើរការវាដោយរបៀបណាបន្ថែមទៀត។ល។

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

អ្វីដែលខ្ញុំណែនាំអោយធ្វើ៖

• សម្រាប់ការទំនាក់ទំនងសមកាលកម្ម៖ ចំនុចបញ្ចប់ធ្វើការស្នើសុំទៅកាន់សេវាកម្មដែលពាក់ព័ន្ធ។ ទាំងនោះ។ យើង​យក​ចំណុច​បញ្ចប់​នេះ ទាញ​ស្គ្រីប​មួយ​នៅ​ខាង​ក្នុង​សេវាកម្ម ដែល​ទៅ​គ្រប់​ចំណុច​ទាំងអស់ ហើយ​និយាយ​ថា "ខ្ញុំ​អាច​ទាញ​បាន ហើយ​ទាញ​ទៅ​ទីនោះ ខ្ញុំ​អាច​ទាញ​បាន ... "
• សម្រាប់ការទំនាក់ទំនងអសមកាល៖ សារចូល - ចំណុចបញ្ចប់ពិនិត្យឡានក្រុងសម្រាប់សារសាកល្បង និងបង្ហាញស្ថានភាពដំណើរការ។
• សម្រាប់ការទំនាក់ទំនងអសមកាល៖ សារចេញ - ចំណុចបញ្ចប់ផ្ញើសារសាកល្បងទៅកាន់ឡានក្រុង។

ជាធម្មតាកើតឡើង៖ យើងមានសេវាកម្មដែលបោះទិន្នន័យទៅក្នុងឡានក្រុង។ យើងមកសេវានេះ ហើយសុំឱ្យអ្នកប្រាប់យើងអំពីសុខភាពនៃការរួមបញ្ចូលរបស់វា។ ហើយប្រសិនបើសេវាកម្មត្រូវការបង្កើតសារនៅកន្លែងណាមួយបន្ថែមទៀត (WebApp) នោះវានឹងបង្កើតសារសាកល្បងនេះ។ ហើយប្រសិនបើយើងដំណើរការសេវាកម្មនៅលើផ្នែក OrderProcessing ដំបូងវាបង្ហោះអ្វីដែលវាអាចប្រកាសឯករាជ្យ ហើយប្រសិនបើមានរឿងដែលពឹងផ្អែកខ្លះនោះ វាអានសំណុំនៃសារសាកល្បងពីឡានក្រុង យល់ថាវាអាចដំណើរការពួកវា រាយការណ៍ និង បើចាំបាច់ បង្ហោះពួកវាបន្ថែមទៀត ហើយអំពីរឿងនេះ គាត់និយាយថា - អ្វីៗមិនអីទេ ខ្ញុំនៅរស់។

ជាញឹកញាប់យើងឮសំណួរ "តើយើងអាចសាកល្បងវានៅលើទិន្នន័យប្រយុទ្ធដោយរបៀបណា?" ជាឧទាហរណ៍ យើងកំពុងនិយាយអំពីសេវាកម្មបញ្ជាទិញដូចគ្នា។ ការបញ្ជាទិញផ្ញើសារទៅកាន់ឃ្លាំងដែលទំនិញត្រូវបានបិទ៖ យើងមិនអាចសាកល្បងវានៅលើទិន្នន័យប្រយុទ្ធបានទេព្រោះ "ទំនិញរបស់ខ្ញុំនឹងត្រូវកាត់ចោល!" ដំណោះស្រាយ៖ រៀបចំផែនការធ្វើតេស្តទាំងមូលនេះនៅដើមដំបូង។ អ្នកក៏មានការធ្វើតេស្តឯកតាដែលបង្កើតការចំអកផងដែរ។ ដូច្នេះ ធ្វើវាក្នុងកម្រិតកាន់តែស៊ីជម្រៅ ដែលអ្នកមានបណ្តាញទំនាក់ទំនងដែលមិនប៉ះពាល់ដល់ប្រតិបត្តិការអាជីវកម្ម។

កម្រិតហេដ្ឋារចនាសម្ព័ន្ធ

ការ​ត្រួត​ពិនិត្យ​ហេដ្ឋា​រចនា​សម្ព័ន្ធ​គឺ​ជា​អ្វី​ដែល​ត្រូវ​បាន​គេ​ចាត់​ទុក​ជា​យូរ​មក​ហើយ​ការ​ត្រួត​ពិនិត្យ​ខ្លួន​ឯង។

• ការត្រួតពិនិត្យហេដ្ឋារចនាសម្ព័ន្ធអាច និងគួរតែត្រូវបានចាប់ផ្តើមជាដំណើរការដាច់ដោយឡែកមួយ។
• អ្នកមិនគួរចាប់ផ្តើមជាមួយនឹងការត្រួតពិនិត្យហេដ្ឋារចនាសម្ព័ន្ធនៅលើគម្រោងដែលកំពុងដំណើរការនោះទេ ទោះបីជាអ្នកពិតជាចង់ធ្វើក៏ដោយ។ នេះ​ជា​ការ​ឈឺ​ចាប់​សម្រាប់​មនុស្ស​គ្រប់​រូប។ "ដំបូងខ្ញុំនឹងត្រួតពិនិត្យចង្កោម ខ្ញុំនឹងត្រួតពិនិត្យហេដ្ឋារចនាសម្ព័ន្ធ" - i.e. ជាដំបូង វានឹងតាមដានអ្វីដែលស្ថិតនៅខាងក្រោម ប៉ុន្តែនឹងមិនចូលទៅក្នុងកម្មវិធីនោះទេ។ ដោយសារតែកម្មវិធីគឺជារឿងដែលមិនអាចយល់បានសម្រាប់ devops ។ វាត្រូវបានបែកធ្លាយទៅគាត់ ហើយគាត់មិនយល់ពីរបៀបដែលវាដំណើរការនោះទេ។ ហើយគាត់យល់ពីហេដ្ឋារចនាសម្ព័ន្ធ ហើយចាប់ផ្តើមជាមួយវា។ ប៉ុន្តែទេ - អ្នកតែងតែត្រូវត្រួតពិនិត្យកម្មវិធីជាមុនសិន។
• កុំទៅហួសពីចំនួននៃការជូនដំណឹង។ ដោយគិតពីភាពស្មុគស្មាញនៃប្រព័ន្ធទំនើប ការជូនដំណឹងកំពុងហោះហើរឥតឈប់ឈរ ហើយអ្នកត្រូវរស់នៅដោយរបៀបណាជាមួយការជូនដំណឹងនេះ។ ហើយ​អ្នក​ដែល​កំពុង​ហៅ​ទូរសព្ទ ដោយ​បាន​មើល​ការ​ជូន​ដំណឹង​មួយ​រយ​បន្ទាប់​ទៀត​នឹង​សម្រេច​ចិត្ត​ថា "ខ្ញុំ​មិន​ចង់​គិត​អំពី​វា"។ ការដាស់តឿនគួរតែជូនដំណឹងតែអំពីរឿងសំខាន់ប៉ុណ្ណោះ។

កម្រិតកម្មវិធីជាអង្គភាពអាជីវកម្ម

ចំណុច​សំខាន់:

• អេលខេ។ នេះគឺជាស្តង់ដារឧស្សាហកម្ម។ ប្រសិនបើហេតុផលមួយចំនួនដែលអ្នកមិនប្រមូលផ្តុំកំណត់ហេតុ សូមចាប់ផ្តើមធ្វើភ្លាមៗ។
• APM APMs ខាងក្រៅជាមធ្យោបាយមួយដើម្បីបិទការត្រួតពិនិត្យកម្មវិធីយ៉ាងឆាប់រហ័ស (NewRelic, BlackFire, Datadog) ។ អ្នក​អាច​ដំឡើង​វត្ថុ​នេះ​ជា​បណ្ដោះអាសន្ន ដើម្បី​យ៉ាង​ហោច​ណាស់​ឱ្យ​យល់​ពី​អ្វី​ដែល​កំពុង​កើត​ឡើង​ជាមួយ​អ្នក។
• ការតាមដាន។ នៅក្នុងសេវាមីក្រូរាប់សិប អ្នកត្រូវតាមដានអ្វីៗគ្រប់យ៉ាង ពីព្រោះសំណើនេះលែងរស់នៅដោយខ្លួនឯងទៀតហើយ។ វាពិបាកណាស់ក្នុងការបន្ថែមនៅពេលក្រោយ ដូច្នេះវាជាការប្រសើរក្នុងការកំណត់ការតាមដានភ្លាមៗនៅក្នុងការអភិវឌ្ឍន៍ - នេះគឺជាការងារ និងអត្ថប្រយោជន៍របស់អ្នកអភិវឌ្ឍន៍។ បើមិនទាន់បានអនុវត្តទេ សូមអនុវត្តន៍! សូមមើល Jaeger/Zipkin

ការជូនដំណឹង

• ការរៀបចំប្រព័ន្ធជូនដំណឹង៖ នៅក្នុងលក្ខខណ្ឌនៃការត្រួតពិនិត្យ bunch នៃរឿងមួយ គួរតែមានប្រព័ន្ធបង្រួបបង្រួមសម្រាប់ការផ្ញើការជូនដំណឹង។ អ្នកអាចនៅ Grafana ។ នៅភាគខាងលិចមនុស្សគ្រប់គ្នាប្រើ PagerDuty ។ ការដាស់តឿនគួរតែច្បាស់លាស់ (ឧ. ថាពួកគេមកពីណា...)។ ហើយវាត្រូវបានណែនាំឱ្យគ្រប់គ្រងថាការជូនដំណឹងត្រូវបានទទួលទាំងអស់។
• ការរៀបចំប្រព័ន្ធកាតព្វកិច្ច៖ ការដាស់តឿនមិនគួរត្រូវបានផ្ញើទៅមនុស្សគ្រប់គ្នាទេ (ទាំងអ្នកគ្រប់គ្នានឹងមានប្រតិកម្មនៅក្នុងហ្វូងមនុស្ស ឬគ្មាននរណាម្នាក់នឹងប្រតិកម្ម)។ អ្នកអភិវឌ្ឍន៍ក៏ត្រូវហៅទូរសព្ទផងដែរ៖ ត្រូវប្រាកដថាកំណត់ផ្នែកនៃទំនួលខុសត្រូវ ធ្វើការណែនាំច្បាស់លាស់ ហើយសរសេរក្នុងនោះថាអ្នកណាត្រូវហៅទូរសព្ទនៅថ្ងៃច័ន្ទ និងថ្ងៃពុធ ហើយអ្នកណាត្រូវហៅទូរសព្ទនៅថ្ងៃអង្គារ និងថ្ងៃសុក្រ (បើមិនដូច្នេះទេ ពួកគេនឹងមិនហៅនរណាម្នាក់សូម្បីតែនៅក្នុង ព្រឹត្តិការណ៍នៃបញ្ហាធំ - ពួកគេនឹងភ័យខ្លាចក្នុងការដាស់អ្នក ឬរំខាន៖ មនុស្សជាទូទៅមិនចូលចិត្តហៅ និងដាស់អ្នកដ៏ទៃទេ ជាពិសេសនៅពេលយប់)។ ហើយពន្យល់ថាការសុំជំនួយមិនមែនជាសូចនាករនៃភាពអសមត្ថភាពទេ ("ខ្ញុំសុំជំនួយ មានន័យថាខ្ញុំជាកម្មករមិនល្អ") លើកទឹកចិត្តឱ្យមានការស្នើសុំជំនួយ។
• ការរៀបចំ "មូលដ្ឋានចំណេះដឹង" និងលំហូរការងារសម្រាប់ដំណើរការឧប្បត្តិហេតុ៖ សម្រាប់ឧប្បត្តិហេតុធ្ងន់ធ្ងរនីមួយៗ ការធ្វើកោសល្យវិច័យគួរតែត្រូវបានគ្រោងទុក ហើយជាវិធានការបណ្តោះអាសន្ន សកម្មភាពដែលនឹងដោះស្រាយឧប្បត្តិហេតុគួរតែត្រូវបានកត់ត្រាទុក។ ហើយធ្វើឱ្យវាក្លាយជាការអនុវត្តដែលការដាស់តឿនម្តងហើយម្តងទៀតគឺជាអំពើបាប។ ពួកគេត្រូវតែត្រូវបានជួសជុលនៅក្នុងកូដ ឬការងារហេដ្ឋារចនាសម្ព័ន្ធ។

ជង់បច្ចេកវិទ្យា

ចូរយើងស្រមៃថាជង់របស់យើងមានដូចខាងក្រោម:

• ការប្រមូលទិន្នន័យ - Prometheus + Grafana;
• ការវិភាគកំណត់ហេតុ - ELK;
• សម្រាប់ APM ឬ Tracing - Jaeger (Zipkin) ។

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

ចំណុចបច្ចេកទេសមួយចំនួនដែលខ្ញុំឃើញនៅគ្រប់ទីកន្លែងនាពេលថ្មីៗនេះ៖

Prometheus កំពុងត្រូវបានរុញនៅខាងក្នុង Kubernetes - តើអ្នកណាជាអ្នកបង្កើតរឿងនេះ?! ប្រសិនបើចង្កោមរបស់អ្នកគាំង តើអ្នកនឹងធ្វើអ្វី? ប្រសិនបើអ្នកមានចង្កោមស្មុគ្រស្មាញនៅខាងក្នុង នោះគួរតែមានប្រព័ន្ធត្រួតពិនិត្យមួយចំនួននៅខាងក្នុងចង្កោម និងខាងក្រៅមួយចំនួនដែលនឹងប្រមូលទិន្នន័យពីខាងក្នុងចង្កោម។

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

ការរកឃើញ

• ការតាមដានការអភិវឌ្ឍន៍មិនមែនជាការដំឡើងឧបករណ៍ប្រើប្រាស់ទេ ប៉ុន្តែជាការអភិវឌ្ឍន៍ផលិតផលកម្មវិធី។ 98% នៃការត្រួតពិនិត្យនាពេលបច្ចុប្បន្ននេះគឺការសរសេរកូដ។ ការសរសេរកូដនៅក្នុងសេវាកម្ម ការសរសេរកូដការត្រួតពិនិត្យខាងក្រៅ ការពិនិត្យមើលសេវាកម្មខាងក្រៅ ហើយនោះជាអ្វីទាំងអស់។
• កុំខ្ជះខ្ជាយពេលវេលារបស់អ្នកអភិវឌ្ឍន៍របស់អ្នកលើការត្រួតពិនិត្យ៖ វាអាចចំណាយពេលរហូតដល់ 30% នៃការងាររបស់ពួកគេ ប៉ុន្តែវាមានតម្លៃ។
• Devops កុំបារម្ភថាអ្នកមិនអាចត្រួតពិនិត្យអ្វីមួយបានទេ ព្រោះរឿងខ្លះជាវិធីគិតខុសគ្នាទាំងស្រុង។ អ្នកមិនមែនជាអ្នកសរសេរកម្មវិធីទេ ហើយការងារត្រួតពិនិត្យគឺពិតជាការងាររបស់ពួកគេ។
• ប្រសិនបើគម្រោងកំពុងដំណើរការហើយមិនត្រូវបានត្រួតពិនិត្យ (ហើយអ្នកគឺជាអ្នកគ្រប់គ្រង) បែងចែកធនធានសម្រាប់ការត្រួតពិនិត្យ។
• ប្រសិនបើផលិតផលកំពុងផលិតរួចហើយ ហើយអ្នកគឺជាអ្នកអភិវឌ្ឍន៍ដែលត្រូវបានគេប្រាប់ឱ្យ "រៀបចំការត្រួតពិនិត្យ" - ព្យាយាមពន្យល់ដល់អ្នកគ្រប់គ្រងនូវអ្វីដែលខ្ញុំបានសរសេរទាំងអស់នេះអំពី។

នេះគឺជាកំណែបន្ថែមនៃរបាយការណ៍នៅឯសន្និសីទ Saint Highload++ ។

ប្រសិនបើអ្នកចាប់អារម្មណ៍លើគំនិត និងគំនិតរបស់ខ្ញុំលើវា និងប្រធានបទពាក់ព័ន្ធ នោះអ្នកអាចនៅទីនេះ អានឆានែល 🙂

ប្រភព: www.habr.com