ការជំនួសថាសដោយស្វ័យប្រវត្តិជាមួយ Ansible

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

អត្ថបទ​នេះ​គឺ​ជា​ប្រភេទ​នៃ​ការ​បក​ប្រែ ការសម្តែង នៅ HighLoad+ 2018

បង្កើតដំណើរការជំនួសថាស

ដំបូងលេខមួយចំនួន

OK គឺជាសេវាកម្មដ៏ធំដែលប្រើដោយមនុស្សរាប់លាននាក់។ វាត្រូវបានបម្រើដោយម៉ាស៊ីនមេប្រហែល 7 ពាន់ដែលមានទីតាំងនៅ 4 មជ្ឈមណ្ឌលទិន្នន័យផ្សេងៗគ្នា។ ម៉ាស៊ីនមេមានថាសច្រើនជាង 70 ពាន់។ ប្រសិនបើអ្នកដាក់ពួកវាពីលើគ្នា អ្នកនឹងទទួលបានប៉មខ្ពស់លើសពី 1 គីឡូម៉ែត្រ។

ថាសរឹងគឺជាសមាសភាគម៉ាស៊ីនមេដែលបរាជ័យញឹកញាប់បំផុត។ ជាមួយនឹងបរិមាណបែបនេះ យើងត្រូវផ្លាស់ប្តូរប្រហែល 30 ថាសក្នុងមួយសប្តាហ៍ ហើយនីតិវិធីនេះបានក្លាយជាទម្លាប់ដែលមិនសូវរីករាយ។

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

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

ឧបករណ៍ផ្ទុកគឺមិនមានករណីលើកលែងនោះទេ។ ស្ថានភាពរបស់ពួកគេត្រូវបានត្រួតពិនិត្យដោយ Zabbix ។ យើងត្រួតពិនិត្យសារនៅក្នុង Syslog សម្រាប់កំហុសក្នុងការសរសេរ/អាន វិភាគស្ថានភាពនៃការវាយឆ្មក់ HW/SW តាមដាន SMART និងគណនាការពាក់សម្រាប់ SSDs។

របៀបដែលថាសត្រូវបានផ្លាស់ប្តូរពីមុន

នៅពេលដែលកេះកើតឡើងនៅក្នុង Zabbix ឧប្បត្តិហេតុមួយត្រូវបានបង្កើតឡើងនៅក្នុង Jira ហើយត្រូវបានចាត់ចែងដោយស្វ័យប្រវត្តិទៅវិស្វករដែលសមស្របនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ។ យើងធ្វើបែបនេះជាមួយឧប្បត្តិហេតុ HW ទាំងអស់ ពោលគឺ រាល់ឧប្បត្តិហេតុដែលទាមទារការងាររាងកាយជាមួយឧបករណ៍នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ។
វិស្វករមជ្ឈមណ្ឌលទិន្នន័យ គឺជាមនុស្សម្នាក់ដែលដោះស្រាយបញ្ហាទាក់ទងនឹងផ្នែករឹង និងទទួលខុសត្រូវក្នុងការដំឡើង ថែទាំ និងរុះរើម៉ាស៊ីនមេ។ ដោយបានទទួលសំបុត្រវិស្វករចូលធ្វើការ។ នៅក្នុងធ្នើរថាស គាត់ផ្លាស់ប្តូរថាសដោយឯករាជ្យ។ ប៉ុន្តែប្រសិនបើគាត់មិនមានសិទ្ធិចូលប្រើឧបករណ៍ដែលត្រូវការទេ វិស្វករងាកទៅរកអ្នកគ្រប់គ្រងប្រព័ន្ធដែលបំពេញកាតព្វកិច្ចសម្រាប់ជំនួយ។ ដំបូងអ្នកត្រូវដកថាសចេញពីការបង្វិល។ ដើម្បីធ្វើដូចនេះអ្នកត្រូវធ្វើការផ្លាស់ប្តូរចាំបាច់នៅលើម៉ាស៊ីនមេ បញ្ឈប់កម្មវិធី និងអាន់ម៉ោនថាស។

អ្នកគ្រប់គ្រងប្រព័ន្ធនៅលើកាតព្វកិច្ចទទួលខុសត្រូវចំពោះប្រតិបត្តិការនៃវិបផតថលទាំងមូលក្នុងអំឡុងពេលផ្លាស់ប្តូរការងារ។ គាត់ស៊ើបអង្កេតឧប្បត្តិហេតុ ជួសជុល និងជួយអ្នកអភិវឌ្ឍន៍បំពេញកិច្ចការតូចៗ។ គាត់មិនដោះស្រាយតែជាមួយ hard drive ទេ។

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

ប៉ុន្តែអ្វីដែលអាក្រក់បំផុតនោះគឺថា អ្នកគ្រប់គ្រងមិនបានឃើញរូបភាពទាំងមូលទេ៖ តើឧប្បត្តិហេតុថាសអ្វីខ្លះកើតឡើង ដែលបញ្ហាអាចកើតឡើង។ នេះគឺដោយសារតែការពិតដែលថាយើងផ្ទេរឧប្បត្តិហេតុ HW ទាំងអស់ទៅវិស្វករ។ បាទ/ចាស វាអាចបង្ហាញឧប្បត្តិហេតុទាំងអស់នៅលើផ្ទាំងគ្រប់គ្រងរបស់អ្នកគ្រប់គ្រង។ ប៉ុន្តែ​មាន​ច្រើន​ណាស់ ហើយ​អ្នក​គ្រប់គ្រង​បាន​ចូល​រួម​តែ​មួយ​ចំនួន​ប៉ុណ្ណោះ។

