SRE (វិស្វកម្មភាពជឿជាក់នៃគេហទំព័រ) គឺជាវិធីសាស្រ្តមួយដើម្បីធានាភាពងាយស្រួលនៃគម្រោងបណ្តាញ។ វាត្រូវបានចាត់ទុកថាជាក្របខ័ណ្ឌមួយសម្រាប់ DevOps និងនិយាយអំពីវិធីដើម្បីសម្រេចបាននូវភាពជោគជ័យក្នុងការអនុវត្តការអនុវត្ត DevOps ។ ការបកប្រែនៅក្នុងអត្ថបទនេះ។ ជំពូកទី 4 គោលបំណងកម្រិតសេវាកម្ម សៀវភៅ វិស្វកម្មភាពជឿជាក់នៃគេហទំព័រ ពី Google ។ ខ្ញុំបានរៀបចំការបកប្រែនេះដោយខ្លួនឯង ហើយពឹងផ្អែកលើបទពិសោធន៍ផ្ទាល់ខ្លួនរបស់ខ្ញុំក្នុងការយល់ដឹងអំពីដំណើរការត្រួតពិនិត្យ។ នៅក្នុងបណ្តាញទូរលេខ monitorim_it и ប្រកាសចុងក្រោយនៅលើ Habre ខ្ញុំក៏បានបោះពុម្ពការបកប្រែជំពូកទី 6 នៃសៀវភៅដូចគ្នាអំពីគោលដៅកម្រិតសេវាកម្ម។

ការបកប្រែដោយឆ្មា។ សូមរីករាយអាន!

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

យើងប្រើប្រាស់វិចារណញាណ បទពិសោធន៍ និងការយល់ដឹងអំពីបំណងប្រាថ្នារបស់អ្នកប្រើប្រាស់ដើម្បីស្វែងយល់ពីសូចនាករកម្រិតសេវាកម្ម (SLIs) គោលបំណងកម្រិតសេវាកម្ម (SLOs) និងកិច្ចព្រមព្រៀងកម្រិតសេវាកម្ម (SLAs)។ វិមាត្រទាំងនេះពិពណ៌នាអំពីរង្វាស់សំខាន់ៗដែលយើងចង់ត្រួតពិនិត្យ ហើយយើងនឹងប្រតិកម្មប្រសិនបើយើងមិនអាចផ្តល់នូវគុណភាពសេវាកម្មដែលរំពឹងទុក។ ទីបំផុត ការជ្រើសរើសរង្វាស់ត្រឹមត្រូវជួយណែនាំសកម្មភាពត្រឹមត្រូវ ប្រសិនបើមានអ្វីមួយខុសប្រក្រតី ហើយថែមទាំងផ្តល់ទំនុកចិត្តដល់ក្រុម SRE លើសុខភាពសេវាកម្មផងដែរ។

ជំពូកនេះពិពណ៌នាអំពីវិធីសាស្រ្តដែលយើងប្រើដើម្បីប្រយុទ្ធប្រឆាំងនឹងបញ្ហានៃគំរូម៉ែត្រ ការជ្រើសរើសម៉ែត្រ និងការវិភាគម៉ែត្រ។ ការពន្យល់ភាគច្រើននឹងគ្មានឧទាហរណ៍ ដូច្នេះយើងនឹងប្រើសេវាកម្មស្ពាដែលបានពិពណ៌នានៅក្នុងឧទាហរណ៍នៃការអនុវត្តរបស់វា (ស្វែងរកស្នាដៃរបស់ស្ពា) ដើម្បីបង្ហាញពីចំណុចសំខាន់ៗ។

វាក្យសព្ទកម្រិតសេវាកម្ម

អ្នកអានជាច្រើនទំនងជាស្គាល់គោលគំនិតរបស់ SLA ប៉ុន្តែពាក្យ SLI និង SLO សមនឹងនិយមន័យដោយប្រុងប្រយ័ត្ន ព្រោះជាទូទៅពាក្យ SLA គឺលើសទម្ងន់ និងមានអត្ថន័យជាច្រើនអាស្រ័យលើបរិបទ។ សម្រាប់ភាពច្បាស់លាស់ យើងចង់បំបែកតម្លៃទាំងនេះ។

សូចនាករ

SLI គឺជាសូចនាករកម្រិតសេវាកម្ម—ជារង្វាស់បរិមាណដែលបានកំណត់យ៉ាងប្រុងប្រយ័ត្ននៃទិដ្ឋភាពមួយនៃកម្រិតនៃសេវាកម្មដែលបានផ្តល់។

