ហេតុអ្វីបានជាធនាគារត្រូវការ AIOps និងការត្រួតពិនិត្យឆ័ត្រ ឬតើទំនាក់ទំនងអតិថិជនផ្អែកលើអ្វី?

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

បច្ចុប្បន្នខ្ញុំកំពុងដឹកនាំការចាប់ផ្ដើមអាជីវកម្មមួយដែលមានឈ្មោះថា MONQ Digital lab ជាកន្លែងដែលក្រុមរបស់ខ្ញុំ និងខ្ញុំកំពុងបង្កើតផលិតផលសម្រាប់ដំណើរការស្វ័យប្រវត្តិកម្មនៃការគាំទ្រ និងប្រតិបត្តិការរបស់ក្រុមហ៊ុន IT ។ ការចូលទៅក្នុងទីផ្សារមិនមែនជាកិច្ចការងាយស្រួលនោះទេ ហើយយើងបានចាប់ផ្តើមជាមួយនឹងកិច្ចការផ្ទះបន្តិចបន្តួច ឆ្លងកាត់អ្នកជំនាញទីផ្សារ ដៃគូរបស់យើង និងអនុវត្តការបែងចែកទីផ្សារ។ សំណួរចម្បងគឺត្រូវយល់ថា "តើការឈឺចាប់របស់អ្នកណាដែលយើងអាចព្យាបាលបានល្អបំផុត?"

ធនាគារបានធ្វើឱ្យវាចូលទៅក្នុង TOP 3 ផ្នែក។ ហើយជាការពិតណាស់ ទីមួយក្នុងបញ្ជីគឺ Tinkoff និង Sberbank ។ នៅពេលដែលយើងបានទៅជួបអ្នកជំនាញទីផ្សារធនាគារ ពួកគេបាននិយាយថា៖ ណែនាំផលិតផលរបស់អ្នកនៅទីនោះ ហើយផ្លូវទៅកាន់ទីផ្សារធនាគារនឹងបើកចំហ។ យើងបានព្យាយាមចូលទាំងនៅទីនោះ និងទីនោះ ប៉ុន្តែការបរាជ័យកំពុងរង់ចាំយើងនៅ Sberbank ហើយបុរសមកពី Tinkoff បានប្រែក្លាយកាន់តែបើកចំហសម្រាប់ការទំនាក់ទំនងប្រកបដោយផលិតភាពជាមួយអ្នកចាប់ផ្តើមអាជីវកម្មរុស្ស៊ី (ប្រហែលជាដោយសារតែ Sber នៅពេលនោះ។ បានទិញ ស្ទើរតែមួយពាន់លាននៃគូប្រជែងលោកខាងលិចរបស់យើង) ។ ក្នុងរយៈពេលមួយខែ យើងបានចាប់ផ្តើមគម្រោងសាកល្បង។ របៀបដែលវាកើតឡើងសូមអានបន្ត។

យើងបានដោះស្រាយបញ្ហានៃប្រតិបត្តិការ និងការត្រួតពិនិត្យអស់រយៈពេលជាច្រើនឆ្នាំ ឥឡូវនេះយើងកំពុងអនុវត្តផលិតផលរបស់យើងនៅក្នុងវិស័យសាធារណៈ ក្នុងការធានារ៉ាប់រង នៅក្នុងធនាគារ នៅក្នុងក្រុមហ៊ុនទូរគមនាគមន៍ ការអនុវត្តន៍មួយគឺជាមួយនឹងក្រុមហ៊ុនអាកាសចរណ៍មួយ (មុនពេលគម្រោង យើងមិនបានសូម្បីតែ គិតថាអាកាសចរណ៍គឺជាឧស្សាហកម្មដែលពឹងផ្អែកលើ IT ហើយឥឡូវនេះយើងពិតជាសង្ឃឹមថា ទោះបីជាមាន COVID ក៏ដោយ ថាក្រុមហ៊ុននឹងលេចចេញ និងចាប់ផ្តើមដំណើរការ)។

ផលិតផលដែលយើងផលិតជាកម្មសិទ្ធិរបស់កម្មវិធីសហគ្រាស ផ្នែក AIOps (Artificial Intelligence for IT Operations ឬ ITOps) ។ គោលដៅចម្បងនៃការអនុវត្តប្រព័ន្ធដូចជាកម្រិតនៃភាពចាស់ទុំនៃដំណើរការនៅក្នុងក្រុមហ៊ុនកើនឡើង៖

