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

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

සාර්ථක නිරීක්ෂණ සහ දැනුම්දීම් පද්ධති ගොඩනැගීම සඳහා Google SRE කණ්ඩායම්වලට මූලික මූලධර්ම සහ හොඳම භාවිතයන් ඇත. මෙම පරිච්ඡේදය මගින් වෙබ් පිටු නරඹන්නෙකුට ඇතිවිය හැකි ගැටළු මොනවාද සහ වෙබ් පිටු ප්‍රදර්ශනය කිරීමට අපහසු වන ගැටළු විසඳන්නේ කෙසේද යන්න පිළිබඳ නිර්දේශ සපයයි.

අර්ථ දැක්වීම්

නිරීක්ෂණයට අදාළ මාතෘකා සාකච්ඡා කිරීමට තනි වචන මාලාවක් භාවිතා නොවේ. Google හි පවා, පහත සඳහන් නියමයන් පොදු භාවිතයේ නැත, නමුත් අපි වඩාත් පොදු අර්ථකථන ලැයිස්තුගත කරන්නෙමු.

අධීක්ෂණය

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

සුදු පෙට්ටිය අධීක්ෂණය

අභ්‍යන්තර සංඛ්‍යාලේඛන උත්පාදනය කරන ලඝු-සටහන්, JVM හෝ HTTP හසුරුවන්න පැතිකඩ ප්‍රමිතික ඇතුළුව, පද්ධති අභ්‍යන්තරයන් විසින් සංදර්ශන කරන ලද ප්‍රමිතික මත පදනම්ව අධීක්ෂණය කිරීම.

කළු පෙට්ටිය අධීක්ෂණය

පරිශීලකයාගේ දෘෂ්ටි කෝණයෙන් යෙදුමේ හැසිරීම පරීක්ෂා කිරීම.

උපකරණ පුවරුව (උපකරණ පුවරු)

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

ඇඟවීම (දැනුම්දීම)

දෝෂ හේතුවෙන් හෝ ඉල්ලීම් පෝලිමේ වැඩි වීමක් හේතුවෙන් ක්‍රියාත්මක විය හැකි විද්‍යුත් තැපෑලෙන් හෝ වෙනත් ආකාරයකින් පුද්ගලයෙකුට ලැබීමට අදහස් කරන දැනුම්දීම්. දැනුම්දීම් වර්ගීකරණය කර ඇත: ටිකට්පත්, ඊමේල් ඇඟවීම් සහ පණිවිඩකරු පණිවිඩ.

මූල හේතුව (මූල හේතුව)

නිවැරදි කළ විට නැවත සිදු නොවිය යුතු මෘදුකාංග දෝෂයක් හෝ මානව දෝෂයක්. ගැටලුවට ප්‍රධාන හේතු කිහිපයක් තිබිය හැකිය: ප්‍රමාණවත් ක්‍රියාවලි ස්වයංක්‍රීයකරණය, මෘදුකාංග දෝෂය, යෙදුම් තර්කනය ප්‍රමාණවත් ලෙස අධ්‍යයනය නොකිරීම. මෙම සෑම සාධකයක්ම මූලික හේතුව විය හැකි අතර, ඒ සෑම එකක්ම ඉවත් කළ යුතුය.

නෝඩ් සහ යන්ත්‍රය (නෝඩ් සහ යන්ත්‍රය)

භෞතික සේවාදායකයක්, අතථ්‍ය යන්ත්‍රයක් හෝ බහාලුමක් මත ධාවනය වන යෙදුමක තනි අවස්ථාවක් වෙත යොමු කිරීමට හුවමාරු කළ හැකි නියමයන්. එක් යන්ත්‍රයක සේවා කිහිපයක් තිබිය හැක. සේවා විය හැක්කේ:

• එකිනෙකට සම්බන්ධ: උදාහරණයක් ලෙස, හැඹිලි සේවාදායකයක් සහ වෙබ් සේවාදායකයක්;
• එකම දෘඪාංගයේ අසම්බන්ධ සේවා: උදාහරණයක් ලෙස, කේත ගබඩාවක් සහ වින්‍යාස පද්ධතියක් සඳහා විශාරදයක්, වැනි රූකඩ හෝ හිස.

තල්ලුව

මෘදුකාංග වින්‍යාසයේ ඕනෑම වෙනසක්.

අධීක්ෂණය අවශ්ය වන්නේ ඇයි

යෙදුම් නිරීක්ෂණය කළ යුතු හේතු කිහිපයක් තිබේ:

දිගුකාලීන ප්රවණතා විශ්ලේෂණය

