একজন সফ্টওয়্যার প্রকৌশলী হিসাবে, ঘটনাগুলি মোকাবেলা করা খুব খারাপ। শনিবার সকালে 3 টায় সেই অন-কল পৃষ্ঠাটি পাচ্ছেন? এটি ভয়-প্ররোচিত, আত্মা-চুষক এবং সম্পূর্ণরূপে একটি ঘৃণ্য পর্ব হতে পারে। এটি আপনার কর্মক্ষেত্রে ঘন ঘন ঘটলে, এটি বেশ আক্ষরিক অর্থেই PTSD প্ররোচিত করতে পারে।
দুর্ভাগ্যবশত, এটি সফ্টওয়্যার জিটজিস্টের একটি অংশ এবং পার্সেল। যদি কিছু থাকে তবে এই আগুন যার মাধ্যমে আসল প্রকৌশল জাল হয়। এই ঘটনাগুলি আপনাকে শেখায় যে কীভাবে শক্ত সিস্টেমগুলিকে স্থপতি করতে হয় এবং অনেক ক্ষেত্রে কীভাবে নয়।
এই নিবন্ধটি সফ্টওয়্যার ঘটনাগুলি কীভাবে মোকাবেলা করতে হয় তার 2টি দিকের মধ্যে যায়:
আমরা যে বিষয়গুলো নিয়ে আলোচনা করব তা হল-
আমাদের কিছু বিবরণ জন্য ডুব দিন!
আপনি সত্যিই আপনার গ্রাহকদের মাধ্যমে বা ঘটনাটি শুরু হওয়ার দিন বা সপ্তাহের কিছু গুরুতর অ্যাকাউন্টিং অসঙ্গতির মাধ্যমে আপনি কতগুলি ঘটনা শিখছেন তা কমিয়ে আনতে চান। যদিও "অটোমেশন" ইঞ্জিনিয়ারিং-এ একটি অত্যধিক ব্যবহার করা শব্দ, এটি সেই ক্ষেত্রগুলির মধ্যে একটি যেখানে আপনি সত্যিকার অর্থেই সংকেত-থেকে-শব্দ অনুপাতের সঠিক ভারসাম্য খুঁজে পেতে চান এবং নিশ্চিত করুন যে আপনি এবং আপনার দল কোনও মানবিক হস্তক্ষেপের প্রয়োজন ছাড়াই সতর্কতাগুলি পান৷
যদি বাছাই করার মতো অনেকগুলি জিনিস থাকে তবে সুপার হাই-লেভেল যান। আপনি বাছাই করতে পারেন সর্বোচ্চ স্তরের মেট্রিক কি? এক যদি উপাদান সিস্টেম প্রত্যাশিত হিসাবে কাজ করতে ব্যর্থ হয়, আদর্শ থেকে বিচ্যুত হবে? এটি প্ল্যাটফর্মের মাধ্যমে প্রবাহিত রাজস্ব ট্র্যাকিং হতে পারে (একটি ই-কমার্স, আর্থিক, বা $-ভিত্তিক প্ল্যাটফর্মের জন্য), বা বর্তমান সক্রিয় ব্যবহারকারীর সংখ্যা (সোশ্যাল মিডিয়া প্ল্যাটফর্মের জন্য)।
আপনি যদি দেখেন যে সংখ্যাগুলি একটি বা দুটি স্ট্যান্ডার্ড বিচ্যুতি দ্বারা ক্রেটার বা ড্রপ হয়েছে, অবিলম্বে ডেভ টিমকে সতর্ক করুন৷ ব্যবসার নাড়ি বা মূল ব্যবহারকারীর অভিজ্ঞতার উপর প্রথম (বা সবচেয়ে গুরুত্বপূর্ণ) সতর্কতা ফোকাস করা নিরীক্ষণের জন্য একটি দুর্দান্ত মেট্রিক হতে চলেছে। আপনি যত বেশি পরিশীলিত হবেন এবং সিস্টেমটিকে আরও ভালভাবে বুঝতে পারবেন, আপনি একটি পর্যবেক্ষণের দৃষ্টিকোণ থেকে স্ট্যাকের আরও গভীরে যেতে শুরু করতে পারেন।
নেতৃস্থানীয় সূচকগুলি ভবিষ্যদ্বাণীমূলক প্রকৃতির এবং সম্ভবত ঘটতে থাকা একটি সমস্যাকে নির্দেশ করতে পারে যেখানে পিছিয়ে থাকা সূচকগুলি পোস্ট-হক এবং সমস্যাটি ভালভাবে প্রগতিশীল হয়ে গেলে পরবর্তীতে প্রতিনিধিত্ব করে। আপনি যদি পিছিয়ে থাকা সূচকগুলির (যেমন "অর্ডার প্লেসড প্লেমমেটিং" বলুন) ছাড়াও বা তার জায়গায় অগ্রণী সূচকগুলিতে (যেমন "সেশনের সময়কাল" নামতে শুরু করে) ট্যাপ করতে পারেন, আপনি সম্ভবত এমন কিছু এড়াতে পারেন যা বেশ বিপর্যয়কর।
আপনার সতর্কতাগুলি অবশ্যই স্ব-প্রকাশ্য হতে হবে যাতে তারা বরখাস্ত হলে পরবর্তী পদক্ষেপগুলি কী করতে হবে তা স্পষ্ট হয়৷ সমস্যাটির তীব্রতা নির্ণয় করা, ঘটনার সমস্যা সমাধান করা বা সমস্যাটির প্রতিকার করা যাই হোক না কেন, সতর্কতার সাথে যুক্ত যথেষ্ট বিশদ থাকতে হবে। আপনি নিশ্চিত করতে চান যে সতর্কতার সাথে কী করতে হবে তা নির্ধারণ করতে এটির জন্য অনেক আগাম আলোচনার প্রয়োজন নেই৷
আপনি সতর্কতার বিষয়বস্তুতে এই বিবরণগুলি আটকে রাখতে পারেন, অথবা যদি এটি মোটামুটি শব্দপূর্ণ হয়, আপনি একটি রানবুকের সাথে লিঙ্ক করতে পারেন যা দল এই ধরণের সমস্যার জন্য রক্ষণাবেক্ষণ করে।
পরিষেবার মালিকানা, টাইমজোন সচেতনতা ইত্যাদির মতো বিষয়গুলির উপর ভিত্তি করে এটি কাকে পাঠানো হয় তা সহ একটি সতর্কতা ফায়ার হলে কী ঘটে তার একটি পরিষ্কার রূপরেখা থাকা একটি দ্রুত প্রতিক্রিয়া নিশ্চিত করার জন্য গুরুত্বপূর্ণ। প্রতিরক্ষার সেই অবিলম্বে প্রথম লাইনের বাইরে, কীভাবে এবং কার কাছে ঘটনার প্রতিক্রিয়াকারী ঘটনাটিকে বাড়িয়ে তুলতে পারে সে সম্পর্কে স্পষ্টতা রয়েছে তা নিশ্চিত করাও সমানভাবে গুরুত্বপূর্ণ।
প্রায়শই, যদি সমস্যাটি জটিল হয় বা একজন ব্যক্তি পরিচালনা করতে পারে তার পরিধিতে অনেক বড়, তাহলে আরও সিনিয়র লোকদের (বা দলে একাধিক ব্যক্তি) পাশাপাশি ক্রস-ফাংশনাল স্টেকহোল্ডারদের টানতে হবে। টুলিং (যেমন PagerDuty, OpsGenie) বা ক্রিস্টাল ক্লিয়ার ডকুমেন্টেশন (চালিত বই, উইকি পৃষ্ঠা, রেপো READMEs) এর মাধ্যমে এই সমস্ত সহজে অ্যাক্সেসযোগ্য করা একটি বিপর্যয়মূলক ঘটনা বা কিছুই-বার্গারের মধ্যে পার্থক্য হতে পারে।
আপনার স্পষ্ট বৃদ্ধি পাথের প্রয়োজন, আপনি এটি ডিফল্ট প্রতিক্রিয়া হতে চান না। ঊর্ধ্বতন ব্যবস্থাপনার সাথে পরামর্শ করার প্রয়োজন ছাড়াই আপনাকে অবশ্যই প্রথম প্রতিক্রিয়াকারীদের রক্তপাত বন্ধ করতে বা প্রতিকারের জন্য ঘটনাস্থলে সিদ্ধান্ত নিতে সক্ষম হতে হবে। ফল আউট সীমিত করার ক্ষেত্রে এবং সেইসাথে যে কর্মচারীদের একটি উচ্চ দায়িত্ব দেওয়া হয় যে তারা বড় সিদ্ধান্ত নেওয়ার জন্য বিশ্বস্ত হয় তাদের জন্য এটি উভয়ই ভাল। লাল ফিতা হ্রাস করুন এবং ব্যক্তিদের এজেন্সি বাড়ান।
কল চেইন এবং এসকেলেশন পাথের মতো জিনিসগুলির পাশাপাশি, অপর একটি সমান্তরাল অংশ যা গুরুত্বপূর্ণ একটি ঘটনা অগ্রাধিকার স্কেল। এটি সাধারণত প্রথম প্রতিক্রিয়াকারী বা ঘটনা কমান্ডারের জন্য একটি দ্রুত রেফারেন্স। এটি তাদের দ্রুত ঘটনার তীব্রতা শনাক্ত করতে এবং এটিকে লেবেল করতে সাহায্য করে কারণ এটি বিভিন্ন গ্রেডের প্রতিক্রিয়ার নিশ্চয়তা দিতে পারে।
সমালোচনামূলক ঘটনাগুলির মধ্যে পার্থক্য করা (যেমন সিস্টেম বিভ্রাট বা আর্থিক ডেটা দুর্নীতি) এবং ছোটখাটো সমস্যাগুলি (যেমন রঙ প্যালেটের সমস্যা) মিথ্যা অ্যালার্ম এড়াতে প্রতিক্রিয়াকারীদের জন্য অপরিহার্য। এটি নিশ্চিত করে যে দলের প্রতিক্রিয়া কার্যকর এবং ফোকাস থাকবে।
প্রশ্ন ছাড়াই, সবচেয়ে গুরুত্বপূর্ণ জিনিসগুলির মধ্যে একটি হল যত দ্রুত সম্ভব ঘটনার সমাধান করা। ঘটনাটি চলমান অবস্থায় কেন কিছু ঘটেছে বা কীভাবে এটি প্রতিরোধ করা যেতে পারে তা দর্শন করার জন্য আপনি সময় ব্যয় করতে চান না। আপনি পোস্টমর্টেম জন্য এটি সংরক্ষণ করতে পারেন. এই মুহুর্তের জন্য, নির্মমভাবে ঘটনার সমাধান করার দিকে মনোনিবেশ করুন এবং পরে কঠিন প্রশ্নগুলি জিজ্ঞাসা করুন।
কখনও কখনও, ঘটনা খুব বড় হতে পারে। তারা অনেকগুলি পরিষেবাকে স্পর্শ করে, তারা একাধিক ব্যবসায়িক ডোমেন বিস্তৃত করে, অথবা তারা রাজস্ব বা খ্যাতির ক্ষেত্রে সত্যিই প্রভাবশালী। তখনই এটা খুবই গুরুত্বপূর্ণ যে পুরো ঘটনার জন্য একজন ব্যক্তিকে "ট্রাফিক পুলিশ" নিয়োগ করা হয়। প্লেস এক্সচেঞ্জে, আমরা "ইনসিডেন্ট কমান্ডার" প্রতিষ্ঠা করেছি যারা একটি ছোট গ্রুপ যারা জটিল ঘটনার প্রতিক্রিয়ায় প্রশিক্ষিত।
এই ধরনের ভূমিকা রাখা এত গুরুত্বপূর্ণ কারণ হল যখন একাধিক পক্ষ জড়িত থাকে, তখন কাউকে ট্রাফিক পরিচালনা করতে হবে। প্রায়শই, ইঞ্জিনিয়াররা সমস্যার জটিলতা সম্পর্কে খরগোশের গর্তে যেতে শুরু করে বা কীভাবে সমস্যাটি সমাধান করা যায় তা বোঝার চেষ্টা করে।
ইনসিডেন্ট কমান্ডারের ভূমিকা হল গ্রুপের ফোকাস দ্রুত ঘটনার সমাধানে রাখা। তারা নিশ্চিত করে যে প্রত্যেকেরই কর্মের প্রতি পক্ষপাতিত্ব রয়েছে এবং যদিও পার্শ্ব তদন্ত গুরুত্বপূর্ণ হতে পারে, এগিয়ে গতি নিশ্চিত করা আরও গুরুত্বপূর্ণ। অভ্যন্তরীণ এবং বহিরাগত উভয় স্টেকহোল্ডার এবং অংশীদারদের সাথে স্পষ্ট এবং অবিচ্ছিন্ন যোগাযোগ রয়েছে তা নিশ্চিত করার জন্যও তারা দায়ী।
ইনসিডেন্ট কমান্ডাররা সাধারণত ভয়েস কমিউনিকেশনের একটি সিঙ্ক্রোনাস লাইন শুরু করবে, যেমন স্ল্যাক হাডল বা গুগল মিট মিটিং। এটি নিশ্চিত করে যে ঘটনার রেজোলিউশনের জন্য গুরুত্বপূর্ণ লোকেরা ক্রমাগত যোগাযোগে রয়েছে। এটি আশ্চর্যজনক যে এই ছোট জিনিসটি কেবল চ্যাট ব্যবহার করে লোকেদের অ্যাসিঙ্ক জিনিসগুলি সমাধান করার অনুমতি দেওয়ার সাথে তুলনা করা হয়।
ইনসিডেন্ট কমান্ডাররা যে কাজগুলি সম্পন্ন করতে হবে তার জন্য সুস্পষ্ট প্রতিনিধি দল রয়েছে তা নিশ্চিত করার জন্যও দায়ী এবং নিশ্চিত করুন যে সেই কাজগুলির জন্য প্রতিক্রিয়া বা ফলাফল পাওয়ার জন্য জবাবদিহিতা রয়েছে।
যেমন তারা বলে, আপনি যদি 2 জনকে একটি ঘোড়া খাওয়াতে বলেন, ঘোড়াটি মারা যায়। একজন ঘটনা কমান্ডার এটি ঘটতে বাধা দেয় এবং শেষ পর্যন্ত ঘটনার দ্রুত সমাধানের জন্য দায়ী।
লোকেরা প্রায়শই তাদের প্রিয় অ্যাপ বা সফ্টওয়্যারটি ক্ষমা করে দেয় যদি তারা ঘটনাটি সমাধানে কীভাবে কঠোর পরিশ্রম করছে সে সম্পর্কে তাদের অবহিত করা হয়। জিনিসগুলি লুকিয়ে রাখার চেষ্টা করা হয় কারণ আপনি মনে করেন না যে আপনি এই ঘটনার সম্পূর্ণ হ্যান্ডেল করেছেন, অথবা আপনি এবং আপনার দল এটি নিয়ে বিব্রত বোধ করছেন যোগাযোগটি বাইরের দিকে প্রবাহিত হওয়া বন্ধ করার কোনও কারণ নয়।
নিশ্চিত করুন যে যোগাযোগটি আপনার অভ্যন্তরীণ এবং বাহ্যিক উভয় অংশীদারের সাথে সংক্ষিপ্ত, ঘন ঘন এবং স্বচ্ছ হয় কারণ এটি সদিচ্ছা তৈরিতে সহায়তা করবে।
শেখার সংস্কৃতি গড়ে তোলার জন্য পোস্ট-মর্টেম বা ঘটনা-পরবর্তী রেট্রোস্পেকটিভ গুরুত্বপূর্ণ, এবং সেগুলি অবশ্যই নির্দোষ হতে হবে। ব্যক্তি নয় প্রক্রিয়াটির সমালোচনা করুন। যে ব্যক্তি (গুলি) এটি ঘটিয়ে থাকতে পারে তার চেয়ে কেউ নিজের পক্ষে কঠিন নয় এবং আপনি তাদের জনসমক্ষে ফ্ল্যাগলেট করে কিছুই লাভ করেন না। যদি কিছু হয়, সমস্ত গবেষণা পরামর্শ দেয় যে আপনি আসলে এটি করে হারান। Etsy-এর লোকেরা এটি সম্পর্কে কথা বলতে অনেক ভাল, তাই আপনি আরও জানতে চাইলে https://www.etsy.com/codeascraft/blameless-postmortems পড়ুন।
সচেতনতা তৈরি করতে এবং এই ঘটনাগুলি থেকে শেখার জন্য প্রতিক্রিয়া লুপগুলি নিজেরাই ময়না-তদন্ত পরিচালনা করা গুরুত্বপূর্ণ, ভবিষ্যতে এগুলি যাতে না ঘটতে পারে তার জন্য যে অ্যাকশন আইটেমগুলি নিয়ে আলোচনা করা হয়, তা হয়ত আরও গুরুত্বপূর্ণ। যদি গোষ্ঠীটি সিস্টেমে ফাঁক বা দুর্বলতার একটি সেট চিহ্নিত করে থাকে, তাহলে একই সমস্যা পুনরায় ঘটতে না দেওয়ার জন্য সময়মতো সেগুলি সমাধান করার জন্য ফোকাস এবং মনোযোগ দেওয়া অত্যন্ত গুরুত্বপূর্ণ।
ঘটনা ঘটতে বাধা দেওয়া কঠিন, এবং এটি সাধারণত আপনার ব্যবসা এবং গ্রাহকদের সাথে একটি কঠিন কথোপকথন। কিন্তু একই ঘটনা বারবার ঘটলে, এখন তা রক্ষা করা কঠিন এবং দলের স্বাস্থ্য এবং দক্ষতার ক্ষেত্রে একটি গুরুতর সমস্যা নির্দেশ করে।
সবাই এটা পায়. এমনকি ব্যবসায়ীরাও তা পায়। সফ্টওয়্যার তৈরি করা কঠিন, এবং এমন একটি বিশ্বে যেখানে আমাদের সমস্ত সফ্টওয়্যারের 100-1000 নির্ভরতা রয়েছে, যেখানে ফল্ট লাইনগুলি ক্র্যাক হতে পারে, এটি ভবিষ্যদ্বাণী করা অসম্ভব৷ বিষ্ঠা ফ্যান আঘাত করবে, এবং এটা ঠিক আছে. আমরা ঘটনা ঘটতে বাধা দিতে পারি না। যাইহোক, যা সত্যিই সাহায্য করে তা হল নিশ্চিত করা যে আপনার ঘটনার জন্য MTTD সত্যিই কম।
মিন টাইম টু ডিটেক্ট (MTTD) হল একটি মূল পারফরম্যান্স ইন্ডিকেটর (KPI) যা একটি সংস্থার একটি ঘটনা বা নিরাপত্তা হুমকি শনাক্ত করতে কতটা গড় সময় নেয় তা পরিমাপ করে। ব্যবসায়িক ডোমেন, প্রভাবের তীব্রতা ইত্যাদি বিবেচনা করে এটিকে সাধারণীকরণ করা কঠিন, কিন্তু আপনি যদি আপনার MTTD কে সেকেন্ড থেকে মিনিটে কমিয়ে আনতে সক্ষম হন, তাহলে আপনি সম্ভবত এটি বলার বিপরীতে একটি ঘটনার প্রভাব উল্লেখযোগ্যভাবে কমাতে সক্ষম হবেন। ঘন্টা থেকে দিন ছিল (সপ্তাহ বা মাস, যা দুর্ভাগ্যবশত সম্পূর্ণরূপে সম্ভব)।
এই সব তাই গুরুতর! টাকা নষ্ট হচ্ছে! ভয়ানক অভিজ্ঞতা হচ্ছে গ্রাহকদের! যাইহোক, এই সবের মাঝে, আমি এটিকে হাস্যরসের ধারনাকে সমালোচনামূলক বলে মনে করেছি। আমাদের ভুলে যাওয়া উচিত নয় যে এই প্রক্রিয়ায় প্রত্যেকেই একজন মানুষ এবং বিভিন্ন মাত্রার চাপের মধ্য দিয়ে যাচ্ছে। উপযুক্ত সন্ধিক্ষণে হাস্যরসের ডোজ ইনজেকশন করা সেই চাপের কিছুটা উপশম করতে সহায়তা করে।
এটি বন্ধুত্বের অনুভূতি তৈরি করে যা দলটিকে মনে করে যে তারা নরকের একটি দ্বীপে যাওয়ার চেয়ে তারা একসাথে এতে রয়েছে।
যে একটি মোড়ানো. পড়ার জন্য ধন্যবাদ!
⭐ আপনি যদি এই ধরণের সামগ্রী পছন্দ করেন তবে আমাকে অনুসরণ করতে ভুলবেন না বা https://a1engineering.substack.com/subscribe- এ সাবস্ক্রাইব করুন! ⭐
আনস্প্ল্যাশে জুলিয়ান এল-এর ফিচার ফটো