លើសពីនេះ វិស្វករមិនអាចកំណត់អាទិភាពបានត្រឹមត្រូវទេ ព្រោះគាត់មិនដឹងអ្វីសោះអំពីគោលបំណងនៃម៉ាស៊ីនមេជាក់លាក់ ឬការបែងចែកព័ត៌មានក្នុងចំណោម drives។

នីតិវិធីជំនួសថ្មី។

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

យើង​ក៏​បាន​យល់​ស្រប​ដែរ​ថា ក្នុង​អំឡុង​ពេល​ឧប្បត្តិហេតុ​មួយ យើង​នឹង​ប្តូរ​តែ​ថាស​មួយ​ប៉ុណ្ណោះ។ នេះបានសម្រួលយ៉ាងសំខាន់ដល់ដំណើរការស្វ័យប្រវត្តិកម្ម ការប្រមូលស្ថិតិ និងការងារនាពេលអនាគត។

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

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

វត្តមាននៃវាល និងការបង្ហាញរបស់ពួកគេគឺងាយស្រួល ប៉ុន្តែវាមិនបានសង្គ្រោះយើងពីតម្រូវការក្នុងការប្រើការជជែកនោះទេ។ ដើម្បីធ្វើដូច្នេះ យើងត្រូវផ្លាស់ប្តូរលំហូរការងារ។

ពីមុនវាដូចនេះ៖

នេះជារបៀបដែលវិស្វករបន្តធ្វើការនៅថ្ងៃនេះ នៅពេលដែលពួកគេមិនត្រូវការជំនួយពីអ្នកគ្រប់គ្រង។

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

យើងក៏បានបន្ថែមស្ថានភាពផងដែរ។ រួចរាល់ហើយ. សំបុត្រត្រូវបានផ្ទេរទៅវាបន្ទាប់ពីជំនួសថាស។ នោះគឺ អ្វីគ្រប់យ៉ាងត្រូវបានធ្វើរួច ប៉ុន្តែ HW/SW RAID ត្រូវបានធ្វើសមកាលកម្មនៅលើម៉ាស៊ីនមេ។ នេះអាចចំណាយពេលយូរ។

ប្រសិនបើអ្នកគ្រប់គ្រងចូលរួមក្នុងការងារនោះ គ្រោងការណ៍នឹងកាន់តែស្មុគស្មាញបន្តិច។

ពីស្ថានភាព បើកទូលាយ សំបុត្រអាចត្រូវបានបកប្រែដោយទាំងអ្នកគ្រប់គ្រងប្រព័ន្ធ និងវិស្វករ។ នៅក្នុងស្ថានភាព កំពុង​ដំណើរការ អ្នកគ្រប់គ្រងដកថាសចេញពីការបង្វិល ដូច្នេះវិស្វករអាចទាញវាចេញបានដោយសាមញ្ញ៖ បើកអំពូល Backlight ដកឌីស បញ្ឈប់កម្មវិធី អាស្រ័យលើក្រុមជាក់លាក់នៃម៉ាស៊ីនមេ។

បន្ទាប់មកសំបុត្រត្រូវបានផ្ទេរទៅ រួចរាល់ក្នុងការផ្លាស់ប្តូរ៖ នេះជាសញ្ញាប្រាប់វិស្វករថាថាសអាចត្រូវបានទាញចេញ។ វាលទាំងអស់នៅក្នុង Jira ត្រូវបានបំពេញរួចហើយ វិស្វករដឹងពីប្រភេទ និងទំហំរបស់ថាស។ ទិន្នន័យនេះត្រូវបានបញ្ចូលដោយស្វ័យប្រវត្តិនៅលើស្ថានភាពមុន ឬដោយអ្នកគ្រប់គ្រង។

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

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

មិនចាំបាច់ជជែកទេ។ ជាការពិតណាស់ អ្នកគ្រប់គ្រងអាចសរសេរទៅកាន់វិស្វករថា "វាត្រូវជំនួសអោយលឿនជាងមុន" ឬ "វាល្ងាចហើយ តើអ្នកមានពេលជំនួសវាទេ?" ប៉ុន្តែ​យើង​លែង​ទាក់ទង​គ្នា​ជា​រៀង​រាល់​ថ្ងៃ​ក្នុង​ការ​ជជែក​អំពី​បញ្ហា​ទាំង​នេះ។

ថាសចាប់ផ្តើមត្រូវបានផ្លាស់ប្តូរជាបាច់។ ប្រសិនបើអ្នកគ្រប់គ្រងមកធ្វើការលឿនបន្តិច គាត់មានពេលទំនេរ ហើយគ្មានអ្វីកើតឡើងទេ គាត់អាចរៀបចំម៉ាស៊ីនមេមួយចំនួនសម្រាប់ជំនួស៖ បំពេញវាល ដកថាសចេញពីការបង្វិល និងផ្ទេរភារកិច្ចទៅវិស្វករ។ វិស្វករមកដល់មជ្ឈមណ្ឌលទិន្នន័យបន្តិចក្រោយមក ឃើញកិច្ចការ យកដ្រាយចាំបាច់ចេញពីឃ្លាំង ហើយជំនួសពួកគេភ្លាមៗ។ ជាលទ្ធផលអត្រាជំនួសបានកើនឡើង។

មេរៀនដែលបានរៀននៅពេលបង្កើតលំហូរការងារ

