SRE (Site Reliability Engineering) යනු වෙබ් ව්‍යාපෘති වෙත ප්‍රවේශ විය හැකි ප්‍රවේශයකි. එය DevOps සඳහා රාමුවක් ලෙස සලකනු ලබන අතර DevOps භාවිතයන් සාර්ථක වන්නේ කෙසේදැයි කියයි. මෙම ලිපිය පරිවර්තනය කරයි 4 වන පරිච්ඡේදය සේවා මට්ටමේ අරමුණු පොත් අඩවි විශ්වසනීයත්වය ඉංජිනේරු Google වෙතින්. මම මෙම පරිවර්තනය මා විසින්ම සකස් කර අධීක්ෂණ ක්‍රියාවලීන් අවබෝධ කර ගැනීමේ මගේම අත්දැකීම් මත විශ්වාසය තැබුවෙමි. ටෙලිග්‍රාම් නාලිකාවේ අධීක්ෂණය_එය и Habré හි අවසන් සටහන මම සේවා මට්ටමේ ඉලක්ක ගැන එම පොතේ 6 වන පරිච්ඡේදයේ පරිවර්තනයක් ද පළ කළෙමි.

බළලා විසින් පරිවර්තනය. කියවීම රසවිඳින්න!

ඇත්ත වශයෙන්ම වැදගත් වන දර්ශක මොනවාද සහ ඒවා මැනීම සහ ඇගයීමට ලක් කරන්නේ කෙසේද යන්න පිළිබඳ අවබෝධයක් නොමැති නම් සේවාවක් කළමනාකරණය කළ නොහැක. මේ සඳහා, අපගේ පරිශීලකයින් අපගේ අභ්‍යන්තර API වලින් එකක් හෝ පොදු නිෂ්පාදනයක් භාවිතා කරන්නේද යන්න නොසලකා, අපි ඔවුන්ට යම් මට්ටමක සේවාවක් නිර්වචනය කර සපයන්නෙමු.

සේවා මට්ටමේ දර්ශක (SLIs), සේවා මට්ටමේ අරමුණු (SLOs) සහ සේවා මට්ටමේ ගිවිසුම් (SLAs) තේරුම් ගැනීමට පරිශීලකයන්ගේ ආශාව පිළිබඳ අපගේ බුද්ධිය, අත්දැකීම් සහ අවබෝධය අපි භාවිතා කරමු. මෙම මානයන් අපට නිරීක්ෂණය කිරීමට අවශ්‍ය ප්‍රධාන ප්‍රමිතික විස්තර කරන අතර අපට අපේක්ෂිත ගුණාත්මක සේවාව සැපයීමට නොහැකි නම් අපි ප්‍රතිචාර දක්වනු ඇත. අවසාන වශයෙන්, නිවැරදි ප්‍රමිතික තෝරා ගැනීම යම් දෙයක් වැරදී ගියහොත් නිවැරදි ක්‍රියාවන්ට මඟ පෙන්වීමට උපකාරී වන අතර, SRE කණ්ඩායමට සේවාවේ සෞඛ්‍යය පිළිබඳ විශ්වාසය ද ලබා දෙයි.

මෙට්‍රික් ආකෘතිකරණය, මෙට්‍රික් තේරීම සහ මෙට්‍රික් විශ්ලේෂණය යන ගැටලුවලට එරෙහිව සටන් කිරීමට අප භාවිතා කරන ප්‍රවේශය මෙම පරිච්ඡේදය විස්තර කරයි. බොහෝ පැහැදිලි කිරීම් උදාහරණ නොමැතිව වනු ඇත, එබැවින් අපි එහි ක්‍රියාත්මක කිරීමේ උදාහරණයේ විස්තර කර ඇති ෂේක්ස්පියර් සේවාව (ෂේක්ස්පියර්ගේ කෘති සෙවීම) ප්‍රධාන කරුණු නිදර්ශනය කිරීමට භාවිතා කරන්නෙමු.

සේවා මට්ටමේ පාරිභාෂිතය

බොහෝ පාඨකයන්ට SLA සංකල්පය හුරුපුරුදු විය හැකි නමුත්, SLI සහ SLO යන පද පරිස්සමෙන් නිර්වචනය කළ යුතුය, මන්ද සාමාන්‍යයෙන් SLA යන පදය අධික ලෙස පටවා ඇති අතර සන්දර්භය අනුව අර්ථ ගණනාවක් ඇති බැවිනි. පැහැදිලිකම සඳහා, අපට මෙම අගයන් වෙන් කිරීමට අවශ්‍යයි.

දර්ශක

SLI යනු සේවා මට්ටමේ දර්ශකයකි - සපයනු ලබන සේවා මට්ටමේ එක් අංශයක ප්‍රවේශමෙන් නිර්වචනය කරන ලද ප්‍රමාණාත්මක මිනුමක්.

බොහෝ සේවා සඳහා, යතුර SLI ඉල්ලීම් ප්‍රමාදය ලෙස සැලකේ - ඉල්ලීමකට ප්‍රතිචාරයක් ලබා දීමට කොපමණ කාලයක් ගතවේද. අනෙකුත් පොදු SLI වලට දෝෂ අනුපාතය ඇතුළත් වේ, බොහෝ විට ලැබෙන සියලුම ඉල්ලීම් වලින් කොටසක් ලෙස ප්‍රකාශ වේ, සහ පද්ධති ප්‍රතිදානය, සාමාන්‍යයෙන් තත්පරයට ඉල්ලීම් වලින් මනිනු ලැබේ. මිනුම් බොහෝ විට එකතු කරනු ලැබේ: අමු දත්ත පළමුව එකතු කර පසුව වෙනස්වීම්, මධ්‍යන්‍ය හෝ ප්‍රතිශතයක් බවට පරිවර්තනය වේ.

