আইটি টিমের জন্য ঘটনা পরিচালনা অ্যাপ: ওয়ার্কফ্লো থেকে পোস্টমরটেম পর্যন্ত

একটি অভ্যন্তরীণ ইনসিডেন্ট অ্যাপ আসলে কোন সমস্যা সমাধান করে

আউটেজ হলে বেশিরভাগ টিম যা খোলা থাকে তাই ধরতে যায়: একটি চ্যাট থ্রেড, একটি ইমেইল চেইন, বা কেউ সময় পেলেই আপডেট করা একটি স্প্রেডশিট। চাপের মধ্যে সেই সেটআপ সব সময় একইভাবে ভেঙে পড়ে: মালিকানা অস্পষ্ট হয়ে যায়, টাইমস্ট্যাম্প মিস হয়, এবং সিদ্ধান্তগুলি স্ক্রোলের ভেতরেই হারিয়ে যায়।

একটি সাধারণ ইনসিডেন্ট ম্যানেজমেন্ট অ্যাপ মৌলিক জিনিসগুলো ঠিক করে। এটি একটি জায়গা দেয় যেখানে ইনসিডেন্টটি থাকে, একটি পরিষ্কার মালিক থাকে, সবাই যে severity তে একমত থাকে তা নির্দিষ্ট থাকে, এবং কী ঘটেছে ও কখন তা দেখানো একটি টাইমলাইন থাকে। ঐ একক রেকর্ড গুরুত্বপূর্ণ, কারণ একই প্রশ্নগুলো প্রতিটি ইনসিডেন্টে উঠে: কে নেতৃত্ব দিচ্ছে? এটা কখন শুরু হয়েছিল? বর্তমান স্ট্যাটাস কী? আগে কী চেষ্টা করা হয়েছে?

ওই শেয়ারড রেকর্ড ছাড়া হ্যান্ডঅফগুলো সময় নষ্ট করে। সাপোর্ট গ্রাহকদের এক বলছে, ইঞ্জিনিয়ারিং অন্য কিছু করছে। ম্যানেজাররা আপডেট চাইলে রেসপন্ডাররা ফিক্স থেকে বিচ্ছিন্ন হয়। পরে কেউ কনফিডেন্সসহ টাইমলাইন পুনর্নির্মাণ করতে পারে না, তাই পোস্টমরটেম অনুমানভিত্তিক হয়ে যায়।

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

IT অপারেশন এবং অন-কল ইঞ্জিনিয়াররা এটি ব্যবহার করে রেসপন্স সংহত করে। সাপোর্ট দ্রুত সঠিক আপডেট দিতে পারে। ম্যানেজাররা রেসপন্ডারদের বাধা না দিয়ে অগ্রগতি দেখতে পারে।

উদাহরণ দৃশ্য: একটি P1 আউটেজ অ্যালার্ট থেকে ক্লোজার পর্যন্ত

সকাল 9:12 এ মনিটরিং কাস্টমার পোর্টালে 500 এরর স্পাইক ধরা পড়লে অ্যালার্ট দেয়। একটি সাপোর্ট এজেন্টও রিপোর্ট করে, “প্রায় সকল ব্যবহারকারীর লগইন ব্যর্থ হচ্ছে।” অন-কল IT লিড ইনসিডেন্ট অ্যাপে একটি P1 ইনসিডেন্ট ওপেন করে এবং প্রথম অ্যালার্ট ও সাপোর্টের স্ক্রিনশট সংযুক্ত করে।

P1 হলে আচরণ দ্রুত পরিবর্তিত হয়। ইনসিডেন্ট মালিক ব্যাকএন্ড মালিক, ডাটাবেস মালিক এবং একটি সাপোর্ট লিয়াজনকে টেনে আনে। অনাবশ্যক কাজগুলো স্থগিত করা হয়। পরিকল্পিত ডিপ্লয়মেন্ট বন্ধ করা হয়। টিম আপডেট কেডেন্সে একমত হয় (উদাহরণস্বরূপ প্রতি 15 মিনিটে)। একটি শেয়ার করা কল শুরু হয়, কিন্তু ইনসিডেন্ট রেকর্ডই সত্যের উৎস থাকে।