• នៅពេលសាងសង់នីតិវិធីអ្នកត្រូវប្រមូលព័ត៌មានពីប្រភពផ្សេងៗគ្នា។
  អ្នកគ្រប់គ្រងមួយចំនួនរបស់យើងមិនបានដឹងថាវិស្វករផ្លាស់ប្តូរឌីសដោយខ្លួនឯងទេ។ មនុស្សមួយចំនួនគិតថាការធ្វើសមកាលកម្ម MD RAID ត្រូវបានគ្រប់គ្រងដោយវិស្វករ ទោះបីជាពួកគេខ្លះមិនមានលទ្ធភាពធ្វើដូច្នេះក៏ដោយ។ វិស្វករឈានមុខគេមួយចំនួនបានធ្វើរឿងនេះ ប៉ុន្តែមិនតែងតែដោយសារតែដំណើរការនេះមិនត្រូវបានពិពណ៌នានៅគ្រប់ទីកន្លែង។
• នីតិវិធីគួរតែសាមញ្ញនិងអាចយល់បាន។
  វាពិបាកសម្រាប់មនុស្សម្នាក់ក្នុងការរក្សាជំហានជាច្រើនក្នុងចិត្ត។ ស្ថានភាពជិតខាងដ៏សំខាន់បំផុតនៅក្នុង Jira គួរតែត្រូវបានដាក់នៅលើអេក្រង់មេ។ អ្នក​អាច​ប្តូរ​ឈ្មោះ​ពួកវា​ជា​ឧទាហរណ៍ យើង​ហៅ​ថា​កំពុង​ដំណើរការ​រួចរាល់​ក្នុង​ការ​ផ្លាស់ប្តូរ។ ហើយស្ថានភាពផ្សេងទៀតអាចត្រូវបានលាក់នៅក្នុងម៉ឺនុយទម្លាក់ចុះ ដើម្បីកុំឱ្យវាឈឺភ្នែក។ ប៉ុន្តែវាជាការប្រសើរជាងកុំកំណត់មនុស្ស ដើម្បីផ្តល់ឱកាសឱ្យពួកគេធ្វើការផ្លាស់ប្តូរ។
  ពន្យល់ពីតម្លៃនៃការច្នៃប្រឌិត។ នៅពេលដែលមនុស្សយល់ ពួកគេកាន់តែទទួលយកនីតិវិធីថ្មី។ វាមានសារៈសំខាន់ខ្លាំងណាស់សម្រាប់យើងដែលមនុស្សមិនចុចតាមរយៈដំណើរការទាំងមូល ប៉ុន្តែធ្វើតាមវា។ បន្ទាប់មកយើងបង្កើតស្វ័យប្រវត្តិកម្មលើបញ្ហានេះ។
• រង់ចាំ, វិភាគ, ដោះស្រាយវា។
  យើង​ចំណាយ​ពេល​ប្រហែល​មួយ​ខែ​ដើម្បី​កសាង​នីតិវិធី ការអនុវត្ត​បច្ចេកទេស កិច្ចប្រជុំ និង​ការពិភាក្សា។ ហើយការអនុវត្តត្រូវចំណាយពេលលើសពីបីខែ។ ខ្ញុំបានឃើញពីរបៀបដែលមនុស្សចាប់ផ្តើមប្រើការច្នៃប្រឌិតបន្តិចម្តងៗ។ មានភាពអវិជ្ជមានច្រើននៅដំណាក់កាលដំបូង។ ប៉ុន្តែ​វា​ឯករាជ្យ​ទាំងស្រុង​ពី​នីតិវិធី​ខ្លួន​វា និង​ការអនុវត្ត​បច្ចេកទេស​។ ជាឧទាហរណ៍ អ្នកគ្រប់គ្រងម្នាក់មិនបានប្រើ Jira ទេ ប៉ុន្តែកម្មវិធីជំនួយ Jira នៅក្នុង Confluence ហើយរបស់ខ្លះមិនមានសម្រាប់គាត់ទេ។ យើងបានបង្ហាញគាត់ Jira ហើយផលិតភាពរបស់អ្នកគ្រប់គ្រងបានកើនឡើងទាំងសម្រាប់កិច្ចការទូទៅ និងសម្រាប់ការជំនួសថាស។

ស្វ័យប្រវត្តិកម្មនៃការជំនួសថាស

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

ដោយសារឥឡូវនេះដំណើរការជំនួសរបស់យើងត្រូវបានបែងចែកទៅជាដំណាក់កាល ដែលនីមួយៗមានអ្នកសំដែងជាក់លាក់ និងបញ្ជីសកម្មភាព យើងអាចបើកដំណើរការស្វ័យប្រវត្តិជាដំណាក់កាល ហើយមិនមែនទាំងអស់ក្នុងពេលតែមួយនោះទេ។ ឧទាហរណ៍ ដំណាក់កាលសាមញ្ញបំផុត - រួចរាល់ (ពិនិត្យមើល RAID/ការធ្វើសមកាលកម្មទិន្នន័យ) អាចត្រូវបានផ្ទេរយ៉ាងងាយស្រួលទៅ bot ។ នៅពេលដែល bot បានរៀនតិចតួច អ្នកអាចផ្តល់ឱ្យវានូវកិច្ចការសំខាន់ជាងនេះ - ការដាក់ថាសចូលទៅក្នុងការបង្វិល។ល។

ការរៀបចំសួនសត្វ