ඉතා මැනවින්, SLI සෘජුවම රුචිකත්වයේ සේවා මට්ටම මනිනු ඇත, නමුත් මුල් එක ලබා ගැනීමට හෝ අර්ථ නිරූපණය කිරීමට අපහසු බැවින් සමහර විට මිනුම් සඳහා අදාළ මෙට්‍රික් එකක් පමණක් පවතී. උදාහරණයක් ලෙස, සේවාලාභී පාර්ශ්වයේ ප්‍රමාදය බොහෝ විට වඩාත් යෝග්‍ය මෙට්‍රික් එකක් වේ, නමුත් ප්‍රමාදය සේවාදායකයේ පමණක් මැනිය හැකි අවස්ථා තිබේ.

SRE සඳහා වැදගත් වන තවත් SLI වර්ගයක් වන්නේ ලබා ගත හැකි බව හෝ සේවාවක් භාවිතා කළ හැකි කාලයයි. බොහෝ විට සාර්ථක ඉල්ලීම් අනුපාතය ලෙස අර්ථ දක්වා ඇත, සමහර විට අස්වැන්න ලෙස හැඳින්වේ. (ජීවිත කාලය - දත්ත ගබඩා කිරීමේ පද්ධති සඳහා දිගු කාලයක් සඳහා දත්ත රඳවා තබා ගැනීමේ සම්භාවිතාව ද වැදගත් වේ.) 100% ලබා ගත නොහැකි වුවද, 100% ට ආසන්න ලබා ගැනීම බොහෝ විට ලබා ගත හැකිය; ලබා ගත හැකි අගයන් ප්‍රකාශ කරනු ලැබේ "නවය" ගණන »ලබා ගැනීමේ ප්‍රතිශතය. උදාහරණයක් ලෙස, 99% සහ 99,999% ලබා ගත හැකි බව "2 නවය" සහ "5 නවය" ලෙස ලේබල් කළ හැක. Google Compute Engine හි දැනට ප්‍රකාශිත ලද හැකි ඉලක්කය "තුනහමාර නවය" හෝ 99,95% වේ.

අරමුණු

SLO යනු සේවා මට්ටමේ අරමුණකි: SLI මගින් මනිනු ලබන සේවා මට්ටමක් සඳහා ඉලක්ක අගයක් හෝ අගයන් පරාසයක්. SLO සඳහා සාමාන්‍ය අගයක් වන්නේ “SLI ≤ ඉලක්කය” හෝ “පහළ සීමාව ≤ SLI ≤ ඉහළ සීමාව” වේ. උදාහරණයක් ලෙස, SLO මිලි තත්පර 100ට අඩු සාමාන්‍ය සෙවුම් විමසුම් ප්‍රමාදයකට සැකසීමෙන් අපි ශේක්ස්පියර් සෙවුම් ප්‍රතිඵල “වේගවත්” ලබා දීමට තීරණය කළ හැක.

නිවැරදි SLO තෝරා ගැනීම සංකීර්ණ ක්‍රියාවලියකි. පළමුව, ඔබට සැමවිටම නිශ්චිත අගයක් තෝරා ගත නොහැක. ඔබේ සේවාවට බාහිරින් ලැබෙන HTTP ඉල්ලීම් සඳහා, තත්පරයට විමසුම් (QPS) මෙට්‍රික් මූලික වශයෙන් තීරණය වන්නේ ඔබේ සේවාව වෙත පැමිණීමට ඔබේ පරිශීලකයන්ගේ ආශාව මත වන අතර, ඔබට ඒ සඳහා SLO එකක් සැකසිය නොහැක.

අනෙක් අතට, ඔබට එක් එක් ඉල්ලීම සඳහා සාමාන්‍ය ප්‍රමාදය මිලි තත්පර 100 ට වඩා අඩු වීමට අවශ්‍ය බව පැවසිය හැකිය. එවැනි ඉලක්කයක් තැබීමෙන් අඩු ප්‍රමාදයකින් ඔබේ ඉදිරිපස ලිවීමට හෝ එවැනි ප්‍රමාදයක් ලබා දෙන උපකරණ මිලදී ගැනීමට ඔබට බල කළ හැකිය. (මිලි තත්පර 100 පැහැදිලිවම අත්තනෝමතික අංකයකි, නමුත් ඊටත් වඩා අඩු ප්‍රමාද සංඛ්‍යාවක් තිබීම වඩා හොඳය. මන්දගාමී වේගයට වඩා වේගවත් වේගය හොඳ බව යෝජනා කිරීමට සාක්ෂි තිබේ, සහ ඇතැම් අගයන්ට වඩා වැඩි පරිශීලක ඉල්ලීම් සැකසීමේ ප්‍රමාදය ඇත්ත වශයෙන්ම මිනිසුන්ට ඈත්ව සිටීමට බල කරයි ඔබගේ සේවයෙන්.)

නැවතත්, මෙය බැලූ බැල්මට පෙනෙනවාට වඩා අපැහැදිලි ය: ඔබ ගණනය කිරීමෙන් QPS සම්පූර්ණයෙන්ම බැහැර නොකළ යුතුය. කාරණය නම් QPS සහ ප්‍රමාදය එකිනෙකට දැඩි ලෙස සම්බන්ධ වීමයි: ඉහළ QPS බොහෝ විට ඉහළ ප්‍රමාදයන් ඇති කරයි, සහ සේවා සාමාන්‍යයෙන් යම් බරක් සීමාවකට ළඟා වූ විට කාර්ය සාධනයේ තියුණු අඩුවීමක් අත්විඳියි.

SLO තේරීම සහ ප්‍රකාශනය සේවාව ක්‍රියා කරන ආකාරය පිළිබඳ පරිශීලක අපේක්ෂාවන් සකසයි. මෙම උපායමාර්ගය මන්දගාමී කාර්ය සාධනය වැනි සේවා හිමිකරුට එරෙහිව පදනම් විරහිත පැමිණිලි අඩු කළ හැකිය. පැහැදිලි SLO නොමැතිව, පරිශීලකයින් බොහෝ විට අපේක්ෂිත කාර්ය සාධනය පිළිබඳ ඔවුන්ගේම අපේක්ෂාවන් නිර්මාණය කරයි, එය සේවාව සැලසුම් කරන සහ කළමනාකරණය කරන පුද්ගලයින්ගේ අදහස් සමඟ කිසිදු සම්බන්ධයක් නොතිබිය හැකිය. මෙම තත්වය සේවාවෙන් අපේක්ෂාවන් උද්ධමනය වීමට හේතු විය හැක, පරිශීලකයින් වැරදි ලෙස මෙම සේවාව ඇත්ත වශයෙන්ම වඩා ප්‍රවේශ විය හැකි බව විශ්වාස කරන විට සහ පද්ධතිය ඇත්ත වශයෙන්ම වඩා අඩු විශ්වාසදායක බව පරිශීලකයින් විශ්වාස කරන විට අවිශ්වාසයක් ඇති කරයි.

