Project ও Lab
২১টি lab। প্রতিটাই সত্যি চলে।
Video দেখে সাথে সাথে টাইপ করলেই অনেক training নিজেকে hands-on বলে ফেলে। এখানে কথাটার মানে আলাদা। নিজের cloud account‑এ ২১টি চালু system দাঁড় করাবেন, আর প্রতিটার শেষে automatic কিছু একটা আপনাকে বলে দেবে জিনিসটা সত্যিই কাজ করছে কি না। এই পেজে সব বিস্তারিত লেখা আছে। project‑এর ভেতরে কী থাকে, ভুল হলে কী হয়, আর শেষে যে দুটো আপনার নিজের হয়ে থেকে যায় সেগুলো দেখতে কেমন।
Lab‑এর ভেতরে কী থাকে
চারটা অংশ। প্রতিবার সেই একই চারটা।
২১টির যেকোনোটা খুলুন, সেই একই চারটা অংশ পাবেন। একটা শেষ করলেই বাকি সবগুলোর নিয়ম আপনার জানা হয়ে যায়। তখন মাথা খাটে technology‑তে, assignment কী চাইছে সেটা বুঝতে নয়।
১ · শেষ করার মতো আসল file
চালু code, দরকারি অংশগুলো ফাঁকা রাখা। প্রতিটা ফাঁক দাগানো, তাই কাজ কোথায় সেটা নিয়ে দ্বিধা থাকে না। খালি screen‑এর সামনে বসে কোথা থেকে শুরু করবেন ভাবতে হয় না, আবার রেডি উত্তর copy করার সুযোগও নেই। সপ্তাহ এগোলে file‑এর ধরন বদলায়, গড়নটা একই থাকে।
২ · বানাবেন সত্যিকারের জিনিস
নিজের account‑এ, নিজের login দিয়ে সত্যিকারের cloud server দাঁড় করাবেন। simulator নয়। রাতারাতি নিজেকে মুছে ফেলা practice sandbox‑ও নয়। যে project‑এ টাকা খরচ হতে পারে, সেটা একদম উপরেই লেখা থাকে। আর কাজ শেষে সব বন্ধ করে দেওয়ার ধাপগুলোও সাথে দেওয়া।
৩ · এক command‑এ automatic check
একটা command চালাবেন। সেটা আপনার আসল file আর আপনার চালু system পড়ে বলে দেবে কোনটা ঠিক হয়েছে, কোনটা হয়নি। কিছু fail করলে ঠিক কোন জিনিসটা fail করেছে তার নাম বলে দেয়। ফলে হাতে শুধু নম্বর আসে না, ঠিক করার শুরুর জায়গাটা আসে।
৪ · শেষ করা উদাহরণ
pass করার পর শেষ করা version খুলে নিজেরটার সাথে মিলিয়ে দেখুন। দুটো উত্তরই কাজ করতে পারে, তবু আলাদা হতে পারে। আপনারটা কোথায় অন্য পথ ধরল, সেটা দেখাই শেখার আসল জায়গা। ২১টির মধ্যে ২০টিতে এই উদাহরণ আছে। final project‑এ নেই। ওটা তো আপনারই।
আসল output
Course নিজেই নিজের খাতা দেখে
check চললে ঠিক এমনটাই দেখায়। বোঝার জন্য আপনাকে code পড়তে জানতে হবে না। কী কী পরীক্ষা হলো তার তালিকা, প্রতিটার পাশে pass বা fail লেখা। এখানে দেখছেন সপ্তাহ ৮-এর Python project, আর যে file‑টা চলছে তার নাম validate.sh। তৃতীয় লাইনটা খেয়াল করুন। আমরা যে অর্ধেক-শেষ version আপনাকে দিই, check নিশ্চিত করছে সেটা এখনও fail করে। এটা ইচ্ছে করেই। এতে প্রমাণ হয় ফাঁকগুলো সত্যিকারের ফাঁক, আর project শেষ করতে হলে আপনাকে নিজের হাতে কিছু লিখতেই হবে। যে project‑এর শুরুর file চুপচাপ pass করে যায়, সেটা আপনাকে কিছুই শেখাত না। আর এই লাইনটা না থাকলে কারও চোখেই পড়ত না।
$ ./validate.sh == validating python-automation == [PASS] py_compile: all .py files (syntax) [PASS] unittest: solution passes all tests [PASS] starter is incomplete (tests fail until TODOs are done) == 3 passed, 0 failed ==
তিনটা check। code‑টা ঠিকঠাক Python কি না, শেষ করা উদাহরণটা সত্যিই চলে কি না, আর আপনাকে দেওয়া version এখনও অচল কি না। তিনটাই না মিললে project‑টাকে শেখানোর যোগ্য বলে ধরি না। এই পেজে raw output শুধু এখানেই দেখাচ্ছি। বাকিটা সোজা ভাষায় বলে দেব।
AI প্রসঙ্গে
Checkmark নয়, script কেন
এই প্রোগ্রামের প্রায় যেকোনো exercise‑এর উত্তর language model আপনাকে ধরিয়ে দেবে। দুনিয়া এখন এরকমই। উল্টোটা ভান করলে আপনার সময় নষ্ট হতো, আর আপনার বুদ্ধিকেও ছোট করা হতো। তাই lab‑গুলো আমরা এই দুনিয়ার বিরুদ্ধে বানাইনি, বানিয়েছি এই দুনিয়ার জন্যই।
Checkbox‑এ টিক যে কেউ দিতে পারে, আর ওতে কিছুই মাপা হয় না। check কিন্তু সত্যি কথাটা বলে দেয়, জিনিসটা চলে কি না। কারণ সে আপনার code চালায়, আর আপনার বানানো system‑এ গিয়ে নিজের চোখে দেখে আসে। দেখতে নিখুঁত, অথচ চলে না। এমন উত্তরও ঠিক ততটাই fail করে, যতটা কিছু না লিখলে করত।
কীভাবে ওখানে পৌঁছেছেন, project‑এর তাতে কিছুই যায় আসে না। model ব্যবহার করুন। documentation ঘাঁটুন। সহপাঠীকে জিজ্ঞেস করুন। শুধু একটা কাজ কাউকে দিয়ে করানো যাবে না, আর সেটাই আসল। জিনিসটাকে সত্যি চালাতে হবে, real server‑এ, নিজের login আর নিজের ভুল নিয়ে। তারপর সপ্তাহ ২৪-এ দাঁড়িয়ে মুখে বলতে হবে কেন ওভাবেই বানিয়েছেন।
কাজটাও ঠিক এটাই। দেখতে বিশ্বাসযোগ্য file বানানোর জন্য কাউকে টাকা দেওয়া হয় না। টাকা দেওয়া হয় জিনিসটা চালু রাখার জন্য।
ইচ্ছে করেই ভাঙা
১৪টি project শুরুতেই ভাঙা code ধরিয়ে দেয়
পরিষ্কার শুরু থেকে কিছু বানানো কাজের সহজ অর্ধেক। কঠিন অর্ধেকটার জন্যই আসলে লোক নেওয়া হয়। আগে থেকে ভেঙে পড়ে থাকা, আপনার নিজের লেখা নয় এমন কিছুর ভেতর ঢুকে বের করা কেন ভাঙল।
তাই ২১টির মধ্যে ১৪টি project‑এ code‑এর আরেকটা copy দেওয়া থাকে, যাতে সত্যিকারের ত্রুটি বসানো। কী গোলমাল হয়েছে বের করে ঠিক করা আপনার কাজ। ওই copy আপনার হাতে পৌঁছানোর আগেই project‑এর নিজের check যাচাই করে নিয়েছে যে ওটা সত্যিই ভাঙা। ত্রুটিটা আসল, আপনি খেয়াল করবেন এই আশায় বসিয়ে রাখা কোনো টাইপো নয়।
check নিজের সীমা নিয়েও খোলাখুলি। যে tool দিয়ে সে পরীক্ষা করতে চেয়েছিল সেটা আপনার machine‑এ install করা না থাকলে, সে সেটা বলে দেয় আর ওই আইটেমকে skipped লিখে রাখে। চুপচাপ pass ধরে নেয় না। কী সত্যিই check হলো আর কী হলো না, আপনি সবসময় জানেন। ফাঁকটা লুকিয়ে না রেখে জানিয়ে দেওয়া। এই অভ্যাসটার দাম দেখতে-চকচকে স্কোরের চেয়ে অনেক বেশি, আর প্রোগ্রাম আপনাকে যা যা শেখাতে চায় এটা তার একটা।
Debugging এখানে শেখানো হয়, র্যাগিং হিসেবে নয়
ভাঙা copy হাতে ধরিয়ে দিয়ে শুভকামনা জানিয়ে ছেড়ে দেওয়া হয় না। প্রতিটা class‑এ আগে চিন্তার ধরনটা নিয়ে কাজ হয়। error message কীভাবে পড়বেন, এরপর কোথায় খুঁজবেন, কীভাবে সমস্যাটা ছোট করে আনবেন। তারপর আপনি গিয়ে সেটা করেন। class‑এর ফাঁকে setup, tool বা এখনও অর্থহীন লাগছে এমন error‑এ আটকে গেলে support team তো আছেই। আটকে যাওয়া স্বাভাবিক। একা আটকে থাকা নয়।
পুরো তালিকা
সবগুলো ২১টি lab
প্রতিটা lab প্রোগ্রামের নির্দিষ্ট সপ্তাহের সাথে বাঁধা। কয়েকটা পরে আরও কঠিন হয়ে ফিরে আসে। Kubernetes, অর্থাৎ অনেক machine জুড়ে container চালানোর system, প্রথম দেখবেন সপ্তাহ ১১-তে। আর সপ্তাহ ২১-এ সেটাকেই চাপের মধ্যে চালু রাখবেন। যেকোনো project ধরে সোজা তার সপ্তাহে চলে যেতে পারেন।
setup-validation
সপ্তাহ ১
checker‑টা শেষ করে নিজের কম্পিউটারে চালাবেন। course‑এর দরকারি সব tool ঠিকমতো বসেছে কি না তখনই ধরা পড়ে। সপ্তাহ ২ তাই শুরু হয় কাজ দিয়ে, install‑এর ঝামেলা দিয়ে নয়।
linux-shell-automation
সপ্তাহ ২ ও ৮
Backup, disk-check আর log-rotation script। এখান থেকেই command line ভয়ের জিনিস থাকে না, কাজ করার হাতিয়ার হয়ে ওঠে।
git-collaboration
সপ্তাহ ৩
একই code‑এ পুরো team কীভাবে কাজ করে একে অন্যেরটা মুছে না ফেলে, আর পরিবর্তন কীভাবে review হয়। ভুলগুলো এখানেই করে ফেলুন, গুরুত্বপূর্ণ হয়ে ওঠার আগে।
aws-cli-fundamentals
সপ্তাহ ৪
Command line থেকে read-only AWS operation, সত্যিকারের account‑এ live চালানো। এখানে কিছুতেই আপনার টাকা খরচ হবে না।
security-automation
সপ্তাহ ৬, ১৭ ও ১৯
Cloud‑এ কে কী করতে পারবে সেটা ঠিক করা, তারপর নিয়মগুলো লিখে রাখা। মনে রাখার ভরসায় না থেকে নিয়ম তখন নিজে থেকেই কার্যকর হয়।
aws-storage-databases
সপ্তাহ ৭
Cloud storage আর database ক্লিক করে জোড়া না দিয়ে file‑এ লিখে বর্ণনা করবেন। তারপর নিজের account‑এ সত্যিই বানাবেন, আর সত্যিই আবার মুছে দেবেন।
python-automation
সপ্তাহ ৮ ও ১৮
কাজের বারবার করা অংশগুলোর জন্য Python, সাথে real test। উপরে যে project‑টা দেখলেন এটাই। নিজের শুরুর file এখনও fail করছে কি না, সেটাও নিজেই check করে।
ansible-config-mgmt
সপ্তাহ ৮
একটা file থেকে অনেক machine একইভাবে সেট করা, প্রতিবার। হাতে হাতে configure করে সবগুলো মিলে যাওয়ার আশায় বসে থাকা নয়।
cicd-pipelines
সপ্তাহ ৯ ও ১৯
যে assembly line আপনার laptop থেকে code‑কে নিজে থেকেই live user পর্যন্ত পৌঁছে দেয়, সেটা build করবেন। পথে test হয়, আর কোনো মানুষকে file এদিক-ওদিক copy করতে হয় না।
docker-containers
সপ্তাহ ১০
Application‑কে তার দরকারি সবকিছুসহ প্যাক করা, যাতে আপনার laptop আর cloud‑এ একইভাবে চলে। পড়বেন না, নিজে বানাবেন।
kubernetes-fundamentals
সপ্তাহ ১১ ও ১২
Kubernetes‑এর ভিত্তি, একবারে একটা করে চালু অংশ শিখে। diagram‑এর সাথে নয়, সত্যিকারের cluster‑এর সাথে মিলিয়ে দেখা হয়।
k8s-production-ops
সপ্তাহ ১২ ও ২১
চালু cluster‑এ চারটা drill। খারাপ version release করা, সেটাকে আটকে যেতে দেখা, undo করা, আর পুরোটা সময় user‑দের সেবা চালু রাখা।
helm-charts
সপ্তাহ ১৩
App একবার package করে test আর live environment‑এ বসানো। প্রতিটার জন্য আলাদা করে সবকিছুর copy রেখে দিতে হয় না।
terraform-aws-foundations
সপ্তাহ ৫, ১৪, ১৫ ও ১৭
নিজের server আর network code হিসেবে লিখে রাখা। review করা যায়, একদম গোড়া থেকে আবার বানানোও যায়। আপনি না বলা পর্যন্ত কিছুই তৈরি হয় না।
observability
সপ্তাহ ১৬ ও ২১
Monitoring। chart আর alert দেখিয়ে দেয় আপনার system এই মুহূর্তে কী করছে, ফলে আপনি আশা করেন না, জানেন। Prometheus আর Grafana দিয়ে বানানো।
observability-stack
সপ্তাহ ১৬ ও ২১
পুরো monitoring setup, মাপা যায় এমন reliability target আর সত্যিকারের user impact‑এ বেজে ওঠা alert সহ। alert কাজ করে, এটা ধরে নেবেন না, প্রমাণ করবেন।
platform-golden-path
সপ্তাহ ২০
রেডি একটা setup, নতুন service ঠিকভাবে শুরু করতে অন্য engineer‑রা যেটা বারবার কাজে লাগাতে পারে। তারপর সেটা দিয়ে আপনি সত্যিই একটা বানাবেন। নিচে দেওয়া দ্বিতীয় portfolio project।
sre-incident-response
সপ্তাহ ২১ ও ২২
Reliability target, জিনিস ভাঙলে ধাপে ধাপে কী করতে হবে তার guide, আর পরে দোষারোপ ছাড়া লিখিত review। রাত ৩টায় আপনি যা করবেন, তা লেখা হয় রাত ৩টার আগেই।
performance-scaling
সপ্তাহ ২২
System‑এ ভারী traffic ছুড়ে দিয়ে দেখবেন সে সামলাতে নিজের কপি বাড়াচ্ছে, ১ থেকে ৫। কতটা চাপ নিতে পারবেন সেটা তখন অনুমান থাকে না, মেপে বলা যায়।
final project
সপ্তাহ ২৩ ও ২৪
সপ্তাহ ৪–২২-এর সবকিছু জোড়া লেগে একটা চালু system। এটা আপনি বানাবেন, present করবেন, আর প্রশ্নের উত্তর দেবেন। নিচে দেওয়া প্রথম portfolio project।
career-prep
সপ্তাহ ২৫
Résumé, system-design practice আর গোছানো interview‑এর উত্তর। আছে কি না সেটা নয়, ভেতরে বিষয়বস্তু আছে কি না সেটাই check করা হয়।
Portfolio
দুটো জিনিস, যা বানিয়ে আপনি কাউকে দেখাতে পারবেন
ঊনিশটা project একটা করে tool শেখায়। বাকি দুটো এমন কিছু দাঁড় করায় যা পুরোপুরি আপনার। অচেনা কাউকে ধরে ধরে বুঝিয়ে দিতে পারবেন, আর link‑টা পাঠিয়েও দিতে পারবেন।
Final project — code থেকে live user, নিরাপদে
সপ্তাহ ২৩ ও ২৪
পুরো পথটা শুরু থেকে শেষ পর্যন্ত বানাবেন। code, যে assembly line সেটাকে test করে package করে, পথে বসানো security check, real cloud server‑এ release, আর যে monitoring প্রমাণ করে জিনিসটা সুস্থ আছে। code merge করলেই পরিবর্তন live হয়, দরকার হলে একইভাবে roll back। বাকি project‑গুলো অংশগুলো শেখায়। এটা অংশগুলোর জোড়ের দায় আপনার কাঁধে তুলে দেয়।
তারপর এটাকে defend করবেন। শব্দটা ভারী শোনায়, কাজটা সোজা। যা বানিয়েছেন তা present করবেন, আর নিজের সিদ্ধান্ত নিয়ে আসল প্রশ্নের উত্তর দেবেন। বাস্তবে মানে দাঁড়ায়:
- জিনিসটা কীভাবে জোড়া লেগেছে আর কেন, সবাইকে ধরে ধরে বোঝাবেন।
- কঠিন প্রশ্নের মুখে পড়বেন। “এটা কী করে” নয়, বরং “এভাবে কেন, ওভাবে কেন নয়, আর এতে আপনার কী খরচ হলো।”
- JD Lincoln আপনার চালু system‑এ live কিছু একটা ভেঙে দেবেন। কী হলো সেটা class‑এর সামনে বসেই বের করে ঠিক করবেন।
এই একটা project‑এরই শেষ করা কোনো উদাহরণ নেই। দেওয়ার মতো কিছু নেই-ও। এটা আপনার design, আপনার trade-off, আপনার উত্তর।
রেডি একটা setup, যা অন্য engineer‑রা কাজে লাগাতে পারে
সপ্তাহ ২০
Final project আপনাকে system বানাতে বলে। এটা চায় আরও কঠিন কিছু। অন্য engineer‑রা যেটা দিয়ে নিজেদের system বানাবে, সেই জিনিসটাই বানান।
একটা starting kit আর একটা generator তৈরি করবেন। কেউ একটা command চালাবে, আর নতুন একটা service হাজির হবে। তার packaging, তার release setup, তার assembly line আগে থেকেই জোড়া লাগানো, আগে থেকেই ঠিক। প্রতিটা engineer‑কে আলাদা করে নিজের মতো আবিষ্কার করে নিতে হয় না। তারপর project‑টা ওই তৈরি হওয়া service সত্যিই build করে দেখায়, শর্টকাটটা সত্যিই কাজে লাগে।
এটা একদম অন্য মাপের কাজ। আপনি আর সেই মানুষ থাকেন না যে সমস্যাটা একবার সমাধান করে। আপনি সেই মানুষ হয়ে ওঠেন, যে পরের একশো জনের পক্ষে ভুল করা কঠিন করে দেয়। platform engineer আর একই tool জানা লোকের মধ্যে পার্থক্যটা মূলত এখানেই।
এসে একটা দেখে যান
সিদ্ধান্ত নেওয়ার আগে একটা lab চলতে দেখুন
প্রথম class ফ্রি। কোনো payment নেই, card নেই, বাধ্যবাধকতাও নেই। এসে নিজের চোখের সামনে একটা real project pass বা fail করতে দেখুন। প্রোগ্রামের বর্ণনা দেওয়া পেজ দেখে নয়, ওটা দেখেই বিচার করুন।
শুরু করতে লাগবে শুধু সাধারণ কম্পিউটার চালানোর দক্ষতা, command line শেখার ইচ্ছা, আর একটা AWS account। আগে DevOps অভিজ্ঞতা না থাকলেও চলবে। Class হয় English বা বাংলায়, বাংলাভাষী instructor‑এর সাথে। কোন option আপনার জন্য ঠিক আর পরের batch কবে, সেটা admissions‑কে জিজ্ঞেস করুন: admissions@leadsacademy.org।