දත්ත සමුදාය කොතරම් විශාලද සහ එය කෙතරම් වේගයෙන් වර්ධනය වේද? දෛනික පරිශීලක සංඛ්‍යාව වෙනස් වන්නේ කෙසේද?

කාර්ය සාධන සංසන්දනය

Acme Bucket of Bytes 2.72 හි විමසුම් Ajax DB 3.14 ට වඩා වේගවත්ද? අමතර නෝඩයක් දිස් වූ පසු ඉල්ලීම් හැඹිලිගත කිරීම කොතරම් හොඳද? වෙබ් අඩවිය පසුගිය සතියට වඩා මන්දගාමී වී තිබේද?

අනතුරු ඇඟවීම් (දැනුම්දීම්)

යමක් කැඩී ඇති අතර යමෙකු එය නිවැරදි කළ යුතුය. නැත්නම් ඉක්මනින් යමක් කැඩී යයි, යමෙකු ඉක්මනින් එය පරීක්ෂා කළ යුතුය.

උපකරණ පුවරු නිර්මාණය කිරීම

උපකරණ පුවරු මූලික ප්‍රශ්නවලට පිළිතුරු දිය යුතු අතර යමක් ඇතුළත් කළ යුතුය "රන් සංඥා 4" - ප්‍රමාදයන් (ප්‍රමාදය), ගමනාගමනය (රථවාහන), දෝෂ (දෝෂ) සහ පැටවුම් අගය (සන්තෘප්තිය).

අතීත විශ්ලේෂණ පැවැත්වීම (නිදොස්කරණය)

ඉල්ලීම් සැකසීමේ ප්‍රමාදය වැඩි විය, එම අවස්ථාවේදීම සිදුවූයේ කුමක්ද?
අධීක්ෂණ පද්ධති ව්‍යාපාරික බුද්ධි පද්ධති සඳහා දත්ත ප්‍රභවයක් ලෙස සහ ආරක්‍ෂක සිදුවීම් විශ්ලේෂණයට පහසුකම් සැලසීමට ප්‍රයෝජනවත් වේ. මෙම පොත SREs විශේෂඥ දැනුම ඇති ඉංජිනේරු ක්ෂේත්‍ර කෙරෙහි අවධානය යොමු කරන බැවින්, අපි මෙහි නිරීක්ෂණ ශිල්පීය ක්‍රම සාකච්ඡා නොකරමු.

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

මානව ඇඟවීම් පූරණය කිරීම සේවකයාගේ කාලය තරමක් මිල අධික භාවිතයකි. සේවකයා වැඩ කරන්නේ නම්, අනතුරු ඇඟවීම කාර්ය ප්රවාහයට බාධා කරයි. සේවකයා නිවසේ සිටී නම්, අනතුරු ඇඟවීම පුද්ගලික වේලාවට බාධා කරන අතර සමහර විට නින්දට වැටේ. අනතුරු ඇඟවීම් නිතර සිදුවන විට, සේවකයින් පැමිණෙන ඇඟවීම් ඉවත් කිරීම, ප්‍රමාද කිරීම හෝ නොසලකා හරින්න. වරින් වර ඔවුන් සැබෑ අනතුරු ඇඟවීම නොසලකා හරින අතර, එය ශබ්ද සිදුවීම් මගින් ආවරණය කරයි. ඝෝෂාකාරී සිදුවීම් ශීඝ්‍ර ගැටළු හඳුනා ගැනීම සහ විසඳීම වළක්වන බැවින් සේවා බාධා කිරීම් දිගු කාලයක් පැවතිය හැකිය. ඵලදායී මහජන ලිපින පද්ධති හොඳ සංඥා-ශබ්ද අනුපාතයක් ඇත.

අධීක්ෂණ පද්ධතියෙන් සාධාරණ අපේක්ෂාවන් තීරණය කිරීම

සංකීර්ණ යෙදුමක් සඳහා නිරීක්ෂණ පිහිටුවීම සංකීර්ණ ඉංජිනේරු කාර්යයකි. සැලකිය යුතු යටිතල ව්‍යුහයක් එකතු කිරීම, ප්‍රදර්ශනය කිරීම සහ අනතුරු ඇඟවීමේ මෙවලම් සමඟ වුවද, සාමාජිකයින් 10-12 දෙනෙකුගෙන් යුත් Google SRE කණ්ඩායමකට සාමාන්‍යයෙන් අධීක්ෂණ පද්ධති ගොඩනැගීම සහ නඩත්තු කිරීම ප්‍රධාන අරමුණ වන පුද්ගලයන් එක් කෙනෙක් හෝ දෙදෙනෙකු ඇතුළත් වේ. අපි අධීක්ෂණ යටිතල පහසුකම් සාමාන්‍යකරණය කර මධ්‍යගත කරන විට මෙම සංඛ්‍යාව කාලයත් සමඟ අඩු වී ඇත, නමුත් සෑම SRE කණ්ඩායමකට සාමාන්‍යයෙන් අවම වශයෙන් එක් අධීක්ෂණ-පමණි කාර්ය මණ්ඩල සාමාජිකයෙකු සිටී. අධීක්ෂණ පද්ධති උපකරණ පුවරු නැරඹීම තරමක් සිත්ගන්නා කරුණක් වන අතර, SRE කණ්ඩායම් ගැටළු නිරීක්ෂණය කිරීමට යමෙකු තිරය දෙස බැලීමට අවශ්‍ය වන අවස්ථා ප්‍රවේශමෙන් වළක්වන බව පැවසිය යුතුය.

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

