SRE (የጣቢያ አስተማማኝነት ምህንድስና) የድር ፕሮጄክቶችን ተደራሽ የማድረግ አቀራረብ ነው። ለዴቭኦፕስ እንደ ማዕቀፍ ይቆጠራል እና በDevOps አተገባበር እንዴት እንደሚሳካ ይነግራል። ይህ ጽሑፍ ይተረጎማል ምዕራፍ 4 የአገልግሎት ደረጃ ዓላማዎች መጽሐፎች የጣቢያ አስተማማኝነት ምህንድስና ከ Google. እኔ ራሴ ይህንን ትርጉም አዘጋጅቼ የክትትል ሂደቶችን በመረዳት በራሴ ልምድ ተመክቻለሁ። በቴሌግራም ቻናል ሞኒተሪም_ነው и በ Habré ላይ የመጨረሻው ልጥፍ እኔም ስለ የአገልግሎት ደረጃ ግቦች የዚሁ መጽሐፍ ምዕራፍ 6 ትርጉም አሳትሜያለሁ።

በድመት ትርጉም. በማንበብ ይደሰቱ!

ምን ጠቋሚዎች በትክክል አስፈላጊ እንደሆኑ እና እንዴት እንደሚለኩ እና እንደሚገመግሙ ምንም መረዳት ከሌለ አገልግሎቱን ማስተዳደር አይቻልም። ለዚህም፣ ከውስጣችን ኤፒአይዎች ወይም ይፋዊ ምርቶች ምንም ቢሆኑም፣ ለተጠቃሚዎቻችን የተወሰነ የአገልግሎት ደረጃን እንገልፃለን እና እንሰጣለን።

የአገልግሎት ደረጃ አመላካቾችን (SLIs)፣ የአገልግሎት ደረጃ አላማዎችን (SLOs) እና የአገልግሎት ደረጃ ስምምነቶችን (SLAs) ለመረዳት የተጠቃሚዎች ፍላጎት ያላቸውን ግንዛቤ፣ ልምድ እና ግንዛቤ እንጠቀማለን። እነዚህ ልኬቶች ልንቆጣጠራቸው የምንፈልጋቸውን ዋና መለኪያዎች ይገልፃሉ እና የሚጠበቀውን የአገልግሎት ጥራት ማቅረብ ካልቻልን ምላሽ የምንሰጥባቸው። በመጨረሻም ትክክለኛ መለኪያዎችን መምረጥ የሆነ ችግር ከተፈጠረ ትክክለኛዎቹን ድርጊቶች ለመምራት ይረዳል, እና እንዲሁም የ SRE ቡድን በአገልግሎቱ ጤና ላይ እምነት እንዲኖረው ያደርጋል.

ይህ ምዕራፍ የሜትሪክ ሞዴሊንግ፣ የሜትሪክ ምርጫ እና የሜትሪክ ትንተና ችግሮችን ለመዋጋት የምንጠቀመውን አካሄድ ይገልጻል። አብዛኛው ማብራርያ ያለ ምሳሌ ይሆናል ስለዚህ በአተገባበር ምሳሌው ላይ የተገለፀውን የሼክስፒር አገልግሎት (የሼክስፒርን ስራዎች ፈልግ) ዋና ዋና ነጥቦቹን እንጠቀማለን።

የአገልግሎት ደረጃ ቃላት

ብዙ አንባቢዎች ስለ SLA ጽንሰ-ሀሳብ ሊያውቁ ይችላሉ ነገር ግን SLI እና SLO የሚሉት ቃላት ጥንቃቄ የተሞላበት ፍቺ ይገባቸዋል ምክንያቱም በአጠቃላይ SLA የሚለው ቃል ከመጠን በላይ የተጫነ እና እንደ አውድ ላይ በመመስረት በርካታ ትርጉሞች አሉት። ግልጽ ለማድረግ, እነዚህን እሴቶች መለየት እንፈልጋለን.

ጠቋሚዎች

SLI የአገልግሎት ደረጃ አመልካች ነው—በጥንቃቄ የተገለጸ የአንድ የአገልግሎት ደረጃ መለኪያ መለኪያ።

ለአብዛኛዎቹ አገልግሎቶች ቁልፉ SLI እንደ የጥያቄ መዘግየት ይቆጠራል - ለጥያቄ ምላሽ ለመመለስ ምን ያህል ጊዜ ይወስዳል። ሌሎች የተለመዱ SLIዎች የስህተት መጠን፣ ብዙ ጊዜ ከተቀበሉት የጥያቄዎች ሁሉ ክፍልፋይ እና የስርዓት ውፅዓት፣ አብዛኛውን ጊዜ በሰከንድ ጥያቄዎች ይለካሉ። መለኪያዎች ብዙ ጊዜ ይሰባሰባሉ፡ ጥሬ መረጃ በመጀመሪያ ይሰበሰባል ከዚያም ወደ ለውጥ፣ አማካኝ ወይም መቶኛ ይቀየራል።

በሐሳብ ደረጃ፣ SLI በቀጥታ የሚለካው የአገልግሎት የፍላጎት ደረጃን ነው፣ ነገር ግን አንዳንድ ጊዜ ተዛማጅ መለኪያ ብቻ ለመለካት ይገኛል ምክንያቱም ዋናው ለማግኘት ወይም ለመተርጎም አስቸጋሪ ነው። ለምሳሌ፣ የደንበኛ-ጎን መዘግየት ብዙውን ጊዜ ይበልጥ ተገቢ መለኪያ ነው፣ ነገር ግን መዘግየት በአገልጋዩ ላይ ብቻ የሚለካባቸው ጊዜያት አሉ።