ගිවිසුම්

සේවා මට්ටමේ ගිවිසුමක් යනු ඔබේ පරිශීලකයින් සමඟ ඇති පැහැදිලි හෝ ව්‍යංග ගිවිසුමක් වන අතර එහි අඩංගු SLOs හමුවීමේ (හෝ හමු නොවීම) ප්‍රතිවිපාක ඇතුළත් වේ. ප්‍රතිවිපාක වඩාත් පහසුවෙන් හඳුනාගත හැක්කේ ඒවා මූල්‍ය - වට්ටමක් හෝ දඩයක් - නමුත් ඒවාට වෙනත් ආකාර ගත හැකිය. SLOs සහ SLAs අතර වෙනස ගැන කතා කිරීමට පහසු ක්‍රමයක් නම් "SLOs හමු නොවුණහොත් කුමක් සිදුවේද?" පැහැදිලි ප්රතිවිපාක නොමැති නම්, ඔබ නිසැකවම SLO එකක් දෙස බලයි.

SLAs ව්‍යාපාර සහ නිෂ්පාදන තීරණවලට සමීපව බැඳී ඇති නිසා SRE සාමාන්‍යයෙන් SLA නිර්මාණය කිරීමට සම්බන්ධ නොවේ. කෙසේ වෙතත්, SRE අසාර්ථක වූ SLO වල ප්‍රතිවිපාක අවම කිරීමට උදව් කිරීමට සම්බන්ධ වේ. ඔවුන්ට SLI තීරණය කිරීමටද උදවු කළ හැක: පැහැදිලිවම, ගිවිසුමේ SLO මැනීමට වෛෂයික ක්‍රමයක් තිබිය යුතුය නැතහොත් එකඟ නොවීම් ඇති වේ.

Google සෙවීම යනු පොදු SLA නොමැති වැදගත් සේවාවක් සඳහා උදාහරණයකි: සෑම කෙනෙකුම හැකි තරම් කාර්යක්ෂම ලෙස සෙවීම භාවිතා කිරීමට අපට අවශ්‍යය, නමුත් අපි ලෝකය සමඟ ගිවිසුමක් අත්සන් කර නැත. කෙසේ වෙතත්, සෙවීමක් නොමැති නම් ප්‍රතිවිපාක තවමත් පවතී - ලබා ගත නොහැකි වීම අපගේ කීර්තිනාමය පහත වැටීමක් මෙන්ම වෙළඳ ප්‍රචාරණ ආදායම අඩු කරයි. Google for Work වැනි වෙනත් බොහෝ Google සේවා, පරිශීලකයන් සමඟ පැහැදිලි සේවා මට්ටමේ ගිවිසුම් ඇත. කිසියම් සේවාවකට SLA තිබේද යන්න නොසලකා, SLI සහ SLO නිර්වචනය කර සේවාව කළමනාකරණය කිරීමට ඒවා භාවිතා කිරීම වැදගත් වේ.

බොහෝ න්‍යායන් - දැන් අත්දැකීමට.

ප්රායෝගිකව දර්ශක

සේවා මට්ටම මැනීමට සුදුසු ප්‍රමිතික තෝරා ගැනීම වැදගත් බව අප නිගමනය කර ඇති හෙයින්, සේවාවක් හෝ පද්ධතියක් සඳහා වැදගත් වන ප්‍රමිතික මොනවාදැයි ඔබ දැන් දන්නේ කෙසේද?

ඔබ සහ ඔබේ පරිශීලකයින් සැලකිලිමත් වන්නේ කුමක් ද?

ඔබට අධීක්ෂණ පද්ධතියක් තුළ නිරීක්ෂණය කළ හැකි සෑම මෙට්‍රික් එකක්ම SLI එකක් ලෙස භාවිත කිරීමට අවශ්‍ය නැත; පද්ධතියකින් පරිශීලකයින්ට අවශ්‍ය දේ තේරුම් ගැනීම ඔබට ප්‍රමිතික කිහිපයක් තෝරා ගැනීමට උපකාරී වේ. බොහෝ දර්ශක තෝරා ගැනීම වැදගත් දර්ශක වෙත අවධානය යොමු කිරීම දුෂ්කර කරයි, කුඩා සංඛ්‍යාවක් තෝරා ගැනීමෙන් ඔබේ පද්ධතියේ විශාල කොටස් අවධානයෙන් තොරව තැබිය හැකිය. අපි සාමාන්‍යයෙන් පද්ධතියක සෞඛ්‍යය තක්සේරු කිරීමට සහ තේරුම් ගැනීමට ප්‍රධාන දර්ශක කිහිපයක් භාවිතා කරමු.

සේවා සාමාන්‍යයෙන් SLI අනුව ඒවාට අදාළ කොටස් කිහිපයකට බෙදිය හැකිය:

• අපගේ උදාහරණයෙන් ෂේක්ස්පියර් සේවාව සඳහා සෙවුම් අතුරුමුහුණත් වැනි අභිරුචි ඉදිරිපස පද්ධති. ඒවා තිබිය යුතුය, ප්‍රමාදයන් නොමැති අතර ප්‍රමාණවත් කලාප පළලක් තිබිය යුතුය. ඒ අනුව, ප්රශ්න ඇසිය හැක: ඉල්ලීමට ප්රතිචාර දැක්විය හැකිද? ඉල්ලීමට ප්‍රතිචාර දැක්වීමට කොපමණ කාලයක් ගත වූවාද? ඉල්ලීම් කීයක් ක්‍රියාවට නැංවිය හැකිද?
• ගබඩා පද්ධති. ඔවුන් අඩු ප්‍රතිචාර ප්‍රමාදය, ලබා ගැනීමේ හැකියාව සහ කල්පැවැත්ම අගය කරයි. ආශ්‍රිත ප්‍රශ්න: දත්ත කියවීමට හෝ ලිවීමට කොපමණ කාලයක් ගතවේද? ඉල්ලීම මත අපට දත්ත වෙත ප්‍රවේශ විය හැකිද? අපට අවශ්‍ය විට දත්ත තිබේද? 26 පරිච්ෙඡ්දය බලන්න දත්ත අඛණ්ඩතාව: ඔබ කියවන දේ මෙම ගැටළු පිළිබඳ සවිස්තරාත්මක සාකච්ඡාවක් සඳහා ඔබ ලියන දෙයයි.
• දත්ත සැකසුම් නල මාර්ග වැනි විශාල දත්ත පද්ධති ප්‍රතිදානය සහ විමසුම් සැකසුම් ප්‍රමාදය මත රඳා පවතී. ආශ්‍රිත ප්‍රශ්න: කොපමණ දත්ත සකසන්නේද? ඉල්ලීමක් ලැබීමේ සිට ප්‍රතිචාරයක් නිකුත් කිරීම දක්වා දත්ත ගමන් කිරීමට කොපමණ කාලයක් ගතවේද? (පද්ධතියේ සමහර කොටස් ඇතැම් අදියරවල ප්‍රමාදයන් ද තිබිය හැක.)

දර්ශක එකතුව

Borgmon වැනි අධීක්ෂණ පද්ධතියක් භාවිතා කරමින් බොහෝ සේවා මට්ටමේ දර්ශක සර්වර් පැත්තේ ස්වභාවිකව එකතු වේ (පහත බලන්න). 10 වන පරිච්ඡේදය කාල ශ්‍රේණි දත්ත මත පදනම්ව ඇඟවීම් පුහුණු කරන්න) හෝ Prometheus, හෝ සරලව වරින් වර ලඝු-සටහන් විශ්ලේෂණය කිරීම, තත්ත්වය 500 සමඟ HTTP ප්‍රතිචාර හඳුනා ගැනීම. කෙසේ වෙතත්, සමහර පද්ධති සේවාලාභී පාර්ශ්වයේ ප්‍රමිතික එකතුවකින් සමන්විත විය යුතුය, මන්ද සේවාදායක පාර්ශ්වයේ අධීක්‍ෂණය නොමැතිකම බලපාන ගැටළු ගණනාවක් මග හැරීමට හේතු විය හැක. පරිශීලකයන්, නමුත් සේවාදායක පාර්ශ්වීය මිනුම් වලට බලපාන්නේ නැත. උදාහරණයක් ලෙස, අපගේ Shakespeare සෙවුම් පරීක්ෂණ යෙදුමේ පසුපෙළ ප්‍රතිචාර ප්‍රමාදය කෙරෙහි අවධානය යොමු කිරීම ජාවාස්ක්‍රිප්ට් ගැටළු හේතුවෙන් පරිශීලක පාර්ශවයේ ප්‍රමාදයක් ඇති විය හැක: මෙම අවස්ථාවෙහිදී, පිටුව සැකසීමට බ්‍රවුසරයට කොපමණ කාලයක් ගතවේද යන්න මැනීම වඩා හොඳ මිනුම් දණ්ඩකි.

එකතු කිරීම

සරල බව සහ භාවිතයේ පහසුව සඳහා, අපි බොහෝ විට අමු මිනුම් එකතු කරමු. මෙය ප්රවේශමෙන් කළ යුතුය.

සමහර ප්‍රමිතික තත්පරයකට ඉල්ලීම් වැනි සරල බව පෙනේ, නමුත් මෙම පෙනෙන ලෙස සරල මිනුම පවා කාලයත් සමඟ දත්ත ව්‍යංගයෙන් එකතු කරයි. මිනුම තත්පරයකට වරක් නිශ්චිතව ලැබී තිබේද නැතහොත් මිනිත්තුවකට ලැබෙන ඉල්ලීම් ගණනට වඩා මැනීම සාමාන්‍ය වේද? අවසාන විකල්පය තත්පර කිහිපයක් පමණක් පවතින ඉතා ඉහළ ක්ෂණික ඉල්ලීම් සංඛ්‍යාවක් සැඟවිය හැක. තත්පරයකට ඉල්ලීම් 200ක් ඉරට්ටේ සංඛ්‍යා සහිතව සහ ඉතිරි කාලය 0 ක් ලබා දෙන පද්ධතියක් සලකා බලන්න. තත්පරයකට ඉල්ලීම් 100 ක සාමාන්‍ය අගයක ස්වරූපයෙන් නියතයක් සහ ක්ෂණික භාරය දෙගුණයක් එකම දෙයක් නොවේ. ඒ හා සමානව, සාමාන්‍ය විමසුම් ප්‍රමාදයන් ආකර්ශනීය බවක් පෙනෙන්නට ඇත, නමුත් එය වැදගත් විස්තරයක් සඟවයි: බොහෝ විමසුම් වේගවත් වීමට ඉඩ ඇත, නමුත් බොහෝ විමසුම් මන්දගාමී වේ.

බොහෝ දර්ශක සාමාන්‍යයට වඩා බෙදාහැරීම් ලෙස වඩා හොඳින් සැලකේ. උදාහරණයක් ලෙස, SLI ප්‍රමාදය සඳහා, සමහර ඉල්ලීම් ඉක්මනින් ක්‍රියාවට නංවනු ඇත, සමහරක් සෑම විටම වැඩි කාලයක් ගතවනු ඇත, සමහර විට බොහෝ කාලයක් ගත වේ. සරල සාමාන්යයක් මෙම දිගු ප්රමාදයන් සැඟවිය හැක. රූපය උදාහරණයක් පෙන්වයි: සාමාන්‍ය ඉල්ලීමක් සේවය කිරීමට ආසන්න වශයෙන් 50 ms ගත වුවද, ඉල්ලීම් වලින් 5% 20 ගුණයකින් මන්දගාමී වේ! සාමාන්‍ය ප්‍රමාදය මත පමණක් පදනම්ව අධීක්‍ෂණය සහ අනතුරු ඇඟවීම දවස පුරා හැසිරීමේ වෙනස්කම් නොපෙන්වයි, ඇත්ත වශයෙන්ම සමහර ඉල්ලීම් (ඉහළම රේඛාව) සැකසීමේ කාලයෙහි කැපී පෙනෙන වෙනස්කම් ඇති විට.