9:18 AM নাগাদ কেউ জিজ্ঞাসা করে, “কী পরিবর্তন হয়েছে?” টাইমলাইনে 8:57 AM এ একটি ডিপ্লয় দেখা যায়, কিন্তু কি ডিপ্লয় করা হয়েছিল তা লেখা নেই। ব্যাকএন্ড মালিক তবুও রোলব্যাক করে। এরর কমে, পরে আবার ফিরে আসে। এখন টিম সন্দেহ করে ডাটাবেসের দিকে।

বেশিরভাগ বিলম্ব কয়েকটি পূর্বানুমেয় স্থানে দেখা যায়: অস্পষ্ট হ্যান্ডঅফ (“আমি ভেবেছিলাম তুমি সেটা দেখছো”), প্রাসঙ্গিকতা হারানো (সাম্প্রতিক পরিবর্তন, জানা ঝুঁকি, বর্তমান মালিক), এবং চ্যাট, টিকেট ও ইমেইলে ছড়িয়ে থাকা আপডেট।

9:41 AM এ ডাটাবেস মালিক একটি রানের কুয়েরি খুঁজে পায় যা একটি শিডিউল করা জব শুরু করেছিল। তারা জবটি নিষ্ক্রিয় করে, প্রভাবিত সার্ভিস রিস্টার্ট করে এবং পুনরুদ্ধার নিশ্চিত করে। মনিটরিংয়ের জন্য সেভারিটি P2 তে ডাউনগ্রেড করা হয়।

ভাল ক্লোজার মানে শুধু “এটি আবার চলছে” নয়। এটা একটি পরিষ্কার রেকর্ড: মিনিট-প্রতি-মিনিট টাইমলাইন, চূড়ান্ত রুট কারণ, কে কোন সিদ্ধান্ত নিয়েছিল, কী বন্ধ করা হয়েছিল, এবং মালিক ও ডিউ-তারিখসহ ফলো-আপ কাজ। এভাবে একটি চাপপূর্ণ P1 শেখায় এবং পুনরাবৃত্তি কমায়।

ডেটা মডেল: সবচেয়ে সরল স্ট্রাকচার যা কাজ করে

একটি ভাল ইনসিডেন্ট টুল বড় মাপেই একটি ভাল ডেটা মডেল। যদি রেকর্ডগুলো অস্পষ্ট হয়, মানুষ ইনসিডেন্ট কী, কখন শুরু হয়েছে, এবং কী এখনও খোলা তা নিয়ে বিতর্ক করবে।

কোর এনটিটি গুলোকে এমনভাবে রাখুন যেভাবে IT টিমগুলো ইতিমধ্যেই কথা বলে:

• Incident: যা ঘটেছে তার কন্টেইনার
• Service: ব্যবসায় যা চলছে (API, ডাটাবেস, VPN, বিলিং)
• User: রেসপন্ডার এবং স্টেকহোল্ডার
• Update: সময়ভিত্তিক সংক্ষিপ্ত স্ট্যাটাস নোট
• Task: ইনসিডেন্টের সময় (এবং পরের) কংক্রিট কাজ
• Postmortem: ইনসিডেন্টের সঙ্গে জোড়া একটি লিখিত রির্পোট, অ্যাকশন আইটেমসহ

ভবিষ্যতে বিভ্রান্তি এড়াতে Incident-কে কিছু স্ট্রাকচার্ড ফিল্ড দিন যা সবসময় পূরণ করা হয়। ফ্রি টেক্সট সাহায্য করে, কিন্তু এটিই একমাত্র সত্যের উৎস হওয়া উচিত নয়। একটি ব্যবহারিক মিনিমাম: একটি স্পষ্ট টাইটেল, প্রভাব (ব্যবহারকারীরা কী অভিজ্ঞতা পাচ্ছেন), প্রভাবিত সার্ভিসসমূহ, শুরু সময়, বর্তমান স্ট্যাটাস, এবং সেভারিটি।