ለኤስአርኤዎች አስፈላጊ የሆነው ሌላው የSLI አይነት መገኘት ወይም አገልግሎትን መጠቀም የሚቻልበት የጊዜ ክፍል ነው። ብዙውን ጊዜ የተሳካላቸው ጥያቄዎች መጠን ተብሎ ይገለጻል፣ አንዳንዴም ምርት ይባላል። (የህይወት ዘመን—መረጃው ረዘም ላለ ጊዜ የመቆየቱ እድል - ለመረጃ ማከማቻ ስርዓቶችም አስፈላጊ ነው። የ"ዘጠኝ" ብዛት" የመገኛ መቶኛ። ለምሳሌ፣ 100% እና 100% ተገኝነት እንደ "99 nines" እና "99,999 nines" ተብሎ ሊሰየም ይችላል። የGoogle Compute Engine የአሁኑ የተገኝነት ግብ "ሶስት ተኩል ዘጠኝ" ወይም 2% ነው።

ዓላማዎች

SLO የአገልግሎት ደረጃ ዓላማ ነው፡ በSLI ለሚለካ የአገልግሎት ደረጃ የታለመ እሴት ወይም የእሴቶች ክልል። የ SLO መደበኛ እሴት "SLI ≤ ዒላማ" ወይም "ዝቅተኛ ገደብ ≤ SLI ≤ የላይኛው ገደብ" ነው። ለምሳሌ፣ SLO ን በአማካይ ከ100 ሚሊሰከንድ ያነሰ የፍለጋ መጠይቅ በማዘጋጀት የሼክስፒርን የፍለጋ ውጤቶችን “በፍጥነት” እንደምንመልስ ልንወስን እንችላለን።

ትክክለኛውን SLO መምረጥ ውስብስብ ሂደት ነው። በመጀመሪያ፣ ሁልጊዜ የተወሰነ እሴት መምረጥ አይችሉም። ለአገልግሎትዎ የውጭ ገቢ HTTP ጥያቄዎች የጥያቄ በሰከንድ (QPS) መለኪያ በዋነኝነት የሚወሰነው በተጠቃሚዎችዎ አገልግሎትን ለመጎብኘት ባላቸው ፍላጎት ነው እና ለዛ SLO ማዘጋጀት አይችሉም።

በሌላ በኩል፣ ለእያንዳንዱ ጥያቄ አማካይ መዘግየት ከ100 ሚሊሰከንድ ያነሰ እንዲሆን ይፈልጋሉ ማለት ይችላሉ። እንዲህ ዓይነቱን ግብ ማቀናበር የፊት ገጽዎን በዝቅተኛ መዘግየት እንዲጽፉ ወይም እንደዚህ ያለ መዘግየት የሚሰጡ መሳሪያዎችን እንዲገዙ ሊያስገድድዎት ይችላል። (100 ሚሊሰከንዶች ግልጽ የዘፈቀደ ቁጥር ነው ፣ ግን ዝቅተኛ የቆይታ ቁጥሮች ቢኖሩትም የተሻለ ነው ። ፈጣን ፍጥነት ከዘገየ ፍጥነት እንደሚሻል የሚጠቁሙ መረጃዎች አሉ ፣ እና የተጠቃሚ ጥያቄዎችን ከተወሰኑ እሴቶች በላይ የማስኬድ መዘግየት በእውነቱ ሰዎች እንዲርቁ ያስገድዳቸዋል ። ከእርስዎ አገልግሎት.)

እንደገና ፣ ይህ በመጀመሪያ እይታ ላይ ከሚመስለው የበለጠ አሻሚ ነው-QPSን ከስሌቱ ውስጥ ሙሉ በሙሉ ማስወጣት የለብዎትም። እውነታው ግን QPS እና መዘግየት አንዳቸው ከሌላው ጋር በጥብቅ የተሳሰሩ ናቸው፡ ከፍ ያለ QPS ብዙ ጊዜ ወደ ከፍተኛ መዘግየት ያመራል፣ እና አገልግሎቶች የተወሰነ ጭነት ገደብ ላይ ሲደርሱ የአፈፃፀም ከፍተኛ ቅነሳ ያጋጥማቸዋል።

SLO መምረጥ እና ማተም አገልግሎቱ እንዴት እንደሚሰራ የተጠቃሚ የሚጠበቁትን ያስቀምጣል። ይህ ስልት በአገልግሎት ባለቤቱ ላይ የሚነሱ መሠረተ ቢስ ቅሬታዎችን ለምሳሌ አፈጻጸሙን ይቀንሳል። ግልጽ SLO ከሌለ ተጠቃሚዎች ብዙ ጊዜ ስለ ተፈላጊ አፈጻጸም የራሳቸውን ተስፋ ይፈጥራሉ፣ ይህም አገልግሎቱን ከሚቀርጹ እና ከሚያስተዳድሩት ሰዎች አስተያየት ጋር ምንም ግንኙነት ላይኖረው ይችላል። ይህ ሁኔታ ተጠቃሚዎች አገልግሎቱ ከተጨባጭ የበለጠ ተደራሽ ይሆናል ብለው በስህተት ሲያምኑ እና ስርዓቱ ከትክክለኛው ያነሰ አስተማማኝ ነው ብለው ሲያምኑ ይህ ሁኔታ ከአገልግሎቱ የሚጠበቀውን የተጋነነ እንዲሆን ያደርጋል።

ስምምነቶች

የአገልግሎት ደረጃ ስምምነት ከተጠቃሚዎችዎ ጋር ግልጽ ወይም ስውር ውል ሲሆን ይህም በውስጣቸው ያሉትን ኤስ.ኦ.ኤስ.ኦዎች ማሟላት (ወይም አለማሟላት) የሚያስከትለውን ውጤት ያካትታል። ውጤቶቹ በቀላሉ የሚታወቁት ፋይናንሺያል ሲሆኑ - ቅናሽ ወይም መቀጮ - ነገር ግን ሌላ ቅጾችን ሊወስዱ ይችላሉ። በ SLOs እና SLA መካከል ስላለው ልዩነት ለመነጋገር ቀላሉ መንገድ “SLOs ካልተሟሉ ምን ይከሰታል?” ብሎ መጠየቅ ነው። ምንም ግልጽ ውጤቶች ከሌሉ፣ በእርግጠኝነት SLOን እየተመለከቱ ነው።

SRE በተለምዶ SLAs በመፍጠር ውስጥ አይሳተፍም ምክንያቱም SLAዎች ከንግድ እና የምርት ውሳኔዎች ጋር በቅርበት የተሳሰሩ ናቸው። SRE ግን ያልተሳኩ SLOs የሚያስከትለውን መዘዝ ለመቀነስ በመርዳት ላይ ይሳተፋል። እንዲሁም SLI ን ለመወሰን ሊያግዙ ይችላሉ፡ በግልጽ እንደሚታየው በስምምነቱ ውስጥ SLO ን ለመለካት ተጨባጭ መንገድ መኖር አለበት አለበለዚያ አለመግባባት ይፈጠራል።

ጎግል ፍለጋ ይፋዊ SLA የሌለው ጠቃሚ አገልግሎት ምሳሌ ነው፡ ሁሉም ሰው ፍለጋን በተቻለ መጠን በብቃት እንዲጠቀም እንፈልጋለን ነገር ግን ከአለም ጋር ውል አልፈረምም። ነገር ግን፣ ፍለጋ የማይገኝ ከሆነ አሁንም መዘዞች አሉ - አለመገኘት ስማችን እንዲቀንስ እና የማስታወቂያ ገቢ እንዲቀንስ ያደርጋል። እንደ Google for Work ያሉ ሌሎች ብዙ የGoogle አገልግሎቶች ከተጠቃሚዎች ጋር ግልጽ የሆነ የአገልግሎት ደረጃ ስምምነት አላቸው። አንድ የተወሰነ አገልግሎት SLA ቢኖረውም፣ SLI እና SLO ን መግለፅ እና አገልግሎቱን ለማስተዳደር መጠቀም አስፈላጊ ነው።

በጣም ብዙ ቲዎሪ - አሁን ለመለማመድ.

ጠቋሚዎች በተግባር

የአገልግሎት ደረጃን ለመለካት ተስማሚ መለኪያዎችን መምረጥ አስፈላጊ ነው ብለን ከደመደምን በኋላ አሁን የትኞቹ መለኪያዎች ለአንድ አገልግሎት ወይም ስርዓት አስፈላጊ እንደሆኑ እንዴት ያውቃሉ?

እርስዎ እና ተጠቃሚዎችዎ ስለ ምን ያስባሉ?

በክትትል ስርዓት ውስጥ መከታተል የሚችሉትን እያንዳንዱን መለኪያ እንደ SLI መጠቀም አያስፈልግዎትም። ተጠቃሚዎች ከስርዓት ምን እንደሚፈልጉ መረዳት ብዙ መለኪያዎችን እንዲመርጡ ይረዳዎታል። ብዙ አመላካቾችን መምረጥ በአስፈላጊ አመላካቾች ላይ ለማተኮር አስቸጋሪ ያደርገዋል, ትንሽ ቁጥር ሲመርጡ ብዙ የሲስተምዎ ክፍሎች ያለ ክትትል ሊተዉ ይችላሉ. የስርዓትን ጤና ለመገምገም እና ለመረዳት ብዙ ቁልፍ አመልካቾችን በተለምዶ እንጠቀማለን።

አገልግሎቶቹ በአጠቃላይ ከSLI ጋር በሚዛመዱት በብዙ ክፍሎች ሊከፋፈሉ ይችላሉ፡-

• እንደ የሼክስፒር አገልግሎት የፍለጋ መገናኛዎች ያሉ ብጁ የፊት-ፍጻሜ ስርዓቶች ከኛ ምሳሌ። መገኘት አለባቸው, ምንም መዘግየት እና በቂ የመተላለፊያ ይዘት ሊኖራቸው ይገባል. በዚህ መሠረት ጥያቄዎችን መጠየቅ ይቻላል ለጥያቄው ምላሽ መስጠት እንችላለን? ለጥያቄው ምላሽ ለመስጠት ምን ያህል ጊዜ ፈጅቷል? ስንት ጥያቄዎችን ማስተናገድ ይቻላል?
• የማከማቻ ስርዓቶች. ዝቅተኛ ምላሽ መዘግየት፣ ተገኝነት እና ዘላቂነት ዋጋ ይሰጣሉ። ተዛማጅ ጥያቄዎች፡ መረጃ ለማንበብ ወይም ለመጻፍ ምን ያህል ጊዜ ይወስዳል? በተጠየቅን ጊዜ ውሂቡን ማግኘት እንችላለን? እኛ በሚያስፈልገን ጊዜ መረጃው ይገኛል? ምዕራፍ 26 የውሂብ ታማኝነትን ተመልከት፡ ያነበብከው ስለእነዚህ ጉዳዮች ዝርዝር ውይይት የምትጽፈው ነው።
• እንደ የውሂብ ማቀናበሪያ ቧንቧዎች ያሉ ትላልቅ የመረጃ ሥርዓቶች በግብአት እና በጥያቄ ሂደት መዘግየት ላይ ይመረኮዛሉ። ተዛማጅ ጥያቄዎች፡ ምን ያህል ውሂብ ነው የሚሰራው? ውሂቡ ጥያቄ ከመቀበል ምላሽ እስከ መስጠት ድረስ ለመጓዝ ምን ያህል ጊዜ ይወስዳል? (አንዳንድ የስርአቱ ክፍሎችም በተወሰኑ ደረጃዎች መዘግየቶች ሊኖራቸው ይችላል።)

የጠቋሚዎች ስብስብ

ብዙ የአገልግሎት ደረጃ አመላካቾች እንደ ቦርሞን ያሉ የክትትል ስርዓትን በመጠቀም በአገልጋዩ በኩል በተፈጥሮ ይሰበሰባሉ (ከዚህ በታች ይመልከቱ)። ምዕራፍ 10 በጊዜ ተከታታይ መረጃ ላይ በመመስረት የተግባር ማንቂያዎች) ወይም ፕሮሜቴየስ፣ ወይም በየጊዜው መዝገቦቹን በመተንተን፣ የኤችቲቲፒ ምላሾችን በሁኔታ 500 መለየት። ይሁን እንጂ፣ አንዳንድ ሲስተሞች ከደንበኛ-ጎን መለኪያዎች ስብስብ ጋር የታጠቁ መሆን አለባቸው፣ ምክንያቱም የደንበኛ-ጎን ክትትል አለመኖሩ ተጽዕኖ የሚያሳድሩ በርካታ ችግሮችን ወደ ማጣት ሊያመራ ይችላል። ተጠቃሚዎች፣ ነገር ግን የአገልጋይ ጎን መለኪያዎችን አይነኩም። ለምሳሌ በሼክስፒር የፍለጋ ሙከራ አፕሊኬሽን የኋላ ምላሽ መዘግየት ላይ ማተኮር በጃቫስክሪፕት ጉዳዮች ምክንያት በተጠቃሚው በኩል መዘግየትን ሊያስከትል ይችላል፡ በዚህ አጋጣሚ አሳሹ ገጹን ለመስራት ምን ያህል ጊዜ እንደሚፈጅ መለካት የተሻለ መለኪያ ነው።

