DevOps යනු කුමක්ද?

DevOps හි නිර්වචනය ඉතා සංකීර්ණයි, එබැවින් අපට සෑම අවස්ථාවකදීම ඒ පිළිබඳ සාකච්ඡාව නැවත ආරම්භ කිරීමට සිදුවේ. හබ්රේ ගැන පමණක් මෙම මාතෘකාව පිළිබඳ ප්‍රකාශන දහසක් ඇත. නමුත් ඔබ මෙය කියවන කෙනෙක් නම් DevOps යනු කුමක්දැයි ඔබ දන්නවා ඇති. මොකද මම එහෙම නෑ. හෙලෝ මගේ නම ඇලෙක්සැන්ඩර් ටිටෝව් (@osminog), සහ අපි DevOps ගැන කතා කරන්නම්, මම මගේ අත්දැකීම් බෙදා ගන්නම්.

මගේ කතාව ප්‍රයෝජනවත් කරන්නේ කෙසේද යන්න ගැන මම දිගු කලක් තිස්සේ සිතමින් සිටිමි, එබැවින් මෙහි බොහෝ ප්‍රශ්න ඇති වනු ඇත - මා මගෙන් අසන සහ අපගේ සමාගමේ ගනුදෙනුකරුවන්ගෙන් මා අසන ඒවා. මෙම ප්රශ්නවලට පිළිතුරු සැපයීමෙන්, අවබෝධය වඩා හොඳ වේ. මගේ දෘෂ්ටි කෝණයෙන් DevOps අවශ්‍ය වන්නේ මන්දැයි මම ඔබට කියමි, එය නැවතත්, මගේ දෘෂ්ටි කෝණයෙන්, සහ ඔබ මගේ දෘෂ්ටි කෝණයෙන් නැවත DevOps වෙත ගමන් කරන බව තේරුම් ගන්නේ කෙසේද. අවසාන කරුණ වනුයේ ප්‍රශ්න හරහාය. ඒවාට ඔබම පිළිතුරු දීමෙන්, ඔබේ සමාගම DevOps වෙත ගමන් කරන්නේද නැතහොත් යම් ආකාරයකින් ගැටලු තිබේද යන්න ඔබට තේරුම් ගත හැකිය.

එක් කාලයකදී මම ඒකාබද්ධ කිරීම් සහ අත්පත් කර ගැනීම් රැල්ලෙන් ගමන් කරමින් සිටියෙමි. මුලින්ම මම Qik කියන පොඩි startup එකක වැඩ කලා, ඊට පස්සේ Skype කියන ටිකක් ලොකු කම්පැනි එකෙන් ගත්ත, ඊට පස්සේ Microsoft කියන ටිකක් ලොකු company එකකින් ගත්ත. ඒ මොහොතේ, විවිධ ප්‍රමාණයේ සමාගම්වල DevOps අදහස පරිවර්තනය වන ආකාරය මම දැකීමට පටන් ගතිමි. ඉන්පසුව, මම DevOps දෙස වෙළඳපොලේ දෘෂ්ටි කෝණයෙන් බැලීමට උනන්දු වූ අතර, මගේ සගයන් සහ මම Express 42 සමාගම ආරම්භ කළෙමු. දැනට වසර 6 ක් තිස්සේ අපි වෙළඳපොලේ රැළි දිගේ ගමන් කරමින් සිටිමු.

වෙනත් දේ අතර, මම DevOps මොස්කව් ප්‍රජාවේ සංවිධායකයින්ගෙන් කෙනෙක් සහ DevOps-Days 2017 හි සංවිධායකයි, නමුත් මම 2018 සංවිධානය කළේ නැත. Express 42 බොහෝ සමාගම් සමඟ වැඩ කරයි. අපි එහි DevOps වර්ධනය කරන්නෙමු, එය සිදුවන ආකාරය නරඹන්නෙමු, නිගමනවලට එළඹෙමු, විශ්ලේෂණය කරන්නෙමු, අපගේ නිගමන සැමට කියන්නෙමු, සහ DevOps පරිචයන් තුළ මිනිසුන් පුහුණු කරන්නෙමු. පොදුවේ ගත් කල, මේ සම්බන්ධයෙන් අපගේ අත්දැකීම් සහ ප්‍රවීණත්වය වැඩි කිරීමට අපි අපේ උපරිමය කරන්නෙමු.

ඇයි DevOps

සෑම කෙනෙකුම හා සෑම විටම හොල්මන් කරන පළමු ප්රශ්නය වන්නේ - ඇයි? බොහෝ අය සිතන්නේ DevOps යනු ස්වයංක්‍රීයකරණය හෝ සෑම සමාගමකටම දැනටමත් තිබූ සමාන දෙයක් බවයි.

— අපට අඛණ්ඩ ඒකාබද්ධතාවයක් තිබුණි - මෙයින් අදහස් කරන්නේ අපට දැනටමත් DevOps තිබූ බවයි, සහ මේ සියල්ල අවශ්‍ය වන්නේ ඇයි? පිටරට උන් ආතල් ගත්තට අපිව වැඩ කරන එක නවත්තනවා!

වසර 9 ක් පුරා ප්රජාව සහ ක්රමවේදය සංවර්ධනය කිරීම, මෙය තවමත් අලෙවිකරණ ග්ලිටර් නොවන බව දැනටමත් පැහැදිලි වී ඇත, නමුත් එය අවශ්ය වන්නේ මන්දැයි තවමත් සම්පූර්ණයෙන්ම පැහැදිලි නැත. ඕනෑම මෙවලමක් සහ ක්‍රියාවලියක් මෙන්, DevOps හට එය අවසානයේ අත්කර ගන්නා නිශ්චිත ඉලක්ක ඇත.

මේ සියල්ලට හේතුව ලෝකය වෙනස් වීමයි. අපේ ශාන්ත පීටර්ස්බර්ග් සම්භාව්‍ය ගායනා කළ පරිදි, A ලක්ෂයේ සිට B දක්වා නිශ්චිත උපාය මාර්ගයකට අනුව, මේ සඳහා ගොඩනඟන ලද නිශ්චිත ව්‍යුහයක් සමඟ සමාගම් කෙලින්ම සිහිනයක් දෙසට ගමන් කරන විට ඔහු ව්‍යවසාය ප්‍රවේශයෙන් ඉවත් වේ.

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