1. ពន្លត់ភ្លើង៖ កំណត់អត្តសញ្ញាណការបរាជ័យ ជម្រះស្ទ្រីមនៃការដាស់តឿនពីកំទេចកំទី ប្រគល់ភារកិច្ច និងឧប្បត្តិហេតុដល់អ្នកទទួលខុសត្រូវ។
2. បង្កើនប្រសិទ្ធភាពនៃសេវាកម្មព័ត៌មានវិទ្យា៖ កាត់បន្ថយពេលវេលាដើម្បីដោះស្រាយឧប្បត្តិហេតុ បង្ហាញពីមូលហេតុនៃការបរាជ័យ បង្កើនតម្លាភាពនៃស្ថានភាពព័ត៌មានវិទ្យា។
3. បង្កើនប្រសិទ្ធភាពអាជីវកម្ម៖ កាត់បន្ថយចំនួនពលកម្មដោយដៃ កាត់បន្ថយហានិភ័យ បង្កើនភាពស្មោះត្រង់របស់អតិថិជន។

តាមបទពិសោធន៍របស់យើង ធនាគារមាន "ការឈឺចាប់" ដូចខាងក្រោមជាមួយនឹងការត្រួតពិនិត្យរួមជាមួយនឹងហេដ្ឋារចនាសម្ព័ន្ធ IT ធំៗទាំងអស់៖

• “អ្នកណាដឹង”៖ មាននាយកដ្ឋានបច្ចេកទេសជាច្រើន ស្ទើរតែគ្រប់គ្នាមានប្រព័ន្ធត្រួតពិនិត្យយ៉ាងតិចមួយ ហើយភាគច្រើនមានច្រើនជាងមួយ។
• "ហ្វូងមូស" នៃការដាស់តឿន៖ ប្រព័ន្ធនីមួយៗបង្កើតមនុស្សរាប់រយនាក់ និងបំផ្ទុះអ្នកទទួលខុសត្រូវទាំងអស់ជាមួយពួកគេ (ជួនកាលក៏រវាងនាយកដ្ឋាន)។ វាពិបាកក្នុងការរក្សាការផ្តោតអារម្មណ៍នៃការគ្រប់គ្រងលើការជូនដំណឹងនីមួយៗ ភាពបន្ទាន់ និងសារៈសំខាន់របស់ពួកគេត្រូវបានកម្រិតដោយសារតែចំនួនដ៏ធំ។
• ធនាគារធំៗ - អ្នកដឹកនាំវិស័យចង់មិនត្រឹមតែតាមដានប្រព័ន្ធរបស់ពួកគេជាបន្តបន្ទាប់ ដើម្បីដឹងពីកន្លែងដែលមានការបរាជ័យប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានវេទមន្តពិតប្រាកដនៃ AI ផងដែរ - ដើម្បីធ្វើឱ្យប្រព័ន្ធត្រួតពិនិត្យដោយខ្លួនឯង ទស្សន៍ទាយដោយខ្លួនឯង និងកែតម្រូវខ្លួនឯង។

នៅពេលយើងមកដល់ការប្រជុំលើកដំបូងនៅ Tinkoff យើងត្រូវបានគេប្រាប់ភ្លាមៗថាពួកគេមិនមានបញ្ហាជាមួយការត្រួតពិនិត្យ ហើយគ្មានអ្វីធ្វើឱ្យពួកគេឈឺចាប់ទេ ហើយសំណួរចម្បងគឺ៖ "តើយើងអាចផ្តល់អ្វីសម្រាប់អ្នកដែលធ្វើបានល្អរួចទៅហើយ?"

ការសន្ទនាមានរយៈពេលវែង យើងបានពិភាក្សាអំពីរបៀបដែលសេវាកម្មមីក្រូរបស់ពួកគេត្រូវបានបង្កើតឡើង របៀបដែលនាយកដ្ឋានធ្វើការ បញ្ហាហេដ្ឋារចនាសម្ព័ន្ធមានភាពរសើបជាង ដែលមិនមានភាពរសើបសម្រាប់អ្នកប្រើប្រាស់ កន្លែងណាជា "កន្លែងពិការភ្នែក" និងអ្វីជាគោលដៅ និង SLAs របស់ពួកគេ។

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