ድምር

ለቀላል እና ለአጠቃቀም ቀላልነት, ብዙውን ጊዜ ጥሬ መለኪያዎችን እንሰበስባለን. ይህ በጥንቃቄ መደረግ አለበት.

አንዳንድ መለኪያዎች ቀላል ይመስላሉ፣ ልክ እንደ በሰከንድ ጥያቄዎች፣ ነገር ግን ይህ ቀጥተኛ የሚመስለው መለኪያ እንኳን በጊዜ ሂደት ውሂብን በአንድ ላይ ያዋህዳል። ልኬቱ በተለይ በሰከንድ አንድ ጊዜ ተቀብሏል ወይንስ ልኬቱ የሚለካው በደቂቃ ከጥያቄዎች ብዛት በላይ ነው? የኋለኛው አማራጭ ለጥቂት ሰከንዶች ብቻ የሚቆዩ በጣም ከፍ ያለ ቅጽበታዊ ጥያቄዎችን መደበቅ ይችላል። በሴኮንድ 200 ጥያቄዎችን ከቁጥሮች ጋር እና 0 በቀሪው ጊዜ የሚያገለግል ስርዓትን አስቡበት። በሴኮንድ 100 ጥያቄዎች አማካኝ ዋጋ ያለው ቋሚ እና ቅጽበታዊ ጭነት ሁለት ጊዜ አንድ አይነት አይደለም። በተመሳሳይም አማካኝ የጥያቄ መዘግየት ማራኪ ሊመስል ይችላል ነገር ግን አንድ አስፈላጊ ዝርዝር ነገርን ይደብቃል፡ ምናልባት ብዙ ጥያቄዎች ፈጣን ሊሆኑ ይችላሉ ነገር ግን ቀርፋፋ የሆኑ ብዙ መጠይቆች ይኖራሉ።

