វិធីសាស្រ្តករណី៖ ការត្រួតពិនិត្យមនុស្ស

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

ស្វែងយល់ពីទស្សនវិជ្ជាត្រួតពិនិត្យ ដែលកើតមកក្នុងរយៈពេលជាច្រើនទសវត្សរ៍នៃភារកិច្ចរបស់ខ្ញុំនៅក្នុងក្រុមត្រួតពិនិត្យផ្សេងៗគ្នា។ នាងត្រូវបានទទួលឥទ្ធិពលយ៉ាងទូលំទូលាយដោយព្រះគម្ពីរពិតពី Rob Evashchuk ទស្សនវិជ្ជារបស់ខ្ញុំលើការដាស់តឿន (ទស្សនវិជ្ជាការជូនដំណឹងរបស់ខ្ញុំ) រួមបញ្ចូលនៅក្នុងសៀវភៅស្តីពី Google SREនិងសៀវភៅដោយ John Alspaugh ការពិចារណាសម្រាប់ការរចនាការជូនដំណឹង (កំណត់ចំណាំលើការដំឡើងការជូនដំណឹង)។

ខេលី ដុន, Arijit Mukheryi и Maxim Petazzoni - សូមអរគុណចំពោះជំនួយរបស់អ្នកក្នុងការកែសម្រួលសារបង្ហោះ។

តើ CASE ជាអ្វី?

ខ្ញុំបានសម្រេចចិត្តមកជាមួយអក្សរកាត់ដ៏ស្រស់ស្អាតដូចជា វិធីសាស្រ្តប្រើប្រាស់របស់ Brendan Gregg ឬ វិធីសាស្រ្តក្រហមរបស់ Tom Wilkie. ខ្ញុំហៅវា។ វិធីសាស្រ្តករណី. គាត់ពិពណ៌នាអំពីចំណុចចំនួនបួនដែលត្រូវយកចិត្តទុកដាក់នៅពេលធ្វើការជាមួយការត្រួតពិនិត្យដោយស្វ័យប្រវត្តិ៖

• Cអត្ថបទ - ធ្ងន់ (បរិបទកំណត់)
• Aអាចធ្វើសកម្មភាពបាន។ (តម្លៃជាក់ស្តែង)
• Sផ្អែកលើរោគសញ្ញា (ការសង្កត់ធ្ងន់លើរោគសញ្ញា)
• Eមានតម្លៃ (ថ្នាក់)

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

ដើម្បីធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការចងចាំ សូមស្រមៃថាអ្នកត្រូវការ CASE [នោះគឺជាករណីមួយ ហេតុផល - កំណត់ចំណាំរបស់អ្នកបកប្រែ] ដើម្បីបង្ហាញពីភាពត្រឹមត្រូវនៃការជូនដំណឹងនីមួយៗ។ :វ៉ែនតា:

ហើយហេតុអ្វីបានជាទាំងអស់នេះ?

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

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

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

បរិបទ - ធ្ងន់ - ការចងបរិបទ

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

បញ្ហាមានប្រភពជាច្រើន។ ជាពិសេសខ្មោច។

តើខ្ញុំអាចជួយមន្ត្រីកាតព្វកិច្ចដោយរបៀបណា? រឿងដំបូងដែលមន្ត្រីកាតព្វកិច្ចឃើញគឺជាការជូនដំណឹង ដូច្នេះគាត់បង្កើតសម្មតិកម្មទាំងអស់នៅលើមូលដ្ឋានរបស់វា។ បន្ទាប់មកគាត់មើលការណែនាំ និងផ្ទាំងគ្រប់គ្រង ប៉ុន្តែតើវាតែងតែមានទិន្នន័យនៅលើការជូនដំណឹងជាក់លាក់មួយ ហើយមិនត្រឹមតែព័ត៌មានទូទៅទេ? Alspaugh ផ្តល់ដំបូន្មានថា "គិតអំពីរបៀបដែលអ្នកអាចបកស្រាយ ឬឆ្លើយតបទៅនឹងការជូនដំណឹង" (ស្លាយទី 29)1. ការជូនដំណឹងដ៏ល្អគឺផ្តោតលើបុគ្គលដែលបំពេញកាតព្វកិច្ច មិនមែនគ្រាន់តែកំណត់រចនាសម្ព័ន្ធដោយកម្រិតនោះទេ។

