የዌቢናር ግልባጭ "SRE - ተስፋ ወይስ የወደፊት?"

ዌቢናር ደካማ ኦዲዮ አለው፣ ስለዚህ ግልባጭ አድርገናል።

ስሜ ሜድቬድየቭ ኤድዋርድ እባላለሁ። ዛሬ ስለ SRE ምን እንደሆነ ፣ SRE እንዴት እንደታየ ፣ ለ SRE መሐንዲሶች የሥራ መመዘኛዎች ምንድ ናቸው ፣ ስለ አስተማማኝነት መመዘኛዎች ትንሽ ፣ ስለ ክትትልነቱ እናገራለሁ ። ከላይ እናልፋለን፣ ምክንያቱም በአንድ ሰአት ውስጥ ብዙ መናገር አይችሉም፣ ግን ለተጨማሪ ግምገማ ቁሳቁሶችን እሰጥዎታለሁ፣ እና ሁላችንም በ ላይ እንጠብቃለን። Slurme SRE. በጥር ወር መጨረሻ ላይ በሞስኮ.

በመጀመሪያ፣ SRE - Site Reliability Engineering - ምን እንደሆነ እንነጋገር። እና እንዴት እንደ የተለየ አቀማመጥ, እንደ የተለየ አቅጣጫ ታየ. ይህ ሁሉ የተጀመረው በባህላዊ የእድገት ክበቦች ውስጥ ዴቭ እና ኦፕስ ሁለት ሙሉ ለሙሉ የተለያዩ ቡድኖች በመሆናቸው አብዛኛውን ጊዜ ሁለት ሙሉ ለሙሉ የተለያዩ ግቦች ያላቸው በመሆናቸው ነው። የልማት ቡድኑ ዓላማ የንግድ ፍላጎቶችን ለማሟላት አዳዲስ ባህሪያትን ማውጣት ነው። የኦፕስ ቡድን አላማ ሁሉም ነገር እንደሚሰራ እና ምንም ነገር እንደማይሰበር ማረጋገጥ ነው. በግልጽ ለማየት እንደሚቻለው, እነዚህ ግቦች በቀጥታ እርስ በርስ ይቃረናሉ: ሁሉም ነገር እንዲሰራ እና ምንም ነገር እንዳይሰበር, በተቻለ መጠን አዲስ ባህሪያትን ማውጣት የተሻለ ነው. በዚህ ምክንያት, ብዙ ውስጣዊ ግጭቶች ይነሳሉ, ይህም አሁን DevOps ተብሎ የሚጠራው ዘዴ ለመፍታት እየሞከረ ነው.

ችግሩ የዴቭኦፕስ ግልፅ ፍቺ እና የዴቭኦፕስ ግልፅ አተገባበር የለንም ማለት ነው። ከ2 አመት በፊት በየካተሪንበርግ በተደረገ ኮንፈረንስ ተናግሬ ነበር፣ እና እስከዚህ ጊዜ ድረስ የዴቭኦፕስ ክፍል “DevOps ምንድን ነው” በሚለው ዘገባ ጀመረ። እ.ኤ.አ. በ 2017 ፣ ዴፖፕስ ወደ 10 ዓመት ሊጠጋ ነው ፣ ግን አሁንም ስለ ምን እንደሆነ እየተከራከርን ነው። እና ይሄ ጉግል ከጥቂት አመታት በፊት ለመፍታት የሞከረው በጣም እንግዳ ሁኔታ ነው።

እ.ኤ.አ. በ2016 ጎግል “ሳይት አስተማማኝ ምህንድስና” የተሰኘ መጽሐፍ አወጣ። እና በእውነቱ፣ የ SRE እንቅስቃሴ የጀመረው በዚህ መጽሐፍ ነው። SRE በአንድ የተወሰነ ኩባንያ ውስጥ የዴቭኦፕስ ፓራዳይምን ተግባራዊ ለማድረግ የተለየ አማራጭ ነው። የኤስአርአይ መሐንዲሶች የስርዓቶችን አስተማማኝ አሠራር የማረጋገጥ ግብ አውጥተዋል። በዋነኛነት የተወሰዱት ከገንቢዎች፣ አንዳንዴም ጠንካራ የእድገት ዳራ ካላቸው አስተዳዳሪዎች ነው። እና የስርዓት አስተዳዳሪዎች ያደርጉት የነበረውን ያደርጉታል, ነገር ግን በልማት እና በስርአቱ ላይ ያለው እውቀት ከኮድ እይታ አንጻር እነዚህ ሰዎች ወደ ተለመደው አስተዳደራዊ ስራ ሳይሆን ወደ አውቶሜሽን ያዘነብላሉ.

በ SRE ቡድኖች ውስጥ ያለው የዴቭኦፕስ ፓራዲም የተተገበረው መዋቅራዊ ችግሮችን የሚፈቱ የ SRE መሐንዲሶች በመኖራቸው ነው። እዚህ ነው, ሰዎች ለ 8 ዓመታት ሲያወሩ የነበረው በዴቭ እና ኦፕስ መካከል ያለው ተመሳሳይ ግንኙነት. ጀማሪዎች SREs እንዳይሆኑ የ SRE ሚና ከአርክቴክት ጋር ተመሳሳይ ነው። በስራቸው መጀመሪያ ላይ ያሉ ሰዎች ገና ምንም ልምድ የላቸውም እና የሚፈለገውን የእውቀት ስፋት የላቸውም። ምክንያቱም SRE በትክክል ምን እና መቼ በትክክል ሊሳሳቱ እንደሚችሉ በጣም የተራቀቀ እውቀትን ይፈልጋል። ስለዚህ, አንድ ዓይነት ልምድ እዚህ ያስፈልጋል, እንደ አንድ ደንብ, በኩባንያው ውስጥም ሆነ በውጭ.

በ SRE እና devops መካከል ያለው ልዩነት ይገለጽ እንደሆነ ይጠይቃሉ። እሷ አሁን ተገልጻለች። በድርጅቱ ውስጥ ስለ SRE ቦታ መነጋገር እንችላለን. ኦፕስ አሁንም የተለየ ክፍል ከሆነበት ከጥንታዊው የዴቭኦፕ አቀራረብ በተለየ SRE የልማት ቡድን አካል ነው። በምርት ልማት ውስጥ ይሳተፋሉ. SRE ከአንዱ ገንቢ ወደ ሌላው የሚሸጋገር ሚና የሆነበት አካሄድም አለ። በኮድ ግምገማዎች ውስጥ በተመሳሳይ መልኩ ይሳተፋሉ, ለምሳሌ, UX ዲዛይነሮች, ገንቢዎች እራሳቸው እና አንዳንድ ጊዜ የምርት አስተዳዳሪዎች. SREs በተመሳሳይ ደረጃ ይሰራሉ። የእነርሱን ማፅደቅ እንፈልጋለን፣ ግምገማቸውን እንፈልጋለን፣ ስለዚህ ለእያንዳንዱ ማሰማራት SRE እንዲህ ይላል፡- “እሺ፣ ይህ ማሰማራት፣ ይህ ምርት በአስተማማኝነት ላይ አሉታዊ ተጽዕኖ አያሳድርም። ከሆነ ደግሞ ተቀባይነት ባለው ገደብ ውስጥ ይሆናል። ስለዚህ ጉዳይ እንነጋገራለን.

በዚህ መሰረት፣ SRE በኮድ ለውጦች ላይ ቬቶ አለው። እና በአጠቃላይ፣ ይህ ደግሞ SRE በስህተት ከተተገበረ ወደ ትንሽ ግጭት ይመራል። ስለ ሳይት ተዓማኒነት ኢንጂነሪንግ በዛ መጽሐፍ ውስጥ፣ ብዙ ክፍሎች፣ ከአንድ በላይም ቢሆን፣ እነዚህን ግጭቶች እንዴት ማስወገድ እንደሚችሉ ይነግሩታል።