አብዛኛዎቹ አመላካቾች ከአማካይ ይልቅ እንደ ማከፋፈያዎች በተሻለ ሁኔታ ይታያሉ። ለምሳሌ፣ ለSLI መዘግየት፣ አንዳንድ ጥያቄዎች በፍጥነት ይከናወናሉ፣ አንዳንዶቹ ግን ሁልጊዜ ረዘም ያለ ጊዜ ይወስዳሉ፣ አንዳንዴም ብዙ ጊዜ ይወስዳሉ። ቀላል አማካኝ እነዚህን ረጅም መዘግየቶች መደበቅ ይችላል። በሥዕሉ ላይ አንድ ምሳሌ ያሳያል፡ ምንም እንኳን አንድ የተለመደ ጥያቄ ለማገልገል በግምት 50 ሚሴ የሚወስድ ቢሆንም፣ 5% ጥያቄዎች 20 ጊዜ ቀርፋፋ ናቸው! በአማካኝ መዘግየት ላይ ብቻ የተመሰረተ ክትትል እና ማስጠንቀቂያ ቀኑን ሙሉ የባህሪ ለውጦችን አያሳይም ፣ በእርግጥ በአንዳንድ ጥያቄዎች ሂደት ጊዜ ላይ ጉልህ ለውጦች ሲኖሩ (ከፍተኛው መስመር)።