ជាលទ្ធផល យើងបានកំណត់ផ្នែកមួយចំនួននៃកិច្ចសហប្រតិបត្តិការ៖

1. ដំណាក់កាលដំបូងគឺការត្រួតពិនិត្យឆ័ត្រ ដើម្បីបង្កើនល្បឿននៃការដោះស្រាយឧប្បត្តិហេតុ
2. ដំណាក់កាលទីពីរគឺដំណើរការស្វ័យប្រវត្តិកម្មដើម្បីកាត់បន្ថយហានិភ័យ និងកាត់បន្ថយការចំណាយសម្រាប់ការធ្វើមាត្រដ្ឋាននាយកដ្ឋានព័ត៌មានវិទ្យា។

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

រឿងសំខាន់មួយនៅក្នុងគំនិតរបស់យើងនៅក្នុងទំនាក់ទំនងជាមួយអតិថិជនគឺភាពស្មោះត្រង់។ បន្ទាប់ពីការសន្ទនាដំបូងនិងការគណនាតម្លៃនៃអាជ្ញាប័ណ្ណវាត្រូវបានគេនិយាយថាចាប់តាំងពីការចំណាយទាបដូច្នេះវាប្រហែលជាមានតម្លៃក្នុងការទិញអាជ្ញាប័ណ្ណភ្លាមៗ (បើប្រៀបធៀបទៅនឹង Dynatrace Klyuch-Astrom ពីអត្ថបទខាងលើអំពីធនាគារបៃតងរបស់យើង អាជ្ញាប័ណ្ណមានតម្លៃមិនមែនមួយភាគបីនៃពាន់លានទេប៉ុន្តែ 12 ពាន់រូប្លិ៍ក្នុងមួយខែសម្រាប់ 1 ជីហ្គាបៃសម្រាប់ Sber វានឹងមានតម្លៃថោកជាងច្រើនដង) ។ ប៉ុន្តែ​យើង​ប្រាប់​គេ​ភ្លាម​ថា​អ្វី​ដែល​យើង​មាន និង​អ្វី​ដែល​យើង​មិន​មាន។ ប្រហែលជាអ្នកតំណាងផ្នែកលក់មកពីក្រុមហ៊ុនរួមបញ្ចូលគ្នាដ៏ធំមួយអាចនិយាយថា "បាទ យើងអាចធ្វើអ្វីគ្រប់យ៉ាងបាន ពិតណាស់ទិញអាជ្ញាប័ណ្ណរបស់យើង" ប៉ុន្តែយើងបានសម្រេចចិត្តដាក់កាតទាំងអស់របស់យើងនៅលើតុ។ នៅពេលចាប់ផ្តើម ប្រអប់របស់យើងមិនមានការរួមបញ្ចូលជាមួយ Prometheus ទេ ហើយកំណែថ្មីជាមួយនឹងប្រព័ន្ធរងស្វ័យប្រវត្តិកម្មជិតនឹងត្រូវបានចេញផ្សាយ ប៉ុន្តែយើងមិនទាន់បានដឹកជញ្ជូនវាទៅឱ្យអតិថិជននៅឡើយទេ។

គម្រោងសាកល្បងបានចាប់ផ្តើម ព្រំដែនរបស់វាត្រូវបានកំណត់ ហើយយើងត្រូវបានគេផ្តល់ពេល 2 ខែ។ ភារកិច្ចចម្បងគឺ៖

• រៀបចំកំណែថ្មីនៃវេទិកា ហើយដាក់ពង្រាយវានៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធរបស់ធនាគារ
• ភ្ជាប់ប្រព័ន្ធត្រួតពិនិត្យចំនួន 2 (Zabbix និង Prometheus);
• ផ្ញើការជូនដំណឹងទៅកាន់អ្នកដែលទទួលខុសត្រូវនៅក្នុង Slack និងតាមរយៈសារ SMS;
• ដំណើរការស្គ្រីបព្យាបាលដោយស្វ័យប្រវត្តិ។

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