ሰዎች SRE ከመረጃ ደህንነት ጋር እንዴት እንደሚዛመድ ይጠይቃሉ። SRE በቀጥታ በመረጃ ደህንነት ውስጥ አልተሳተፈም። በአብዛኛው በትልልቅ ኩባንያዎች ውስጥ ይህ የሚከናወነው በግለሰብ ሰዎች, ሞካሪዎች እና ተንታኞች ነው. ነገር ግን SRE ከእነሱ ጋር መስተጋብር የሚፈጥረው አንዳንድ ክዋኔዎች፣ አንዳንዶቹ ይፈጽማሉ፣ አንዳንድ ደህንነትን የሚነኩ ማሰማራት የምርቱን መገኘት ሊጎዱ ይችላሉ። ስለዚህ፣ SRE በአጠቃላይ ከማንኛውም ቡድኖች ጋር ግንኙነት አለው፣ የደህንነት ቡድኖችን፣ ተንታኞችን ጨምሮ። ስለዚህ፣ SREs በዋናነት የሚፈለጉት DevOpsን ለመተግበር ሲሞክሩ ነው፣ ነገር ግን በገንቢዎች ላይ ያለው ሸክም በጣም ትልቅ ይሆናል። ያም ማለት፣ የልማቱ ቡድን እራሱ ከአሁን በኋላ ሊቋቋመው አይችልም ምክንያቱም አሁን እነሱ ለኦፕስ ተጠያቂ መሆን አለባቸው። እና የተለየ ሚና ይታያል. ይህ ሚና በበጀት ውስጥ የታቀደ ነው. አንዳንድ ጊዜ ይህ ሚና በቡድኑ መጠን ውስጥ ይገነባል, የተለየ ሰው ይታያል, አንዳንድ ጊዜ ከገንቢዎቹ አንዱ ይሆናል. የመጀመሪያው SRE በቡድኑ ላይ የሚታየው በዚህ መንገድ ነው።

በ SRE የተጎዳው የስርዓት ውስብስብነት፣ የአሰራር አስተማማኝነት ላይ ተጽእኖ የሚያሳድር ውስብስብነት፣ አስፈላጊ ወይም ድንገተኛ ሊሆን ይችላል። አስፈላጊው ውስብስብነት የምርቱ ውስብስብነት አዲስ የምርት ባህሪያት በሚፈልጉበት መጠን ሲጨምር ነው. የዘፈቀደ ውስብስብነት የስርዓቱ ውስብስብነት ሲጨምር ነው, ነገር ግን የምርት ባህሪ እና የንግድ መስፈርቶች በቀጥታ በዚህ ላይ ተጽዕኖ አያሳርፉም. አንድም ገንቢው የሆነ ቦታ ላይ ስህተት ሰርቷል፣ ወይም አልጎሪዝም ጥሩ አይደለም፣ ወይም አንዳንድ ተጨማሪ ፍላጎቶች የምርቱን ውስብስብነት ሳያስፈልግ የሚጨምሩ መሆናቸው ተገለጠ። ጥሩ SRE ሁልጊዜ ከዚህ ሁኔታ መራቅ አለበት. ይህም ማለት ማንኛውም ቃል ኪዳን፣ ማንኛውም ማሰማራት፣ በዘፈቀደ ጭማሪዎች ምክንያት ውስብስብነትን የሚጨምር ማንኛውም የመጎተት ጥያቄ መታገድ አለበት።

ጥያቄው ለምን ኢንጂነር፣ ብዙ እውቀት ያለው የስርዓት አስተዳዳሪ፣ ቡድኑን ለመቀላቀል ለምን አይቀጥሩም የሚለው ነው። በመሐንዲስ ሚና ውስጥ ያለ ገንቢ፣ በጣም ጥሩው የሰው ኃይል መፍትሔ እንዳልሆነ ተነግሮናል። በመሐንዲስ ሚና ውስጥ ያለ ገንቢ ሁል ጊዜ የተሻለው የሰው ኃይል መፍትሄ አይደለም ፣ ግን እዚህ ያለው ነጥብ በኦፕስ ውስጥ የተሰማራ ገንቢ ትንሽ የበለጠ በራስ-ሰር የመፍጠር ፍላጎት አለው ፣ ይህንን ተግባራዊ ለማድረግ ትንሽ ተጨማሪ እውቀት እና ችሎታ ያለው መሆኑ ነው። አውቶሜሽን. እና በዚህ መሠረት ለአንዳንድ ልዩ ስራዎች ጊዜን ብቻ ሳይሆን መደበኛውን ብቻ ሳይሆን እንደ MTTR (የማገገሚያ ጊዜ አማካይ, የመልሶ ማግኛ ጊዜ) የመሳሰሉ አስፈላጊ የንግድ መለኪያዎችን እንቀንሳለን. ስለዚህ, እና ስለዚህ ጉዳይ ትንሽ ቆይቶ እንነጋገራለን, ለድርጅቱ ገንዘብ እንቆጥባለን.

አሁን ስለ SRE ሥራ መመዘኛዎች እንነጋገር. እና በመጀመሪያ ስለ አስተማማኝነት. በትናንሽ ኩባንያዎች እና ጅማሬዎች ውስጥ ብዙውን ጊዜ ሰዎች አገልግሎቱ በጥሩ ሁኔታ ከተጻፈ, ምርቱ በደንብ እና በትክክል ከተፃፈ, አይሰራም, አይሰበርም ብለው ያስባሉ. ያ ብቻ ነው, ጥሩ ኮድ እንጽፋለን, ስለዚህ ምንም የሚሰበር ነገር የለም. ኮዱ በጣም ቀላል ነው, ምንም የሚሰበር ነገር የለም. ፈተናዎች አያስፈልገንም የሚሉ ተመሳሳይ ሰዎች ናቸው, ምክንያቱም, ተመልከት, እነዚህ ሶስት የቪፒአይ ዘዴዎች ናቸው, ለምን አስጨናቂ?

ይህ ሁሉ ስህተት ነው, በእርግጥ. እና እነዚህ ሰዎች በዚህ አይነት ኮድ በተግባር ይጎዳሉ፣ ምክንያቱም ነገሮች ይበላሻሉ። ነገሮች አንዳንድ ጊዜ በጣም ባልተጠበቁ መንገዶች ይሰበራሉ. አንዳንድ ጊዜ ሰዎች አይሆንም ይላሉ, በጭራሽ አይሆንም. እና አሁንም ይከሰታል. ብዙ ጊዜ ይከሰታል። ለዚያም ነው ማንም ሰው 100% ተገኝነትን ለማግኘት የማይጥርበት፣ ምክንያቱም 100% ተገኝነት በጭራሽ አይከሰትም። ይህ የተለመደ ነው. እና ለዚያም ነው ሁልጊዜ ስለ አገልግሎት አቅርቦት ስንነጋገር ስለ ዘጠኝ የምንናገረው. 2 ዘጠኝ ፣ 3 ዘጠኝ ፣ 4 ዘጠኝ ፣ 5 ዘጠኝ። ይህንን ወደ የእረፍት ጊዜ ከተረጎምነው, ለምሳሌ, 5 nines በዓመት ከ 5 ደቂቃዎች ትንሽ በላይ ነው, 2 ዘጠኝ የ 3,5 ቀናት የእረፍት ጊዜ ነው.

ነገር ግን በተወሰነ ጊዜ የ POI መቀነስ እና ወደ ኢንቨስትመንት መመለስ እንዳለ ግልጽ ነው. ከሁለት ዘጠኝ ወደ ሶስት ዘጠኝ መሄድ ማለት የእረፍት ጊዜን ከ 3 ቀናት በላይ መቀነስ ማለት ነው. ከአራት ዘጠኝ ወደ አምስት መሄድ በዓመት 47 ደቂቃዎችን ይቀንሳል። እና ይህ ለንግድ ስራ ወሳኝ ላይሆን ይችላል. እና በአጠቃላይ አስፈላጊው አስተማማኝነት ቴክኒካዊ ጉዳይ አይደለም, በመጀመሪያ, የንግድ ጉዳይ ነው, የምርት ጉዳይ ነው. ለምርቱ ተጠቃሚዎች ምን ዓይነት የመቀነስ ደረጃ ተቀባይነት አለው, ምን እንደሚጠብቁ, ምን ያህል እንደሚከፍሉ, ለምሳሌ ምን ያህል ገንዘብ እንደሚያጡ, ስርዓቱ ምን ያህል ገንዘብ እንደሚያጣ.