50፣ 85፣ 95 እና 99 ፐርሰንታይል የስርአት መዘግየት። የY ዘንግ በሎጋሪዝም ቅርጸት ነው።

ፐርሰንታይሎችን ለጠቋሚዎች መጠቀም የስርጭቱን ቅርፅ እና ባህሪያቱን እንዲመለከቱ ያስችልዎታል፡ ከፍተኛ ፐርሰንታይል ደረጃ ለምሳሌ 99 ወይም 99,9 መጥፎውን እሴት ያሳያል፣ 50 ፐርሰንታይል (ሚዲያን በመባልም ይታወቃል) በጣም ተደጋጋሚ ሁኔታን ያሳያል። መለኪያው. የምላሽ ጊዜ መበታተን ባበዛ ቁጥር የረዥም ጊዜ ጥያቄዎች በተጠቃሚው ተሞክሮ ላይ ተጽዕኖ ያሳድራሉ። ውጤቱ በከፍተኛ ጭነት እና ወረፋዎች ባሉበት ሁኔታ ይሻሻላል. የተጠቃሚ ተሞክሮ ጥናት እንደሚያሳየው ሰዎች በአጠቃላይ ቀርፋፋ ስርዓትን የሚመርጡት ከፍተኛ ምላሽ ሰጪ ጊዜ ልዩነት ስላለው ነው ስለዚህ አንዳንድ የኤስአርአይ ቡድኖች በከፍተኛ ፐርሰንታይል ውጤቶች ላይ ብቻ ያተኩራሉ፣በዚህም መሰረት በ99,9 ፐርሰንታይል ያለው የሜትሪክ ባህሪ ጥሩ ከሆነ አብዛኛው ተጠቃሚዎች ችግር አይገጥማቸውም። .

በስታቲስቲክስ ስህተቶች ላይ ማስታወሻ

በአጠቃላይ የእሴቶች ስብስብ አማካኝ (የሂሳብ አማካኝ) ሳይሆን ከመቶኛ ጋር መስራት እንመርጣለን። ይህ ብዙ የተበታተኑ እሴቶችን እንድንመለከት ያስችለናል, እነሱም ብዙውን ጊዜ ከአማካይ በተለየ ሁኔታ (እና የበለጠ አስደሳች) ባህሪያት አላቸው. በኮምፒዩተር ሲስተም ሰው ሰራሽ ባህሪ ምክንያት ሜትሪክ እሴቶች ብዙውን ጊዜ የተዛቡ ናቸው ፣ ለምሳሌ ፣ ምንም ጥያቄ ከ 0 ms ባነሰ ጊዜ ውስጥ ምላሽ ሊሰጥ አይችልም ፣ እና የ 1000 ms ጊዜ ያለፈበት ማለት ከእሴቶች የበለጠ ስኬታማ ምላሾች ሊኖሩ አይችሉም። ከማለቁ ጊዜ ይልቅ. በውጤቱም, መካከለኛ እና መካከለኛው ተመሳሳይ ወይም እርስ በርስ ሊቀራረቡ እንደሚችሉ መቀበል አንችልም!

ያለቅድመ ሙከራ፣ እና የተወሰኑ መደበኛ ግምቶች እና ግምቶች እስካልያዙ ድረስ፣ የእኛ መረጃ በመደበኛነት የሚሰራጭ ነው ብለን እንዳንደመድም እንጠነቀቃለን። ስርጭቱ እንደተጠበቀው ካልሆነ፣ ችግሩን የሚያስተካክለው አውቶሜሽን ሂደት (ለምሳሌ፣ ከውጪ ሲመለከት፣ አገልጋዩን በከፍተኛ የፍላጎት ሂደት መዘግየት) እንደገና ያስጀምረዋል) ብዙ ጊዜ እያደረገ ወይም በቂ ላይሆን ይችላል (ሁለቱም አይደሉም)። በጣም ጥሩ).

አመላካቾችን መደበኛ አድርግ

ስለእነሱ ሁል ጊዜ መገመት እንዳይኖርብዎት የ SLI አጠቃላይ ባህሪዎችን ደረጃውን የጠበቀ እንዲሆን እንመክራለን። መደበኛ ንድፎችን የሚያረካ ማንኛውም ባህሪ ከግለሰብ SLI ዝርዝር ሊገለል ይችላል፣ ለምሳሌ፡-

• የመደመር ክፍተቶች፡ "በአማካኝ ከ1 ደቂቃ በላይ"
• የመደመር ቦታዎች፡ "በጥቅሉ ውስጥ ያሉ ሁሉም ተግባራት"
• ምን ያህል ጊዜ መለኪያዎች ይወሰዳሉ: "በየ 10 ሴኮንድ"
• ምን ጥያቄዎች ተካትተዋል፡- "HTTP GET ከጥቁር ሣጥን ክትትል ስራዎች"
• መረጃው እንዴት እንደሚገኝ: "በአገልጋዩ ላይ ስለተለካው ክትትል እናመሰግናለን"
• የውሂብ መዳረሻ መዘግየት፡ "ባይት የሚቆይበት ጊዜ"

