අවංකවම, අධීක්ෂණ දෙපාර්තමේන්තුවේ ඔහුගේ සගයන්ගේ නිෂ්ඵල උත්සාහයන් ගැන අයිවන් බොහෝ විට සිනාසුණේය. සමාගමේ කළමනාකාරිත්වය ඔවුන්ට සාක්ෂාත් කර ගැනීමට නියෝග කළ ප්‍රමිතික ක්රියාත්මක කිරීමට ඔවුන් විශාල උත්සාහයක් ගත්හ. ඔවුන් කෙතරම් කාර්යබහුල වූවාද කිවහොත්, වෙනත් කිසිවෙකු කිසිවක් කරනවාට ඔවුන් අකමැති විය.
නමුත් කළමනාකරණයට එය ප්‍රමාණවත් නොවීය - ඔවුන් නිරන්තරයෙන් වැඩි වැඩියෙන් නව ප්‍රමිතික ඇණවුම් කළ අතර, කලින් කළ දේ භාවිතා කිරීම ඉතා ඉක්මනින් නතර කරයි.
මෑතකාලීනව, සෑම කෙනෙකුම LeadTime ගැන කතා කරයි - ව්‍යාපාරික විශේෂාංග බෙදා හැරීමේ කාලය. මෙට්රික් පිස්සු අංකයක් පෙන්වීය - එක් කාර්යයක් ලබා දීමට දින 200 ක්. සියල්ලෝම අහස් හඬින් තම දෑත් අහසට එසවූ හැටි!
ටික වේලාවකට පසු, ශබ්දය ක්‍රමයෙන් අඩු වූ අතර කළමනාකරණයට තවත් මෙට්රික් එකක් සෑදීමට නියෝගයක් ලැබුණි.
නව මෙට්රික් අඳුරු කොනක නිහඬව මිය යන බව අයිවන්ට සම්පූර්ණයෙන්ම පැහැදිලි විය.
ඇත්ත වශයෙන්ම, අයිවන් සිතුවේ, අංකය දැන සිටීම කිසිවෙකුට කිසිවක් නොකියයි. දින 200 ක් හෝ දින 2 ක් - වෙනසක් නැත, මන්ද අංකයෙන් හේතුව තීරණය කර එය හොඳ හෝ නරක දැයි තේරුම් ගත නොහැක.
මෙය සාමාන්‍ය ප්‍රමිතික උගුලකි: නව මෙට්රික් එකක් පැවැත්මේ සාරය පවසන අතර යම් රහස් රහසක් පැහැදිලි කරන බව පෙනේ. හැමෝම මේ සඳහා බොහෝ බලාපොරොත්තු තබා ඇත, නමුත් යම් හේතුවක් නිසා කිසිවක් සිදු නොවේ. ඔව්, රහස මෙට්රික් වලින් සොයාගත යුතු නැති නිසා!
අයිවන් සඳහා මෙය සමත් වූ වේදිකාවකි. ඒක එයාට තේරුණා මිනුම් සඳහා, සහ සියලු රහස් සෙවිය යුතුය , i.e. මෙම මෙට්රික් සෑදී ඇති බවයි.
ඔන්ලයින් වෙළඳසැලක් සඳහා, බලපෑමේ පරමාර්ථය මුදල් ගෙන එන එහි ගනුදෙනුකරුවන් වනු ඇත, සහ DevOps සඳහා, එය නල මාර්ගයක් භාවිතයෙන් බෙදාහැරීම් නිර්මාණය කරන සහ ක්රියාත්මක කරන කණ්ඩායම් වේ.
දිනක්, ශාලාවේ සුවපහසු පුටුවක වාඩි වූ අයිවන්, බලපෑමේ පරමාර්ථය කණ්ඩායම් බව සැලකිල්ලට ගනිමින්, DevOps ප්‍රමිතික බැලීමට අවශ්ය ආකාරය හොඳින් සිතා බැලීමට තීරණය කළේය.
DevOps Metrics හි අරමුණ
සෑම කෙනෙකුටම බෙදා හැරීමේ කාලය අඩු කිරීමට අවශ්ය බව පැහැදිලිය. දින 200 ඇත්තෙන්ම හොඳ නැත.
ඒත් කොහොමද, ඒක තමයි ප්‍රශ්නය?
සමාගම කණ්ඩායම් සිය ගණනක් සේවයේ යොදවා ඇති අතර, සෑම දිනකම බෙදාහැරීම් දහස් ගණනක් DevOps නල මාර්ගය හරහා සිදු වේ. සැබෑ බෙදාහැරීමේ කාලය බෙදාහැරීමක් ලෙස දිස්වනු ඇත. සෑම කණ්ඩායමකටම තමන්ගේම කාලය සහ තමන්ගේම ලක්ෂණ ඇත. ඔබ මෙම අවුලෙන් කිසිවක් සොයා ගන්නේ කෙසේද?
පිළිතුර ස්වාභාවිකවම මතු විය - අපි ගැටළු කණ්ඩායම් සොයා ගත යුතු අතර ඔවුන් සමඟ සිදුවන්නේ කුමක්ද සහ එය මෙතරම් කාලයක් ගත වන්නේ මන්දැයි සොයා බැලිය යුතු අතර, සියල්ල ඉක්මනින් කරන්නේ කෙසේදැයි "හොඳ" කණ්ඩායම් වලින් ඉගෙන ගන්න. මෙය සිදු කිරීම සඳහා, ඔබ එක් එක් DevOps ස්ථාවරය තුළ කණ්ඩායම් විසින් ගත කරන කාලය මැනිය යුතුය:
“පද්ධතියේ අරමුණ වනුයේ ඔවුන් ස්ථාවරය පසු කරන කාලය මත පදනම්ව කණ්ඩායම් තෝරා ගැනීමයි. එහි ප්රතිඵලයක් වශයෙන්, අපි තෝරාගත් කාලය සමඟ විධාන ලැයිස්තුවක් ලබා ගත යුතු අතර, අංකයක් නොවේ.
ස්ටෑන්ඩ් එකට මුළු වෙලාව කීයද, ස්ටෑන්ඩ් අතර කොච්චර වෙලාවක් ගියාද කියලා හොයලා බැලුවොත් අපිට කණ්ඩායම් හොයාගෙන, එයාලව අමතා, ඊට හේතුව වඩාත් විස්තරාත්මකව තේරුම් අරගෙන ඒවා නැති කරන්න පුළුවන්.” අයිවන් සිතුවා.
DevOps සඳහා බෙදා හැරීමේ කාලය ගණනය කරන්නේ කෙසේද
එය ගණනය කිරීම සඳහා, DevOps ක්රියාවලිය සහ එහි සාරය සොයා බැලීම අවශ්ය විය.
සමාගම සීමිත පද්ධති සංඛ්‍යාවක් භාවිතා කරන අතර තොරතුරු ලබා ගත හැක්කේ ඔවුන්ගෙන් මිස වෙන කොහේවත් නොවේ.
සමාගමේ සියලුම කාර්යයන් ජිරා හි ලියාපදිංචි කර ඇත. කාර්යයක් භාරගත් විට, ඒ සඳහා ශාඛාවක් නිර්මාණය කරන ලද අතර, එය ක්රියාත්මක කිරීමෙන් පසුව, BitBucket සහ Pull Request සඳහා කැපවීමක් සිදු කරන ලදී. PR (Pull Request) පිළිගත් විට, බෙදා හැරීමක් ස්වයංක්‍රීයව නිර්මාණය කර Nexus ගබඩාවේ ගබඩා කර ඇත.
ඊළඟට, පෙරළීම, ස්වයංක්‍රීය සහ අතින් පරීක්ෂා කිරීමේ නිරවද්‍යතාවය පරීක්ෂා කිරීම සඳහා ජෙන්කින්ස් භාවිතයෙන් බෙදා හැරීම නැවතුම් කිහිපයක සිදු කරන ලදී:
නැවතුම්පොළේ වේලාව ගණනය කිරීම සඳහා ගත හැකි තොරතුරු මොනවාදැයි අයිවන් විස්තර කළේය:
- Nexus වෙතින් - බෙදාහැරීමේ නිර්මාණ කාලය සහ විධාන කේතය අඩංගු ෆෝල්ඩරයේ නම
- ජෙන්කින්ස් වෙතින් - එක් එක් රැකියාවේ ආරම්භක වේලාව, කාලසීමාව සහ ප්‍රතිඵලය, ස්ථාවර නාමය (රැකියා පරාමිතීන් තුළ), අදියර (රැකියා පියවර), Nexus හි බෙදා හැරීමට සම්බන්ධ කරන්න.
- ජිරා සහ බිට්බකට් නල මාර්ගයට ඇතුළත් නොකිරීමට අයිවන් තීරණය කළේය, මන්ද ... ඒවා සංවර්ධන අදියරට වඩා සම්බන්ධ වූ අතර, නිමි බෙදාහැරීම නැවතුම්පොළවල පෙරළීමට නොවේ.
පවතින තොරතුරු මත පදනම්ව, පහත රූප සටහන ඇඳ ඇත:
බෙදාහැරීම් නිර්මාණය කිරීමට කොපමණ කාලයක් ගතවේද සහ ඒ සෑම එකක් සඳහාම කොපමණ කාලයක් වැය කරන්නේද යන්න දැන ගැනීමෙන්, ඔබට සම්පූර්ණ DevOps නල මාර්ගය (පූර්ණ චක්රය) හරහා යාමේ සම්පූර්ණ පිරිවැය පහසුවෙන් ගණනය කළ හැකිය.
Ivan අවසන් කළ DevOps ප්‍රමිතික මෙන්න:
- සාදන ලද බෙදාහැරීම් ගණන
- ස්ථාවරයට "පැමිණි" සහ ස්ථාවරය "පසුකර ගිය" බෙදාහැරීම්වල කොටස
- ස්ථාවරය මත ගත කළ කාලය (ස්ථාවර චක්රය)
- සම්පූර්ණ චක්රය (සියලු නැවතුම් සඳහා මුළු කාලය)
- රැකියා කාලය
- නැවතුම් අතර අක්‍රීය කාලය
- එකම ස්ථාවරයේ රැකියා දියත් කිරීම් අතර අක්‍රීය කාලය
එක් අතකින්, ප්‍රමිතික කාලය අනුව DevOps නල මාර්ගය ඉතා හොඳින් සංලක්ෂිත කරයි, අනෙක් අතට, ඒවා ඉතා සරල ලෙස සලකනු ලැබීය.
හොඳින් කළ කාර්යය ගැන සෑහීමකට පත් වූ අයිවන් ඉදිරිපත් කිරීමක් කර කළමනාකාරිත්වයට ඉදිරිපත් කිරීමට ගියේය.
ඔහු ආපසු පැමිණියේ අඳුරු සහ දෑත් පහත් කරමිනි.
“මේක නම් මහා විනාශයක් අයියේ,” උපහාසාත්මක සගයා සිනාසුණේය.
ලිපියේ වැඩිදුර කියවන්න "".
මූලාශ්රය: www.habr.com