Google SRE කණ්ඩායම සංකීර්ණ යැපුම් ධූරාවලිය සමඟ විවිධ මට්ටමේ සාර්ථකත්වයන් සමඟ වැඩ කර ඇත. "ඩේටාබේස් එක ස්ලෝ වෙලා කියලා දැනගත්තොත් මට ඩේටාබේස් ස්ලෝඩවුන් ඇලර්ට් එකක් එනවා, එහෙම නැත්නම් ස්ලෝ සයිට් ඇලර්ට් එකක් එනවා" වැනි නීති අපි භාවිතා කරන්නේ කලාතුරකිනි. යැපීම පදනම් වූ රීති සාමාන්‍යයෙන් දත්ත මධ්‍යස්ථානය වෙත පරිශීලක ගමනාගමනය පෙරීමේ පද්ධතිය වැනි අපගේ පද්ධතියේ වෙනස් නොවන කොටස් වෙත යොමු වේ. උදාහරණයක් ලෙස, "දත්ත මධ්‍යස්ථාන ගමනාගමන පෙරහන වින්‍යාස කර ඇත්නම්, පරිශීලක ඉල්ලීම් සැකසීමේ ප්‍රමාදයන් ගැන මට අනතුරු අඟවන්න එපා" යනු දත්ත මධ්‍යස්ථාන ඇඟවීම් සඳහා වන එක් පොදු රීතියකි. අපගේ යටිතල ව්‍යුහයට අඛණ්ඩ ප්‍රතිනිර්මාණය කිරීමේ නියත අනුපාතයක් ඇති නිසා Google හි කණ්ඩායම් කිහිපයක් සංකීර්ණ පරායත්ත ධුරාවලියට සහාය දක්වයි.

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

ඒ හා සමානව, ශබ්ද මට්ටම අඩු සහ සංඥා මට්ටම ඉහළ මට්ටමක තබා ගැනීමට, අනතුරු ඇඟවීමට ලක්වන වස්තූන් නිරීක්ෂණය කිරීමේ ප්රවේශයන් ඉතා සරල සහ විශ්වසනීය විය යුතුය. මිනිසුන් සඳහා අනතුරු ඇඟවීම් උත්පාදනය කරන නීති තේරුම් ගැනීමට සහ පැහැදිලි ගැටලුවක් ඉදිරිපත් කිරීමට පහසු විය යුතුය.

හේතූන් මත රෝග ලක්ෂණ

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

රෝග ලක්ෂණය
හේතුව

HTTP දෝෂය 500 හෝ 404 ලැබීම
දත්ත සමුදා සේවාදායකයන් සම්බන්ධතා ප්‍රතික්ෂේප කරයි

මන්දගාමී සේවාදායක ප්‍රතිචාර
ඉහළ CPU භාවිතය හෝ හානි වූ ඊතර්නෙට් කේබලය

ඇන්ටාක්ටිකාවේ පරිශීලකයින්ට cat GIFs නොලැබේ
ඔබේ CDN විද්‍යාඥයින්ට සහ බළලුන්ට වෛර කරයි, එබැවින් සමහර IPs අසාදු ලේඛනගත කර ඇත

පුද්ගලික අන්තර්ගතය සෑම තැනකම තිබේ
නව මෘදුකාංග නිකුතුවක් පෙරළීමෙන් ෆයර්වෝලය සියලු ACL අමතක කර සියලු දෙනාටම ඇතුළු වීමට ඉඩ දුන්නේය

"මොකක්ද" සහ "ඇයි" යනු උපරිම සංඥා සහ අවම ශබ්දය සහිත හොඳ නිරීක්ෂණ පද්ධතියක් නිර්මාණය කිරීම සඳහා වඩාත් වැදගත් ගොඩනැඟිලි කොටස් වලින් එකකි.

කළු පෙට්ටිය එදිරිව සුදු පෙට්ටිය