ጥረትን ለመቆጠብ ለእያንዳንዱ የተለመደ መለኪያ እንደገና ጥቅም ላይ ሊውሉ የሚችሉ SLI አብነቶችን ይፍጠሩ። እንዲሁም አንድ የተወሰነ SLI ምን ማለት እንደሆነ ለመረዳት ለሁሉም ሰው ቀላል ያደርጉታል።

ግቦች በተግባር

በማሰብ (ወይም በማወቅ!) ተጠቃሚዎችዎ ስለሚያስቡት ነገር በማሰብ ይጀምሩ እንጂ ሊለኩት የሚችሉትን አይደለም። ብዙ ጊዜ ተጠቃሚዎችዎ የሚያሳስቧቸው ነገር ለመለካት አስቸጋሪ ወይም የማይቻል ነው፣ ስለዚህ እርስዎ ወደ ፍላጎታቸው መቅረብ ይችላሉ። ነገር ግን፣ ለመለካት ቀላል በሆነው ብቻ ከጀመርክ፣ ብዙም ጠቃሚ የሆኑ SLOs ታገኛለህ። በውጤቱም, አንዳንድ ጊዜ የሚፈለጉትን ግቦች መለየት እና ከተወሰኑ አመልካቾች ጋር መስራት ጠቋሚዎችን ከመምረጥ እና ከዚያም ግቦቹን ከማሳካት የተሻለ እንደሚሰራ ተገንዝበናል.

ግቦችዎን ይግለጹ

ለከፍተኛ ግልጽነት፣ SLOs እንዴት እንደሚለኩ እና ትክክለኛ የሆኑባቸው ሁኔታዎች መገለጽ አለበት። ለምሳሌ፣ የሚከተለውን ማለት እንችላለን (ሁለተኛው መስመር ከመጀመሪያው ጋር አንድ ነው፣ ግን የSLI ነባሪዎችን ይጠቀማል)

• 99% (በአማካይ ከ1 ደቂቃ በላይ) Get RPC ጥሪዎች ከ100 ሚሴ ባነሰ ጊዜ ውስጥ ይጠናቀቃሉ (በሁሉም የኋለኛ አገልጋዮች ላይ ይለካሉ)።
• 99% Get RPC ጥሪዎች ከ100 ሚሴ ባነሰ ጊዜ ውስጥ ይጠናቀቃሉ።

የክንውን ኩርባዎች ቅርፅ አስፈላጊ ከሆነ፣ ብዙ SLOዎችን መግለጽ ይችላሉ፡

• 90% ያግኙ RPC ጥሪዎች ከ1 ሚሴ ባነሰ ጊዜ ውስጥ ተጠናቀዋል።
• 99% ያግኙ RPC ጥሪዎች ከ10 ሚሴ ባነሰ ጊዜ ውስጥ ተጠናቀዋል።
• 99.9% ያግኙ RPC ጥሪዎች ከ100 ሚሴ ባነሰ ጊዜ ውስጥ ተጠናቀዋል።

የእርስዎ ተጠቃሚዎች የተለያዩ የሥራ ጫናዎችን የሚያመነጩ ከሆነ፡ የጅምላ ሂደት (ለዚህ ውፅዓት አስፈላጊ ነው) እና በይነተገናኝ ሂደት (ለዚህ መዘግየት አስፈላጊ ነው) ለእያንዳንዱ የጭነት ክፍል የተለየ ግቦችን መግለፅ ጠቃሚ ሊሆን ይችላል፡

• 95% የደንበኛ ጥያቄዎች የፍተሻ ሂደት ያስፈልጋቸዋል። በ<1 ሰከንድ የተፈጸሙ RPC ጥሪዎችን ያቀናብሩ።
• 99% ደንበኞች ስለ መዘግየት ግድ ይላቸዋል። የ RPC ጥሪዎች ብዛት በትራፊክ <1 ኪባ እና በ<10 ms ሩጫ ያቀናብሩ።

SLOs 100% ይሟላሉ ብሎ መናገሩ ከእውነታው የራቀ እና የማይፈለግ ነው፡ ይህ አዲስ ተግባርን የማስተዋወቅ እና የማሰማራትን ፍጥነት ይቀንሳል እና ውድ መፍትሄዎችን ይፈልጋል። ይልቁንስ የስህተት በጀት መፍቀድ የተሻለ ነው - የተፈቀደው የስርዓት ቅነሳ መቶኛ - እና ይህን እሴት በየቀኑ ወይም በየሳምንቱ ይቆጣጠሩ። ከፍተኛ አመራር በየወሩ ወይም በየሩብ ወር ግምገማዎች ሊፈልጉ ይችላሉ። (የስህተት በጀቱ ከሌላ SLO ጋር ለማነፃፀር በቀላሉ SLO ነው።)

የ SLO ጥሰቶች መቶኛ ከስህተት በጀት ጋር ሊመሳሰል ይችላል (ምዕራፍ 3 እና ክፍል ይመልከቱ "ለስህተት በጀት ማበረታቻ") አዲስ ልቀቶችን መቼ ማሰማራት እንዳለበት የሚወስነው ለሂደቱ ግብአት ሆኖ የሚያገለግለው የልዩነት እሴት።