አንድ አስፈላጊ ጥያቄ የቀሩት ክፍሎች አስተማማኝነት ምንድን ነው. ምክንያቱም በ 4 እና 5 ዘጠኝ መካከል ያለው ልዩነት 2 አስተማማኝነት ዘጠኝ ባለው ስማርትፎን ላይ አይታይም. በግምት፣ በአመት 10 ጊዜ በአገልግሎትዎ ውስጥ የሆነ ነገር በስማርትፎን ላይ ቢሰበር፣ ምናልባት 8 ጊዜ ብልሽቱ በስርዓተ ክወናው በኩል ተከስቷል። ተጠቃሚው ለዚህ ጥቅም ላይ ይውላል, እና በዓመት አንድ ተጨማሪ ጊዜ ለእሱ ትኩረት አይሰጥም. አስተማማኝነትን መጨመር እና ትርፍ መጨመርን ዋጋ ማወዳደር ያስፈልጋል.
በ SRE ላይ ባለው መጽሐፍ ውስጥ ከ 4 ዘጠኝ ወደ 3 ዘጠኝ ለመጨመር ጥሩ ምሳሌ አለ. የተገኝነት መጨመር በትንሹ ከ 0,1% ያነሰ ሆኖ ተገኝቷል. እና የአገልግሎቱ ገቢ በዓመት 1 ሚሊዮን ዶላር ከሆነ የገቢ ጭማሪው 900 ዶላር ነው. ተገኝነትን በዘጠኝ መጨመር በዓመት ከ900 ዶላር ያነሰ ዋጋ የሚያስከፍለን ከሆነ፣ ጭማሪው የገንዘብ ትርጉም አለው። በዓመት ከ 900 ዶላር በላይ የሚወጣ ከሆነ, ከአሁን በኋላ ትርጉም አይሰጥም, ምክንያቱም የገቢ መጨመር በቀላሉ የጉልበት ወጪዎችን እና የንብረት ወጪዎችን አያካክስም. እና 3 ዘጠኝ ይበቃናል.

ይህ በእርግጥ ሁሉም ጥያቄዎች እኩል የሆኑበት ቀላል ምሳሌ ነው። እና ከ 3 ዘጠኝ እስከ 4 ዘጠኝ ድረስ መሄድ በጣም ቀላል ነው, ግን በተመሳሳይ ጊዜ, ለምሳሌ, ከ 2 ዘጠኝ ወደ 3 መሄድ ቀድሞውኑ የ 9 ሺህ ዶላር ቁጠባ ነው, የገንዘብ ትርጉም ሊኖረው ይችላል. በተፈጥሮ፣ እንደ እውነቱ ከሆነ፣ ጥያቄን አለመመዝገብ ገጽን ካለማሳየት የከፋ ነው፣ ጥያቄዎች የተለያየ ክብደት አላቸው። እነሱ ከንግድ እይታ አንፃር ሙሉ ለሙሉ የተለያዩ መመዘኛዎች ሊኖራቸው ይችላል ፣ ግን አሁንም ፣ እንደ ደንቡ ፣ ስለማንኛውም ልዩ አገልግሎቶች ካልተነጋገርን ፣ ይህ ትክክለኛ አስተማማኝ አቀራረብ ነው።
ለአገልግሎቱ የስነ-ህንፃ መፍትሄ በምንመርጥበት ጊዜ SRE ከአስተባባሪዎች አንዱ ስለመሆኑ አንድ ጥያቄ ደርሶናል። ይህ በተረጋጋ ሁኔታ ላይ ምንም ኪሳራ እንዳይኖር አሁን ባለው መሠረተ ልማት ውስጥ ከመዋሃድ አንጻር ተቀባይነት አለው. አዎ፣ SREዎች የመሳብ ጥያቄዎችን ይጎትታሉ፣ ይፈጽማሉ፣ ይለቃሉ በተመሳሳይ መንገድ፤ በሥነ ሕንፃ ግንባታ፣ በአዳዲስ አገልግሎቶች ትግበራ፣ በአነስተኛ አገልግሎቶች እና በአዳዲስ መፍትሄዎች ትግበራ ላይ ተጽዕኖ ያሳድራሉ። ለምን ቀደም ብዬ ልምድ ትፈልጋለህ፣ መመዘኛ ትፈልጋለህ። በእውነቱ፣ SRE በማንኛውም የስነ-ህንፃ እና የሶፍትዌር መፍትሄ ውስጥ ካሉት ድምጾች ማገድ አንዱ ነው። በዚህ መሠረት SRE እንደ መሐንዲስ በመጀመሪያ ደረጃ መረዳት ብቻ ሳይሆን አንዳንድ የተወሰኑ ውሳኔዎች አስተማማኝነትን ፣ መረጋጋትን እንዴት እንደሚነኩ እና ይህ ከንግድ ፍላጎቶች ጋር እንዴት እንደሚዛመድ መረዳት አለበት ፣ እና ከየትኛው እይታ ይህ ሊፈቀድ ይችላል ። እና ከእሱ ጋር ከሌለ.

ስለዚህ, ስለ አስተማማኝነት መስፈርቶች ለመነጋገር ጊዜው አሁን ነው, በ SRE ውስጥ በተለምዶ እንደ SLA (የአገልግሎት ደረጃ ስምምነት) ይገለጻል. በጣም የታወቀ ቃል ሊሆን ይችላል። SLI (የአገልግሎት ደረጃ አመልካች)። SLO (የአገልግሎት ደረጃ ዓላማ)። የአገልግሎት ደረጃ ስምምነት ምናልባት ጉልህ ቃል ነው፣ በተለይ ከአውታረ መረቦች፣ አቅራቢዎች እና ማስተናገጃዎች ጋር ሰርተው ከሆነ። ይህ የጠቅላላ አገልግሎትዎን አፈጻጸም የሚገልጽ አጠቃላይ ስምምነት ነው, ቅጣቶች, ለስህተቶች አንዳንድ ቅጣቶች, መለኪያዎች, መስፈርቶች. እና SLI የተደራሽነት መለኪያው ራሱ ነው። ማለትም ፣ SLI ምን ሊሆን ይችላል-ከአገልግሎቱ የምላሽ ጊዜ ፣ ​​የስህተት ብዛት እንደ መቶኛ። ስለ አንድ ዓይነት ፋይል ማስተናገጃ እየተነጋገርን ከሆነ ይህ የመተላለፊያ ይዘት ሊሆን ይችላል። ስለ እውቅና ስልተ ቀመሮች እየተነጋገርን ከሆነ, ጠቋሚው ለምሳሌ የመልሱ ትክክለኛነት እንኳን ሊሆን ይችላል. SLO (የአገልግሎት ደረጃ ዓላማ) በቅደም ተከተል የኤስኤልአይ አመልካች፣ እሴቱ እና ጊዜ ጥምር ነው።

SLA እንዲህ ሊሆን ይችላል እንበል. አገልግሎቱ በአመት ውስጥ 99,95% ጊዜ ይገኛል። ወይም 99 ወሳኝ የቴክኒክ ድጋፍ ትኬቶች በ3 ሰዓታት ውስጥ በሩብ ይዘጋሉ። ወይም 85% ጥያቄዎች በየወሩ በ1,5 ሰከንድ ውስጥ ይመለሳሉ። ማለትም ስህተቶች እና ውድቀቶች በጣም የተለመዱ መሆናቸውን ቀስ በቀስ እየተረዳን ነው። ይህ ተቀባይነት ያለው ሁኔታ ነው, ለእሱ እያቀድን ነው, በተወሰነ ደረጃም ቢሆን እንቆጥራለን. ማለትም፣ SRE ስህተቶችን ሊያደርጉ የሚችሉ፣ ለስህተቶች መደበኛ ምላሽ መስጠት ያለባቸውን እና እነሱን ከግምት ውስጥ ማስገባት ያለባቸውን ስርዓቶች ይገነባል። እና ከተቻለ ተጠቃሚው ወይም እንዳያስተውላቸው ወይም እንዳያስተውላቸው ስህተቶችን ማስተናገድ አለባቸው ፣ ግን ሁሉም ነገር ሙሉ በሙሉ እንዳይፈርስ አንድ ዓይነት መፍትሄ አለ።