ස්වයංක්‍රීයකරණය බොහෝ විට වෙනස් නොවේ, මන්ද සමාගමක් හොඳින් පාගා දැමූ රස්තියාදුකාරයෙකුට ගිය විට, වෙනස් කිරීමට ඇත්තේ කුමක්ද? එය ක්රියා කරයි - එය ස්පර්ශ නොකරන්න. දැන් ලෝකයේ ප්‍රවේශයන් වෙනස් වෙමින් පවතින අතර, Agile නමින් හැඳින්වෙන තැනැත්තා යෝජනා කරන්නේ අවසාන ලක්ෂ්‍යය B ක්ෂණිකව නොපෙනෙන බවයි.

සමාගමක් වෙළඳපල හරහා යන විට, සේවාදායකයෙකු සමඟ වැඩ කරන විට, එය නිරන්තරයෙන් වෙළඳපල ගවේෂණය කරන අතර B අවසාන ලක්ෂ්‍යය වෙනස් කරයි. එපමණක් නොව, සමාගම බොහෝ විට එහි දිශාව වෙනස් කරන තරමට එය අවසානයේ සාර්ථක වේ, මන්ද එය වැඩි වෙළඳපලක් තෝරා ගන්නා බැවිනි. නිකේතන.

මම මෑතකදී ඉගෙන ගත් සිත්ගන්නා සමාගමක් විසින් උපාය මාර්ගය විදහා දක්වයි. One Box Shave යනු පෙට්ටියක රේසර් සහ රැවුල බෑමේ උපාංග සඳහා දායක බෙදා හැරීමේ සේවාවකි. විවිධ ගනුදෙනුකරුවන් සඳහා ඔවුන්ගේ "කොටුව" අභිරුචිකරණය කරන්නේ කෙසේදැයි ඔවුන් දනී. මෙය සිදු කරනු ලබන්නේ කිසියම් මෘදුකාංගයක් මගින් වන අතර, එය භාණ්ඩ නිෂ්පාදනය කරන කොරියානු කර්මාන්ත ශාලාව වෙත ඇණවුම යවයි.

මෙම නිෂ්පාදනය ඩොලර් බිලියනයකට යුනිලීවර් විසින් මිලදී ගෙන ඇත. එය දැන් Gillette සමඟ තරඟ කරන අතර ඇමරිකානු වෙළඳපොලේ පාරිභෝගිකයින්ගෙන් සැලකිය යුතු කොටසක් ඉවත් කර ඇත. One Box Shave මෙහෙම කියනවා:

- තල 4? ඔබ බරපතලද? ඔබට මෙය අවශ්ය වන්නේ ඇයි - එය රැවුල බෑමේ ගුණාත්මකභාවය වැඩි දියුණු නොවේ. විශේෂයෙන් තෝරාගත් ක්‍රීම් එකක්, සුවඳක් සහ තල දෙකක් සහිත උසස් තත්ත්වයේ රේසරයක් එම මෝඩ 4 ගිලට් බ්ලේඩ් වලට වඩා බොහෝ ගැටලු විසඳයි! අපි ඉක්මනින්ම 10ට යමුද?

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

Time-to-market හි කාරණය වන්නේ අප කොපමණ වාරයක් යෙදවීම නොවේ. ඔබට බොහෝ විට යෙදවිය හැකිය, නමුත් මුදා හැරීමේ චක්‍ර දිගු වේ. මාස තුනක මුදා හැරීමේ චක්‍ර එකිනෙක මත අධිස්ථාපනය වී සතියකින් ඒවා මාරු කරන්නේ නම්, සමාගම සතියකට වරක් යොදවන බව පෙනේ. අදහසේ සිට අවසාන ක්‍රියාත්මක කිරීම දක්වා මාස 3 ක් ගතවේ.

Time-to-market යනු අදහසේ සිට අවසාන ක්‍රියාත්මක කිරීම දක්වා කාලය අවම කිරීමයි.

මෙම අවස්ථාවේදී, මෘදුකාංග වෙළඳපොළ සමඟ අන්තර් ක්රියා කරයි. One Box Shave වෙබ් අඩවිය සේවාදායකයා සමඟ අන්තර් ක්‍රියා කරන ආකාරය මෙයයි. ඔවුන්ට විකුණුම්කරුවන් නැත - අමුත්තන් ක්ලික් කර පැතුම් තබන වෙබ් අඩවියකි. ඒ අනුව, නව යමක් නිරන්තරයෙන් වෙබ් අඩවියේ පළ කළ යුතු අතර කැමැත්තට අනුකූලව යාවත්කාලීන කළ යුතුය. නිදසුනක් වශයෙන්, දකුණු කොරියාවේ ඔවුන් රුසියාවට වඩා වෙනස් ලෙස රැවුල කපන අතර, ඔවුන් කැමති පයින් සුවඳ නොව, නමුත්, උදාහරණයක් ලෙස, කැරට් සහ වැනිලා.

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

උදාහරණයක් ලෙස, Qik හිදී අපි හදිසියේම දැනගත්තේ, සේවාදායකයට සම්බන්ධතා ලැයිස්තු උඩුගත කිරීමට මිනිසුන් සැබවින්ම කැමති බවත්, ඔවුන් අපට යෙදුමක් ලබා දුන් බවත්ය. මුලදී අපි ඒ ගැන හිතුවේ නැහැ. සම්භාව්‍ය සමාගමක, මෙය දෝෂයක් බව සෑම කෙනෙකුම තීරණය කරනු ඇත, එය විශිෂ්ට ලෙස ක්‍රියා කළ යුතු යැයි පිරිවිතර නොකී නිසා සහ සාමාන්‍යයෙන් දණහිස මත ක්‍රියාත්මක වූ බැවින්, ඔවුන් විශේෂාංගය ක්‍රියා විරහිත කර මෙසේ පවසනු ඇත: “කාටවත් මෙය අවශ්‍ය නැත, වැදගත්ම දෙය නම් ප්‍රධාන ක්‍රියාකාරිත්වය ක්‍රියාත්මක වීමයි. ” තවද තාක්ෂණ සමාගම මෙය අවස්ථාවක් ලෙස දකින අතර මෙයට අනුකූලව මෘදුකාංගය වෙනස් කිරීමට පටන් ගනී.

1968 දී, දූරදර්ශී පුද්ගලයෙක් වන මෙල්වින් කොන්වේ පහත අදහස සකස් කළේය.

පද්ධතිය නිර්මාණය කරන සංවිධානය එම සංවිධානයේ සන්නිවේදන ව්‍යුහය අනුකරණය කරන සැලසුමකින් සීමා වේ.