የዒላማ እሴቶችን መምረጥ

የእቅድ እሴቶችን መምረጥ (SLOs) በተመረጡት SLIs፣ SLOs (እና ምናልባትም SLAs) ውስጥ መንጸባረቅ ስላለባቸው የምርት እና የንግድ ፍላጎቶች ምክንያት ቴክኒካዊ እንቅስቃሴ ብቻ አይደለም። እንደዚሁም፣ ከሰራተኞች ምደባ፣ ከገበያ ጊዜ፣ ከመሳሪያዎች አቅርቦት እና ከፋይናንስ ጋር የተያያዙ ጉዳዮችን በተመለከተ መረጃ መለዋወጥ ሊያስፈልግ ይችላል። SRE የዚህ ውይይት አካል መሆን አለበት እና የተለያዩ አማራጮችን አደጋዎች እና አዋጭነት ለመረዳት ይረዳል። የበለጠ ውጤታማ ውይይት ለማረጋገጥ የሚረዱ ጥቂት ጥያቄዎችን ይዘን መጥተናል።

አሁን ባለው አፈጻጸም መሰረት ግብ አይምረጡ።
የስርዓቱን ጥንካሬ እና ወሰን መረዳት አስፈላጊ ቢሆንም፣ ያለምክንያት መለኪያዎችን ማላመድ ስርዓቱን እንዳትጠብቅ ሊያግድዎት ይችላል፡ ያለ ጉልህ ዳግም ዲዛይን ሊሳኩ የማይችሉ ግቦችን ለማሳካት የጀግንነት ጥረት ይጠይቃል።

ቀላል እንዲሆን
ውስብስብ የ SLI ስሌቶች በስርዓት አፈፃፀም ላይ ለውጦችን ሊደብቁ እና የችግሩን መንስኤ ለማግኘት አስቸጋሪ ያደርጉታል.

ፍፁም ነገሮችን ያስወግዱ
መዘግየት ሳይጨምር ላልተወሰነ ጊዜ እያደገ የሚሄድ ሸክም የሚቋቋም ሥርዓት መኖሩ ፈታኝ ቢሆንም፣ ይህ መስፈርት ከእውነታው የራቀ ነው። እንደዚህ አይነት ሀሳቦችን የሚቃረን ስርዓት ለመንደፍ እና ለመገንባት ብዙ ጊዜ የሚፈልግ ይሆናል፣ ለአሰራር ውድ ይሆናል እና ባነሰ ነገር ለሚያደርጉ ተጠቃሚዎች ለሚጠበቀው ነገር በጣም ጥሩ ይሆናል።

በተቻለ መጠን ጥቂት SLOዎችን ይጠቀሙ
የስርዓት ባህሪያትን ጥሩ ሽፋን ለማረጋገጥ በቂ የኤስ.ኦ.ኤስ.ዎች ብዛት ይምረጡ። የመረጡትን SLO ን ይጠብቁ፡ አንድን SLO በመግለጽ ስለ ቅድሚያ የሚሰጧቸው ጉዳዮች ክርክር በጭራሽ ማሸነፍ ካልቻሉ፣ ያንን SLO ግምት ውስጥ ማስገባት ጠቃሚ ላይሆን ይችላል። ነገር ግን፣ ሁሉም የስርዓት ባህሪያት ለ SLOs ተስማሚ አይደሉም፡ SLOs በመጠቀም የተጠቃሚን ደስታ ደረጃ ለማስላት አስቸጋሪ ነው።

ፍጹምነትን አታሳድድ
በጭነት ውስጥ ስላለው የስርአቱ ባህሪ የበለጠ ሲማሩ የSLOዎችን ትርጓሜ እና ግቦች በጊዜ ሂደት ማጥራት ይችላሉ። ሊደረስበት የማይችል ሆኖ ሲገኝ ዘና ማለት ያለበትን ከመጠን ያለፈ ጥብቅ ግብ ከመምረጥ በጊዜ ሂደት በሚያጣራው ተንሳፋፊ ግብ መጀመር ይሻላል።

SLOs ለኤስአርኤዎች እና ለምርት ገንቢዎች ለተጠቃሚዎች ስጋት ስላላቸው ቅድሚያ ለመስጠት ቁልፍ አሽከርካሪ መሆን ይችላሉ እና አለባቸው። ጥሩ SLO ለልማት ቡድን ጠቃሚ የማስፈጸሚያ መሳሪያ ነው። ነገር ግን በደንብ ያልተነደፈ SLO ቡድኑ የጀግንነት ጥረት ካደረገ ከመጠን በላይ ጠበኛ SLO፣ ወይም SLO በጣም ዝቅተኛ ከሆነ ደካማ ምርት ወደ አባካኝ ስራ ሊያመራ ይችላል። SLO ኃይለኛ ማንሻ ነው, በጥበብ ይጠቀሙበት.

የእርስዎን መለኪያዎች ይቆጣጠሩ

SLI እና SLO ስርዓቶችን ለማስተዳደር የሚያገለግሉ ቁልፍ አካላት ናቸው፡

• የSLI ስርዓቶችን ይቆጣጠሩ እና ይለኩ።
• SLIን ከSLO ጋር ያወዳድሩ እና እርምጃ ያስፈልግ እንደሆነ ይወስኑ።
• እርምጃ ከተፈለገ ግቡን ለማሳካት ምን መደረግ እንዳለበት ይወቁ።
• ይህንን ተግባር ያጠናቅቁ።