សម្រាប់សេវាកម្មភាគច្រើន SLI គន្លឹះត្រូវបានចាត់ទុកថាជាភាពយឺតយ៉ាវនៃសំណើ - តើវាត្រូវការរយៈពេលប៉ុន្មានដើម្បីត្រឡប់ការឆ្លើយតបទៅនឹងសំណើមួយ។ SLIs ទូទៅផ្សេងទៀតរួមមានអត្រាកំហុស ដែលជារឿយៗត្រូវបានបង្ហាញជាប្រភាគនៃសំណើទាំងអស់ដែលទទួលបាន និងដំណើរការប្រព័ន្ធ ដែលជាធម្មតាត្រូវបានវាស់វែងជាសំណើក្នុងមួយវិនាទី។ ការវាស់វែងត្រូវបានប្រមូលផ្តុំជាញឹកញាប់៖ ទិន្នន័យឆៅត្រូវបានប្រមូលដំបូង ហើយបន្ទាប់មកបំប្លែងទៅជាអត្រានៃការផ្លាស់ប្តូរ មធ្យម ឬភាគរយ។

តាមឧត្ដមគតិ SLI វាស់ដោយផ្ទាល់នូវកម្រិតនៃការចាប់អារម្មណ៍ ប៉ុន្តែពេលខ្លះមានតែម៉ែត្រដែលទាក់ទងប៉ុណ្ណោះដែលអាចរកបានសម្រាប់ការវាស់វែង ពីព្រោះឯកសារដើមពិបាកទទួលបាន ឬបកស្រាយ។ ជាឧទាហរណ៍ ភាពយឺតយ៉ាវខាងម៉ាស៊ីនភ្ញៀវ ជារឿយៗជារង្វាស់ដែលសមស្របជាង ប៉ុន្តែមានពេលខ្លះដែលភាពយឺតយ៉ាវអាចវាស់វែងបានតែនៅលើម៉ាស៊ីនមេប៉ុណ្ណោះ។

ប្រភេទ SLI មួយផ្សេងទៀតដែលមានសារៈសំខាន់ចំពោះ SREs គឺភាពអាចរកបាន ឬផ្នែកនៃពេលវេលាដែលសេវាកម្មអាចប្រើប្រាស់បាន។ ជារឿយៗត្រូវបានកំណត់ថាជាអត្រានៃសំណើដែលទទួលបានជោគជ័យ ជួនកាលគេហៅថាទិន្នផល។ (ពេញមួយជីវិត—លទ្ធភាពដែលទិន្នន័យនឹងត្រូវបានរក្សាទុកក្នុងរយៈពេលយូរ—ក៏មានសារៈសំខាន់សម្រាប់ប្រព័ន្ធផ្ទុកទិន្នន័យផងដែរ។) ទោះបីជាភាពអាចរកបាន 100% មិនអាចទៅរួចក៏ដោយ ភាពអាចរកបានជិត 100% ជាញឹកញាប់អាចសម្រេចបាន តម្លៃដែលអាចរកបានត្រូវបានបង្ហាញជា ចំនួន "ប្រាំបួន" » ភាគរយនៃភាពអាចរកបាន។ ឧទាហរណ៍ ភាពអាចរកបាន 99% និង 99,999% អាចត្រូវបានដាក់ស្លាកថា "2 nine" និង "5 nine"។ គោលដៅដែលអាចរកបាននាពេលបច្ចុប្បន្នរបស់ Google Compute Engine គឺ "ប្រាំបួនកន្លះ" ឬ 99,95% ។

គោលបំណង

SLO គឺជាគោលបំណងកម្រិតសេវាកម្ម៖ តម្លៃគោលដៅ ឬជួរតម្លៃសម្រាប់កម្រិតសេវាកម្មដែលត្រូវបានវាស់ដោយ SLI ។ តម្លៃធម្មតាសម្រាប់ SLO គឺ "SLI ≤ គោលដៅ" ឬ "ដែនកំណត់ទាប ≤ SLI ≤ ដែនកំណត់ខាងលើ" ។ ជាឧទាហរណ៍ យើងអាចសម្រេចចិត្តថាយើងនឹងត្រឡប់លទ្ធផលស្វែងរករបស់ Shakespeare "លឿន" ដោយកំណត់ SLO ទៅជាភាពយឺតនៃសំណួរស្វែងរកជាមធ្យមតិចជាង 100 មីលីវិនាទី។

ការជ្រើសរើស SLO ត្រឹមត្រូវគឺជាដំណើរការដ៏ស្មុគស្មាញមួយ។ ទីមួយ អ្នកមិនអាចជ្រើសរើសតម្លៃជាក់លាក់ណាមួយបានឡើយ។ សម្រាប់សំណើ HTTP ចូលមកខាងក្រៅចំពោះសេវាកម្មរបស់អ្នក រង្វាស់សំណួរក្នុងមួយវិនាទី (QPS) ត្រូវបានកំណត់ជាចម្បងដោយបំណងប្រាថ្នារបស់អ្នកប្រើក្នុងការចូលមើលសេវាកម្មរបស់អ្នក ហើយអ្នកមិនអាចកំណត់ SLO សម្រាប់នោះទេ។