50, 85, 95, සහ 99 ප්‍රතිශත පද්ධති ප්‍රමාදය. Y අක්ෂය ලඝුගණක ආකෘතියේ ඇත.

දර්ශක සඳහා ප්‍රතිශත භාවිතා කිරීමෙන් ඔබට ව්‍යාප්තියේ හැඩය සහ එහි ලක්ෂණ දැකීමට ඉඩ සලසයි: 99 හෝ 99,9 වැනි ඉහළ ප්‍රතිශත මට්ටමක් නරකම අගය පෙන්නුම් කරන අතර සියයට 50 (මධ්‍යමය ලෙසද හැඳින්වේ) වඩාත් නිරන්තර තත්ත්වය පෙන්නුම් කරයි මෙට්රික්. ප්‍රතිචාර කාලය විසරණය වැඩි වන තරමට දිගුකාලීන ඉල්ලීම් පරිශීලක අත්දැකීමට බලපායි. ඉහළ බරක් යටතේ සහ පෝලිම් ඉදිරියේ බලපෑම වැඩි දියුණු වේ. පරිශීලක අත්දැකීම් පර්යේෂණ මගින් පෙන්නුම් කර ඇත්තේ මිනිසුන් සාමාන්‍යයෙන් වැඩි ප්‍රතිචාර කාල විචලනය සහිත මන්දගාමී පද්ධතියකට කැමති බවයි, එබැවින් සමහර SRE කණ්ඩායම් ඉහළ ප්‍රතිශත ලකුණු කෙරෙහි පමණක් අවධානය යොමු කරයි, ප්‍රතිශත 99,9 හි මෙට්‍රික් හැසිරීම යහපත් නම්, බොහෝ පරිශීලකයින්ට ගැටළු ඇති නොවේ. .

සංඛ්යානමය දෝෂ පිළිබඳ සටහන

අපි සාමාන්‍යයෙන් අගයන් සමූහයක මධ්‍යන්‍ය (අංක ගණිත මධ්‍යන්‍ය) ට වඩා ප්‍රතිශත සමඟ වැඩ කිරීමට කැමැත්තෙමු. මෙය බොහෝ විට සාමාන්යයෙන් වඩා සැලකිය යුතු ලෙස වෙනස් (හා වඩා රසවත්) ලක්ෂණ ඇති, වඩාත් විසිරුණු අගයන් සලකා බැලීමට අපට ඉඩ සලසයි. පරිගණක පද්ධතිවල කෘතිම ස්වභාවය හේතුවෙන්, මෙට්‍රික් අගයන් බොහෝ විට විකෘති වේ, උදාහරණයක් ලෙස, කිසිදු ඉල්ලීමකට 0 ms ට අඩු ප්‍රතිචාරයක් ලැබිය නොහැක, සහ ms 1000 කින් කල් ඉකුත්වීම යනු වැඩි අගයන් සමඟ සාර්ථක ප්‍රතිචාර තිබිය නොහැකි බවයි. කල් ඉකුත්වීමට වඩා. එහි ප්‍රතිඵලයක් ලෙස මධ්‍යන්‍ය සහ මධ්‍ය අගය සමාන හෝ එකිනෙකට සමීප විය හැකි බව අපට පිළිගත නොහැක!

පූර්ව පරීක්‍ෂාවකින් තොරව, සහ ඇතැම් සම්මත උපකල්පන සහ ආසන්න කිරීම් පවතින්නේ නම් මිස, අපගේ දත්ත සාමාන්‍යයෙන් බෙදා හරින බව නිගමනය නොකිරීමට අපි ප්‍රවේශම් වෙමු. බෙදා හැරීම අපේක්ෂා කළ පරිදි නොවේ නම්, ගැටළුව විසඳන ස්වයංක්‍රීයකරණ ක්‍රියාවලිය (උදාහරණයක් ලෙස, එය පිටස්තරයින් දකින විට, එය ඉහළ ඉල්ලීම් සැකසුම් ප්‍රමාදයන් සමඟ සේවාදායකය නැවත ආරම්භ කරයි) එය බොහෝ විට හෝ ප්‍රමාණවත් නොවීම (මේ දෙකම සිදු නොවේ. ඉතා හොඳයි).

දර්ශක සම්මත කරන්න

SLI සඳහා සාමාන්‍ය ලක්ෂණ ප්‍රමිතිගත කිරීමට අපි නිර්දේශ කරමු, එවිට ඔබට ඒවා සෑම විටම අනුමාන කිරීමට අවශ්‍ය නොවේ. සම්මත රටා තෘප්තිමත් කරන ඕනෑම විශේෂාංගයක් තනි SLI හි පිරිවිතරයෙන් බැහැර කළ හැක, උදාහරණයක් ලෙස:

• එකතු කිරීමේ කාල පරතරයන්: "සාමාන්‍ය විනාඩි 1 ට වැඩි"
• එකතු කිරීමේ ප්රදේශ: "පොකුරේ සියලුම කාර්යයන්"
• කොපමණ වාරයක් මිනුම් ගනු ලැබේ: "සෑම තත්පර 10 කට වරක්"
• ඇතුළත් කර ඇති ඉල්ලීම් මොනවාද: "HTTP GET වෙතින් කළු පෙට්ටි නිරීක්ෂණ රැකියා"
• දත්ත ලබා ගන්නා ආකාරය: "සේවාදායකයේ මනින ලද අපගේ අධීක්ෂණයට ස්තූතියි"
• දත්ත ප්‍රවේශ ප්‍රමාදය: "අවසාන බයිටයට කාලය"