අපි තීරනාත්මක ප්‍රමිතික සඳහා විස්තීර්ණ සුදු පෙට්ටි අධීක්‍ෂණය සහ සාමාන්‍ය කළු පෙට්ටි නිරීක්‍ෂණය ඒකාබද්ධ කරමු. Black-box සහ White-box සංසන්දනය කිරීමට ඇති පහසුම ක්‍රමය නම් Black-box රෝග ලක්ෂණ කේන්ද්‍ර කර ඇති අතර එය ක්‍රියාශීලී නිරීක්ෂණයකට වඩා ප්‍රතික්‍රියාශීලී වීමයි: "පද්ධතිය මේ මොහොතේ නිවැරදිව ක්‍රියා නොකරයි." White-box පද්ධතිවල අභ්‍යන්තර පිරික්සුම් හැකියාවන් මත රඳා පවතී: සිදුවීම් ලොග හෝ වෙබ් සේවාදායකයන්. මේ අනුව, වයිට්-බොක්ස් ඔබට ඉදිරියට එන ගැටළු හඳුනා ගැනීමට ඉඩ සලසයි, ඉල්ලීමක් නැවත සම්ප්‍රේෂණය කිරීමක් ලෙස පෙනෙන අක්‍රමිකතා යනාදිය.

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

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

අනතුරු ඇඟවීම් යැවීමේදී කළු පෙට්ටි නිරීක්ෂණයට ප්‍රධාන වාසියක් ඇත: ගැටලුව දැනටමත් සැබෑ රෝග ලක්ෂණ ඇති කර ඇති විට ඔබ ලබන්නාට දැනුම් දීමක් සිදු කරයි. අනෙක් අතට, තවමත් මතුවී නැති නමුත් ඉදිරියට එන Black-box ප්‍රශ්නයට නිරීක්ෂණය කිරීමෙන් පලක් නැත.

රන් සංඥා හතරක්

ස්වර්ණමය නිරීක්ෂණ සංඥා හතර වන්නේ ප්‍රමාදය, ගමනාගමනය, දෝෂ සහ සන්තෘප්තියයි. ඔබට මැනිය හැක්කේ පරිශීලක පද්ධති ප්‍රමිතික හතරක් පමණක් නම්, එම හතර කෙරෙහි අවධානය යොමු කරන්න.

ප්‍රමාදය

ඉල්ලීම සැකසීමට ගතවන කාලය. සාර්ථක සහ අසාර්ථක ඉල්ලීම්වල ප්‍රමාදය අතර වෙනස හඳුනා ගැනීම වැදගත්ය. උදාහරණයක් ලෙස, දත්ත සමුදායකට හෝ වෙනත් පසුබිමකට නැතිවූ සම්බන්ධතාවයක් නිසා ඇති වූ HTTP 500 දෝෂයක් ඉතා ඉක්මනින් හඳුනාගත හැකිය, කෙසේ වෙතත්, HTTP 500 දෝෂයක් අසාර්ථක ඉල්ලීමක් දැක්විය හැක. සමස්ත ප්‍රමාදය මත 500 දෝෂයක බලපෑම සොයා ගැනීම වැරදි නිගමනවලට තුඩු දිය හැකිය. අනෙක් අතට, මන්දගාමී දෝෂයක් පවා වේගවත් දෝෂයකි! එමනිසා, දෝෂ පෙරීමට වඩා දෝෂ ප්‍රමාදය නිරීක්ෂණය කිරීම වැදගත් වේ.

රථවාහන

ඉහළ මට්ටමේ පද්ධති ප්‍රමිතිකවලින් මනිනු ලබන, ඔබේ පද්ධතියට ඉල්ලීම් ගණන. වෙබ් සේවාවක් සඳහා, මෙම මිනුම සාමාන්‍යයෙන් නියෝජනය කරන්නේ තත්පරයකට HTTP ඉල්ලීම් සංඛ්‍යාව ඉල්ලීම්වල ස්වභාවය අනුව බෙදීමයි (උදාහරණයක් ලෙස, ස්ථිතික හෝ ගතික අන්තර්ගතය). ශ්‍රව්‍ය ප්‍රවාහ පද්ධතියක් සඳහා, මෙම මිනුම ජාල I/O අනුපාතය හෝ සමගාමී සැසි ගණන මත කේන්ද්‍රගත විය හැක. ප්‍රධාන අගය ගබඩා කිරීමේ පද්ධතියක් සඳහා, මෙම මිනුම තත්පරයට ගනුදෙනු හෝ සෙවීම් විය හැකිය.

වැරදි