ម្យ៉ាងវិញទៀត អ្នកអាចនិយាយបានថា អ្នកចង់ឱ្យភាពយឺតយ៉ាវជាមធ្យមសម្រាប់សំណើនីមួយៗតិចជាង 100 មីលីវិនាទី។ ការកំណត់គោលដៅបែបនេះអាចបង្ខំអ្នកឱ្យសរសេរផ្នែកខាងមុខរបស់អ្នកជាមួយនឹងភាពយឺតយ៉ាវទាប ឬទិញឧបករណ៍ដែលផ្តល់ភាពយឺតយ៉ាវបែបនេះ។ (100 មិល្លីវិនាទីច្បាស់ជាចំនួនបំពាន ប៉ុន្តែវាជាការប្រសើរជាងដែលមានលេខ latency ទាបជាង។ មានភស្តុតាងដែលបង្ហាញថាល្បឿនលឿនប្រសើរជាងល្បឿនយឺត ហើយភាពយឺតយ៉ាវក្នុងដំណើរការសំណើរបស់អ្នកប្រើលើសពីតម្លៃជាក់លាក់ពិតជាបង្ខំមនុស្សឱ្យនៅឆ្ងាយ។ ពីសេវាកម្មរបស់អ្នក។ )

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

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

កិច្ចព្រមព្រៀង

កិច្ចព្រមព្រៀងកម្រិតសេវាកម្មគឺជាកិច្ចសន្យាច្បាស់លាស់ ឬមិនច្បាស់លាស់ជាមួយអ្នកប្រើប្រាស់របស់អ្នក ដែលរួមបញ្ចូលផលវិបាកនៃការជួប (ឬមិនជួប) SLOs ដែលពួកគេមាន។ ផលវិបាកត្រូវបានទទួលស្គាល់យ៉ាងងាយស្រួលបំផុតនៅពេលដែលពួកគេមានហិរញ្ញវត្ថុ - ការបញ្ចុះតម្លៃឬការផាកពិន័យ - ប៉ុន្តែពួកគេអាចយកទម្រង់ផ្សេងទៀត។ មធ្យោបាយងាយស្រួលក្នុងការនិយាយអំពីភាពខុសគ្នារវាង SLOs និង SLAs គឺត្រូវសួរថា "តើមានអ្វីកើតឡើងប្រសិនបើ SLOs មិនត្រូវបានបំពេញ?" ប្រសិនបើមិនមានផលវិបាកច្បាស់លាស់ទេ អ្នកពិតជាកំពុងសម្លឹងមើល SLO ហើយ។

SRE ជាធម្មតាមិនពាក់ព័ន្ធនឹងការបង្កើត SLAs ទេ ដោយសារតែ SLAs ត្រូវបានភ្ជាប់យ៉ាងជិតស្និទ្ធទៅនឹងការសម្រេចចិត្តអាជីវកម្ម និងផលិតផល។ ទោះជាយ៉ាងណាក៏ដោយ SRE ចូលរួមនៅក្នុងការជួយកាត់បន្ថយផលវិបាកនៃ SLOs ដែលបរាជ័យ។ ពួកគេក៏អាចជួយកំណត់ SLI ផងដែរ៖ ជាក់ស្តែង ត្រូវតែមានមធ្យោបាយដែលមានគោលបំណងដើម្បីវាស់វែង SLO នៅក្នុងកិច្ចព្រមព្រៀង ឬវានឹងមានការខ្វែងគំនិតគ្នា។

Google Search គឺជាឧទាហរណ៍នៃសេវាកម្មសំខាន់ដែលមិនមាន SLA សាធារណៈ៖ យើងចង់ឱ្យអ្នកគ្រប់គ្នាប្រើប្រាស់ការស្វែងរកប្រកបដោយប្រសិទ្ធភាពតាមដែលអាចធ្វើទៅបាន ប៉ុន្តែយើងមិនបានចុះហត្ថលេខាលើកិច្ចសន្យាជាមួយពិភពលោកទេ។ ទោះជាយ៉ាងណាក៏ដោយ វានៅតែមានផលវិបាក ប្រសិនបើការស្វែងរកមិនអាចប្រើបាន - ភាពមិនអាចរកបាននាំឱ្យធ្លាក់ចុះកេរ្តិ៍ឈ្មោះរបស់យើង ក៏ដូចជាកាត់បន្ថយប្រាក់ចំណូលពីការផ្សាយពាណិជ្ជកម្មផងដែរ។ សេវាកម្ម Google ជាច្រើនទៀតដូចជា Google for Work មានកិច្ចព្រមព្រៀងកម្រិតសេវាកម្មច្បាស់លាស់ជាមួយអ្នកប្រើប្រាស់។ ដោយមិនគិតពីថាតើសេវាជាក់លាក់ណាមួយមាន SLA ទេ វាជាការសំខាន់ក្នុងការកំណត់ SLI និង SLO ហើយប្រើពួកវាដើម្បីគ្រប់គ្រងសេវាកម្ម។

