PagerDuty, හෝ මෙහෙයුම් දෙපාර්තමේන්තුවට රාත්‍රියේ නිදාගත නොහැක

පද්ධතිය වඩාත් සංකීර්ණ වන තරමට, එය සියලු ආකාරයේ ඇඟවීම් වලින් පිරී යයි. තවද මෙම ඇඟවීම් වලට ප්‍රතිචාර දැක්වීම, ඒවා එකතු කිරීම සහ ඒවා දෘශ්‍යමාන කිරීම අවශ්‍ය වේ. මම හිතන්නේ මෙය බොහෝ දෙනෙකුට චකිතයක් දක්වා හුරුපුරුදු තත්වයක් බවයි.

සාකච්ඡා කරනු ලබන විසඳුම වඩාත්ම අනපේක්ෂිත නොවේ, නමුත් සෙවීම මෙම මාතෘකාව පිළිබඳ සම්පූර්ණ ලිපියක් ලබා නොදේ.

එමනිසා, මම FunCorp හි අත්දැකීම් බෙදාහදා ගැනීමට සහ රාජකාරි ක්‍රියාවලිය ව්‍යුහගත කර ඇති ආකාරය, අමතන්නේ කවුරුන්ද, ඇයි සහ ඔබට ඒ සියල්ල දෙස බැලිය හැක්කේ කෙසේද යන්න ගැන කතා කිරීමට මම තීරණය කළෙමි.

PagerDuty, හෝ මෙහෙයුම් දෙපාර්තමේන්තුවට රාත්‍රියේ නිදාගත නොහැක

PagerDuty යනු කුමක්ද?

එබැවින්, මෙම සියලු ගැටළු විසඳීම සඳහා, අපි පහසු මෙවලමක් සෙවීමට පටන් ගත්තෙමු. ටිකක් සෙවීමෙන් පසුව, අපි PagerDuty තෝරා ගත්තෙමු. PD අපට පෙනුනේ ඒකාබද්ධ කිරීම් සහ සැකසුම් විශාල සංඛ්‍යාවක් සහිත තරමක් සම්පූර්ණ සහ සංක්ෂිප්ත විසඳුමක් ලෙසයි. ඇය මොන වගේද?

කෙටියෙන් කිවහොත්, PagerDuty යනු සිදුවීම් සැකසුම් වේදිකාවක් වන අතර එමඟින් විවිධ ඒකාබද්ධ කිරීම් හරහා පැමිණෙන සිදුවීම් සැකසීමට, රාජකාරි ඇණවුම් සැකසීමට සහ සිද්ධියේ මට්ටම අනුව (ඉහළ මට්ටමින් - ඇමතුමක්, පහළ මට්ටමක දී - රාජකාරියේ යෙදී සිටින ඉංජිනේරුවරයාට අනතුරු ඇඟවීමක් කළ හැකිය. යෙදුමෙන් තල්ලුවක් / SMS) .

රාජකාරි නිලධාරියා කවුද?

PD පිහිටුවීම ආරම්භ කළ යුතු පළමු ස්ථානය මෙය විය හැකිය.

FunCorp හි, අනෙකුත් සමාගම් මෙන්, රාජකාරි නිලධාරියෙකුගේ ගෞරවනීය තනතුරක් ඇත. එය දිනකට වරක් ඉංජිනේරුවෙකුගෙන් ඉංජිනේරුවෙකුට සම්ප්රේෂණය වේ. PagerDuty වෙතින් අනතුරු ඇඟවීමක් සඳහා ඊනියා පළමු සහ දෙවන ප්‍රතිචාර පේළියක් ඇත. ඉහළ ප්‍රමුඛතා ඇඟවීමක් පැමිණේ යැයි සිතමු, සහ පළමු පේළියේ සිට රාජකාරි නිලධාරියාට ඇමතුමෙන් විනාඩි 10 කට පසු එයට ප්‍රතිචාරයක් නොමැති නම් (එනම්, එය පිළිගැනීමට හෝ විසඳන ලද තත්ත්වයට මාරු නොකෙරේ), ඇමතුම දෙවැන්නට යයි. රාජකාරි ඉංජිනේරු. මෙය PagerDuty තුලම Escalation Policies හරහා වින්‍යාස කර ඇත.

PagerDuty, හෝ මෙහෙයුම් දෙපාර්තමේන්තුවට රාත්‍රියේ නිදාගත නොහැක

දෙවන රාජකාරි නිලධාරියා ප්‍රතිචාර නොදක්වන්නේ නම්, දැනුම්දීම නැවත පැමිණේ ප්රධාන රාජකාරි නිලධාරියාට.