ለምሳሌ፣ ደረጃ 2 ጥያቄው ጊዜው አልፎበታል እና ምንም ነገር ካልተደረገ በጥቂት ሰዓታት ውስጥ SLO ን እንደሚሰብር ካሳየ፣ ደረጃ 3 አገልጋዮቹ ሲፒዩ የታሰሩ ናቸው የሚለውን መላምት መሞከርን ሊያካትት ይችላል እና ተጨማሪ አገልጋዮችን ማከል ጭነቱን ያሰራጫል። SLO ከሌለ፣ (ወይም መቼ) እርምጃ መውሰድ እንዳለቦት አታውቅም።

SLO ን ያቀናብሩ - ከዚያ የተጠቃሚ የሚጠበቁ ነገሮች ይቀናበራሉ
SLO ማተም የተጠቃሚዎችን የስርዓት ባህሪን ያዘጋጃል። ተጠቃሚዎች (እና ሊሆኑ የሚችሉ ተጠቃሚዎች) ለአጠቃቀም ምቹ መሆን አለመሆኑን ለመረዳት ብዙውን ጊዜ ከአገልግሎት ምን እንደሚጠብቁ ማወቅ ይፈልጋሉ። ለምሳሌ፣ የፎቶ ማጋሪያ ድረ-ገጽን ለመጠቀም የሚፈልጉ ሰዎች ረጅም ዕድሜ እና አነስተኛ ዋጋ ያለው አገልግሎትን ከመጠቀም መቆጠብ ሊፈልጉ ይችላሉ ለተገኘው ተደራሽነት በመጠኑ ያነሰ፣ ምንም እንኳን ተመሳሳይ አገልግሎት ለማህደር መዛግብት አስተዳደር ስርዓት ተስማሚ ሊሆን ይችላል።

ለተጠቃሚዎችህ ተጨባጭ የሚጠበቁ ነገሮችን ለማዘጋጀት ከሚከተሉት ዘዴዎች አንዱን ወይም ሁለቱንም ተጠቀም፡

• የደህንነት ህዳግን ጠብቅ። ለተጠቃሚዎች ከሚታወጀው የበለጠ ጥብቅ የውስጥ SLO ይጠቀሙ። ይህ በውጫዊ ሁኔታ ከመታየቱ በፊት ለችግሮች ምላሽ ለመስጠት እድል ይሰጥዎታል. የSLO ቋት እንዲሁ የስርዓት አፈጻጸምን የሚነኩ ልቀቶችን ሲጭኑ የደህንነት ህዳግ እንዲኖርዎት እና ስርዓቱ ተጠቃሚዎችን በእረፍት ጊዜ ማሳደድ ሳያስፈልግ በቀላሉ ለማቆየት ያስችላል።
• የተጠቃሚ ከሚጠበቀው በላይ አትበል። ተጠቃሚዎች እርስዎ በሚናገሩት ሳይሆን በሚያቀርቡት ነገር ላይ የተመሰረቱ ናቸው። ትክክለኛው የአገልግሎትዎ አፈጻጸም ከተገለጸው SLO በጣም የተሻለ ከሆነ ተጠቃሚዎች አሁን ባለው አፈጻጸም ላይ ይመካሉ። ሆን ተብሎ ስርዓቱን በመዝጋት ወይም በቀላል ጭነቶች ውስጥ አፈፃፀምን በመገደብ ከመጠን በላይ ጥገኛነትን ማስወገድ ይችላሉ።

ስርዓቱ የሚጠበቁትን ምን ያህል እንደሚያሟላ መረዳቱ ስርዓቱን ለማፋጠን እና የበለጠ ተደራሽ እና ጠንካራ እንዲሆን ለማድረግ ኢንቨስት ለማድረግ ይረዳል። በአማራጭ፣ አገልግሎቱ በጣም ጥሩ እየሰራ ከሆነ፣ አንዳንድ የሰራተኞች ጊዜ በሌሎች ቅድሚያዎች ላይ መዋል አለበት፣ ለምሳሌ የቴክኒክ እዳ መክፈል፣ አዲስ ባህሪያትን ማከል ወይም አዳዲስ ምርቶችን ማስተዋወቅ።

ስምምነቶች በተግባር

SLA መፍጠር የሚያስከትለውን መዘዝ እና ቅጣት ለመወሰን የንግድ እና የህግ ቡድኖችን ይጠይቃል። የኤስአርአይ ሚና በኤስኤልኤ ውስጥ የተካተቱትን SLOs በማሟላት ረገድ ሊከሰቱ የሚችሉ ተግዳሮቶችን እንዲገነዘቡ መርዳት ነው። SLOs ለመፍጠር አብዛኛዎቹ ምክሮች SLAs ላይም ይተገበራሉ። ለተጠቃሚዎች ቃል በገቡት ቃል ወግ አጥባቂ መሆን ብልህነት ነው ምክንያቱም ብዙ ባላችሁ ቁጥር ምክንያታዊ ያልሆኑ ወይም ለመገናኘት አስቸጋሪ የሚመስሉ SLAዎችን መቀየር ወይም ማስወገድ በጣም ከባድ ነው።

ትርጉሙን እስከ መጨረሻ ስላነበብክ እናመሰግናለን። ስለ ክትትል የቴሌግራም ቻናሌን ሰብስክራይብ ያድርጉ ሞኒተሪም_ነው и ጦማር በመካከለኛ.

ምንጭ: hab.com