උත්සාහය සුරැකීමට, එක් එක් පොදු මෙට්‍රික් සඳහා නැවත භාවිත කළ හැකි SLI සැකිලි කට්ටලයක් සාදන්න; යම් SLI යන්නෙන් අදහස් කරන්නේ කුමක්ද යන්න සෑම කෙනෙකුටම තේරුම් ගැනීමට ඒවා පහසු කරයි.

ප්රායෝගිකව ඉලක්ක

ඔබට මැනිය හැකි දේ ගැන නොව ඔබේ පරිශීලකයින් සැලකිලිමත් වන දේ ගැන සිතීමෙන් (හෝ සොයා ගැනීමෙන්!) ආරම්භ කරන්න. බොහෝ විට ඔබේ පරිශීලකයින් සැලකිලිමත් වන දේ මැනීමට අපහසු හෝ කළ නොහැකි ය, එබැවින් ඔබ අවසානයේ ඔවුන්ගේ අවශ්‍යතාවලට සමීප වේ. කෙසේ වෙතත්, ඔබ මැනීමට පහසු දේ සමඟ ආරම්භ කළහොත්, ඔබට අඩු ප්‍රයෝජනවත් SLOs ලැබෙනු ඇත. එහි ප්‍රතිඵලයක් වශයෙන්, මුලින් අපේක්ෂිත ඉලක්ක හඳුනාගෙන පසුව නිශ්චිත දර්ශක සමඟ වැඩ කිරීම දර්ශක තෝරාගෙන ඉලක්ක සපුරා ගැනීමට වඩා හොඳින් ක්‍රියා කරන බව අපි සමහර විට සොයාගෙන ඇත.

ඉලක්ක නිර්වචනය කරන්න

උපරිම පැහැදිලිකම සඳහා, SLO මනිනු ලබන ආකාරය සහ ඒවා වලංගු වන කොන්දේසි නිර්වචනය කළ යුතුය. උදාහරණයක් ලෙස, අපට පහත සඳහන් දේ පැවසිය හැකිය (දෙවන පේළිය පළමුවැන්නයි, නමුත් SLI පෙරනිමි භාවිතා කරයි):

• Get RPC ඇමතුම් වලින් 99%ක් (සාමාන්‍යයෙන් මිනිත්තු 1කට වඩා වැඩි) 100ms ට අඩු කාලයකින් සම්පූර්ණ වේ (සියලු පසුතල සේවාදායක හරහා මනිනු ලැබේ).
• Get RPC ඇමතුම් වලින් 99% ක් 100ms ට අඩු කාලයකින් සම්පූර්ණ වේ.

කාර්ය සාධන වක්‍රවල හැඩය වැදගත් නම්, ඔබට බහු SLOs සඳහන් කළ හැක:

• ලබා ගන්න RPC ඇමතුම් වලින් 90% ක් 1 ms ට අඩු කාලයකින් සම්පූර්ණ කර ඇත.
• ලබා ගන්න RPC ඇමතුම් වලින් 99% ක් 10 ms ට අඩු කාලයකින් සම්පූර්ණ කර ඇත.
• ලබා ගන්න RPC ඇමතුම් වලින් 99.9% ක් 100 ms ට අඩු කාලයකින් සම්පූර්ණ කර ඇත.

ඔබගේ පරිශීලකයින් විෂමජාතීය වැඩ බර ජනනය කරන්නේ නම්: තොග සැකසීම (ප්‍රතිදානය වැදගත් වන) සහ අන්තර්ක්‍රියාකාරී සැකසුම් (ප්‍රමාදය වැදගත් වන), එක් එක් බර පන්තිය සඳහා වෙන වෙනම ඉලක්ක නිර්වචනය කිරීම වටී:

• පාරිභෝගික ඉල්ලීම්වලින් 95%කට ප්‍රතිදානය අවශ්‍ය වේ. ක්‍රියාත්මක කළ RPC ඇමතුම් ගණන සකසන්න <1 s.
• ගනුදෙනුකරුවන්ගෙන් 99%ක් ප්‍රමාදය ගැන සැලකිලිමත් වේ. ගමනාගමනය <1 KB සහ ධාවන <10 ms සමඟ RPC ඇමතුම් ගණන සකසන්න.

SLOs 100% ක්ම සපුරාලන බව අවධාරනය කිරීම යථාර්ථවාදී නොවන සහ නුසුදුසු ය: මෙය නව ක්‍රියාකාරීත්වය සහ යෙදවීම හඳුන්වාදීමේ වේගය අඩු කළ හැකි අතර මිල අධික විසඳුම් අවශ්‍ය වේ. ඒ වෙනුවට, දෝෂ අයවැයකට ඉඩ දීම වඩා හොඳය - පද්ධතිය අක්‍රීය වීමට ඉඩ දී ඇති ප්‍රතිශතය - සහ මෙම අගය දිනපතා හෝ සතිපතා නිරීක්ෂණය කරන්න. ජ්‍යෙෂ්ඨ කළමනාකාරීත්වයට මාසික හෝ කාර්තුමය ඇගයීම් අවශ්‍ය විය හැක. (දෝෂ අයවැය වෙනත් SLO සමඟ සැසඳීම සඳහා හුදෙක් SLO වේ.)

SLO උල්ලංඝනය කිරීම් ප්‍රතිශතය දෝෂ අයවැයට සැසඳිය හැක (පරිච්ඡේදය 3 සහ කොටස බලන්න "දෝෂ අයවැය සඳහා අභිප්රේරණය"), නව නිකුතු යෙදවිය යුත්තේ කවදාද යන්න තීරණය කරන ක්‍රියාවලියට ආදානය ලෙස භාවිතා කරන වෙනස අගය සමඟ.

ඉලක්ක අගයන් තෝරා ගැනීම