ទ្រឹស្តីជាច្រើន - ឥឡូវនេះដើម្បីទទួលបទពិសោធន៍។

សូចនាករក្នុងការអនុវត្ត

ដោយសារយើងសន្និដ្ឋានថា វាជារឿងសំខាន់ក្នុងការជ្រើសរើសរង្វាស់សមស្រប ដើម្បីវាស់កម្រិតសេវាកម្ម តើឥឡូវនេះអ្នកដឹងដោយរបៀបណាថាម៉ែត្រមួយណាសំខាន់សម្រាប់សេវាកម្ម ឬប្រព័ន្ធ?

តើអ្នក និងអ្នកប្រើប្រាស់របស់អ្នកខ្វល់អំពីអ្វី?

អ្នកមិនចាំបាច់ប្រើរាល់ម៉ែត្រជា SLI ដែលអ្នកអាចតាមដាននៅក្នុងប្រព័ន្ធត្រួតពិនិត្យនោះទេ។ ការយល់ដឹងអំពីអ្វីដែលអ្នកប្រើចង់បានពីប្រព័ន្ធមួយនឹងជួយអ្នកក្នុងការជ្រើសរើសម៉ែត្រជាច្រើន។ ការជ្រើសរើសសូចនាករច្រើនពេកធ្វើឱ្យពិបាកក្នុងការផ្តោតលើសូចនាករសំខាន់ៗ ខណៈពេលដែលការជ្រើសរើសលេខតូចអាចទុកប្រព័ន្ធរបស់អ្នកជាច្រើនដោយមិនមានការយកចិត្តទុកដាក់។ ជាធម្មតា យើងប្រើសូចនាករសំខាន់ៗជាច្រើន ដើម្បីវាយតម្លៃ និងយល់ពីសុខភាពនៃប្រព័ន្ធមួយ។

សេវាកម្មជាទូទៅអាចត្រូវបានបែងចែកទៅជាផ្នែកជាច្រើននៅក្នុងលក្ខខណ្ឌនៃ SLI ដែលពាក់ព័ន្ធនឹងពួកគេ៖

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

ការប្រមូលសូចនាករ

សូចនាករកម្រិតសេវាកម្មជាច្រើនត្រូវបានប្រមូលដោយធម្មជាតិបំផុតនៅលើផ្នែកម៉ាស៊ីនមេ ដោយប្រើប្រព័ន្ធត្រួតពិនិត្យដូចជា Borgmon (សូមមើលខាងក្រោម)។ ជំពូកទី 10 ការអនុវត្តការជូនដំណឹងដោយផ្អែកលើទិន្នន័យស៊េរីពេលវេលា) ឬ Prometheus ឬគ្រាន់តែវិភាគកំណត់ហេតុជាប្រចាំ ដោយកំណត់អត្តសញ្ញាណការឆ្លើយតប HTTP ជាមួយស្ថានភាព 500។ ទោះជាយ៉ាងណាក៏ដោយ ប្រព័ន្ធមួយចំនួនគួរតែត្រូវបានបំពាក់ជាមួយនឹងការប្រមូលម៉ែត្រពីភាគីអតិថិជន ដោយសារកង្វះការត្រួតពិនិត្យផ្នែកអតិថិជនអាចនាំឱ្យបាត់បញ្ហាមួយចំនួនដែលប៉ះពាល់ដល់ អ្នក​ប្រើ ប៉ុន្តែ​មិន​ប៉ះពាល់​ដល់​ម៉ែត្រ​ខាង​ម៉ាស៊ីន​មេ។ ជាឧទាហរណ៍ ការផ្តោតលើភាពយឺតយ៉ាវនៃការឆ្លើយតបផ្នែកខាងក្រោយនៃកម្មវិធីសាកល្បងការស្វែងរករបស់ Shakespeare របស់យើងអាចបណ្តាលឱ្យមានភាពយឺតយ៉ាវនៅខាងអ្នកប្រើប្រាស់ ដោយសារបញ្ហា JavaScript៖ ក្នុងករណីនេះ ការវាស់ស្ទង់រយៈពេលដែលវាត្រូវការកម្មវិធីរុករកតាមអ៊ីនធឺណិតដើម្បីដំណើរការទំព័រគឺជាមាត្រដ្ឋានប្រសើរជាង។