වඩාත් විස්තරාත්මකව, වෙනත් වර්ගයක පද්ධති නිෂ්පාදනය කිරීම සඳහා, ඔබට වෙනත් වර්ගයක සමාගමක් තුළ සන්නිවේදන ව්‍යුහයක් ද තිබිය යුතුය. ඔබේ සන්නිවේදන ව්‍යුහය ඉහළ ධුරාවලියක් නම්, මෙය ඔබට ඉතා ඉහළ Time-to-Market දර්ශකයක් සැපයිය හැකි පද්ධති නිර්මාණය කිරීමට ඉඩ නොදේ.

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

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

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

එසේනම් ඔබට DevOps අවශ්‍ය වන්නේ ඇයි?

ඩිජිටල් නිෂ්පාදන සංවර්ධනය සඳහා. ඔබේ සමාගමට ඩිජිටල් නිෂ්පාදනයක් නොමැති නම්, DevOps අවශ්ය නොවේ - එය ඉතා වැදගත් වේ.

DevOps අනුක්‍රමික මෘදුකාංග නිෂ්පාදනයේ වේග සීමාවන් ජය ගනී. එය තුළ සියලු ක්රියාවලීන් එකවර සිදු වේ.

අපහසුතා වැඩිවේ. DevOps එවැන්ජලිස්තවරුන් ඔබට එය මෘදුකාංග මුදා හැරීම පහසු කරන බව පවසන විට, මෙය විකාරයකි.

DevOps සමඟ, දේවල් වඩාත් සංකීර්ණ වනු ඇත.

Avito ස්ටෑන්ඩ් හි පැවති සම්මන්ත්‍රණයේදී, ඩොකර් කන්ටේනරයක් යෙදවීම කෙබඳු දැයි ඔබට දැක ගත හැකිය - එය යථාර්ථවාදී නොවන කාර්යයකි. සංකීර්ණත්වය තහනම් වේ; ඔබට එකවර බොහෝ බෝල හසුරුවන්න සිදු වේ.

DevOps සමාගම තුළ ක්‍රියාවලිය සහ සංවිධානය සම්පූර්ණයෙන්ම වෙනස් කරයි — වඩාත් නිවැරදිව, එය වෙනස් වන්නේ DevOps නොව, ඩිජිටල් නිෂ්පාදනයයි. DevOps වෙත පැමිණීමට, ඔබ තවමත් මෙම ක්‍රියාවලිය සම්පූර්ණයෙන්ම වෙනස් කළ යුතුය.

විශේෂඥයෙකු සඳහා ප්රශ්න

මොනවද ඔබට තියෙන්නේ? සමාගමක සේවය කරන අතරතුර සහ විශේෂඥයෙකු ලෙස වර්ධනය වන විට ඔබට ඔබෙන්ම ඇසිය හැකි ප්රශ්න.

ඩිජිටල් නිෂ්පාදනයක් නිර්මාණය කිරීම සඳහා ඔබට උපාය මාර්ගයක් තිබේද? තිබේ නම්, එය දැනටමත් හොඳයි. මෙයින් අදහස් වන්නේ ඔබේ සමාගම DevOps වෙත ගමන් කරන බවයි.

ඔබේ සමාගම දැනටමත් ඩිජිටල් නිෂ්පාදනයක් නිර්මාණය කරනවාද? මෙයින් අදහස් කරන්නේ ඔබට තවත් මට්ටමක් ඉහළට නැඟී වඩාත් රසවත් ලෙස දේවල් කළ හැකි බවයි - නැවතත් DevOps දෘෂ්ටි කෝණයකින්. මම කතා කරන්නේ මෙම දෘෂ්ටි කෝණයෙන් පමණි.

ඔබේ සමාගම ඩිජිටල් නිෂ්පාදන නිකේතනයේ වෙළඳපල ප්‍රමුඛයන්ගෙන් එකක්ද? Spotify, Yandex, Uber දැන් තාක්ෂණික ප්‍රගතියේ උච්චතම ස්ථානයේ සිටින සමාගම් වේ.

මෙම ප්‍රශ්න ඔබෙන්ම අසන්න, සියලු පිළිතුරු නැත නම්, සමහර විට ඔබ මෙම සමාගමෙහි DevOps නොකළ යුතුය. DevOps හි මාතෘකාව ඔබට සැබවින්ම සිත්ගන්නාසුළු නම්, සමහර විට ... ඔබ වෙනත් සමාගමකට මාරු විය යුතුද? ඔබේ සමාගමට DevOps වෙත යාමට අවශ්‍ය නම්, නමුත් ඔබ සියලු ප්‍රශ්නවලට “නැත” යැයි පිළිතුරු දුන්නේ නම්, එය කිසිදා වෙනස් නොවන සුන්දර රයිනෝසිරස් වැනි ය.

සංවිධානය

මම කිව්වා වගේ, කොන්වේගේ නීතියට අනුව, සමාගමක සංවිධානය වෙනස් වේ. ආයතනික දෘෂ්ටි කෝණයෙන් DevOps සමාගම තුළට විනිවිද යාම වළක්වන දේ සමඟ මම ආරම්භ කරමි.

"ළිං" පිළිබඳ ගැටළුව

"Silo" යන ඉංග්‍රීසි වචනය මෙහි රුසියානු භාෂාවට පරිවර්තනය කර ඇත්තේ "well" ලෙසිනි. මෙම ගැටලුවේ කාරණය වන්නේ එයයි කණ්ඩායම් අතර තොරතුරු හුවමාරුවක් නොමැත. සෑම කණ්ඩායමක්ම සැරිසැරීමට පොදු සිතියමක් ගොඩනඟා නොගෙන, එහි විශේෂඥතාව ගැඹුරින් හාරයි.

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

DevOps යෝජනා කරන්නේ මෙම ව්‍යාකූලත්වයේ මොහොත හරහා යාමට සහ පොදු අන්තර්ක්‍රියා සිතියමක් ගොඩනැගීමට සියලු දෙපාර්තමේන්තු එකට වැඩ කිරීමයි.

සාධක දෙකක් මෙයට බාධා කරයි.

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

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

- අපට CI දියත් කිරීමට අවශ්‍ය විය, නමුත් කළමනාකරණයට එය අවශ්‍ය නොවන බව පෙනී ගියේය.

මෙය හරියටම සිදු වන්නේ නිසාය CI и අඛණ්ඩ බෙදාහැරීමේ ක්රියාවලිය බොහෝ විභාගවල මායිමේ ඇත. ආයතනික මට්ටමින් "ළිං" පිළිබඳ ගැටලුව ජය නොගෙන, ඔබ කුමක් කළත්, කොතරම් දුක් වූවත් ඔබට ඉදිරියට යාමට නොහැකි වනු ඇත.