තෝරාගත් SLIs, SLOs (සහ සමහරවිට SLAs) තුළ පිළිබිඹු විය යුතු නිෂ්පාදන සහ ව්‍යාපාරික අවශ්‍යතා නිසා සැලසුම් අගයන් (SLOs) තේරීම තනිකරම තාක්ෂණික ක්‍රියාකාරකමක් නොවේ. ඒ හා සමානව, කාර්ය මණ්ඩලය, වෙළඳපොළට කාලය, උපකරණ ලබා ගැනීම සහ මූල්‍යකරණය සම්බන්ධ ගැටළු සම්බන්ධයෙන් තොරතුරු හුවමාරු කර ගැනීමට අවශ්‍ය විය හැකිය. SRE මෙම සංවාදයේ කොටසක් විය යුතු අතර විවිධ විකල්පවල අවදානම් සහ ශක්‍යතාව තේරුම් ගැනීමට උදවු විය යුතුය. වඩාත් ඵලදායී සාකච්ඡාවක් සහතික කිරීමට උපකාර විය හැකි ප්‍රශ්න කිහිපයක් අපි ඉදිරිපත් කර ඇත්තෙමු:

වත්මන් කාර්ය සාධනය මත පදනම්ව ඉලක්කයක් තෝරා නොගන්න.
පද්ධතියක ශක්තීන් සහ සීමාවන් අවබෝධ කර ගැනීම වැදගත් වන අතර, තර්කයකින් තොරව ප්‍රමිතික අනුවර්තනය කිරීමෙන් පද්ධතිය පවත්වාගෙන යාමෙන් ඔබව අවහිර කළ හැකිය: සැලකිය යුතු ප්‍රතිනිර්මාණයකින් තොරව සාක්ෂාත් කර ගත නොහැකි ඉලක්ක සාක්ෂාත් කර ගැනීමට වීරෝදාර උත්සාහයන් අවශ්‍ය වනු ඇත.

එය සරලව තබා ගන්න
සංකීර්ණ SLI ගණනය කිරීම් මඟින් පද්ධතියේ ක්‍රියාකාරීත්වයේ වෙනස්කම් සැඟවිය හැකි අතර ගැටලුවට හේතුව සොයා ගැනීම අපහසු වේ.

නිරපේක්ෂ දේවලින් වළකින්න
ප්‍රමාදය වැඩි නොකර දින නියමයක් නොමැතිව වර්ධනය වන බරක් හැසිරවිය හැකි පද්ධතියක් ඇති කර ගැනීමට පෙළඹෙන නමුත්, මෙම අවශ්‍යතාවය යථාර්ථවාදී නොවේ. එවැනි පරමාදර්ශ වෙත ප්‍රවේශ වන පද්ධතියක් සැලසුම් කිරීමට සහ ගොඩනැගීමට බොහෝ කාලයක් අවශ්‍ය වනු ඇත, ක්‍රියාත්මක කිරීමට මිල අධික වනු ඇත, සහ අඩුවෙන් යමක් කරන පරිශීලකයින්ගේ අපේක්ෂාවන්ට වඩා හොඳ වනු ඇත.

හැකි තරම් SLO කිහිපයක් භාවිතා කරන්න
පද්ධති ගුණාංග පිළිබඳ හොඳ ආවරණයක් සහතික කිරීම සඳහා ප්‍රමාණවත් SLO සංඛ්‍යාවක් තෝරන්න. ඔබ තෝරා ගන්නා SLOs ආරක්ෂා කරන්න: ඔබට නිශ්චිත SLO නියම කිරීමෙන් ප්‍රමුඛතා පිළිබඳ තර්කයක් ජයගත නොහැකි නම්, එම SLO සලකා බැලීම වටින්නේ නැත. කෙසේ වෙතත්, සියලුම පද්ධති ගුණාංග SLO වලට අනුගත නොවේ: SLOs භාවිතයෙන් පරිශීලක ප්‍රසාද මට්ටම ගණනය කිරීම අපහසුය.

පරිපූර්ණත්වය පසුපස හඹා නොයන්න
බර පැටවීම යටතේ පද්ධතියේ හැසිරීම ගැන ඔබ වැඩි විස්තර දැන ගන්නා විට ඔබට කාලයත් සමඟ SLO හි නිර්වචන සහ ඉලක්ක පිරිපහදු කළ හැක. ඔබට ළඟා විය නොහැකි බව පෙනෙන විට ලිහිල් කළ යුතු ඕනෑවට වඩා දැඩි ඉලක්කයක් තෝරා ගැනීමට වඩා කාලයත් සමඟ ඔබ පිරිපහදු කරන පාවෙන ඉලක්කයකින් ආරම්භ කිරීම වඩා හොඳය.

SLOs හට SREs සහ නිෂ්පාදන සංවර්ධකයින් සඳහා ප්‍රමුඛත්වය දීමේ ප්‍රධාන ධාවකයක් විය හැකි අතර ඒවා භාවිතා කරන්නන් සඳහා සැලකිල්ලක් දක්වන බැවිනි. හොඳ SLO යනු සංවර්ධන කණ්ඩායමක් සඳහා ප්‍රයෝජනවත් බලාත්මක මෙවලමකි. නමුත් දුර්වල ලෙස නිර්මාණය කරන ලද SLO, කණ්ඩායම අධික ලෙස ආක්‍රමණශීලී SLO ලබා ගැනීමට වීරෝදාර උත්සාහයක් දරන්නේ නම්, හෝ SLO ඉතා අඩු නම් දුර්වල නිෂ්පාදනයක් අපතේ යන වැඩකට තුඩු දිය හැකිය. SLO යනු බලවත් ලීවරයක්, එය ඥානවන්තව භාවිතා කරන්න.

ඔබේ මිනුම් පාලනය කරන්න

SLI සහ SLO යනු පද්ධති කළමනාකරණය සඳහා භාවිතා කරන ප්‍රධාන අංග වේ:

• SLI පද්ධති අධීක්ෂණය සහ මැනීම.
• SLI SLO හා සසඳා ක්‍රියාමාර්ග අවශ්‍ය දැයි තීරණය කරන්න.
• ක්රියාවක් අවශ්ය නම්, ඉලක්කය සපුරා ගැනීම සඳහා සිදු විය යුතු දේ සොයා ගන්න.
• මෙම ක්‍රියාව සම්පූර්ණ කරන්න.