ដូច្នេះនេះគឺជាគំនិតមួយចំនួនអំពីរបៀបកែលម្អបរិបទនៃការជូនដំណឹង៖

• បង្ហាញអ្នកប្រើប្រាស់នូវអ្វីដែលមានប្រយោជន៍ និងបង្កើតជាពិសេស ហើយមិនត្រឹមតែការណែនាំធម្មតា ឬផ្ទាំងគ្រប់គ្រងប៉ុណ្ណោះទេ។ ពីមុន បុរស និងខ្ញុំបានប្រើផ្ទាំងគ្រប់គ្រងការស៊ើបអង្កេតដែលបានកំណត់រចនាសម្ព័ន្ធសម្រាប់ការជូនដំណឹងជាក់លាក់។ វានឹងជួយប្រសិនបើបញ្ហាត្រូវបានដឹង ប៉ុន្តែនឹងធ្វើឱ្យអ្នកផ្សេងមានការភ័ន្តច្រឡំប៉ុណ្ណោះ។ យើងត្រូវស្វែងរកតុល្យភាពនៅទីនេះ។
• ប្រាប់យើងអំពីប្រវត្តិនៃការជូនដំណឹង៖ តើវាថ្មីទេ? តើវាដំណើរការញឹកញាប់ទេ? តើវាជារដូវទេ?
• បង្ហាញការផ្លាស់ប្តូរថ្មីៗចំពោះស្ថានភាពប្រព័ន្ធ។ ថ្មីៗនេះមានអ្វីផ្លាស់ប្តូរ? (ឧទាហរណ៍ ការដាក់ពង្រាយ ឬបើក/បិទមុខងារ។ )
• បង្ហាញទំនាក់ទំនង និងផ្តល់ព័ត៌មានសម្រាប់គំរូផ្លូវចិត្ត៖ ភាពអាស្រ័យនៃប្រព័ន្ធគួរតែអាចមើលឃើញយ៉ាងច្បាស់ និយមជាមួយនឹងការចង្អុលបង្ហាញអំពីមុខងារ។
• ភ្ជាប់អ្នកប្រើប្រាស់យ៉ាងរហ័សជាមួយក្រុម៖ តើពួកគេអាចឃើញឧប្បត្តិហេតុដែលកំពុងកើតឡើង ឬតើពួកគេអាចរកឃើញថាអ្នកផ្សេងទៀតនៅក្នុងក្រុមហ៊ុនបានទទួលការជូនដំណឹងដែរឬទេ? កម្មវិធី ការគ្រប់គ្រងឧប្បត្តិហេតុ បានធ្វើឱ្យសកម្ម?

តាមឧត្ដមគតិ កម្មវិធីគ្រប់គ្រងឧប្បត្តិហេតុនឹងផ្តល់ដំបូន្មានអំពីរបៀបកែលម្អបរិបទជូនដំណឹងនៃការស៊ើបអង្កេតឧប្បត្តិហេតុ។ តែងតែមានអ្វីដែលត្រូវធ្វើការ!

អាចធ្វើសកម្មភាពបាន - តម្លៃជាក់ស្តែង

មន្ត្រី​កាតព្វកិច្ច​គួរ​ធ្វើ​អ្វី​មួយ​ដើម្បី​ឆ្លើយ​តប​នឹង​ការ​ជូន​ដំណឹង? បើ​អ្នក​មិន​ចាំបាច់​ធ្វើ​អ្វី ឬ​មិន​ច្បាស់​ថា​ត្រូវ​ធ្វើ​អ្វី​ទេ ហេតុ​អ្វី​បាន​ជា​អ្នក​ដាស់​គាត់? អ្នក​ត្រូវ​ជៀសវាង​ការ​ជូន​ដំណឹង​ដែល​រំខាន​អ្នក​ដែល​បំពេញ​កាតព្វកិច្ច ហើយ​មិន​តម្រូវ​ឱ្យ​មាន​សកម្មភាព។

មើលប្រកាសលើ imgur.com

តើ​ខ្ញុ​ុំ​គួរ​ធ្វើអ្វី? តើ​អ្នក​ចង់បាន​អ្វី?

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

នេះជាអ្វីដែលការជូនដំណឹងជាមួយនឹងតម្លៃជាក់ស្តែងមើលទៅដូច៖