සමාගමේ ක්‍රියාවලියේ සෑම සහභාගිවන්නෙකුම: පසුපෙළ සහ ඉදිරිපස සංවර්ධකයින්, පරීක්ෂණ, ඩීබීඒ, ක්‍රියාකාරිත්වය, ජාලය, තමන්ගේම දිශාවට හෑරීම, සහ කළමනාකරු හැර වෙනත් කිසිවෙකුට පොදු සිතියමක් නොමැත, ඔහු කෙසේ හෝ ඒවා නිරීක්ෂණය කර “බෙදීම” භාවිතයෙන් කළමනාකරණය කරයි. සහ ජය" ක්රමය.

මිනිසුන් සමහර තරු හෝ කොඩි සඳහා සටන් කරයි, සෑම කෙනෙකුම ඔවුන්ගේ විශේෂඥ දැනුම හාරා ඇත.

මෙහි ප්රතිඵලයක් වශයෙන්, මේ සියල්ල එකට සම්බන්ධ කිරීම සහ පොදු නල මාර්ගයක් ගොඩනැගීමේ කාර්යය පැනනගින විට සහ තරු සහ කොඩි සඳහා තවදුරටත් සටන් කිරීමට අවශ්ය නොවන විට, ප්රශ්නය පැනනගින්නේ - අප කුමක් කළ යුතුද? අපි කොහොම හරි එකඟතාවකට එන්න ඕන, හැබැයි මේක කරන හැටි ඉස්කෝලෙදි කවුරුවත් කියලා දුන්නේ නැහැ. අපට පාසලේ සිට උගන්වා ඇත: අටවන ශ්‍රේණිය - හොඳයි! - හත්වන ශ්‍රේණියට සාපේක්ෂව! මෙතනත් එහෙමයි.

ඔබේ සමාගමෙත් එය එසේමද?

මෙය පරීක්ෂා කිරීම සඳහා, ඔබට පහත ප්‍රශ්න ඔබෙන්ම ඇසිය හැක.

කණ්ඩායම් පොදු මෙවලම් භාවිතා කරන අතර එම පොදු මෙවලම්වල වෙනස්කම් වලට දායක වේද?

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

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

සමාගමේ ජයග්‍රහණ නොසලකා පුද්ගලික ජයග්‍රහණ ලබා ගැනීම කළමනාකරුවන්ට කොතරම් වැදගත්ද?

ඔබ මෙම ප්‍රශ්නවලට ඔබම පිළිතුරු දෙන්නේ නම්, ඔබේ සමාගම තුළ ඔබට එවැනි ගැටලුවක් තිබේද යන්න වඩාත් පැහැදිලි වනු ඇත.

කේතය ලෙස යටිතල පහසුකම්

මෙම ගැටළුව සම්මත වූ පසු, DevOps හි තවදුරටත් ඉදිරියට යාමට අපහසු වන පළමු වැදගත් භාවිතය වේ කේතය ලෙස යටිතල පහසුකම්.

බොහෝ විට, යටිතල පහසුකම් කේතය ලෙස පහත පරිදි වටහා ගනී:

— අපි හැම දෙයක්ම bash තුළ ස්වයංක්‍රීය කරමු, පරිපාලකයින්ට අතින් වැඩ අඩු වන පරිදි ස්ක්‍රිප්ට් වලින් ආවරණය කරමු!

නමුත් එය සත්‍ය නොවේ.

කේතය ලෙස යටිතල පහසුකම් යන්නෙන් අදහස් වන්නේ ඔබ එහි තත්ත්වය නිරන්තරයෙන් අවබෝධ කර ගැනීම සඳහා ඔබ සමඟ වැඩ කරන තොරතුරු තාක්ෂණ පද්ධතිය කේත ආකාරයෙන් විස්තර කිරීමයි.

අනෙකුත් කණ්ඩායම් සමඟ එක්ව, ඔබ සැමට තේරුම් ගත හැකි සහ සැරිසැරීමට සහ සැරිසැරීමට හැකි කේතයක් ආකාරයෙන් සිතියමක් නිර්මාණය කරයි. එය කුමක් කළත් කමක් නැත - චෙෆ්, ඇන්සිබල්, ලුණු, හෝ Kubernetes හි YAML ගොනු භාවිතා කිරීම - වෙනසක් නැත.

සම්මන්ත්‍රණයේදී, 2GIS හි සගයෙක් පැවසුවේ, තනි පද්ධතිවල ව්‍යුහය විස්තර කරන Kubernetes සඳහා ඔවුන්ගේම අභ්‍යන්තර දෙයක් සෑදූ ආකාරයයි. පද්ධති 500 විස්තර කිරීමට, ඔවුන්ට මෙම විස්තරය උත්පාදනය කරන වෙනම මෙවලමක් අවශ්‍ය විය. මෙම විස්තරය ඇති විට, සෑම කෙනෙකුටම එකිනෙකා සමඟ පරීක්ෂා කළ හැකිය, වෙනස්කම් නිරීක්ෂණය කළ හැකිය, එය වෙනස් කරන්නේ කෙසේද සහ එය වැඩිදියුණු කරන්නේ කෙසේද, නැතිවූ දේ.

එකඟ වන්න, තනි තනි bash ස්ක්‍රිප්ට් සාමාන්‍යයෙන් මෙම අවබෝධය ලබා නොදේ. මා සේවය කළ එක් සමාගමක, "ලියන්න පමණක්" පිටපත සඳහා නමක් පවා තිබුණි - පිටපත ලියා ඇති විට, නමුත් එය තවදුරටත් කියවිය නොහැක. මෙය ඔබටත් හුරුපුරුදු යැයි සිතමි.

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

හොඳම කේත භාවිතයන් අනුව කේතය පවත්වාගෙන යයි: ඒකාබද්ධ සංවර්ධනය, කේත සමාලෝචනය, XP-ක්‍රමලේඛනය, පරීක්ෂා කිරීම, ඉල්ලීම් අදින්න, කේත යටිතල පහසුකම් සඳහා CI - මේ සියල්ල සුදුසු වන අතර භාවිතා කළ හැකිය.

කේතය සියලුම ඉංජිනේරුවන් සඳහා පොදු භාෂාවක් බවට පත්වේ.