রিলেশনশিপগুলো অতিরিক্ত ফিল্ডের চেয়েও বেশি গুরুত্বপূর্ণ। একটি ইনসিডেন্টের অনেকগুলো আপডেট ও টাস্ক থাকতে হবে, এবং সার্ভিসগুলোর সাথে many-to-many লিঙ্ক থাকবে (কারণ আউটেজ প্রায়ই একাধিক সিস্টেমকে প্রভাবিত করে)। একটি পোস্টমরটেম ইনসিডেন্টের সাথে one-to-one হওয়া উচিত, যাতে একটি চূড়ান্ত গল্প থাকে।

উদাহরণ: “Checkout errors” ইনসিডেন্টটি Services “Payments API” এবং “PostgreSQL”-এর সাথে লিঙ্ক করবে, প্রতি 15 মিনিটে আপডেট থাকবে, এবং “রোলব্যাক করা” ও “রিট্রাই গার্ড যুক্ত করা” মতো টাস্ক থাকবে। পরে পোস্টমরটেম রুট কারণ ধরে এবং দীর্ঘমেয়াদী টাস্ক তৈরি করে।

সেভারিটি স্তর এবং রেসপন্স লক্ষ্য

চাপের মধ্যে মানুষ সহজ লেবেল চায় যেগুলো প্রত্যেকের কাছে একই অর্থ বহন করে। P1 থেকে P4 স্পষ্ট ভাষায় সংজ্ঞায়িত করুন এবং সেভারিটি ফিল্ডের পাশে সংজ্ঞা দেখান।

• P1 (Critical): কোর সার্ভিস ডাউন বা ডেটা হারানোর সম্ভাবনা। অনেক ব্যবহারকারী ব্লক।
• P2 (High): বড় ফিচার ভাঙ্গা, কিন্তু ওয়ার্কঅ্যারাউন্ড আছে বা বিস্তার সীমিত।
• P3 (Medium): অপ্রয়োজনীয় সমস্যা, ছোট গ্রুপ প্রভাবিত, ব্যবসায়িক প্রভাব কম।
• P4 (Low): কসমেটিক বা সামান্য বাগ, পরে সময়সূচিতে রাখুন।

রেসপন্স লক্ষ্যগুলোকে প্রতিশ্রুতির মতো পড়ান। একটি সহজ বেসলাইন (আপনার বাস্তবতার সাথে সামঞ্জস্য করুন):

এস্ক্যালেশন নিয়মগুলো মেকানিক্যাল রাখুন। যদি একটি P2 তার আপডেট কেডেন্স মিস করে বা প্রভাব বাড়ে, সিস্টেম সেভারিটি রিভিউ পরামর্শ দেওয়া উচিত। থ্র্যাশ এড়াতে সেভারিটি পরিবর্তন করার অনুমতি সীমিত রাখুন (প্রায়ই ইনসিডেন্ট মালিক বা ইনসিডেন্ট কমান্ডার), তবু যে কেউ মন্তব্য করে রিভিউ অনুরোধ করতে পারবে।

একটি দ্রুত ইমপ্যাক্ট ম্যাট্রিক্স টিমগুলোকে দ্রুত সেভারিটি নির্ধারণে সাহায্য করে। এটিকে কিছু বাধ্যতামূলক ফিল্ড হিসেবে ধরে রাখুন: প্রভাবিত ব্যবহারকারী, আয় ঝুঁকি, সেফটি, সম্মতি/সিকিউরিটি, এবং ওয়ার্কঅ্যারাউন্ড আছে কি না।

চাপের সময় মানুষকে নির্দেশ দেয় এমন ওয়ার্কফ্লো স্টেট

ইনসিডেন্ট চলাকালীন মানুষদের আরো অপশন নয় দরকার—তারা এমন একটি ছোট সেট স্টেট চায় যা পরবর্তী পদক্ষেপ স্পষ্ট করে।

ভাল দিনের মতো আপনি যে ধাপগুলো ইতিমধ্যেই অনুসরণ করেন সেগুলো দিয়ে শুরু করুন, তারপর তালিকাটি ছোট রাখুন। যদি 6 বা 7-এর বেশি স্টেট থাকে, টিমগুলো বাক্যবিন্যাস নিয়ে বিতর্ক করবে ফিক্স করার বদলে।