មុន​នឹង​យើង​និយាយ​អំពី​រូបយន្ត​នេះ សូម​ធ្វើ​ដំណើរ​កម្សាន្ត​ខ្លី​មួយ​ក្នុង​សួន​សត្វ​នៃ​ការ​ដំឡើង​របស់​យើង។ ជាដំបូង វាគឺដោយសារតែទំហំដ៏ធំសម្បើមនៃហេដ្ឋារចនាសម្ព័ន្ធរបស់យើង។ ទីពីរ យើងព្យាយាមជ្រើសរើសការកំណត់រចនាសម្ព័ន្ធផ្នែករឹងល្អបំផុតសម្រាប់សេវាកម្មនីមួយៗ។ យើងមានម៉ូដែល Hardware RAID ប្រហែល 20 ដែលភាគច្រើនជា LSI និង Adaptec ប៉ុន្តែក៏មាន HP និង DELL នៃកំណែផ្សេងៗគ្នាផងដែរ។ ឧបករណ៍បញ្ជា RAID នីមួយៗមានឧបករណ៍គ្រប់គ្រងផ្ទាល់ខ្លួន។ សំណុំនៃពាក្យបញ្ជា និងការចេញពួកវាអាចខុសគ្នាពីកំណែមួយទៅកំណែសម្រាប់ឧបករណ៍បញ្ជា RAID នីមួយៗ។ កន្លែងដែល HW-RAID មិនត្រូវបានប្រើ mdraid អាចត្រូវបានប្រើប្រាស់។

យើងធ្វើការដំឡើងថ្មីស្ទើរតែទាំងអស់ដោយគ្មានការបម្រុងទុកថាស។ យើងព្យាយាមលែងប្រើ Hardware និង Software RAID ទៀតហើយ ដោយសារយើងបម្រុងទុកប្រព័ន្ធរបស់យើងនៅកម្រិតមជ្ឈមណ្ឌលទិន្នន័យ មិនមែនម៉ាស៊ីនមេទេ។ ប៉ុន្តែជាការពិតណាស់ មានម៉ាស៊ីនមេចាស់ជាច្រើនដែលចាំបាច់ត្រូវគាំទ្រ។

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

សរុបមក យើងមានក្រុមម៉ាស៊ីនមេពិសេសជាង 400 ដែលដំណើរការជិត 100 កម្មវិធីផ្សេងៗគ្នា។ ដើម្បីគ្របដណ្តប់ជម្រើសដ៏ច្រើនបែបនេះ យើងត្រូវការឧបករណ៍ស្វ័យប្រវត្តិកម្មពហុមុខងារ។ និយមជាមួយ DSL សាមញ្ញ ដូច្នេះមិនត្រឹមតែអ្នកដែលសរសេរវាទេដែលអាចគាំទ្រវាបាន។

យើងជ្រើសរើស Ansible ព្រោះវាគ្មានភ្នាក់ងារ៖ មិនចាំបាច់រៀបចំហេដ្ឋារចនាសម្ព័ន្ធ ការចាប់ផ្តើមរហ័ស។ លើសពីនេះទៀតវាត្រូវបានសរសេរនៅក្នុង Python ដែលត្រូវបានទទួលយកជាស្តង់ដារនៅក្នុងក្រុម។

គ្រោងការណ៍ទូទៅ

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

កម្មវិធី DiskoBot ដែលសរសេរជាភាសា Python តែងតែធ្វើការស្ទង់មតិ Jira សម្រាប់សំបុត្រថ្មី។ វាកត់សំគាល់ថាសំបុត្រដែលកំពុងដំណើរការថ្មីបានបង្ហាញខ្លួន ខ្សែដែលត្រូវគ្នាត្រូវបានកេះ ដែលបើកដំណើរការសៀវភៅលេងនៅក្នុង Ansible (វាត្រូវបានធ្វើសម្រាប់ស្ថានភាពនីមួយៗនៅក្នុង Jira)។ ក្នុងករណីនេះ Prepare2change ត្រូវបានបើកដំណើរការ។

Ansible ត្រូវបានផ្ញើទៅកាន់ម៉ាស៊ីន យកថាសចេញពីការបង្វិល ហើយរាយការណ៍ពីស្ថានភាពទៅកម្មវិធីតាមរយៈ Callbacks។

ដោយផ្អែកលើលទ្ធផល bot ផ្ទេរសំបុត្រដោយស្វ័យប្រវត្តិទៅ Ready to change ។ វិស្វករ​ទទួល​បាន​ការ​ជូន​ដំណឹង​ហើយ​ទៅ​ផ្លាស់​ប្តូរ​ថាស បន្ទាប់​មក​គាត់​ផ្ទេរ​សំបុត្រ​ទៅ​ផ្លាស់​ប្តូរ។

យោងតាមគ្រោងការណ៍ដែលបានពិពណ៌នាខាងលើ សំបុត្រត្រលប់ទៅ bot ដែលបើកដំណើរការសៀវភៅលេងមួយផ្សេងទៀតទៅម៉ាស៊ីនហើយដាក់ថាសទៅជាការបង្វិល។ bot បិទសំបុត្រ។ ហ៊ឺយ!

ឥឡូវនេះសូមនិយាយអំពីសមាសធាតុមួយចំនួននៃប្រព័ន្ធ។

ឌីស្កូបូត

កម្មវិធីនេះត្រូវបានសរសេរនៅក្នុង Python ។ វាជ្រើសរើសសំបុត្រពី Jira យោងទៅតាម JQL ។ អាស្រ័យលើស្ថានភាពនៃសំបុត្រ ក្រោយមកទៀតទៅកាន់អ្នកដោះស្រាយដែលត្រូវគ្នា ដែលនៅក្នុងវេនបើកដំណើរការ Ansible playbook ដែលត្រូវនឹងស្ថានភាព។

JQL និងចន្លោះពេលបោះឆ្នោតត្រូវបានកំណត់នៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធកម្មវិធី។

jira_states:
  investigate:
    jql: '… status = Open and "Disk Size" is EMPTY'
    interval: 180

  inprogress:
    jql: '…  and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
 
  ready:
    jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
    interval: 7200