මේ අනුව, පැමිණෙන ඕනෑම ඉහළ ප්‍රමුඛතා ඇඟවීමක් සැකසීමෙන් තොරව පැවතිය නොහැක. 

දැන් අපි බලමු සිද්ධි කොහෙන්ද එන්න පුළුවන් කියලා.

අපි භාවිතා කරන්නේ කුමන ඒකාබද්ධ කිරීම්ද?

PD හට විවිධ සේවාවන්ගෙන් විවිධ සිදුවීම් රැසක් ලැබේ. අප සතුව දැනට එවැනි සේවාවන් 25ක් පමණ ඇති අතර ඒවා සැකසීමට අපි සූදානම් කළ ඒකාබද්ධ කිරීම් කිහිපයක් භාවිතා කරමු.

  • Prometheus

ප්‍රධාන ප්‍රමිතික එකතු කිරීමේ පද්ධතිය Prometheus වේ. Habré හි දැනටමත් ඒ ගැන බොහෝ දේ ලියා ඇත, විවිධ පරිසරයන් සඳහා ඒවායින් කිහිපයක් අප සතුව ඇති බව මම කියමි: එකක් අතථ්‍ය යන්ත්‍ර සහ ඩොකර් වලින් ප්‍රමිතික එකතු කරයි, තවත් එකක් ඇමසන් සේවා වලින්, තෙවනුව දෘඩාංග යන්ත්‍ර වලින්. ටෙලිග්‍රාෆ් ප්‍රධාන වශයෙන් භාවිතා කරන්නේ මෙට්‍රික් අපනයනකරුවෙකු ලෙසය.

  • විද්යුත් තැපෑල

මෙහි ද මාතෘකාවෙන් සියල්ල පැහැදිලි යැයි සිතමි. ක්‍රෝන් මගින් ක්‍රියාත්මක කරන ලද සමහර ස්ක්‍රිප්ට් වලින් දැනුම්දීම් යැවීමට මෙම අනුකලනය භාවිතා කරයි. PD ඔබට ලිපි එවන නිශ්චිත ලිපිනයක් ලබා දෙයි. එවැනි ඒකාබද්ධතාවයකින් සේවාවක් නිර්මාණය කිරීමේදී, ඔබට ප්‍රමුඛතා සැකසිය හැකිය, එන සිදුවීම් සකසන්නේ කුමන අනුපිළිවෙලටද, හරියටම ඇඟවීමක් නිර්මාණය කරන්නේ කෙසේද (එන සෑම ලිපියක් සඳහාම, එන ලිපියක් සඳහා + නිශ්චිත රීතියක් යනාදිය).

PagerDuty, හෝ මෙහෙයුම් දෙපාර්තමේන්තුවට රාත්‍රියේ නිදාගත නොහැක

  • ඉල්ලූම

මගේ මතය අනුව, ඉතා රසවත් ඒකාබද්ධතාවයක්. යම් දෙයක් සිදු වූ නමුත් සිදුවීම්වලින් ආවරණය නොවන අවස්ථා තිබේ. එමනිසා, අපි සිදුවීමක් නිර්මාණය කිරීම සඳහා Slack වෙතින් අනුකලනය එකතු කළෙමු. එනම්, ඔබට ආයතනික Slack වෙත ලිවිය හැකිය /callofduty සියල්ල මන්දගාමී වන අතර ඉක්මනින් කැඩී යනු ඇත සහ PD විසින් එය සකස් කර රාජකාරි ඉංජිනේරුවරයාට සිද්ධිය යවනු ඇත.

අපි කරනවා:

PagerDuty, හෝ මෙහෙයුම් දෙපාර්තමේන්තුවට රාත්‍රියේ නිදාගත නොහැක

අපි දකිනවා:

PagerDuty, හෝ මෙහෙයුම් දෙපාර්තමේන්තුවට රාත්‍රියේ නිදාගත නොහැක

  • API