একটি ব্যবহারিক সেট:

• New: অ্যালার্ট এসেছে, এখনও নিশ্চিত নয়
• Acknowledged: কেউ মালিক নিয়েছে, প্রথম রেসপন্স শুরু
• Investigating: প্রভাব নিশ্চিত করা, সম্ভাব্য কারণ সংকীর্ণ করা
• Mitigating: প্রভাব কমানোর কাজ চলছে
• Monitoring: সার্ভিস স্থিতিশীল দেখায়, relapse-এ নজর রাখা হচ্ছে
• Resolved: সার্ভিস পুনরুদ্ধার, রিভিউ-র জন্য প্রস্তুত

প্রতিটি স্ট্যাটাসের স্পষ্ট এন্ট্রি এবং এক্সিট নিয়ম থাকা উচিত। উদাহরণস্বরূপ:

• Acknowledged এ যাওয়ার আগে মালিক সেট করা এবং পরবর্তী অ্যাকশন এক বাক্যে লেখা বাধ্যতামূলক।
• Mitigating এ যেতে কমপক্ষে একটি কংক্রিট মিটিগেশন টাস্ক থাকা দরকার (রোলব্যাক, ফিচার ফ্ল্যাগ অফ, ক্যাপাসিটি যোগ করা)।

ট্রানজিশন ব্যবহার করে মানুষ যে ফিল্ডগুলো ভুলে যায় সেগুলো জোর দিয়ে নিন। একটি সাধারণ নিয়ম: ইনসিডেন্ট ক্লোজ করা যাবে না যদি না একটি সংক্ষিপ্ত রুট কারণ সারাংশ এবং অন্তত একটি ফলো-আপ আইটেম থাকে। যদি “RCA: TBD” অনুমোদিত থাকে, তা বেশিরভাগ সময়ই তেমনই থেকে যায়।

ইনসিডেন্ট পেজটি এক নজরে তিনটি প্রশ্নের উত্তর দিতে পারা উচিত: এটি কাদের মালিকানাধীন, পরবর্তী অ্যাকশন কী, এবং সর্বশেষ আপডেট কখন পোস্ট করা হয়েছে।

অ্যাসাইনমেন্ট এবং এসক্যালেশন নিয়ম

ইনসিডেন্ট যদি উচ্চশব্দপূর্ণ হয়, সবচেয়ে দ্রুত সময় নষ্ট হওয়ার উপায় হল অস্পষ্ট মালিকানা। আপনার অ্যাপটি একজন ব্যক্তিকে স্পষ্টভাবে দায়িত্ব দেবার ব্যবস্থা করবে, তবু অন্যরা সহজে সাহায্য করতে পারবে।

একটি সহজ প্যাটার্ন যা কার্যকর:

• Primary owner: রেসপন্স চালায়, আপডেট পোস্ট করে, পরবর্তী পদক্ষেপ সিদ্ধান্ত নেয়
• Helpers: টাস্ক নেয় (ডায়াগনস্টিক, রোলব্যাক, কমিউনিকেশন) এবং রিপোর্ট করে
• Approver: লীড যিনি ঝুঁকিপূর্ণ কাজ অনুমোদন করতে পারেন

অ্যাসাইনমেন্ট স্পষ্ট এবং অডিটেবল হওয়া উচিত। কে মালিক সেট করেছে, কে গ্রহণ করেছে, এবং পরবর্তী সব পরিবর্তন ট্র্যাক করুন। “Accepted” গুরুত্বপূর্ণ, কারণ যে কাউকে নিযুক্ত করা হয়েছে কিন্তু সে ঘুমোচ্ছে বা অফলাইনে থাকে সে প্রকৃত মালিক নয়।

অন-কল বনাম টিম-ভিত্তিক অ্যাসাইনমেন্ট সাধারণত সেভারিটির ওপর নির্ভর করে। P1/P2-এর জন্য ডিফল্ট অন-কল রোটেশন রাখা ভাল যাতে সবসময় একটি নামকরা মালিক থাকে। নিম্ন সেভারিটির জন্য টিম-ভিত্তিক অ্যাসাইনমেন্ট কাজ করতে পারে, কিন্তু তখনও সংক্ষিপ্ত সময়ে একটি একক প্রাইমারি মালিক নির্দিষ্ট করতে হবে।