ለምሳሌ፣ ቪዲዮን ወደ ዩቲዩብ ከሰቀሉ፣ እና ዩቲዩብ ወዲያውኑ መለወጥ ካልቻለ፣ ቪዲዮው በጣም ትልቅ ከሆነ፣ ቅርጸቱ ጥሩ ካልሆነ፣ ጥያቄው በተፈጥሮ ጊዜው ካለፈ በኋላ አይሳካም፣ YouTube 502 አያሳይም። ስህተት፣ ዩቲዩብ እንዲህ ይላል፡ “ሁሉንም ነገር ፈጥረናል፣ ቪዲዮዎ በሂደት ላይ ነው። በ10 ደቂቃ ውስጥ ዝግጁ ይሆናል። ይህ የጸጋ ዝቅጠት መርህ ነው፣ ለምሳሌ፣ ይህን ካደረጉት ከግንባር-መጨረሻ ልማት።

የምንነጋገረው ቀጣይ ቃላቶች, ከአስተማማኝ ጋር ለመስራት በጣም አስፈላጊ ናቸው, ከስህተቶች, ከሚጠበቁ ነገሮች ጋር, MTBF እና MTTR ናቸው. MTBF በውድቀቶች መካከል ያለው አማካይ ጊዜ ነው። MTTR አማካኝ የመልሶ ማግኛ ጊዜ፣ ለማገገም አማካይ ጊዜ። ማለትም ስህተቱ ከታወቀበት ጊዜ አንስቶ ስህተቱ ከታየበት ጊዜ አንስቶ አገልግሎቱ ወደ ሙሉ መደበኛ ስራው እስኪመለስ ድረስ ምን ያህል ጊዜ እንዳለፈ ማለት ነው። MTBF በዋናነት የሚስተካከለው በኮድ ጥራት ላይ በመስራት ነው። ማለትም፣ SREs "አይ" ማለት መቻላቸው ነው። እና ሁሉም ቡድን SRE "አይ" ሲል ሊረዳው የሚገባው እሱ ጎጂ ስለሆነ አይደለም, እሱ መጥፎ አይደለም, ነገር ግን አለበለዚያ ሁሉም ሰው ይሰቃያል.

በድጋሚ, ብዙ ጽሑፎች, ብዙ ዘዴዎች, ብዙ መንገዶች አሉ, ሌላው ቀርቶ ብዙ ጊዜ በምጠቀስበት መጽሐፍ ውስጥ እንኳን, ሌሎች ገንቢዎች SRE ን መጥላት እንዳይጀምሩ እንዴት ማረጋገጥ እንደሚቻል. MTTR፣ በሌላ በኩል፣ በእርስዎ SLO (የአገልግሎት ደረጃ ዓላማ) ላይ ስለመስራት ነው። እና ይሄ በአብዛኛው አውቶማቲክ ነው. ምክንያቱም፣ ለምሳሌ፣ የእኛ SLO በሩብ 4 ዘጠኝ ጊዜ የሚቆይ ነው። ይህ ማለት በ 3 ወራት ውስጥ ለ 13 ደቂቃዎች የእረፍት ጊዜን መፍቀድ እንችላለን. እናም የእኛ MTTR ምናልባት ከ13 ደቂቃ በላይ ሊሆን አይችልም። ቢያንስ ለ 13 የእረፍት ጊዜ ምላሽ ለመስጠት 1 ደቂቃዎችን ከወሰድን, ይህ ማለት በሩብ ዓመቱ ሙሉውን በጀት ጨርሰናል ማለት ነው. SLO እየጣስን ነው። 13 ደቂቃ ምላሽ ለመስጠት እና አለመሳካት ለማሽን ብዙ ነው ነገር ግን ለአንድ ሰው በጣም ትንሽ ነው። ምክንያቱም አንድ ሰው ማንቂያ ሲደርሰው፣ ምላሽ በሚሰጥበት ጊዜ፣ ስህተቱን ባወቀበት ጊዜ፣ ጊዜው ጥቂት ደቂቃዎች ነው። አንድ ሰው እንዴት ማስተካከል እንዳለበት እስኪረዳ ድረስ, በትክክል ምን እንደሚስተካከል, ምን ማድረግ እንዳለበት, ጥቂት ተጨማሪ ደቂቃዎችን ይወስዳል. እና በእውነቱ ፣ ምንም እንኳን እንደ ተለወጠ ፣ አገልጋዩን እንደገና ማስጀመር ወይም አዲስ መስቀለኛ መንገድን ከፍ ማድረግ ቢፈልጉም MTTR በእጅ ከ7-8 ደቂቃዎችን ይወስዳል። ሂደትን በራስ-ሰር በሚሰራበት ጊዜ MTTR ብዙ ጊዜ ወደ ሰከንድ አንዳንዴም ሚሊሰከንዶች ይደርሳል። ጎግል ብዙውን ጊዜ ስለ ሚሊሰከንዶች ይናገራል ፣ ግን በእውነቱ ፣ በእርግጥ ፣ ነገሮች በጣም ጥሩ አይደሉም።

በሐሳብ ደረጃ፣ SRE ማለት ይቻላል ሙሉ በሙሉ ሥራውን በራስ ሰር መሥራት ይኖርበታል፣ ምክንያቱም ይህ በቀጥታ MTTRን፣ ሜትሪክስን፣ የጠቅላላውን አገልግሎት SLO እና፣ በዚህ መሠረት፣ የንግዱን ትርፍ ይነካል። ጊዜው ካለፈ፣ ጥፋቱ ከSRE ጋር እንደሆነ እንጠየቃለን። እንደ እድል ሆኖ, ጥፋቱ በማንም ላይ አይደለም. እና ይህ የተለየ ባህል ነው, እሱም ባልሜል-ድህረ-ሞት ተብሎ የሚጠራው, ዛሬ ስለማንናገርበት, ግን በ Slurm ላይ እንመረምራለን. ይህ ስለ ብዙ ሊነገር የሚችል በጣም አስደሳች ርዕስ ነው። በግምት በሩብ ጊዜ የተመደበው ጊዜ ካለፈ ሁሉም ሰው በጥቂቱ ተወቃሽ ነው ይህም ማለት ሁሉንም ሰው መውቀስ ፍሬያማ አይደለም ማለት ነው፡ ይልቁንስ ምናልባት ማንንም ሳንወቅስ ሁኔታውን አስተካክለን ባለን ነገር እንስራ። በእኔ ልምድ ይህ አቀራረብ ለአብዛኞቹ ቡድኖች በተለይም በሩሲያ ውስጥ ትንሽ እንግዳ ነው, ግን ትርጉም ያለው እና በጣም ጥሩ ይሰራል. ስለዚህ, በመጨረሻ በዚህ ርዕስ ላይ ሊያነቧቸው የሚችሉ ጽሑፎችን እና ጽሑፎችን እመክራለሁ. ወይም ወደ Slurm SRE ይምጡ።

ላብራራ። የ SLO ሩብ ጊዜ ካለፈ፣ የእረፍት ጊዜው 13 ደቂቃ ካልሆነ፣ ግን 15 ከሆነ፣ ለዚህ ​​ተጠያቂው ማን ሊሆን ይችላል? እርግጥ ነው፣ SRE ጥፋተኛ ሊሆን ይችላል ምክንያቱም ግልጽ የሆነ መጥፎ ተግባር ስለፈፀመ ወይም ማሰማራቱ ነው። ለዚህ ተጠያቂው የመረጃ ማእከል አስተዳዳሪው ሊሆን ይችላል፣ምክንያቱም ያልታቀደ ጥገና አድርጎ ሊሆን ይችላል። ለዚህ ተጠያቂው የዳታ ሴንተር አስተዳዳሪ ከሆነ፣ ከኦፕስ የመጣው ሰው በSLO ላይ ሲስማሙ ጥገናን ባለማሰሉ ተጠያቂ ነው። ይህ የአስተዳዳሪው፣ የቴክኒካል ዳይሬክተሩ ወይም የመረጃ ማእከል ኮንትራቱን የፈረመ እና የውሂብ ማዕከል SLA ለተፈለገው ጊዜ ያልተነደፈ መሆኑን ትኩረት ያልሰጠ ሰው ስህተት ነው። በዚህ መሠረት ሁሉም ሰው ለዚህ ሁኔታ ትንሽ ተጠያቂ ነው. እናም ይህ ማለት ለዚህ ሁኔታ በተለይ በማንም ላይ ተጠያቂ ማድረግ ምንም ፋይዳ የለውም ማለት ነው. ግን በእርግጥ መታረም አለበት. ለዛም ነው ድህረ-ሞት የሚኖረው። እና ለምሳሌ GitHub ድህረ-ሞትን ካነበቡ እና ይህ ሁል ጊዜ በጣም አስደሳች ፣ ትንሽ እና በእያንዳንዱ የተለየ ጉዳይ ላይ ያልተጠበቀ ታሪክ ነው ፣ ማንም የዚህ የተለየ ሰው ጥፋተኛ ነው ብሎ የሚናገረውን መተካት ይችላሉ ። ነቀፋ ሁል ጊዜ በተወሰኑ ጉድለቶች ላይ ነው የሚከናወነው።

