"Devops ක්රියාත්මක කරන්නේ කෙසේද" යන ප්රශ්නය වසර ගණනාවක් පුරා පවතී, නමුත් බොහෝ හොඳ ද්රව්ය නොමැත. සමහර විට ඔබ කෙසේ වෙතත් තම කාලය විකුණා ගැනීමට අවශ්ය එතරම් බුද්ධිමත් නොවන උපදේශකයින්ගේ දැන්වීම් වලට ගොදුරු වේ. සමහර විට මේවා මෙගා කෝපරේෂන් නැව් විශ්වයේ විස්තාරය සීසාන ආකාරය පිළිබඳ නොපැහැදිලි, අතිශය සාමාන්‍ය වචන වේ. ප්රශ්නය පැනනගින්නේ: මෙය අපට වැදගත් වන්නේ කුමක්ද? හිතවත් කතුතුමනි, ඔබට ඔබේ අදහස් ලැයිස්තුවක් තුළ පැහැදිලිව සකස් කළ හැකිද?
මේ සියල්ල පැන නගින්නේ සමාගමේ සංස්කෘතියේ පරිවර්තනයන්හි ප්‍රති result ලය පිළිබඳ සැබෑ භාවිතය සහ අවබෝධය සමුච්චය වී නොමැති බැවිනි. සංස්කෘතියේ වෙනස්කම් දිගුකාලීන දේවල් වන අතර, එහි ප්රතිඵල සතියකින් හෝ මාසයකින් නොපෙනේ. වසර ගණනාවක් තිස්සේ සමාගම් ගොඩනඟා අසාර්ථක වූ ආකාරය දැකීමට තරම් වයසැති කෙනෙකු අපට අවශ්ය වේ.
ජෝන් විලිස් - DevOps හි එක් පියෙක්. ජෝන්ට සමාගම් විශාල සංඛ්‍යාවක් සමඟ වැඩ කිරීමේ දශක ගණනාවක අත්දැකීම් තිබේ. මෑතකදී, ජෝන් ඔවුන් සමඟ වැඩ කරන විට සිදු වන නිශ්චිත රටා දැකීමට පටන් ගත්තේය. මෙම පුරාවිද්‍යා භාවිතා කරමින්, ජෝන් DevOps පරිවර්තනයේ සැබෑ මාවතේ සමාගම්වලට මග පෙන්වයි. DevOops 2018 සම්මන්ත්‍රණයෙන් ඔහුගේ වාර්තාවේ පරිවර්තනයෙන් මෙම පුරාවිද්‍යා ගැන වැඩිදුර කියවන්න.
කථිකයා ගැන:
තොරතුරු තාක්ෂණ කළමනාකරණයේ වසර 35 කට වැඩි කාලයක්, Canonical හි OpenCloud හි පූර්වගාමියා නිර්මාණය කිරීමට සහභාගී වූ අතර, ආරම්භක 10 කට සහභාගී වූ අතර, ඉන් දෙකක් Dell සහ Docker වෙත විකුණන ලදී. දැනට ඔහු SJ Technologies හි DevOps සහ Digital Practices හි උප සභාපතිවරයා වේ.
ඊළඟට ජෝන්ගේ පැත්තෙන් කතාව.
මගේ නම ජෝන් විලිස් වන අතර මාව සොයා ගැනීමට පහසුම ස්ථානය ට්විටර් ය, . මට Gmail සහ GitHub මත එකම අන්වර්ථයක් ඇත. ඒ ඔබට මගේ වාර්තාවල වීඩියෝ පටිගත කිරීම් සහ ඒවා සඳහා ඉදිරිපත් කිරීම් සොයා ගත හැක.
විවිධ විශාල සමාගම්වල CIOs සමඟ මට බොහෝ රැස්වීම් තිබේ. DevOps යනු කුමක්දැයි ඔවුන්ට නොතේරෙන බවට ඔවුන් බොහෝ විට පැමිණිලි කරන අතර, එය ඔවුන්ට පැහැදිලි කිරීමට උත්සාහ කරන සෑම කෙනෙකුම වෙනස් දෙයක් ගැන කතා කරයි. තවත් පොදු පැමිණිල්ලක් නම්, අධ්යක්ෂවරුන් ඔවුන්ට පැහැදිලි කළ පරිදි සෑම දෙයක්ම කරන බව පෙනෙන්නට තිබුණත්, DevOps ක්රියා නොකරයි. අපි කතා කරන්නේ අවුරුදු සියයකට වඩා පැරණි විශාල සමාගම් ගැන ය. ඔවුන් සමඟ කතා කිරීමෙන් පසු, බොහෝ ගැටලු සඳහා වඩාත් සුදුසු වන්නේ උසස් තාක්‍ෂණය නොව සාපේක්ෂව අඩු තාක්ෂණික විසඳුම් බව මම නිගමනය කළෙමි. සති ගණනක් මම විවිධ දෙපාර්තමේන්තු වල අය සමඟ කතා කළා. පෝස්ට් එකේ පලවෙනි පින්තුරේ ඔයා දකින්නේ මගේ අන්තිම ප්‍රොජෙක්ට් එක, දවස් තුනක වැඩ වලින් පස්සේ කාමරේ පෙනුනේ මෙහෙමයි.
DevOps යනු කුමක්ද?
ඇත්ත වශයෙන්ම, ඔබ විවිධ පුද්ගලයින් 10 දෙනෙකුගෙන් ඇසුවහොත්, ඔවුන් විවිධ පිළිතුරු 10 ක් ලබා දෙනු ඇත. නමුත් මෙන්න සිත්ගන්නා කරුණ: මෙම පිළිතුරු දහයම නිවැරදි වනු ඇත. මෙහි වැරදි පිළිතුරක් නොමැත. මම වසර 10 ක් පමණ DevOps වෙත ඉතා ගැඹුරින් සිටි අතර පළමු DevOpsDay හි පළමු ඇමරිකානුවා විය. DevOps වලට සම්බන්ධ සෑම කෙනෙකුටම වඩා මම දක්ෂ බව මම නොකියමි, නමුත් ඒ සඳහා එතරම් උත්සාහයක් ගත් කිසිවෙක් නැති තරම්ය. මානව ප්‍රාග්ධනය සහ තාක්‍ෂණය එකට එකතු වූ විට DevOps ඇති වන බව මම විශ්වාස කරමි. විවිධ සංස්කෘතීන් ගැන අපි බොහෝ දේ කතා කළත් අපට බොහෝ විට මිනිස් මානය අමතක වේ.
දැන් අපට බොහෝ දත්ත තිබේ, වසර පහක ශාස්ත්‍රීය පර්යේෂණ, කාර්මික පරිමාණයෙන් න්‍යායන් පරීක්ෂා කිරීම. මෙම අධ්‍යයනයන් අපට පවසන දෙය නම්, ඔබ ආයතනික සංස්කෘතියක සමහර හැසිරීම් රටා ඒකාබද්ධ කළහොත්, ඔබට 2000x වේගයක් ලබා ගත හැකි බවයි. මෙම ත්වරණය ස්ථාවරත්වයේ සමාන දියුණුවකින් ගැලපේ. මෙය DevOps හට ඕනෑම සමාගමකට ලබා දිය හැකි ප්‍රතිලාභයේ ප්‍රමාණාත්මක මිනුමකි. මීට වසර කිහිපයකට පෙර, මම Fortune 5000 සමාගමක CEO ට DevOps ගැන කතා කළෙමි, මම ඉදිරිපත් කිරීමට සූදානම් වන විට, මගේ වසර ගණනාවක අත්දැකීම් විනාඩි 5 කින් සාරාංශ කිරීමට සිදු වූ නිසා මම බොහෝ කලබල වී සිටියෙමි.
අවසානයේ මම පහත දේ ලබා දුන්නා DevOps අර්ථ දැක්වීම: එය මානව ප්‍රාග්ධනය ඉහළ කාර්ය සාධනයක් සහිත ආයතනික ප්‍රාග්ධනය බවට පරිවර්තනය කිරීමට හැකි වන පරිචයන් සහ රටා සමූහයකි. Toyota සමාගම පසුගිය වසර 50ක් 60ක් තිස්සේ ක්රියාත්මක වූ ආකාරය උදාහරණයක්.
(මින් ඉදිරියට, එවැනි රූප සටහන් සපයනු ලබන්නේ යොමු ද්රව්ය ලෙස නොව, නිදර්ශන ලෙසය. ඒවායේ අන්තර්ගතය එක් එක් නව සමාගම සඳහා වෙනස් වේ. කෙසේ වෙතත්, පින්තූරය වෙන වෙනම බලා විශාල කර ගත හැක.
එවැනි වඩාත් සාර්ථක පිළිවෙත් වලින් එකකි වටිනා ධාරාව සිතියම්කරණය. මේ ගැන හොඳ පොත් කිහිපයක් ලියා ඇත, ඒවායින් වඩාත්ම සාර්ථක වන්නේ කැරන් මාටින් විසිනි. නමුත් පසුගිය වසර පුරාවටම, මෙම ප්රවේශය පවා ඉතා උසස් තාක්ෂණික බව මම නිගමනය කළෙමි. එය නිසැකවම බොහෝ වාසි ඇති අතර මම එය බොහෝ විට භාවිතා කර ඇත. නමුත් ප්රධාන විධායක නිලධාරියා තම සමාගමට නව රේල් පීලි වෙත මාරු විය නොහැක්කේ මන්දැයි ඔබෙන් විමසූ විට, අගය ප්‍රවාහ සිතියම්ගත කිරීම ගැන කතා කිරීමට ඉක්මන් වැඩිය. මුලින්ම පිළිතුරු දිය යුතු තවත් බොහෝ මූලික ප්‍රශ්න තිබේ.
මම හිතන්නේ මගේ බොහෝ සගයන් කරන වැරැද්ද නම් ඔවුන් සමාගමට කරුණු පහක මාර්ගෝපදේශයක් ලබා දී මාස හයකට පසු ආපසු පැමිණ සිදු වූ දේ බැලීමයි. අගය ප්‍රවාහ සිතියම්ගත කිරීම වැනි හොඳ යෝජනා ක්‍රමයක පවා අන්ධ ලප ඇති බව කියමු. විවිධ සමාගම්වල අධ්යක්ෂවරුන් සමඟ සම්මුඛ සාකච්ඡා සිය ගණනකින් පසු, මම ගැටලුව එහි සංරචක වලට බෙදීමට ඉඩ සලසන යම් රටාවක් සකස් කර ඇති අතර දැන් අපි මෙම එක් එක් සංරචක පිළිවෙලට සාකච්ඡා කරමු. ඕනෑම තාක්ෂණික විසඳුම් යෙදීමට පෙර, මම මෙම රටාව භාවිතා කරන අතර, ප්රතිඵලයක් වශයෙන්, මගේ සියලු බිත්ති රූප සටහන් වලින් ආවරණය වී ඇත. මෑතකදී මම අන්යොන්ය අරමුදලක් සමඟ වැඩ කරමින් සිටි අතර මම එවැනි යෝජනා ක්රම 100-150 ක් සමඟ අවසන් කළෙමි.
නරක සංස්කෘතිය උදේ ආහාරය සඳහා හොඳ ප්රවේශයන් අනුභව කරයි
ප්රධාන අදහස මෙයයි: සංවිධානයේ සංස්කෘතියම අයහපත් නම්, කෙට්ටු, කඩිසර, SAFE සහ DevOps කිසිදු උපකාරයක් නොවනු ඇත. එය හරියට ස්කූබා ආම්පන්න නොමැතිව ගැඹුරට කිමිදීම හෝ x-ray නොමැතිව ක්රියා කිරීම වැනි ය. වෙනත් වචන වලින් කිවහොත්, ඩ්‍රකර් සහ ඩෙමිං යන ව්‍යවහාරයට: නරක සංවිධානාත්මක සංස්කෘතියක් ඕනෑම හොඳ පද්ධතියක් හුස්ම හිර නොකර ගිල දමනු ඇත.
මෙම ප්රධාන ගැටළුව විසඳීම සඳහා, ඔබ පහත පියවර ගත යුතුය:
- සියලුම වැඩ දෘශ්යමාන කරන්න: ඔබ සියලු වැඩ දෘශ්යමාන කිරීමට අවශ්ය වේ. එය අනිවාර්යයෙන්ම යම් තිරයක පෙන්විය යුතුය යන අර්ථයෙන් නොව, එය නිරීක්ෂණය කළ යුතුය යන අර්ථයෙන්.
- ඒකාබද්ධ වැඩ කළමනාකරණ පද්ධති: කළමනාකරණ පද්ධති ඒකාබද්ධ කළ යුතුය. "ගෝත්‍රික" දැනුම සහ ආයතනික දැනුම පිළිබඳ ගැටලුවේ දී, අවස්ථා 9 න් 10 කදීම බාධකය වන්නේ මිනිසුන් ය. පොතේ ගැටලුව වූයේ ව්යාපෘතිය නියමිත කාලසටහනට වසර තුනක් ප්‍රමාද වීමට හේතු වූ බ්‍රෙන්ට් නම් තනි පුද්ගලයෙකි. ඒ වගේම මම හැමතැනම මේ "බ්‍රෙන්ට්" වලට දුවනවා. මෙම බාධක විසඳීමට, මම අපගේ ලැයිස්තුවේ ඊළඟ අයිතම දෙක භාවිතා කරමි.
- සීමා කිරීම් ක්‍රමවේදය පිළිබඳ න්යාය: සීමාවන් පිළිබඳ න්යාය.
- සහයෝගීතා හැක්: සහයෝගීතා හැක්.
- Toyota Kata (): මම Toyota Kata ගැන වැඩිය කතා කරන්නේ නැහැ. කැමති නම්, මගේ github මත මෙම සෑම මාතෘකාවක් මතම පාහේ.
- වෙළඳපල නැඹුරු සංවිධානය: වෙළඳපල ඉලක්ක කරගත් සංවිධානය.
- මාරු-වම් විගණක: චක්රයේ මුල් අවධියේදී විගණනය.
මම ඉතා සරලව සංවිධානයක් සමඟ වැඩ කිරීමට පටන් ගනිමි: මම සමාගමට ගොස් සේවකයින් සමඟ කතා කරමි. ඔබට පෙනෙන පරිදි, උසස් තාක්ෂණයක් නොමැත. ඔබට අවශ්ය වන්නේ ලිවීමට යමක් පමණි. මම කණ්ඩායම් කිහිපයක් එක් කාමරයකට රැස් කර මගේ පුරාවිද්‍යා 7 හි ඉදිරිදර්ශනයෙන් ඔවුන් මට පවසන දේ විශ්ලේෂණය කරමි. ඊට පස්සේ මම එයාලටම මාර්කර් එකක් දීලා කියනවා, එයාලා මෙච්චරකල් හයියෙන් කියපු හැම දෙයක්ම බෝඩ් එකේ ලියන්න කියලා. සාමාන්යයෙන් මෙම ආකාරයේ රැස්වීම් වලදී සෑම දෙයක්ම ලියා ඇති එක් පුද්ගලයෙකු සිටින අතර, හොඳම ලෙස ඔහු සාකච්ඡාවෙන් 10% ක් ලිවිය හැකිය. මගේ ක්‍රමය සමඟ, මෙම අගය 40% දක්වා ඉහළ නැංවිය හැකිය.
(මෙම නිදර්ශනය වෙන වෙනම බැලිය හැක )
මගේ ප්රවේශය විලියම් ෂ්නයිඩර්ගේ කෘතිය මත පදනම් වේ. ) ප්රවේශය පදනම් වන්නේ ඕනෑම සංවිධානයක් වර්ග හතරකට බෙදිය හැකිය යන අදහස මතය. මට මෙම යෝජනා ක්‍රමය සාමාන්යයෙන් සංවිධානයක් විශ්ලේෂණය කිරීමේදී පැන නගින වෙනත් යෝජනා ක්රම සිය ගණනක් සමඟ වැඩ කිරීමේ ප්‍රතිඵලයකි. අපට ඉහළ මට්ටමේ පාලනයක් ඇති නමුත් අඩු නිපුණතාවයක් ඇති සංවිධානයක් ඇතැයි සිතමු. මෙය අතිශයින්ම නුසුදුසු විකල්පයකි: සෑම කෙනෙකුම රේඛාවට ඇදී යන විට, නමුත් කුමක් කළ යුතු දැයි කිසිවෙකු දන්නේ නැත.
තරමක් හොඳ විකල්පයක් වන්නේ පාලනය සහ නිපුණතාවය යන දෙකෙහිම ඉහළ මට්ටමේ එකක්. එවැනි සමාගමක් ලාභදායී නම්, සමහර විට එයට DevOps අවශ්ය නොවේ. ඉහළ මට්ටමේ පාලනයක්, අඩු නිපුණතාවයක් සහ සහයෝගීතාවයක් ඇති සමාගමක් සමඟ වැඩ කිරීම වඩාත් සිත්ගන්නා සුළුය, නමුත් ඒ සමඟම ඉහළ මට්ටමේ සංස්කෘතියක් (වගා කිරීම). මෙයින් අදහස් කරන්නේ සමාගම එහි වැඩ කිරීමට කැමති බොහෝ දෙනෙක් සිටින අතර ශ්රම පිරිවැටුම අඩු බවයි.
(මෙම නිදර්ශනය වෙන වෙනම බැලිය හැක )
දෘඩ මාර්ගෝපදේශ සහිත ක්රම සත්‍යය සාක්ෂාත් කර ගැනීමට බාධා කරන බව මට පෙනේ. විශේෂයෙන් අගය ප්‍රවාහ සිතියම්ගත කිරීමේදී, තොරතුරු ව්‍යුහගත කළ යුතු ආකාරය සම්බන්ධයෙන් බොහෝ නීති තිබේ. මම දැන් කතා කරන වැඩවල මුල් අවධියේදී, කිසිවෙකුට මෙම නීති අවශ්ය නොවේ. ඔහුගේ අතේ සලකුණක් ඇති පුද්ගලයෙකු පුවරුවේ සමාගමේ සැබෑ තත්වය විස්තර කරන්නේ නම්, තත්වය තේරුම් ගැනීමට හොඳම ක්‍රමය මෙයයි. එවැනි තොරතුරු අධ්යක්ෂවරුන් වෙත ළඟා නොවේ. මේ මොහොතේ, පුද්ගලයාට බාධා කර ඔහු යම් ආකාරයක ඊතලයක් වැරදියට ඇද දැමූ බව පැවසීම මෝඩකමකි. මෙම අදියරේදී, සරල නීති භාවිතා කිරීම වඩා හොඳය, උදාහරණයක් ලෙස: බහු-වර්ණ සලකුණු භාවිතා කිරීමෙන් බහු මට්ටමේ වියුක්තකරණය සරලව නිර්මාණය කළ හැකිය.
මම නැවත නැවතත්, උසස් තාක්ෂණයක් නැත. කළු සලකුණ සෑම දෙයක්ම ක්රියාත්මක වන ආකාරය පිළිබඳ වෛෂයික යථාර්ථය නිරූපණය කරයි. රතු සලකුණක් සමඟ, මිනිසුන් වත්මන් තත්වය ගැන ඔවුන් අකමැති දේ සලකුණු කරයි. මා නොව ඔවුන් මෙය ලිවීම වැදගත් ය. රැස්වීමකින් පසු මම CIO වෙත ගිය විට, මම නිවැරදි කළ යුතු දේවල් 10 ලැයිස්තුවක් ඉදිරිපත් නොකරමි. සමාගමේ පුද්ගලයන් පවසන දේ සහ පවතින ඔප්පු කළ රටා අතර සම්බන්ධතා සොයා ගැනීමට මම උත්සාහ කරමි. අවසාන වශයෙන්, නිල් සලකුණක් ගැටලුවට විසඳුම් යෝජනා කරයි.
(මෙම නිදර්ශනය වෙන වෙනම බැලිය හැක )
මෙම ප්රවේශයේ උදාහරණයක් දැන් ඉහත නිරූපණය කර ඇත. මේ අවුරුද්දේ මුල මම එක බැංකුවක වැඩ කළා. නිර්මාණ සහ අවශ්‍යතා සමාලෝචනවලට නොපැමිණිය යුතු බව එහි සිටි ආරක්ෂක අංශවලට ඒත්තු ගියේය.
(මෙම නිදර්ශනය වෙන වෙනම බැලිය හැක )
ඊට පස්සේ අපි වෙනත් දෙපාර්තමේන්තු වල අය සමඟ කතා කළා, මීට වසර 8 කට පමණ පෙර මෘදුකාංග සංවර්ධකයින් ආරක්ෂක සේවකයින් වැඩ මන්දගාමී වීම නිසා සේවයෙන් පහ කළ බව පෙනී ගියේය. ඉන්පසු එය තහනම් කිරීමක් බවට පත් වූ අතර එය සුළු වශයෙන් ගත්හ. යථාර්ථයේ දී තහනමක් නොතිබුණද.
අපගේ රැස්වීම අතිශයින් ව්‍යාකූල ආකාරයකින් සිදු විය: පැය තුනක් පමණ, විවිධ කණ්ඩායම් පහකට කේතය සහ එකලස් කිරීම අතර සිදුවන්නේ කුමක්ද යන්න මට පැහැදිලි කිරීමට නොහැකි විය. තවද මෙය සරලම දෙය බව පෙනේ. බොහෝ DevOps උපදේශකයින් මෙය දැනටමත් දන්නා බව උපකල්පනය කරයි.
ඉන්පසුව පැය හතරක් නිහඩව සිටි තොරතුරු තාක්ෂණ පාලනය භාර පුද්ගලයා අප ඔහුගේ මාතෘකාවට එන විට හදිසියේම පණ ගැන්වී ඉතා දිගු කාලයක් අපව අල්ලාගෙන සිටියේය. අවසානයේදී මම ඔහුගෙන් රැස්වීම ගැන සිතන්නේ කුමක්දැයි විමසුවෙමි, ඔහුගේ පිළිතුර මට කිසිදා අමතක නොවේ. ඔහු මෙසේ පැවසීය: "අපේ බැංකුවට මෘදුකාංග බෙදා හැරීමේ ක්රම දෙකක් පමණක් ඇති බව මම සිතුවෙමි, නමුත් දැන් ඒවායින් පහක් ඇති බව මම දනිමි, මම තුනක් ගැනවත් දැන සිටියේ නැත."
(මෙම නිදර්ශනය වෙන වෙනම බැලිය හැක )
මෙම බැංකුවේ අවසන් රැස්වීම වූයේ ආයෝජන මෘදුකාංග කණ්ඩායම සමඟය. කඩදාසි පත්‍රයක සලකුණක් සමඟ රූප සටහන් ලිවීම පුවරුවකට වඩා හොඳ බවත් ස්මාර්ට් පුවරුවකට වඩා හොඳ බවත් පෙනී ගියේ ඇය සමඟ ය.
ඔබ දකින ඡායාරූප අපගේ රැස්වීමේ සිව්වන දිනයේ හෝටල් සම්මන්ත්‍රණ ශාලාව කෙබඳුද යන්නයි. රටා, එනම් පුරාවිද්‍යා සෙවීමට අපි මෙම යෝජනා ක්රම භාවිතා කළෙමු.
එබැවින්, මම කම්කරුවන්ගෙන් ප්‍රශ්න අසමි, ඔවුන් පිළිතුරු වර්ණ තුනක (කළු, රතු සහ නිල්) සලකුණු වලින් ලියා ඇත. මම පුරාවිද්‍යා සඳහා ඔවුන්ගේ පිළිතුරු විශ්ලේෂණය කරමි. දැන් අපි සියලු පුරාවිද්‍යා අනුපිළිවෙලින් සාකච්ඡා කරමු.
1. සියලුම වැඩ දෘශ්යමාන කරන්න: වැඩ දෘශ්යමාන කරන්න
මම වැඩ කරන බොහෝ සමාගම් නොදන්නා වැඩ ප්‍රතිශතය ඉතා ඉහළයි. නිදසුනක් වශයෙන්, එක් සේවකයෙකු තවත් සේවකයෙකු වෙත පැමිණ යමක් කිරීමට සරලව ඉල්ලා සිටින විට මෙය වේ. විශාල සංවිධානවල, 60% සැලසුම් නොකළ වැඩ තිබිය හැක. තවද කාර්යයෙන් 40% ක් දක්වා කිසිදු ආකාරයකින් ලේඛනගත කර නොමැත. එය බෝයිං නම්, මම මගේ ජීවිතයේ නැවත ඔවුන්ගේ ගුවන් යානයට ගොඩ නොවනු ඇත. වැඩවලින් අඩක් පමණක් ලේඛනගත කර ඇත්නම්, මෙම කාර්යය නිවැරදිව සිදුවේද නැද්ද යන්න නොදනී. අනෙක් සියලුම ක්රම නිෂ්ඵල බවට හැරේ - කිසිවක් ස්වයංක්‍රීය කිරීමට උත්සාහ කිරීම තේරුමක් නැත, මන්ද දන්නා 50% කාර්යයේ වඩාත්ම සංගත සහ පැහැදිලි කොටස විය හැකි අතර, ස්වයංක්‍රීයකරණය විශිෂ්ට ප්‍රති results ල ලබා නොදෙනු ඇත, සහ නරකම දේවල් නොපෙනෙන අර්ධයේ ඇත. ලියකියවිලි නොමැති විට, මා දැනටමත් කතා කර ඇති “බ්‍රෙන්ට්” සඳහා බාධක සොයා ගැනීමට නොව, සියලු ආකාරයේ හැක් සහ සැඟවුණු වැඩ සොයා ගත නොහැක. Dominica DeGrandis ගේ අපූරු පොතක් තියෙනවා . ඇය හෙළි කරයි විවිධ "කාල කාන්දුවීම්" පහක් (කාල හොරු):
- ක්‍රියාවලියේ වැඩ වැඩියි (WIP)
- නොදන්නා යැපීම්
- සැලසුම් නොකළ වැඩ
- පරස්පර ප්රමුඛතා
- නොසලකා හරින ලද වැඩ
මෙය ඉතා වටිනා විශ්ලේෂණයක් වන අතර පොත විශිෂ්ටයි, නමුත් දත්ත වලින් 50% ක් පමණක් පෙනෙන්නේ නම් මෙම උපදෙස් සියල්ලම නිෂ්ඵල වේ. 90% ට වැඩි නිරවද්‍යතාවයක් ලබා ගන්නේ නම් ඩොමිනිකා විසින් යෝජනා කරන ලද ක්රම භාවිතා කළ හැක. මම කතා කරන්නේ ලොක්කා යටත් නිලධාරියෙකුට මිනිත්තු 15 ක කාර්යයක් ලබා දෙන අවස්ථා ගැන ය, නමුත් එයට ඔහුට දින තුනක් ගත වේ; නමුත් ලොක්කා ඇත්තටම දන්නේ නැහැ මේ යටත් නිලධාරියා තව හතර පස් දෙනෙකුගෙන් යැපෙන බව.
ෆීනික්ස් ව්යාපෘතිය වසර තුනක් ප්‍රමාද වූ ව්‍යාපෘතියක් පිළිබඳ අපූරු කතාවකි. එක් චරිතයක් මේ නිසා නෙරපා හැරීමට මුහුණ දෙන අතර ඔහුට සොක්‍රටීස් වර්ගයක් ලෙස ඉදිරිපත් කරන තවත් චරිතයක් හමුවෙයි. හරියටම වැරදුනේ කුමක්දැයි සොයා ගැනීමට ඔහු උපකාර කරයි. සමාගමට එක් පද්ධති පරිපාලකයෙකු සිටින බව පෙනේ, ඔහුගේ නම බ්‍රෙන්ට් වන අතර, සියලු කටයුතු කෙසේ හෝ ඔහු හරහා සිදු වේ. එක් රැස්වීමකදී, යටත් නිලධාරීන්ගෙන් එක් අයෙකුගෙන් අසනු ලැබේ: සෑම පැය භාගයකම කාර්යය සතියක් ගත වන්නේ ඇයි? පිළිතුර පෝලිම් න්යාය සහ ලිට්ල්ගේ නීතිය පිළිබඳ ඉතා සරල ඉදිරිපත් කිරීමක් වන අතර, මෙම ඉදිරිපත් කිරීමේදී පෙනී යන්නේ 90% ක් පදිංචිව සිටින විට, සෑම පැයකටම වැඩ පැය 9 ක් ගත වන බවයි. සෑම කාර්යයක්ම තවත් පුද්ගලයින් හත් දෙනෙකුට යැවිය යුතුය, එවිට එම පැය 63 පැය 7 ගුණයකින් 9 වේ. මම කියන්නේ Little's Law හෝ ඕනෑම සංකීර්ණ පෝලිම් සිද්ධාන්තයක් භාවිතා කිරීමට නම්, ඔබට අවම වශයෙන් දත්ත තිබිය යුතුය.
ඉතින් මම දෘශ්‍යතාව ගැන කතා කරන විට, මම අදහස් කරන්නේ සියල්ල තිරයේ ඇති බව නොවේ, නමුත් ඔබට අවම වශයෙන් දත්ත තිබේ. ඔවුන් එසේ කරන විට, බොහෝ විට පෙනී යන්නේ සැලසුම් නොකළ වැඩ විශාල ප්‍රමාණයක් අවශ්ය නොවන විට බ්‍රෙන්ට් වෙත යවන බවයි. ඒවගේම Brent කියන්නේ නියම මිනිහෙක්, එයා කවදාවත් එපා කියන්නේ නැහැ, නමුත් එයා එයාගේ වැඩේ කරන්නේ කොහොමද කියලා කාටවත් කියන්නේ නැහැ.
වැඩේ පෙනෙන විට, දත්ත පිළිවෙලට වර්ගීකරණය කළ හැකිය (ෆොටෝ එකේ ඩොමිනිකා කරන්නේ එයයි), පස් කාල කාන්දුවීම් වල සාරාංශය යෙදිය හැකිය, ස්වයංක්‍රීයකරණය යෙදිය හැකිය.
2. වැඩ කළමනාකරණ පද්ධති ඒකාබද්ධ කරන්න: කාර්ය කළමනාකරණය
මම කතා කරන පුරාවිද්‍යාව පිරමීඩ වර්ගයක්. පළමු එක නිවැරදිව සිදු කර ඇත්නම්, දෙවැන්න දැනටමත් ඇඩෝන වර්ගයකි. මේවායින් බොහොමයක් ආරම්භක සඳහා ක්රියා නොකරයි, Fortune 5000 වැනි විශාල සමාගම් සඳහා ඒවා මතක තබා ගත යුතුය. මම අවසන් වරට සේවය කළ සමාගමට ටිකට්පත් පද්ධති 10 ක් තිබුණි. එක් කණ්ඩායමකට Remedy තිබුණා, තවත් කණ්ඩායමක් තමන්ගේම ක්රමයක් ලිව්වා, තුන්වන කණ්ඩායමක් ජිරා භාවිතා කළා, සමහරක් විද්‍යුත් තැපෑලෙන් කළා. සමාගමට විවිධ නල මාර්ග 30 ක් තිබේ නම් එකම ගැටළුව පැන නගී, නමුත් එවැනි සියලු අවස්ථා සාකච්ඡා කිරීමට මට කාලය නැත.
මම ප්‍රවේශපත්‍ර නිර්මාණය කරන්නේ කෙසේද, ඊළඟට ඔවුන්ට කුමක් සිදුවේද සහ ඒවා මඟ හරින්නේ කෙසේද යන්න හරියටම මිනිසුන් සමඟ සාකච්ඡා කරමි. වඩාත්ම සිත්ගන්නා කරුණ නම් අපගේ රැස්වීම්වලදී මිනිසුන් තරමක් අවංකව කතා කිරීමයි. ඇත්ත වශයෙන්ම "ප්රධාන බලපෑමක්" ලබා දිය යුතු ප්‍රවේශපත්‍රවලට "සුළු / කිසිදු බලපෑමක්" දමන්නේ කොපමණ පිරිසක්දැයි මම විමසුවෙමි. සෑම කෙනෙකුම පාහේ මෙය කරන බව පෙනී ගියේය. මම හෙලාදැකීමේ නිරත නොවන අතර මිනිසුන් හඳුනා නොගැනීමට හැකි සෑම ආකාරයකින්ම උත්සාහ කරමි. ඔවුන් මට අවංකවම යමක් පාපොච්චාරණය කළ විට, මම පුද්ගලයාව ලබා නොදෙමි. නමුත් සෑම කෙනෙකුම පාහේ පද්ධතිය මඟ හරින විට, එයින් අදහස් වන්නේ සියලු ආරක්ෂාව අනිවාර්යයෙන්ම ජනෙල් ඇඳීම බවයි. එබැවින්, මෙම පද්ධතියේ දත්ත වලින් කිසිදු නිගමනයකට එළඹිය නොහැක.
ටිකට් ගැටළුව විසඳීම සඳහා, ඔබ එක් ප්රධාන පද්ධතියක් තෝරාගත යුතුය. ඔබ ජිරා භාවිතා කරන්නේ නම්, එය ජිරා තබා ගන්න. විකල්පයක් තිබේ නම්, එය එකම එකක් වේවා. අවසාන කරුණ නම් ප්‍රවේශපත්‍ර සංවර්ධන ක්‍රියාවලියේ තවත් පියවරක් ලෙස සැලකිය යුතු බවයි. සෑම ක්‍රියාවකටම ටිකට් පතක් තිබිය යුතු අතර, එය සංවර්ධන කාර්ය ප්රවාහය හරහා ගලා යා යුතුය. ප්‍රවේශපත් කණ්ඩායමට යවනු ලබන අතර, එය ඒවා කතන්දර පුවරුවේ පළ කර ඒවා සඳහා වගකීම භාර ගනී.
මෙය යටිතල පහසුකම් සහ මෙහෙයුම් ඇතුළුව සියලුම දෙපාර්තමේන්තු සඳහා අදාළ වේ. මෙම අවස්ථාවේ දී, තත්වය පිළිබඳ අවම වශයෙන් යම් පිළිගත හැකි අදහසක් සකස් කළ හැකිය. මෙම ක්‍රියාවලිය ස්ථාපිත වූ පසු, එක් එක් යෙදුම සඳහා වගකිව යුත්තේ කවුරුන්ද යන්න හදිසියේම හඳුනා ගැනීම පහසු වේ. මොකද දැන් අපිට ලැබෙන්නේ 50%ක් නෙවෙයි 98%ක් අලුත් සේවා. මෙම මූලික ක්‍රියාවලිය ක්රියාත්මක වන්නේ නම්, පද්ධතිය පුරා නිරවද්‍යතාවය වැඩි දියුණු වේ.
සේවා නල මාර්ගය
මෙය නැවතත් විශාල සමාගම් සඳහා පමණක් අදාළ වේ. ඔබ නව ක්ෂේත්‍රයක නව සමාගමක් නම්, ඔබේ අත් දෙක රෝල් කර ඔබේ ට්‍රැවිස් සීඅයි හෝ සර්කල්සීඅයි සමඟ වැඩ කරන්න. Fortune 5000 සමාගම් ගැන කියනවනම්, මම වැඩ කරපු බැංකුවේ වෙච්ච සිද්ධියක්. ගූගල් ඔවුන් වෙත පැමිණ පැරණි IBM පද්ධතිවල රූප සටහන් පෙන්වීය. Google එකේ කට්ටිය ව්‍යාකූලව ඇහුවා - කෝ මේකේ source code? නමුත් source code එකක්වත් GUI එකක්වත් නැහැ. විශාල සංවිධාන සමඟ කටයුතු කළ යුතු යථාර්ථය මෙයයි: පැරණි ප්රධාන රාමුවක අවුරුදු 40 ක් පැරණි බැංකු වාර්තා. මගේ එක් සේවාදායකයෙක් KeyBank යෙදුම සඳහා Circuit Breaker රටා සහිත Kubernetes බහාලුම් සහ Chaos Monkey භාවිතා කරයි. නමුත් මෙම බහාලුම් අවසානයේ COBOL යෙදුමකට සම්බන්ධ වේ.
ගූගල් හි සිටින අය මගේ සේවාදායකයාගේ සියලු ගැටලු විසඳන බවට සම්පූර්ණයෙන්ම විශ්වාස කළ අතර පසුව ඔවුන් ප්‍රශ්න ඇසීමට පටන් ගත්හ: IBM දත්ත පයිප්ප යනු කුමක්ද? ඔවුන්ට කියනු ලැබේ: මෙය සම්බන්ධකයකි. එය සම්බන්ධ වන්නේ කුමක් ද? Sperry පද්ධතියට. ඒ මොකක්ද? සහ යනාදි. මුලින්ම බැලූ බැල්මට පෙනෙන්නේ: කුමන ආකාරයේ DevOps තිබිය හැකිද? නමුත් ඇත්ත වශයෙන්ම එය හැකි ය. බෙදා හැරීමේ කණ්ඩායම් වෙත කාර්ය ප්රවාහය භාර දීමට ඔබට ඉඩ සලසන බෙදාහැරීමේ පද්ධති තිබේ.
3. සීමාවන් පිළිබඳ න්යාය: සීමාවන් පිළිබඳ න්යාය
අපි තුන්වන පුරාවිද්‍යාව වෙත යමු: ආයතනික/"ගෝත්‍රික" දැනුම. රීතියක් ලෙස, ඕනෑම සංවිධානයක සෑම දෙයක්ම දන්නා සහ සියල්ල කළමනාකරණය කරන කිහිප දෙනෙකු සිටී. මේ අය තමයි වැඩිම කාලයක් සංවිධානයේ සිටි අය සහ සියලු විසඳුම් දන්නා අය.
මෙය රූප සටහනේ එන විට, මම විශේෂයෙන් එවැනි පුද්ගලයින් සලකුණු කරුවෙකු සමඟ රවුම් කරමි: නිදසුනක් වශයෙන්, සියලු රැස්වීම්වලදී යම් ලූ කෙනෙකු සිටින බව පෙනේ. මට එය පැහැදිලිය: මෙය දේශීය බ්‍රෙන්ට් ය. CIO මා ටී-ෂර්ට් එකකින් සහ සපත්තුවකින් සහ IBM එකේ කොල්ලා ඇඳුමකින් සැරසී සිටින විට, මාව තෝරා ගන්නේ අනෙක් පුද්ගලයා නොකියන සහ අධ්‍යක්ෂවරයා ඇසීමට අකමැති දේවල් අධ්‍යක්ෂවරයාට පැවසිය හැකි බැවිනි. . මම එයාලට කියනවා එයාලගේ කම්පැනි එකේ හිරවෙලා ඉන්නේ ෆ්‍රෙඩ් කියලා කෙනෙක් සහ ලූ කියලා කෙනෙක් කියලා. මෙම බාධකය ලිහා දැමිය යුතුය, ඔවුන්ගේ දැනුම ඔවුන්ගෙන් එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් ලබා ගත යුතුය.
මෙම ආකාරයේ ගැටළුවක් විසඳීම සඳහා, උදාහරණයක් ලෙස, Slack භාවිතා කිරීමට මට යෝජනා කළ හැකිය. දක්ෂ අධ්‍යක්ෂවරයෙක් අසනු ඇත - ඇයි? සාමාන්යයෙන්, එවැනි අවස්ථාවන්හිදී, DevOps උපදේශකයින් පිළිතුරු දෙයි: මන්ද සෑම කෙනෙකුම එය කරන බැවිනි. අධ්‍යක්ෂවරයා ඇත්තටම දක්ෂ නම්, ඔහු කියයි: ඉතින් මොකක්ද. ඒ වගේම මෙතනින් තමයි සංවාදය අවසන් වෙන්නේ. ඒවගේම මේකට මගේ උත්තරේ තමයි: මොකද කම්පැනියේ ෆ්‍රෙඩ්, ලූ, සූසී සහ ජේන් යන බෝතල් හතරක් තියෙනවා. ඔවුන්ගේ දැනුම ආයතනගත කිරීමට නම්, මුලින්ම Slack හඳුන්වා දිය යුතුය. ඔබේ විකි සියල්ල සම්පූර්ණ විකාරයක් වන්නේ ඒවායේ පැවැත්ම ගැන කිසිවෙක් නොදන්නා බැවිනි. ඉංජිනේරු කණ්ඩායම ඉදිරිපස සහ පසු-අන්ත සංවර්ධනයට සම්බන්ධ වන්නේ නම් සහ ප්‍රශ්න සමඟ ඉදිරිපස සංවර්ධන කණ්ඩායම හෝ යටිතල පහසුකම් කණ්ඩායම සම්බන්ධ කර ගත හැකි බව සියලු දෙනා දැනගත යුතුය. එතකොට තමයි ලූට හෝ ෆ්‍රෙඩ්ට විකියට සම්බන්ධ වෙන්න වෙලාව ලැබෙන්නේ. එවිට Slack හි යමෙක් අසනු ඇත, කියන්න, පියවර 5 ක්රියා නොකරන්නේ ඇයි? එවිට Lou හෝ Fred විකියේ උපදෙස් නිවැරදි කරනු ඇත. ඔබ මෙම ක්‍රියාවලිය ස්ථාපිත කරන්නේ නම්, බොහෝ දේ තනිවම සිදුවනු ඇත.
මෙය මගේ ප්රධාන කරුණයි: ඕනෑම උසස් තාක්ෂණයක් නිර්දේශ කිරීම සඳහා, ඔබ ප්‍රථමයෙන් ඒවා සඳහා පදනම පිළිවෙලට තැබිය යුතු අතර, මෙය විස්තර කර ඇති අඩු තාක්ෂණික විසඳුම් සමඟ කළ හැකිය. ඔබ උසස් තාක්ෂණයන් සමඟ ආරම්භ කර ඒවා අවශ්ය වන්නේ මන්දැයි පැහැදිලි නොකරන්නේ නම්, නීතියක් ලෙස, මෙය හොඳින් අවසන් නොවේ. අපගේ එක් සේවාදායකයෙක් ඉතා ලාභදායී සහ සරල විසඳුමක් වන Azure ML භාවිතා කරයි. ඔවුන්ගේ ප්‍රශ්නවලින් 30% කට පමණ ස්වයං ඉගෙනුම් යන්ත්‍රය මගින්ම පිළිතුරු සපයන ලදී. ඒවගේම මේක ලියලා තියෙන්නේ දත්ත විද්‍යාවට, සංඛ්‍යාලේඛනවලට හෝ ගණිතයට සම්බන්ධ නැති ක්‍රියාකරුවන්. මෙය සැලකිය යුතු ය. එවැනි විසඳුමක පිරිවැය අවම වේ.
4. සහයෝගීතා හැක්: සහයෝගීතා හැක්
හතරවන පුරාවිද්‍යාව හුදකලා වීමට එරෙහිව සටන් කිරීමේ අවශ්‍යතාවයයි. බොහෝ අය දැනටමත් මෙය දන්නවා: හුදකලාව සතුරුකම ඇති කරයි. සෑම දෙපාර්තමේන්තුවක්ම තමන්ගේම තට්ටුවේ තිබේ නම් සහ සෝපානයේ හැර මිනිසුන් කිසිම ආකාරයකින් එකිනෙකා සමඟ ඡේදනය නොවන්නේ නම්, ඔවුන් අතර සතුරුකම ඉතා පහසුවෙන් පැන නගී. නමුත් ඊට පටහැනිව, මිනිසුන් එකිනෙකා සමඟ එකම කාමරයේ සිටී නම්, ඇය වහාම පිටව යයි. යමෙක් යම් සාමාන්‍ය චෝදනාවක් ඉවත දැමූ විට, උදාහරණයක් ලෙස, එවැනි අතුරු මුහුණතක් කිසි විටෙකත් ක්රියා නොකරයි, එවැනි චෝදනාවක් විසංයෝජනය කිරීමට පහසු දෙයක් නොමැත. අතුරු මුහුණත ලියූ ක්‍රමලේඛකයින්ට නිශ්චිත ප්‍රශ්න ඇසීමට පටන් ගත යුතු අතර, උදාහරණයක් ලෙස, පරිශීලකයා මෙවලම වැරදි ලෙස භාවිතා කළ බව ඉක්මනින් පැහැදිලි වනු ඇත.
හුදකලාව ජය ගැනීමට බොහෝ ක්රම තිබේ. වරක් ඕස්ට්‍රේලියාවේ බැංකුවකට උපදෙස් ලබා දෙන ලෙස මගෙන් ඉල්ලා සිටියද, මට දරුවන් දෙදෙනෙකු සහ බිරිඳක් සිටින නිසා මම එය ප්‍රතික්ෂේප කළෙමි. ඔවුන්ට උපකාර කිරීමට මට කළ හැකි වූයේ චිත්‍රක කතන්දර නිර්දේශ කිරීම පමණි. මේක ක්රියාත්මක වෙනවා කියලා ඔප්පු වෙච්ච දෙයක්. තවත් රසවත් ක්රමයක් වන්නේ කෙට්ටු කෝපි රැස්වීම්. විශාල සංවිධානයක, දැනුම බෙදා හැරීම සඳහා මෙය විශිෂ්ට විකල්පයකි. ඊට අමතරව, ඔබට අභ්‍යන්තර devopsdays, hackathons සහ යනාදිය පැවැත්විය හැකිය.
5. කටා පුහුණු කිරීම
මම ආරම්භයේදීම අනතුරු ඇඟවූ පරිදි, මම අද මේ ගැන කතා නොකරමි. ඔබ කැමති නම්, ඔබට බලන්න පුළුවන් .
මයික් රොදර්ගෙන් මෙම මාතෘකාව පිළිබඳ හොඳ කතාවක් ද තිබේ:
6. වෙළඳපල දිශානතිය: වෙළඳපල ඉලක්ක කරගත් සංවිධානය
මෙහි විවිධ ගැටළු තිබේ. උදාහරණයක් ලෙස, "I" පුද්ගලයින්, "T" පුද්ගලයින් සහ "E" පුද්ගලයින්. "මම" මිනිසුන් යනු එක් දෙයක් පමණක් කරන අයයි. සාමාන්යයෙන් ඔවුන් හුදකලා දෙපාර්තමේන්තු සහිත සංවිධානවල පවතී. "T" යනු පුද්ගලයෙකු එක් දෙයකට දක්ෂ නමුත් තවත් සමහර දේවල් වලට දක්ෂයි. "ඊ" හෝ "පනාව" යනු පුද්ගලයෙකුට බොහෝ කුසලතා ඇති විටය.
කොන්වේ නීතිය ක්රියාත්මක වන්නේ මෙහි (), වඩාත් සරල ආකාරයෙන් පහත පරිදි දැක්විය හැක: කණ්ඩායම් තුනක් සම්පාදකයේ වැඩ කරන්නේ නම්, ප්රතිඵලය කොටස් තුනක සම්පාදකයක් වනු ඇත. එබැවින්, සංවිධානයක් තුළ ඉහළ මට්ටමේ හුදකලාව තිබේ නම්, මෙම සංවිධානය තුළ Kubernetes, Circuit Breaker, API extensibility සහ වෙනත් විසිතුරු දේවල් පවා සංවිධානය කරන ආකාරයටම සකස් කරනු ලැබේ. කොන්වේට අනුව සහ ඔබ සියලු තරුණ ගීක්වරුන් නොසලකා හැරීමට.
මෙම ගැටලුවට විසඳුම බොහෝ වාරයක් විස්තර කර ඇත. උදාහරණයක් ලෙස, ප්‍රනාන්දු ෆර්නැන්ඩස් විසින් විස්තර කරන ලද සංවිධානාත්මක පුරාවිද්‍යා ඇත. හුදකලාව සමඟ මා කතා කළ එම ගැටලුකාරී ගෘහ නිර්මාණ ශිල්පය ක්‍රියාකාරීත්වයට නැඹුරු ගෘහ නිර්මාණ ශිල්පයකි. දෙවෙනි වර්ගය තමයි නරකම, matrix architecture, අනිත් දෙකේ අවුල්. තෙවනුව බොහෝ ආරම්භකයින් තුළ දක්නට ලැබෙන අතර විශාල සමාගම් ද මෙම වර්ගයට ගැලපීමට උත්සාහ කරයි. එය වෙළඳපල ඉලක්ක කරගත් සංවිධානයකි. මෙහිදී අපි පාරිභෝගික ඉල්ලීම් සඳහා වේගවත්ම ප්‍රතිචාරය ලබා ගැනීමට ප්‍රශස්ත කරමු. මෙය සමහර විට පැතලි සංවිධානයක් ලෙස හැඳින්වේ.
බොහෝ අය මෙම ව්යුහය විවිධ ආකාරවලින් විස්තර කරයි, මම වචන වලට කැමතියි කණ්ඩායම් ගොඩනැගීම/ධාවනය කිරීම, Amazon හි ඔවුන් එය හඳුන්වයි පීසා කණ්ඩායම් දෙකක්. මෙම ව්යුහය තුළ, සියලුම වර්ගයේ “I” පුද්ගලයින් එක් සේවාවක් වටා කාණ්ඩගත කර ඇති අතර, ක්‍රමයෙන් ඔවුන් “T” වර්ගයට සමීප වන අතර, නිවැරදි කළමනාකාරීත්වය ක්රියාත්මක වන්නේ නම්, ඔවුන්ට “E” බවට පවා පත්විය හැකිය. මෙහි පළමු ප්රතිවිරෝධය වන්නේ එවැනි ව්යුහයක් අනවශ්ය මූලද්රව්ය ඇති බවයි. ඔබට විශේෂ පරීක්ෂක දෙපාර්තමේන්තුවක් තිබිය හැකි නම් එක් එක් දෙපාර්තමේන්තුවේ පරීක්ෂකයෙකු අවශ්ය වන්නේ ඇයි? එයට මම පිළිතුරු දෙමි: මෙම නඩුවේ අමතර වියදම් අනාගතයේ දී "E" වර්ගය බවට පත් වීමට සමස්ත සංවිධානය සඳහා මිල වේ. මෙම ව්යුහය තුළ, පරීක්ෂකයා ක්රමක්රමයෙන් ජාල, ගෘහ නිර්මාණ ශිල්පය, සැලසුම් ආදිය ගැන ඉගෙන ගනී. එහි ප්රතිඵලයක් වශයෙන්, සංවිධානයේ සෑම සහභාගිවන්නෙකුම සංවිධානයේ සිදුවන සෑම දෙයක්ම සම්පූර්ණයෙන්ම දැන සිටියි. කර්මාන්තය තුළ මෙම යෝජනා ක්‍රමය ක්රියාත්මක වන ආකාරය දැන ගැනීමට ඔබට අවශ්ය නම්, කියවන්න .
7. Shift-left auditors: චක්රයේ මුල් කාලයේ විගණනය කරන්න. ප්රදර්ශනය කර ඇති ආරක්ෂක නීතිවලට අනුකූල වීම
ඔබේ ක්‍රියාවන් සුවඳ පරීක්ෂණයෙන් සමත් නොවන විට මෙය සිදු වේ. ඔබ වෙනුවෙන් වැඩ කරන මිනිසුන් මෝඩ නැත. ඉහත උදාහරණයේ දී මෙන්, ඔවුන් සෑම තැනකම සුළු / කිසිදු බලපෑමක් ඇති කළේ නම්, මෙය වසර තුනක් පැවතුනි, සහ කිසිවෙකු කිසිවක් නොදුටු නම්, පද්ධතිය ක්රියා නොකරන බව කවුරුත් හොඳින් දනී. හෝ තවත් උදාහරණයක් - වෙනස් කිරීම් උපදේශක මණ්ඩලයක්, සෑම බදාදා දිනකම වාර්තා ඉදිරිපත් කළ යුතුය. න්‍යායාත්මකව, සමස්තයක් ලෙස පද්ධතිය ක්රියා කරන ආකාරය දැන සිටිය යුතු පුද්ගලයින් පිරිසක් එහි වැඩ කරති (ඉතා හොඳින් වැටුප් නොලැබේ, මාර්ගයෙන්). පසුගිය වසර පහ තුළ, අපගේ පද්ධති ඇදහිය නොහැකි තරම් සංකීර්ණ බව ඔබ දැක ඇති. ඒවගේම තමන් නොකළ සහ තමන් කිසිවක් නොදන්නා වෙනසක් ගැන පස් හය දෙනෙකුට තීරණයක් ගත යුතුය.
ඇත්ත වශයෙන්ම, මෙම ප්රවේශය ක්රියා නොකරයි. මේ අය සිස්ටම් එක රකින්නේ නැති නිසා මට මේ වගේ දේවල් අයින් කරන්න වෙනවා. කණ්ඩායම විසින්ම තීරණය ගත යුතුය, මන්ද එයට කණ්ඩායම වගකිව යුතුය. එසේ නොමැති නම්, තම ජීවිතයේ කිසි දිනෙක කේත ලියා නැති කළමනාකරුවෙකු කේත ලිවීමට කොපමණ කාලයක් ගත විය යුතුදැයි ක්‍රමලේඛකයාට පැවසීමේදී පරස්පර විරෝධී තත්වයක් පැන නගී. මා සමඟ වැඩ කළ එක් සමාගමක ගෘහ නිර්මාණ පුවරුවක්, නිෂ්පාදන පුවරුවක් යනාදිය ඇතුළුව සෑම වෙනස්කමක්ම සමාලෝචනය කළ විවිධ පුවරු 7ක් තිබුණි. අනිවාර්ය පොරොත්තු කාල සීමාවක් පවා තිබුනා, එක් සේවකයෙක් මට කිව්වත් අවුරුදු දහයක වැඩ කාලය තුළ, මෙම අනිවාර්ය කාලය තුළ මෙම පුද්ගලයා විසින් කරන ලද වෙනසක් කිසි විටෙකත් කිසිවෙකු ප්‍රතික්ෂේප කර නැත.
විගණකවරුන්ට ආරාධනා කළ යුත්තේ අප හා එක්වන ලෙස මිස ඔවුන්ගෙන් මිදීමට නොවේ. ඔබ වෙනස් කළ නොහැකි ද්විමය බහාලුම් ලියන බව ඔවුන්ට පවසන්න, ඔවුන් සියලු පරීක්ෂණ සමත් වුවහොත්, සදහටම නොවෙනස්ව පවතිනු ඇත. ඔබට කේතයක් ලෙස නල මාර්ගයක් ඇති බවත් එයින් අදහස් කරන්නේ කුමක්ද යන්න පැහැදිලි කරන්න. ඔවුන්ට පහත යෝජනා ක්‍රමය පෙන්වන්න: සියලුම අවදානම් පරීක්ෂණ සමත් වන බහාලුමක් තුළ වෙනස් කළ නොහැකි කියවීමට පමණක් ද්විමය; එවිට කිසිවෙකු එය ස්පර්ශ නොකරනවා පමණක් නොව, එය ගතිකව නිර්මාණය කර ඇති බැවින්, නල මාර්ගය නිර්මාණය කරන පද්ධතියට පවා ඔවුන් අත නොතබයි. මට සේවාදායකයන් ඇත, Capital One, ඔවුන් බ්ලොක්චේන් වැනි දෙයක් නිර්මාණය කිරීමට Vault භාවිතා කරයි. විගණකවරයාට චෙෆ්ගෙන් “වට්ටෝරු” පෙන්වීමට අවශ්ය නැත; බ්ලොක්චේන් පෙන්වීම ප්‍රමාණවත් වේ, එයින් නිෂ්පාදනයේ ජිරා ටිකට් පතට සිදුවූයේ කුමක්ද සහ එයට වගකිව යුත්තේ කවුරුන්ද යන්න පැහැදිලිය.
අනුව , Sonatype විසින් 2018 දී නිර්මාණය කරන ලද, 2017 දී OSS බාගත කිරීමේ ඉල්ලීම් බිලියන 87 ක් විය.
දුර්වලතා නිසා සිදුවන පාඩුව අති විශාලයි. එපමණක් නොව, ඔබ දැන් ඉහත දකින සංඛ්‍යාවල අවස්ථා වියදම් ඇතුළත් නොවේ. කෙටියෙන් DevSecOps යනු කුමක්ද? මෙම නම කෙතරම් සාර්ථකද යන්න ගැන කතා කිරීමට මා උනන්දු නොවන බව මම වහාම කියමි. කාරණය වන්නේ DevOps ඉතා සාර්ථක වී ඇති බැවින්, එම නල මාර්ගයට ආරක්ෂාව එක් කිරීමට අප උත්සාහ කළ යුතුය.
මෙම අනුපිළිවෙලෙහි උදාහරණයක්:
මම ඒවා සියල්ලටම කැමති වුවද මෙය විශේෂිත නිෂ්පාදන සඳහා නිර්දේශයක් නොවේ. මුලින් කර්මාන්තයේ ආයතනික ආදර්ශය මත පදනම් වූ DevOps, නිෂ්පාදනයක් මත වැඩ කරන සෑම අදියරක්ම ස්වයංක්‍රීය කිරීමට ඔබට ඉඩ සලසයි.
ආරක්ෂාව සම්බන්ධයෙන් අපට එකම ප්‍රවේශයක් ගැනීමට නොහැකි වීමට හේතුවක් නැත.
ප්රතිඵලය
අවසාන වශයෙන්, මම DevSecOps සඳහා උපදෙස් කිහිපයක් දෙන්නෙමි. ඔබේ පද්ධති නිර්මාණය කිරීමේ ක්‍රියාවලියට ඔබ විගණකවරුන් ඇතුළත් කර ඔවුන්ව දැනුවත් කිරීමට කාලය ගත කළ යුතුය. ඔබ විගණකවරුන් සමඟ සහයෝගයෙන් කටයුතු කළ යුතුය. ඊළඟට, ඔබ ව්යාජ ධනාත්මක දේවලට එරෙහිව පරම නිර්දය සටනක් දිය යුතුය. වඩාත්ම මිල අධික අවදානම් පරිලෝකන මෙවලම සමඟ වුවද, ඔබේ සංඥාව සහ ශබ්ද අනුපාතය කුමක්දැයි ඔබ නොදන්නේ නම්, ඔබේ සංවර්ධකයින් අතර අතිශයින් නරක පුරුදු නිර්මාණය කිරීමට ඔබට හැකිය. සංවර්ධකයින් සිදුවීම්වලින් යටපත් වී ඒවා මකා දමනු ඇත. ඔබ Equifax කතාව ගැන අසා ඇත්නම්, ඉහළම අනතුරු ඇඟවීමේ මට්ටම නොසලකා හරින ලද එහි සිදුවූයේ එයයි. ඊට අමතරව, දුර්වලතා ව්‍යාපාරයට බලපාන ආකාරය පැහැදිලි වන ආකාරයෙන් පැහැදිලි කළ යුතුය. උදාහරණයක් ලෙස, මෙය Equifax කතාවේ ඇති දුර්වලතාවයම බව ඔබට පැවසිය හැකිය. ආරක්ෂක දුර්වලතා අනෙකුත් මෘදුකාංග ගැටළු වලට සමානව සැලකිය යුතුය, එනම් ඒවා සමස්ත DevOps ක්‍රියාවලියට ඇතුළත් කළ යුතුය. ඔබ ඔවුන් සමඟ ජිරා, කන්බන්, ආදිය හරහා වැඩ කළ යුතුය. වෙනත් කෙනෙකු මෙය කරනු ඇතැයි සංවර්ධකයින් නොසිතිය යුතුය - ඊට පටහැනිව, සෑම කෙනෙකුම මෙය කළ යුතුය. අවසාන වශයෙන්, ඔබ මිනිසුන් පුහුණු කිරීම සඳහා ශක්තිය වැය කළ යුතුය.
ප්රයෝජනවත් සබැඳි
ඔබට ප්රයෝජනවත් විය හැකි DevOops සම්මන්ත්‍රණයේ කතා කිහිපයක් මෙන්න:
- Sergey Berdnikov, Artyom Kalichkin - සාර්ථක කතාව, හෝ "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps on a scale: ක්රියා තුනකින් ග්‍රීක ඛේදවාචකයක් (, )
- ඇලෙක්සැන්ඩර් ටිටොව්, කිරිල් ටොල්කචෙව් -
- තිමෝති ලිස්ටර් -
දෙස බලන්න DevOops 2020 මොස්කව් - එහි රසවත් දේවල් ද තිබේ.
මූලාශ්රය: www.habr.com