ছুট এবং আউটেজের জন্য আপনার প্রক্রিয়ায় পরিকল্পনা রাখুন, কেবল আপনার সিস্টেমেই নয়। যদি নিযুক্ত ব্যক্তি ‘অব্যর্থ’ হিসেবে চিহ্নিত থাকে, তাহলে এটি স্বয়ংক্রিয়ভাবে সেকেন্ডারি অন-কল বা টিম লিডের কাছে রুট করুন। এটিকে স্বয়ংক্রিয় রাখুন, কিন্তু দৃশ্যমান রাখুন যাতে দ্রুত সংশোধন করা যায়।

এস্ক্যালেশন সেভারিটি এবং নীরবতা—দুটোর ওপর ট্রিগার করা উচিত। একটি ব্যবহারিক শুরু:

• P1: 5 মিনিটে যদি কোন মালিক গ্রহণ না করে তবে এসক্যালেট করুন
• P1/P2: 15 থেকে 30 মিনিটে যদি কোন আপডেট না থাকলে এসক্যালেট করুন
• যেকোনো সেভারিটি: যদি স্টেট “Investigating” প্রতিক্রিয়া লক্ষ্য অতিক্রম করে থাকে তবে এসক্যালেট করুন

টাইমলাইন, আপডেট, এবং নোটিফিকেশন

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

টাইমলাইন কী ধরা উচিত

টাইমলাইনটি মতামতপূর্ণ রাখুন। এটাকে চ্যাট লগ বানাতে দেবেন না। বেশিরভাগ টিম কয়েকটি এন্ট্রিতে নির্ভর করে: ডিটেকশন, অ্যাকনলেজমেন্ট, মূল মিটিগেশন ধাপ, পুনরুদ্ধার, এবং ক্লোজার।

প্রতিটি এন্ট্রিতে টাইমস্ট্যাম্প, লেখক, এবং সংক্ষিপ্ত সাদাসিধে বর্ণনা থাকা দরকার। পরে যোগ হওয়া কেউ পাঁচটি এন্ট্রি পড়ে দ্রুত কি হচ্ছে তা বুঝতে পারা উচিত।

পরিষ্কার রাখার জন্য আপডেট টাইপ

বিভিন্ন আপডেট বিভিন্ন শ্রোতাদের বহন করে। এন্ট্রিগুলোতে টাইপ থাকলে সুবিধা হয়—যেমন internal note (কাঁচা বিবরণ), customer-facing update (নিরাপদ ভাষা), decision (কেন আপনি অপশন A বেছে নিলেন), এবং handoff (পরবর্তী ব্যক্তিকে কী জানতে হবে)।

রিমাইন্ডারগুলো ব্যক্তিগত পছন্দ নয় বরং সেভারিটির উপর নির্ভর করা উচিত। টাইমার গেলে প্রথমে কারেন্ট মালিককে পিং করুন, তারপর যদি বারবার মিস হয় তবে এসক্যালেট করুন।

নোটিফিকেশনগুলো লক্ষ্যভিত্তিক এবং পূর্বানুমেয় হওয়া উচিত। সাধারণ নিয়ম: তৈরি হলে, সেভারিটি পরিবর্তন হলে, পুনরুদ্ধার হলে, এবং ওভারডিউ আপডেট হলে নোটিফাই করুন। কোম্পানি-স্তরে সবাইকে প্রতিটি পরিবর্তনের জন্য নোটিফাই করা থেকে বিরত থাকুন।

পোস্টমরটেম যাতে বাস্তবে ফলো-আপ করে

একটি পোস্টমরটেমের দুইটি কাজ থাকা উচিত: সাধারন ভাষায় কী ঘটেছে ব্যাখ্যা করা, এবং পরবর্তীবার একই ব্যর্থতা কম ঘটার উপায় তৈরি করা।

রিপোর্টটি সংক্ষিপ্ত রাখুন, এবং আউটপুটকে অ্যাকশনে বাধ্য করুন। একটি ব্যবহারিক কাঠামো: সারসংক্ষেপ, গ্রাহক প্রভাব, রুট কারণ, প্রয়োগকৃত ফিক্স, এবং ফলো-আপ।

