DevOps ඉංජිනේරුවන් නොමැත. එවිට සිටින්නේ කවුද, එය සමඟ කුමක් කළ යුතුද?

DevOps ඉංජිනේරුවන් නොමැත. එවිට සිටින්නේ කවුද, එය සමඟ කුමක් කළ යුතුද?

පහුගිය දවස්වල අන්තර්ජාලය පුරාවටම එවැනි දැන්වීම් ගලා ගියා. ප්‍රියමනාප වැටුපක් තිබුණත් ඇතුලේ වල් මිත්‍යාදෘෂ්ටිය ලියා තිබීම ගැන කෙනෙකුට ලැජ්ජාවක් ඇති නොවෙන්න පුළුවන්. මුලදී උපකල්පනය කර ඇත්තේ “DevOps” සහ “ඉංජිනේරු” කෙසේ හෝ එක් වචනයකට එකට ඇලවිය හැකි අතර පසුව අහඹු ලෙස අවශ්‍යතා ලැයිස්තුවක් ඇත, ඒවායින් සමහරක් පැහැදිලිවම sysadmin පුරප්පාඩුවෙන් පිටපත් කර ඇත.

මෙම ලිපියෙන් මම මේ ජීවිතයේ මෙම අවස්ථාවට පැමිණියේ කෙසේද, DevOps යනු කුමක්ද සහ දැන් එයට කුමක් කළ යුතුද යන්න ගැන ටිකක් කතා කිරීමට කැමැත්තෙමි.

එවැනි පුරප්පාඩු හැකි සෑම ආකාරයකින්ම හෙළා දැකිය හැකිය, නමුත් කාරණය ඉතිරිව පවතී: ඒවායින් බොහොමයක් ඇති අතර, මේ මොහොතේ වෙළඳපල ක්‍රියා කරන ආකාරය මෙයයි. අපි devops සම්මන්ත්‍රණයක් පවත්වා විවෘතව ප්‍රකාශ කළේ: "DevOops - DevOps ඉංජිනේරුවන් සඳහා නොවේ." මෙය බොහෝ දෙනෙකුට අමුතු හා වල් ලෙස පෙනෙනු ඇත: සම්පූර්ණයෙන්ම වාණිජ උත්සවයක් කරන පුද්ගලයින් වෙළඳපොළට එරෙහිව යන්නේ ඇයි. දැන් අපි සියල්ල පැහැදිලි කරන්නෙමු.

සංස්කෘතිය සහ ක්රියාවලීන් ගැන

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

උදාහරණයක් ලෙස, පද්ධති පරිපාලකයෙකු සහ සේවා කළමනාකරණය සඳහා SRE ප්‍රවේශයක් අතර වෙනස විස්තර කිරීම සුප්‍රසිද්ධ Google SRE පොත ආරම්භ වේ. ඇතුළත සිත්ගන්නා අධ්‍යයනයන් සිදු කර ඇත DORA සමීක්ෂණය - හොඳම සංවර්ධකයින් කෙසේ හෝ පැයකට වරක් වඩා වේගයෙන් නිෂ්පාදනයට නව වෙනස්කම් යෙදවීමට සමත් වන බව පැහැදිලිය. ඔවුන් තම දෑතින් 10% ට නොඅඩු ලෙස පරීක්ෂා කරයි (මෙය දැකිය හැකිය පසුගිය වසරේ DORA) ඔවුන් මෙය කරන්නේ කෙසේද? “Excel or die” වාර්තා ශීර්ෂයන්ගෙන් එකක් පවසයි. පරීක්ෂණ සන්දර්භය තුළ මෙම සංඛ්‍යාලේඛන පිළිබඳ සවිස්තරාත්මක සාකච්ඡාවක් සඳහා, ඔබට බාරුක් සඩෝගුර්ස්කිගේ ප්‍රධාන දේශනය වෙත යොමු විය හැකිය. “අපිට DevOps තියෙනවා. අපි සියලුම පරීක්ෂකයින් දොට්ට දමමු." අපගේ අනෙක් සමුළුවේදී, හයිසන්බග්.

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

