යෙදුම් අධීක්ෂණය ගැන ඉංජිනේරුවන් සැලකිලිමත් නොවන්නේ ඇයි?

හැමෝටම සුබ සිකුරාදා! මිත්රවරුනි, අද අපි පාඨමාලාවට කැප වූ ප්රකාශන මාලාව දිගටම කරගෙන යන්නෙමු "DevOps භාවිතයන් සහ මෙවලම්", මක්නිසාද යත් පාඨමාලාව සඳහා නව කණ්ඩායමේ පන්ති ලබන සතිය අවසානයේ ආරම්භ වන බැවිනි. ඉතින්, අපි පටන් ගනිමු!

යෙදුම් අධීක්ෂණය ගැන ඉංජිනේරුවන් සැලකිලිමත් නොවන්නේ ඇයි?

අධීක්ෂණය යනු සාධාරණයි. මෙය දන්නා කරුණකි. Nagios ගෙන එන්න, දුරස්ථ පද්ධතිය මත NRPE ධාවනය කරන්න, NRPE TCP port 5666 මත Nagios වින්‍යාස කරන්න සහ ඔබට අධීක්ෂණය ඇත.

එය ඉතා පහසු වන අතර එය සිත්ගන්නා සුළු නොවේ. දැන් ඔබට CPU කාලය, තැටි උප පද්ධතිය, RAM සඳහා මූලික මිතික ඇත, පෙරනිමියෙන් Nagios සහ NRPE වෙත සපයනු ලැබේ. නමුත් මෙය ඇත්ත වශයෙන්ම "අධීක්ෂණය" නොවේ. මෙය ආරම්භය පමණි.

(සාමාන්‍යයෙන් ඔවුන් PNP4Nagios, RRDtool සහ Thruk ස්ථාපනය කර, Slack හි දැනුම්දීම් සකසා කෙලින්ම nagiosexchange වෙත යමු, නමුත් අපි එය දැනට අත්හැර දමමු).

හොඳ නිරීක්ෂණ ඇත්ත වශයෙන්ම තරමක් සංකීර්ණ වේ, ඔබ නිරීක්ෂණය කරන යෙදුමේ අභ්‍යන්තරය ඔබ සැබවින්ම දැන සිටිය යුතුය.

අධීක්ෂණය අපහසුද?

ඕනෑම සේවාදායකයක්, එය ලිනක්ස් හෝ වින්ඩෝස් වේවා, අර්ථ දැක්වීම අනුව යම් අරමුණක් ඉටු කරයි. Apache, Samba, Tomcat, ගොනු ආචයනය, LDAP - මෙම සියලුම සේවාවන් එක් හෝ කිහිපයකින් අඩු හෝ වැඩි වශයෙන් අද්විතීය වේ. ඒ සෑම එකක්ම තමන්ගේම කාර්යයක්, තමන්ගේම ලක්ෂණ ඇත. ප්‍රමිතික, කේපීඅයි (ප්‍රධාන කාර්ය සාධන දර්ශක) ලබා ගැනීමට විවිධ ක්‍රම තිබේ, ඒවා සේවාදායකය පැටවෙන විට ඔබට සිත්ගන්නා සුළුය.

යෙදුම් අධීක්ෂණය ගැන ඉංජිනේරුවන් සැලකිලිමත් නොවන්නේ ඇයි?
ඡායාරූපයේ කර්තෘ ලූක් චෙසර් මත නොපෙනී

(මගේ උපකරණ පුවරුව නියොන් නිල් පාටයි - සිහිනෙන් සුසුම්ලමින් -... හ්ම්ම්...)

සේවා සපයන ඕනෑම මෘදුකාංගයකට ප්‍රමිතික එකතු කිරීමේ යාන්ත්‍රණයක් තිබිය යුතුය. Apache සතුව මොඩියුලයක් ඇත mod-status, සේවාදායක තත්ත්‍ව පිටුව පෙන්වමින්. Nginx සතුව ඇත - stub_status. Tomcat සතුව ප්‍රධාන මිතික පෙන්වන JMX හෝ අභිරුචි වෙබ් යෙදුම් තිබේ. MySQL සතුව "ගෝලීය තත්ත්වය පෙන්වන්න" ආදී විධානයක් ඇත.
එසේනම් සංවර්ධකයින් ඔවුන් විසින් නිර්මාණය කරන යෙදුම් වලට සමාන යාන්ත්‍රණ ගොඩනඟන්නේ නැත්තේ ඇයි?

මේක කරන්නේ developersලා විතරද?

ප්‍රමිතික කාවැද්දීම සඳහා යම් මට්ටමක උදාසීනත්වයක් සංවර්ධකයින්ට සීමා නොවේ. මම වැඩ කළේ ඔවුන් Tomcat භාවිතයෙන් යෙදුම් සංවර්ධනය කළ සමාගම්වල සහ සාමාන්‍ය Tomcat දෝෂ ලොග හැර, ඔවුන්ගේම කිසිදු ප්‍රමිතික, සේවා ක්‍රියාකාරකම්වල ලඝු-සටහන් කිසිවක් සපයා නැත. සමහර සංවර්ධකයින් උදේ 3:15 ට කියවීමට තරම් අවාසනාවන්ත පද්ධති පරිපාලකයාට කිසිවක් අදහස් නොකරන ලඝු-සටහන් රාශියක් ජනනය කරයි.