ফলো-আপই মূল বিষয়। এগুলোকে শেষে একটি অনুচ্ছেদে রেখে দেবেন না। প্রতিটি ফলো-আপকে একটি ট্র্যাক করা টাস্কে রূপান্তর করুন যার মালিক এবং একটি ডিউ-তারিখ আছে—even যদি ডিউ-তারিখ “পরবর্তী স্প্রিন্ট” হয়। এটাই পার্থক্য “আমরা মনিটরিং উন্নত করা উচিত” এবং “Alex শুক্রবারের মধ্যে DB কানেকশন স্যাচুরেশন অ্যালার্ট যোগ করবে” এর মধ্যে।

ট্যাগগুলি পোস্টমরটেমগুলো পরে কাজে লাগবে। প্রতিটি ইনসিডেন্টে 1 থেকে 3 টি থিম যোগ করুন (monitoring gap, deployment, capacity, process)। এক মাস পরে আপনি সহজ প্রশ্নের উত্তর দিতে পারবেন, যেমন বেশিরভাগ P1 রিলিজ থেকেই আসে নাকি অ্যালার্ট হারানোর কারণে।

এভিডেন্স অটাচ করা সহজ হওয়া উচিত, বাধ্যতামূলক নয়। স্ক্রিনশট, লগ স্নিপেট, এবং বাহ্যিক সিস্টেমের রেফারেন্স (টিকেট আইডি, চ্যাট থ্রেড, ভেন্ডর কেস নাম্বার) সংযুক্ত করার জন্য অপশনাল ফিল্ড রাখুন। এটি লাইটওয়েট রাখুন যাতে মানুষ আসলে এটিতে ভর্তি করে।

ধাপে ধাপে: একটিই অভ্যন্তরীণ অ্যাপে মিনি-সিস্টেম তৈরি করা

এটিকে একটি ছোট প্রোডাক্ট হিসেবে বিবেচনা করুন, একটি অতিরিক্ত কলাম সহ স্প্রেডশিট হিসেবে নয়। একটি ভাল ইনসিডেন্ট অ্যাপটি মূলত তিনটি ভিউ: এখন কী ঘটছে, পরবর্তী কী করা উচিত, এবং পরে কী শেখা হয়েছে।

চাপের নিচে মানুষ যে স্ক্রিনগুলো খুলবে সেগুলো প্রথমে স্কেচ করুন:

• Queue: খোলা ইনসিডেন্টগুলো কিছু ফিল্টারসহ (Open, Needs update, Waiting on vendor, Closed)
• Incident page: সেভারিটি, মালিক, বর্তমান স্ট্যাটাস, টাইমলাইন, টাস্ক, এবং সাম্প্রতিক আপডেট
• Postmortem page: প্রভাব, রুট কারণ, অ্যাকশন আইটেম, মালিক

ডেটা মডেল এবং পারমিশন একসাথে তৈরি করুন। যদি সবাই সব কিছু এডিট করতে পারে, হিস্টরি বিশৃঙ্খল হবে। সাধারণ পদ্ধতি: IT-এর জন্য বিস্তৃত ভিউ অ্যাক্সেস, স্টেট/সেভারিটি পরিবর্তন নিয়ন্ত্রিত, রেসপন্ডাররা আপডেট যোগ করতে পারবেন, এবং পোস্টমরটেম অনুমোদনের জন্য একটি স্পষ্ট মালিক থাকবে।

তারপর ওয়ার্কফ্লো নিয়ম যোগ করুন যা আধা-ভরা ইনসিডেন্ট বাধা দেয়। প্রয়োজনীয় ফিল্ডগুলো স্টেটের ওপর নির্ভর করবে। আপনি হতে পারেন “New” এ শুধু টাইটেল ও রিপোর্টার অনুমোদন করেন, কিন্তু “Mitigating” এ ইমপ্যাক্ট সারাংশ বাধ্যতামূলক করতে পারেন, এবং “Resolved” এ রুট কারণ সারাংশ এবং অন্তত একটি ফলো-আপ টাস্ক বাধ্যতামূলক করতে পারেন।