ខណៈពេលដែលយើងកំពុងរៀបចំអ្នកបើកបរ យើងបានជួបប្រទះបញ្ហាថ្មីមួយដែលអាចបិទគម្រោងមុនកាលវិភាគ៖ ដើម្បីផ្ញើការជូនដំណឹងទៅកាន់អ្នកផ្ញើសារភ្លាមៗ និងតាមរយៈសារ SMS យើងត្រូវការការតភ្ជាប់ចូល និងចេញទៅកាន់ម៉ាស៊ីនមេ Microsoft Azure (នៅពេលនោះយើងប្រើវេទិកានេះ ដើម្បីផ្ញើការដាស់តឿនទៅកាន់ Slack) និងសេវាកម្មផ្ញើ SMS ខាងក្រៅ។ ប៉ុន្តែនៅក្នុងគម្រោងនេះ សុវត្ថិភាពគឺជាការផ្តោតជាពិសេស។ ដោយអនុលោមតាមគោលការណ៍របស់ធនាគារ “រន្ធ” បែបនេះមិនអាចបើកបានក្នុងកាលៈទេសៈណាក៏ដោយ។ អ្វីគ្រប់យ៉ាងត្រូវដំណើរការពីរង្វិលជុំបិទជិត។ យើងត្រូវបានផ្តល់ជូនឱ្យប្រើប្រាស់ API នៃសេវាកម្មខាងក្នុងផ្ទាល់ខ្លួនរបស់យើង ដែលផ្ញើការជូនដំណឹងទៅកាន់ Slack និងតាមរយៈសារ SMS ប៉ុន្តែយើងមិនមានឱកាសដើម្បីភ្ជាប់សេវាកម្មបែបនេះចេញពីប្រអប់នោះទេ។

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

ប៉ុន្តែ​យើង​នៅ​សល់​ពេល​មួយ​ខែ​យ៉ាង​ជាក់លាក់​ក្នុង​អំឡុង​ពេល​ដែល​យើង​ត្រូវ​ដំឡើង​អ្វី​គ្រប់​យ៉ាង កំណត់​រចនាសម្ព័ន្ធ និង​ដាក់​ពង្រាយ​ស្វ័យប្រវត្តិកម្ម។

យោងតាមលោក Sergei ដែលជាប្រធានស្ថាបត្យកររបស់យើង វាត្រូវចំណាយពេលយ៉ាងហោចណាស់មួយខែដើម្បីអនុវត្តប្រព័ន្ធដោត។

យើងមិនមានពេលទេ...

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

ជាលទ្ធផលនៃអ្នកបើកយន្តហោះ លទ្ធផលបច្ចេកទេសសំខាន់ៗ និងការសន្និដ្ឋានជាច្រើនត្រូវបានទទួល៖

យើងបានសាកល្បងមុខងារថ្មីសម្រាប់ដំណើរការការជូនដំណឹង

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

ចំណុចប្រទាក់ "គន្លឹះសំយោគ" ។ រៀបចំដំណើរការការជូនដំណឹងពីប្រព័ន្ធត្រួតពិនិត្យដែលបានភ្ជាប់

បង្កើតស្ថានភាពនៃ "សុខភាព" នៃប្រព័ន្ធ

ផ្អែកលើការជូនដំណឹង ព្រឹត្តិការណ៍ត្រួតពិនិត្យត្រូវបានបង្កើតឡើងដែលប៉ះពាល់ដល់សុខភាពរបស់អង្គភាពកំណត់រចនាសម្ព័ន្ធ (CUs)។ យើងកំពុងអនុវត្តគំរូសេវាធនធាន (RSM) ដែលអាចប្រើ CMDB ខាងក្នុង ឬភ្ជាប់ខាងក្រៅ - ក្នុងអំឡុងពេលគម្រោងសាកល្បង អតិថិជនមិនបានភ្ជាប់ CMDB ផ្ទាល់ខ្លួនទេ។

ចំណុចប្រទាក់សម្រាប់ធ្វើការជាមួយគំរូសេវាកម្មធនធាន។ អ្នកបើកយន្តហោះ RSM ។

តាមពិតទៅ អតិថិជនមានអេក្រង់ត្រួតពិនិត្យតែមួយ ដែលព្រឹត្តិការណ៍ពីប្រព័ន្ធផ្សេងៗអាចមើលឃើញ។ បច្ចុប្បន្ននេះប្រព័ន្ធពីរត្រូវបានភ្ជាប់ទៅ "ឆ័ត្រ" - Zabbix និង Prometheus និងប្រព័ន្ធត្រួតពិនិត្យផ្ទៃក្នុងនៃវេទិកាខ្លួនឯង។