කේතයේ යටිතල පහසුකම් වෙනස් කිරීමට වැඩි කාලයක් ගත නොවේ. ඔව්, යටිතල පහසුකම් කේතයට තාක්ෂණික ණය ද තිබිය හැක. සාමාන්‍යයෙන් කණ්ඩායම්වලට එය මුණගැසෙන්නේ ඔවුන් ස්ක්‍රිප්ට් පොකුරක් හෝ ඇන්සිබල් ස්වරූපයෙන් “යටිතල පහසුකම් කේතයක් ලෙස” ක්‍රියාත්මක කිරීමට පටන් ගෙන වසර එකහමාරකට පසුවය, ඔවුන් ස්පැගටි කේතයක් මෙන් ලියන අතර ඔවුන් බැෂ් ස්ක්‍රිප්ට් ද මිශ්‍රණයට විසි කරයි!

වැදගත්: ඔබ තවමත් මෙම දේවල් උත්සාහ කර නොමැති නම්, එය මතක තබා ගන්න ඇන්සිබල් යනු බෂ් නොවේ! ලේඛන ප්රවේශමෙන් කියවන්න, ඔවුන් ඒ ගැන ලියන දේ අධ්යයනය කරන්න.

යටිතල ව්‍යුහය යනු කේතය ලෙස යටිතල ව්‍යූහ කේත වෙනම ස්ථරවලට වෙන් කිරීමයි.

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


පදනම ස්ථරය - OS, උපස්ථ සහ අනෙකුත් පහත් මට්ටමේ දේවල් වින්‍යාස කර ඇත්තේ එලෙසයි, උදාහරණයක් ලෙස, Kubernetes මූලික මට්ටමින් යොදවා ඇති ආකාරය.

සේවා මට්ටම - මේවා ඔබ සංවර්ධකයාට සපයන සේවාවන් වේ: සේවාවක් ලෙස ලොග් වීම, සේවාවක් ලෙස නිරීක්ෂණය කිරීම, සේවාවක් ලෙස දත්ත සමුදාය, සේවාවක් ලෙස සමතුලිත කිරීම, සේවාවක් ලෙස පෝලිම්, සේවාවක් ලෙස අඛණ්ඩ බෙදා හැරීම - තනි කණ්ඩායම් විසින් සපයනු ලබන සේවාවන් සමූහයකි. සංවර්ධනය සඳහා ලබා දිය හැකිය. මේ සියල්ල ඔබගේ වින්‍යාස කළමනාකරණ පද්ධතියේ වෙනම මොඩියුලවල විස්තර කළ යුතුය.

යෙදුම් සෑදූ ස්ථරය සහ පෙර ස්ථර දෙක මත ඒවා දිග හැරෙන ආකාරය විස්තර කරයි.

ප්‍රශ්න පාලනය කරන්න

ඔබේ සමාගමට පොදු යටිතල පහසුකම් ගබඩාවක් තිබේද? ඔබ ඔබේ යටිතල පහසුකම්වල තාක්ෂණික ණය කළමනාකරණය කරන්නේද? ඔබ යටිතල පහසුකම් ගබඩාවක සංවර්ධන පරිචයන් භාවිතා කරන්නේද? ඔබේ යටිතල පහසුකම් ස්ථරවලට කපා තිබේද? ඔබට Base-service-APP රූප සටහන පරීක්ෂා කළ හැක. වෙනසක් කරන්න කොච්චර අමාරුද?

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

අඛණ්ඩ බෙදාහැරීම

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

ඔබ සතුව එය ඇති බවත් එය කළමනාකරණය කරන්නේ කෙසේද යන්නත් පැහැදිලි වූ පසු, හැකි ඉක්මනින් නිෂ්පාදනයට සංවර්ධක කේතය යවන්නේ කෙසේදැයි ඔබ සොයා ගැනීමට පටන් ගනී. මම අදහස් කළේ සංවර්ධකයා සමඟ - “ළිං” පිළිබඳ ගැටළුව අපට මතකයි, එනම්, මෙය ඉදිරිපත් කරන්නේ තනි පුද්ගලයින් නොව කණ්ඩායමකි.

අපි එක්ක ඉන්නකොට වන්යා එව්තුකොවිච් පළමු පොත දැක්කා ජෙස් නිහතමානී සහ කර්තෘ කණ්ඩායම් "අඛණ්ඩ භාරදීම", 2009 දී නිකුත් කරන ලද, එහි මාතෘකාව රුසියානු භාෂාවට පරිවර්තනය කරන්නේ කෙසේදැයි අපි දිගු කලක් සිතුවෙමු. ඔවුන්ට එය "නිරන්තරයෙන් බෙදා හැරීම" ලෙස පරිවර්තනය කිරීමට අවශ්‍ය වූ නමුත්, අවාසනාවකට මෙන්, එය "අඛණ්ඩ බෙදා හැරීම" ලෙස පරිවර්තනය විය. මට පේන විදියට අපේ නමේ රුසියානු දෙයක් තියෙනවා පීඩනයක් එක්ක.

නිරන්තරයෙන් බෙදා හැරීමේ මාධ්‍යයන්

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

අඛණ්ඩව බෙදා හැරීමට, ඔබට යටිතල පහසුකම් වේදිකාවක් හරහා දිවෙන පුරාවස්තු ආකෘතියක් අවශ්‍ය වේ. ඔබ යටිතල පහසුකම් වේදිකාවක් හරහා විවිධ ආකෘතිවල "ජීවිත නාස්තිය" විසි කළහොත්, එය ඒකාබද්ධ වේ, එය නඩත්තු කිරීමට අපහසු වේ, සහ තාක්ෂණික ණය පිළිබඳ ගැටළුව පැන නගී. කෞතුක වස්තුවේ ආකෘතිය පෙළගැස්විය යුතුය - මෙය ද සාමූහික කාර්යයකි: අප සියල්ලන්ම එකට එකතු වී, අපගේ මොළය අවුල් කර මෙම ආකෘතිය සමඟ පැමිණිය යුතුය.

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

මෙය පැක්-මෑන් ක්‍රීඩාව තරමක් සිහිගන්වයි - කෞතුක වස්තුව යම් ආකාරයක කතාවක් හරහා ගමන් කරයි. ඒ අතරම, කේතය ඇත්ත වශයෙන්ම කතාව හරහා යන්නේද යන්න සහ එය කෙසේ හෝ ඔබේ නිෂ්පාදනයට සම්බන්ධද යන්න පාලනය කිරීම වැදගත් වේ. නිෂ්පාදනයේ කතන්දර අඛණ්ඩ බෙදා හැරීමේ ක්‍රියාවලියට ඇදගෙන යා හැකිය: යමක් වැටුණු විට එය මේ ආකාරයට විය, දැන් අපි මෙම දර්ශනය පද්ධතිය තුළ වැඩසටහන්ගත කරමු. සෑම අවස්ථාවකදීම කේතය මෙම අවස්ථාව හරහා ද යන අතර, ඊළඟ වතාවේ ඔබට මෙම ගැටලුවට මුහුණ දීමට සිදු නොවනු ඇත. එය ඔබේ සේවාදායකයා වෙත ළඟා වීමට වඩා බොහෝ කලකට පෙර ඔබ එය සොයා ගනු ඇත.

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