শেষে, 2 থেকে 3টি পুরনো ইনসিডেন্ট রেপ্লে করে টেস্ট করুন। একজনকে ইনসিডেন্ট কমান্ডার ও একজনকে রেসপন্ডার হিসেবে রাখুন। আপনি দ্রুত দেখবেন কোন স্ট্যাটাসগুলো অস্পষ্ট, কোন ফিল্ডগুলো মানুষ স্কিপ করে, এবং কোথায় আরও ভাল ডিফল্ট দরকার।

সাধারণ ভুল এবং সেগুলো কিভাবে এড়াবেন

অধিকাংশ ইনসিডেন্ট সিস্টেম সহজ কারণে ব্যর্থ হয়: মানুষ স্ট্রেসে নিয়মগুলো মনে রাখে না, এবং অ্যাপ পরে যা দরকার তা ক্যাপচার করে না।

ভুল 1: খুব বেশি সেভারিটি বা স্ট্যাটাস

যদি আপনার ছয়টির বেশি সেভারিটি এবং দশটির বেশি স্ট্যাটাস থাকে, মানুষ আন্দাজ করবে। সেভারিটি 3 থেকে 4 রাখুন এবং স্ট্যাটাসগুলোকে পরের কী করা উচিত তা বোঝার উপর ফোকাস করুন।

ভুল 2: কোনো একক মালিক নেই

যখন সবাই “দেখছে”, তখন কেউ চালায় না। ইনসিডেন্ট এগোতে পারার আগে একটি নামকরা মালিক বাধ্যতামূলক করুন, এবং হ্যান্ডঅফগুলো স্পষ্টভাবে রেকর্ড করুন।

ভুল 3: অনির্ভরযোগ্য টাইমলাইন

“কবে কী হল” যদি চ্যাট হিস্ট্রির ওপর নির্ভর করে, পোস্টমরটেম বিতর্কে পরিণত হয়। ওপেন, অ্যাকনলেজড, মিটিগেটেড, এবং রিজলভড টাইমস্ট্যাম্পগুলো অটো-ক্যাপচার করুন এবং টাইমলাইন এন্ট্রিগুলো সংক্ষিপ্ত রাখুন।

এছাড়াও অস্পষ্ট রুট কারণ নোট যেমন “নেটওয়ার্ক সমস্যা” দিয়ে ক্লোজ করা এড়ান। একটি স্পষ্ট রুট কারণ বিবৃতি এবং অন্তত একটি কংক্রিট পরবর্তী ধাপ অনিবার্য করুন।

লঞ্চ চেকলিস্ট এবং পরবর্তী ধাপ

পুরো IT অর্গে রোল আউট করার আগে মৌলিকগুলো স্ট্রেস টেস্ট করুন। যদি মানুষ প্রথম দুই মিনিটে সঠিক বোতাম না পায়, তারা আবার চ্যাট থ্রেড ও স্প্রেডশিটে ফিরে যাবে।

ছোট একটি লঞ্চ চেকগুলোর ওপর ফোকাস করুন: ভূমিকা ও পারমিশন, স্পষ্ট সেভারিটি সংজ্ঞা, বাধ্যতামূলক মালিকানা, রিমাইন্ডার নিয়ম, এবং রেসপন্স টার্গেট মিস হলে একটি এসক্যালেশন পথ।

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

যদি আপনি এটি একটিই অভ্যন্তরীণ টুল হিসেবে তৈরি করতে চান এবং স্প্রেডশিট ও আলাদা অ্যাপগুলো জোড়া না করতে চান, AppMaster (appmaster.io) একটি অপশন হতে পারে। এটি আপনাকে একটি ডেটা মডেল, ওয়ার্কফ্লো নিয়ম, এবং ওয়েব/মোবাইল ইন্টারফেস এক জায়গায় তৈরির সুযোগ দেয়, যা ইনসিডেন্ট কিউ, ইনসিডেন্ট পেজ, এবং পোস্টমরটেম ট্র্যাকিংয়ের সাথে ভাল মিলবে।