ወደሚቀጥለው ጥያቄ እንሂድ። አውቶማቲክ. እኔ ብዙውን ጊዜ፣ ስለ አውቶሜሽን በሌላ አውድ ሳወራ፣ በአጠቃላይ ከሚያስቀምጡት በላይ ብዙ ጊዜ እንዳይወስድ ስራን በራስ ሰር ለመስራት ምን ያህል ጊዜ መስራት እንደሚችሉ የሚናገር ሰንጠረዥን ብዙ ​​ጊዜ እጠቅሳለሁ። የሚይዝ ነገር አለ። የሚይዘው ነገር SREዎች አንድን ተግባር በራስ ሰር ሲሰሩ ጊዜን ብቻ ሳይሆን ገንዘብን ይቆጥባሉ ምክንያቱም አውቶሜሽን በቀጥታ በMTTR ላይ ተጽዕኖ ያሳድራል። እነሱ ለማለት ይቻላል የሰራተኞችን እና የገንቢዎችን ሞራል ያድናሉ ፣ ይህ ደግሞ አድካሚ ሀብት ነው። የዕለት ተዕለት እንቅስቃሴን ይቀንሳሉ. እና ይህ ሁሉ በስራ ላይ እና በውጤቱም, በንግድ ስራ ላይ በጎ ተጽእኖ ይኖረዋል, ምንም እንኳን አውቶማቲክ በጊዜ ወጪዎች ላይ ምንም ትርጉም የማይሰጥ ቢመስልም.

እንደ እውነቱ ከሆነ, ሁልጊዜ ማለት ይቻላል, እና በ SRE ሚና ውስጥ የሆነ ነገር በራስ-ሰር መስራት የማይገባባቸው በጣም ጥቂት አጋጣሚዎች አሉ. ቀጥሎ ስለ ስህተት በጀት, ለስህተት በጀት ተብሎ ስለሚጠራው እንነጋገራለን. እንደ እውነቱ ከሆነ፣ ለራስህ ካዘጋጀኸው SLO በተሻለ ሁኔታ እየሠራህ ከሆነ፣ ይህ ደግሞ በጣም ጥሩ አይደለም። ይህ በጣም መጥፎ ነው፣ ምክንያቱም SLO የሚሠራው እንደ ዝቅተኛ ወሰን ብቻ ሳይሆን እንደ ግምታዊ የላይኛው ወሰን ጭምር ነው። እራስዎን 99% ተገኝነት SLO ሲያዘጋጁ እና በእውነቱ 99,99% ሲኖርዎት ለሙከራ የተወሰነ ቦታ እንዳለዎት ይገለጣል ፣ ይህም ንግዱን በጭራሽ አይጎዳውም ፣ ምክንያቱም እርስዎ እራስዎ ይህንን ሁሉ በአንድ ላይ ወስነዋል ፣ እና እርስዎ ይህን ቦታ አይጠቀሙበት. ለስህተቶች በጀት አለዎት, ይህም በእርስዎ ጉዳይ ላይ የማይጠፋ ነው.

ምን እያደረግን ነው? በጥሬው ለሁሉም ነገር እንጠቀማለን. በምርት ሁኔታዎች ውስጥ ለመሞከር, አፈፃፀሙን ሊነኩ የሚችሉ አዳዲስ ባህሪያትን ለመልቀቅ, ለመልቀቅ, ለጥገና, ለታቀዱ የእረፍት ጊዜያት. ተቃራኒው ህግም ይሠራል: በጀቱ ካለቀ, ምንም አዲስ ነገር መልቀቅ አንችልም, ምክንያቱም አለበለዚያ ከ SLO እንበልጣለን. በጀቱ ቀድሞውኑ ተዳክሟል ፣ አንድ ነገር አውጥተናል ፣ በአፈፃፀም ላይ አሉታዊ ተጽዕኖ ካሳደረ ፣ ማለትም ፣ በራሱ SLO ን በቀጥታ የሚጨምር አንዳንድ ማስተካከያ ካልሆነ ፣ ከዚያ ከበጀት በላይ እንሄዳለን ፣ እና ይህ መጥፎ ሁኔታ ነው። ትንተና፣ ከሞት በኋላ እና ምናልባትም አንዳንድ የሂደት እርማት ያስፈልገዋል።

ማለትም ፣ አገልግሎቱ ራሱ በደንብ የማይሰራ ከሆነ ፣ እና SLO ከጠፋ እና በጀቱ በሙከራዎች ላይ ካልሆነ ፣ በማንኛውም የተለቀቁ ላይ ሳይሆን በራሱ ፣ ከዚያ ከአንዳንድ አስደሳች ጥገናዎች ይልቅ ፣ ሳቢ ከመሆን ይልቅ። ባህሪያት, ይልቅ አስደሳች የተለቀቁ. ማንኛውንም የፈጠራ ስራ ከመስራት ይልቅ በጀቱን በቅደም ተከተል ለመመለስ ወይም SLO ን ለማረም ዲዳ ማስተካከያዎችን ማድረግ አለቦት ይህ ደግሞ ብዙ ጊዜ መከሰት የሌለበት ሂደት ነው።

ስለዚህ ፣ ለስህተቶች የበለጠ በጀት ባለንበት ሁኔታ ሁሉም ሰው ፍላጎት አለው-SRE እና ገንቢዎች። ለገንቢዎች፣ ለስህተቶች ትልቅ በጀት ማለት ልቀቶችን፣ ሙከራዎችን እና ሙከራዎችን ማስተናገድ ይችላሉ። ለኤስአርኤዎች፣ ለስህተቶች በጀት እና ወደዚህ በጀት መግባት ማለት በእውነቱ ጥሩ ስራ እየሰሩ ነው ማለት ነው። እና ይህ የአንድ ዓይነት የጋራ ሥራ ተነሳሽነት ላይ ተጽዕኖ ያሳድራል። የእርስዎን SREs እንደ ገንቢዎች የሚያዳምጡ ከሆነ፣ ጥሩ ስራ ለመስራት እና ብዙ ስራዎችን ለመስራት ብዙ ቦታ ይኖርዎታል።

በምርት ላይ ያሉ ሙከራዎች በትልልቅ ቡድኖች ውስጥ በጣም አስፈላጊ እና ከሞላ ጎደል የ SRE ዋና አካል ናቸው። እና ብዙውን ጊዜ Chaos Monkey የተባለ መገልገያ ከተለቀቀው Netflix ላይ ካለው ቡድን የመጣው ትርምስ ምህንድስና በሚለው ስም ይሄዳል።
Chaos Monkey ከሲአይ/ሲዲ ቧንቧ መስመር ጋር ይገናኛል እና በአጋጣሚ አገልጋዩን በምርት ላይ ያበላሸዋል። በድጋሚ በ SRE መዋቅር ውስጥ የተበላሸ አገልጋይ በራሱ መጥፎ አይደለም, ይጠበቃል. እና በጀቱ ውስጥ ከተካተተ, ተቀባይነት ያለው እና ንግዱን አይጎዳውም. በእርግጥ ኔትፍሊክስ በቂ ያልተደጋገሙ ሰርቨሮች፣ በቂ ማባዛት፣ ይህ ሁሉ ተጠቃሚው በአጠቃላይ ሳያስተውል ሊስተካከል የሚችል ነው፣ እና በእርግጠኝነት አንድ አገልጋይ ለየትኛውም በጀት የሚተው የለም።