HTTP ඒකාබද්ධ කිරීම. ඇත්ත වශයෙන්ම, මෙහි විශේෂයෙන් රසවත් කිසිවක් නැත, JSON ආකෘතියෙන් ශරීරයක් සහිත POST ඉල්ලීමක් පමණි. උදාහරණයක් ලෙස, රසවත් දෙයක්: අපි එය බාහිර නිරීක්ෂණ සඳහා භාවිතා කරමු https://www.statuscake.com/. මෙම සේවාව ලෝකයේ විවිධ ප්‍රදේශවලින් අපගේ වෙබ් අඩවි වල ප්‍රවේශ්‍යතාව පරීක්ෂා කරයි. අපට පිළිගත නොහැකි ප්‍රතිචාර කේතයක් ලැබුණු විට (උදාහරණයක් ලෙස, 502), සිදුවීමක් නිර්මාණය වන අතර පසුව සියල්ල ඉහත විස්තර කර ඇති දාමය අනුගමනය කරයි. StatusCake හට අභ්‍යන්තර URL, SSL සහතිකය හෝ වසම් කල් ඉකුත්වීම නිරීක්ෂණය කිරීමේ හැකියාව ඇත.

  • LibreNMS

මෙය තවත් අධීක්ෂණ පද්ධතියකි, ඔබට ඒ ගැන වැඩි විස්තර ඔවුන්ගේ වෙබ් අඩවියෙන් කියවිය හැකිය https://www.librenms.org/. එහි ආධාරයෙන්, අපි සේවාදායකයන්ගෙන් ජාල අතුරුමුහුණත් සහ iDRAC නිරීක්ෂණය කරමු.

PagerDuty, හෝ මෙහෙයුම් දෙපාර්තමේන්තුවට රාත්‍රියේ නිදාගත නොහැක

Datadog, CloudWatch වැනි ඒකාබද්ධ කිරීම් ද විය. ඔවුන්ට සිදු වූ දේ ගැන ඔබට තවත් දැක ගත හැකිය මෙතන.

දෘශ්යකරණය

ප්‍රධාන සිදුවීම් වාර්තා කිරීමේ පද්ධතිය Slack වේ. PD වෙත එන සියලුම සිද්ධීන් විශේෂ කතාබස් එකකට ලියා ඇති අතර, ඒවායේ තත්ත්වය වෙනස් වුවහොත්, මෙයද කතාබස් තුළ පෙන්වයි.

PagerDuty, හෝ මෙහෙයුම් දෙපාර්තමේන්තුවට රාත්‍රියේ නිදාගත නොහැක

සිවිලිමෙන් එල්ලෙන මොනිටරවල තිරවල ප්‍රයෝජනවත් දත්ත පෙන්වීමට අවස්ථාව උදා වූ විට, අපට (devops දෙපාර්තමේන්තුවේ) ඒවා ප්‍රදර්ශනය කිරීමට කිසිවක් නොමැති බව අපට හදිසියේම වැටහුණි. පුදුම Grafana ඇත, නමුත් එය සෑම දෙයක්ම ආවරණය නොකරන අතර, සේවකයින් ප්‍රස්ථාරවලට නොව අනතුරු ඇඟවීම් වලට ප්‍රතිචාර දක්වයි.

PD සඳහා සංක්ෂිප්ත සහ තොරතුරු සහිත “පුවරුවක්” සඳහා GitHub හි සම්පූර්ණ නමුත් අසාර්ථක සෙවීමකින් පසුව, අපි අපගේම ලිවීමට තීරණය කළෙමු - අපට අවශ්‍ය දේ සමඟ පමණි. මුලදී PD අතුරුමුහුණත ප්රදර්ශනය කිරීමට අදහසක් තිබුණද, එය වඩාත් අපහසු විය.

එය ලිවීමට, ඔබ කළ යුත්තේ කියවීමට පමණක් හිමිකම් ඇති PD එකකින් යතුරක් ලබා ගැනීමයි.
මෙන්න අපට ලැබුණු දේ:

PagerDuty, හෝ මෙහෙයුම් දෙපාර්තමේන්තුවට රාත්‍රියේ නිදාගත නොහැක

තිරයේ වත්මන් විවෘත සිදුවීම්, තෝරාගත් කාලසටහනෙන් රාජකාරියේ සිටින වත්මන් ඉංජිනේරුවරයාගේ නම සහ ඉහළ ප්‍රමුඛතා සිදුවීමකින් තොරව කාලය පෙන්වයි (ඉහළ ප්‍රමුඛතා සිදුවීමක් සහිත පැනලය රතු පැහැයෙන් උද්දීපනය කෙරේ).

මෙම ක්‍රියාත්මක කිරීමේ මූලාශ්‍ර මෙතැනින් බලන්න.

එහි ප්‍රතිඵලයක් වශයෙන්, අපගේ සියලු සිදුවීම් බැලීම සඳහා පහසු උපකරණ පුවරුවක් අපට ලැබුණි. ඔබගෙන් සමහරෙකුට අපගේ අත්දැකීම ප්‍රයෝජනවත් වේ නම් මම සතුටු වෙමි.

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

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