ឧទាហរណ៍ ក្នុង​ចំណោម​សំបុត្រ​ក្នុង​ស្ថានភាព​កំពុង​ដំណើរការ មាន​តែ​ប្រអប់​ដែល​មាន​ទំហំ​ថាស និង​ឈ្មោះ​ឧបករណ៍​ដែល​បាន​បំពេញ​ប៉ុណ្ណោះ​ត្រូវ​បាន​ជ្រើសរើស។ ឈ្មោះឧបករណ៍គឺជាឈ្មោះឧបករណ៍ប្លុកដែលត្រូវការដើម្បីប្រតិបត្តិសៀវភៅលេង។ ទំហំថាសគឺត្រូវការដើម្បីឱ្យវិស្វករដឹងថាទំហំថាសដែលត្រូវការ។

ហើយក្នុងចំណោមសំបុត្រដែលមានស្ថានភាពរួចរាល់ សំបុត្រដែលមានស្លាក dbot_ignore ត្រូវបានច្រោះចេញ។ ដោយវិធីនេះ យើងប្រើស្លាក Jira ទាំងសម្រាប់ការត្រងបែបនេះ និងសម្រាប់ការសម្គាល់សំបុត្រស្ទួន និងការប្រមូលស្ថិតិ។

ប្រសិនបើសៀវភៅលេងបរាជ័យ Jira កំណត់ស្លាក dbot_failed ដូច្នេះវាអាចត្រូវបានតម្រៀបចេញនៅពេលក្រោយ។

អន្តរប្រតិបត្តិការជាមួយ Ansible

កម្មវិធីទំនាក់ទំនងជាមួយ Ansible តាមរយៈ Ansible Python API. ដើម្បី playbook_executor យើងហុចឈ្មោះឯកសារ និងសំណុំនៃអថេរមួយ។ នេះអនុញ្ញាតឱ្យអ្នករក្សាគម្រោង Ansible ជាទម្រង់ឯកសារ yml ធម្មតា ជាជាងការពិពណ៌នាវានៅក្នុងកូដ Python ។

ផងដែរនៅក្នុង Ansible តាមរយៈ *extra_vars* ឈ្មោះឧបករណ៍ទប់ស្កាត់ ស្ថានភាពសំបុត្រ ក៏ដូចជា callback_url ដែលមានលេខសោបញ្ហា - វាត្រូវបានប្រើសម្រាប់ការហៅត្រឡប់មកវិញនៅក្នុង HTTP ។

សម្រាប់ការបើកដំណើរការនីមួយៗ បញ្ជីសារពើភណ្ឌបណ្តោះអាសន្នត្រូវបានបង្កើត ដែលរួមមានម៉ាស៊ីនមួយ និងក្រុមដែលម៉ាស៊ីននេះជាកម្មសិទ្ធិ ដូច្នេះ group_vars ត្រូវបានអនុវត្ត។

នេះគឺជាឧទាហរណ៍នៃកិច្ចការដែលអនុវត្តការហៅត្រឡប់ HTTP ។

យើងទទួលបានលទ្ធផលនៃការប្រតិបត្តិសៀវភៅលេងដោយប្រើ callaback(s)។ ពួកវាមានពីរប្រភេទ៖

• កម្មវិធីជំនួយការហៅត្រឡប់មកវិញដែលអាចប្រើបានវាផ្តល់ទិន្នន័យលើលទ្ធផលនៃការប្រតិបត្តិសៀវភៅ។ វាពិពណ៌នាអំពីកិច្ចការដែលត្រូវបានចាប់ផ្តើម បញ្ចប់ដោយជោគជ័យ ឬមិនបានជោគជ័យ។ ការហៅត្រឡប់មកវិញនេះត្រូវបានហៅនៅពេលដែលសៀវភៅលេងបានបញ្ចប់ការលេង។
• ការហៅត្រឡប់ HTTP ដើម្បីទទួលបានព័ត៌មានពេលកំពុងលេងសៀវភៅលេង។ នៅក្នុងកិច្ចការ Ansible យើងប្រតិបត្តិសំណើ POST/GET ទៅកាន់កម្មវិធីរបស់យើង។

អថេរត្រូវបានឆ្លងកាត់ HTTP callback(s) ដែលត្រូវបានកំណត់កំឡុងពេលប្រតិបត្តិនៃ playbook ហើយដែលយើងចង់រក្សាទុក និងប្រើប្រាស់ក្នុងការដំណើរការជាបន្តបន្ទាប់។ យើងសរសេរទិន្នន័យនេះក្នុង sqlite ។

យើងក៏ទុកមតិយោបល់ និងផ្លាស់ប្តូរស្ថានភាពសំបុត្រតាមរយៈការហៅត្រឡប់ HTTP ផងដែរ។

ការហៅត្រឡប់ HTTP

# Make callback to Diskobot App
# Variables:
#    callback_post_body: # A dict with follow keys. All keys are optional
#       msg: If exist it would be posted to Jira as comment
#       data: If exist it would be saved in Incident.variables
#       desire_state: Set desire_state for incident
#       status: If exist Proceed issue to that status

  - name: Callback to Diskobot app (jira comment/status)
    uri:
      url: "{{ callback_url }}/{{ devname }}"
      user: "{{ diskobot_user }}"
      password: "{{ diskobot_pass }}"
      force_basic_auth: True
      method: POST
      body: "{{ callback_post_body | to_json }}"
      body_format: json
    delegate_to: 127.0.0.1

ដូចកិច្ចការជាច្រើនដែលមានប្រភេទដូចគ្នា យើងដាក់វានៅក្នុងឯកសារទូទៅដាច់ដោយឡែក ហើយបញ្ចូលវាប្រសិនបើចាំបាច់ ដើម្បីកុំឱ្យវាកើតឡើងដដែលៗនៅក្នុងសៀវភៅលេង។ នេះរួមបញ្ចូលទាំង callback_ url ដែលមានលេខកូដបញ្ហា និងឈ្មោះម៉ាស៊ីន។ នៅពេលដែល Ansible ប្រតិបត្តិសំណើ POST នេះ bot យល់ថាវាបានមកជាផ្នែកមួយនៃឧប្បត្តិហេតុបែបនេះ។