ඔබ සිතන්නේ වෙබ් ක්‍රමලේඛකයින්ගේ කුමන කොටස නිෂ්පාදනයේදී ඔවුන්ගේ යෙදුම් භාවිතා කරන කොන්දේසි සැබවින්ම තේරුම් ගෙන ඇති බව ද? කීයෙන් කීදෙනාද ඇඩ්මින්ලා ළඟට ගිහින් ඩේටාබේස් එක කඩා වැටුණොත් මොකද වෙන්නේ කියලා හොයාගන්න හදනවද? ඒවගේම ඔවුන්ගෙන් කවුද පරීක්ෂකයන් වෙත ගොස් නිවැරදිව පරීක්ෂණ ලියන ආකාරය උගන්වන ලෙස ඉල්ලා සිටින්නේද? ඒ වගේම ආරක්‍ෂක නිලධාරීන්, නිෂ්පාදන කළමනාකරුවන් සහ තවත් පිරිසක් ඉන්නවා.

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

විෂම කවය

එතකොට "devops engineering" කියන විනය ආවේ කොහෙන්ද? අපට අනුවාදයක් තිබේ! DevOps අදහස් හොඳයි—එතරම් හොඳ ඒවා ඔවුන්ගේම සාර්ථකත්වයේ ගොදුරු බවට පත් විය. ඔවුන්ගේම වාතාවරණයක් ඇති සමහර සෙවන සහිත බඳවා ගන්නන් සහ මිනිස් ජාවාරම්කරුවන් මෙම සමස්ත මාතෘකාව වටා කැරකෙන්නට පටන් ගත්හ.

සිතන්න: ඊයේ ඔබ කිම්කි හි ෂවර්මා සාදමින් සිටි අතර අද ඔබ දැනටමත් විශාල මිනිසෙක්, ජ්‍යෙෂ්ඨ බඳවා ගන්නෙක්. අපේක්ෂකයින් සෙවීම සහ තෝරා ගැනීමේ සම්පූර්ණ ක්‍රියාවලියක් ඇත, සෑම දෙයක්ම පහසු නැත, ඔබ තේරුම් ගත යුතුය. අපි කියමු දෙපාර්තමේන්තු ප්රධානියා පවසන්නේ: X හි විශේෂඥයෙකු සොයා ගන්න. අපි "ඉංජිනේරු" යන වචනය X වෙත පවරමු, අපි ඉවරයි. Linux අවශ්‍යද? හොඳයි, මෙය අනිවාර්යයෙන්ම Linux ඉංජිනේරුවෙකු වේ, ඔබට DevOps අවශ්‍ය නම්, DevOps ඉංජිනේරුවෙකි. පුරප්පාඩුව සමන්විත වන්නේ මාතෘකාවකින් පමණක් නොව, යම් පෙළක් ඇතුළත ඇතුළත් කළ යුතුය. පහසුම ක්‍රමය නම් ඔබේ පරිකල්පනය අනුව Google වෙතින් මූල පද මාලාවක් ඇතුළත් කිරීමයි. DevOps වචන දෙකකින් සමන්විත වේ - "Dev" සහ "Ops", එයින් අදහස් කරන්නේ අපි සංවර්ධකයින් සහ පරිපාලකයින් සම්බන්ධ මූල පද එක ගොඩකට ඇලවිය යුතු බවයි. ක්‍රමලේඛන භාෂා 42 ක ප්‍රවීණතාවය සහ වසර 20 ක Kubernetes සහ Swarm එකවර භාවිතා කිරීමේ පුරප්පාඩු දිස්වන්නේ එලෙස ය. වැඩ කරන රූප සටහන.

එක්තරා “ඩෙවොප්ස්” සුපිරි වීරයෙකුගේ අර්ථ විරහිත හා අනුකම්පා විරහිත ප්‍රතිරූපය මිනිසුන්ගේ මනසෙහි මුල් බැස ඇති ආකාරය මෙයයි, ඔවුන් සෑම කෙනෙකුම ජෙන්කින්ස් වෙත යෙදවීමට වින්‍යාස කරනු ඇත, සතුට පැමිණේ. ඔහ්, සෑම දෙයක්ම ඉතා සරල නම්. “ඔබට පද්ධති පරිපාලකයින් දඩයම් කළ හැක්කේද මෙයයි,” HR සිතන්නේ, “එය විලාසිතාමය වචනයකි, මූල පද සමාන වේ, ඔවුන් ඇමක් ගත යුතුය.”

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