ការប្រមូលផ្តុំ

សម្រាប់ភាពសាមញ្ញ និងភាពងាយស្រួល យើងច្រើនតែប្រមូលការវាស់វែងឆៅ។ នេះត្រូវធ្វើដោយប្រុងប្រយ័ត្ន។

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

សូចនាករភាគច្រើនត្រូវបានគេមើលឃើញថាជាការចែកចាយជាជាងមធ្យមភាគ។ ឧទាហរណ៍ សម្រាប់ភាពយឺតនៃ SLI សំណើមួយចំនួននឹងត្រូវបានដំណើរការយ៉ាងរហ័ស ខណៈពេលដែលមួយចំនួនតែងតែចំណាយពេលយូរ ជួនកាលយូរជាងនេះ។ មធ្យមសាមញ្ញអាចលាក់ការពន្យារពេលដ៏យូរទាំងនេះ។ តួលេខបង្ហាញឧទាហរណ៍៖ ទោះបីជាសំណើធម្មតាចំណាយពេលប្រហែល 50 ms ដើម្បីបម្រើក៏ដោយ 5% នៃសំណើគឺយឺតជាង 20 ដង! ការត្រួតពិនិត្យ និងការជូនដំណឹងដោយផ្អែកលើភាពយឺតយ៉ាវជាមធ្យមមិនបង្ហាញពីការផ្លាស់ប្តូរអាកប្បកិរិយាពេញមួយថ្ងៃនោះទេ នៅពេលដែលការពិតមានការផ្លាស់ប្តូរគួរឱ្យកត់សម្គាល់នៅក្នុងពេលវេលាដំណើរការនៃសំណើមួយចំនួន (បន្ទាត់កំពូល)។

ភាពយឺតនៃប្រព័ន្ធ 50, 85, 95 និង 99 ភាគរយ។ អ័ក្ស Y ជាទម្រង់លោការីត។

ការប្រើប្រាស់ភាគរយសម្រាប់សូចនាករអនុញ្ញាតឱ្យអ្នកមើលឃើញរូបរាងនៃការចែកចាយ និងលក្ខណៈរបស់វា៖ កម្រិតភាគរយខ្ពស់ដូចជា 99 ឬ 99,9 បង្ហាញពីតម្លៃដ៏អាក្រក់បំផុត ខណៈដែល 50 ភាគរយ (ត្រូវបានគេស្គាល់ផងដែរថាជាមធ្យម) បង្ហាញពីស្ថានភាពញឹកញាប់បំផុតនៃ ម៉ែត្រ។ ការបែកខ្ចាត់ខ្ចាយពេលវេលាឆ្លើយតបកាន់តែច្រើន សំណើដែលអូសបន្លាយកាន់តែយូរប៉ះពាល់ដល់បទពិសោធន៍អ្នកប្រើប្រាស់។ ប្រសិទ្ធភាពត្រូវបានពង្រឹងនៅក្រោមការផ្ទុកខ្ពស់និងនៅក្នុងវត្តមាននៃជួរ។ ការស្រាវជ្រាវបទពិសោធន៍របស់អ្នកប្រើប្រាស់បានបង្ហាញថាមនុស្សជាទូទៅចូលចិត្តប្រព័ន្ធយឺតជាមួយនឹងភាពខុសគ្នានៃពេលវេលាឆ្លើយតបខ្ពស់ ដូច្នេះក្រុម SRE មួយចំនួនផ្តោតតែលើពិន្ទុភាគរយខ្ពស់ ដោយឈរលើមូលដ្ឋានថាប្រសិនបើអាកប្បកិរិយារបស់ម៉ែត្រនៅ 99,9 ភាគរយគឺល្អ អ្នកប្រើប្រាស់ភាគច្រើននឹងមិនជួបបញ្ហាទេ។ .

ចំណាំលើកំហុសស្ថិតិ

