পেজারডিউটি, বা কেন অপারেশন বিভাগ রাতে ঘুমাতে পারে না

সিস্টেমটি যত জটিল হবে, ততই এটি সব ধরণের সতর্কতার সাথে অতিবৃদ্ধ হবে। এবং এই একই সতর্কতাগুলির প্রতিক্রিয়া করার প্রয়োজন, তাদের একত্রিত করা এবং তাদের কল্পনা করা। আমি মনে করি এটি এমন একটি পরিস্থিতি যা অনেকের কাছেই নার্ভাসনেস পর্যন্ত পরিচিত।

যে সমাধানটি নিয়ে আলোচনা করা হবে তা সবচেয়ে অপ্রত্যাশিত নয়, তবে অনুসন্ধানটি এই বিষয়ে একটি পূর্ণাঙ্গ নিবন্ধ ফেরত দেয় না।

তাই, আমি ফানকর্প-এর অভিজ্ঞতা শেয়ার করার সিদ্ধান্ত নিয়েছি এবং ডিউটি ​​প্রক্রিয়াটি কীভাবে গঠন করা হয়, কে কল করে, কেন এবং কীভাবে আপনি এই সমস্ত কিছু দেখতে পারেন সে সম্পর্কে কথা বলার সিদ্ধান্ত নিয়েছি।

PagerDuty কি?

সুতরাং, এই সমস্ত সমস্যা সমাধানের জন্য, আমরা একটি সুবিধাজনক টুল খুঁজতে শুরু করি। কিছু অনুসন্ধানের পর, আমরা পেজারডিউটি ​​বেছে নিয়েছি। PD আমাদের কাছে বিপুল সংখ্যক ইন্টিগ্রেশন এবং সেটিংস সহ একটি মোটামুটি সম্পূর্ণ এবং সংক্ষিপ্ত সমাধান বলে মনে হয়েছিল। সে কি পছন্দ করে?

সংক্ষেপে, PagerDuty হল একটি ঘটনা প্রক্রিয়াকরণ প্ল্যাটফর্ম যা বিভিন্ন ইন্টিগ্রেশনের মাধ্যমে ইনকামিং ঘটনাগুলিকে প্রক্রিয়া করতে পারে, ডিউটি ​​অর্ডার সেট আপ করতে পারে এবং তারপর ঘটনার স্তরের উপর নির্ভর করে ডিউটিতে থাকা ইঞ্জিনিয়ারকে সতর্ক করতে পারে (উচ্চ স্তরে - একটি কল, একটি নিম্ন স্তরে - অ্যাপ্লিকেশন / এসএমএস থেকে একটি ধাক্কা)।

ডিউটি ​​অফিসার কে?

এটি সম্ভবত PD সেট আপ শুরু করার প্রথম স্থান।

অন্যান্য কোম্পানির মতো ফানকর্পেও ডিউটি ​​অফিসারের সম্মানসূচক পদ রয়েছে। এটি দিনে একবার প্রকৌশলী থেকে প্রকৌশলীতে প্রেরণ করা হয়। PagerDuty থেকে একটি সতর্কতার প্রতিক্রিয়ার তথাকথিত প্রথম এবং দ্বিতীয় লাইন রয়েছে৷ ধরুন একটি উচ্চ-অগ্রাধিকার সতর্কতা আসে, এবং যদি প্রথম লাইন থেকে ডিউটি ​​ইঞ্জিনিয়ারের কাছে কল করার 10 মিনিট পরে এটিতে কোনও প্রতিক্রিয়া না হয় (অর্থাৎ, এটি স্বীকৃতি বা সমাধানের স্থিতিতে স্থানান্তরিত হয় না), কলটি দ্বিতীয়টিতে যায় ডিউটি ​​ইঞ্জিনিয়ার। এটিকে পেজারডিউটিতেই কনফিগার করা হয়েছে এসকেলেশন পলিসির মাধ্যমে।