ඒ නිසා අපිට සැපයුම සහ ඉල්ලුම තියෙනවා. තමන්වම පෝෂණය කරන විෂම චක්‍රයක්. අපි සටන් කරන්නේ මෙයට එරෙහිවයි (DevOops සම්මන්ත්‍රණය නිර්මාණය කිරීම ඇතුළුව).

ඇත්ත වශයෙන්ම, තමන් "devops" ලෙස නම් කර ඇති පද්ධති පරිපාලකයින්ට අමතරව, වෙනත් සහභාගිවන්නන් ඇත - උදාහරණයක් ලෙස, වෘත්තීය SREs හෝ Infrastructure-as-Code developers.

මිනිසුන් DevOps හි කරන දේ (ඇත්තටම)

එබැවින් ඔබට DevOps භාවිතයන් ඉගෙනීම සහ යෙදීමෙහි ඉදිරියට යාමට අවශ්‍ය වේ. නමුත් මෙය කරන්නේ කෙසේද, කුමන දිශාවට බැලිය යුතුද? නිසැකවම, ඔබ ජනප්‍රිය මූල පද මත අන්ධ ලෙස විශ්වාසය නොතැබිය යුතුය.

රස්සාවක් තියෙනවනම් කවුරු හරි කරන්න ඕන. මොවුන් "devops ඉංජිනේරුවන්" නොවන බව අපි දැනටමත් සොයාගෙන ඇත, එසේ නම් කවුද? මෙය තනතුරු අනුව නොව නිශ්චිත වැඩ ක්ෂේත්‍ර අනුව සකස් කිරීම වඩාත් නිවැරදි බව පෙනේ.

පළමුව, ඔබට DevOps-ක්‍රියාවලි සහ සංස්කෘතියේ හදවත ඇමතීමට හැකිය. සංස්කෘතිය මන්දගාමී හා දුෂ්කර ව්‍යාපාරයක් වන අතර, එය සාම්ප්‍රදායිකව කළමනාකරුවන්ගේ වගකීමක් වුවද, ක්‍රමලේඛකයන්ගේ සිට පරිපාලකයින් දක්වා සෑම කෙනෙකුම එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් සම්බන්ධ වේ. මාස කිහිපයකට පෙර ටිම් ලිස්ටර් සම්මුඛ සාකච්ඡාවකදී පැවසීය:

“සංස්කෘතිය තීරණය වන්නේ සංවිධානයේ මූලික වටිනාකම් මගිනි. සාමාන්‍යයෙන් මිනිසුන්ට මෙය නොපෙනේ, නමුත් වසර ගණනාවක් උපදේශන කටයුතුවල යෙදී සිටින අපි එය දැකීමට පුරුදු වී සිටිමු. ඔබ සමාගමකට ඇතුළු වන අතර වචනාර්ථයෙන් මිනිත්තු කිහිපයකින් සිදුවන්නේ කුමක්දැයි ඔබට දැනෙන්නට පටන් ගනී. අපි මෙය "රසය" ලෙස හඳුන්වමු. සමහර විට මෙම සුවඳ ඇත්තෙන්ම හොඳයි. සමහර විට එය ඔක්කාරය ඇති කරයි. (...) නිශ්චිත ක්‍රියාවන් පිටුපස ඇති වටිනාකම් සහ විශ්වාසයන් තේරුම් ගන්නා තෙක් ඔබට සංස්කෘතියක් වෙනස් කළ නොහැක. හැසිරීම නිරීක්ෂණය කිරීම පහසුය, නමුත් විශ්වාසයන් සෙවීම දුෂ්කර ය. DevOps යනු දේවල් වඩ වඩාත් සංකීර්ණ වන ආකාරය පිළිබඳ විශිෂ්ට උදාහරණයක් පමණි.