ኔትፍሊክስ በአንድ ወቅት ሙሉ የእንደዚህ አይነት መገልገያዎች ስብስብ ነበረው, ከነዚህም አንዱ, Chaos Gorilla, በአማዞን ውስጥ ከሚገኙት ዞኖች አንዱን ሙሉ በሙሉ ያሰናክላል. እና እንደነዚህ ያሉት ነገሮች በመጀመሪያ ፣ የተደበቁ ጥገኞችን ለመለየት ይረዳሉ ፣ ምን ተጽዕኖ እንደሚያሳድር ፣ በምን ላይ እንደሚመረኮዝ ሙሉ በሙሉ ግልፅ ካልሆነ። እና ይሄ, ከማይክሮ ሰርቪስ ጋር እየሰሩ ከሆነ እና ሰነዱ ሙሉ በሙሉ ፍጹም ካልሆነ, ይህ ለእርስዎ ሊያውቅ ይችላል. እና በድጋሜ, ይህ በማዘጋጀት ጊዜ ሊይዙት የማይችሉትን በኮዱ ውስጥ ስህተቶችን ለመያዝ ይረዳል, ምክንያቱም ማንኛውም አቀማመጥ ትክክለኛ ማስመሰል አይደለም, ምክንያቱም የመጫኛ መለኪያው የተለየ ስለሆነ, የመጫኛ ንድፍ የተለየ ነው, መሳሪያዎቹም እንዲሁ, አብዛኛዎቹ ናቸው. ሊሆን ይችላል, ሌላ. ከፍተኛ ጭነቶች ያልተጠበቁ እና ያልተጠበቁ ሊሆኑ ይችላሉ. እና እንደዚህ ዓይነቱ ሙከራ እንደገና ከበጀት በላይ የማይሄድ ፣ በመሠረተ ልማት ፣ በአውቶሞተሮች እና በሲአይ/ሲዲ ቧንቧዎች በጭራሽ የማይያዙ ስህተቶችን በደንብ ይረዳል ። እና ይህ ሁሉ በበጀትዎ ውስጥ እስካካተተው ድረስ አገልግሎትዎ እዚያ መውጣቱ ምንም አይደለም, ምንም እንኳን በጣም የሚያስፈራ ቢመስልም, አገልጋዩ ተሰናክሏል, ምን አይነት ቅዠት ነው. አይ፣ ያ የተለመደ ነው፣ ያ ጥሩ ነው፣ ስህተቶችን ለመያዝ ይረዳል። በጀት ካለህ ማውጣት ትችላለህ።

ጥያቄ፡- ምን ዓይነት ሥነ ጽሑፍ ልመክረው እችላለሁ? ዝርዝሩ መጨረሻ ላይ ነው። ብዙ ጽሑፎች አሉ, ብዙ ሪፖርቶችን እመክራለሁ. እንዴት እንደሚሰራ እና SRE የራሳቸው የሶፍትዌር ምርት በሌሉበት ወይም በትንሹ እድገት በኩባንያዎች ውስጥ እንደሚሰራ። ለምሳሌ, በድርጅት ውስጥ, ዋናው እንቅስቃሴው ሶፍትዌር ካልሆነ. በድርጅት ውስጥ ፣ ዋናው እንቅስቃሴው ሶፍትዌር ካልሆነ ፣ SRE ልክ እንደሌላው ቦታ ይሰራል ፣ ምክንያቱም በድርጅት ውስጥ እርስዎም መጠቀም አለብዎት ፣ ምንም እንኳን ባይገነቡም ፣ የሶፍትዌር ምርቶችን ፣ ዝመናዎችን ማውጣት ያስፈልግዎታል ፣ እርስዎ መሠረተ ልማቱን መቀየር፣ ማደግ፣ መመዘን ያስፈልጋል። እና SREs በእነዚህ ሂደቶች ውስጥ ሊከሰቱ የሚችሉ ችግሮችን ለመለየት እና ለመተንበይ ይረዳሉ እና አንዳንድ እድገት ከጀመሩ እና የንግድ ፍላጎቶች ከተቀየሩ በኋላ ይቆጣጠራሉ። ምክንያቱም SRE እንዲኖርዎት በሶፍትዌር ልማት ውስጥ መሳተፍ በፍጹም አስፈላጊ አይደለም፣ ቢያንስ ብዙ አገልጋዮች ካሉዎት እና ቢያንስ የተወሰነ እድገትን የሚጠብቁ ከሆነ።

ለአነስተኛ ፕሮጀክቶች, ትናንሽ ድርጅቶች ተመሳሳይ ነው, ምክንያቱም ትላልቅ ኩባንያዎች ለሙከራ በጀት እና ቦታ አላቸው. ግን በተመሳሳይ ጊዜ, እነዚህ ሁሉ የሙከራ ፍሬዎች በየትኛውም ቦታ ጥቅም ላይ ሊውሉ ይችላሉ, ማለትም, SREs, በ Google, Netflix እና Dropbox ውስጥ ታይተዋል. ግን በተመሳሳይ ጊዜ ትናንሽ ኩባንያዎች እና ጀማሪዎች ቀድሞውኑ የተጨመቁ ነገሮችን ማንበብ, መጽሃፎችን ማንበብ እና ሪፖርቶችን መመልከት ይችላሉ. ስለዚህ ጉዳይ ብዙ ጊዜ መስማት ይጀምራሉ, የተወሰኑ ምሳሌዎችን ይመልከቱ, እንደማስበው, እሺ, ይህ በእርግጥ ጠቃሚ ሊሆን ይችላል, ይህ ደግሞ ያስፈልገናል, አሪፍ.

ያም ማለት, እነዚህን ሂደቶች መደበኛ ለማድረግ ሁሉም ዋና ስራዎች አስቀድመው ተከናውነዋል. ማድረግ ያለብዎት ነገር ቢኖር በኩባንያዎ ውስጥ የ SRE ሚናን መግለፅ እና እነዚህን ሁሉ ልምዶች በትክክል መተግበር መጀመር ብቻ ነው, ይህም እንደገና, ቀደም ሲል ተብራርቷል. ማለትም ፣ ለአነስተኛ ኩባንያዎች ጠቃሚ ከሆኑ መርሆዎች ፣ ይህ ሁልጊዜ የ SLA ፣ SLI ፣ SLO ፍች ነው። በሶፍትዌር ውስጥ ካልተሳተፉ, እነዚህ ውስጣዊ SLAs እና ውስጣዊ SLOs, ለስህተት ውስጣዊ በጀት ይሆናሉ. ይህ ሁልጊዜ ማለት ይቻላል በቡድኑ ውስጥ እና በንግዱ ውስጥ ወደ አንዳንድ አስደሳች ውይይቶች ይመራል ፣ ምክንያቱም እርስዎ ለመሠረተ ልማት ፣ ለአንዳንድ ተስማሚ ሂደቶች አደረጃጀት ፣ ተስማሚ የቧንቧ መስመር ላይ ከሚያስፈልገው በላይ ወጪ እያወጡ ነው ። እና እነዚህ በ IT ክፍል ውስጥ ያላችሁ 4 ዘጠኝ, አሁን በትክክል አያስፈልጓቸውም. ነገር ግን በተመሳሳይ ጊዜ, ጊዜ ማሳለፍ ይቻል ነበር, በሌላ ነገር ላይ ስህተቶች የሚሆን በጀት ማውጣት.

በዚህ መሠረት የክትትል ቁጥጥር እና አደረጃጀት ለማንኛውም መጠን ላለው ኩባንያ ጠቃሚ ነው. እና በአጠቃላይ ይህ የአስተሳሰብ መንገድ, ስህተቶች ተቀባይነት ያለው ነገር, በጀት ባለበት, አላማዎች ባሉበት, ከ 3 ሰው ጅምር ጀምሮ ለማንኛውም መጠን ላለው ኩባንያ እንደገና ጠቃሚ ነው.