দ্বিতীয় কর্তব্য কর্মকর্তা সাড়া না দিলে, বিজ্ঞপ্তিটি আবার ফিরে আসে প্রধান ডিউটি ​​অফিসারের কাছে।

এইভাবে, কোনো ইনকামিং উচ্চ অগ্রাধিকার সতর্কতা অপ্রক্রিয়াজাত করা যাবে না। 

এখন দেখা যাক ঘটনাগুলো কোথা থেকে আসতে পারে।

আমরা কি ইন্টিগ্রেশন ব্যবহার করি?

পিডি বিভিন্ন পরিষেবা থেকে অনেকগুলি বিভিন্ন ঘটনা গ্রহণ করে। আমাদের কাছে বর্তমানে এই ধরনের প্রায় 25টি পরিষেবা রয়েছে এবং সেগুলি প্রক্রিয়া করার জন্য আমরা কিছু রেডিমেড ইন্টিগ্রেশন ব্যবহার করি৷

• প্রমিথিউস

প্রধান মেট্রিক্স সংগ্রহ ব্যবস্থা প্রমিথিউস। Habré-এ এটি সম্পর্কে ইতিমধ্যে অনেক কিছু লেখা হয়েছে, আমি শুধু বলব যে আমাদের কাছে বিভিন্ন পরিবেশের জন্য তাদের বেশ কয়েকটি রয়েছে: একটি ভার্চুয়াল মেশিন এবং ডকার থেকে মেট্রিক্স সংগ্রহ করে, অন্যটি অ্যামাজন পরিষেবা থেকে, তৃতীয়টি হার্ডওয়্যার মেশিন থেকে। টেলিগ্রাফ প্রধানত একটি মেট্রিক্স রপ্তানিকারক হিসাবে ব্যবহৃত হয়।

• ই-মেইল

এখানেও আমার মনে হয়, শিরোনাম থেকেই সবকিছু পরিষ্কার। এই ইন্টিগ্রেশনটি ক্রোন দ্বারা সঞ্চালিত কিছু স্ক্রিপ্ট থেকে বিজ্ঞপ্তি পাঠাতে ব্যবহৃত হয়। PD আপনাকে একটি নির্দিষ্ট ঠিকানা দেয় যেখানে আপনি চিঠি পাঠান। এই জাতীয় একীকরণের সাথে একটি পরিষেবা তৈরি করার সময়, আপনি অগ্রাধিকার সেট করতে পারেন, আগত ঘটনাগুলি কী ক্রমে প্রক্রিয়া করা হবে, কীভাবে একটি সতর্কতা তৈরি করতে হবে (প্রতিটি আগত চিঠির জন্য, একটি আগত চিঠির জন্য + একটি নির্দিষ্ট নিয়ম ইত্যাদি)।

• ঢিলা

আমার মতে, একটি খুব আকর্ষণীয় ইন্টিগ্রেশন. এমন সময় আছে যখন কিছু ঘটে কিন্তু ঘটনা দ্বারা আচ্ছাদিত হয় না। অতএব, আমরা একটি ঘটনা তৈরি করতে স্ল্যাক থেকে একীকরণ যোগ করেছি। অর্থাৎ, আপনি কর্পোরেট স্ল্যাকে লিখতে পারেন /callofduty সবকিছু ধীরগতির এবং শীঘ্রই ভেঙ্গে যাবে এবং পিডি এটি প্রক্রিয়া করবে এবং ডিউটি ​​ইঞ্জিনিয়ারের কাছে ঘটনাটি পাঠাবে।

আমরা করি:

আমরা দেখি:

• এপিআই

