2008 සිට, අපගේ සමාගම මූලික වශයෙන් යටිතල පහසුකම් කළමනාකරණය සහ වෙබ් ව්‍යාපෘති සඳහා පැය-400 තාක්ෂණික සහායෙහි නිරත වී ඇත: අපට සේවාදායකයින් 15 කට වඩා ඇත, එය රුසියානු ඊ-වාණිජ්‍යයෙන් 15% ක් පමණ වේ. ඒ අනුව ඉතා විවිධාකාර ගෘහනිර්මාණ ශිල්පයට සහාය වේ. යමක් වැටුණොත්, විනාඩි XNUMX ක් ඇතුළත එය නිවැරදි කිරීමට අපි බැඳී සිටිමු. නමුත් අනතුරක් සිදුවී ඇති බව වටහා ගැනීම සඳහා, ඔබ ව්යාපෘතිය නිරීක්ෂණය කළ යුතු අතර සිදුවීම් වලට ප්රතිචාර දැක්විය යුතුය. මෙය කරන්නේ කෙසේද?
නිසි නිරීක්ෂණ පද්ධතියක් සංවිධානය කිරීමේ ගැටලුවක් පවතින බව මම විශ්වාස කරමි. කරදරයක් නොතිබුනේ නම්, මගේ කථාව එක් නිබන්ධනයකින් සමන්විත වනු ඇත: "කරුණාකර Prometheus + Grafana සහ ප්ලගීන 1, 2, 3 ස්ථාපනය කරන්න." අවාසනාවකට මෙන්, එය තවදුරටත් එසේ ක්රියා නොකරයි. ඒවගේම ප්‍රධානම ප්‍රශ්නය තමයි 2008 වසරේ තිබුනු මෘදුකාංග සංරචක අනුව හැමෝම දිගටම විශ්වාස කරන එක.
අධීක්ෂණ පද්ධතියේ සංවිධානය සම්බන්ධයෙන්, මම කියන්නට උත්සාහ කරන්නේ ... දක්ෂ අධීක්ෂණයක් සහිත ව්‍යාපෘති නොපවතී. තත්වය කෙතරම් නරකද යත්, යමක් වැටුණහොත්, එය නොපෙනී යාමේ අවදානමක් ඇත - සියල්ලට පසු, “සියල්ල නිරීක්ෂණය කරනු ලබන” බව සෑම කෙනෙකුටම විශ්වාසයි.
සමහර විට සෑම දෙයක්ම නිරීක්ෂණය කරනු ලැබේ. නමුත් කෙසේද?
පහත දැක්වෙන ආකාරයේ කථාවක් අප සියල්ලන්ටම හමු වී ඇත: එක්තරා devops, යම් පරිපාලකයෙකු වැඩ කරයි, සංවර්ධන කණ්ඩායමක් ඔවුන් වෙත පැමිණ පවසයි - "අපි නිදහස්, දැන් නිරීක්ෂණය කරන්න." කුමක් නිරීක්ෂණය කරන්න? එය ක්රියා කරන්නේ කෙසේද?
හරි. අපි පැරණි ආකාරයෙන් නිරීක්ෂණය කරමු. එය දැනටමත් වෙනස් වෙමින් පවතින අතර, ඔබ A සේවාව නිරීක්ෂණය කළ බව පෙනේ, එය සේවා B බවට පත් වූ අතර එය C සේවාව සමඟ අන්තර් ක්රියා කරයි. නමුත් සංවර්ධන කණ්ඩායම ඔබට පවසන්නේ: "මෘදුකාංගය ස්ථාපනය කරන්න, එය සියල්ල නිරීක්ෂණය කළ යුතුය!"
එසේ නම් වෙනස් වී ඇත්තේ කුමක්ද? - හැම දෙයක්ම වෙනස් වෙලා!
2008 හැම දෙයක්ම හොඳයි
සංවර්ධකයින් කිහිප දෙනෙකු, එක් සේවාදායකයක්, එක් දත්ත සමුදා සේවාදායකයක් ඇත. ඔක්කොම යන්නේ මෙතනින්. අපට යම් තොරතුරු තිබේ, අපි zabbix, Nagios, cacti ස්ථාපනය කරමු. ඉන්පසු අපි CPU, තැටි ක්‍රියාකාරිත්වය සහ තැටි අවකාශය මත පැහැදිලි ඇඟවීම් සකස් කරමු. වෙබ් අඩවිය ප්රතිචාර දක්වන බව සහ දත්ත ගබඩාවට ඇණවුම් පැමිණෙන බව සහතික කිරීම සඳහා අපි අතින් පරීක්ෂණ කිහිපයක් ද සිදු කරන්නෙමු. එපමණයි - අපි අඩු හෝ වැඩි වශයෙන් ආරක්ෂිතයි.
අපි පරිපාලක විසින් අධීක්ෂණය ලබා දීම සඳහා කරන ලද වැඩ ප්රමාණය සංසන්දනය කළහොත්, ඉන් 98% ස්වයංක්රියව සිදු විය: නිරීක්ෂණය කරන පුද්ගලයා Zabbix ස්ථාපනය කරන්නේ කෙසේද, එය වින්යාසගත කරන්නේ කෙසේද සහ ඇඟවීම් වින්යාසගත කරන්නේ කෙසේද යන්න තේරුම් ගත යුතුය. සහ 2% - බාහිර චෙක්පත් සඳහා: වෙබ් අඩවිය ප්රතිචාර දක්වයි සහ දත්ත ගබඩාවට ඉල්ලීමක් කරයි, නව ඇණවුම් පැමිණ ඇත.
2010 බර වැඩෙමින් පවතී
අපි සෙවුම් යන්ත්‍රයක් එකතු කරමින් වෙබය පරිමාණය කිරීමට පටන් ගනිමු. නිෂ්පාදන නාමාවලියෙහි සියලුම නිෂ්පාදන අඩංගු බව සහතික කර ගැනීමට අපට අවශ්‍යය. තවද එම නිෂ්පාදන සෙවීම ක්රියා කරයි. දත්ත සමුදාය ක්රියා කරන බව, ඇණවුම් සිදු කරන බව, වෙබ් අඩවිය බාහිරව ප්රතිචාර දක්වන බවත්, සේවාදායකයන් දෙකකින් ප්රතිචාර දක්වන බවත්, වෙනත් සේවාදායකයකට නැවත සමතුලිත වන විට පරිශීලකයා වෙබ් අඩවියෙන් නෙරපා හරින්නේ නැති බවත් යනාදිය. තව ආයතන තියෙනවා.
එපමණක් නොව, යටිතල පහසුකම් හා සම්බන්ධ ආයතනය තවමත් කළමනාකරුගේ හිසෙහි විශාලතම ලෙස පවතී. මගේ ඔළුවේ තාම අදහසක් තියෙනවා මොනිටර් කරන කෙනා තමයි zabbix ස්ථාපනය කරලා configure කරන්න පුළුවන් කෙනා කියලා.
නමුත් ඒ සමඟම, බාහිර චෙක්පත් පැවැත්වීම, සෙවුම් දර්ශක විමසුම් ස්ක්රිප්ට් කට්ටලයක් නිර්මාණය කිරීම, සුචිගත කිරීමේ ක්‍රියාවලියේදී සෙවුම වෙනස් වන්නේ දැයි පරීක්ෂා කිරීමට ස්ක්රිප්ට් කට්ටලයක්, භාණ්ඩ මාරු කරන්නේ දැයි පරීක්ෂා කරන ස්ක්රිප්ට් කට්ටලයක් වැනි කාර්යයන් දිස්වේ. බෙදා හැරීමේ සේවාව, ආදිය. සහ යනාදි.
සටහන: මම "ස්ක්රිප්ට් කට්ටලයක්" 3 වතාවක් ලිව්වා. එනම්, අධීක්ෂණය සඳහා වගකිව යුතු පුද්ගලයා තවදුරටත් සරලව zabbix ස්ථාපනය කරන තැනැත්තා නොවේ. මෙය කේතනය ආරම්භ කරන පුද්ගලයෙකි. නමුත් තවමත් කණ්ඩායමේ මනසෙහි කිසිවක් වෙනස් වී නැත.
නමුත් ලෝකය වෙනස් වෙමින් පවතී, වඩ වඩාත් සංකීර්ණ වෙමින් පවතී. අථත්‍යකරණ ස්ථරයක් සහ නව පද්ධති කිහිපයක් එකතු වේ. ඔවුන් එකිනෙකා සමඟ අන්තර් ක්රියා කිරීමට පටන් ගනී. “ක්ෂුද්‍ර සේවා සුවඳක්” යැයි කීවේ කවුද? නමුත් සෑම සේවාවක්ම තවමත් තනි තනිව වෙබ් අඩවියක් ලෙස පෙනේ. අපට එය වෙත හැරී එය අවශ්ය තොරතුරු සපයන අතර එය තනිවම ක්රියා කරන බව තේරුම් ගත හැකිය. ඔබ වසර 5-7-10 ක් තිස්සේ සංවර්ධනය වෙමින් පවතින ව්‍යාපෘතියකට නිරන්තරයෙන් සම්බන්ධ වන පරිපාලකයෙකු නම්, මෙම දැනුම එකතු වේ: නව මට්ටමක් දිස්වේ - ඔබ එය තේරුම් ගත්තා, වෙනත් මට්ටමක් දිස්වේ - ඔබ එය තේරුම් ගත්තා ...
නමුත් කලාතුරකින් කෙනෙක් අවුරුදු 10ක් ව්යාපෘතියක් එක්ක යන්නේ නැහැ.
නිරීක්ෂකයාගේ ජීව දත්ත පත්‍රය
ඔබ වහාම සංවර්ධකයින් 20 දෙනෙකු කුලියට ගත් නව ආරම්භයකට පැමිණ, ක්ෂුද්‍ර සේවා 15 ක් ලියා ඇති අතර, ඔබ පරිපාලකයෙකු යැයි කියනු ලැබේ: “CI/CD සාදන්න. කරුණාකර." ඔබ CI/CD ගොඩනගා ඇති අතර හදිසියේම ඔබට ඇසෙන්නේ: "අපට "කියුබ්" තුළ නිෂ්පාදනය සමඟ වැඩ කිරීම අපහසුය, යෙදුම එහි ක්රියා කරන්නේ කෙසේද යන්න තේරුම් නොගෙන. එකම "කියුබ්" තුළ අපට වැලිපිල්ලක් සාදන්න.
ඔබ මෙම ඝනකයේ වැලිපිල්ලක් සාදන්න. ඔවුන් වහාම ඔබට කියයි: “අපට අවශ්ය වන්නේ නිෂ්පාදනයේ සිට සෑම දිනකම යාවත්කාලීන වන වේදිකා දත්ත සමුදායක් අවශ්ය වන අතර එමඟින් එය දත්ත ගබඩාවේ ක්රියා කරන බව අපට වැටහෙන නමුත් ඒ සමඟම නිෂ්පාදන දත්ත ගබඩාව නරක් නොකරනු ඇත.”
ඔබ මේ සියල්ල තුළ ජීවත් වේ. මුදා හැරීමට පෙර සති 2 ක් ඉතිරිව ඇත, ඔවුන් ඔබට පවසන්නේ: "දැන් අපි මේ සියල්ල නිරීක්ෂණය කරමු ..." එනම්. පොකුරු යටිතල ව්‍යුහය නිරීක්ෂණය කරන්න, ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පය නිරීක්ෂණය කරන්න, බාහිර සේවාවන් සමඟ වැඩ අධීක්ෂණය කරන්න...
මගේ සගයන් සුපුරුදු යෝජනා ක්‍රමය ඔවුන්ගේ හිසෙන් ඉවතට ගෙන මෙසේ කියයි: “හොඳයි, මෙහි සියල්ල පැහැදිලිය! මේ සියල්ල නිරීක්ෂණය කරන වැඩසටහනක් ස්ථාපනය කරන්න. ඔව්, ඔව්: Prometheus + Grafana + ප්ලගින.
ඔවුන් එකතු කරන්නේ: "ඔබට සති දෙකක් තිබේ, සෑම දෙයක්ම ආරක්ෂිත බවට වග බලා ගන්න."
අපි දකින ගොඩක් ව්‍යාපෘතිවල නිරීක්ෂණ කටයුතු සඳහා එක් අයකු වෙන් කරනවා. අපි සති 2 ක් සඳහා නිරීක්ෂණ කටයුතු සඳහා පුද්ගලයෙකු බඳවා ගැනීමට අවශ්ය බව සිතන්න, අපි ඔහු සඳහා ජීව දත්ත පත්රයක් ලියන්නෙමු. අප මෙතෙක් පැවසූ සෑම දෙයක්ම ලබා දී මෙම පුද්ගලයාට තිබිය යුතු කුසලතා මොනවාද?
- යකඩ යටිතල ව්‍යුහයේ ක්‍රියාකාරිත්වයේ අධීක්ෂණය සහ විශේෂතා ඔහු තේරුම් ගත යුතුය.
- ඔහු Kubernetes අධීක්ෂණය කිරීමේ විශේෂතා තේරුම් ගත යුතුය (සහ සෑම කෙනෙකුටම “කියුබ්” වෙත යාමට අවශ්‍යය, මන්ද ඔබට සෑම දෙයකින්ම වියුක්ත කළ හැකි, සැඟවීමට, පරිපාලකයා ඉතිරිය සමඟ කටයුතු කරන බැවින්) - එයම, එහි යටිතල පහසුකම් සහ යෙදුම් නිරීක්ෂණය කරන්නේ කෙසේද යන්න තේරුම් ගත යුතුය. තුල.
- සේවා එකිනෙකා සමඟ විශේෂ ආකාරවලින් සන්නිවේදනය කරන බව ඔහු තේරුම් ගත යුතු අතර, සේවා එකිනෙකා සමඟ අන්තර් ක්රියා කරන ආකාරය පිළිබඳ විශේෂතා දැන සිටිය යුතුය. වෙනත් මාර්ගයක් නොමැති නිසා සමහර සේවාවන් සමමුහුර්තව සන්නිවේදනය කරන ව්යාපෘතියක් දැකිය හැකිය. උදාහරණයක් ලෙස, පසුපෙළ REST හරහා, gRPC හරහා නාමාවලි සේවාව වෙත ගොස්, නිෂ්පාදන ලැයිස්තුවක් ලබාගෙන එය ආපසු ලබා දෙයි. ඔයාට මෙතන ඉන්න බෑ. සහ අනෙකුත් සේවාවන් සමඟ එය අසමමුහුර්තව ක්රියා කරයි. ඇණවුම බෙදා හැරීමේ සේවාවට මාරු කිරීම, ලිපියක් යැවීම යනාදිය.
මේ සියල්ලෙන් ඔබ දැනටමත් පිහිනා ඇති? අනික මේක මොනිටර් කරන්න ඕන ඇඩ්මින් තවත් අවුල් වුනා. - වැඩ වැඩි වන විට - ඔහු නිවැරදිව සැලසුම් කිරීමට සහ සැලසුම් කිරීමට හැකි විය යුතුය.
- එබැවින් ඔහු විසින් නිර්මාණය කරන ලද සේවාවෙන් උපාය මාර්ගයක් නිර්මාණය කළ යුතු අතර, එය නිශ්චිතවම නිරීක්ෂණය කරන්නේ කෙසේදැයි තේරුම් ගත යුතුය. ඔහුට ව්‍යාපෘතියේ ගෘහනිර්මාණ ශිල්පය සහ එහි සංවර්ධනය පිළිබඳ අවබෝධයක් + සංවර්ධනයේදී භාවිතා කරන තාක්ෂණයන් පිළිබඳ අවබෝධයක් අවශ්ය වේ.
අපි සම්පූර්ණයෙන්ම සාමාන්‍ය අවස්ථාවක් මතක තබා ගනිමු: සමහර සේවාවන් PHP හි ඇත, සමහර සේවාවන් Go හි ඇත, සමහර සේවාවන් JS හි ඇත. ඔවුන් කෙසේ හෝ එකිනෙකා සමඟ වැඩ කරති. "ක්ෂුද්‍ර සේවා" යන යෙදුම පැමිණෙන්නේ මෙතැනින් ය: සංවර්ධකයින්ට සමස්තයක් ලෙස ව්යාපෘතිය තේරුම් ගත නොහැකි තනි පද්ධති බොහොමයක් තිබේ. කණ්ඩායමේ එක් කොටසක් JS හි සේවා ලියන අතර එය තනිවම ක්රියා කරන අතර පද්ධතියේ ඉතිරි කොටස ක්රියා කරන්නේ කෙසේදැයි නොදනී. අනෙක් කොටස Python හි සේවා ලියන අතර අනෙකුත් සේවාවන් ක්රියා කරන ආකාරය බාධා නොකරයි; ඔවුන් තමන්ගේම ප්‍රදේශයේ හුදකලා වේ. තුන්වෙනි එක තමයි PHP හෝ වෙනත් දෙයකින් සේවා ලිවීම.
මෙම පුද්ගලයින් 20 දෙනාම සේවා 15 කට බෙදා ඇති අතර, මේ සියල්ල තේරුම් ගත යුත්තේ එක් පරිපාලකයෙකු පමණි. නවත්වන්න! පුද්ගලයන් 15 දෙනෙකුට සම්පූර්ණ පද්ධතිය තේරුම් ගත නොහැකි නිසා අපි පද්ධතිය ක්ෂුද්‍ර සේවා 20 කට බෙදා ඇත.
නමුත් එය කෙසේ හෝ නිරීක්ෂණය කළ යුතුය ...
ප්රතිඵලය කුමක්ද? එහි ප්‍රතිඵලයක් වශයෙන්, සමස්ත සංවර්ධකයින්ගේ කණ්ඩායමට තේරුම් ගත නොහැකි සෑම දෙයක්ම ඉදිරිපත් කරන එක් පුද්ගලයෙක් සිටින අතර, ඒ සමඟම අප ඉහත සඳහන් කළ දේ ඔහු දැන සිටිය යුතු අතර කිරීමට හැකි විය යුතුය - දෘඩාංග යටිතල පහසුකම්, කුබර්නෙටස් යටිතල පහසුකම් යනාදිය.
මම මොනවා කියන්නද... හූස්ටන්, අපිට ප්‍රශ්න තියෙනවා.
නවීන මෘදුකාංග ව්යාපෘතියක් අධීක්ෂණය කිරීම මෘදුකාංග ව්‍යාපෘතියකි
අධීක්ෂණය කියන්නේ මෘදුකාංගයක් කියන බොරු විශ්වාසයේ ඉඳන් අපි ආශ්චර්ය ගැන විශ්වාසයක් ගොඩනගා ගන්නවා. නමුත් ආශ්චර්යයන්, අහෝ, සිදු නොවේ. ඔබට zabbix ස්ථාපනය කළ නොහැකි අතර සෑම දෙයක්ම වැඩ කිරීමට බලාපොරොත්තු වේ. ග්‍රැෆනා ඉන්ස්ටෝල් කරලා ඔක්කොම හරි යයි කියලා හිතලා වැඩක් නෑ. සේවාවල ක්‍රියාකාරිත්වය සහ ඒවා එකිනෙකා සමඟ අන්තර්ක්‍රියා කිරීම, බාහිර පද්ධති ක්රියා කරන ආකාරය පරීක්ෂා කිරීම සංවිධානය කිරීම සඳහා වැඩි කාලයක් ගත කරනු ඇත. ඇත්ත වශයෙන්ම, කාලයෙන් 90% ක් වැය කරනු ලබන්නේ ස්ක්රිප්ට් ලිවීමට නොව මෘදුකාංග සංවර්ධනය සඳහා ය. තවද එය ව්‍යාපෘතියේ කාර්යය අවබෝධ කරගත් කණ්ඩායමක් විසින් හැසිරවිය යුතුය.
මෙම තත්වය තුළ එක් පුද්ගලයෙකු නිරීක්ෂණයට ඇද දැමුවහොත්, විපත්තිය සිදුවනු ඇත. හැමතැනම වෙන දේ තමයි.
උදාහරණයක් ලෙස, කෆ්කා හරහා එකිනෙකා සමඟ සන්නිවේදනය කරන සේවාවන් කිහිපයක් තිබේ. ඇණවුම ආවා, අපි කෆ්කාට ඇණවුම ගැන පණිවිඩයක් යැව්වා. ඇණවුම පිළිබඳ තොරතුරුවලට සවන් දී භාණ්ඩ නැව්ගත කරන සේවාවක් තිබේ. ඇණවුම පිළිබඳ තොරතුරු වලට සවන් දෙන සහ පරිශීලකයාට ලිපියක් යවන සේවාවක් තිබේ. ඉන්පසු තවත් සේවාවන් රාශියක් දිස්වන අතර අපි ව්‍යාකූල වීමට පටන් ගනිමු.
තවද ඔබ මෙය මුදා හැරීමට කෙටි කාලයක් ඉතිරිව ඇති වේදිකාවේදී පරිපාලක සහ සංවර්ධකයින්ට ලබා දෙන්නේ නම්, පුද්ගලයාට මෙම සම්පූර්ණ ප්‍රොටෝකෝලය තේරුම් ගැනීමට අවශ්ය වනු ඇත. එම. මෙම පරිමාණයේ ව්යාපෘතියක් සැලකිය යුතු කාලයක් ගත වන අතර, මෙය පද්ධති සංවර්ධනයට සාධක විය යුතුය.
නමුත් බොහෝ විට, විශේෂයෙන් ආරම්භක වලදී, පසුව නිරීක්ෂණය කිරීම කල් දමන ආකාරය අපි දකිමු. “දැන් අපි සංකල්පයේ සාධනයක් සාදන්නෙමු, අපි එය සමඟ දියත් කරන්නෙමු, එය වැටීමට ඉඩ දෙන්න - අපි කැප කිරීමට සූදානම්. ඊට පස්සේ අපි ඒ සියල්ල නිරීක්ෂණය කරන්නෙමු. ” ව්යාපෘතිය මුදල් ඉපයීමට පටන් ගත් විට (හෝ නම්) ව්‍යාපාරයට තවත් විශේෂාංග එකතු කිරීමට අවශ්ය වේ - එය ක්රියා කිරීමට පටන් ගෙන ඇති නිසා, එය තවදුරටත් ඉදිරියට ගෙන යා යුතුය! තවද ඔබ සිටින්නේ පෙර සියල්ල නිරීක්ෂණය කිරීමට අවශ්ය ස්ථානයේය, එය කාලයෙන් 1%ක් නොව තවත් බොහෝ දේ ගතවේ. මාර්ගය වන විට, අධීක්ෂණය සඳහා සංවර්ධකයින් අවශ්ය වනු ඇති අතර, නව විශේෂාංග මත වැඩ කිරීමට ඔවුන්ට ඉඩ දීම පහසුය. එහි ප්‍රතිඵලයක් වශයෙන්, නව විශේෂාංග ලියා ඇත, සෑම දෙයක්ම අවුල් වී ඇත, සහ ඔබ නිමක් නැති හිරවීමක සිටී.
ඉතින් ආරම්භයේ සිට ආරම්භ වන ව්යාපෘතියක් නිරීක්ෂණය කරන්නේ කෙසේද, සහ ඔබ නිරීක්ෂණය කළ යුතු ව්යාපෘතියක් ලබා ගන්නේ නම් කුමක් කළ යුතුද, නමුත් ඔබ ආරම්භ කළ යුත්තේ කොතැනින්ද?
පළමුව, ඔබ සැලසුම් කළ යුතුය.
ගීතමය අපගමනය: බොහෝ විට ඒවා යටිතල පහසුකම් අධීක්ෂණයෙන් ආරම්භ වේ. උදාහරණයක් ලෙස, අපට Kubernetes ඇත. ප්‍රොමිතියස් ග්‍රැෆානා සමඟ ස්ථාපනය කිරීමෙන්, “කියුබ්” අධීක්ෂණය සඳහා ප්ලගීන ස්ථාපනය කිරීමෙන් ආරම්භ කරමු. සංවර්ධකයින්ට පමණක් නොව, පරිපාලකයින්ට ද අවාසනාවන්ත භාවිතයක් ඇත: "අපි මෙම ප්ලගිනය ස්ථාපනය කරන්නෙමු, නමුත් ප්ලගිනය එය කරන්නේ කෙසේදැයි බොහෝ විට දනී." මිනිසුන් වැදගත් ක්‍රියාවන්ගෙන් පටන් ගන්නවාට වඩා සරල හා සරල දේවලින් පටන් ගැනීමට කැමතියි. සහ යටිතල පහසුකම් නිරීක්ෂණය කිරීම පහසුය.
පළමුව, ඔබට නිරීක්ෂණය කිරීමට අවශ්ය කුමක්ද සහ කෙසේද යන්න තීරණය කරන්න, පසුව මෙවලමක් තෝරන්න, මන්ද අන් අයට ඔබ ගැන සිතිය නොහැක. සහ ඔවුන් කළ යුතුද? අනෙක් අය විශ්වීය පද්ධතියක් ගැන තමන් ගැනම සිතුවා - නැතහොත් මෙම ප්ලගිනය ලියා ඇති විට කිසිසේත් සිතුවේ නැත. තවද මෙම ප්ලගිනයට පරිශීලකයින් 5 දහසක් සිටින නිසා එයින් කිසිදු ප්‍රයෝජනයක් ඇති බවක් අදහස් නොවේ. සමහර විට ඔබ 5001 වැනියා බවට පත්වනු ඇත්තේ මීට පෙර එහි පුද්ගලයන් 5000ක් සිටි නිසාය.
ඔබ යටිතල පහසුකම් නිරීක්ෂණය කිරීම ආරම්භ කළහොත් සහ ඔබේ යෙදුමේ පසුබිම ප්රතිචාර දැක්වීම නතර කළහොත්, සියලුම පරිශීලකයින්ට ජංගම යෙදුම සමඟ සම්බන්ධතාව අහිමි වනු ඇත. දෝෂයක් දිස්වනු ඇත. ඔවුන් ඔබ වෙත පැමිණ "යෙදුම වැඩ කරන්නේ නැත, ඔබ මෙහි කරන්නේ කුමක්ද?" - "අපි නිරීක්ෂණය කරනවා." - "යෙදුම ක්රියා නොකරන බව ඔබට නොපෙනේ නම් ඔබ නිරීක්ෂණය කරන්නේ කෙසේද?!"
- පරිශීලකයාගේ ඇතුල්වීමේ ස්ථානයේ සිට ඔබ නිරීක්ෂණය කිරීම ආරම්භ කළ යුතු බව මම විශ්වාස කරමි. යෙදුම ක්රියාත්මක වන බව පරිශීලකයා නොපෙනේ නම්, එය එයයි, එය අසාර්ථකයි. සහ අධීක්ෂණ පද්ධතිය මේ ගැන මුලින්ම අනතුරු ඇඟවිය යුතුය.
- එවිට පමණක් අපට යටිතල පහසුකම් නිරීක්ෂණය කළ හැකිය. නැතහොත් එය සමාන්තරව කරන්න. යටිතල පහසුකම් සමඟ එය පහසුයි - මෙන්න අපට අවසානයේ zabbix ස්ථාපනය කළ හැකිය.
- දේවල් ක්රියා නොකරන්නේ කොතැනද යන්න තේරුම් ගැනීමට දැන් ඔබ යෙදුමේ මූලයන් වෙත යා යුතුය.
මගේ ප්රධාන අදහස නම් සංවර්ධන ක්‍රියාවලියට සමාන්තරව නිරීක්ෂණ යා යුතු බවයි. ඔබ වෙනත් කාර්යයන් සඳහා අධීක්ෂණ කණ්ඩායමේ අවධානය වෙනතකට යොමු කළහොත් (CI/CD නිර්මාණය කිරීම, වැලිපිල්ල, යටිතල පහසුකම් ප්‍රතිසංවිධානය කිරීම), අධීක්ෂණය ප්‍රමාද වීමට පටන් ගන්නා අතර ඔබට කිසිදා සංවර්ධනයට හසු විය නොහැක (නැතහොත් ඉක්මනින් හෝ පසුව ඔබට එය නැවැත්වීමට සිදුවනු ඇත).
සෑම දෙයක්ම මට්ටම් අනුව
අධීක්ෂණ පද්ධතියක් සංවිධානය කිරීම මා දකින්නේ එලෙසයි.
1) යෙදුම් මට්ටම:
- යෙදුම් ව්යාපාර තර්කනය නිරීක්ෂණය කිරීම;
- සේවාවන්හි සෞඛ්‍ය ප්‍රමිතික නිරීක්ෂණය කිරීම;
- ඒකාබද්ධතා අධීක්ෂණය.
2) යටිතල පහසුකම් මට්ටම:
- වාද්‍ය වෘන්ද මට්ටම නිරීක්ෂණය කිරීම;
- පද්ධති මෘදුකාංග අධීක්ෂණය;
- යකඩ මට්ටම නිරීක්ෂණය කිරීම.
3) නැවතත් යෙදුම් මට්ටම - නමුත් ඉංජිනේරු නිෂ්පාදනයක් ලෙස:
- යෙදුම් ලොග් එකතු කිරීම සහ අධීක්ෂණය කිරීම;
- APM;
- ලුහුබැඳීම.
4) අනතුරු ඇඟවීම:
- අනතුරු ඇඟවීමේ පද්ධතියක් සංවිධානය කිරීම;
- රාජකාරි පද්ධතියක් සංවිධානය කිරීම;
- "දැනුම් පදනමක්" සංවිධානය කිරීම සහ සිදුවීම් සැකසීම සඳහා කාර්ය ප්රවාහය.
වැදගත්: අපි අනතුරු ඇඟවීමට යන්නේ පසුව නොව, වහාම! අධීක්ෂණය දියත් කිරීමට අවශ්ය නොවන අතර “කෙසේ හෝ පසුව” ඇඟවීම් ලැබෙන්නේ කාටදැයි සොයා බලන්න. සියල්ලට පසු, නිරීක්ෂණය කිරීමේ කාර්යය කුමක්ද: පද්ධතියේ යම් දෙයක් වැරදි ලෙස ක්රියා කරන්නේ කොතැනද යන්න තේරුම් ගැනීමට සහ නිවැරදි පුද්ගලයින්ට ඒ ගැන දැන ගැනීමට ඉඩ දෙන්න. මේක ඉවර වෙනකම්ම තියල ගියොත් හරි මිනිස්සු දැනගන්නේ "අපිට මොකුත් වැඩ කරන්නේ නෑ" කියල විතරයි මොකක් හරි අවුලක් වෙනව කියල.
යෙදුම් ස්තරය - ව්යාපාර තාර්කික අධීක්ෂණය
මෙන්න අපි කතා කරන්නේ යෙදුම පරිශීලකයා සඳහා ක්රියා කරන බව පරීක්ෂා කිරීම ගැන ය.
සංවර්ධන අවධියේදී මෙම මට්ටම සිදු කළ යුතුය. උදාහරණයක් ලෙස, අපට කොන්දේසි සහිත ප්‍රොමිතියස් ඇත: එය චෙක්පත් කරන සේවාදායකයට ගොස්, අන්ත ලක්ෂ්‍යය අදින්න, සහ අන්ත ලක්ෂ්‍යය ගොස් API පරීක්ෂා කරයි.
වෙබ් අඩවිය ක්රියා කරන බව සහතික කර ගැනීම සඳහා මුල් පිටුව නිරීක්ෂණය කිරීමට බොහෝ විට ඉල්ලා සිටින විට, ක්‍රමලේඛකයින් API ක්රියා කරන බව සහතික කර ගැනීමට අවශ්ය සෑම අවස්ථාවකම ඇද ගත හැකි හසුරුව ලබා දෙයි. මේ මොහොතේ ක්‍රමලේඛකයින් තවමත් /api/test/helloworld ගෙන ලියන්න
සෑම දෙයක්ම ක්රියාත්මක වන බව සහතික කර ගැනීමට ඇති එකම මාර්ගය? - නැත!
- එවැනි චෙක්පත් නිර්මාණය කිරීම සංවර්ධකයින්ගේ කර්තව්යය වේ. ඒකක පරීක්ෂණ ලිවිය යුත්තේ කේතය ලියන ක්‍රමලේඛකයින් විසිනි. මක්නිසාද යත්, ඔබ එය පරිපාලක වෙත කාන්දු කළහොත්, "මචං, මෙන්න සියලුම කාර්යයන් 25 සඳහා API ප්‍රොටෝකෝල ලැයිස්තුවක්, කරුණාකර සියල්ල නිරීක්ෂණය කරන්න!" - කිසිවක් සාර්ථක නොවනු ඇත.
- ඔබ “හෙලෝ වර්ල්ඩ්” මුද්‍රණය කරන්නේ නම්, API ක්රියා කළ යුතු සහ ක්රියා කරන බව කිසිවකු කිසිදා දැන නොගනු ඇත. සෑම API වෙනසක්ම චෙක්පත්වල වෙනසක් ඇති කළ යුතුය.
- ඔබට දැනටමත් එවැනි ගැටලුවක් තිබේ නම්, විශේෂාංග නවත්වන්න සහ මෙම චෙක්පත් ලියන සංවර්ධකයින් වෙන් කරන්න, නැතහොත් පාඩු පිළිගන්න, කිසිවක් පරීක්ෂා කර නැති අතර අසාර්ථක වනු ඇත.
තාක්ෂණික උපදෙස්:
- චෙක්පත් සංවිධානය කිරීම සඳහා බාහිර සේවාදායකයක් සංවිධානය කිරීමට වග බලා ගන්න - ඔබේ ව්යාපෘතිය බාහිර ලෝකයට ප්‍රවේශ විය හැකි බවට ඔබට සහතික විය යුතුය.
- තනි අන්ත ලක්ෂ්‍ය පමණක් නොව සම්පූර්ණ API ප්‍රොටෝකෝලය හරහා චෙක්පත් සංවිධානය කරන්න.
- පරීක්ෂණ ප්රතිඵල සමඟ prometheus-endpoint සාදන්න.
යෙදුම් ස්ථරය - සෞඛ්‍ය ප්‍රමිතික අධීක්ෂණය
දැන් අපි කතා කරන්නේ බාහිර සෞඛ්‍ය ප්‍රමිතික සේවා ගැන.
බාහිර අධීක්ෂණ පද්ධතියකින් අප හඳුන්වන බාහිර චෙක්පත් භාවිතයෙන් යෙදුමේ සියලුම "හැසිරුම්" නිරීක්ෂණය කිරීමට අපි තීරණය කළෙමු. නමුත් මේවා පරිශීලකයා "දකින" "හැන්ඩ්ල්" වේ. අපගේ සේවාවන්ම ක්රියාත්මක වන බවට සහතික වීමට අපට අවශ්‍යය. මෙහි වඩා හොඳ කතාවක් තිබේ: K8s සතුව සෞඛ්‍ය පරීක්ෂාවන් ඇත, එවිට අවම වශයෙන් "කියුබ්" සේවාව ක්රියාත්මක වන බව ඒත්තු ගැන්විය හැකිය. නමුත් මම දැක ඇති චෙක්පත් වලින් අඩක් එකම මුද්‍රණය “හෙලෝ වර්ල්ඩ්” ය. එම. එබැවින් ඔහු යෙදවීමෙන් පසු වරක් ඇදගෙන යයි, ඔහු පිළිතුරු දුන්නේ සියල්ල හොඳින් ඇති බවයි - එපමණයි. තවද සේවාව, එය තමන්ගේම API සපයන්නේ නම්, එම API සඳහා විශාල ප්‍රවේශ ලක්ෂ්‍ය සංඛ්‍යාවක් ඇත, එයද නිරීක්ෂණය කළ යුතුය, මන්ද එය ක්රියාත්මක වන බව අපට දැන ගැනීමට අවශ්ය වේ. අපි දැනටමත් එය ඇතුළත නිරීක්ෂණය කරමින් සිටිමු.
මෙය නිවැරදිව තාක්‍ෂණිකව ක්රියාත්මක කරන්නේ කෙසේද: සෑම සේවාවක්ම එහි වත්මන් ක්‍රියාකාරිත්වය පිළිබඳ අවසාන ලක්ෂ්‍යයක් හෙළිදරව් කරන අතර ග්‍රැෆනා (හෝ වෙනත් ඕනෑම යෙදුමක්) හි ප්‍රස්ථාරවල අපි සියලු සේවාවන්හි තත්ත්වය දකිමු.
- සෑම API වෙනසක්ම චෙක්පත්වල වෙනසක් ඇති කළ යුතුය.
- සෞඛ්‍ය ප්‍රමිතික සමඟ වහාම නව සේවාවක් සාදන්න.
- පරිපාලකයෙකුට සංවර්ධකයින් වෙත පැමිණ "මට විශේෂාංග කිහිපයක් එක් කරන්න එවිට මට සියල්ල තේරෙන අතර මගේ අධීක්ෂණ පද්ධතියට මේ පිළිබඳ තොරතුරු එක් කරන්න" යනුවෙන් ඉල්ලා සිටිය හැක. නමුත් සංවර්ධකයින් සාමාන්‍යයෙන් පිළිතුරු දෙන්නේ, “නිකුතුවට සති දෙකකට පෙර අපි කිසිවක් එකතු නොකරමු.”
එවැනි පාඩු සිදුවන බව සංවර්ධන කළමනාකරුවන්ට දන්වන්න, සංවර්ධන කළමනාකරුවන්ගේ කළමනාකාරිත්වය ද දන්වන්න. මක්නිසාද යත් සෑම දෙයක්ම වැටෙන විට, යමෙකු තවමත් අමතා "නිරන්තරයෙන් පහත වැටෙන සේවාව" (c) නිරීක්ෂණය කිරීමට ඉල්ලා සිටිනු ඇත. - මාර්ගය වන විට, Grafana සඳහා ප්ලගීන ලිවීමට සංවර්ධකයන්ට වෙන් කරන්න - මෙය පරිපාලකයින් සඳහා හොඳ උපකාරයක් වනු ඇත.
යෙදුම් ස්තරය - ඒකාබද්ධතා අධීක්ෂණය
ඒකාබද්ධතා අධීක්ෂණය ව්යාපාර-විවේචනාත්මක පද්ධති අතර සන්නිවේදන අධීක්ෂණය කෙරෙහි අවධානය යොමු කරයි.
උදාහරණයක් ලෙස, එකිනෙකා සමඟ සන්නිවේදනය කරන සේවා 15 ක් ඇත. මේවා තවදුරටත් වෙනම අඩවි නොවේ. එම. අපට සේවාව තනිවම ඇදගෙන, / හෙලෝවර්ල්ඩ් ලබා ගැනීමට සහ සේවාව ක්රියාත්මක වන බව තේරුම් ගත නොහැක. මක්නිසාද යත් ඇණවුම් කරන වෙබ් සේවාව බස් රථයට ඇණවුම පිළිබඳ තොරතුරු යැවිය යුතු බැවිනි - බස් රථයෙන්, ගබඩා සේවාවට මෙම පණිවිඩය ලැබී එය සමඟ තවදුරටත් වැඩ කළ යුතුය. විද්‍යුත් තැපැල් බෙදා හැරීමේ සේවාව මෙය කෙසේ හෝ තවදුරටත් ක්රියා කළ යුතුය.
ඒ අනුව, අපට තේරුම් ගත නොහැක, එක් එක් තනි පුද්ගල සේවයට පහර දීම, ඒ සියල්ල ක්රියාත්මක වන බව. මක්නිසාද යත් සෑම දෙයක්ම සන්නිවේදනය කරන සහ අන්තර් ක්රියා කරන නිශ්චිත බස් රථයක් අපට ඇති බැවිනි.
එබැවින්, මෙම අදියර අනෙකුත් සේවාවන් සමඟ අන්තර්ක්‍රියා කිරීම සඳහා පරීක්ෂණ සේවාවල අදියර සලකුණු කළ යුතුය. පණිවිඩ තැරැව්කරු නිරීක්ෂණය කිරීමෙන් සන්නිවේදන අධීක්ෂණය සංවිධානය කළ නොහැක. දත්ත නිකුත් කරන සේවාවක් සහ එය ලබා ගන්නා සේවාවක් තිබේ නම්, තැරැව්කරු නිරීක්ෂණය කිරීමේදී අපට පෙනෙන්නේ පැත්තෙන් පැත්තට පියාසර කරන දත්ත පමණි. මෙම දත්තවල අන්තර් ක්‍රියාකාරිත්වය අභ්‍යන්තරව නිරීක්ෂණය කිරීමට අප කෙසේ හෝ සමත් වුවද - යම් නිෂ්පාදකයෙකු දත්ත පළ කරයි, යමෙකු එය කියවයි, මෙම ප්රවාහය දිගටම කෆ්කා වෙත යයි - එක් සේවාවක් එක් අනුවාදයකින් පණිවිඩය යවා ඇත්නම් මෙය තවමත් අපට තොරතුරු ලබා නොදේ. , නමුත් අනෙක් සේවාව මෙම අනුවාදය අපේක්ෂා නොකළ අතර එය මඟ හැරියේය. සෑම දෙයක්ම ක්රියාත්මක වන බව සේවාවන් අපට පවසන බැවින් අපි මේ ගැන නොදනිමු.
මම නිර්දේශ කරන දේ:
- සමමුහුර්ත සන්නිවේදනය සඳහා: අවසාන ලක්ෂ්‍යය අදාළ සේවාවන් සඳහා ඉල්ලීම් කරයි. එම. අපි මෙම අන්ත ලක්ෂ්‍යය ලබාගෙන, සේවාව තුළ ස්ක්රිප්ට් එකක් අදින්න, එය සියලුම ලක්ෂ්‍ය වෙත ගොස් “මට එතනට අදින්න පුළුවන්, එතැනට අදින්න, මට එතැනට අදින්න පුළුවන්...”
- අසමමුහුර්ත සන්නිවේදනය සඳහා: පැමිණෙන පණිවිඩ - අවසාන ලක්ෂ්‍යය මඟින් පරීක්ෂණ පණිවිඩ සඳහා බස් රථය පරීක්ෂා කර සැකසුම් තත්ත්වය පෙන්වයි.
- අසමමුහුර්ත සන්නිවේදනය සඳහා: පිටතට යන පණිවිඩ - අන්ත ලක්ෂ්‍යය බස් රථයට පරීක්ෂණ පණිවිඩ යවයි.
සාමාන්‍යයෙන් සිදු වන පරිදි: බස් රථයට දත්ත විසි කරන සේවාවක් අප සතුව ඇත. අපි මෙම සේවාව වෙත පැමිණ එහි ඒකාබද්ධ සෞඛ්‍යය ගැන අපට පවසන ලෙස ඔබෙන් ඉල්ලා සිටිමු. තවද සේවාවට තව කොතැනක හෝ පණිවිඩයක් නිෂ්පාදනය කිරීමට අවශ්ය නම් (WebApp), එවිට එය මෙම පරීක්ෂණ පණිවිඩය නිපදවනු ඇත. අපි OrderProcessing පැත්තේ සේවාවක් ක්රියාත්මක කරන්නේ නම්, එය පළමුව ස්වාධීනව පළ කළ හැකි දේ පළ කරයි, සහ සමහර යැපෙන දේවල් තිබේ නම්, එය බස් රථයෙන් පරීක්ෂණ පණිවිඩ කට්ටලයක් කියවා, එය සැකසීමට හැකි බව තේරුම් ගනී, එය වාර්තා කරයි සහ , අවශ්ය නම්, ඒවා තවදුරටත් පළ කරන්න, මේ ගැන ඔහු පවසන්නේ - සියල්ල හරි, මම ජීවතුන් අතර.
බොහෝ විට අපට ඇසෙන්නේ "සටන් දත්ත මත මෙය පරීක්ෂා කරන්නේ කෙසේද?" උදාහරණයක් ලෙස, අපි එකම ඇණවුම් සේවාව ගැන කතා කරමු. ඇණවුම භාණ්ඩ ලියා ඇති ගබඩාවට පණිවිඩ යවයි: අපට මෙය සටන් දත්ත මත පරීක්ෂා කළ නොහැක, මන්ද “මගේ භාණ්ඩ කපා හරිනු ඇත!” විසඳුම: මෙම සම්පූර්ණ පරීක්ෂණය ආරම්භයේදීම සැලසුම් කරන්න. ඔබට සමච්චල් කරන ඒකක පරීක්ෂණ ද ඇත. එබැවින්, ව්යාපාරයේ ක්රියාකාරිත්වයට හානියක් නොවන සන්නිවේදන නාලිකාවක් ඇති ගැඹුරු මට්ටමින් එය කරන්න.
යටිතල පහසුකම් මට්ටම
යටිතල පහසුකම් අධීක්ෂණය යනු බොහෝ කලක සිට තමන් විසින්ම නිරීක්ෂණය කිරීම ලෙස සලකනු ලැබූ දෙයකි.
- යටිතල පහසුකම් අධීක්ෂණය වෙනම ක්‍රියාවලියක් ලෙස දියත් කළ හැකිය.
- ඔබට සැබවින්ම අවශ්ය වුවද, ක්රියාත්මක වන ව්‍යාපෘතියක යටිතල පහසුකම් නිරීක්ෂණය කිරීම ආරම්භ නොකළ යුතුය. මෙය සියලුම devops සඳහා වේදනාවකි. "පළමුව මම පොකුර නිරීක්ෂණය කරමි, මම යටිතල පහසුකම් නිරීක්ෂණය කරමි" - i.e. පළමුව, එය පහත ඇති දේ නිරීක්ෂණය කරනු ඇත, නමුත් යෙදුමට නොයනු ඇත. මොකද application එක devops වලට නොතේරෙන දෙයක්. එය ඔහුට කාන්දු වූ අතර, එය ක්රියා කරන්නේ කෙසේදැයි ඔහු තේරුම් නොගනී. ඔහු යටිතල පහසුකම් තේරුම් ගෙන එය ආරම්භ කරයි. නමුත් නැත - ඔබ සැමවිටම යෙදුම නිරීක්ෂණය කළ යුතුය.
- ඇඟවීම් ගණන ඉක්මවා නොයන්න. නවීන පද්ධතිවල සංකීර්ණත්වය සැලකිල්ලට ගනිමින්, අනතුරු ඇඟවීම් නිරන්තරයෙන් පියාසර කරන අතර, ඔබ කෙසේ හෝ මෙම ඇඟවීම් පොකුරක් සමඟ ජීවත් විය යුතුය. ඇමතුම් ලබන පුද්ගලයා, ඊළඟ ඇඟවීම් සියයක් දෙස බලා, "මට ඒ ගැන හිතන්න අවශ්ය නැහැ" කියා තීරණය කරයි. ඇඟවීම් තීරණාත්මක දේවල් ගැන පමණක් දැනුම් දිය යුතුය.
ව්යාපාර ඒකකයක් ලෙස යෙදුම් මට්ටම
ප්රධාන කරුණු:
- ELK මෙය කර්මාන්තයේ සම්මතයයි. කිසියම් හේතුවක් නිසා ඔබ ලඝු-සටහන් එකතු නොකරන්නේ නම්, වහාම එය ආරම්භ කරන්න.
- APM. යෙදුම් අධීක්ෂණය ඉක්මනින් වසා දැමීමේ මාර්ගයක් ලෙස බාහිර APMs (NewRelic, BlackFire, Datadog). ඔබට සිදුවන්නේ කුමක්ද යන්න අවම වශයෙන් කෙසේ හෝ තේරුම් ගැනීමට ඔබට මෙය තාවකාලිකව ස්ථාපනය කළ හැකිය.
- ලුහුබැඳීම. ක්ෂුද්‍ර සේවා දුසිම් ගණනක, ඉල්ලීම තවදුරටත් තනිවම නොපවතින බැවින් ඔබට සියල්ල සොයාගත යුතුය. පසුව එකතු කිරීම ඉතා අපහසු වේ, එබැවින් සංවර්ධනයේ ලුහුබැඳීම වහාම උපලේඛනගත කිරීම වඩා හොඳය - මෙය සංවර්ධකයින්ගේ කාර්යය සහ උපයෝගීතාවයයි. ඔබ තවමත් එය ක්රියාත්මක කර නොමැති නම්, එය ක්රියාත්මක කරන්න! ජේගර්/සිප්කින් බලන්න
අනතුරු අඟවයි
- දැනුම්දීම් පද්ධතියක් සංවිධානය කිරීම: දේවල් රාශියක් නිරීක්ෂණය කිරීමේ කොන්දේසි යටතේ, දැනුම්දීම් යැවීම සඳහා ඒකාබද්ධ පද්ධතියක් තිබිය යුතුය. ඔබට ග්‍රැෆානා හි කළ හැකිය. බටහිර රටවල හැමෝම PagerDuty පාවිච්චි කරනවා. ඇඟවීම් පැහැදිලි විය යුතුය (උදා: ඒවා පැමිණියේ කොහෙන්ද...). දැනුම්දීම් කිසිසේත්ම ලැබෙන බව පාලනය කිරීම සුදුසුය
- රාජකාරි පද්ධතියක් සංවිධානය කිරීම: අනතුරු ඇඟවීම් සෑම කෙනෙකුටම නොයැවිය යුතුය (එක්කෝ සෑම කෙනෙකුම සමූහයක් තුළ ප්රතිචාර දක්වනු ඇත, නැතහොත් කිසිවෙකු ප්රතිචාර නොදක්වනු ඇත). සංවර්ධකයින් ද ඇමතුම් ලබා ගත යුතුය: වගකීම් සහිත ක්ෂේත්‍ර නිර්වචනය කිරීමට වග බලා ගන්න, පැහැදිලි උපදෙස් ලබා දී සඳුදා සහ බදාදා හරියටම අමතන්නේ කාටද, අඟහරුවාදා සහ සිකුරාදා ඇමතිය යුත්තේ කාටද යන්න එහි ලියන්න (එසේ නොමැති නම් ඔවුන් කිසිවෙකුට කතා නොකරනු ඇත. විශාල ගැටලුවක සිදුවීමක් - ඔවුන් ඔබව අවදි කිරීමට හෝ බාධා කිරීමට බිය වනු ඇත: මිනිසුන් සාමාන්‍යයෙන් වෙනත් පුද්ගලයින් ඇමතීමට සහ අවදි කිරීමට කැමති නැත, විශේෂයෙන් රාත්‍රියේ). සහ උපකාරය ඉල්ලා සිටීම අකාර්යක්ෂමතාවයේ දර්ශකයක් නොවන බව පැහැදිලි කරන්න ("මම උදව් ඉල්ලනවා, ඒ කියන්නේ මම නරක සේවකයෙක්"), උදව් සඳහා ඉල්ලීම් දිරිමත් කරන්න.
- සිදුවීම් සැකසීම සඳහා "දැනුම පදනමක්" සංවිධානය කිරීම සහ කාර්ය ප්රවාහය: සෑම බරපතල සිදුවීමක් සඳහාම පශ්චාත් මරණ පරීක්ෂණයක් සැලසුම් කළ යුතු අතර, තාවකාලික පියවරක් ලෙස, සිද්ධිය විසඳන ක්රියාවන් වාර්තා කළ යුතුය. නැවත නැවත අනතුරු ඇඟවීම් පාපයක් බව පුරුද්දක් කර ගන්න. ඒවා කේත හෝ යටිතල පහසුකම් වැඩ වලදී සවි කළ යුතුය.
තාක්ෂණික තොගය
අපි හිතමු අපේ තොගය මෙහෙමයි කියලා.
- දත්ත එකතු කිරීම - Prometheus + Grafana;
- ලොග් විශ්ලේෂණය - ELK;
- APM හෝ Tracing සඳහා - Jaeger (Zipkin).
විකල්ප තේරීම තීරණාත්මක නොවේ. මක්නිසාද යත් මුලදී ඔබ පද්ධතිය නිරීක්ෂණය කරන්නේ කෙසේදැයි තේරුම් ගෙන සැලැස්මක් ලියා ඇත්නම්, ඔබ ඔබේ අවශ්‍යතාවලට ගැලපෙන මෙවලම් තෝරා ගැනීමට පටන් ගනී. ප්‍රශ්නය වන්නේ ඔබ මුලින්ම නිරීක්ෂණය කිරීමට තෝරාගත්තේ කුමක්ද යන්නයි. මක්නිසාද යත්, ඔබ ආරම්භයේදී තෝරාගත් මෙවලම ඔබේ අවශ්‍යතා කිසිසේත් නොගැලපෙන බැවිනි.
මෑතකදී මම සෑම තැනකම දකින තාක්ෂණික කරුණු කිහිපයක්:
ප්‍රොමිතියස්ව කුබර්නෙටස් ඇතුලට තල්ලු කරනවා - කවුද මේක ගෙනාවේ?! ඔබේ පොකුර කඩා වැටුණොත්, ඔබ කරන්නේ කුමක්ද? ඔබට ඇතුළත සංකීර්ණ පොකුරක් තිබේ නම්, පොකුර තුළ යම් ආකාරයක අධීක්ෂණ පද්ධතියක් තිබිය යුතු අතර, සමහරක් පිටත, පොකුර ඇතුළත දත්ත රැස් කරනු ඇත.
පොකුර ඇතුළත අපි ලඝු-සටහන් සහ අනෙකුත් සියල්ල එකතු කරමු. නමුත් නිරීක්ෂණ පද්ධතිය පිටත තිබිය යුතුය. බොහෝ විට, අභ්‍යන්තරව ස්ථාපනය කර ඇති Promtheus ඇති පොකුරක් තුළ, වෙබ් අඩවියේ ක්‍රියාකාරිත්වය පිළිබඳ බාහිර පරීක්ෂණ සිදු කරන පද්ධති ද ඇත. බාහිර ලෝකයට ඔබගේ සම්බන්ධතා පහත වැටී ඇති අතර යෙදුම ක්රියා නොකරන්නේ නම් කුමක් කළ යුතුද? ඇතුළත සෑම දෙයක්ම හොඳින් ඇති බව පෙනේ, නමුත් එය පරිශීලකයින්ට දේවල් පහසු නොකරයි.
සොයා ගැනීම්
- සංවර්ධන අධීක්ෂණය යනු උපයෝගිතා ස්ථාපනය කිරීම නොව, මෘදුකාංග නිෂ්පාදනයක් සංවර්ධනය කිරීමයි. අද නිරීක්ෂණ වලින් 98% ක් කේතීකරණය වේ. සේවාවන්හි කේතීකරණය, බාහිර චෙක්පත් කේතනය කිරීම, බාහිර සේවා පරීක්ෂා කිරීම සහ එපමණයි.
- නිරීක්ෂණ සඳහා ඔබේ සංවර්ධකයින්ගේ කාලය නාස්ති නොකරන්න: එය ඔවුන්ගේ කාර්යයෙන් 30% දක්වා ගත හැක, නමුත් එය වටිනවා.
- Devops, ඔබට යමක් නිරීක්ෂණය කළ නොහැකි බව කණගාටු නොවන්න, මන්ද සමහර දේවල් සම්පූර්ණයෙන්ම වෙනස් චින්තනයකි. ඔබ ක්‍රමලේඛකයෙකු නොවූ අතර, අධීක්ෂණ කටයුතු හරියටම ඔවුන්ගේ කාර්යයයි.
- ව්යාපෘතිය දැනටමත් ක්රියාත්මක වන අතර නිරීක්ෂණය නොකළේ නම් (සහ ඔබ කළමනාකරුවෙකු නම්), අධීක්ෂණය සඳහා සම්පත් වෙන් කරන්න.
- නිෂ්පාදිතය දැනටමත් නිෂ්පාදනයේ පවතී නම් සහ ඔබ "අධීක්ෂණය පිහිටුවීමට" පවසන ලද devops නම් - මා මේ සියල්ල ලියා ඇති දේ කළමනාකරණයට පැහැදිලි කිරීමට උත්සාහ කරන්න.
මෙය Saint Highload++ සමුළුවේ වාර්තාවේ දීර්ඝ අනුවාදයකි.
ඔබ ඒ පිළිබඳ මගේ අදහස් සහ සිතුවිලි සහ අදාළ මාතෘකා ගැන උනන්දුවක් දක්වන්නේ නම්, මෙහිදී ඔබට කළ හැකිය 🙂
මූලාශ්රය: www.habr.com