මෙය අසාර්ථක ඉල්ලීම් අනුපාතය, පැහැදිලිවම (උදාහරණයක් ලෙස, HTTP 500), ව්‍යංගයෙන් (උදාහරණයක් ලෙස, HTTP 200 නමුත් නරක අන්තර්ගතය සමඟ ඒකාබද්ධව), හෝ ප්‍රතිපත්ති අනුව (උදාහරණයක් ලෙස, "ඔබ එක් තත්පරයකින් ප්‍රතිචාරයක් ග්‍රහණය කළහොත්, ඕනෑම තත්පරයක් දෝෂයකි"). සියලුම අසාර්ථක තත්ත්වයන් ප්‍රකාශ කිරීමට ප්‍රමාණවත් HTTP ප්‍රතිචාර කේත නොමැති නම්, අර්ධ අසාර්ථකත්වය හඳුනා ගැනීමට ද්විතියික (අභ්‍යන්තර) ප්‍රොටෝකෝල අවශ්‍ය විය හැකිය. එවැනි සියලු වැරදි ඉල්ලීම් අධීක්‍ෂණය කිරීම තොරතුරු රහිත විය හැකි අතර, අන්තයේ සිට අවසානය දක්වා පද්ධති පරීක්ෂණ මඟින් ඔබ වැරදි අන්තර්ගතයක් සකසන බව සොයා ගැනීමට උදවු කළ හැක.

සන්තෘප්තිය

මෙට්‍රික් ඔබේ සේවාව කෙතරම් දැඩි ලෙස භාවිත කරන්නේ දැයි පෙන්වයි. මෙය වඩාත්ම සීමිත සම්පත් හඳුනා ගන්නා පද්ධති අධීක්ෂණ මිනුමකි (නිදසුනක් ලෙස, සීමිත මතකයක් ඇති පද්ධතියක, මතකය පෙන්වයි, සීමිත I / O සහිත පද්ධතියක, I / O ගණන පෙන්වයි). බොහෝ පද්ධති 100% භාවිතයට පැමිණීමට පෙර පිරිහෙන බව සලකන්න, එබැවින් භාවිත ඉලක්කයක් තිබීම අත්‍යවශ්‍ය වේ.

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

අවසාන වශයෙන්, සන්තෘප්තිය ඉදිරි සන්තෘප්තිය පිළිබඳ අනාවැකි සමඟ ද සම්බන්ධ වේ, එනම්: "ඔබේ දත්ත සමුදාය පැය 4 කින් ඔබේ දෘඪ තැටිය පුරවනු ඇති බව පෙනේ."

ඔබ ස්වර්ණමය සංඥා හතරම මනින්නේ නම් සහ ප්‍රමිතික වලින් එකක ගැටලුවක් ඇති විට (හෝ, සන්තෘප්තියේ නම්, පාහේ ගැටලුවක්), ඔබ පුද්ගලයාට දන්වන්නේ නම්, ඔබේ සේවාව අඩු වැඩි වශයෙන් නිරීක්ෂණයෙන් ආවරණය වනු ඇත.

වලිගය ගැන කරදර වීම (හෝ උපකරණ සහ කාර්ය සාධනය)

මුල සිටම අධීක්ෂණ පද්ධතියක් ගොඩනඟන විට, සාමාන්‍ය ප්‍රමාදය, සාමාන්‍ය නෝඩ් CPU භාවිතය හෝ සාමාන්‍ය දත්ත සමුදා පදිංචිය මත පදනම්ව පද්ධතියක් සංවර්ධනය කිරීමට පෙළඹේ. අවසාන උදාහරණ දෙකේ අන්තරාය පැහැදිලිය: ප්‍රොසෙසර සහ දත්ත සමුදායන් ඉතා අනපේක්ෂිත ආකාරයකින් බැහැර කරනු ලැබේ. ප්‍රමාදයට ද එය අදාළ වේ. ඔබ තත්පරයකට ඉල්ලීම් 100 බැගින් සාමාන්‍ය 1000ms ප්‍රමාදයක් සහිත වෙබ් සේවාවක් පවත්වාගෙන යන්නේ නම්, ඉල්ලීම්වලින් 1%කට තත්පර 5ක් ගත විය හැක. පරිශීලකයන් එවැනි වෙබ් සේවා කිහිපයක් මත රඳා පවතී නම්, තනි පසුබිමක 99 වැනි ප්‍රතිශතය පහසුවෙන් අතුරු මුහුණතේ මධ්‍ය ප්‍රතිචාර කාලය බවට පත් විය හැක.