• ការជូនដំណឹងតម្រូវឱ្យមានសកម្មភាពជាជាងការរាយការណ៍ព័ត៌មាន។
• សកម្មភាពនេះពិបាក ឬប្រថុយប្រថានក្នុងការធ្វើស្វ័យប្រវត្តិកម្ម។ បើ​សកម្មភាព​អាច​ធ្វើ​ដោយ​ស្វ័យ​ប្រវត្តិ ធ្វើ​ស្វ័យប្រវត្តិ​ទៅ ឈប់​ជេរ​មនុស្ស!
• សេចក្តីជូនដំណឹងមានការណែនាំជាបន្ទាន់ក្នុងទម្រង់ កិច្ចព្រមព្រៀងកម្រិតសេវាកម្ម (SLA) ឬ គោលដៅពេលវេលានៃការងើបឡើងវិញ (RTO) ។ បន្ទាប់មកមន្រ្តីកាតព្វកិច្ចអាចដំណើរការកម្មវិធីគ្រប់គ្រងឧប្បត្តិហេតុរបស់អង្គការ។

ខ្ញុំចង់បញ្ជាក់៖ ខ្ញុំមិននិយាយថាការជូនដំណឹងគួរតែមកសម្រាប់ SLOs សំខាន់បំផុត (គោលបំណងកម្រិតសេវាកម្ម) សម្រាប់ API នោះទេ។ ការត្រួតពិនិត្យ SLO ត្រូវបានបែងចែក និងបែងចែកឥតឈប់ឈរ ហើយទាមទារវិធីសាស្រ្តដូចគ្នាចំពោះសេវាកម្មទាំងអស់។ វាច្បាស់ណាស់ថាអ្នកនឹងតាមដាន SLOs ដ៏សំខាន់បំផុតសម្រាប់អតិថិជនដែលបង់ប្រាក់ឱ្យអ្នក។ ប៉ុន្តែ SLOs ហេដ្ឋារចនាសម្ព័ន្ធ ដូចជាមូលដ្ឋានទិន្នន័យ ក៏ត្រូវត្រួតពិនិត្យផងដែរ។ មិនយូរប៉ុន្មានអ្នកនឹងត្រូវដោះស្រាយជាមួយអតិថិជនខាងក្នុងនិងគាំទ្រពួកគេ។ ហើយដូច្នេះនៅលើការផ្សាយពាណិជ្ជកម្មគ្មានកំណត់។

ផ្អែកលើរោគសញ្ញា - ការសង្កត់ធ្ងន់លើរោគសញ្ញា

មិនថាអ្នកចូលចិត្ត ឬអត់ទេ អ្នកកំពុងធ្វើការនៅក្នុងប្រព័ន្ធចែកចាយ (Kavaj)2. ជាលទ្ធផល អ្នកប្រើយុទ្ធសាស្ត្រផ្សេងៗដើម្បីញែកសេវាកម្ម និងការពារពួកគេពីការបរាជ័យ (Trainor et al.)3. ហើយទោះបីជាការប្រមូលសំរាមដែលពន្យារពេល ឬសំណួរមូលដ្ឋានទិន្នន័យដែលជាប់គាំងបង្ហាញពីបញ្ហាក៏ដោយ មិនចាំបាច់ប្រញាប់ប្រញាល់ជួសជុលវាទេ ប្រសិនបើអ្នកប្រើមិនមានបញ្ហានាពេលខាងមុខ។

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