ගැටලුවේ තාක්ෂණික කොටසක් ද ඇත, ඇත්ත වශයෙන්ම. ඔබේ නව කේතය මාසයකින් පරීක්‍ෂා කර වසරකට පසුව නිකුත් කරනු ලැබුවහොත් සහ ඒ සියල්ල වේගවත් කිරීමට භෞතිකව කළ නොහැකි නම්, ඔබ හොඳ භාවිතයන් සමඟ ජීවත් නොවිය හැකිය. හොඳ භාවිතයන් හොඳ මෙවලම් මගින් සහාය වේ. උදාහරණයක් ලෙස, Infrastructure-as-Code යන අදහස මනසේ තබාගෙන, ඔබට AWS CloudFormation සහ Terraform සිට Chef-Ansible-Puppet දක්වා ඕනෑම දෙයක් භාවිතා කළ හැකිය. ඔබ මේ සියල්ල දැන සිටිය යුතු අතර එය කිරීමට හැකි විය යුතු අතර, මෙය දැනටමත් තරමක් ඉංජිනේරු විනයකි. හේතුව බලපෑම සමඟ පටලවා නොගැනීම වැදගත්ය: පළමුව ඔබ SRE හි මූලධර්මවලට අනුව වැඩ කරන අතර පසුව පමණක් මෙම මූලධර්ම යම් නිශ්චිත තාක්ෂණික විසඳුම් ආකාරයෙන් ක්රියාත්මක කරන්න. ඒ අතරම, SRE යනු ඉතා විස්තීර්ණ ක්‍රමවේදයක් වන අතර එය ජෙන්කින්ස් පිහිටුවන ආකාරය ඔබට නොකියයි, නමුත් මූලික මූලධර්ම පහක් ගැන:

  • භූමිකාවන් සහ දෙපාර්තමේන්තු අතර සන්නිවේදනය වැඩිදියුණු කිරීම
  • රැකියාවේ අනිවාර්ය අංගයක් ලෙස වැරදි පිළිගැනීම
  • ක්රමානුකූලව වෙනස්කම් සිදු කිරීම
  • මෙවලම් සහ වෙනත් ස්වයංක්‍රීයකරණය භාවිතා කිරීම
  • මැනිය හැකි සියල්ල මැනීම