මන්දගාමී සාමාන්‍යයක් සහ ඉතා මන්දගාමී ඉල්ලීම් අතර වෙනස හඳුනා ගැනීමට ඇති සරලම ක්‍රමය නම් සත්‍ය ප්‍රමාදයන් වෙනුවට සංඛ්‍යාලේඛනවල ප්‍රකාශිත ඉල්ලීම්වල මිනුම් එකතු කිරීමයි (හිස්ටෝග්‍රෑම් ප්‍රදර්ශනය කිරීමට සුදුසු මෙවලමකි), ලබා ගත් සේවාව මගින් කොපමණ ඉල්ලීම් ලබා දුන්නේද? 0 ms සහ 10ms අතර, 10ms සහ 30ms අතර, 30ms සහ 100ms අතර, 100ms සහ 300ms අතර, ආදිය. histogram සීමාවන් ආසන්න වශයෙන් ඝාතීය ලෙස (3 ගුණයකින් පමණ) පුළුල් කිරීම ඉල්ලීම් බෙදා හැරීම දෘශ්‍යමාන කිරීමට බොහෝ විට පහසු ක්‍රමයකි.

මිනුම් සඳහා නිවැරදි කැටිති තෝරා ගැනීම

පද්ධතියේ විවිධ මූලද්රව්ය විවිධ මට්ටම්වල විස්තර සහිතව මැනිය යුතුය. උදාහරණ වශයෙන්:

• යම් කාල පරිච්ඡේදයක් තුළ CPU භාවිත භාවිතය නැරඹීමෙන් ඉහළ ප්‍රමාදයන් ඇති කරන දිගු කරල් නොපෙන්වයි.
• අනෙක් අතට, වසරකට පැය 9කට වඩා අක්‍රිය කාලය (99,9% වාර්ෂික අතිකාල) ඉලක්ක කරගත් වෙබ් සේවාවක් සඳහා, HTTP 200 ප්‍රතිචාරය විනාඩියකට වරක් හෝ දෙවරකට වඩා පරීක්ෂා කිරීම අනවශ්‍ය ලෙස නිතර සිදු විය හැක.
• ඒ හා සමානව, සෑම විනාඩි 99,9-1 කට වරක් වඩා 2% ලබා ගැනීම සඳහා දෘඪ තැටියේ නිදහස් ඉඩ පරීක්ෂා කිරීම අනවශ්ය විය හැකිය.

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

1. සෑම තත්පරයකම CPU භාවිතය මැන බලන්න.
2. විස්තරය 5% දක්වා අඩු කරන්න.
3. සෑම මිනිත්තුවකම ප්‍රමිතික එකතු කරන්න.

විශ්ලේෂණය සහ ගබඩා කිරීම සඳහා ඉහළ පොදු කාර්ය අත්විඳීමෙන් තොරව ඉහළ කැටිති දත්ත රැස් කිරීමට මෙම උපාය මාර්ගය ඔබට ඉඩ සලසයි.

හැකි තරම් සරල, නමුත් පහසු නොවේ

විවිධ අවශ්‍යතා එකිනෙක ගොඩගැසීම ඉතා සංකීර්ණ අධීක්ෂණ පද්ධතියකට මඟ පෑදිය හැක. උදාහරණයක් ලෙස, ඔබේ පද්ධතියට පහත සංකීර්ණ අංග තිබිය හැක:

• ඉල්ලීම් ප්‍රමාදය සඳහා විවිධ සීමාවන්ට අනුව, විවිධ ප්‍රතිශතවලින්, සියලු වර්ගවල විවිධ ප්‍රමිතික හරහා ඇඟවීම්.
• විය හැකි හේතු හඳුනා ගැනීමට සහ හඳුනා ගැනීමට අමතර කේතයක් ලිවීම.
• ගැටළු ඇති විය හැකි එක් එක් හේතු සඳහා අදාළ උපකරණ පුවරු සාදන්න.

විය හැකි සංකූලතා මූලාශ්ර කිසිදා අවසන් නොවේ. සියලුම මෘදුකාංග පද්ධති මෙන්, අධීක්‍ෂණය ඉතා සංකීර්ණ විය හැකි අතර එය බිඳෙනසුලු, වෙනස් කිරීමට සහ නඩත්තු කිරීමට අපහසු වේ.

එමනිසා, හැකිතාක් සරල කිරීමට ඔබේ අධීක්ෂණ පද්ධතිය සැලසුම් කරන්න. නිරීක්ෂණය කළ යුතු දේ තෝරාගැනීමේදී, පහත සඳහන් කරුණු මතක තබා ගන්න:

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

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

මූලධර්ම එකට සම්බන්ධ කිරීම

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