ដើម្បីធ្វើឱ្យការជូនដំណឹងមានអត្ថន័យ សូមផ្តោតលើ សូចនាករការអនុវត្តសំខាន់សម្រាប់អ្នកប្រើប្រាស់។ Evashchuk ហៅវាថា "ការត្រួតពិនិត្យសម្រាប់អ្នកប្រើប្រាស់" ។ សូមចងចាំថាទស្សនវិជ្ជានេះត្រូវតែអនុវត្តនៅទូទាំងអង្គភាព។ ប្រសិនបើសេវាកម្មមានបញ្ហាបន្ទាន់នៅកន្លែងណាមួយជ្រៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធ ក្រុមដែលសមស្របនឹងថែរក្សាពួកគេ។ ការការពារប្រព័ន្ធពីការបរាជ័យបែបនេះគឺជាបញ្ហាដាច់ដោយឡែកទាំងស្រុង (គ្រូបង្វឹក et al ។3.

រោគសញ្ញាមិនមានលក្ខណៈប្រែប្រួលទេ។

Richard Cook រំលឹកយើងថា ប្រព័ន្ធស្មុគ្រស្មាញ ពោរពេញដោយគុណវិបត្តិ ចំណុចខ្វះខាត និងបញ្ហា4. ការព្យាយាមរាយបញ្ជីហេតុផលដែលអាចមានទាំងអស់គឺជាកិច្ចការរបស់ស៊ីស៊ីភៀន។ អ្នកព្យាយាមពិពណ៌នាបញ្ហា ប៉ុន្តែពួកគេផ្លាស់ប្តូរគ្រប់ពេលវេលា។ Cindy Sridharan ជឿជាក់ថា "ប្រព័ន្ធមិនចាំបាច់ស្ថិតក្នុងស្ថានភាពល្អឥតខ្ចោះរាល់វិនាទីទេ" ហើយវាជាការប្រសើរក្នុងការប្រើប្រាស់វិធីសាស្រ្តរបស់មនុស្សកាន់តែច្រើន ("ការសង្កេតប្រព័ន្ធចែកចាយ" (“ការត្រួតពិនិត្យប្រព័ន្ធចែកចាយ”), ៧)5.

ជៀសវាងការជូនដំណឹងបន្ទាប់ពីឧប្បត្តិហេតុមួយ។

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

កុំ​ចាញ់​បោក​ដោយ​សារ​ការ​ជូន​ដំណឹង។ គិតកាន់តែប្រសើរ៖

• ហេតុអ្វីបានជាការជូនដំណឹងផ្អែកលើរោគសញ្ញាមិនកត់សម្គាល់បញ្ហា?
• តើវាមានប្រយោជន៍ក្នុងការកែលម្អបរិបទសម្រាប់អ្នកប្រើប្រាស់ដែរឬទេ?
• តើ​ឧបករណ៍​ត្រួតពិនិត្យ​អាច​ត្រូវ​បាន​ធ្វើ​ឱ្យ​ប្រសើរ​ឡើង​ដោយ​របៀប​ណា​ដើម្បី​ធ្វើ​ឱ្យ​ការ​ធ្វើ​រោគវិនិច្ឆ័យ​លឿន​ជាង​ការ​ជូនដំណឹង​អំពី​អ្វី​ដែល​បាន​កើត​ឡើង?

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

ការជូនដំណឹងផ្អែកលើហេតុផលគឺអាចអត់ឱនបានក្នុងកម្រិតមធ្យម

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

ការវាយតម្លៃ - ការវាយតម្លៃ

រាល់ការផ្លាស់ប្តូរប្រព័ន្ធ (កូដថ្មី ហេដ្ឋារចនាសម្ព័ន្ធថ្មី អ្វីថ្មី) ពង្រីកជួរនៃការបរាជ័យ (Cook, 3)។4 តើការជូនដំណឹងនេះនៅតែដំណើរការដូចការរំពឹងទុកដែរឬទេ? គំរូផ្លូវចិត្តច្បាស់លាស់ និងបច្ចុប្បន្ននៃប្រព័ន្ធ និងបទពិសោធន៍ឆ្លើយតបទៅនឹងការជូនដំណឹងអំពីជំនួយមួយចំនួន វិធីសាស្រ្តបង្ការ - នេះគឺជាលក្ខណៈសំខាន់ៗ អង្គការតម្រង់ទិសការសិក្សា. ពិការភាពនៅក្នុងប្រព័ន្ធកំពុងវិវឌ្ឍឥតឈប់ឈរ ហើយយើងត្រូវតែតាមទាន់ពួកគេ។

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

• ប្រើ វិស្វកម្មវឹកវរ, ថ្ងៃប្រកួត ឬវិធីសាស្រ្តធ្វើតេស្តការជូនដំណឹងផ្សេងទៀត។ ក្រុមអាចធ្វើវាដោយខ្លួនឯងបានដោយមិនចាំបាច់ពឹងផ្អែកលើប្រព័ន្ធគ្រប់គ្រងឧប្បត្តិហេតុធ្ងន់!
• បញ្ចូលការប្រមូលការជូនដំណឹងដែលទាក់ទងនឹងឧប្បត្តិហេតុទាំងអស់ទៅក្នុងកម្មវិធីគ្រប់គ្រងឧប្បត្តិហេតុរបស់អ្នក។ សម្គាល់មានប្រយោជន៍ គ្រោះថ្នាក់ មិនសមរម្យ មិនច្បាស់លាស់។ល។ ប្រើពួកវាជាមតិកែលម្អ។
• ការជូនដំណឹងត្រឹមត្រូវត្រូវបានបង្កឡើងជាញឹកញាប់ ហើយត្រូវបានសាកល្បងដោយប្រុងប្រយ័ត្ន។ ត្រូវប្រាកដថាតំណទាំងអស់ដំណើរការ ចង្អុលទៅបរិបទត្រឹមត្រូវ ។ល។
• ប្រសិនបើការជូនដំណឹងមិនដែលឆេះ ឬឆេះញឹកញាប់ពេក វាមានអ្វីមួយខុសប្រក្រតី។ ជួសជុលវាឬយកវាចេញ។ សូមប្រយ័ត្នចំពោះសកម្មភាព ឬសកម្មភាពហួសហេតុ!
• កំណត់ពេលវេលានៃការជូនដំណឹងជាមួយនឹងកាលបរិច្ឆេទផុតកំណត់។ ប្រសិនបើកាលបរិច្ឆេទផុតកំណត់បានផុតកំណត់ វាយតម្លៃការជូនដំណឹងដោយប្រើវិធីសាស្ត្រ CASE ហើយធ្វើបច្ចុប្បន្នភាពត្រាពេលវេលា។ ដូចគ្នានឹងអាហារដែរ ពិនិត្យកាលបរិច្ឆេទផុតកំណត់ឱ្យបានទៀងទាត់។
• សម្រួលដំណើរការនៃការកែលម្អការជូនដំណឹង។ ប្រើការត្រួតពិនិត្យជាកូដ និងរក្សាទុកការជូនដំណឹងនៅក្នុងឃ្លាំង Git ។ សំណើទាញជួយចូលរួមក្រុម និងផ្តល់ឱ្យអ្នកនូវប្រវត្តិនៃការជូនដំណឹងពីមុន។ ហើយអ្នកនឹងលែងភ័យខ្លាចក្នុងការផ្លាស់ប្តូរការជូនដំណឹង ឬសុំការអនុញ្ញាតពីអ្នកដែលទទួលខុសត្រូវចំពោះពួកគេ។
• រៀបចំមតិកែលម្អសម្រាប់ការជូនដំណឹង ទោះបីជាវាសាមញ្ញក៏ដោយ។ ទម្រង់ Googleដូច្នេះ​មន្ត្រី​កាតព្វកិច្ច​សម្គាល់​ការ​ជូន​ដំណឹង​ថា​គ្មាន​ប្រយោជន៍ ឬ​រំខាន។ បង្កប់តំណភ្ជាប់ ឬការហៅឱ្យធ្វើសកម្មភាពចូលទៅក្នុងការជូនដំណឹងដោយខ្លួនឯង ហើយពិនិត្យមើលមតិកែលម្អរបស់អ្នកឱ្យបានទៀងទាត់។
• បង្កើតច្បាប់ក្នុងក្រុម - ទុកអោយអ្នកដែលមានកាតព្វកិច្ចធ្វើការដើម្បីសម្រួលដល់ការបំពេញកាតព្វកិច្ចនៅពេលដែលមានការងារតិចតួច។ សូមឱ្យអ្វីៗទាំងអស់បន្ទាប់ពីអ្នកកាន់តែប្រសើរជាងវាបន្តិច។

សេចក្តីសន្និដ្ឋាន

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

ឧស្សាហកម្មទាំងមូលត្រូវគិតអំពីកត្តាមនុស្សក្នុងពេលបំពេញកាតព្វកិច្ចដោយមិនលះបង់សេវាកម្មអតិថិជនលំដាប់កំពូល។ ឧបករណ៍ និងការអនុវត្តទាំងអស់នេះអាច និងគួរត្រូវបានកែលម្អ។ ខ្ញុំសង្ឃឹមថាវិធីសាស្ត្រ CASE នឹងជួយក្នុងរឿងនេះ។

រីករាយជាមួយការជូនដំណឹងដែលប្រសើរឡើង!

ប្រភព: www.habr.com