"නොකඩවා බෙදා හැරීම" මේ වගේ.

බෙදා හැරීමේ ක්‍රියාවලිය Dev, CI, Test, PreProd, Prod යනු වෙනම පරිසරයක් නොවේ, මේවා ඔබේ පුරාවස්තුව ගමන් කරන ගිනි ආරක්ෂණ මුදල් සහිත අදියර හෝ ස්ථාන වේ.

ඔබට මූලික සේවා APP ලෙස විස්තර කර ඇති යටිතල පහසුකම් කේතය තිබේ නම් එය උපකාරී වේ සියලුම scripts අමතක කරන්න එපා, සහ මෙම කෞතුක වස්තුව සඳහා කේතය ලෙස ඒවා ලියන්න, පුරාවස්තු ප්රවර්ධනය කරන්න ඔබ යන විට එය වෙනස් කරන්න.

ස්වයං පරීක්ෂණ ප්රශ්න

විශේෂාංග විස්තරයේ සිට 95% ක්ම නිෂ්පාදනයට මුදා හැරීමට ගතවන කාලය සතියකට වඩා අඩුද? නල මාර්ගයේ සෑම අදියරකදීම කෞතුක වස්තුවේ ගුණාත්මකභාවය වැඩි දියුණු වේද? ඒක හරහා යන කතාවක් තියෙනවද? ඔබ විවිධ යෙදවීමේ උපාය මාර්ග භාවිතා කරනවාද?

සියලුම පිළිතුරු ඔව් නම්, ඔබ ඇදහිය නොහැකි තරම් සිසිල් ය! අදහස් දැක්වීමේදී ඔබේ පිළිතුරු ලියන්න - මම සතුටු වනු ඇත).

Обратная связь

මෙය සියල්ලටම වඩා දුෂ්කරම පුරුද්දයි. DevOpsConf සම්මන්ත්‍රණයේදී, Infobip හි සගයෙක්, ඒ ගැන කතා කරමින්, ඔහුගේ වචන වලින් ටිකක් ව්‍යාකූල විය, මන්ද මෙය සැබවින්ම ඔබ සියල්ල නිරීක්ෂණය කළ යුතු බව පිළිබඳ ඉතා සංකීර්ණ භාවිතයකි!

නිදසුනක් වශයෙන්, බොහෝ කලකට පෙර, මම Qik හි වැඩ කළ විට සහ අපි සියල්ල නිරීක්ෂණය කිරීමට අවශ්ය බව අපට වැටහුණා. අපි මෙය කළ අතර, දැන් අපි Zabbix හි අයිතම 150 ක් ඇති අතර, ඒවා නිරන්තරයෙන් නිරීක්ෂණය කරනු ලැබේ. එය බියජනකයි, තාක්ෂණික අධ්‍යක්ෂවරයා ඔහුගේ පන්සල දෙසට ඇඟිල්ල දිගු කළේය:

- යාලුවනේ, ඇයි ඔබ අපැහැදිලි දෙයක් සමඟ සේවාදායකය දූෂණය කරන්නේ?

නමුත් මෙය ඇත්තෙන්ම ඉතා සිසිල් උපාය මාර්ගයක් බව පෙන්නුම් කරන සිදුවීමක් සිදු විය.

එක් සේවාවක් නිරන්තරයෙන් බිඳ වැටීමට පටන් ගත්තේය. මුලදී, එය කඩා වැටුනේ නැත, එය සිත්ගන්නා සුළුය, කේතය එහි එකතු නොකළේය, එය මූලික තැරැව්කරුවකු වූ නිසා, ප්රායෝගිකව කිසිදු ව්යාපාරික ක්රියාකාරිත්වයක් නොතිබුණි - එය හුදෙක් තනි තනි සේවාවන් අතර පණිවිඩ යවා ඇත. මෙම සේවාව මාස 4 ක් සඳහා වෙනස් නොවූ අතර හදිසියේම එය "ඛණ්ඩනය කිරීමේ දෝෂය" දෝෂය සමඟ කඩා වැටීමට පටන් ගත්තේය.

අපි කම්පනයට පත් වී, Zabbix හි අපගේ ප්‍රස්ථාර විවෘත කළ අතර, සති එකහමාරකට පෙර, මෙම තැරැව්කරු භාවිතා කරන API සේවාවේ ඉල්ලීම්වල හැසිරීම විශාල වශයෙන් වෙනස් වූ බව පෙනී ගියේය. ඊළඟට අපි දැක්කා යම් ආකාරයක පණිවිඩයක් යැවීමේ වාර ගණන වෙනස් වී ඇති බව. පස්සේ තමයි දැනගත්තේ මේ අය android clients කියලා. අපි ඇහුවා:

- යාලුවනේ, සති එකහමාරකට පෙර ඔබට සිදු වූයේ කුමක්ද?

ප්‍රතිචාර වශයෙන්, ඔවුන් UI නැවත සැලසුම් කළ ආකාරය පිළිබඳ රසවත් කතාවක් අපට අසන්නට ලැබුණි. ඔවුන් HTTP පුස්තකාලය වෙනස් කළ බව කිසිවෙකු වහාම කියනු ඇතැයි සිතිය නොහැක. ඇන්ඩ්‍රොයිඩ් සේවාලාභීන් සඳහා, එය නාන කාමරයේ සබන් මාරු කිරීම වැනි ය - ඔවුන්ට මතක නැත. එහි ප්‍රතිඵලයක් වශයෙන්, විනාඩි 40 ක සංවාදයකින් පසු, ඔවුන් HTTP පුස්තකාලය වෙනස් කර ඇති බවත්, එහි පෙරනිමි කාල වකවානු වෙනස් වී ඇති බවත් අපි සොයා ගත්තෙමු. මෙය API සේවාදායකයේ රථවාහන හැසිරීම වෙනස් කිරීමට හේතු වූ අතර, එය තැරැව්කරු තුළ තරඟයක් ඇති කළ තත්වයක් ඇති වූ අතර එය බිඳ වැටීමට පටන් ගත්තේය.