යෙදුම් අධීක්ෂණය ගැන ඉංජිනේරුවන් සැලකිලිමත් නොවන්නේ ඇයි?
ඡායාරූපයේ කර්තෘ ටිම් ගව් මත නොපෙනී

එවැනි නිෂ්පාදන නිකුත් කිරීමට ඉඩ සලසන පද්ධති ඉංජිනේරුවන් ද තත්ත්වය සඳහා යම් වගකීමක් දැරිය යුතුය. එම ප්‍රමිතිකවල සන්දර්භය සහ යෙදුම් ක්‍රියාකාරකම් අනුව ඒවා අර්ථකථනය කිරීමේ හැකියාව නොමැතිව, ලඝු-සටහන් වලින් අර්ථවත් ප්‍රමිතික උකහා ගැනීමට උත්සාහ කිරීමට පද්ධති ඉංජිනේරුවන් කිහිප දෙනෙකුට කාලය හෝ සැලකිල්ලක් ඇත. "යමක් දැනට (හෝ ඉක්මනින් සිදුවනු ඇත) වැරදියි" යන දර්ශක හැර, එයින් ප්‍රයෝජන ගත හැක්කේ කෙසේදැයි සමහරුන්ට වැටහෙන්නේ නැත.

ප්‍රමිතික අවශ්‍යතාවය පිළිබඳ චින්තනයේ වෙනසක් සංවර්ධකයින් අතර පමණක් නොව පද්ධති ඉංජිනේරුවන් අතර ද සිදුවිය යුතුය.

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

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

මෙය දේ වෙන් කරයි

devops මානසිකත්වය සංවර්ධනය (dev) සහ මෙහෙයුම් (ops) චින්තනය අතර සහජීවනය විස්තර කරයි. "Devops" කිරීමට හිමිකම් කියන ඕනෑම සමාගමක් කළ යුත්තේ:

  1. ඔවුන් බොහෝ විට නොකරන දේවල් පැවසීම (The Princess Bride meme වෙත යොමු කරමින් - "මම හිතන්නේ ඒකෙන් ඔබ අදහස් කරන දේ අදහස් වෙන්නේ නැහැ!")
  2. අඛණ්ඩ නිෂ්පාදන වැඩිදියුණු කිරීමේ ආකල්පයක් දිරිමත් කරන්න.

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

වමට යන්න, වමට, මම කිව්වා LEEEE-

මට නම්, Devops හි එක් ප්‍රධාන මූලධර්මයක් වන්නේ "වමට මාරුවීම" යන්නයි. මෙම සන්දර්භය තුළ වමට මාරුවීම යන්නෙන් අදහස් වන්නේ හැකියාව මාරු කිරීමයි (වගකීමක් නැත, නමුත් හැකියාවන් පමණි) මෘදුකාංග බෙදා හැරීමේ ජීවන චක්‍රයේ වම් පසින් කාර්ය සාධන ප්‍රමිතික නිර්මාණය කිරීම, ලඝු-සටහන් වඩාත් කාර්යක්ෂමව භාවිතා කිරීම යනාදී වශයෙන් පද්ධති ඉංජිනේරුවන් සාමාන්‍යයෙන් සැලකිලිමත් වන දේවල් කිරීමට.

යෙදුම් අධීක්ෂණය ගැන ඉංජිනේරුවන් සැලකිලිමත් නොවන්නේ ඇයි?
ඡායාරූපයේ කර්තෘ නිෂ්පාදකයින් විසින් NESA මත නොපෙනී

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