අධීක්ෂණ සහ අනතුරු ඇඟවීමේ රීති නිර්මාණය කිරීමේදී, පහත සඳහන් ප්‍රශ්න ඇසීමෙන් ඔබට ව්‍යාජ ධනාත්මක සහ අනවශ්‍ය ඇඟවීම් වළක්වා ගත හැක:

• මෙම රීතිය හදිසි, ක්‍රියාවට කැඳවන සහ අනිවාර්යයෙන්ම පරිශීලකයාට බලපාන වෙනත් ආකාරයකින් හඳුනාගත නොහැකි පද්ධති තත්වයක් අනාවරණය කරයිද?
• එය හිතකර බව දැන දැන මට මෙම අනතුරු ඇඟවීම නොසලකා හැරිය හැකිද? මට මෙම අනතුරු ඇඟවීම නොසලකා හැරිය හැක්කේ කවදාද සහ ඇයි සහ මට මෙම අවස්ථාව මග හැරිය හැක්කේ කෙසේද?
• මෙම ඇඟවීමෙන් අදහස් වන්නේ පරිශීලකයින්ට අහිතකර ලෙස බලපාන බව ද? පරිශීලකයින්ට සෘණාත්මක බලපෑමක් ඇති නොවන අවස්ථා තිබේද, උදාහරණයක් ලෙස, රථවාහන පෙරීම හේතුවෙන් හෝ පරීක්ෂණ පද්ධති භාවිතා කරන විට, පෙරහන් කළ යුතු ඇඟවීම්?
• මෙම ඇඟවීමට ප්‍රතිචාර වශයෙන් මට ක්‍රියාමාර්ග ගත හැකිද? මෙම පියවර හදිසිද නැතහොත් ඔවුන්ට උදෑසන වන තුරු බලා සිටිය හැකිද? ක්‍රියාව ස්වයංක්‍රීය කිරීම ආරක්ෂිතද? මෙම ක්‍රියාව දිගු කාලීන විසඳුමක් හෝ කෙටි කාලීන විසඳුමක් වේවිද?
• සමහර අයට මෙම ගැටලුව සඳහා බහුවිධ ඇඟවීම් ලැබේ, එබැවින් සංඛ්‍යාව අඩු කළ හැකිද?

මෙම ප්‍රශ්න මගින් ඇඟවීම් සහ අනතුරු ඇඟවීමේ පද්ධති පිළිබඳ මූලික දර්ශනය පිළිබිඹු වේ:

• අනතුරු ඇඟවීමක් එන සෑම අවස්ථාවකම, මට හදිසි ප්‍රතිචාරයක් දැක්විය යුතුය. මම වෙහෙසට පත්වීමට පෙර දිනකට කිහිප වතාවක් ඉක්මන් කළ හැකිය.
• සෑම ඇඟවීමක්ම යාවත්කාලීන විය යුතුය.
• අනතුරු ඇඟවීමක් සඳහා සෑම ප්‍රතිචාරයක්ම මිනිස් මැදිහත්වීම අවශ්‍ය විය යුතුය. දැනුම්දීම ස්වයංක්‍රීයව සැකසිය හැකි නම්, එය නොපැමිණිය යුතුය.
• ඇඟවීම් නව ගැටලුවක් හෝ පෙර සිදු නොවූ සිදුවීමක් විය යුතුය.

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

දිගු කාලීන අධීක්ෂණය

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

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

Bigtable SRE: අධික ලෙස අනතුරු ඇඟවීම පිළිබඳ කතාවක්

Google හි අභ්‍යන්තර යටිතල පහසුකම් සාමාන්‍යයෙන් සපයනු ලබන අතර සේවා මට්ටම (SLO) අනුව මනිනු ලැබේ. වසර ගණනාවකට පෙර, Bigtable සේවාවේ SLO පදනම් වූයේ ධාවනය වන සේවාලාභියෙකු අනුකරණය කරන කෘතිම ගනුදෙනුවක සාමාන්‍ය කාර්ය සාධනය මතය. Bigtable හි ඇති ගැටළු සහ ගබඩා තොගයේ පහළ මට්ටම් හේතුවෙන්, සාමාන්‍ය කාර්ය සාධනය "විශාල" වලිගයකින් ධාවනය විය: නරකම 5% විමසුම් බොහෝ විට අනෙක් ඒවාට වඩා සැලකිය යුතු ලෙස මන්දගාමී විය.

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