ជាទូទៅយើងចូលចិត្តធ្វើការជាមួយភាគរយជាជាងមធ្យម (មធ្យមនព្វន្ធ) នៃសំណុំនៃតម្លៃ។ នេះអនុញ្ញាតឱ្យយើងពិចារណាតម្លៃដែលបែកខ្ញែកកាន់តែច្រើន ដែលជារឿយៗមានលក្ខណៈខុសគ្នាខ្លាំង (និងគួរឱ្យចាប់អារម្មណ៍) ជាងមធ្យម។ ដោយសារលក្ខណៈសិប្បនិម្មិតនៃប្រព័ន្ធកុំព្យូទ័រ តម្លៃម៉ែត្រត្រូវបានបំភាន់ជាញឹកញយ ឧទាហរណ៍ គ្មានសំណើណាមួយអាចទទួលបានការឆ្លើយតបតិចជាង 0 ms ហើយការអស់ពេលនៃ 1000 ms មានន័យថាមិនអាចមានការឆ្លើយតបដោយជោគជ័យជាមួយនឹងតម្លៃធំជាងនោះទេ។ ជាងការអស់ពេល។ ជាលទ្ធផល យើងមិនអាចទទួលយកបានទេថា មធ្យម និងមធ្យមអាចដូចគ្នា ឬនៅជិតគ្នា!

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

កំណត់ស្តង់ដារសូចនាករ

យើងសូមណែនាំឱ្យធ្វើស្តង់ដារលក្ខណៈទូទៅសម្រាប់ SLI ដូច្នេះអ្នកមិនចាំបាច់ប៉ាន់ស្មានអំពីពួកវារាល់ពេល។ លក្ខណៈពិសេសណាមួយដែលបំពេញតាមលំនាំស្តង់ដារអាចត្រូវបានដកចេញពីការបញ្ជាក់នៃ SLI នីមួយៗ ឧទាហរណ៍៖

• ចន្លោះពេលសរុប៖ "ជាមធ្យមលើសពី 1 នាទី"
• តំបន់ប្រមូលផ្តុំ៖ "កិច្ចការទាំងអស់នៅក្នុងចង្កោម"
• តើការវាស់វែងត្រូវបានគេយកញឹកញាប់ប៉ុណ្ណា៖ "រៀងរាល់ 10 វិនាទី"
• សំណើអ្វីខ្លះត្រូវបានរួមបញ្ចូល៖ "HTTP GET ពីការងារត្រួតពិនិត្យប្រអប់ខ្មៅ"
• របៀបដែលទិន្នន័យត្រូវបានទទួល៖ "សូមអរគុណចំពោះការត្រួតពិនិត្យរបស់យើងដែលបានវាស់វែងនៅលើម៉ាស៊ីនមេ"
• ភាពយឺតយ៉ាវនៃការចូលប្រើទិន្នន័យ៖ "ពេលវេលាដល់បៃចុងក្រោយ"

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

គោលដៅក្នុងការអនុវត្ត

ចាប់ផ្តើមដោយគិតអំពី (ឬស្វែងយល់!) អ្វីដែលអ្នកប្រើរបស់អ្នកខ្វល់ មិនមែនអ្វីដែលអ្នកអាចវាស់វែងបានទេ។ ជារឿយៗ អ្វីដែលអ្នកប្រើប្រាស់របស់អ្នកខ្វល់ខ្វាយអំពីវាពិបាក ឬមិនអាចវាស់វែងបាន ដូច្នេះអ្នកកាន់តែខិតទៅជិតតម្រូវការរបស់ពួកគេ។ ទោះជាយ៉ាងណាក៏ដោយ ប្រសិនបើអ្នកគ្រាន់តែចាប់ផ្តើមជាមួយនឹងអ្វីដែលងាយស្រួលក្នុងការវាស់វែង អ្នកនឹងបញ្ចប់ដោយ SLO ដែលមានប្រយោជន៍តិច។ ជាលទ្ធផល ពេលខ្លះយើងបានរកឃើញថា ដំបូងកំណត់គោលដៅដែលចង់បាន ហើយបន្ទាប់មកធ្វើការជាមួយសូចនាករជាក់លាក់ ដំណើរការប្រសើរជាងការជ្រើសរើសសូចនាករ ហើយបន្ទាប់មកសម្រេចបាននូវគោលដៅ។

កំណត់គោលដៅ

សម្រាប់ភាពច្បាស់លាស់អតិបរមា វាគួរតែត្រូវបានកំណត់ពីរបៀបដែល SLOs ត្រូវបានវាស់វែង និងលក្ខខណ្ឌដែលវាមានសុពលភាព។ ឧទាហរណ៍ យើងអាចនិយាយដូចខាងក្រោម (បន្ទាត់ទីពីរគឺដូចគ្នាទៅនឹងទីមួយដែរ ប៉ុន្តែប្រើលំនាំដើម SLI)៖

• 99% (ជាមធ្យមលើសពី 1 នាទី) នៃការហៅទូរសព្ទ Get RPC នឹងបញ្ចប់ក្នុងរយៈពេលតិចជាង 100ms (វាស់នៅទូទាំងម៉ាស៊ីនមេ backend ទាំងអស់)។
• 99% នៃការហៅទូរសព្ទ RPC នឹងបញ្ចប់ក្នុងរយៈពេលតិចជាង 100ms។