ហើយនេះគឺជាឧទាហរណ៍ពីសៀវភៅលេង ដែលយើងបញ្ចេញថាសពីឧបករណ៍ MD៖

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

កិច្ចការនេះផ្ទេរសំបុត្រ Jira ទៅស្ថានភាព "រួចរាល់ក្នុងការផ្លាស់ប្តូរ" ហើយបន្ថែមមតិយោបល់។ ផងដែរ អថេរ mdam_data រក្សាទុកបញ្ជីឧបករណ៍ md ដែលថាសត្រូវបានដកចេញ ហើយ parted_info រក្សាទុកការបោះចោលភាគថាសពីការបំបែក។

នៅពេលដែលវិស្វករបញ្ចូលឌីសថ្មី យើងអាចប្រើអថេរទាំងនេះដើម្បីស្ដារការបោះចោលភាគថាស ក៏ដូចជាបញ្ចូលថាសទៅក្នុងឧបករណ៍ md ដែលវាត្រូវបានដកចេញ។

របៀបពិនិត្យដែលអាចប្រើបាន

វាគួរឱ្យខ្លាចក្នុងការបើកស្វ័យប្រវត្តិកម្ម។ ដូច្នេះហើយ យើងបានសម្រេចចិត្តដំណើរការសៀវភៅលេងទាំងអស់នៅក្នុងរបៀប
ការរត់ស្ងួតដែលក្នុងនោះ Ansible មិនអនុវត្តសកម្មភាពណាមួយនៅលើម៉ាស៊ីនមេទេ ប៉ុន្តែគ្រាន់តែត្រាប់តាមពួកគេ។

ការបើកដំណើរការបែបនេះគឺដំណើរការតាមរយៈម៉ូឌុលហៅត្រឡប់មកវិញដាច់ដោយឡែក ហើយលទ្ធផលនៃការប្រតិបត្តិសៀវភៅលេងត្រូវបានរក្សាទុកក្នុង Jira ជាមតិយោបល់។

ទីមួយ វាបានធ្វើឱ្យវាអាចផ្ទៀងផ្ទាត់ការងាររបស់ bot និង playbooks។ ទីពីរ វាបង្កើនទំនុកចិត្តរបស់អ្នកគ្រប់គ្រងលើរូបយន្ត។

នៅពេលដែលយើងឆ្លងកាត់ការបញ្ជាក់ហើយដឹងថាអ្នកអាចដំណើរការ Ansible មិនត្រឹមតែនៅក្នុងរបៀបស្ងួតប៉ុណ្ណោះទេ យើងបានបង្កើតប៊ូតុង Run Diskobot នៅក្នុង Jira ដើម្បីបើកដំណើរការសៀវភៅលេងដូចគ្នាជាមួយនឹងអថេរដូចគ្នានៅលើម៉ាស៊ីនដូចគ្នា ប៉ុន្តែនៅក្នុងរបៀបធម្មតា។

លើសពីនេះ ប៊ូតុងនេះត្រូវបានប្រើដើម្បីចាប់ផ្តើមសៀវភៅលេងឡើងវិញប្រសិនបើវាគាំង។

រចនាសម្ព័ន្ធសៀវភៅលេង

ខ្ញុំបាននិយាយរួចមកហើយថា អាស្រ័យលើស្ថានភាពនៃសំបុត្រ Jira, bot បើកដំណើរការសៀវភៅលេងផ្សេងៗ។

ទីមួយ វាកាន់តែងាយស្រួលក្នុងការរៀបចំច្រកចូល។
ទីពីរ ក្នុងករណីខ្លះវាចាំបាច់ណាស់។

ឧទាហរណ៍ នៅពេលជំនួសថាសប្រព័ន្ធ ដំបូងអ្នកត្រូវចូលទៅកាន់ប្រព័ន្ធដាក់ពង្រាយ បង្កើតភារកិច្ច ហើយបន្ទាប់ពីការដាក់ឱ្យត្រឹមត្រូវ នោះម៉ាស៊ីនមេនឹងអាចចូលប្រើបានតាមរយៈ ssh ហើយអ្នកអាចដាក់កម្មវិធីនៅលើវាបាន។ ប្រសិនបើយើងធ្វើអ្វីៗទាំងអស់នេះក្នុងសៀវភៅលេងតែមួយ នោះ Ansible នឹងមិនអាចបំពេញវាបានទេ ដោយសារម៉ាស៊ីនមិនអាចប្រើបាន។

យើងប្រើតួនាទី Ansible សម្រាប់ក្រុមនីមួយៗនៃម៉ាស៊ីនមេ។ នៅទីនេះអ្នកអាចមើលឃើញពីរបៀបដែលសៀវភៅលេងត្រូវបានរៀបចំនៅក្នុងមួយក្នុងចំណោមពួកគេ។

នេះ​ជា​ការ​ងាយ​ស្រួល​ព្រោះ​វា​ច្បាស់​ភ្លាម​ថា​តើ​កិច្ចការ​ណា​មាន​ទីតាំង។ នៅក្នុង main.yml ដែលជាការបញ្ចូលសម្រាប់តួនាទី Ansible យើងអាចរួមបញ្ចូលដោយស្ថានភាពសំបុត្រ ឬកិច្ចការទូទៅដែលទាមទារសម្រាប់មនុស្សគ្រប់គ្នា ឧទាហរណ៍ ការឆ្លងកាត់អត្តសញ្ញាណ ឬទទួលសញ្ញាសម្ងាត់។

