পাইলট এবং PoCs পরিচালনার জন্য একটি দ্রুত নির্দেশিকা

ভূমিকা

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

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

তাহলে, আমরা কীভাবে সবকিছু বিচক্ষণতার সাথে করে তা বাস্তবায়ন করতে পারি?

প্রশিক্ষণ

পাইলটের লক্ষ্য

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

সুতরাং, পরিশেষে আমরা তিন ধরনের প্রধান পাইলট টেস্টিং এবং পাইলটের একটি বিশেষ ক্ষেত্র হিসেবে প্রুফ অফ কনসেপ্ট (PoC) পেয়ে থাকি:
* লোড টেস্টিং (+ স্কেলেবিলিটি)
কার্যকরী পরীক্ষা
ত্রুটি সহনশীলতা পরীক্ষা

বিশেষ ক্ষেত্রে, কোনো নির্দিষ্ট গ্রাহকের উদ্বেগের ওপর নির্ভর করে, পাইলট প্রকল্পটি বিভিন্ন উদ্দেশ্যকে একত্রিত করতে পারে, অথবা এর বিপরীতে, সেগুলোর মধ্যে কেবল একটিও উপস্থিত থাকতে পারে।

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

উপকরণ

পাইলট পরীক্ষাটি বিক্রেতা/পরিবেশক/অংশীদারের ডেমো সরঞ্জাম অথবা গ্রাহকের নিজস্ব সরঞ্জামে পরিচালনা করা যেতে পারে। কঠোরভাবে বলতে গেলে, পার্থক্যটি সামান্য; সাধারণ পদ্ধতি একই।

পাইলট শুরু করার আগে সরঞ্জাম সংক্রান্ত মূল প্রশ্নটি হলো: সরঞ্জামের সম্পূর্ণ সেট কি উপস্থিত আছে (সুইচ, ডেটা কেবল এবং পাওয়ার কেবল সহ)? সরঞ্জামগুলো কি পরীক্ষার জন্য প্রস্তুত (এতে কি সঠিক ফার্মওয়্যার সংস্করণ চলছে, সবকিছু কি সমর্থিত এবং সব বাতি কি সবুজ)?

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

পরীক্ষা কর্মসূচি

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

সম্প্রদায়

পাইলট প্রস্তুতি প্রক্রিয়ার অংশ হিসেবে, বিক্রেতা/অংশীদার এবং গ্রাহক উভয় পক্ষেই পাইলটের তারিখ, সমস্ত প্রয়োজনীয় ব্যক্তির উপস্থিতি এবং পরীক্ষার জন্য তাদের প্রস্তুতির মধ্যে সমন্বয় করা অপরিহার্য। হায়, কত পাইলটই না শুরু হয়েছে যখন সরঞ্জাম স্থাপন করার পরের দিনই গ্রাহকের মূল ব্যক্তি ছুটিতে চলে গেছেন!

দায়িত্ব/প্রবেশের ক্ষেত্র

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

পাইলট

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

পাইলটের সমাপ্তি

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

উত্স: www.habr.com