ប្រសិនបើរូបរាងនៃខ្សែកោងដំណើរការមានសារៈសំខាន់ អ្នកអាចបញ្ជាក់ SLOs ច្រើន៖

• 90% នៃការទទួលការហៅទូរសព្ទ RPC បានបញ្ចប់ក្នុងរយៈពេលតិចជាង 1 ms ។
• 99% នៃការទទួលការហៅទូរសព្ទ RPC បានបញ្ចប់ក្នុងរយៈពេលតិចជាង 10 ms ។
• 99.9% នៃការទទួលការហៅទូរសព្ទ RPC បានបញ្ចប់ក្នុងរយៈពេលតិចជាង 100 ms ។

ប្រសិនបើអ្នកប្រើរបស់អ្នកបង្កើតបន្ទុកការងារខុសៗគ្នា៖ ដំណើរការភាគច្រើន (ដែលលំហូរមានសារៈសំខាន់) និងដំណើរការអន្តរកម្ម (សម្រាប់ភាពយឺតយ៉ាវគឺសំខាន់) វាអាចមានប្រយោជន៍ក្នុងការកំណត់គោលដៅដាច់ដោយឡែកសម្រាប់ថ្នាក់ផ្ទុកនីមួយៗ៖

• 95% នៃសំណើរបស់អតិថិជនទាមទារការឆ្លងកាត់។ កំណត់ចំនួននៃការហៅ RPC ដែលបានប្រតិបត្តិ <1 s ។
• 99% នៃអតិថិជនយកចិត្តទុកដាក់ចំពោះភាពយឺតយ៉ាវ។ កំណត់ចំនួននៃការហៅ RPC ដែលមានចរាចរណ៍ <1 KB និងដំណើរការ <10 ms ។

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

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

ការជ្រើសរើសតម្លៃគោលដៅ

ការជ្រើសរើសតម្លៃនៃផែនការ (SLOs) មិនមែនជាសកម្មភាពបច្ចេកទេសសុទ្ធសាធទេ ដោយសារតែផលិតផល និងផលប្រយោជន៍អាជីវកម្មដែលត្រូវតែឆ្លុះបញ្ចាំងនៅក្នុង SLIs, SLOs (និងអាចជា SLAs) ដែលបានជ្រើសរើស។ ដូចគ្នានេះដែរ ព័ត៌មានអាចនឹងត្រូវផ្លាស់ប្តូរទាក់ទងនឹងបញ្ហាទាក់ទងនឹងបុគ្គលិក ពេលវេលាសម្រាប់ទីផ្សារ ភាពអាចរកបានឧបករណ៍ និងហិរញ្ញវត្ថុ។ SRE គួរតែជាផ្នែកមួយនៃការសន្ទនានេះ និងជួយយល់ពីហានិភ័យ និងលទ្ធភាពនៃជម្រើសផ្សេងៗ។ យើងបានបង្កើតនូវសំណួរមួយចំនួនដែលអាចជួយធានាបាននូវការពិភាក្សាប្រកបដោយផលិតភាពបន្ថែមទៀត៖

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

រក្សាវាឱ្យសាមញ្ញ
ការគណនា SLI ស្មុគ្រស្មាញអាចលាក់ការផ្លាស់ប្តូរនៅក្នុងដំណើរការប្រព័ន្ធ និងធ្វើឱ្យពិបាកក្នុងការស្វែងរកមូលហេតុនៃបញ្ហា។

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

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

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

SLOs អាច និងគួរតែជាកត្តាជំរុញសំខាន់ក្នុងការផ្តល់អាទិភាពការងារសម្រាប់ SREs និងអ្នកអភិវឌ្ឍន៍ផលិតផល ព្រោះវាឆ្លុះបញ្ចាំងពីការព្រួយបារម្ភចំពោះអ្នកប្រើប្រាស់។ SLO ដ៏ល្អគឺជាឧបករណ៍អនុវត្តដ៏មានប្រយោជន៍សម្រាប់ក្រុមអភិវឌ្ឍន៍។ ប៉ុន្តែ SLO ដែលត្រូវបានរចនាមិនល្អអាចនាំទៅរកការងារខ្ជះខ្ជាយ ប្រសិនបើក្រុមការងារខិតខំប្រឹងប្រែងដើម្បីសម្រេចបាននូវ SLO ដែលឈ្លានពានខ្លាំងពេក ឬផលិតផលមិនល្អ ប្រសិនបើ SLO ទាបពេក។ SLO គឺជាដងថ្លឹងដ៏មានអានុភាព ប្រើវាដោយប្រាជ្ញា។

គ្រប់គ្រងការវាស់វែងរបស់អ្នក។