ගැඹුරු අධීක්ෂණයකින් තොරව මෙය විවෘත කිරීම සාමාන්‍යයෙන් කළ නොහැක්කකි. සංවිධානයට තවමත් "ළිං" පිළිබඳ ගැටළුවක් තිබේ නම්, සෑම කෙනෙකුම එකිනෙකාට මුදල් විසි කරන විට, මෙය වසර ගණනාවක් ජීවත් විය හැකිය. ගැටළුව විසඳීමට නොහැකි නිසා ඔබ සේවාදායකය නැවත ආරම්භ කරන්න. ඔබ සතුව ඇති සියලුම සිදුවීම් ඔබ නිරීක්ෂණය කරන විට, ලුහුබැඳීම, නිරීක්ෂණය කිරීම සහ අධීක්ෂණය කිරීම පරීක්ෂණයක් ලෙස භාවිතා කරන විට - කේතය ලියන්න සහ එය නිරීක්ෂණය කරන්නේ කෙසේදැයි වහාම සඳහන් කරන විට, කේතයේ ස්වරූපයෙන් (අපට දැනටමත් යටිතල පහසුකම් කේතයක් ලෙස ඇත), සියල්ල පැහැදිලි වන්නේ කෙසේද? අත්ල මත. එවැනි සංකීර්ණ ගැටළු පවා පහසුවෙන් නිරීක්ෂණය කළ හැකිය.

නිෂ්පාදනයේදී නොව බෙදා හැරීමේ ක්‍රියාවලියේ එක් එක් අදියරේදී කෞතුක වස්තුවට සිදුවන දේ පිළිබඳ සියලු තොරතුරු රැස් කරන්න.

අධීක්ෂණය CI වෙත උඩුගත කරන්න, සමහර මූලික දේවල් දැනටමත් එහි දෘශ්‍යමාන වනු ඇත. පසුව ඔබ ඒවා Test, PredProd සහ load testing තුළ දකිනු ඇත. ප්‍රමිතික, සංඛ්‍යාලේඛන පමණක් නොව ලඝු-සටහන් ද සෑම අදියරකදීම තොරතුරු රැස් කරන්න: යෙදුම ක්‍රියාත්මක වූ ආකාරය, විෂමතා - සියල්ල එකතු කරන්න.

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

ස්වයං පාලනය සඳහා ප්රශ්න

ඔබේ නිරීක්ෂණ සහ ලොග් කිරීම ඔබ සඳහා සංවර්ධන මෙවලමද? කේතය ලිවීමේදී, ඔබ ඇතුළු ඔබේ සංවර්ධකයින් එය නිරීක්ෂණය කරන්නේ කෙසේදැයි සිතන්නේද?

පාරිභෝගිකයන්ගෙන් ගැටලු ගැන ඔබට ඇසෙනවාද? ඔබ අධීක්‍ෂණයෙන් සහ ලොග් වීමෙන් සේවාදායකයා වඩා හොඳින් තේරුම් ගන්නවාද? නිරීක්‍ෂණයෙන් සහ ලොග් වීමෙන් ඔබ පද්ධතිය වඩා හොඳින් තේරුම් ගන්නවාද? සිස්ටම් එකේ ට්‍රෙන්ඩ් එක වැඩි වෙනව දැකල තව සති 3කින් ඔක්කොම මැරෙනව කියල තේරුන නිසා සිස්ටම් එක වෙනස් කරනවද?

ඔබ මෙම සංරචක තුන ලබා ගත් පසු, ඔබට ඔබේ සමාගම තුළ කුමන ආකාරයේ යටිතල පහසුකම් වේදිකාවක් තිබේදැයි සිතා බැලිය හැකිය.

යටිතල පහසුකම් වේදිකාව

කාරණය එය සෑම සමාගමකටම ඇති අසමාන මෙවලම් කට්ටලයක් නොවේ.

යටිතල පහසුකම් වේදිකාවක කාරණය නම් සියලුම කණ්ඩායම් මෙම මෙවලම් භාවිතා කර ඒවා එකට සංවර්ධනය කිරීමයි.

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

සියලුම කණ්ඩායම් යටිතල පහසුකම් වේදිකාව සංවර්ධනය කර එය ඔවුන්ගේම IDE ලෙස සලකයි. ඔබගේ IDE හි ඔබ සෑම දෙයක්ම ලස්සනට සහ වේගවත් කිරීමට විවිධ ප්ලගීන ස්ථාපනය කරයි, සහ හොට්කී වින්‍යාස කරන්න. ඔබ Sublime, Atom හෝ Visual Studio කේතය විවෘත කරන විට, කේත දෝෂ ගලා එන අතර එය කිසිසේත් වැඩ කළ නොහැකි බව ඔබට වැටහේ, ඔබට වහාම දුක දැනෙන අතර ඔබ ඔබේ IDE නිවැරදි කිරීමට දිව යයි.

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

යටිතල පහසුකම් වේදිකාව නිරන්තරයෙන් ගුණාත්මක භාවය වැඩිදියුණු කිරීමත් සමඟ කෞතුක වස්තුව සංවර්ධනයේ සිට සේවාදායකයා වෙත මාරු කිරීම සහතික කරයි.. නිෂ්පාදනයේදී කේතයට සිදුවන කථා මාලාවක් සමඟ IP වැඩසටහන්ගත කර ඇත. සංවර්ධනයේ වසර ගණනාවක් පුරා, මෙම කථා රාශියක් ඇත, ඒවායින් සමහරක් අද්විතීය වන අතර ඔබට පමණක් සම්බන්ධ වේ - ඒවා ගූගල් කළ නොහැක.

මෙම අවස්ථාවේදී, යටිතල පහසුකම් වේදිකාව ඔබේ තරඟකාරී වාසිය බවට පත්වේ, එය තරඟකරුගේ මෙවලමෙහි නොමැති යමක් ගොඩනගා ඇති බැවිනි. ඔබේ IP ගැඹුරු වන තරමට, Time-to-market අනුව ඔබේ තරඟකාරී වාසිය වැඩි වේ. මෙහි දිස්වේ විකුණුම්කරු අගුලු දැමීමේ ගැටලුව: ඔබට වෙනත් කෙනෙකුගේ වේදිකාවක් ගත හැකිය, නමුත් වෙනත් කෙනෙකුගේ අත්දැකීම් භාවිතා කිරීමෙන්, එය ඔබට කොතරම් අදාළදැයි ඔබට වැටහෙන්නේ නැත. ඔව්, සෑම සමාගමකටම Amazon වැනි වේදිකාවක් ගොඩනගා ගත නොහැක. මෙය දුෂ්කර රේඛාවක් වන අතර එහිදී සමාගමේ අත්දැකීම් වෙළඳපොලේ එහි ස්ථානයට අදාළ වන අතර ඔබට එහි විකුණුම් අගුලක් භාවිතා කළ නොහැක. මෙයද සිතීම වැදගත්ය.