HTTP ইন্টিগ্রেশন। আসলে, এখানে বিশেষ আকর্ষণীয় কিছু নেই, JSON ফর্ম্যাটে একটি বডি সহ একটি পোস্ট অনুরোধ। উদাহরণস্বরূপ, কিছু আকর্ষণীয়: আমরা এটি ব্যবহার করে বাহ্যিক নিরীক্ষণের জন্য ব্যবহার করি https://www.statuscake.com/. এই পরিষেবাটি বিশ্বের বিভিন্ন প্রান্ত থেকে আমাদের সাইটের অ্যাক্সেসযোগ্যতা পরীক্ষা করে। ক্ষেত্রে যখন আমরা একটি অগ্রহণযোগ্য প্রতিক্রিয়া কোড পাই (উদাহরণস্বরূপ, 502), একটি ঘটনা তৈরি হয় এবং তারপরে সবকিছু উপরে বর্ণিত চেইন অনুসরণ করে। StatusCake নিজেই অভ্যন্তরীণ URL, SSL শংসাপত্র বা ডোমেনের মেয়াদ শেষ হওয়া নিরীক্ষণ করার ক্ষমতা রাখে।

• LibreNMS

এটি আরেকটি মনিটরিং সিস্টেম, আপনি তাদের ওয়েবসাইটে এটি সম্পর্কে আরও পড়তে পারেন https://www.librenms.org/. এর সাহায্যে, আমরা সার্ভার থেকে নেটওয়ার্ক ইন্টারফেস এবং iDRAC নিরীক্ষণ করি।

ডেটাডগ, ক্লাউডওয়াচের মতো ইন্টিগ্রেশনও ছিল। আপনি তাদের কি ঘটেছে সম্পর্কে আরো দেখতে পারেন ঠিক এখানে.

ভিজ্যুয়ালাইজেশন

প্রধান ঘটনা রিপোর্টিং সিস্টেম স্ল্যাক. PD তে আসা সমস্ত ঘটনা একটি বিশেষ চ্যাটে লেখা হয় এবং যদি তাদের স্থিতি পরিবর্তিত হয় তবে এটি চ্যাটেও প্রদর্শিত হয়।

যখন সিলিং থেকে ঝুলন্ত মনিটরগুলির স্ক্রিনে দরকারী ডেটা প্রদর্শন করার সুযোগ আসে, তখন আমরা হঠাৎ বুঝতে পারি যে আমাদের (ডেভপস বিভাগে) তাদের প্রদর্শন করার মতো কিছুই নেই। একটি দুর্দান্ত গ্রাফানা রয়েছে, তবে এটি সমস্ত কিছুকে কভার করে না এবং কর্মীরা চার্টে নয়, সতর্কতায় প্রতিক্রিয়া জানায়।

PD-এর জন্য একটি সংক্ষিপ্ত এবং তথ্যপূর্ণ "বোর্ড"-এর জন্য GitHub-এ একটি পুঙ্খানুপুঙ্খ কিন্তু অসফল অনুসন্ধানের পর, আমরা আমাদের নিজস্ব লেখার সিদ্ধান্ত নিয়েছি - শুধুমাত্র আমাদের যা প্রয়োজন তা দিয়ে। যদিও প্রথমে PD ইন্টারফেস নিজেই প্রদর্শন করার একটি ধারণা ছিল, এটি আরও বেশি অসুবিধাজনক লাগছিল।

এটি লিখতে, আপনাকে যা করতে হবে তা হল শুধুমাত্র-পঠন-অধিকার সহ PD থেকে একটি কী প্রাপ্ত করা।
এবং আমরা যা পেয়েছি তা হল:

স্ক্রীনটি বর্তমান খোলা ঘটনা, নির্বাচিত সময়সূচী থেকে দায়িত্বরত বর্তমান প্রকৌশলীর নাম এবং উচ্চ অগ্রাধিকারের ঘটনা ছাড়া সময় প্রদর্শন করে (একটি উচ্চ অগ্রাধিকার ঘটনা সহ প্যানেলটি লাল রঙে হাইলাইট করা হবে)।

এখানে এই বাস্তবায়ন সূত্র দেখুন.

ফলস্বরূপ, আমরা আমাদের সমস্ত ঘটনা দেখার জন্য একটি সুবিধাজনক ড্যাশবোর্ড পেয়েছি। আপনাদের মধ্যে কেউ যদি আমাদের অভিজ্ঞতাকে কাজে লাগায় তাহলে আমি খুশি হব।

উত্স: www.habr.com