SLI និង SLO គឺជាធាតុសំខាន់ដែលត្រូវបានប្រើដើម្បីគ្រប់គ្រងប្រព័ន្ធ៖

• ត្រួតពិនិត្យ និងវាស់វែងប្រព័ន្ធ SLI ។
• ប្រៀបធៀប SLI ទៅ SLO ហើយសម្រេចចិត្តថាតើត្រូវការសកម្មភាពដែរឬទេ។
• ប្រសិនបើ​ត្រូវ​ធ្វើ​សកម្មភាព ចូរ​រក​ឱ្យ​ឃើញ​នូវ​អ្វី​ដែល​ត្រូវ​កើត​ឡើង​ដើម្បី​សម្រេច​បាន​គោលដៅ។
• បំពេញសកម្មភាពនេះ។

ឧទាហរណ៍ ប្រសិនបើជំហានទី 2 បង្ហាញថាសំណើកំពុងអស់ពេល ហើយនឹងបំបែក SLO ក្នុងរយៈពេលពីរបីម៉ោង ប្រសិនបើគ្មានអ្វីត្រូវបានធ្វើទេ ជំហានទី 3 អាចពាក់ព័ន្ធនឹងការសាកល្បងសម្មតិកម្មដែលថាម៉ាស៊ីនមេត្រូវបានចង CPU ហើយការបន្ថែមម៉ាស៊ីនមេបន្ថែមទៀតនឹងចែកចាយបន្ទុក។ បើគ្មាន SLO ទេ អ្នកនឹងមិនដឹងថាតើ (ឬពេលណា) ត្រូវចាត់វិធានការនោះទេ។

កំណត់ SLO - បន្ទាប់មកការរំពឹងទុករបស់អ្នកប្រើនឹងត្រូវបានកំណត់
ការបោះពុម្ព SLO កំណត់ការរំពឹងទុករបស់អ្នកប្រើសម្រាប់ឥរិយាបថប្រព័ន្ធ។ អ្នកប្រើប្រាស់ (និងអ្នកប្រើប្រាស់សក្តានុពល) តែងតែចង់ដឹងពីអ្វីដែលត្រូវរំពឹងពីសេវាកម្ម ដើម្បីស្វែងយល់ថាតើវាសាកសមសម្រាប់ការប្រើប្រាស់ដែរឬទេ។ ជាឧទាហរណ៍ អ្នកដែលចង់ប្រើគេហទំព័រចែករំលែករូបថត ប្រហែលជាចង់ជៀសវាងការប្រើសេវាកម្មដែលសន្យាថានឹងប្រើប្រាស់បានយូរ និងតម្លៃទាប ជាថ្នូរនឹងភាពអាចរកបានតិចជាងបន្តិច បើទោះបីជាសេវាកម្មដូចគ្នានេះអាចជាជម្រើសដ៏ល្អសម្រាប់ប្រព័ន្ធគ្រប់គ្រងការរក្សាទុកឯកសារក៏ដោយ។

ដើម្បីកំណត់ការរំពឹងទុកជាក់ស្តែងសម្រាប់អ្នកប្រើប្រាស់របស់អ្នក សូមប្រើយុទ្ធសាស្ត្រមួយ ឬទាំងពីរខាងក្រោម៖

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

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

កិច្ចព្រមព្រៀងក្នុងការអនុវត្ត

ការបង្កើត SLA ទាមទារឱ្យក្រុមអាជីវកម្ម និងផ្នែកច្បាប់កំណត់ផលវិបាក និងការផាកពិន័យចំពោះការបំពានវា។ តួនាទីរបស់ SRE គឺដើម្បីជួយពួកគេឱ្យយល់អំពីបញ្ហាប្រឈមដែលអាចកើតមានក្នុងការជួបជាមួយ SLOs ដែលមាននៅក្នុង SLA ។ អនុសាសន៍ភាគច្រើនសម្រាប់បង្កើត SLOs ក៏អនុវត្តចំពោះ SLAs ផងដែរ។ វាជាការឆ្លាតវៃក្នុងការរក្សានូវអ្វីដែលអ្នកសន្យានឹងអ្នកប្រើប្រាស់ ព្រោះថាអ្នកមានកាន់តែច្រើន វាកាន់តែពិបាកក្នុងការផ្លាស់ប្តូរ ឬលុប SLA ដែលហាក់ដូចជាមិនសមហេតុផល ឬពិបាកក្នុងការជួប។

អរគុណសម្រាប់ការអានការបកប្រែដល់ចប់។ ជាវឆានែលទូរលេខរបស់ខ្ញុំអំពីការត្រួតពិនិត្យ monitorim_it и ប្លុកនៅលើមធ្យម.

ប្រភព: www.habr.com