ልንነጋገርባቸው የምንችላቸው የቴክኒካዊ ልዩነቶች የመጨረሻው ክትትል ነው. ምክንያቱም ስለ SLA፣ SLI፣ SLO ከተነጋገርን ከበጀት ጋር መስማማት አለመሆናችንን፣ ግቦቻችንን እንደምናከብር እና በመጨረሻው SLA ላይ እንዴት ተጽእኖ እንዳለን ሳንቆጣጠር ልንረዳ አንችልም። ክትትል በሚከተለው መንገድ እንደሚከሰት ብዙ ጊዜ አስተውያለሁ፡ አንዳንድ ዋጋ አለ ለምሳሌ፡ ለአገልጋዩ የሚቀርብበት ጊዜ፡ አማካኝ ሰዓት ወይም የውሂብ ጎታው የጥያቄዎች ብዛት። በኢንጂነሩ የሚወሰን መለኪያ አለው። ልኬቱ ከመደበኛው የተለየ ከሆነ ኢሜይል ይላካል። ይህ ሁሉ ፍጹም ከንቱ ነው ፣ እንደ ደንቡ ፣ ምክንያቱም ወደ እንደዚህ ዓይነት የማንቂያዎች መጨናነቅ ፣ የክትትል መልእክቶች ከመጠን በላይ መጨመር ፣ አንድ ሰው በመጀመሪያ ፣ በእያንዳንዱ ጊዜ እነሱን መተርጎም ሲኖርበት ፣ ማለትም ፣ የሜትሪክ እሴቱ አስፈላጊነት ማለት እንደሆነ ይወስኑ። አንድ ዓይነት ድርጊት። እና ሁለተኛ, እሱ በቀላሉ እነዚህን ሁሉ ማንቂያዎች ማስተዋል ያቆማል, በመሠረቱ ምንም እርምጃ ከእሱ የማይፈለግ ከሆነ. ማለትም፣ ጥሩ የክትትል ህግ እና SRE በሚተገበርበት ጊዜ የመጀመሪያው ህግ ማሳወቂያ መምጣት ያለበት እርምጃ ሲያስፈልግ ብቻ ነው።

በመደበኛ ሁኔታ 3 የክስተቶች ደረጃዎች አሉ. ማንቂያዎች አሉ, ቲኬቶች አሉ, ምዝግብ ማስታወሻዎች አሉ. ማንቂያዎች ከእርስዎ ፈጣን እርምጃ የሚፈልግ ማንኛውም ነገር ነው። ያም ማለት ሁሉም ነገር ተሰብሯል, አሁን መስተካከል አለበት. ትኬቶች በመጠባበቅ ላይ ያሉ እርምጃዎችን የሚጠይቁ ናቸው። አዎ, አንድ ነገር ማድረግ ያስፈልግዎታል, አንድ ነገር በእጅዎ ማድረግ ያስፈልግዎታል, አውቶሜትድ አልተሳካም, ነገር ግን በሚቀጥሉት ጥቂት ደቂቃዎች ውስጥ ማድረግ የለብዎትም. ምዝግብ ማስታወሻዎች ድርጊትን የማይጠይቁ ነገሮች ናቸው, እና በአጠቃላይ, ነገሮች በጥሩ ሁኔታ ከሄዱ, ማንም ማንም አያነበውም. ምዝግብ ማስታወሻዎቹን ማንበብ አስፈላጊ ይሆናል ፣ ከኋላ ፣ አንድ ነገር ለተወሰነ ጊዜ እንደተሰበረ ሲታወቅ ፣ ስለእሱ አናውቅም። ወይም አንድ ዓይነት ምርመራ መደረግ አለበት. ነገር ግን በአጠቃላይ ምንም አይነት እርምጃ የማይፈልግ ሁሉም ነገር ወደ ምዝግብ ማስታወሻዎች ይሄዳል.

የዚህ ሁሉ የጎንዮሽ ጉዳት፣ የትኛዎቹ ክንውኖች ድርጊቶችን እንደሚፈልጉ ለይተን ካወቅን እና ድርጊቱ ምን መሆን እንዳለበት በደንብ ከገለፅን ይህ ማለት ድርጊቱ በራስ-ሰር ሊሠራ ይችላል ማለት ነው። ምን ይሆናል ማለት ነው። ከማስጠንቀቂያ እየመጣን ነው። ወደ ተግባር እንሂድ። ወደዚህ ድርጊት መግለጫ እንሂድ. እና ከዚያ ወደ አውቶሜትድ እንሄዳለን. ያም ማለት ማንኛውም አውቶማቲክ ለአንድ ክስተት ምላሽ በመስጠት ይጀምራል.

ከክትትል ወደ ታዛቢነት ወደ ሚባለው ቃል እንሸጋገራለን. ባለፉት ጥቂት አመታት በዚህ ቃል ዙሪያ ትንሽ ማበረታቻም ነበር። እና ይህ ከዐውደ-ጽሑፉ ውጪ ምን ማለት እንደሆነ የሚረዱት ጥቂት ሰዎች ናቸው። ነገር ግን ዋናው ነጥብ ታዛቢነት የስርዓት ግልጽነት መለኪያ ነው. የሆነ ችግር ከተፈጠረ፣ ምን ያህል በትክክል እንደተሳሳተ እና የስርዓቱ ሁኔታ በዚያን ጊዜ ምን ያህል እንደሆነ በፍጥነት ማወቅ ይችላሉ። ከኮድ እይታ: የትኛው ተግባር አልተሳካም, የትኛው አገልግሎት አልተሳካም. ለምሳሌ ፣ የውስጥ ተለዋዋጮች ፣ ውቅረት ሁኔታው ​​ምን ነበር? ከመሠረተ ልማት እይታ አንጻር ይህ የተገኘበት ዞን ውድቀቱ የተከሰተበት ነው, እና አንዳንድ ዓይነት Kubernetes ካሉዎት, በየትኛው ፖድ ውስጥ ውድቀት ተከስቷል, የፖዳው ሁኔታ ምን ነበር. እና በዚህ መሠረት, ታዛቢነት ከ MTTR ጋር ቀጥተኛ ግንኙነት አለው. የአገልግሎቱ ታዛቢነት ከፍ ባለ መጠን ስህተቱን ለመለየት ቀላል ነው, ስህተቱን ለማስተካከል ቀላል ነው, ስህተቱን በራስ-ሰር ለማድረግ ቀላል ነው, የ MTTR ዝቅተኛ ነው.

ወደ ትናንሽ ኩባንያዎች እንደገና ከሄድን, አሁን እንኳን, ከቡድኑ መጠን ጋር ምን እንደሚደረግ, እና በትንሽ ቡድን ውስጥ የተለየ SRE መቅጠር አስፈላጊ እንደሆነ ይጠይቃሉ. ስለዚህ ጉዳይ ትንሽ ቀደም ብሎ ተናግሬያለሁ። በጅምር ወይም ለምሳሌ በቡድን የመጀመሪያ የእድገት ደረጃዎች ውስጥ ይህ በጭራሽ አስፈላጊ አይደለም ፣ ምክንያቱም SRE የሽግግር ሚና ሊደረግ ይችላል። እና ይሄ ቡድኑን በጥቂቱ ያሳድጋል, ምክንያቱም ቢያንስ አንዳንድ ልዩነቶች አሉ. እና በተጨማሪም ፣ ከዕድገቱ ጋር ፣ በአጠቃላይ ፣ የ SRE ኃላፊነቶች በከፍተኛ ሁኔታ ስለሚቀየሩ ሰዎችን ያዘጋጃል። አንድን ሰው ከቀጠሩት, በእርግጥ, እሱ አንዳንድ የሚጠበቁ ነገሮች አሉት. እና እነዚህ ተስፋዎች በጊዜ ሂደት አይለወጡም, ነገር ግን መስፈርቶቹ በጣም ይለወጣሉ. ስለዚህ በመጀመሪያዎቹ ደረጃዎች SRE መቅጠር በጣም ከባድ ነው። የራስዎን ማሳደግ በጣም ቀላል ነው። ግን ማሰብ ተገቢ ነው።

ብቸኛው ልዩነት, ምናልባትም, በጣም ጥብቅ እና በሚገባ የተገለጹ የከፍታ መስፈርቶች ሲኖሩ ነው. ማለትም ፣ በጅምር ላይ ፣ ይህ ከባለሀብቶች የተወሰነ ዓይነት ግፊት ፣ በአንድ ጊዜ ብዙ ጊዜ የእድገት ትንበያ ሊሆን ይችላል። ከዚያ SRE መቅጠር በአጠቃላይ ትክክል ነው ምክንያቱም ሊጸድቅ ይችላል። የእድገት መስፈርቶች አሉን, በእንደዚህ አይነት እድገት ምንም ነገር እንደማይሰበር የማረጋገጥ ኃላፊነት ያለበት ሰው እንፈልጋለን.