ការស៊ើបអង្កេត.yml

ដំណើរការសម្រាប់សំបុត្រក្នុងស្ថានភាពស៊ើបអង្កេត និងបើក។ អ្វីដែលសំខាន់បំផុតសម្រាប់សៀវភៅលេងនេះគឺឈ្មោះឧបករណ៍ប្លុក។ ព័ត៌មាននេះមិនតែងតែមានទេ។

ដើម្បីទទួលបានវា យើងវិភាគការសង្ខេប Jira ដែលជាតម្លៃចុងក្រោយពីគន្លឹះ Zabbix ។ វាអាចមានឈ្មោះឧបករណ៍ប្លុក - សំណាង។ ឬវាអាចមានចំណុចម៉ោន បន្ទាប់មកអ្នកត្រូវចូលទៅកាន់ម៉ាស៊ីនមេ ញែកវា និងគណនាថាសដែលត្រូវការ។ កេះក៏អាចបញ្ជូនអាសយដ្ឋាន scsi ឬព័ត៌មានមួយចំនួនផ្សេងទៀតផងដែរ។ ប៉ុន្តែវាក៏កើតឡើងផងដែរដែលមិនមានតម្រុយហើយអ្នកត្រូវវិភាគ។

ដោយបានរកឃើញឈ្មោះឧបករណ៍ប្លុក យើងប្រមូលព័ត៌មានអំពីប្រភេទ និងទំហំនៃថាសពីវា ដើម្បីបំពេញវាលនៅក្នុង Jira ។ យើងក៏ដកព័ត៌មានអំពីអ្នកលក់ ម៉ូដែល កម្មវិធីបង្កប់ លេខសម្គាល់ SMART ហើយបញ្ចូលទាំងអស់នេះទៅក្នុងមតិយោបល់នៅក្នុងសំបុត្រ Jira ។ អ្នកគ្រប់គ្រង និងវិស្វករមិនចាំបាច់ស្វែងរកទិន្នន័យនេះទៀតទេ។ 🙂

រៀបចំ2change.yml

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

ក្នុងករណីសាមញ្ញបំផុត យើងកំពុងនិយាយអំពីការដកថាសចេញពី HW/MD RAID ។

នៅក្នុងស្ថានភាពស្មុគ្រស្មាញកាន់តែច្រើន (នៅក្នុងប្រព័ន្ធផ្ទុកទិន្នន័យរបស់យើង) នៅពេលដែលការបម្រុងទុកត្រូវបានអនុវត្តនៅកម្រិតកម្មវិធី អ្នកត្រូវចូលទៅកាន់កម្មវិធីតាមរយៈ API រាយការណ៍ពីលទ្ធផលឌីស បិទដំណើរការវា ហើយចាប់ផ្តើមការសង្គ្រោះ។

ឥឡូវនេះយើងកំពុងធ្វើចំណាកស្រុកដ៏ធំទៅ ពពកហើយប្រសិនបើម៉ាស៊ីនមេមានមូលដ្ឋានលើពពក នោះ Diskobot ហៅ Cloud API និយាយថាវានឹងដំណើរការជាមួយមីនីននេះ ដែលជាម៉ាស៊ីនមេដែលកំពុងដំណើរការកុងតឺន័រ ហើយសួរថា "ផ្ទេរកុងតឺន័រទាំងអស់ពីមីនីននេះ"។ ហើយក្នុងពេលជាមួយគ្នានេះ បើកអំពូល Backlight របស់ឌីស ដើម្បីឱ្យវិស្វករអាចមើលឃើញភ្លាមៗថាតើមួយណាត្រូវទាញចេញ។

បានផ្លាស់ប្តូរ.yml

បន្ទាប់ពីជំនួសថាសមួយ យើងពិនិត្យមើលភាពអាចរកបានរបស់វាជាមុនសិន។

វិស្វករមិនតែងតែដំឡើងដ្រាយវ៍ថ្មីទេ ដូច្នេះយើងបានបន្ថែមការត្រួតពិនិត្យតម្លៃ SMART ដែលបំពេញចិត្តយើង។

តើ​យើង​កំពុង​មើល​លក្ខណៈ​អ្វី​ខ្លះ?ចំនួនផ្នែកដែលបានផ្លាស់ប្តូរទីតាំង (5) < 100
ចំនួនផ្នែកដែលកំពុងរង់ចាំបច្ចុប្បន្ន (107) == 0

ប្រសិនបើការសាកល្បងបរាជ័យ វិស្វករត្រូវបានជូនដំណឹងដើម្បីជំនួសវាម្តងទៀត។ ប្រសិនបើអ្វីៗគ្រប់យ៉ាងស្ថិតក្នុងសណ្តាប់ធ្នាប់ អំពូល Backlight នឹងបិទ ការសម្គាល់ត្រូវបានអនុវត្ត ហើយឌីសត្រូវបានដាក់ចូលទៅក្នុងការបង្វិល។

ready.yml

ករណីសាមញ្ញបំផុត៖ ពិនិត្យមើលការធ្វើសមកាលកម្មការវាយឆ្មក់ HW/SW ឬបញ្ចប់ការធ្វើសមកាលកម្មទិន្នន័យនៅក្នុងកម្មវិធី។

API កម្មវិធី

ខ្ញុំបានលើកឡើងជាច្រើនដងថា bot ចូលប្រើ APIs កម្មវិធីជាញឹកញាប់។ ជាការពិតណាស់ មិនមែនគ្រប់កម្មវិធីទាំងអស់សុទ្ធតែមានវិធីសាស្រ្តចាំបាច់នោះទេ ដូច្នេះពួកគេត្រូវតែកែប្រែ។ នេះគឺជាវិធីសាស្ត្រសំខាន់ៗដែលយើងប្រើ៖