උදාහරණයක් ලෙස, පියවර 2 මඟින් ඉල්ලීම කාලය අවසන් වී ඇති බවත්, කිසිවක් සිදු නොකළහොත් පැය කිහිපයකින් SLO බිඳී යනු ඇති බවත්, පියවර 3 ට සේවාදායකයන් CPU බැඳී ඇති බවට උපකල්පනය පරීක්ෂා කිරීම ඇතුළත් විය හැකි අතර තවත් සේවාදායකයන් එකතු කිරීමෙන් බර බෙදා හරිනු ඇත . SLO එකක් නොමැතිව, ඔබ ක්‍රියාමාර්ග ගත යුතුද (හෝ කවදාද) දන්නේ නැත.

SLO සකසන්න - එවිට පරිශීලක අපේක්ෂාවන් සැකසෙනු ඇත
SLO ප්‍රකාශනය මඟින් පද්ධති හැසිරීම් සඳහා පරිශීලක අපේක්ෂාවන් සකසයි. පරිශීලකයින්ට (සහ විභව පරිශීලකයින්ට) එය භාවිතයට සුදුසු දැයි තේරුම් ගැනීමට සේවාවකින් අපේක්ෂා කළ යුතු දේ දැන ගැනීමට බොහෝ විට අවශ්‍ය වේ. උදාහරණයක් ලෙස, ඡායාරූප බෙදාගැනීමේ වෙබ් අඩවියක් භාවිතා කිරීමට කැමති පුද්ගලයින්ට, සංරක්ෂිත වාර්තා කළමනාකරණ පද්ධතියක් සඳහා එම සේවාවම වඩාත් සුදුසු වුවද, තරමක් අඩු ලබා ගැනීමේ හැකියාවක් සඳහා දීර්ඝායුෂ සහ අඩු පිරිවැය පොරොන්දු වන සේවාවක් භාවිතා කිරීමෙන් වැළකී සිටීමට අවශ්‍ය විය හැක.

ඔබගේ පරිශීලකයින් සඳහා යථාර්ථවාදී අපේක්ෂාවන් සැකසීමට, පහත උපක්‍රම එකක් හෝ දෙකම භාවිතා කරන්න:

• ආරක්ෂිත සීමාවක් පවත්වා ගන්න. පරිශීලකයින්ට ප්‍රචාරණය කරන දේට වඩා දැඩි අභ්‍යන්තර SLO භාවිතා කරන්න. මෙමගින් ඔබට ගැටළු බාහිරව දෘශ්‍යමාන වීමට පෙර ඒවාට ප්‍රතිචාර දැක්වීමට අවස්ථාව ලබා දේ. SLO බෆරය මඟින් පද්ධතියේ ක්‍රියාකාරීත්වයට බලපාන නිකුතු ස්ථාපනය කිරීමේදී ආරක්‍ෂිත ආන්තිකයක් තිබීමට සහ පරිශීලකයන් අක්‍රිය වීමේදී කලකිරීමට පත් නොවී පද්ධතිය නඩත්තු කිරීමට පහසු බව සහතික කිරීමටද ඉඩ සලසයි.
• පරිශීලක අපේක්ෂාවන් ඉක්මවා නොයන්න. පරිශීලකයන් පදනම් වන්නේ ඔබ පිරිනමන දේ මත මිස ඔබ කියන දේ මත නොවේ. ඔබගේ සේවාවේ සත්‍ය කාර්ය සාධනය ප්‍රකාශිත SLO ට වඩා හොඳ නම්, පරිශීලකයින් වත්මන් කාර්ය සාධනය මත විශ්වාසය තබයි. හිතාමතාම පද්ධතිය වසා දැමීමෙන් හෝ සැහැල්ලු බර යටතේ කාර්ය සාධනය සීමා කිරීමෙන් ඔබට අධික ලෙස යැපීම වළක්වා ගත හැකිය.

පද්ධතියක් අපේක්ෂාවන් කෙතරම් හොඳින් සපුරාලන්නේද යන්න තේරුම් ගැනීම පද්ධතිය වේගවත් කිරීමට සහ එය වඩාත් ප්‍රවේශ විය හැකි සහ ඔරොත්තු දීමේ හැකියාවක් ඇති කිරීමට ආයෝජනය කරන්නේද යන්න තීරණය කිරීමට උපකාරී වේ. විකල්පයක් ලෙස, සේවාවක් ඉතා හොඳින් ක්‍රියාත්මක වන්නේ නම්, තාක්ෂණික ණය ගෙවීම, නව විශේෂාංග එකතු කිරීම හෝ නව නිෂ්පාදන හඳුන්වා දීම වැනි වෙනත් ප්‍රමුඛතා සඳහා කාර්ය මණ්ඩල කාලය වැය කළ යුතුය.

ප්රායෝගිකව ගිවිසුම්

SLA නිර්මාණය කිරීම සඳහා ව්‍යාපාරික සහ නීති කණ්ඩායම් විසින් එය උල්ලංඝනය කිරීම සඳහා වන ප්‍රතිවිපාක සහ දඬුවම් නිර්වචනය කිරීම අවශ්‍ය වේ. SRE හි කාර්යභාරය වන්නේ SLA හි අඩංගු SLOs හමුවීමේදී ඇති විය හැකි අභියෝග තේරුම් ගැනීමට ඔවුන්ට උපකාර කිරීමයි. SLOs නිර්මාණය කිරීම සඳහා වන බොහෝ නිර්දේශ SLAs සඳහා ද අදාළ වේ. ඔබ පරිශීලකයින්ට පොරොන්දු වන දේ සම්බන්ධයෙන් ගතානුගතික වීම නුවණට හුරුය, මන්ද ඔබ සතුව ඇති ප්‍රමාණය, අසාධාරණ හෝ හමුවීමට අපහසු බව පෙනෙන SLA වෙනස් කිරීම හෝ ඉවත් කිරීම අපහසු වේ.

පරිවර්තනය අවසානය දක්වා කියවීමට ස්තූතියි. අධීක්ෂණය පිළිබඳ මගේ විදුලි පණිවුඩ නාලිකාවට දායක වන්න අධීක්ෂණය_එය и මධ්‍යම මත බ්ලොග්.

මූලාශ්රය: www.habr.com