මම මෑතකදී Logrocon විසින් සත්කාරකත්වය සපයන ලද DevOpsForum 2019 සඳහා සහභාගී විය. මෙම සම්මන්ත්‍රණයේදී, ව්‍යාපාර සහ සංවර්ධන සහ තොරතුරු තාක්ෂණ සේවා විශේෂඥයින් අතර ඵලදායී අන්තර්ක්‍රියා සඳහා විසඳුම් සහ නව මෙවලම් සෙවීමට සහභාගිවන්නන් උත්සාහ කළහ.
සම්මන්ත්‍රණය සාර්ථක විය: ඇත්ත වශයෙන්ම ප්‍රයෝජනවත් වාර්තා රාශියක්, රසවත් ඉදිරිපත් කිරීම් ආකෘති සහ කථිකයන් සමඟ බොහෝ සන්නිවේදනයන් තිබුණි. විශාල සම්මන්ත්‍රණවල කථිකයන් මෑතකදී වැරදිකරුවන් වූ දෙයක් කිසිවෙකු මට කිසිවක් විකිණීමට උත්සාහ නොකිරීම විශේෂයෙන් වැදගත් වේ.
Raiffeisenbank, Alfastrakhovanie, Mango Telecom හි ස්වයංක්‍රීයකරණය ක්රියාත්මක කිරීමේ අත්දැකීම් සහ කප්පාදුව යටතේ අනෙකුත් විස්තර වල කථා වලින් උපුටා ගැනීමකි.
මගේ නම යනා, මම පරීක්ෂකයෙකු ලෙස වැඩ කරමි, මම ස්වයංක්‍රීයකරණය මෙන්ම DevOps ද කරමි, මම සම්මන්ත්රණ සහ රැස්වීම්වලට යාමට ප්‍රිය කරමි. පසුගිය වසර දෙක තුළ, මම Oleg Bunin ගේ සම්මන්ත්රණ (HighLoad++, TeamLead Conf), Jug events (Heisenbug, JPoint), TestCon මොස්කව්, DevOps Pro මොස්කව්, බිග් ඩේටා මොස්කව් වෙත ගොස් ඇත.
පළමුවෙන්ම, මම සම්මන්ත්රණ වැඩසටහන කෙරෙහි අවධානය යොමු කරමි. මම වාර්තාව කුමක් ගැනද යන්න ගැන අඩුවෙන් බලන අතර කථිකයා දෙස වැඩිපුර බලන්නෙමි. වාර්තාව ඉතා තාක්‍ෂණික සහ සිත්ගන්නාසුළු එකක් වුවද, ඔබේ සමාගම තුළ වාර්තාවෙන් හොඳම භාවිතයන් කිහිපයක් අදාළ කර ගැනීමට ඔබට හැකි වනු ඇති බව සත්‍යයක් නොවේ. එවිට ඔබට ස්පීකරයක් අවශ්ය වේ.
Raiffeisenbank හි නල මාර්ගයේ අවසානයේ ආලෝකය
සාමාන්යයෙන්, මම මට උනන්දුවක් දක්වන පැත්තක කථිකයන් දඩයම් කරමි. DevOpsForum 2019 හිදී, Raiffeisenbank හි කථිකයෙකු වන Mikhail Bizhan, මගේ උනන්දුව ඇති කළේය. ඔහුගේ කතාව අතරතුර, ඔවුන් ක්‍රමක්‍රමයෙන් ඔවුන්ගේ කණ්ඩායම් DevOps වෙත සම්බන්ධ කර ගන්නේ කෙසේද, ඔවුන්ට එය අවශ්ය වන්නේ ඇයි සහ DevOps පරිවර්තනය පිළිබඳ අදහස ව්‍යාපාරයට විකුණන්නේ කෙසේද යන්න ගැන කතා කළේය. හොඳයි, පොදුවේ, මම නල මාර්ගයේ අවසානයේ ආලෝකය දකින්නේ කෙසේද යන්න ගැන කතා කළා.
Mikhail Bizhan, Raiffeisenbank හි ස්වයංක්‍රීයකරණ අධ්‍යක්ෂ
දැන් ඔවුන්ගේ සමාගම තුළ "DevOps" නැත. එනම්, ඔහු වැඩ කරයි, නමුත් සියලු කණ්ඩායම් තුළ නොවේ. DevOps ක්‍රියාවට නංවන විට, ඔවුන් නිශ්චිත ඉංජිනේරුවන් අනුව සහ නිෂ්පාදනයේ අවශ්‍යතාවය සහ මෙම නිෂ්පාදනය ගොඩනගා ඇති වේදිකාවේ පරිණතභාවය යන දෙකෙහිම කණ්ඩායම්වල සූදානම මත රඳා පවතී. DevOps අවශ්ය වන්නේ මන්දැයි ව්‍යාපාරයකට පැහැදිලි කරන්නේ කෙසේදැයි මීෂා පැවසුවාය.
බැංකු අංශයට වර්ධන ධාවක කිහිපයක් ඇත: සේවා පිරිවැය සහ සේවාදායක පදනම පුළුල් කිරීම. සේවා පිරිවැය වැඩි කිරීම ඉතා හොඳ ධාවකයක් නොවේ, නමුත් සේවාදායක පදනම වර්ධනය කිරීම ප්රතිවිරුද්ධයයි. තරඟකරුවන් වෛෂයිකව සිසිල් නිෂ්පාදනයක් නිකුත් කරන්නේ නම්, සියලුම ගනුදෙනුකරුවන් එහි යයි, පසුව කාලයත් සමඟ වෙළඳපල මට්ටම් අඩු වේ. එබැවින්, නව නිෂ්පාදන වෙළඳපොළට හඳුන්වා දීම සහ ඒවා හඳුන්වාදීමේ වේගය බැංකු අවධානය යොමු කරන ප්රධානතම දෙය වේ. මෙය හරියටම DevOps සඳහා වන අතර ව්‍යාපාර මෙය තේරුම් ගනී.
ඊළඟ වැදගත් සටහන: DevOps සෑම විටම වෙළඳපොළට කාලය අඩු නොකරයි. DevOps වලට තනිවම ක්‍රියා කළ නොහැක, එය නිෂ්පාදනයක් සංවර්ධනයේ සිට නිෂ්පාදනය දක්වා (කේතයේ සිට පාරිභෝගිකයා දක්වා) නිර්මාණය කර වෙළඳපොළට ගෙන ඒමේ ක්‍රියාවලියේ කොටසක් පමණි. නමුත් කේතයට පෙර සෑම දෙයක්ම DevOps වලට කෙලින්ම සම්බන්ධ නොවේ. එනම්, අලෙවිකරුවන්ට වසර ගණනාවක් වෙළඳපල අධ්‍යයනය කළ හැකි අතර තරඟකරුවන් සමඟ ඔවුන්ගේ මුළු ජීවිතයම ගත කළ හැකිය. සේවාදායකයාට අවශ්ය දේ ඉක්මනින් අවබෝධ කර ගැනීම සහ මෙම හෝ එම අංගය ක්රියාත්මක කිරීම සැලසුම් කිරීම අවශ්ය වේ - බොහෝ විට මෙය DevOps සඳහා වැඩ කිරීමට සහ සමාගමට එහි ඉලක්කය සපුරා ගැනීමට ප්‍රමාණවත් නොවේ. එමනිසා, පළමුවෙන්ම, Raiffeisenbank ව්‍යාපාරය සමඟ එකඟ වූයේ DevOps භාවිතා කරන්නේ කෙසේදැයි ඉගෙන ගැනීම අවශ්ය බවයි. ස්වයංක්‍රීයකරණය සඳහා ස්වයංක්‍රීයකරණය නව පාරිභෝගිකයින් සඳහා වන සටනේදී බොහෝ සෙයින් උපකාරී නොවේ.
සාමාන්යයෙන්, DevOps ක්රියාත්මක කිරීමට අවශ්ය බව මීෂා විශ්වාස කරයි, නමුත් ඥානවන්තව. පරිවර්තනයේ ආරම්භයේ දී කණ්ඩායමේ ඵලදායිතාවය පහත වැටෙනු ඇත, එය අඩු මුදලක් උපයනු ඇත, නමුත් පසුව එය යුක්ති සහගත වනු ඇත යන කාරනය සඳහා අප සූදානම් විය යුතුය.
මැන්ගෝ ටෙලිකොම් හි පරීක්ෂණ ස්වයංක්‍රීයකරණය
පරීක්ෂකයෙකු ලෙස මට තවත් රසවත් වාර්තාවක් ලබා දුන්නේ Mango Telecom වෙතින් Egor Maslov විසිනි. ඉදිරිපත් කිරීම "SCRUM කණ්ඩායමක සම්පූර්ණ පරීක්ෂණ චක්‍රයේ ස්වයංක්‍රීයකරණය" ලෙස නම් කරන ලදී. Egor විශ්වාස කරන්නේ DevOps විශේෂයෙන් SCRUM සඳහා නිර්මාණය කර ඇති නමුත් ඒ සමඟම, SCRUM කණ්ඩායමකට DevOps හඳුන්වා දීම තරමක් ගැටළු සහගත බවයි. මෙය සිදු වන්නේ SCRUM කණ්ඩායම සෑම විටම කොහේ හරි ධාවනය වන නිසා, නවෝත්පාදනයන්ගෙන් අවධානය වෙනතකට යොමු කර ක්‍රියාවලිය නැවත ගොඩනඟා ගැනීමට කාලයක් නොමැති බැවිනි. ගැටලුව පවතින්නේ SCRUM කණ්ඩායමේ උප කණ්ඩායම් වෙන් කිරීම (පරීක්ෂණ කණ්ඩායම, සංවර්ධන කණ්ඩායම සහ යනාදිය) සම්බන්ධ නොවීමයි. හොඳයි, ඊට අමතරව, පවතින ක්‍රියාවලියක් ස්වයංක්‍රීය කිරීම සඳහා, ලේඛනගත කිරීම අවශ්ය වන අතර, SCRUM හි, බොහෝ විට සම්පුර්ණයෙන්ම ලියකියවිලි නොමැත - “නිෂ්පාදනය යම් ආකාරයක ලිවීමකට වඩා වැදගත් ය.”
SCRUM වෙත මාරු වීමෙන් පසුව, පරීක්ෂකයින් විශේෂාංග පරීක්ෂා කරන්නේ කෙසේද යන්න පිළිබඳව සංවර්ධකයින් සමඟ සාකච්ඡා කිරීමට පටන් ගත්හ. ක්‍රමයෙන්, ක්‍රියාකාරීත්වයේ පරිමාව වැඩි විය, ලියකියවිලි නොමැති අතර, පරීක්ෂණ මගින් ආවරණය නොවූ ක්‍රියාකාරීත්වයේ දෝෂ රාශියක් අල්ලා ගැනීමට පටන් ගත් අතර පොදුවේ එය පරීක්ෂා කළේ කවුරුන්ද සහ කවදාද යන්න තවදුරටත් පැහැදිලි නැත. කෙටියෙන් - ව්යාකූලත්වය සහ කම්පනයයි. පරීක්ෂණ ස්වයංක්‍රීයකරණයට මාරු වීමට අපි තීරණය කළෙමු. නමුත් ඒ වන විටත් සම්පූර්ණ අසාර්ථකත්වයක් ඇති විය. ඔවුන් අභ්‍යන්තර පරීක්ෂකයින් නොදන්නා තොගයක් මත ලියූ බාහිරින් ලබාගත් ස්වයංක්‍රීයකරණ විශේෂඥයින් කුලියට ගත්හ. ස්වයංක්‍රීය පරීක්ෂණ සඳහා රාමුව ක්රියාත්මක විය, ඇත්ත වශයෙන්ම, නමුත් බාහිරින් ලබා ගත් අය පිටත්ව ගිය පසු එය සති දෙකක් පැවතුනි. ඊළඟට ස්වයංක්‍රීය පරීක්ෂණ අංක දෙක හඳුන්වා දීමට උත්සාහ කළා. එය ආරම්භ වූයේ සෑම දෙයක්ම සමාගම තුළ, ඔබ විසින්ම (නිවැරදි දෛශිකය: අභ්‍යන්තරව විශේෂඥතාව ගොඩනගා ගැනීම), SCRUM රාමුව තුළ ගොඩනගා ගැනීම සහ ක්‍රියාවලිය තුළ ලේඛන නිර්මාණය කිරීම අවශ්ය වේ. ස්වයංක්‍රීයකරණය සඳහා වන තොගය නිෂ්පාදනයේ තොගයට සමාන විය යුතුය (මෙහි මම එය එකතු කරමි, වෙනත් කිසිවක් සමඟ ඔබේ ජාවාස්ක්‍රිප්ට් ව්යාපෘතිය පරීක්ෂා නොකරන්න). ස්ප්‍රින්ට් අවසානයේ, ඔවුන් මුළු කණ්ඩායම සමඟම ස්වයංක්‍රීය පරීක්ෂණය ක්‍රියා කරන ආකාරය පිළිබඳ ආදර්ශනයක් (ප්‍රයෝජනවත්). මේ අනුව, ස්වයංක්‍රීයකරණ ක්‍රියාවලියේ සියලුම කණ්ඩායම් සාමාජිකයින්ගේ සහභාගීත්වය වැඩි වූ අතර, ස්වයංක්‍රීය පරීක්ෂණ කෙරෙහි විශ්වාසය සහ මෙම ස්වයංක්‍රීය පරීක්ෂණය නියත වශයෙන්ම භාවිතා කිරීමට ඇති අවස්ථාව (සහ නිරන්තර අසාර්ථකත්වය හේතුවෙන් මාසයකදී අදහස් දැක්වීමක් සිදු නොවනු ඇත).
මාර්ගය වන විට, DevOpsForum 2019 හි විවෘත මයික්‍රෆෝනයක් තිබුණි - දිගු කලක් දන්නා සහ, මගේ මතය අනුව, ප්‍රයෝජනවත් කථන ආකෘතියකි. ඔබ මේ ආකාරයට ඇවිදිමින්, වාර්තාවලට සවන් දෙන්න, පසුව සම්මන්ත්‍රණයේදී යම් මාතෘකාවක් හෝ ගැටලුවක් සාකච්ඡා කිරීම වටී, ගැටලුව විසඳීමේදී අදාළ අත්දැකීම් බෙදාහදා ගැනීම වටී.
සංවිධායකයින් කෙටි වාර්තා ප්‍රවාහයක් සෑදූ බව ද මම දුටුවෙමි. සෑම වාර්තාවක්ම විනාඩි 10 කට වඩා වැඩි කාලයක් පවතී, පසුව ප්රශ්න. මේ ආකාරයෙන් ඔබට එකවර මාතෘකා බොහොමයක් ආවරණය කළ හැකි අතර ඔබට උනන්දුවක් දක්වන කථිකයන්ගෙන් ප්රශ්න ඇසීමට හැකිය.
ඉදිරිපත් කිරීම් අතර, මම සම්මන්ත්රණ හවුල්කරුවන්ගේ කුටි වටා ඇවිද ගොස් බොහෝ දේ සොරකම් කර/දිනුවා. අහ්, මම අත් පත්‍රිකාවට කැමතියි!
Alfastrakhovanie හි සංවර්ධන අධ්‍යක්ෂ සමග රවුම් මේසය සහ DevOps ගැටළු
DevOpsForum 2019 කේක් එකේ අයිසිං එක තමයි DevOps ප්‍රවීණයන් සමඟ පැයක පූර්ණ සැසිය. විවිධ කෝණවලින් DevOps දෙස බැලීමට සැසිවාර සහභාගිවන්නන් හතර දෙනෙකුට ආරාධනා කරන ලදී: Anton Isanin (Alfastrakhovanie, සංවර්ධන අධ්‍යක්ෂ), Nailya Zamashkina (Fintech Lab, මෙහෙයුම් අධ්‍යක්ෂ), Oleg Egorkin (Rostelecom, Agile coach) සහ Anton Martyanov (ස්වාධීන විශේෂඥ, DevOps දෙස බැලුවා. ව්යාපාරික දෘෂ්ටි කෝණයකින්).
ප්‍රවීණයන් මිනිසුන්ට සමීපව වාඩි වූ අතර පසුව දේවල් සිදු වීමට පටන් ගත්හ: මුළු පැයක්ම, ප්‍රේක්ෂකයන්ගෙන් සහභාගිවන්නන් ඔවුන්ගේ ප්රශ්න ඇසූ අතර ප්‍රවීණයන් රැප් ලබා ගත්හ. සමහර විට සැබෑ වාද විවාද ඇති විය. ප්රශ්න බෙහෙවින් වෙනස් විය, උදාහරණයක් ලෙස: DevOps ඉංජිනේරුවන් කිසිසේත් අවශ්‍යද, ඔවුන් පද්ධති පරිපාලකයින් ලෙස පුහුණු කළ නොහැක්කේ ඇයි, DevOps සෑම කෙනෙකුටම පිරිනැමිය යුතුද, එහි වටිනාකම කුමක්ද, සහ යනාදිය.
ඊට පස්සේ, මම ඇන්ටන් ඉසානින් සමඟ පෞද්ගලිකව කතා කළා. අපි DevOps සංස්කෘතිය සෑම නිවසකටම ගෙන ඒමේ අවශ්‍යතාවය ගැන සාකච්ඡා කළ අතර DevOps පරිවර්තනයේ අඳුරු පැත්ත හෙළිදරව් කළෙමු.
අපි හිතමු හැමෝම එකතු වෙලා DevOps නිෂ්පාදනයට සහ ව්‍යාපාරයට සහ කණ්ඩායමට අවශ්ය බව තීරණය කළා කියලා. අපි එය ක්රියාත්මක කිරීමට යමු. සියල්ල සාර්ථක විය. අපි හුස්ම පිට කළෙමු. DevOps අපව සේවාදායකයා වෙත සමීප කර ඇත, දැන් අපට ඔහුගේ සියලු පැතුම් ඉක්මනින් ඉටු කළ හැකිය. එහි ප්‍රතිඵලයක් වශයෙන්, දැඩි රෙගුලාසි සහ අවශ්‍යතා සහිත විශාල Ops දෙපාර්තමේන්තුවක් අප සතුව ඇති අතර, එය නිරන්තරයෙන් නිෂ්පාදනයේ අඩුපාඩු සොයාගෙන ඉල්ලීම් සමූහයක් නිර්මාණය කරයි. එපමනක් නොව, සේවාදායකයාට අනපේක්ෂිත ලෙස හරිත වෙනුවට බොත්තම කහ වර්ණ කිරීමට අවශ්ය වුවද, සියලු දෝෂ "හදිසි" තත්ත්වය පවරනු ලැබේ. ව්යාපෘතිය වර්ධනය වෙමින් පවතී, නිකුත් කිරීම් සංඛ්යාව වර්ධනය වන අතර, ඒ අනුව, සේවාදායකයින් විසින් නව ක්රියාකාරිත්වයේ දෝෂ සහ වැරදි වැටහීම් සංඛ්යාව. දෝෂ වාර්තා කිරීම සඳහා Ops තවත් පුද්ගලයින් 10 දෙනෙකු බඳවා ගන්නා අතර, ඒවා වසා දැමීම සඳහා සංවර්ධනය තවත් 15 දෙනෙකු බඳවා ගනී. නව විශේෂාංග හඳුන්වා දෙනවා වෙනුවට, කණ්ඩායම නිමක් නැති SD සමඟ ක්‍රියා කරයි, පරිශීලකයාට ක්‍රියාකාරීත්වය සහ ඒ සමඟම සහාය පැහැදිලි කරයි. එහි ප්‍රතිඵලයක් වශයෙන්, Ops සහ සංවර්ධන දෙකම ක්‍රියා කරයි, නමුත් සේවාලාභියා සහ ව්‍යාපාරය අසතුටට පත්ව ඇත: නව විශේෂාංග හිරවෙයි. DevOps පවතින බව පෙනේ, නමුත් එය පවතින බවක් නොපෙනේ.
DevOps ක්රියාත්මක කිරීමේ අවශ්‍යතාවය සම්බන්ධයෙන් ඇන්ටන් පැහැදිලිව ප්‍රකාශ කළේ මෙය ව්‍යාපාරයේ පරිමාණය මත කෙලින්ම රඳා පවතින බවයි. වසරකට එක් සේවාදායකයෙකුට සේවය කිරීමෙන් සමාගමට බිලියනයක් ලැබෙන්නේ නම්, DevOps අවශ්ය නොවේ (ඔබට මෙම සේවාදායකයාට නිතිපතා නව වෙනස්කම් කිරීමට අවශ්ය නොවේ නම්). සෑම දෙයක්ම චොකලට් වලින් ආවරණය වී ඇත. නමුත් ව්‍යාපාරය වර්ධනය වී වැඩි ගනුදෙනුකරුවන් පෙනී සිටින්නේ නම්, ඔබ එයට අනුකූල විය යුතුය. රීතියක් ලෙස, සමාගම තුළ මුලින් සිසිල් Ops නොමැත. පළමුව අපි නිෂ්පාදිතය කපා, පසුව පමණක් අපට වැටහෙන්නේ නිෂ්පාදිතය ක්‍රියා කිරීමට නම්, අපි සේවාදායකයන් කෙරෙහි අවධානයෙන් සිටිය යුතු අතර සැපයුම් අධීක්ෂණය කළ යුතු බවයි. එතකොට තමයි Ops හැදෙන්නේ. ඔප්ස්, වෙනම අංශයක් ලෙස, සංවර්ධනය සඳහා බාධක රාශියක් තැබීමට පටන් ගන්නා අතර සියලුම බෙදාහැරීම් ඇනහිටීමට පටන් ගන්නා බව තේරුම් ගත යුතුය. එනම්, මෙම අවස්ථාවේ දී, DevOps සංස්කෘතිය දැනටමත් අදාළ වේ, නමුත් එහි අඳුරු පැත්ත ගැන අප අමතක නොකළ යුතුය.
මූලාශ්රය: www.habr.com