• ស្ថានភាព។ ស្ថានភាពនៃចង្កោម ឬថាស ដើម្បីយល់ថាតើវាអាចត្រូវបានធ្វើការជាមួយ;
• ចាប់ផ្តើម / បញ្ឈប់។ ការធ្វើឱ្យសកម្ម / ការធ្វើឱ្យសកម្មថាស;
• ផ្ទេរ/ស្តារ។ ការផ្ទេរទិន្នន័យ និងការស្តារឡើងវិញក្នុងអំឡុងពេល និងបន្ទាប់ពីការជំនួស។

មេរៀនដែលបានរៀនពី Ansible

ខ្ញុំពិតជាស្រឡាញ់ Ansible ។ ប៉ុន្តែជាញឹកញយ ពេលខ្ញុំមើលគម្រោងប្រភពបើកចំហផ្សេងៗ និងមើលពីរបៀបដែលមនុស្សសរសេរសៀវភៅលេង ខ្ញុំមានការភ័យខ្លាចបន្តិច។ ការ​ត្បាញ​តក្កវិជ្ជា​ស្មុគ្រស្មាញ​នៃ​ពេល/រង្វិលជុំ កង្វះ​ភាព​បត់បែន និង​ភាព​គ្មាន​សមត្ថភាព​ដោយសារ​ការ​ប្រើ​សែល/ពាក្យ​បញ្ជា​ញឹកញាប់។

យើងបានសម្រេចចិត្តធ្វើឱ្យអ្វីៗទាំងអស់មានលក្ខណៈសាមញ្ញតាមដែលអាចធ្វើទៅបាន ដោយទាញយកអត្ថប្រយោជន៍ពី Ansible - modularity ។ នៅកម្រិតខ្ពស់បំផុតមានសៀវភៅលេង ពួកវាអាចត្រូវបានសរសេរដោយអ្នកគ្រប់គ្រងណាមួយ អ្នកអភិវឌ្ឍន៍ភាគីទីបីដែលដឹងតិចតួចអំពី Ansible ។

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

ប្រសិនបើតក្កវិជ្ជាមួយចំនួនពិបាកអនុវត្តនៅក្នុងសៀវភៅលេង យើងផ្លាស់ទីវាទៅក្នុងម៉ូឌុល Ansible ឬតម្រង។ ស្គ្រីបអាចត្រូវបានសរសេរជាភាសា Python ឬភាសាផ្សេងទៀត។

ពួកគេងាយស្រួលនិងរហ័សក្នុងការសរសេរ។ ឧទាហរណ៍ ម៉ូឌុល backlight ឌីស ជាឧទាហរណ៍ដែលត្រូវបានបង្ហាញខាងលើ មាន 265 បន្ទាត់។

នៅកម្រិតទាបបំផុតគឺបណ្ណាល័យ។ សម្រាប់គម្រោងនេះ យើងបានសរសេរកម្មវិធីដាច់ដោយឡែកមួយ ប្រភេទនៃការអរូបីលើ Hardware និង Software RAIDs ដែលអនុវត្តសំណើដែលត្រូវគ្នា។

ចំណុចខ្លាំងបំផុតរបស់ Ansible គឺភាពសាមញ្ញ និងសៀវភៅលេងច្បាស់លាស់។ ខ្ញុំជឿថាអ្នកត្រូវប្រើវា និងមិនបង្កើតឯកសារ yaml គួរឱ្យខ្លាច និងលក្ខខណ្ឌមួយចំនួនធំ លេខកូដសែល និងរង្វិលជុំ។

ប្រសិនបើអ្នកចង់ធ្វើបទពិសោធន៍របស់យើងម្តងទៀតជាមួយ Ansible API សូមចងចាំរឿងពីរយ៉ាង៖

• Playbook_executor និង playbooks ជាទូទៅមិនអាចត្រូវបានផ្តល់ឱ្យអស់ពេលទេ។ មានការអស់ពេលនៅលើវគ្គ ssh ប៉ុន្តែមិនមានការអស់ពេលនៅលើសៀវភៅលេងទេ។ ប្រសិនបើយើងព្យាយាមផ្ដាច់ថាសដែលលែងមាននៅក្នុងប្រព័ន្ធនោះ សៀវភៅលេងនឹងដំណើរការដោយគ្មានទីបញ្ចប់ ដូច្នេះយើងត្រូវរុំការបើកដំណើរការរបស់វានៅក្នុងរុំដាច់ដោយឡែក ហើយសម្លាប់វាដោយអស់ពេល។
• Ansible ដំណើរការលើដំណើរការ forked ដូច្នេះ API របស់វាមិនមានសុវត្ថិភាពខ្សែស្រឡាយទេ។ យើងដំណើរការសៀវភៅលេងរបស់យើងទាំងអស់ដែលមានខ្សែតែមួយ។

ជាលទ្ធផល យើងអាចធ្វើការជំនួសថាសបានប្រហែល 80% ដោយស្វ័យប្រវត្តិ។ សរុបមក អត្រាជំនួសបានកើនឡើងទ្វេដង។ ថ្ងៃនេះអ្នកគ្រប់គ្រងគ្រាន់តែមើលឧប្បត្តិហេតុហើយសម្រេចចិត្តថាតើឌីសត្រូវផ្លាស់ប្តូរឬអត់ហើយចុចតែម្តង។

ប៉ុន្តែឥឡូវនេះយើងចាប់ផ្តើមមានបញ្ហាមួយទៀត៖ អ្នកគ្រប់គ្រងថ្មីមួយចំនួនមិនដឹងពីរបៀបផ្លាស់ប្តូរដ្រាយវ៍។ 🙂

ប្រភព: www.habr.com