මෙය නිකම්ම නිකම් ප්‍රකාශ මාලාවක් නොව විශේෂිත එකක් ක්රියා කිරීමට මාර්ගෝපදේශය. උදාහරණයක් ලෙස, දෝෂ පිළිගැනීමේ මාවතේ, ඔබට SLI (SLI (සේවා මට්ටමේ දර්ශක) සහ SLO (සේවා මට්ටමේ අරමුණු), පශ්චාත් මරණ පරීක්ෂණ ලිවීමට සහ ඒවා ලිවීමට බිය නොවන ලෙස සකස් කිරීමට ඉගෙන ගන්න.

SRE විනය තුළ, මෙවලම් භාවිතය වැදගත් එකක් වුවද සාර්ථකත්වයේ එක් කොටසක් පමණි. අපි නිරන්තරයෙන් තාක්ෂණික වශයෙන් සංවර්ධනය කළ යුතු අතර, ලෝකයේ සිදුවෙමින් පවතින දේ දෙස බලන්න සහ අපගේ කාර්යයේදී එය යෙදිය හැකි ආකාරය.

අනෙක් අතට, Cloud Native විසඳුම් දැන් ඉතා ජනප්‍රිය වී ඇත. අද Cloud Native Computing Foundation විසින් නිර්වචනය කර ඇති පරිදි, Cloud Native තාක්‍ෂණයන් මගින් ආයතනවලට පොදු, පුද්ගලික සහ දෙමුහුන් වලාකුළු වැනි ගතික පරිසරයන් තුළ පරිමාණය කළ හැකි යෙදුම් සංවර්ධනය කිරීමට සහ ධාවනය කිරීමට හැකි වේ. උදාහරණ ලෙස බහාලුම්, සේවා දැල්, ක්ෂුද්‍ර සේවා, වෙනස් කළ නොහැකි යටිතල පහසුකම් සහ ප්‍රකාශන API ඇතුළත් වේ. මෙම සියලු ශිල්පීය ක්‍රම මගින් ලිහිල්ව සම්බන්ධ වූ පද්ධති ප්‍රත්‍යාස්ථව, කළමනාකරණය කළ හැකි සහ ඉතා හොඳින් නිරීක්ෂණය කළ හැකි ලෙස පවතිනු ඇත. හොඳ ස්වයංක්‍රීයකරණය ඉංජිනේරුවන්ට විශාල වෙනස්කම් කිරීමට ඉඩ සලසයි, එය කාර්යබහුල දෙයක් බවට පත් නොකර පුරෝකථනය කළ හැකි ප්‍රතිඵල ඇත. මේ සියල්ල Docker සහ Kubernetes වැනි සුප්‍රසිද්ධ මෙවලම් තොගයකින් සහාය වේ.

මෙම තරමක් සංකීර්ණ හා පුළුල් නිර්වචනය ප්‍රදේශය ද තරමක් සංකීර්ණ වීම නිසාය. එක් අතකින්, මෙම ක්රමයට නව වෙනස්කම් ඉතා සරලව එකතු කළ යුතු බව තර්ක කරයි. අනෙක් අතට, මෘදුකාංග නිර්වචනය කරන ලද යටිතල ව්‍යුහයක් මත ලිහිල්ව සම්බන්ධිත සේවාවන් ජීවත් වන සහ අඛණ්ඩ CI/CD භාවිතයෙන් එහි බෙදා හරින ආකාරයේ බහාලුම් පරිසරයක් නිර්මාණය කරන්නේ කෙසේදැයි සොයා බැලීමට සහ මේ සියල්ල වටා DevOps පරිචයන් ගොඩනඟා ගැනීමට - මේ සියල්ලටම වඩා අවශ්‍ය වේ. එකෙක් බල්ලා කනවාට වඩා.

මේ සියල්ලට කුමක් කරන්නද

සෑම කෙනෙකුම මෙම ගැටළු තමන්ගේම ආකාරයෙන් විසඳයි: නිදසුනක් වශයෙන්, විෂම චක්රය බිඳ දැමීම සඳහා ඔබට සාමාන්ය පුරප්පාඩු ප්රකාශයට පත් කළ හැකිය. DevOps සහ Cloud Native වැනි වචන වලින් අදහස් කරන්නේ කුමක්දැයි ඔබට තේරුම් ගත හැකි අතර ඒවා නිවැරදිව හා කාරණයට භාවිතා කරන්න. ඔබට DevOps තුළ සංවර්ධනය කළ හැකි අතර ඔබේ උදාහරණයෙන් නිවැරදි ප්‍රවේශයන් පෙන්විය හැක.

අපි සම්මන්ත්‍රණයක් කරනවා DevOops 2020 මොස්කව්, අපි දැන් කතා කළ දේවල් ගැඹුරින් සොයා බැලීමට අවස්ථාවක් සපයයි. මේ සඳහා වාර්තා කණ්ඩායම් කිහිපයක් තිබේ:

  • ක්‍රියාවලි සහ සංස්කෘතිය;
  • අඩවි විශ්වසනීයත්වය ඉංජිනේරු;
  • වලාකුළු ස්වදේශික;

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

නිසැකවම, සම්මන්ත්‍රණයේදීම ඔබට එකවර ධාවන පථ තුනකට යා නොහැක, එබැවින් අපි වැඩසටහන සංවිධානය කරන්නේ සෑම වේලාවකම සෑම රසය සඳහාම මාතෘකා ඇති ආකාරයටය.

ඉතිරිව ඇත්තේ ඔබ DevOps ඉංජිනේරුවෙකු නම් කුමක් කළ යුතු දැයි තේරුම් ගැනීමයි! පළමුව, ඔබ ඇත්තටම කරන්නේ කුමක්ද යන්න තීරණය කිරීමට උත්සාහ කරන්න. සාමාන්යයෙන් ඔවුන් මෙම වචනය ඇමතීමට කැමතියි:

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

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

DevOps ඉංජිනේරුවන් නොමැත. එවිට සිටින්නේ කවුද, එය සමඟ කුමක් කළ යුතුද?
සිට ලිස්සා යන්න කොන්ස්ටන්ටින් ඩයනර් විසින් වාර්තාව මියුනිච් හි

DevOops 2020 මොස්කව් අප්‍රේල් 29-30 දිනවල මොස්කව්හිදී පැවැත්වේ, ප්‍රවේශපත්‍ර දැනටමත් තිබේ නිල වෙබ් අඩවියෙන් මිලදී ගන්න.

විකල්පයක් ලෙස, ඔබට පුළුවන් ඔබේ වාර්තාව ඉදිරිපත් කරන්න පෙබරවාරි 8 දක්වා. පෝරමය පුරවන විට, ඔබේ වාර්තාවෙන් වඩාත් ප්‍රතිලාභ ලබන ඉලක්කගත ප්‍රේක්ෂකයින් තෝරාගත යුතු බව කරුණාවෙන් සලකන්න (ලැයිස්තුව ඇතුලේ විස්මයක් තැන්පත් වෙලා තියෙනවා).

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

අදහස් එක් කරන්න