ចំណុចប្រទាក់វិភាគ។ អេក្រង់ត្រួតពិនិត្យតែមួយ។

បើកដំណើរការស្វ័យប្រវត្តិកម្ម

ការតាមដានព្រឹត្តិការណ៍បានបង្កឱ្យមានការចាប់ផ្តើមនៃសកម្មភាពដែលបានកំណត់រចនាសម្ព័ន្ធជាមុន - ការផ្ញើការជូនដំណឹង ការដំណើរការស្គ្រីប ការចុះឈ្មោះ/ពង្រឹងឧប្បត្តិហេតុ - ក្រោយមកទៀតមិនត្រូវបានសាកល្បងជាមួយម៉ាស៊ីនភ្ញៀវពិសេសនេះទេ ដោយសារតែ នៅក្នុងគម្រោងសាកល្បងមិនមានការរួមបញ្ចូលជាមួយតុសេវាកម្មទេ។

ចំណុចប្រទាក់ការកំណត់សកម្មភាព។ ផ្ញើការជូនដំណឹងទៅ Slack ហើយចាប់ផ្ដើមម៉ាស៊ីនមេឡើងវិញ។

ការពង្រីកមុខងារផលិតផល

នៅពេលពិភាក្សាអំពីស្គ្រីបស្វ័យប្រវត្តិកម្ម អតិថិជនបានស្នើសុំការគាំទ្រ bash និងចំណុចប្រទាក់ដែលស្គ្រីបទាំងនេះអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធយ៉ាងងាយស្រួល។ កំណែថ្មីបានធ្វើបន្ថែមទៀតបន្តិច (សមត្ថភាពក្នុងការសរសេររចនាសម្ព័ន្ធឡូជីខលពេញលេញនៅក្នុង Lua ដោយមានការគាំទ្រសម្រាប់ cURL, SSH និង SNMP) និងបានអនុវត្តមុខងារដែលអនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងវដ្តជីវិតនៃស្គ្រីប (បង្កើត កែសម្រួល ការគ្រប់គ្រងកំណែ។ លុប និងទុកក្នុងប័ណ្ណសារ)។

ចំណុចប្រទាក់សម្រាប់ធ្វើការជាមួយស្គ្រីបព្យាបាលដោយស្វ័យប្រវត្តិ។ ម៉ាស៊ីនមេចាប់ផ្តើមស្គ្រីបឡើងវិញតាមរយៈ SSH ។

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

ក្នុងអំឡុងពេលសាកល្បង រឿងរ៉ាវរបស់អ្នកប្រើប្រាស់ក៏ត្រូវបានបង្កើតឡើងផងដែរ ដែលធ្វើឲ្យមុខងារបច្ចុប្បន្នប្រសើរឡើង និងបង្កើនតម្លៃសម្រាប់អតិថិជន ខាងក្រោមនេះជាពួកគេមួយចំនួន៖

• អនុវត្តសមត្ថភាពក្នុងការបញ្ជូនបន្តអថេរដោយផ្ទាល់ពីការជូនដំណឹងទៅស្គ្រីប autohealing;
• បន្ថែមការអនុញ្ញាតទៅវេទិកាតាមរយៈ Active Directory ។

ហើយយើងបានទទួលបញ្ហាប្រឈមជាសាកលបន្ថែមទៀត - ដើម្បី "បង្កើត" ផលិតផលជាមួយនឹងសមត្ថភាពផ្សេងទៀត៖

• ការសាងសង់ដោយស្វ័យប្រវត្តិនៃគំរូសេវាកម្មធនធានដោយផ្អែកលើ ML ជាជាងច្បាប់ និងភ្នាក់ងារ (ប្រហែលជាបញ្ហាប្រឈមចម្បងឥឡូវនេះ);
• ការគាំទ្រសម្រាប់ភាសាស្គ្រីប និងតក្កវិជ្ជាបន្ថែម (ហើយវានឹងក្លាយជា JavaScript) ។

នៅក្នុងគំនិតរបស់ខ្ញុំ សំខាន់​បំផុតអ្វី​ដែល​អ្នក​បើក​យន្តហោះ​នេះ​បង្ហាញ​គឺ​មាន​រឿង​ពីរ៖

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

ប្រភព: www.habr.com