යෝජනා ක්රමය

මෙය DevOps සමාගමක සියලු පරිචයන් සහ ක්‍රියාවලි සැකසීමට ඔබට උපකාර වන යටිතල පහසුකම් වේදිකාවක මූලික රූප සටහනකි.

එය සමන්විත වන්නේ කුමක් දැයි බලමු.

සම්පත් වාද්‍ය වෘන්ද පද්ධතිය, එය යෙදුම් සහ අනෙකුත් සේවාවන් සඳහා CPU, මතකය, තැටිය සපයයි. මේ මත - පහළ මට්ටමේ සේවා: අධීක්ෂණය, ලොග් කිරීම, CI/CD එන්ජිම, පුරාවස්තු ගබඩා කිරීම, පද්ධති කේතය ලෙස යටිතල පහසුකම්.

ඉහළ මට්ටමේ සේවා: දත්ත සමුදාය සේවාවක් ලෙස, පෝලිම්, සේවාවක් ලෙස ශේෂය පැටවීම, සේවාවක් ලෙස රූප ප්‍රමාණය වෙනස් කිරීම, සේවාවක් ලෙස විශාල දත්ත කර්මාන්ත ශාලාව. මේ මත - ඔබේ සේවාදායකයාට නිරන්තරයෙන් වෙනස් කරන ලද කේතය ලබා දෙන නල මාර්ගය.

ඔබේ මෘදුකාංගය සේවාලාභියා සඳහා ක්‍රියා කරන ආකාරය පිළිබඳ තොරතුරු ඔබට ලැබෙනු ඇත, එය වෙනස් කරන්න, නැවත මෙම කේතය සැපයීම, තොරතුරු ලබා ගන්න - ඒ නිසා ඔබ යටිතල පහසුකම් වේදිකාව සහ ඔබේ මෘදුකාංගය යන දෙකම නිරන්තරයෙන් සංවර්ධනය කරයි.

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

වේදිකාවේ සෑම කොටසක්ම කථාවක් ගෙන යන බව වටහා ගැනීම වැදගත් වන අතර, මෙම ගඩොල් රැගෙන යන්නේ කුමන කථාවදැයි ඔබෙන්ම අසන්න, සමහර විට එය ඉවතට විසි කර තෙවන පාර්ශවීය සේවාවක් සමඟ ප්රතිස්ථාපනය කළ යුතුය. උදාහරණයක් ලෙස, ගඩොල් වෙනුවට Okmeter ස්ථාපනය කළ හැකිද? සමහර විට පිරිමි ළමයින් දැනටමත් අපට වඩා මෙම විශේෂ ise දැනුම වර්ධනය කර ගෙන ඇත. නමුත් සමහර විට එසේ නොවේ - සමහර විට අපට අද්විතීය විශේෂඥතාවයක් ඇත, අපි Prometheus ස්ථාපනය කර එය තවදුරටත් සංවර්ධනය කළ යුතුය.

වේදිකාව නිර්මාණය කිරීම

මෙය සංකීර්ණ සන්නිවේදන ක්‍රියාවලියකි. ඔබට මූලික පරිචයන් ඇති විට, ඔබ අවශ්‍යතා සහ ප්‍රමිතීන් වර්ධනය කරන විවිධ ඉංජිනේරුවන් සහ විශේෂඥයින් අතර සන්නිවේදනය ආරම්භ කරන අතර ඒවා විවිධ මෙවලම් සහ ප්‍රවේශයන් වෙත නිරන්තරයෙන් වෙනස් කරයි. DevOps වල අපිට තියෙන සංස්කෘතිය මෙතනදි වැදගත්.

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

මොනවද ඔබට තියෙන්නේ?

නැවතත්, ඔබට ඔබෙන්ම ඇසිය හැකි ප්රශ්න.

යටිතල පහසුකම් වේදිකාව කැපවී තිබේද? එහි සංවර්ධනයට වගකිව යුත්තේ කවුද? ඔබේ යටිතල පහසුකම් වේදිකාවේ තරඟකාරී වාසි ඔබට වැටහෙනවාද?

මෙම ප්‍රශ්න ඔබගෙන්ම නිතරම අසාගත යුතුය. තෙවන පාර්ශවීය සේවාවන් වෙත යමක් මාරු කළ හැකි නම්, එය මාරු කළ යුතුය; තෙවන පාර්ශවීය සේවාවක් ඔබේ චලනය අවහිර කිරීමට පටන් ගන්නේ නම්, ඔබ තුළම පද්ධතියක් ගොඩනගා ගත යුතුය.

ඉතින්, DevOps...

... මෙය සංකීර්ණ පද්ධතියකි, එයට තිබිය යුත්තේ:

• ඩිජිටල් නිෂ්පාදනය.
• මෙම ඩිජිටල් නිෂ්පාදනය දියුණු කරන ව්‍යාපාරික මොඩියුල.
• කේතය ලියන නිෂ්පාදන කණ්ඩායම්.
• අඛණ්ඩ බෙදාහැරීමේ පිළිවෙත්.
• සේවාවක් ලෙස වේදිකා.
• සේවාවක් ලෙස යටිතල පහසුකම්.
• කේතය ලෙස යටිතල පහසුකම්.
• DevOps තුළ ගොඩනගා ඇති විශ්වසනීයත්වය පවත්වා ගැනීම සඳහා වෙනම භාවිතයන්.
• ඒ සියල්ල විස්තර කරන ප්‍රතිපෝෂණ පුහුණුවක්.

ඔබට මෙම රූප සටහන භාවිතා කළ හැකිය, ඔබ දැනටමත් ඔබේ සමාගම තුළ ඇති දේ යම් ආකාරයකින් ඉස්මතු කර පෙන්වයි: එය සංවර්ධනය කර තිබේද නැතහොත් තවමත් සංවර්ධනය කිරීමට අවශ්‍ය වේ.

සති දෙකකින් ඒක ඉවරයි DevOpsConf 2019. RIT++ හි කොටසක් ලෙස. සම්මන්ත්‍රණයට පැමිණෙන්න, එහිදී ඔබට අඛණ්ඩ බෙදාහැරීම, කේතය ලෙස යටිතල පහසුකම් සහ DevOps පරිවර්තනය පිළිබඳ බොහෝ රසවත් වාර්තා සොයාගත හැකිය. ඔබේ ටිකට්පත් වෙන්කරවා ගන්න, අවසාන මිල අවසන් දිනය මැයි 20 වේ

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