አንድ ተጨማሪ ጥያቄ። ብዙ ጊዜ ገንቢዎች ሙከራዎችን የሚያልፍ ባህሪን ሲቆርጡ, ነገር ግን ምርቱን ሲሰብሩ, የውሂብ ጎታውን ሲጭኑ, ሌሎች ባህሪያትን ሲሰብሩ ምን እንደሚደረግ, ምን አይነት ሂደት እንደሚተገበር. በዚህ መሠረት, በዚህ ጉዳይ ላይ, ለስህተቶች በጀት ቀርቧል. እና አንዳንድ አገልግሎቶች፣ አንዳንድ ባህሪያት በምርት ላይ ወዲያውኑ ይሞከራሉ። ይህ ካናሪ ሊሆን ይችላል፣ ጥቂት ቁጥር ያላቸው ተጠቃሚዎች ብቻ፣ ነገር ግን በማምረት ላይ ያሉ፣ አንድ ባህሪ እያሰማሩ ነው፣ ነገር ግን የሆነ ነገር ቢሰበር፣ ለምሳሌ፣ ለሁሉም ተጠቃሚዎች ግማሽ በመቶ፣ አሁንም በ ለስህተት በጀት. በዚህ መሠረት, አዎ, ስህተት ይሆናል, ለአንዳንድ ተጠቃሚዎች ሁሉም ነገር ይቋረጣል, ነገር ግን ይህ የተለመደ ነው ብለን ተናግረናል.

ስለ SRE መሳሪያዎች ጥያቄ ነበር። ማለትም፣ SREs ሁሉም ሰው የማይጠቀምበት የተለየ ነገር አለ? በእርግጥ፣ አንዳንድ በጣም ልዩ የሆኑ መገልገያዎች አሉ፣ አንዳንድ ሶፍትዌሮች አሉ ለምሳሌ ሸክሞችን የሚመስል ወይም የካናሪ ኤ/ቢ ሙከራን ያደርጋል። ነገር ግን በመሠረታዊነት፣ የኤስአርኢ መሣሪያ ገንቢዎችዎ አስቀድመው እየተጠቀሙበት ያለው ነው። SRE በቀጥታ ከልማት ቡድን ጋር ስለሚገናኝ። እና የተለያዩ መሳሪያዎች ካሉዎት, ለማመሳሰል ጊዜ እንደሚወስድ ይገለጣል. በተለይም SRE በትልልቅ ቡድኖች ውስጥ ቢሰሩ፣ ብዙ ቡድኖች ሊኖሩ በሚችሉባቸው ትላልቅ ኩባንያዎች ውስጥ፣ የኩባንያው አቀፍ ደረጃ አሰጣጥ እዚህ በጣም ጠቃሚ ይሆናል፣ ምክንያቱም 50 ቡድኖች 50 የተለያዩ መገልገያዎችን የሚጠቀሙ ከሆነ ይህ ማለት SRE ሁሉንም ማወቅ አለበት ማለት ነው። እና በእርግጥ ይህ በጭራሽ አይሆንም. እና የስራ ጥራት, ቢያንስ የአንዳንድ ቡድኖች ቁጥጥር ጥራት በከፍተኛ ሁኔታ ይቀንሳል.

የእኛ ዌቢናር ቀስ በቀስ ወደ ማብቂያው እየመጣ ነው። አንዳንድ መሰረታዊ ነገሮችን ልነግርህ ቻልኩ። እርግጥ ነው, ስለ SRE ምንም ነገር በአንድ ሰዓት ውስጥ ሊነገር እና ሊረዳ አይችልም. ነገር ግን ይህንን የአስተሳሰብ መንገድ፣ ዋና ዋና ዋና ነጥቦችን ለማስተላለፍ እንደቻልኩ ተስፋ አደርጋለሁ። እና ከዚያ, ፍላጎት ካሎት, በርዕሱ ላይ በጥልቀት መመርመር, በራስዎ ማጥናት እና በሌሎች ኩባንያዎች ውስጥ በሌሎች ሰዎች እንዴት እንደሚተገበር ይመልከቱ. እና በዚህ መሰረት፣ በየካቲት ወር መጀመሪያ፣ በ Slurm SRE ወደ እኛ ይምጡ።

Slurm SRE አሁን ስለምናገረው በግምት የሚሸፍን የሶስት ቀን የተጠናከረ ኮርስ ነው፣ ነገር ግን በላቀ ጥልቀት፣ ከትክክለኛ ጉዳዮች፣ ከተግባር ጋር፣ አጠቃላይ አጠቃላይ ስራው በተግባራዊ ስራ ላይ ያነጣጠረ ነው። ሰዎች በቡድን ይከፋፈላሉ. ሁላችሁም በእውነተኛ ጉዳዮች ላይ ትሰራላችሁ። በዚህ መሠረት ከ Booking.com ኢቫን ክሩሎቭ እና ቤን ታይለር አስተማሪዎች አሉን። ከጉግል ከሳን ፍራንሲስኮ የመጣ ድንቅ Evgeniy Varabbas አለን። እኔም አንድ ነገር እነግራችኋለሁ. ስለዚህ እኛን ለመጎብኘት መምጣትዎን እርግጠኛ ይሁኑ.
ስለዚህ, የማጣቀሻዎች ዝርዝር. በ SRE ላይ አገናኞች አሉ። የመጀመሪያው በዚያው መጽሐፍ ላይ፣ ወይም ይልቁንም በGoogle የተጻፉ ስለ SRE 2 መጽሐፍት። ሌላኛው SLA ላይ ትንሽ ጽሑፍ, SLI, SLO, ውሎች እና አተገባበራቸው ትንሽ በበለጠ ዝርዝር ውስጥ የተገለጹበት. የሚቀጥሉት 3 በተለያዩ ኩባንያዎች ውስጥ በ SRE ላይ ሪፖርቶች ናቸው. አንደኛ - የ SRE ቁልፎች, ይህ የቤን አሰልጣኝ ከ Google ዋና ማስታወሻ ነው. ሁለተኛ - SRE በ Dropbox ላይ. ሦስተኛው እንደገና ስለ ነው SRE በ Google ላይ. አራተኛ ዘገባ ከ SRE በ Netflix ላይበ 5 አገሮች ውስጥ 190 ቁልፍ የ SRE ሰራተኞች ብቻ ያሉት። እነዚህን ሁሉ መመልከቱ በጣም አስደሳች ነው, ምክንያቱም DevOps ለተለያዩ ኩባንያዎች እና ለተለያዩ ቡድኖች እንኳን በጣም የተለያዩ ነገሮችን እንደሚያመለክት ሁሉ, SRE ተመሳሳይ መጠን ባላቸው ኩባንያዎች ውስጥም ቢሆን በጣም የተለያየ ሃላፊነት አለው.

በሁከት ምህንድስና መርሆዎች ላይ 2 ተጨማሪ አገናኞች፡- (1), (2). እና መጨረሻ ላይ ስለ አስደናቂ ዝርዝሮች ተከታታይ 3 ዝርዝሮች አሉ። ትርምስ ምህንድስና, ስለ SRE እና ስለ SRE መሣሪያ ስብስብ. በ SRE ላይ ያለው ዝርዝር በማይታመን ሁኔታ ትልቅ ነው, ሁሉንም ማለፍ አያስፈልግዎትም, ወደ 200 የሚጠጉ ጽሑፎች አሉ. ስለ አቅም ማቀድ እና እንከን የለሽ ድኅረ ሞትን በተመለከተ ጽሑፎቹን በጣም እመክራለሁ።

የሚስብ ጽሑፍ፡- SRE እንደ የሕይወት ምርጫ

በዚህ ጊዜ ሁሉ ስላዳመጥከኝ አመሰግናለሁ። የሆነ ነገር እንደተማርክ ተስፋ አደርጋለሁ። የበለጠ ለመማር በቂ ቁሳቁሶች እንዳሎት ተስፋ አደርጋለሁ። እና በኋላ እንገናኝ። በየካቲት ውስጥ ተስፋ እናደርጋለን.
ዌቢናር የተስተናገደው በኤድዋርድ ሜድቬዴቭ ነበር።

PS: ማንበብ ለሚፈልጉ ኤድዋርድ የማመሳከሪያዎችን ዝርዝር አቅርቧል። በተግባር ለመረዳት የሚመርጡ ሰዎች በ Slurme SRE.

ምንጭ: hab.com