webinar හි දුර්වල ශ්‍රව්‍ය ඇත, එබැවින් අපි එය පිටපත් කර ඇත.
මගේ නම Medvedev Eduard. අද මම SRE යනු කුමක්ද, SRE දර්ශනය වූ ආකාරය, SRE ඉංජිනේරුවන්ට ඇති වැඩ නිර්ණායක මොනවාද, විශ්වසනීයත්ව නිර්ණායක ගැන ටිකක්, එහි අධීක්ෂණය ගැන ටිකක් කතා කරන්නෙමි. ඔබට පැයකින් බොහෝ දේ පැවසිය නොහැකි නිසා අපි මුදුන් මත ඇවිදින්නෙමු, නමුත් මම අමතර සමාලෝචනයක් සඳහා ද්රව්ය ලබා දෙමි, අපි සියල්ලෝම ඔබ එනතුරු බලා සිටිමු. . ජනවාරි අවසානයේ මොස්කව්හිදී.
පළමුව, SRE යනු කුමක්ද යන්න ගැන කතා කරමු - Site Reliability Engineering. සහ එය වෙනම පිහිටීමක් ලෙස, වෙනම දිශාවක් ලෙස පෙනී සිටි ආකාරය. ඒ සියල්ල ආරම්භ වූයේ සාම්ප්‍රදායික සංවර්ධන කවයන් තුළ, Dev සහ Ops සම්පූර්ණයෙන්ම වෙනස් කණ්ඩායම් දෙකක් වන අතර, සාමාන්යයෙන් සම්පූර්ණයෙන්ම වෙනස් ඉලක්ක දෙකක් ඇත. සංවර්ධන කණ්ඩායමේ ඉලක්කය වන්නේ නව විශේෂාංග එළිදැක්වීම සහ ව්‍යාපාරයේ අවශ්යතා සපුරාලීමයි. Ops කණ්ඩායමේ ඉලක්කය වන්නේ සෑම දෙයක්ම ක්රියාත්මක වන අතර කිසිවක් කැඩී නොයන බවට වග බලා ගැනීමයි. පැහැදිලිවම, මෙම අරමුණු එකිනෙක සෘජුව පරස්පර වේ: සෑම දෙයක්ම වැඩ කිරීමට සහ කිසිවක් කැඩීමට, හැකිතාක් අඩුවෙන් නව විශේෂාංග ඉදිරිපත් කරන්න. මේ නිසා, දැන් DevOps ලෙස හඳුන්වන ක්‍රමවේදය විසඳා ගැනීමට උත්සාහ කරන අභ්‍යන්තර ගැටුම් රාශියක් ඇත.
ගැටළුව වන්නේ අපට DevOps පිළිබඳ පැහැදිලි නිර්වචනයක් සහ DevOps පිළිබඳ පැහැදිලි ක්රියාත්මක කිරීමක් නොමැති වීමයි. මම මීට වසර 2 කට පෙර Yekaterinburg හි පැවති සම්මන්ත්‍රණයකදී කතා කළ අතර, මේ දක්වා DevOps අංශය ආරම්භ වූයේ “DevOps යනු කුමක්ද” වාර්තාවෙනි. 2017 දී, Devops වයස අවුරුදු 10 කට ආසන්නයි, නමුත් අපි තවමත් එය කුමක්දැයි තර්ක කරමින් සිටිමු. තවද මෙය වසර කිහිපයකට පෙර ගූගල් විසින් විසඳා ගැනීමට උත්සාහ කළ ඉතා අමුතු තත්වයක්.
2016 දී Google විසින් Site Reliability Engineering නමින් පොතක් නිකුත් කරන ලදී. ඇත්ත වශයෙන්ම, SRE ව්‍යාපාරය ආරම්භ වූයේ මෙම පොත සමඟ ය. SRE යනු නිශ්චිත සමාගමක DevOps ආකෘතියේ නිශ්චිත ක්රියාත්මක කිරීමකි. පද්ධති විශ්වසනීයව ක්රියාත්මක වන බව සහතික කිරීමට SRE ඉංජිනේරුවන් කැපවී සිටිති. ඔවුන් බොහෝ දුරට පැමිණෙන්නේ සංවර්ධකයින්ගෙන්, සමහර විට ශක්තිමත් සංවර්ධන පසුබිමක් ඇති පරිපාලකයින්ගෙන්. පද්ධති පරිපාලකයින් කළ දේ ඔවුන් කරයි, නමුත් කේතය අනුව පද්ධතිය පිළිබඳ සංවර්ධනය සහ දැනුම පිළිබඳ ශක්තිමත් පසුබිමක් මෙම පුද්ගලයින් සාමාන්ය පරිපාලන කටයුතුවලට නැඹුරු නොවන නමුත් ස්වයංක්රීයකරණයට නැඹුරු වේ.
ව්‍යුහාත්මක ගැටළු විසඳන SRE ඉංජිනේරුවන් සිටින නිසා SRE කණ්ඩායම්වල DevOps ආදර්ශය ක්රියාත්මක වන බව පෙනේ. ඔන්න ඕකයි අවුරුදු 8ක් තිස්සේ මිනිස්සු කතා කරපු Dev සහ Ops අතරේ එකම සම්බන්ධය. නවකයන් SREs බවට පත් නොවීම තුළ SRE හි කාර්යභාරය ගෘහ නිර්මාණ ශිල්පියෙකුගේ කාර්යභාරයට සමාන වේ. ඔවුන්ගේ වෘත්තිය ආරම්භයේ සිටින පුද්ගලයින්ට තවමත් අත්දැකීම් නොමැත, අවශ්ය දැනුමේ පළල නොමැත. මක්නිසාද යත් SRE හට වැරදි විය හැක්කේ කුමක්ද සහ කවදාද යන්න පිළිබඳව ඉතා සියුම් දැනුමක් අවශ්ය වේ. එමනිසා, සමාගම තුළ සහ පිටත නීතියක් ලෙස මෙහි යම් අත්දැකීමක් අවශ්ය වේ.
SRE සහ devops අතර වෙනස විස්තර කරන්නේ දැයි ඔවුන් අසයි. ඇය විස්තර කර ඇත. සංවිධානයේ SRE හි ස්ථානය ගැන අපට කතා කළ හැකිය. Ops තවමත් වෙනම දෙපාර්තමේන්තුවක් වන මෙම සම්භාව්‍ය DevOps ප්‍රවේශය මෙන් නොව, SRE සංවර්ධන කණ්ඩායමේ කොටසකි. ඔවුන් නිෂ්පාදන සංවර්ධනය සඳහා සම්බන්ධ වේ. SRE යනු එක් සංවර්ධකයෙකුගෙන් තවත් කෙනෙකුට යන භූමිකාවක් වන ප්‍රවේශයක් පවා තිබේ. ඔවුන් කේත සමාලෝචන වලට සහභාගී වන්නේ, උදාහරණයක් ලෙස, UX නිර්මාණකරුවන්, සංවර්ධකයින්, සමහර විට නිෂ්පාදන කළමනාකරුවන් ලෙස ය. SRE එකම මට්ටමේ වැඩ කරයි. අපි ඒවා අනුමත කළ යුතුයි, අපි ඒවා සමාලෝචනය කළ යුතුයි, එවිට එක් එක් යෙදවීම සඳහා SRE පවසන්නේ: “හරි, මෙම යෙදවීම, මෙම නිෂ්පාදනය විශ්වසනීයත්වයට අහිතකර ලෙස බලපාන්නේ නැත. එය එසේ නම්, යම් පිළිගත හැකි සීමාවන් තුළ. අපි මේ ගැනත් කතා කරමු.
ඒ අනුව, කේතය වෙනස් කිරීමට SRE හට නිෂේධ බලය ඇත. සාමාන්යයෙන්, SRE වැරදි ලෙස ක්රියාත්මක කළහොත් මෙය යම් ආකාරයක කුඩා ගැටුමකට ද හේතු වේ. Site Reliability Engineering ගැන එකම පොතේ, එක කොටසක්වත් නොව, බොහෝ කොටස් මෙම ගැටුම් මඟහරවා ගන්නේ කෙසේදැයි කියනු ලැබේ.
SRE තොරතුරු ආරක්ෂාවට සම්බන්ධ වන්නේ කෙසේදැයි ඔවුන් අසයි. SRE තොරතුරු ආරක්ෂාව සඳහා සෘජුවම සම්බන්ධ නොවේ. මූලික වශයෙන්, විශාල සමාගම්වල, මෙය සිදු කරනු ලබන්නේ පුද්ගලයන්, පරීක්ෂකයින්, විශ්ලේෂකයින් විසිනි. නමුත් SRE ඔවුන් සමඟ අන්තර් ක්රියා කරන්නේ සමහර මෙහෙයුම්, සමහර කැපවීම්, ආරක්ෂාවට බලපාන සමහර යෙදවීම් නිෂ්පාදනයේ ඇති බව කෙරෙහි ද බලපෑ හැකිය. එබැවින්, සමස්තයක් ලෙස SRE හට විශ්ලේෂකයින් ඇතුළු ආරක්ෂක කණ්ඩායම් ඇතුළු ඕනෑම කණ්ඩායමක් සමඟ අන්තර්ක්‍රියා ඇත. එබැවින්, SREs ප්‍රධාන වශයෙන් අවශ්ය වන්නේ ඔවුන් DevOps ක්රියාත්මක කිරීමට උත්සාහ කරන විට, නමුත් ඒ සමඟම, සංවර්ධකයින් මත ඇති බර ඉතා විශාල වේ. එනම්, දැන් ඔවුන් ද Ops සඳහා වගකිව යුතුය යන කාරණය සමඟ සංවර්ධන කණ්ඩායමට තවදුරටත් කටයුතු කළ නොහැක. ඒ වගේම වෙනම කාර්යභාරයක් තියෙනවා. මෙම කාර්යභාරය අයවැය තුළ සැලසුම් කර ඇත. සමහර විට මෙම භූමිකාව කණ්ඩායමේ ප්‍රමාණයෙන් දක්වා ඇත, වෙනම පුද්ගලයෙකු පෙනී සිටියි, සමහර විට එක් සංවර්ධකයෙකු එය බවට පත්වේ. කණ්ඩායම තුළ පළමු SRE පෙනී සිටින්නේ එලෙස ය.
SRE මගින් බලපෑමට ලක්වන පද්ධතියේ සංකීර්ණත්වය, මෙහෙයුමේ විශ්වසනීයත්වයට බලපාන සංකීර්ණත්වය, අවශ්ය හා අහම්බෙන් සිදු වේ. අවශ්ය සංකීර්ණත්වය යනු නව නිෂ්පාදන විශේෂාංග මගින් අවශ්ය ප්‍රමාණයට නිෂ්පාදනයේ සංකීර්ණත්වය වැඩි වීමයි. අහඹු සංකීර්ණත්වය යනු පද්ධතියේ සංකීර්ණත්වය වැඩි වන විට, නමුත් නිෂ්පාදන විශේෂාංගය සහ ව්යාපාරික අවශ්යතා මෙයට සෘජුවම බලපාන්නේ නැත. සංවර්ධකයා කොතැනක හෝ වැරැද්දක් කර ඇති බව පෙනේ, නැතහොත් ඇල්ගොරිතම ප්‍රශස්ත නොවේ, නැතහොත් විශේෂ අවශ්‍යතාවයකින් තොරව නිෂ්පාදනයේ සංකීර්ණත්වය වැඩි කරන අමතර අවශ්යතා කිහිපයක් හඳුන්වා දී ඇත. හොඳ SRE සෑම විටම මෙම තත්ත්වය කපා හැරිය යුතුය. එනම්, අහඹු ලෙස එකතු කිරීම නිසා අපහසුතා වැඩි වන ඕනෑම කැපවීමක්, ඕනෑම යෙදවීමක්, ඕනෑම පුල් ඉල්ලීමක් අවහිර කළ යුතුය.
ප්‍රශ්නය වන්නේ කණ්ඩායමට ඉංජිනේරුවෙකු, විශාල දැනුමක් ඇති පද්ධති පරිපාලකයෙකු බඳවා නොගන්නේ මන්ද යන්නයි. ඉංජිනේරුවෙකුගේ භූමිකාවේ සංවර්ධකයෙකු, අපට පවසන පරිදි, හොඳම කාර්ය මණ්ඩල විසඳුම නොවේ. ඉංජිනේරුවෙකුගේ භූමිකාවේ සංවර්ධකයෙකු සැමවිටම හොඳම කාර්ය මණ්ඩල විසඳුම නොවේ, නමුත් මෙහි කාරණය නම් Ops හි නියැලී සිටින සංවර්ධකයෙකුට ස්වයංක්රීයකරණය සඳහා තව ටිකක් ආශාවක් තිබීම, ක්රියාත්මක කිරීම සඳහා තව ටිකක් දැනුමක් සහ කුසලතා කට්ටලයක් තිබීමයි. මෙම ස්වයංක්රීයකරණය. ඒ අනුව, අපි යම් නිශ්චිත මෙහෙයුම් සඳහා කාලය පමණක් නොව, දින චර්යාව පමණක් නොව, MTTR (ප්‍රතිසාධනය සඳහා මධ්‍යන්‍ය වේලාව, ප්‍රතිසාධන කාලය) වැනි වැදගත් ව්යාපාරික පරාමිතීන් ද අඩු කරමු. මේ අනුව, අපි මේ ගැන ටිකක් පසුව කතා කරමු, අපි සංවිධානය සඳහා මුදල් ඉතිරි කරමු.
දැන් අපි SRE හි ක්‍රියාකාරිත්වය සඳහා වන නිර්ණායක ගැන කතා කරමු. සහ පළමුවෙන්ම විශ්වසනීයත්වය ගැන. කුඩා සමාගම්, ආරම්භක, බොහෝ විට සිදු වන්නේ සේවාව හොඳින් ලියා ඇත්නම්, නිෂ්පාදිතය හොඳින් හා නිවැරදිව ලියා ඇත්නම්, එය ක්රියා කරයි, එය කැඩී නොයන බව මිනිසුන් උපකල්පනය කරයි. එච්චරයි, අපි හොඳ කේතයක් ලියනවා, කඩන්න දෙයක් නැහැ. කේතය ඉතා සරලයි, කැඩීමට කිසිවක් නැත. මේවා අපට පරීක්ෂණ අවශ්ය නැතැයි කියන අය ගැනම ය, මන්ද, බලන්න, මේවා VPI ක්‍රම තුනයි, ඇයි මෙතන කඩන්නේ.
මේ සියල්ල වැරදියි, ඇත්ත වශයෙන්ම. තවද මෙම පුද්ගලයින් බොහෝ විට ප්රායෝගිකව එවැනි කේතයකින් දෂ්ට කරනු ලැබේ, මන්ද දේවල් කැඩී යයි. සමහර විට අනපේක්ෂිත ආකාරයෙන් දේවල් කැඩී යයි. සමහර වෙලාවට මිනිස්සු එපා කියනවා කවදාවත් එහෙම වෙන්නේ නැහැ කියලා. ඒවගේම ඒක හැම තිස්සෙම වෙනවා. එය ප්රමාණවත් තරම් බොහෝ විට සිදු වේ. 100% ලබා ගැනීම සඳහා කිසිවෙක් උත්සාහ නොකරන්නේ එබැවිනි, මන්ද 100% ලබා ගැනීම කිසි විටෙකත් සිදු නොවේ. මෙය සම්මතයයි. එබැවින්, අපි සේවාවක් ලබා ගැනීමේ හැකියාව ගැන කතා කරන විට, අපි සෑම විටම නවය ගැන කතා කරමු. 2 නවය, 3 නවය, 4 නවය, 5 නවය. අපි මෙය අක්‍රීය කාලය බවට පරිවර්තනය කරන්නේ නම්, උදාහරණයක් ලෙස, නවය 5, එවිට මෙය වසරකට මිනිත්තු 5 කට වඩා ටිකක් වැඩි වේ, නවය 2 යනු අක්‍රීය කාලය දින 3,5 කි.
නමුත් යම් අවස්ථාවක දී POI හි අඩුවීමක්, ආයෝජන මත ප්රතිලාභයක් ඇති බව පැහැදිලිය. නවය දෙකේ සිට නවය තුන දක්වා යනවා කියන්නේ දින 3කට වඩා අඩු කාලයකි. නවය හතරේ සිට පහ දක්වා යාමෙන් වසරකට විනාඩි 47කින් අක්‍රීය කාලය අඩු වේ. ව්‍යාපාර සඳහා එය තීරණාත්මක නොවිය හැකි බව පෙනේ. සහ පොදුවේ, අවශ්ය විශ්වසනීයත්වය තාක්ෂණික ප්රශ්නයක් නොවේ, මුලින්ම, එය ව්යාපාරික ප්රශ්නයක්, එය නිෂ්පාදන ප්රශ්නයක්. නිෂ්පාදනයේ භාවිතා කරන්නන් සඳහා කුමන මට්ටමේ අක්‍රීය කාලය පිළිගත හැකිද, ඔවුන් අපේක්ෂා කරන්නේ කුමක්ද, ඔවුන් කොපමණ මුදලක් ගෙවයි, උදාහරණයක් ලෙස, ඔවුන්ට කොපමණ මුදලක් අහිමි වේ, පද්ධතියට කොපමණ මුදලක් අහිමි වේද.
මෙහිදී වැදගත් ප්රශ්නයක් වන්නේ ඉතිරි සංරචකවල විශ්වසනීයත්වය කුමක්ද යන්නයි. මක්නිසාද යත් 4 සහ 5 නවය අතර වෙනස විශ්වසනීයත්වය 2 නවයක් සහිත ස්මාර්ට් ජංගම දුරකතනයේ නොපෙනේ. දළ වශයෙන් කිවහොත්, වසරකට 10 වතාවක් ඔබේ සේවාවේ ස්මාර්ට් ජංගම දුරකතනයේ යමක් කැඩී ගියහොත්, බොහෝ විට 8 ගුණයක් බිඳවැටීම OS පැත්තෙන් සිදු විය. පරිශීලකයා මේ සඳහා භාවිතා කර ඇති අතර, වසරකට තවත් වරක් අවධානය යොමු නොකරයි. විශ්වසනීයත්වය වැඩි කිරීම සහ ලාභය වැඩි කිරීම සඳහා මිල සහසම්බන්ධ කිරීම අවශ්ය වේ.
SRE හි පොතේ පමණක් 4 නවයේ සිට නවය 3 දක්වා වැඩි කිරීම සඳහා හොඳ උදාහරණයක් තිබේ. ලබා ගත හැකි වැඩිවීම 0,1% ට වඩා ටිකක් අඩු බව පෙනී යයි. තවද සේවාවේ ආදායම වසරකට ඩොලර් මිලියන 1 ක් නම්, ආදායමේ වැඩිවීම ඩොලර් 900 කි. දැරිය හැකි මිල නවයකින් වැඩි කිරීමට වසරකට ඩොලර් 900කට වඩා අඩු මුදලක් වැය වන්නේ නම්, වැඩිවීම මූල්‍යමය අර්ථවත් කරයි. එය වසරකට ඩොලර් 900 කට වඩා වැඩි මුදලක් වැය කරන්නේ නම්, එය තවදුරටත් අර්ථවත් නොවේ, මන්ද ආදායම වැඩිවීම සරලව ශ්රම පිරිවැය, සම්පත් පිරිවැය සඳහා වන්දි ලබා නොදේ. ඒ වගේම නවය 3ක් අපට ප්රමාණවත් වේවි.
මෙය ඇත්ත වශයෙන්ම සියලු ඉල්ලීම් සමාන වන සරල උදාහරණයකි. නවය 3 සිට නවය 4 දක්වා යාම ප්රමාණවත් වේ, නමුත් ඒ සමඟම, උදාහරණයක් ලෙස, නවය 2 සිට 3 දක්වා, මෙය දැනටමත් ඩොලර් 9 දහසක් ඉතිරි කිරීමකි, එය මූල්‍යමය අර්ථයක් ඇති කළ හැකිය. ස්වාභාවිකවම, යථාර්ථයේ දී, ලියාපදිංචි ඉල්ලීම අසාර්ථක වීම පිටුව පෙන්වීමට අසමත් වීම වඩා නරක ය, ඉල්ලීම් විවිධ බර ඇත. ඔවුන්ට ව්යාපාරික දෘෂ්ටි කෝණයකින් සම්පූර්ණයෙන්ම වෙනස් නිර්ණායකයක් තිබිය හැකිය, නමුත් කෙසේ වෙතත්, රීතියක් ලෙස, අපි යම් නිශ්චිත සේවාවන් ගැන කතා නොකරන්නේ නම්, මෙය තරමක් විශ්වාසදායක ආසන්න අගයකි.
සේවාව සඳහා වාස්තු විද්‍යාත්මක විසඳුමක් තෝරාගැනීමේදී SRE සම්බන්ධීකාරකයන්ගෙන් එකක් දැයි අපට ප්රශ්නයක් ලැබුණි. පවතින යටිතල ව්‍යුහයට ඒකාබද්ධ වීම සම්බන්ධයෙන් එහි ස්ථාවරත්වයේ කිසිදු හානියක් සිදු නොවන පරිදි කියමු. ඔව්, SREs, අදින්න ඉල්ලීම්, කැපවීම්, නිකුත් කිරීම් වාස්තු විද්‍යාවට බලපාන ආකාරයටම, නව සේවා හඳුන්වාදීම, ක්ෂුද්‍ර සේවා, නව විසඳුම් ක්රියාත්මක කිරීම. ඇයි මම කලින් කිව්වේ පළපුරුද්ද ඕනේ, සුදුසුකම් ඕනේ කියලා. ඇත්ත වශයෙන්ම, SRE යනු ඕනෑම වාස්තුවිද්‍යාත්මක සහ මෘදුකාංග විසඳුමක අවහිර කරන හඬකි. ඒ අනුව, SRE ඉංජිනේරුවෙකු ලෙස, පළමුව, අවබෝධ කර ගැනීම පමණක් නොව, සමහර නිශ්චිත තීරණ විශ්වසනීයත්වයට, ස්ථාවරත්වයට බලපාන්නේ කෙසේද යන්න තේරුම් ගත යුතු අතර, මෙය ව්යාපාරික අවශ්යතා හා සම්බන්ධ වන ආකාරය සහ එය කුමන දෘෂ්ටි කෝණයකින් පිළිගත හැකිද යන්න තේරුම් ගත යුතුය. නොවන.
එමනිසා, දැන් අපට SRE හි SLA (සේවා මට්ටමේ ගිවිසුම) ලෙස සම්ප්‍රදායිකව අර්ථ දක්වා ඇති විශ්වසනීයත්ව නිර්ණායක ගැන කතා කළ හැකිය. බොහෝ දුරට හුරුපුරුදු යෙදුමකි. SLI (සේවා මට්ටමේ දර්ශකය). SLO (සේවා මට්ටමේ අරමුණ). සේවා මට්ටමේ ගිවිසුම සමහර විට සංකේතාත්මක පදයක් විය හැකිය, විශේෂයෙන් ඔබ ජාල සමඟ, සපයන්නන් සමඟ, සත්කාරකත්වය සමඟ වැඩ කර ඇත්නම්. මෙය ඔබගේ සම්පූර්ණ සේවාවේ කාර්ය සාධනය, දඬුවම්, දෝෂ සඳහා සමහර දඬුවම්, මිනුම්, නිර්ණායක විස්තර කරන පොදු ගිවිසුමකි. සහ SLI යනු ලබා ගත හැකි මෙට්‍රික් එකයි. එනම්, SLI කුමක් විය හැකිද: සේවාවෙන් ප්රතිචාර දැක්වීමේ කාලය, ප්රතිශතයක් ලෙස දෝෂ සංඛ්යාව. එය යම් ආකාරයක ගොනු සත්කාරකයක් නම් එය කලාප පළලක් විය හැකිය. හඳුනාගැනීමේ ඇල්ගොරිතම සම්බන්ධයෙන් ගත් කල, දර්ශකය, උදාහරණයක් ලෙස, පිළිතුරේ නිවැරදි බව පවා විය හැකිය. SLO (සේවා මට්ටමේ අරමුණ) යනු, පිළිවෙලින්, SLI දර්ශකය, එහි අගය සහ කාලසීමාවෙහි එකතුවකි.
අපි හිතමු SLA එක මෙහෙම වෙන්න පුළුවන් කියලා. මෙම සේවාව වසර පුරා 99,95% ක් ලබා ගත හැකිය. නැතහොත් කාර්තුවකට පැය 99ක් ඇතුළත තීරණාත්මක ආධාරක ටිකට්පත් 3ක් වසා දමනු ඇත. නැතහොත් සෑම මසකම තත්පර 85ක් ඇතුළත ඉල්ලීම්වලින් 1,5%කට පිළිතුරු ලැබෙනු ඇත. එනම්, වැරදි සහ අසාර්ථක වීම සාමාන්ය දෙයක් බව අපි ක්‍රමයෙන් තේරුම් ගනිමු. මෙය පිළිගත හැකි තත්වයක්, අපි එය සැලසුම් කරමින් සිටිමු, අපි එය යම් දුරකට පවා ගණන් කරමින් සිටිමු. එනම්, SRE විසින් වැරදි සිදු කළ හැකි පද්ධති ගොඩනඟයි, ඒවා සාමාන්යයෙන් දෝෂ වලට ප්රතිචාර දැක්විය යුතුය, ඒවා සැලකිල්ලට ගත යුතුය. හැකි සෑම විටම, පරිශීලකයා ඒවා නොදකින හෝ දැනුම් දෙන ආකාරයෙන් ඔවුන් දෝෂ හැසිරවිය යුතුය, නමුත් යම් ආකාරයක විසඳුමක් තිබේ, එයට ස්තූතිවන්ත වන්නට සියල්ල සම්පූර්ණයෙන්ම පහත වැටෙන්නේ නැත.
උදාහරණයක් ලෙස, ඔබ යූ ටියුබ් වෙත වීඩියෝවක් උඩුගත කරන්නේ නම් සහ යූ ටියුබ් එය වහාම පරිවර්තනය කළ නොහැකි නම්, වීඩියෝව විශාල නම්, ආකෘතිය ප්‍රශස්ත නොවේ නම්, ඉල්ලීම ස්වාභාවිකවම කල් ඉකුත්වීමකින් අසාර්ථක නොවනු ඇත, යූ ටියුබ් 502 දෝෂයක් ලබා නොදේ. , YouTube කියනු ඇත: "අපි සියල්ල නිර්මාණය කර ඇත, ඔබගේ වීඩියෝව සැකසෙමින් පවතී. විනාඩි 10කින් විතර ලෑස්ති වෙයි." ඔබ මෙය කවදා හෝ කර ඇත්නම්, උදාහරණයක් ලෙස, ඉදිරිපස සංවර්ධනයේ සිට හුරුපුරුදු වන අලංකාර පිරිහීමේ මූලධර්මය මෙයයි.
අපි කතා කරන මීළඟ නියමයන්, විශ්වසනීයත්වය සමඟ, දෝෂ සහිතව, අපේක්ෂාවන් සමඟ වැඩ කිරීම සඳහා ඉතා වැදගත් වේ, MTBF සහ MTTR වේ. MTBF යනු අසාර්ථකත්වයන් අතර මධ්‍යන්‍ය කාලයයි. MTTR ප්‍රකෘතිමත් වීමට මධ්‍යන්‍ය කාලය, ප්‍රතිසාධනය සඳහා සාමාන්ය කාලය. එනම්, දෝෂය සොයාගත් මොහොතේ සිට, එම දෝෂය දර්ශනය වූ මොහොතේ සිට සේවාව සම්පූර්ණ සාමාන්ය ක්රියාකාරීත්වයට පත් කරන මොහොත දක්වා කොපමණ කාලයක් ගත වී තිබේද යන්නයි. MTBF ප්‍රධාන වශයෙන් ස්ථාවර වන්නේ කේතයේ ගුණාත්මකභාවය මත වැඩ කිරීමෙනි. එනම්, SRE වලට "නැහැ" කිව හැකි බව ය. ඒවගේම SRE "නෑ" කිව්වම ඒක කියන්නේ එයා හානිකර නිසාවත්, නරක නිසාවත් නෙවෙයි, එහෙම උනොත් හැමෝම දුක් විදින නිසා කියලා මුළු කණ්ඩායම ගැනම අවබෝධයක් අවශ්‍යයි.
නැවතත්, මම නිතර නිතර සඳහන් කරන පොතේ පවා ලිපි රාශියක්, ක්‍රම රාශියක්, ක්‍රම රාශියක් ඇත, අනෙකුත් සංවර්ධකයින් SRE වලට වෛර කිරීමට පටන් නොගන්නා බවට වග බලා ගන්නේ කෙසේද. අනෙක් අතට MTTR යනු ඔබේ SLOs (සේවා මට්ටමේ අරමුණ) මත වැඩ කිරීමයි. තවද එය බොහෝ විට ස්වයංක්රීයකරණය වේ. මක්නිසාද යත්, උදාහරණයක් ලෙස, අපගේ SLO යනු කාර්තුවකට නවය 4 ක අතිකාලයකි. මෙයින් අදහස් කරන්නේ මාස 3 කින් අපට විනාඩි 13 ක් අක්‍රීය වීමට ඉඩ දිය හැකි බවයි. MTTR මිනිත්තු 13 කට වඩා වැඩි නොවිය හැකි බව පෙනේ. අපි අවම වශයෙන් මිනිත්තු 13 කින් අක්‍රිය වේලාව 1කට ප්රතිචාර දක්වන්නේ නම්, මෙයින් අදහස් කරන්නේ අපි කාර්තුව සඳහා සම්පූර්ණ අයවැය දැනටමත් අවසන් කර ඇති බවයි. අපි SLO කඩනවා. බිඳවැටීමකට ප්‍රතික්‍රියා කර එය නිවැරදි කිරීමට මිනිත්තු 13ක් යනු යන්ත්‍රයකට විශාල ප්‍රමාණයකි, නමුත් මිනිසෙකුට ඉතා කෙටි වේ. මක්නිසාද යත් පුද්ගලයෙකුට අනතුරු ඇඟවීමක් ලැබෙන තුරු, ඔහු ප්‍රතික්‍රියා කරන තුරු, ඔහු දෝෂය තේරුම් ගන්නා තුරු, එය දැනටමත් මිනිත්තු කිහිපයක් ගත වේ. පුද්ගලයෙකු එය නිවැරදි කරන්නේ කෙසේද, හරියටම නිවැරදි කළ යුත්තේ කුමක්ද, කුමක් කළ යුතුද යන්න තේරුම් ගන්නා තුරු, මෙය තවත් මිනිත්තු කිහිපයක් වේ. ඇත්ත වශයෙන්ම, ඔබට සේවාදායකය නැවත ආරම්භ කිරීමට අවශ්ය වුවද, එය පෙනෙන පරිදි හෝ නව නෝඩයක් ඔසවන්න, එවිට අතින් MTTR දැනටමත් විනාඩි 7-8 ක් පමණ වේ. ක්‍රියාවලිය ස්වයංක්‍රීය කරන විට, MTTR බොහෝ විට තත්පරයකට, සමහර විට මිලි තත්පරයට ළඟා වේ. ගූගල් සාමාන්යයෙන් මිලි තත්පර ගැන කතා කරයි, නමුත් ඇත්ත වශයෙන්ම, සෑම දෙයක්ම එතරම් හොඳ නැත.
ඉතා මැනවින්, SRE එහි කාර්යය සම්පූර්ණයෙන්ම පාහේ ස්වයංක්‍රීය කළ යුතුය, මන්ද මෙය MTTR, එහි ප්‍රමිතික, සමස්ත සේවාවේ SLO සහ ඒ අනුව ව්යාපාරික ලාභයට සෘජුවම බලපාන බැවිනි. කාලය ඉක්මවා ගියහොත්, SRE වරදක් තිබේදැයි අපෙන් අසනු ලැබේ. වාසනාවකට මෙන්, කිසිවෙකුට දොස් පැවරිය නොහැක. මෙය balmeless postmortem නමින් හැඳින්වෙන වෙනම සංස්කෘතියකි, එය අද අපි කතා නොකරමු, නමුත් අපි එය Slurm මත විශ්ලේෂණය කරමු. මෙය බොහෝ දේ කතා කළ හැකි ඉතා රසවත් මාතෘකාවකි. දළ වශයෙන්, කාර්තුවකට නියමිත කාලය ඉක්මවා ගියහොත්, සෑම කෙනෙකුටම ටිකක් දොස් පැවරිය යුතුය, එනම් සෑම කෙනෙකුටම දොස් කීම ඵලදායි නොවේ, ඒ වෙනුවට, සමහර විට කිසිවෙකුට දොස් නොකියා, තත්වය නිවැරදි කර අපට ඇති දේ සමඟ වැඩ කරමු. මගේ අත්දැකීම් අනුව, මෙම ප්‍රවේශය බොහෝ කණ්ඩායම් වලට, විශේෂයෙන් රුසියාවේ තරමක් ආගන්තුක ය, නමුත් එය අර්ථවත් වන අතර ඉතා හොඳින් ක්රියා කරයි. එමනිසා, මෙම මාතෘකාව පිළිබඳව ඔබට කියවිය හැකි ලිපිය සහ සාහිත්යය අවසානයේ මම නිර්දේශ කරමි. නැත්තම් Slurm SRE එකට එන්න.
මට පැහැදිලි කරන්න දෙන්න. කාර්තුවකට SLO කාලය ඉක්මවා ගියහොත්, අක්‍රිය කාලය මිනිත්තු 13 ක් නොව 15 ක් නම්, මේ සඳහා දොස් පැවරිය හැක්කේ කාටද? ඇත්ත වශයෙන්ම, SRE දොස් පැවරිය හැකිය, මන්ද ඔහු පැහැදිලිවම යම් ආකාරයක නරක කැපවීමක් හෝ යෙදවීමක් සිදු කර ඇත. දත්ත මධ්‍යස්ථානයේ පරිපාලකයා මේ සඳහා දොස් පැවරිය හැකිය, මන්ද ඔහු යම් ආකාරයක සැලසුම් නොකළ නඩත්තුවක් සිදු කර ඇති බැවිනි. මේකට ඩේටා සෙන්ටර් එකේ ඇඩ්මින්ට දොස් කියනවා නම් ඔප්ස් එකෙන් එන එකා තමයි මේකට බැන්නේ, ඌ SLO එක සම්බන්ධීකරණය කරනකොට මේන්ටේන් එක ගණන් ගත්තේ නැති එක. ඩේටා සෙන්ටර් කොන්ත්‍රාත්තුව අත්සන් කළ කළමනාකරු, තාක්ෂණික අධ්‍යක්ෂ හෝ කවුරුන් හෝ දත්ත මධ්‍යස්ථානයේ SLA අවශ්ය අක්‍රීය කාලය සඳහා නිර්මාණය කර නොමැති බව අවධානය යොමු නොකළ අයෙකු මෙයට දොස් පැවරිය යුතුය. ඒ අනුව, මෙම තත්වය තුළ ටිකෙන් ටික සියල්ලටම දොස් පැවරිය යුතුය. ඒවගේම මේ තත්ත්වය තුළ කාටවත් වරද පැටවීමෙන් තේරුමක් නැති බවයි. නමුත් ඇත්ත වශයෙන්ම එය නිවැරදි කළ යුතුය. ඒකයි පශ්චාත් මරණ පරීක්ෂණ තියෙන්නේ. ඔබ කියවා ඇත්නම්, උදාහරණයක් ලෙස, GitHub පශ්චාත් මරණ පරීක්ෂණ, සහ මෙය සෑම අවස්ථාවකම ඉතා සිත්ගන්නා සුළු, කුඩා හා අනපේක්ෂිත කථාවක් නම්, මෙම විශේෂිත පුද්ගලයාට දොස් පැවරිය යුතු බව කිසිවෙකු කිසි විටෙකත් නොකියන බව ඔබට ප්‍රතිස්ථාපනය කළ හැකිය. දෝෂාරෝපණය සෑම විටම නිශ්චිත අසම්පූර්ණ ක්රියාවලීන් මත තබා ඇත.
අපි ඊළඟ ප්‍රශ්නයට යමු. ස්වයංක්රීයකරණය. මම වෙනත් සන්දර්භයන් තුළ ස්වයංක්රීයකරණය ගැන කතා කරන විට, මම බොහෝ විට ඔබ සුරකින කාලයට වඩා ස්වයංක්‍රීය කිරීමට වැඩි කාලයක් නොගෙන කාර්යයක් ස්වයංක්‍රීය කිරීම සඳහා ඔබට කොපමණ කාලයක් වැඩ කළ හැකිදැයි පවසන වගුවක් වෙත යොමු කරමි. හිරවීමක් තියෙනවා. අල්ලා ගැනීම නම්, SREs කාර්යයක් ස්වයංක්‍රීය කරන විට, ඔවුන් කාලය ඉතිරි කරනවා පමණක් නොව, මුදල් ඉතිරි කරයි, මන්ද ස්වයංක්රීයකරණය MTTR වලට කෙලින්ම බලපායි. ඔවුන් ඉතිරි කරන්නේ, එසේ කතා කිරීමට, සේවකයින්ගේ සහ සංවර්ධකයින්ගේ චිත්ත ධෛර්යය, එය අවසන් කළ හැකි සම්පතක් ද වේ. ඔවුන් දින චර්යාව අඩු කරයි. තවද මේ සියල්ල වැඩ කෙරෙහි ධනාත්මක බලපෑමක් ඇති කරන අතර එහි ප්‍රති result ලයක් වශයෙන් ව්යාපාරයට, කාල පිරිවැය අනුව ස්වයංක්රීයකරණය අර්ථවත් නොවන බව පෙනේ.
ඇත්ත වශයෙන්ම, එය සෑම විටම පාහේ ඇති අතර, SRE හි භූමිකාව තුළ යමක් ස්වයංක්රීයව නොකළ යුතු අවස්ථා ඉතා සුළු වේ. මීළඟට අපි කතා කරමු දෝෂ අයවැය, දෝෂ සඳහා අයවැය ලෙස හඳුන්වන දේ. ඇත්ත වශයෙන්ම, ඔබ විසින්ම සකසා ඇති SLO වලට වඩා සෑම දෙයක්ම ඔබට වඩා හොඳ නම්, මෙයද එතරම් හොඳ නොවන බව පෙනේ. මෙය තරමක් නරක ය, මන්ද SLO ක්රියා කරන්නේ පහළ ලෙස පමණක් නොව, ආසන්න ඉහළ සීමාවක් ලෙස ය. ඔබ විසින්ම 99% ලබා ගත හැකි SLO එකක් සකසා ගත් විට සහ ඇත්ත වශයෙන්ම ඔබට 99,99% ඇති විට, ව්යාපාරයට කිසිසේත් හානියක් නොවන අත්හදා බැලීම් සඳහා ඔබට යම් ඉඩක් ඇති බව පෙනේ, මන්ද ඔබ විසින්ම මෙය තීරණය කර ඇති අතර ඔබ මෙම අවකාශය භාවිතා නොවේ. ඔබට වැරදි සඳහා අයවැයක් ඇත, එය ඔබගේ නඩුවේ භාවිතා නොවේ.
අපි ඒකට මොකද කරන්නේ. අපි එය වචනාර්ථයෙන් සෑම දෙයක් සඳහාම භාවිතා කරමු. නිෂ්පාදන තත්ත්වයන් තුළ පරීක්ෂා කිරීම සඳහා, කාර්ය සාධනයට බලපෑ හැකි නව විශේෂාංග එළිදැක්වීම සඳහා, නිකුත් කිරීම් සඳහා, නඩත්තුව සඳහා, සැලසුම්ගත අක්‍රීය කාලය සඳහා. ප්‍රතිලෝම රීතිය ද අදාළ වේ: අයවැය අවසන් වී ඇත්නම්, අපට අලුත් කිසිවක් නිකුත් කළ නොහැක, එසේ නොවුවහොත් අපි SLO ඉක්මවා යනු ඇත. අයවැය දැනටමත් අවසන් වී ඇත, එය ක්රියාකාරීත්වයට අහිතකර ලෙස බලපාන්නේ නම් අපි යමක් නිකුත් කර ඇත, එනම්, මෙය සෘජුවම SLO වැඩි කරන යම් ආකාරයක නිවැරදි කිරීමක් නොවේ නම්, අපි අයවැයෙන් ඔබ්බට යමින් සිටිමු, මෙය නරක තත්වයකි , එය විශ්ලේෂණය කිරීම, පශ්චාත් මරණ පරීක්ෂණය සහ සමහර ක්‍රියාවලි නිවැරදි කිරීම් අවශ්ය වේ.
එනම්, සේවාවම හොඳින් ක්රියා නොකරන්නේ නම් සහ SLO වියදම් කර අයවැය වියදම් කරන්නේ අත්හදා බැලීම් සඳහා නොව, සමහර නිකුතු සඳහා නොව, තනිවම නම්, සිත්ගන්නාසුලු විශේෂාංග වෙනුවට, රසවත් විසඳුම් කිහිපයක් වෙනුවට, රසවත් නිකුතු වෙනුවට. ඕනෑම නිර්මාණාත්මක කාර්යයක් වෙනුවට, අයවැය නැවත පිළිවෙලට ගැනීමට හෝ SLO සංස්කරණය කිරීමට ඔබට මෝඩ නිවැරදි කිරීම් සමඟ කටයුතු කිරීමට සිදුවනු ඇත, මෙයද නිතර සිදු නොවිය යුතු ක්‍රියාවලියකි.
එබැවින්, දෝෂ සඳහා වැඩි අයවැයක් ඇති තත්වයක් තුළ, සෑම කෙනෙකුම උනන්දු වන බව පෙනී යයි: SRE සහ සංවර්ධකයින් යන දෙකම. සංවර්ධකයින් සඳහා, දෝෂ සඳහා විශාල අයවැයක් යනු ඔබට නිකුත් කිරීම්, පරීක්ෂණ, අත්හදා බැලීම් සමඟ කටයුතු කළ හැකි බවයි. SRE සඳහා, දෝෂ සඳහා අයවැයක් සහ එම අයවැය ඇතුළත් කිරීම යනු ඔවුන් සෘජුවම ඔවුන්ගේ කාර්යය හොඳින් ඉටු කරන බවයි. තවද මෙය යම් ආකාරයක ඒකාබද්ධ කාර්යයක අභිප්රේරණයට බලපායි. ඔබ සංවර්ධකයින් ලෙස ඔබේ SRE වලට ඇහුම්කන් දෙන්නේ නම්, ඔබට හොඳ වැඩ සඳහා වැඩි ඉඩක් සහ දිනචරියාව බෙහෙවින් අඩු වනු ඇත.
නිෂ්පාදනයේ අත්හදා බැලීම් විශාල කණ්ඩායම් තුළ SRE හි ඉතා වැදගත් හා පාහේ අනිවාර්ය අංගයක් බව පෙනේ. තවද එය සාමාන්යයෙන් හඳුන්වන්නේ chaos Engineering ලෙසයි, එය Chaos Monkey නම් උපයෝගීතාවයක් නිකුත් කළ Netflix හි කණ්ඩායමෙන් පැමිණේ.
Chaos Monkey CI/CD නල මාර්ගයට සම්බන්ධ වන අතර නිෂ්පාදනයේදී අහඹු ලෙස සේවාදායකය බිඳ දමයි. නැවතත්, SRE ව්‍යුහය තුළ, අපි කතා කරන්නේ පහත වැටුණු සේවාදායකයක් තමා තුළම නරක නොවන බවයි, එය අපේක්ෂා කෙරේ. එය අයවැය තුළ තිබේ නම්, එය පිළිගත හැකි අතර ව්යාපාරයට හානියක් නොවේ. ඇත්ත වශයෙන්ම, Netflix සතුව ප්රමාණවත් අනවශ්‍ය සේවාදායකයන්, ප්රමාණවත් අනුකරණයක් ඇත, එවිට මේ සියල්ල නිවැරදි කළ හැකි අතර, සමස්තයක් ලෙස පරිශීලකයා නොදැනෙන පරිදි, ඊටත් වඩා කිසිවෙකු කිසිදු අයවැයක් සඳහා එක් සේවාදායකයක් ඉතිරි නොකරයි.
Netflix සතුව යම් කාලයක් සඳහා එවැනි උපයෝගිතා කට්ටලයක් තිබී ඇති අතර, ඉන් එකක් වන Chaos Gorilla, Amazon හි පවතින කලාපයක් සම්පූර්ණයෙන්ම වසා දමයි. එවැනි දේවල් පළමුව, සැඟවුණු පරායත්තතා හෙළි කිරීමට උපකාරී වේ, කුමක් බලපාන්නේද, කුමක් මත රඳා පවතීද යන්න සම්පූර්ණයෙන්ම පැහැදිලි නැති විට. තවද මෙය, ඔබ ක්ෂුද්‍ර සේවාවක් සමඟ වැඩ කරන්නේ නම් සහ ලේඛන සම්පුර්ණයෙන්ම පරිපූර්ණ නොවේ නම්, මෙය ඔබට හුරුපුරුදු විය හැකිය. නැවතත්, ඔබට වේදිකාගත කිරීමේදී අල්ලා ගත නොහැකි කේතයේ දෝෂ අල්ලා ගැනීමට මෙය බොහෝ සෙයින් උපකාරී වේ, මන්ද ඕනෑම වේදිකාවක් හරියටම අනුකරණයක් නොවන නිසා, බර පරිමාණය වෙනස් වීම, පැටවීමේ රටාව වෙනස්, උපකරණ වේ එසේම, බොහෝ විට, වෙනත්. උපරිම බර ද අනපේක්ෂිත හා අනපේක්ෂිත විය හැකිය. නැවතත් අයවැයෙන් ඔබ්බට නොයන එවැනි පරීක්ෂණ, වේදිකාගත කිරීම, ස්වයංක්‍රීය පරීක්ෂණ, CI / CD නල මාර්ගය කිසි විටෙකත් හසු නොවන යටිතල ව්‍යුහයේ දෝෂ අල්ලා ගැනීමට ඉතා හොඳින් උපකාරී වේ. ඒවගේම ඔයාගේ බජට් එකට මේ ඔක්කොම ඇතුලත් වෙනකන්, ඔයාගේ සර්විස් එක එතනට බැහැල ගියාට කමක් නෑ, ඒක හරිම භයානකයි වගේ පෙනුනත්, සර්වර් එක බැහැල ගියා, කොච්චර නපුරු හීනයක්ද. නැත, එය සාමාන්ය දෙයක්, එය හොඳයි, එය දෝෂ අල්ලා ගැනීමට උපකාරී වේ. ඔබට අයවැයක් තිබේ නම්, ඔබට එය වියදම් කළ හැකිය.
ප්‍ර: මට නිර්දේශ කළ හැකි සාහිත්‍ය මොනවාද? අවසානයේ ලැයිස්තුගත කරන්න. සාහිත්යය ගොඩක් තියෙනවා, මම වාර්තා කිහිපයක් උපදෙස් දෙන්නම්. එය ක්රියා කරන්නේ කෙසේද, සහ SRE ඔවුන්ගේම මෘදුකාංග නිෂ්පාදනයක් නොමැතිව හෝ අවම සංවර්ධනයක් ඇති සමාගම්වල ක්රියා කරයි. උදාහරණයක් ලෙස, ප්‍රධාන ක්‍රියාකාරකම් මෘදුකාංගයක් නොවන ව්‍යවසායක. ප්‍රධාන ක්‍රියාකාරකම මෘදුකාංගයක් නොවන ව්‍යවසායක, SRE සෑම තැනකම මෙන් හරියටම ක්රියා කරයි, මක්නිසාද යත් ව්‍යවසායක ඔබ ද භාවිතා කළ යුතුය, සංවර්ධනය නොකළත්, මෘදුකාංග නිෂ්පාදන, ඔබ යාවත්කාලීන කළ යුතුය, ඔබ වෙනස් කළ යුතුය. යටිතල පහසුකම්, ඔබ වර්ධනය විය යුතුය, ඔබ පරිමාණය කළ යුතුය. තවද SREs මෙම ක්‍රියාවලීන්හි ඇති විය හැකි ගැටළු හඳුනා ගැනීමට සහ පුරෝකථනය කිරීමට සහ යම් වර්ධනයක් ආරම්භ වී ව්‍යාපාර අවශ්යතා වෙනස් වූ පසු ඒවා පාලනය කිරීමට උපකාරී වේ. මක්නිසාද යත් ඔබට අවම වශයෙන් සේවාදායකයන් කිහිපයක් තිබේ නම් සහ අවම වශයෙන් යම් වර්ධනයක් අපේක්ෂා කරන්නේ නම් SRE එකක් ලබා ගැනීම සඳහා මෘදුකාංග සංවර්ධනයට සම්බන්ධ වීම අත්‍යවශ්‍ය නොවන බැවිනි.
කුඩා ව්‍යාපෘති, කුඩා සංවිධාන සඳහා ද එය එසේම වේ, මන්ද විශාල සමාගම්වලට අත්හදා බැලීම් කිරීමට අයවැය සහ අවකාශය ඇති බැවිනි. නමුත් ඒ සමඟම, මෙම අත්හදා බැලීම්වල සියලුම පලතුරු ඕනෑම තැනක භාවිතා කළ හැකිය, එනම්, SRE, ඇත්ත වශයෙන්ම, ගූගල් හි, නෙට්ෆ්ලික්ස් හි, ඩ්‍රොප්බොක්ස් හි දර්ශනය විය. නමුත් ඒ සමගම, කුඩා සමාගම් සහ ආරම්භකයින් දැනටමත් ඝනීභවනය කරන ලද ද්රව්ය කියවිය හැකිය, පොත් කියවීම, වාර්තා නැරඹිය හැකිය. ඔවුන් ඒ ගැන නිතර නිතර අසන්නට පටන් ගනී, ඔවුන් නිශ්චිත උදාහරණ දෙස බලයි, එය කමක් නැත, එය ඇත්තෙන්ම ප්රයෝජනවත් විය හැකිය, අපට මෙයද අවශ්ය වේ, එය විශිෂ්ටයි.
එනම්, මෙම ක්රියාවලීන් ප්‍රමිතිගත කිරීමේ සියලුම ප්‍රධාන කාර්යයන් ඔබ වෙනුවෙන් දැනටමත් සිදු කර ඇත. ඔබේ සමාගම තුළ SRE හි කාර්යභාරය නිශ්චිතව තීරණය කිරීම සහ මෙම සියලු භාවිතයන් ඇත්ත වශයෙන්ම ක්රියාත්මක කිරීමට පටන් ගැනීම ඔබට ඉතිරිව ඇත, නැවතත්, දැනටමත් විස්තර කර ඇත. එනම්, කුඩා සමාගම් සඳහා ප්රයෝජනවත් මූලධර්ම වලින්, මෙය සැමවිටම SLA, SLI, SLO යන අර්ථ දැක්වීම වේ. ඔබ මෘදුකාංගයට සම්බන්ධ නොවන්නේ නම්, මේවා අභ්‍යන්තර SLA සහ අභ්‍යන්තර SLO, දෝෂ සඳහා අභ්‍යන්තර අයවැයක් වනු ඇත. මෙය සෑම විටම පාහේ කණ්ඩායම තුළ සහ ව්‍යාපාරය තුළ සිත්ගන්නාසුලු සාකච්ඡාවලට තුඩු දෙයි, මන්ද ඔබ යටිතල පහසුකම් සඳහා, යම් ආකාරයක පරමාදර්ශී ක්‍රියාවලි සංවිධානයක් සඳහා වියදම් කරන බව පෙනී යා හැකි බැවින්, පරමාදර්ශී නල මාර්ගය අවශ්ය ප්‍රමාණයට වඩා බෙහෙවින් වැඩි ය. තවද ඔබට තොරතුරු තාක්ෂණ අංශයේ ඇති මෙම නවයන් 4, ඔබට දැන් ඒවා අවශ්ය නොවේ. නමුත් ඒ සමඟම, ඔබට කාලය ගත කළ හැකිය, වැරදි සඳහා අයවැය වෙනත් දෙයකට වියදම් කළ හැකිය.
ඒ අනුව, ඕනෑම ප්‍රමාණයක සමාගමකට අධීක්ෂණය සහ අධීක්ෂණ සංවිධානය ප්රයෝජනවත් වේ. සහ පොදුවේ ගත් කල, වැරදි පිළිගත හැකි දෙයක්, අයවැයක් තිබේ නම්, අරමුණු තිබේ නම්, මෙම සිතීමේ ක්‍රමය, පුද්ගලයන් 3 දෙනෙකු සඳහා ආරම්භක සිට ආරම්භ වන ඕනෑම ප්‍රමාණයක සමාගමකට නැවත ප්රයෝජනවත් වේ.
කතා කිරීමට ඇති අවසාන තාක්ෂණික සූක්ෂ්මතාවය වන්නේ අධීක්ෂණයයි. මොකද අපි කතා කරන්නේ SLA, SLI, SLO ගැන නම්, අපි අයවැයට ගැලපෙනවාද, අපි අපේ අරමුණු වලට අනුකූලද, අවසාන SLA වලට බලපාන්නේ කෙසේද යන්න නිරීක්ෂණය නොකර අපට තේරුම් ගත නොහැක. අධීක්ෂණය මේ ආකාරයට සිදුවන බව මම බොහෝ වාරයක් දැක ඇත: යම් අගයක් ඇත, උදාහරණයක් ලෙස, සේවාදායකයට ඉල්ලීමක වේලාව, සාමාන්ය කාලය හෝ දත්ත සමුදායට ඇති ඉල්ලීම් ගණන. ඔහු ඉංජිනේරුවෙකු විසින් තීරණය කරන ලද සම්මතයක් ඇත. මෙට්‍රික් සම්මතයෙන් බැහැර වන්නේ නම්, ඊමේල් එකක් එයි. රීතියක් ලෙස, මේ සියල්ල නියත වශයෙන්ම නිෂ්ඵල ය, මන්ද එය එවැනි අනතුරු ඇඟවීම්, අධීක්‍ෂණයෙන් ලැබෙන පණිවිඩ විශාල ප්‍රමාණයකට මග පාදයි, පුද්ගලයෙකු, පළමුව, ඒවා සෑම විටම අර්ථ නිරූපණය කළ යුතු විට, එනම්, මෙට්‍රික් මාධ්‍යවල වටිනාකම තීරණය කළ යුතුය. යම් ක්‍රියාමාර්ගයක අවශ්‍යතාවය. දෙවනුව, මූලික වශයෙන් ඔහුගෙන් කිසිදු ක්‍රියාමාර්ගයක් අවශ්ය නොවන විට ඔහු මෙම සියලු ඇඟවීම් දැකීම නතර කරයි. එය හොඳ අධීක්ෂණ රීතියක් වන අතර SRE ක්රියාත්මක කරන විට පළමු රීතිය වන්නේ ක්‍රියාමාර්ගයක් අවශ්ය වූ විට පමණක් දැනුම් දීමයි.
සම්මත නඩුවේදී, සිදුවීම් මට්ටම් 3 ක් ඇත. ඇලර්ට් තියෙනවා, ටිකට් තියෙනවා, ලොග් තියෙනවා. ඇඟවීම් යනු ඔබ ක්ෂණික ක්‍රියාමාර්ග ගැනීමට අවශ්ය ඕනෑම දෙයකි. එනම්, සියල්ල කැඩී ඇත, ඔබ දැන් එය නිවැරදි කළ යුතුය. ප්‍රවේශපත්‍ර යනු ප්‍රමාද ක්රියාවක් අවශ්ය වේ. ඔව්, ඔබ යමක් කළ යුතුයි, ඔබ අතින් යමක් කළ යුතුයි, ස්වයංක්රීයකරණය අසාර්ථකයි, නමුත් ඊළඟ මිනිත්තු කිහිපය සඳහා ඔබට එය කිරීමට අවශ්ය නැත. ලඝු-සටහන් යනු ක්රියාවක් අවශ්ය නොවන ඕනෑම දෙයක් වන අතර, සාමාන්යයෙන්, දේවල් හොඳින් සිදුවුවහොත්, කිසිවෙක් ඒවා කිසිදා කියවන්නේ නැත. ඔබට ලඝු-සටහන් කියවීමට අවශ්ය වනුයේ, ආපසු හැරී බැලීමේදී, යම් කාලයක් තිස්සේ යමක් කැඩී ඇති බව පෙනී ගිය විට, අපි ඒ ගැන නොදැන සිටිමු. නැත්තම් පොඩ්ඩක් හොයල බලන්න ඕන. නමුත් සාමාන්යයෙන්, කිසිදු ක්රියාවක් අවශ්ය නොවන සෑම දෙයක්ම ලොග් වෙත යයි.
මේ සියල්ලේ අතුරු ප්‍රතිඵලයක් ලෙස, ක්‍රියාවන් සඳහා අවශ්ය සිදුවීම් මොනවාද යන්න නිර්වචනය කර මෙම ක්‍රියාවන් විය යුතු දේ හොඳින් විස්තර කර ඇත්නම්, මෙයින් අදහස් කරන්නේ ක්රියාව ස්වයංක්‍රීය විය හැකි බවයි. එනම්, සිදුවන්නේ කුමක්ද යන්නයි. අපි සීරුවෙන් යනවා. අපි ක්‍රියාවට යමු. අපි මෙම ක්රියාව පිළිබඳ විස්තරයට යන්නෙමු. ඊට පස්සේ අපි ස්වයංක්රීයකරණයට යනවා. එනම්, ඕනෑම ස්වයංක්‍රීයකරණයක් ආරම්භ වන්නේ සිදුවීමකට ප්රතිචාර දැක්වීමෙනි.
අධීක්‍ෂණයේ සිට අපි නිරීක්ෂණ හැකියාව නම් පදයකට යන්නෙමු. පසුගිය වසර කිහිපය තුළ මෙම වචනය වටා තරමක් උද්දීපනයක් ද ඇත. ඒවගේම සන්දර්භයෙන් පිටත එහි තේරුම කුමක්දැයි ස්වල්ප දෙනෙක් තේරුම් ගනී. නමුත් ප්‍රධාන කරුණ නම් නිරීක්ෂණය යනු පද්ධති විනිවිදභාවය සඳහා වන මිතිකයකි. යම් දෙයක් වැරදී ඇත්නම්, හරියටම වැරදී ඇත්තේ කුමක්ද සහ එම මොහොතේ පද්ධතියේ තත්වය කුමක්ද යන්න ඔබට කෙතරම් ඉක්මනින් තීරණය කළ හැකිය. කේතය අනුව: කුමන කාර්යය අසාර්ථකද, කුමන සේවාව අසාර්ථකද. උදාහරණයක් ලෙස, අභ්‍යන්තර විචල්‍යයන්, වින්‍යාසයේ තත්වය කුමක්ද. යටිතල පහසුකම් සම්බන්ධයෙන් ගත් කල, මෙම අසාර්ථකත්වය සිදුවූයේ කුමන ප්‍රදේශයේද, සහ ඔබ සතුව කිසියම් Kubernetes ස්ථාපනය කර ඇත්නම්, එම අසාර්ථකත්වය සිදුවූයේ කුමන පොඩ් එකේද, පොඩ් එකේ තත්වය කුමක්ද. ඒ අනුව, නිරීක්ෂණ හැකියාව MTTR සමඟ සෘජු සම්බන්ධයක් ඇත. සේවාවේ නිරීක්ෂණ හැකියාව වැඩි වන තරමට දෝෂය හඳුනා ගැනීම පහසු වේ, දෝෂය නිවැරදි කිරීම පහසු වේ, දෝෂය ස්වයංක්‍රීය කිරීම පහසු වන තරමට MTTR අඩු වේ.
නැවතත් කුඩා සමාගම් වෙත ගමන් කිරීම, කණ්ඩායම් ප්‍රමාණය සමඟ කටයුතු කරන්නේ කෙසේද සහ කුඩා කණ්ඩායමක් වෙනම SRE කුලියට ගැනීමට අවශ්ය දැයි දැන් පවා විමසීම ඉතා සාමාන්ය දෙයකි. මේ ගැන ටිකක් කලින් කතා කළා. ආරම්භක හෝ, උදාහරණයක් ලෙස, කණ්ඩායමක් සංවර්ධනය කිරීමේ පළමු අදියරේදී, මෙය කිසිසේත්ම අවශ්ය නොවේ, මන්ද SRE සංක්‍රාන්ති භූමිකාවක් බවට පත් කළ හැකි බැවිනි. අවම වශයෙන් යම් විවිධත්වයක් ඇති බැවින් මෙය කණ්ඩායම ටිකක් පුනර්ජීවනය කරනු ඇත. තවද, වර්ධනයත් සමඟ පොදුවේ, SRE හි වගකීම් ඉතා සැලකිය යුතු ලෙස වෙනස් වනු ඇති බවට එය මිනිසුන් සූදානම් කරනු ඇත. ඔබ පුද්ගලයෙකු කුලියට ගන්නේ නම්, ඇත්ත වශයෙන්ම, ඔහුට යම් අපේක්ෂාවන් ඇත. තවද මෙම අපේක්ෂාවන් කාලයත් සමඟ වෙනස් නොවනු ඇත, නමුත් අවශ්යතා බෙහෙවින් වෙනස් වනු ඇත. එබැවින්, SRE කුලියට ගන්නේ කෙසේද යන්න මුල් අවධියේදී තරමක් අපහසුය. ඔබේම වැඩීම වඩාත් පහසු වේ. නමුත් එය සිතා බැලීම වටී.
එකම ව්යතිරේකය, සමහර විට, ඉතා දැඩි සහ හොඳින් අර්ථ දක්වා ඇති වර්ධන අවශ්යතා ඇති විටය. එනම්, ආරම්භක අවස්ථාවක, මෙය ආයෝජකයින්ගෙන් යම් ආකාරයක පීඩනයක් විය හැකිය, එකවර කිහිප වතාවක් වර්ධනය සඳහා යම් ආකාරයක අනාවැකි. එවිට SRE කුලියට ගැනීම මූලික වශයෙන් යුක්ති සහගත වන්නේ එය සාධාරණීකරණය කළ හැකි බැවිනි. අපට වර්ධනය සඳහා අවශ්යතා තිබේ, එවැනි වර්ධනයක් සමඟ කිසිවක් කැඩී නොයන බවට වගකිව යුතු පුද්ගලයෙකු අපට අවශ්ය වේ.
තව එක ප්රශ්නයක්. සංවර්ධකයින් කිහිප වතාවක්ම පරීක්ෂණ සමත් වන විශේෂාංගයක් කපා, නමුත් නිෂ්පාදනය බිඳ දැමීම, පදනම පැටවීම, අනෙකුත් විශේෂාංග බිඳ දැමීම, ක්රියාත්මක කිරීමට කුමන ක්රියාවලියක් සිදු කළ යුතුද යන්න. ඒ අනුව, මෙම නඩුවේදී, දෝෂ සඳහා අයවැය හඳුන්වා දෙනු ලැබේ. තවද සමහර සේවාවන්, සමහර විශේෂාංග දැනටමත් නිෂ්පාදනයේ පරීක්ෂාවට ලක්ව ඇත. එය කැනරි විය හැකිය, පරිශීලකයින් කුඩා සංඛ්‍යාවක් පමණක් වන නමුත් දැනටමත් නිෂ්පාදනයේ දී විශේෂාංගයක් යොදවා ඇත, නමුත් දැනටමත් යමක් කැඩී ගියහොත්, උදාහරණයක් ලෙස, සියලුම පරිශීලකයින්ගෙන් සියයට භාගයක් සඳහා, එය තවමත් සපුරාලනු ඇතැයි අපේක්ෂා කෙරේ. වැරදි සඳහා අයවැය. ඒ අනුව, ඔව්, දෝෂයක් ඇති වනු ඇත, සමහර පරිශීලකයින් සඳහා සියල්ල බිඳ වැටෙනු ඇත, නමුත් මෙය සාමාන්ය දෙයක් බව අපි දැනටමත් පවසා ඇත.
SRE මෙවලම් ගැන ප්රශ්නයක් තිබුණා. එනම්, SREs අන් සියල්ලන්ම භාවිතා නොකරන විශේෂිත දෙයක් තිබේද යන්නයි. ඇත්ත වශයෙන්ම, ඉතා විශේෂිත උපයෝගිතා තිබේ, උදාහරණයක් ලෙස, බර අනුකරණය කරන හෝ කැනරි A / B පරීක්ෂණවල නියැලී සිටින යම් ආකාරයක මෘදුකාංගයක් තිබේ. නමුත් මූලික වශයෙන් SRE මෙවලම් කට්ටලය ඔබේ සංවර්ධකයින් දැනටමත් භාවිතා කරයි. SRE සංවර්ධන කණ්ඩායම සමඟ සෘජුව අන්තර් ක්රියා කරන බැවිනි. ඔබට විවිධ මෙවලම් තිබේ නම්, සමමුහුර්ත කිරීමට කාලය ගතවන බව පෙනේ. විශේෂයෙන් SREs විශාල කණ්ඩායම් වල, කණ්ඩායම් කිහිපයක් සිටිය හැකි විශාල සමාගම්වල වැඩ කරන්නේ නම්, සමාගම් පුරා ප්‍රමිතිකරණය මෙහි බොහෝ උපකාරී වනු ඇත, මන්ද කණ්ඩායම් 50 ක විවිධ උපයෝගිතා 50 ක් භාවිතා කරන්නේ නම්, මෙයින් අදහස් කරන්නේ SRE ඒවා දැන සිටිය යුතු බවයි. සෑම. ඇත්ත වශයෙන්ම මෙය කිසි විටෙකත් සිදු නොවනු ඇත. කාර්යයේ ගුණාත්මකභාවය, අවම වශයෙන් සමහර කණ්ඩායම්වල පාලනයේ ගුණාත්මකභාවය සැලකිය යුතු ලෙස අඩු වනු ඇත.
අපේ webinar එක ඉවර වෙනවා. මට මූලික දේවල් ටිකක් කියන්න පුළුවන් වුණා. ඇත්ත වශයෙන්ම, SRE ගැන කිසිවක් පැයකින් පවසා තේරුම් ගත නොහැක. නමුත් ප්‍රධාන ප්‍රධාන කරුණු වන මෙම සිතීමේ ක්‍රමය ප්‍රකාශ කිරීමට මා සමත් වූ බව මම බලාපොරොත්තු වෙමි. ඉන්පසුව, උනන්දුවක් දක්වන්නේ නම්, මාතෘකාව ගැන සොයා බැලීමට, ඔබම ඉගෙන ගැනීමට, වෙනත් පුද්ගලයින් විසින් වෙනත් සමාගම්වල එය ක්රියාත්මක කරන ආකාරය දෙස බැලීමට හැකි වනු ඇත. ඒ අනුව, පෙබරවාරි මුලදී, Slurm SRE හි අප වෙත එන්න.
Slurm SRE යනු දින තුනක තීව්‍ර පාඨමාලාවක් වන අතර එය මා දැන් කතා කරන දේ ගැන කතා කරනු ඇත, නමුත් වඩාත් ගැඹුරින්, සැබෑ අවස්ථා සමඟ, ප්රායෝගිකව, මුළු තීව්‍රතාවයම ප්‍රායෝගික වැඩ සඳහා ඉලක්ක කර ඇත. මිනිසුන් කණ්ඩායම් වලට බෙදනු ඇත. ඔබ සැවොම සැබෑ නඩු මත වැඩ කරනු ඇත. ඒ අනුව, අපට Booking.com උපදේශකයින් Ivan Kruglov සහ Ben Tyler සිටී. අපට ගූගල් වෙතින් සැන් ෆ්‍රැන්සිස්කෝ වෙතින් අපූරු ඉයුජින් බරබ්බාස් තිබේ. ඒ වගේම මම ඔයාටත් දෙයක් කියන්නම්. එබැවින් අප වෙත පැමිණීමට වග බලා ගන්න.
ඉතින්, ග්‍රන්ථ නාමාවලිය. SRE පිළිබඳ යොමු ඇත. එකම පොත මත, හෝ ඒ වෙනුවට Google විසින් ලියන ලද SRE පිළිබඳ පොත් 2 මත. තවත් එකක් , නියමයන් සහ ඒවායේ යෙදුම තරමක් විස්තරාත්මකව ඇත. ඊළඟ 3 විවිධ සමාගම්වල SRE පිළිබඳ වාර්තා වේ. පලමු - , මෙය Google හි Ben Trainer ගේ ප්‍රධාන සටහනකි. දෙවැනි - . තුන්වැන්න නැවතත් . සිට හතරවන වාර්තාව , රටවල් 5 ක ප්‍රධාන SRE සේවකයින් 190 දෙනෙකු පමණක් සිටී. මේ සියල්ල දෙස බැලීම ඉතා සිත්ගන්නා සුළුය, මන්ද DevOps විවිධ සමාගම්වලට සහ විවිධ කණ්ඩායම්වලට පවා බොහෝ වෙනස් දේ අදහස් කරන ආකාරයටම, SRE ට සමාන ප්‍රමාණයේ සමාගම්වල පවා බොහෝ වෙනස් වගකීම් ඇත.
අවුල් ඉංජිනේරු විද්‍යාවේ මූලධර්ම පිළිබඳ තවත් සබැඳි 2ක්: , . ඒවගේම අවසානයේ Awesome Lists ගැන කතා මාලාවෙන් ලැයිස්තු 3ක් තියෙනවා , ගැන සහ ගැන . SRE හි ලැයිස්තුව ඇදහිය නොහැකි තරම් විශාල ය, ඒ සියල්ල හරහා යාමට අවශ්ය නොවේ, ලිපි 200 ක් පමණ ඇත. ධාරිතා සැලසුම් කිරීම සහ නිර්දෝෂී පශ්චාත් මරණ පරීක්ෂණය පිළිබඳ ලිපි මම බෙහෙවින් නිර්දේශ කරමි.
සිත්ගන්නා ලිපිය:
මේ කාලය පුරාම මට ඇහුම්කන් දීම ගැන ඔබට ස්තූතියි. ඔබ යමක් ඉගෙන ගෙන ඇතැයි බලාපොරොත්තු වෙනවා. ඔබට තව තවත් ඉගෙන ගැනීමට ප්රමාණවත් ද්රව්ය ඇතැයි සිතමු. හා හමුවෙමු. පෙබරවාරි මාසයේ බලාපොරොත්තු වෙනවා.
webinar සත්කාරකත්වය දරනු ලැබුවේ Eduard Medvedev විසිනි.
PS: කියවීමට කැමති අය සඳහා, Eduard යොමු ලැයිස්තුවක් ලබා දුන්නේය. ප්රායෝගිකව තේරුම් ගැනීමට කැමති අය සාදරයෙන් පිළිගනිමු .
මූලාශ්රය: www.habr.com