තත්වයට පිළියමක් ලෙස, කණ්ඩායම තුන්-වැදෑරුම් ප්‍රවේශයක් භාවිතා කළා: Bigtable හි කාර්ය සාධනය වැඩි දියුණු කිරීමට වෙහෙස මහන්සි වී වැඩ කරන අතරතුර, අපි අපගේ SLO ඉලක්කය ලෙස විමසුම් ප්‍රතිචාර ප්‍රමාදය සඳහා 75 වැනි ප්‍රතිශතය තාවකාලිකව සකස් කළෙමු. අපි විද්‍යුත් තැපැල් ඇඟවීම් ද ක්‍රියා විරහිත කළෙමු, ඒවායින් බොහොමයක් ඇති බැවින් ඒවා රෝග විනිශ්චය කිරීමට කාලය නාස්ති කළ නොහැක.

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

Gmail: පුරෝකථනය කළ හැකි, ඇල්ගොරිතම මානව ප්‍රතිචාර

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

එකල, ජීමේල් අධීක්‍ෂණය ව්‍යුහගත කර තිබුණේ කාර්ය පෝලිම භාවිතයෙන් එක් එක් කාර්යයන් අවලංගු කළ විට ඇඟවීම් නිකුත් වන පරිදි ය. මෙම ප්‍රවේශය සුදුසු නොවීය, මන්ද ඒ වන විටත් Gmail විසින් බොහෝ කාර්යයන් දහස් ගණනක් සිදු කර ඇති අතර, ඒ සෑම එකක්ම අපගේ පරිශීලකයින්ගෙන් සියයට ගණනකට ලබා දී ඇත. Gmail පරිශීලකයින්ට හොඳ පරිශීලක අත්දැකීමක් ඇති බව සහතික කිරීමට අපි දැඩි සැලකිල්ලක් දැක්වූ නමුත් බොහෝ ඇඟවීම් හැසිරවීම ප්‍රශ්නයෙන් තොර විය.

මෙම ගැටළුව විසඳීම සඳහා, Gmail SRE විසින් පරිශීලකයින්ට ඇති බලපෑම අවම කිරීම සඳහා හැකිතාක් දුරට උපලේඛනය නිදොස්කරණය කිරීමට මෙවලමක් නිර්මාණය කළේය. ගැටලුව සොයාගැනීමේ සිට එය නිවැරදි කිරීම දක්වා දීර්ඝ කාලීන විසඳුමක් ලැබෙන තුරු සමස්ත චක්‍රයම සරලව ස්වයංක්‍රීය කරන්නේද යන්න පිළිබඳව කණ්ඩායම සාකච්ඡා කිහිපයක් පැවැත්වූ නමුත්, එවැනි විසඳුමක් මඟින් ගැටලුවේ සැබෑ නිරාකරණය ප්‍රමාද වනු ඇතැයි ඇතැමුන් කනස්සල්ලට පත්ව සිටියහ.

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

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

දීර්ඝ කාලීන

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

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

නිගමනය

සෞඛ්‍ය සම්පන්න අධීක්ෂණය සහ ඇඟවීම් සඳහා මාර්ගය සරල සහ සරල ය. එය අනතුරු ඇඟවීම් ජනනය වන ගැටලුවේ රෝග ලක්ෂණ කෙරෙහි අවධානය යොමු කරයි, සහ හේතුව නිරීක්ෂණය කිරීම ගැටළු නිදොස් කිරීම සඳහා ආධාරකයක් ලෙස සේවය කරයි. දත්ත සමුදාය පැටවීම සහ කාර්ය සාධනය අධීක්ෂණය සෘජුවම දත්ත සමුදාය මතම සිදු කළ යුතු වුවද, ඔබ පාලනය කරන තොගයේ ඔබ සිටින තරමට රෝග ලක්ෂණ නිරීක්ෂණය පහසු වේ. විද්‍යුත් තැපැල් දැනුම්දීම් ඉතා සීමිත ප්‍රයෝජනයක් වන අතර පහසුවෙන් ඝෝෂාව දක්වා වර්ධනය වීමට නැඹුරු වේ; ඒ වෙනුවට, ඔබ විද්‍යුත් තැපෑලෙන් දැනුම් දෙන සියලුම වත්මන් ගැටළු නිරීක්ෂණය කරන උපකරණ පුවරුවක් භාවිතා කළ යුතුය. ඉතිහාසගත සහසම්බන්ධතා විශ්ලේෂණය කිරීමට උපකරණ පුවරුව සිදුවීම් ලොගයක් සමඟද යුගල කළ හැක.

දිගු කාලීනව, රෝග ලක්ෂණ අනතුරු ඇඟවීම් සහ ආසන්න සැබෑ ගැටළු අතර සාර්ථක ප්‍රත්‍යාවර්තයක් සාක්ෂාත් කර ගැනීම අවශ්‍ය වන අතර, අධීක්ෂණය වේගවත් රෝග විනිශ්චය සඳහා සහාය වන බව සහතික කිරීම සඳහා ඉලක්ක අනුගත විය යුතුය.

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

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