කෙටියෙන් කිවහොත්

  1. ඔබේ අශ්වයා වතුරට ගෙන යන්න. සංවර්ධකයින්ට තමන් විසින්ම වළක්වා ගත හැකි කරදර කොපමණ දැයි පෙන්වන්න, ඔවුන්ගේ යෙදුම් සඳහා නිවැරදි KPIs සහ ප්‍රමිතික හඳුනා ගැනීමට ඔවුන්ට උදවු කරන්න, එවිට CTO විසින් බැන වදින නිෂ්පාදන හිමිකරුගෙන් කෑගැසීම් අඩු වේ. මෘදු හා සන්සුන්ව ඔවුන් ආලෝකයට ගෙන එන්න. එය ක්‍රියාත්මක නොවන්නේ නම්, හැකි ඉක්මනින් යෙදුම් වලින් මෙම ප්‍රමිතික ලබා ගැනීම ක්‍රියාවට නැංවීම සඳහා ඔවුන්ට හෝ නිෂ්පාදන හිමිකරුට අල්ලස්, තර්ජනය සහ කැජෝල් කරන්න, ඉන්පසු රූප සටහන් අඳින්න. එය ප්‍රමුඛතාවයක් ලෙස නොසැලකෙන බැවින් මෙය දුෂ්කර වනු ඇති අතර නිෂ්පාදන මාර්ග සිතියමේ බොහෝ ආදායම් උත්පාදන ව්‍යාපෘති ඉතිරිව පවතී. එබැවින්, නිෂ්පාදනයට අධීක්‍ෂණය ක්‍රියාත්මක කිරීමට වැය කරන කාලය සහ වියදම සාධාරණීකරණය කිරීමට ඔබට ව්‍යාපාරික නඩුවක් අවශ්‍ය වනු ඇත.
  2. පද්ධති ඉංජිනේරුවන්ට සුවදායක නින්දක් ලබා ගැනීමට උදවු කරන්න. ඕනෑම නිෂ්පාදනයක් නිකුත් කිරීම සඳහා "අපි මුදාහරිමු" පිරික්සුම් ලැයිස්තුවක් භාවිතා කිරීම හොඳ දෙයක් බව ඔවුන්ට පෙන්වන්න. නිෂ්පාදනයේ ඇති සියලුම යෙදුම් ප්‍රමිතික වලින් ආවරණය කර ඇති බවට වග බලා ගැනීම සංවර්ධකයින්ට වැරදී යන්නේ කුමක්ද සහ කොතැනද යන්න බැලීමට ඉඩ දීමෙන් ඔබට රාත්‍රියේ වඩා හොඳින් නිදා ගැනීමට උපකාරී වේ. කෙසේ වෙතත්, ඕනෑම සංවර්ධකයෙකු, නිෂ්පාදන හිමිකරුවෙකු හෝ CTO කුපිත කිරීමට සහ කලකිරීමට පත් කිරීමට නිවැරදි ක්‍රමය නම් නොනැසී පැවතීම සහ ප්‍රතිරෝධය දැක්වීමයි. ඔබ නැවත අවසන් මිනිත්තුව තෙක් රැඳී සිටියහොත් මෙම හැසිරීම ඕනෑම නිෂ්පාදනයක් නිකුත් කරන දිනයට බලපානු ඇත, එබැවින් නැවත වමට ගොස් මෙම ගැටළු හැකි ඉක්මනින් ඔබේ ව්‍යාපෘති සැලැස්මට ලබා ගන්න. අවශ්ය නම්, නිෂ්පාදන රැස්වීම් සඳහා ඔබේ මාර්ගය සකස් කරන්න. ව්යාජ උඩු රැවුලක් සහ හැඟීමක් හෝ යමක් අඳින්න, එය කිසි විටෙකත් අසාර්ථක නොවනු ඇත. ඔබේ උත්සුකයන් සන්නිවේදනය කරන්න, පැහැදිලි ප්‍රතිලාභ නිරූපණය කරන්න, සහ ශුභාරංචිය ප්‍රකාශ කරන්න.
  3. සංවර්ධන (dev) සහ මෙහෙයුම් (ops) යන දෙකම නිෂ්පාදන ප්‍රමිතික රතු කලාපයට ගමන් කිරීමේ අර්ථය සහ ප්‍රතිවිපාක තේරුම් ගෙන ඇති බව සහතික කර ගන්න. නිෂ්පාදන සෞඛ්‍යයේ එකම භාරකරු ලෙස Ops හැර නොයන්න, සංවර්ධකයින් ද සම්බන්ධ වී ඇති බවට වග බලා ගන්න (#productsquads).
  4. ලඝු-සටහන් විශිෂ්ට දෙයක්, නමුත් ප්‍රමිතික ද එසේමය. ඒවා ඒකාබද්ධ කර, ඔබේ ලොග නිෂ්ඵල විශාල දැවෙන බෝලයක් තුළ කුණු කූඩයට ඉඩ නොදෙන්න. වෙනත් කිසිවෙකුට ඔවුන්ගේ ලඝු-සටහන් නොතේරෙන්නේ මන්දැයි සංවර්ධකයින්ට පැහැදිලි කර පෙන්වන්න, උදේ 3:15 ට වැඩකට නැති ලොග දෙස බැලීම කෙබඳුදැයි ඔවුන්ට පෙන්වන්න.

යෙදුම් අධීක්ෂණය ගැන ඉංජිනේරුවන් සැලකිලිමත් නොවන්නේ ඇයි?
ඡායාරූපයේ කර්තෘ මාර්කෝ හෝර්වට් මත නොපෙනී

එච්චරයි. නව තොරතුරු ලබන සතියේ නිකුත් කෙරේ. ඔබ පාඨමාලාව ගැන වැඩිදුර ඉගෙන ගැනීමට කැමති නම්, අපි ඔබට ආරාධනා කරන්නෙමු විවෘත දිනය, සඳුදා සිදුවනු ඇත. දැන් අපි ඔබේ අදහස් සඳහා සම්ප්රදායිකව බලා සිටිමු.

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

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