DevOps ইন্টারভিউ — Linux, Docker, Kubernetes, Terraform, CI/CD আর troubleshooting

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

একটি ছোট উদাহরণ যোগ করলে উত্তর জীবন্ত হয়। পর্ব ০৯-এর নমুনা log-এ “checkout-এ 500” রিপোর্ট আসলে ৭টি 5xx ছিল, ৬টি 500 আর ১টি 504, সবই POST /api/orders-এ।

ফলো-আপ: “সবচেয়ে দামি একটি প্রশ্ন কোনটি?” — “ঠিক আগে কী বদলেছিল?”

উত্তর: অনুমানকে তথ্য বলে চালাবেন না। তিনটি অংশে বলুন: যা জানি, যা জানি না, আর কীভাবে জানব। যেমন: “Gateway API নিজে production-এ চালাইনি। জানি এটি Ingress-এর পরের ধাপ, আর এতে দায়িত্ব ভাগ করা যায়। নির্দিষ্ট field নিশ্চিত নই, তাই official docs দেখে --dry-run=server দিয়ে যাচাই করব।”

অচেনা বিষয়ে কাছের জানা ধারণা থেকে যুক্তি করতেও পারেন, তবে আগে বলে নিন, “এটি আমার অনুমান।”

ফলো-আপ: “Google করতে পারবেন না, তাহলে?” — যুক্তি দিয়ে পরীক্ষার পথ বলুন: কোন আউটপুট দেখলে কোন ধারণা বাদ পড়বে।

উত্তর: সাধারণত আগে ক্ষতি থামানো, যাকে mitigation বলে। Rollback, traffic সরানো বা feature বন্ধ করা কারণ পুরো না জেনেও করা যায়। ক্যাপস্টোনে ২৫% request ভাঙছিল: আগের SHA-তে ফিরতেই ২৬ সেকেন্ডে ক্ষতি থামল, কারণ পরে ধীরে-সুস্থে খোঁজা হলো।

দুটি ব্যতিক্রম মনে রাখুন। নিরাপত্তার ঘটনায় server মুছে ফেললে প্রমাণ হারায়, তাই আগে আলাদা করা হয়। আর schema বদলের পরে কোড rollback করলে ডেটা নষ্ট হতে পারে, তাই আগে দেখে নিতে হয় পুরোনো কোড নতুন schema-য় চলবে কি না।

ফলো-আপ: “Mitigation আর resolution কি এক?” — না। Mitigation ক্ষতি থামায়, resolution সেবা স্থির করে ঘটনা বন্ধ করে।

উত্তর: 755 মানে owner rwx, group আর other r-x. প্রতিটি সংখ্যা r=4, w=2, x=1-এর যোগফল। umask 027 বলে কোন bit কেড়ে নেওয়া হবে। ফাইলের শুরু 666 থেকে হয় 640, directory-র 777 থেকে হয় 750.

ফলো-আপ: “Directory-তে x মানে কী?” — ভেতরে ঢোকা আর নাম ধরে ফাইলে পৌঁছানোর অনুমতি।

উত্তর: Signal-এ মরলে exit code হয় ১২৮ + signal নম্বর। 137 = 128 + 9, মানে SIGKILL. 143 = 128 + 15, মানে SIGTERM. 137 মানেই OOM নয়। পর্ব ৪৩-এর আসল run-এ Reason: OOMKilled আর Exit Code: 137 একসাথে এসেছিল, কিন্তু আরেকটি Pod-এ Reason: Error আর 137: সেখানে grace period ফুরানোয় kubelet নিজে SIGKILL পাঠিয়েছিল।

ফলো-আপ: “তাহলে কীভাবে আলাদা করবেন?” — Kubernetes-এ Reason, Docker-এ .State.OOMKilled, আর VM-এ journalctl -k.

উত্তর: প্রতি core-এ ২, অর্থাৎ কাজ সারিতে জমছে। কিন্তু Linux-এর load-এ শুধু CPU-র অপেক্ষা নয়, D state-এর task-ও গোনা হয়, মানে যারা disk-এর অপেক্ষায় আটকে। তাই top-এর wa দেখুন। পর্ব ১১-এর নমুনায় ২ core-এ load 6.42, কিন্তু wa ৪১%: CPU আসল সমস্যা ছিল না, memory শেষ হয়ে swap চলছিল। তাই core বাড়ালে তেমন লাভ হতো না।

ফলো-আপ: “কোন ক্রমে দেখবেন?” — USE method: প্রতিটি resource-এর utilization, saturation আর errors.

উত্তর: একা দেখলে নয়। Linux ফাঁকা RAM ফেলে রাখে না, disk-এর ডেটা page cache-এ রাখে, আর দরকার হলে ছেড়ে দেয়। তাই available ঘর দেখুন, আর vmstat-এর si, so দিয়ে দেখুন swap এখনই চলছে কি না।

ফলো-আপ: “drop_caches চালাবেন?” — না। কারণ ঠিক হয় না, উল্টো cache হারিয়ে disk আরও ব্যস্ত হয়।

উত্তর: awk '{print $1}' access.log | sort | uniq -c | sort -rn | head. uniq শুধু পাশাপাশি একই লাইন মেলায়, তাই আগে sort লাগে। দ্বিতীয় sort -rn সংখ্যা ধরে বড় থেকে ছোট সাজায়।

ফলো-আপ: “grep 500 দিয়ে 500 গুনলে?” — পর্ব ০৯-এর আসল run-এ grep -c 500 দিল 13, কারণ byte-এর ঘরেও 500 ছিল। কড়া নকশা '" 500 ' দিল 6.

উত্তর: -e ব্যর্থ কমান্ডে থামায়, -u অজানা variable-এ থামায়, আর pipefail pipeline-এর মাঝের ব্যর্থতা ধরে। ফাঁদ আছে দুটি। grep কিছু না পেলে exit 1 দেয়, তাই সাধারণ “মিল নেই” ফলেও script থামে। আর if deploy; then বা deploy || echo no লিখলে deploy function-এর ভেতরে -e কাজই করে না।

ফলো-আপ: “কেন দরকার?” — একটি বানান ভুলের cd ব্যর্থ হওয়ার পরেও rm -rf ./* চলে গেলে ভুল ফোল্ডার মুছে যায়।

উত্তর: Refused মানে packet পৌঁছেছে, কিন্তু ওই port-এ কেউ শুনছে না, RST ফিরেছে, আর তা আসে খুব দ্রুত। দেখুন ss -tlnp আর process. Timeout মানে উত্তরই আসেনি, কেউ চুপচাপ ফেলে দিচ্ছে বা পথ নেই। দেখুন firewall, security group, route.

502 মানে proxy আছে, কিন্তু পেছনের app সংযোগ নেয়নি বা অচল উত্তর দিয়েছে। 504 মানে app সময়মতো উত্তর দেয়নি, তাই তার log আর ডেটাবেস দেখুন।

ফলো-আপ: “Site-এ ঢুকতে না পারলে প্রথমে?” — লক্ষণ নিশ্চিত করে স্তর ধরে: DNS, পথ, port, TLS, HTTP.

উত্তর: Image হলো read-only layer-এর সারি। Container হলো তার ওপর একটি writable layer আর একটি চলমান process. VM-এর নিজের kernel থাকে, container host-এর kernel ভাগ করে, তাই হালকা, কিন্তু আলাদা থাকার সীমাও ভিন্ন।

ফলো-আপ: “Container মুছলে ভেতরের লেখা ফাইল?” — writable layer-এর সাথে যায়। তাই ডেটা রাখুন volume-এ।

উত্তর: RUN build-এর সময় চলে আর layer বানায়। CMD container চালুর সময় চলে আর শুধু config-এ থাকে। ENTRYPOINT মূল প্রোগ্রাম, CMD তার ডিফল্ট argument. docker run-এর শেষের লেখা শুধু CMD-কে বদলায়।

ফলো-আপ: “শুধু CMD থাকা image-এ docker run img hello দিলে?” — hello পুরো CMD-র জায়গা নেয়। পর্ব ৩৭-এর আসল run-এ executable file not found in $PATH, exit 127.

উত্তর: নিয়ম সরল: একটি ধাপ বাতিল হলে নিচের সব ধাপ বাতিল। পর্ব ৩৭-এর আসল run-এ COPY . . আগে আর pip পরে ছিল, তাই app.py-র একটি শব্দ বদলাতেই pip আবার চলল, যদিও dependency একই। সমাধান ক্রমে: আগে COPY requirements.txt ., তারপর install, শেষে source.

.dockerignore দিয়ে context ছোট রাখুন, আর CI-তে remote cache নিন।

ফলো-আপ: “.dockerignore শুধু গতির জন্য?” — না। ওই পর্বের run-এ এটি ছাড়া .env.sample image-এ ঢুকে গিয়েছিল, মানে secret-ও ঢুকতে পারে।

উত্তর: আগের layer read-only. নতুন layer-এ শুধু একটি whiteout চিহ্ন বসে, আসল বাইট আগের layer-এই থাকে। তাই মুছতে হবে একই RUN-এ। Secret হলে এটি ফাঁস: যে image টানবে, সে layer খুলে ফাইলটি পেতে পারে।

ফলো-আপ: “Build-এ secret লাগলে?” — BuildKit-এর secret mount, যা layer-এ থাকে না (পর্ব ৩৮)। ফাঁস হলে আগে key বাতিল করুন।

উত্তর: Build-এর টুল ship না করে image ছোট আর নিরাপদ রাখতে। পর্ব ৩৮-এর আসল run-এ একই ছোট C প্রোগ্রাম: compiler-সহ এক stage ২২৯MB, multi-stage আর alpine ১২.১MB, multi-stage আর scratch ৪৭kB. ক্যাপস্টোনে এর আরেকটি ব্যবহার আছে: চূড়ান্ত image ফাইল নেয় test stage থেকে, তাই test ব্যর্থ হলে image-ই হয় না।

ফলো-আপ: “Scratch-এর দাম কী?” — ভেতরে shell নেই, তাই debug কঠিন।

উত্তর: প্রথমটি shell form: Docker চালায় /bin/sh -c, তাই sh হতে পারে PID 1, আর SIGTERM সবসময় app পর্যন্ত পৌঁছায় না। দ্বিতীয়টি exec form: app নিজেই PID 1. পর্ব ৩৮-এর আসল run-এ docker stop -t 10-এ shell form-এর একটি রূপ ১০.৩২ সেকেন্ড নিয়ে exit 137 দিল, আর exec form ০.২৯ সেকেন্ডে exit 0.

৫০টি container-এর rolling update-এ এই পার্থক্য deploy-কে অনেক ধীর করে, আর চলমান request ভাঙতে পারে।

ফলো-আপ: “App নিজেই PID 1 হলেই কি হলো?” — না। পর্ব ৩৯-এর run-এ handler ছাড়া Python PID 1 হিসেবে SIGTERM উপেক্ষা করে 137 দিল। Handler লিখুন, অথবা --init দিন: তখন exit 143.

উত্তর: EXPOSE মূলত নথি, সে port খোলে না। পর্ব ৩৭-এর আসল run-এ শুধু EXPOSE-এ curl exit 7 দিল, মানে সংযোগই হয়নি। -p দিয়ে publish করতে হয়, যেমন -p 127.0.0.1:8080:8000. শুধু 127.0.0.1-এ বাঁধলে বাইরের কেউ পৌঁছাতে পারেন না।

উত্তর: latest শুধু default tag, সবচেয়ে নতুন image-এর নিশ্চয়তা নয়। Tag সরানো যায়, digest হলো manifest-এর SHA-256, তাই বদলায় না। latest-এ কোন code চলছে বলা যায় না, rollback-ও অনিশ্চিত। ক্যাপস্টোনে image tag ছিল commit SHA, আর উৎপাদনে digest-এ বাঁধা আরও শক্ত।

ফলো-আপ: “Signature কী প্রমাণ করে?” — কে সই করেছে আর digest অক্ষত আছে। কোড নিরাপদ, তা নয়।

উত্তর: না। STATUS হলো kubectl-এর নিজের হিসাব করা লেখা। পর্ব ৪৩-এর আসল run-এ ImagePullBackOff Pod-এর phase ছিল Pending, আর CrashLoopBackOff Pod-এর phase ছিল Running.

তাই শুধু phase == Running দেখে alert বসালে ভাঙা Pod-ও সুস্থ মনে হবে। Alert বসান restart count আর Ready condition-এ।

উত্তর: CrashLoopBackOff মানে “এখন বিরতিতে আছি”, চিরকাল crash নয়। পর্ব ৪৩-এর run-এ প্রথম restart প্রায় সঙ্গে সঙ্গে, তারপর kubelet-এর বার্তায় বিরতি 10s, 20s, 40s, 1m20s, 2m40s, আর 5m0s-এ থেমে গেল। মাপা ফাঁক বার্তার চেয়ে ০ থেকে ৯ সেকেন্ড বেশি ছিল।

নথি অনুযায়ী container ১০ মিনিট টানা ভালো চললে backoff আবার শুরু থেকে গোনা হয়। এটি ওই run-এ মাপা হয়নি, আর নতুন version-এ সংখ্যা বদলাতে পারে।

উত্তর: restartPolicy Always মানে সত্যিই সবসময়, সফল exit-এও restart. পর্ব ৪৩-এ always-exit0 Pod ২৫ সেকেন্ডে ২ বার restart হয়েছিল। একবারের কাজ তাই Deployment-এ নয়, Job-এ চালান। আরেকটি কারণ: ভুল liveness path. ওই পর্বে সুস্থ nginx ভুল পথের জন্য kill হলো, Reason: Completed, Exit Code: 0, আর মিনিটখানেকে CrashLoopBackOff. কারণটি ছিল Events-এ।

উত্তর: kubectl describe pod-এর Events পড়ুন। পর্ব ৪৮-এর আসল run:

Warning FailedScheduling 0/1 nodes are available: 1 Insufficient cpu,
1 Insufficient memory. … preemption: 0/1 nodes are available:
1 Preemption is not helpful for scheduling.

Scheduler আসল ব্যবহার নয়, বুক করা request দেখে। অন্য Pod বেশি request করে রাখলে node ব্যবহারে ফাঁকা থেকেও হিসাবে ভরা। অন্য কারণ: label না মেলা, taint আছে কিন্তু toleration নেই, PVC bound হয়নি।

ফলো-আপ: “PVC Pending কেন?” — মানানসই class নেই, provisioner-এর সমস্যা, অথবা WaitForFirstConsumer-এ Pod-এর অপেক্ষা।

উত্তর: Container একবারও চলেনি, তাই log নেই, RESTARTS ০, phase Pending. describe-এর Events পড়ুন। Message-এর শেষ শব্দই কারণ বলে: পর্ব ৪৩-এর run-এ ছিল not found, মানে tag বা নাম ভুল। unauthorized বা denied সাধারণত private registry-র অনুমতির সমস্যা। প্রথমে ErrImagePull, তারপর বিরতি দিয়ে চেষ্টা, তাই ImagePullBackOff.

উত্তর: না। আগে memory-র গ্রাফ দেখুন। না নামা সিঁড়ি মানে leak, তাই কোড ঠিক করুন। ট্রাফিকের সাথে ওঠানামা মানে সীমা ছোট, তাই মেপে বাড়ান। পর্ব ৪৩-এর run-এ ৬৪ MiB সীমায় শেষ লাইন ছিল allocated 56 MiB, কারণ Python-এর নিজেরও memory লাগে। App error লেখার সুযোগই পায় না, তাই প্রমাণ থাকে status-এ।

ফলো-আপ: “CPU limit পার হলে?” — মরে না, throttle হয়। পর্ব ৪৮-এ ০.১ CPU-র Pod ৫ সেকেন্ডে মাত্র ০.৫৩ সেকেন্ড CPU পেল। Latency বাড়ে, log-এ কিছু থাকে না।

উত্তর: Image আছে, node আছে, কিন্তু container বানানোর তথ্য অসম্পূর্ণ, যেমন Secret নেই। পর্ব ৪৩-এর run-এ Event ছিল secret "db-secret" not found. Pod মোছার দরকার হয়নি: Secret তৈরি হতেই kubelet-এর পরের চেষ্টায় Pod 1/1 Running হলো।

উত্তর: পর্ব ৪৫-এর আসল run-এ চারটি আলাদা ভুল ঘটানো হয়েছিল: selector টাইপো, targetPort: 9090 (app শোনে 8080), targetPort: web (নামটি নেই), আর সব Pod unready. চারটিতেই curl exit 7. তাই error দেখে কারণ বলা যায় না, কারণ ধরা পড়ে EndpointSlice আর Pod পড়ে।

ক্রম: kubectl get svc, Pod-এর ভেতর থেকে getent hosts, kubectl get pods --show-labels, slice-এর PORTS আর ready, তারপর Pod IP-তে সরাসরি curl.

ফলো-আপ: “সঙ্গে সঙ্গে ব্যর্থ আর timeout কি এক?” — না। ফাঁকা Service-এ ০ ms-এ বাতিল, মৃত Pod IP-তে ৩ সেকেন্ড অপেক্ষার পরে timeout.

উত্তর: না। এই কলাম শুধু ঠিকানা দেখায়, অবস্থা নয়। পর্ব ৪৩-এর run-এ shop-a unready হওয়ার পরেও কলামে দুটি IP ছিল, কিন্তু ভেতরে ready=false, আর ৮টি অনুরোধের ৮টিই গেল shop-b-তে। তাই conditions.ready পড়ুন। পুরোনো Endpoints object পর্ব ৪৫-এর run-এ deprecated সতর্কতা দিয়েছিল (v1.33+).

উত্তর: Liveness ব্যর্থ হলে container restart. Readiness ব্যর্থ হলে শুধু traffic বন্ধ, restart নয়। Startup ধীরে চালু হওয়া app-কে সময় দেয়, আর সফল হওয়ার আগে বাকি দুটি শুরু হয় না।

Liveness ডেটাবেস ছুঁলে ডেটাবেস ধীর হলেই সব Pod-এর probe একসাথে ব্যর্থ, Kubernetes সব container মারে, নতুনগুলো খালি cache নিয়ে ধীর ডেটাবেসে আরও চাপ দেয়। একটি সমস্যা হয়ে যায় পুরো outage.

ফলো-আপ: “দুই probe-এ একই endpoint?” — ক্যাপস্টোনে তাই ছিল, ফলে readiness-এর সমস্যায় অকারণে RESTARTS 1. বড় service-এ আলাদা রাখুন।

উত্তর: সর্বোচ্চ ১০ + ৩ = ১৩, সর্বনিম্ন available ১০ − ২ = ৮. maxUnavailable ০ মানে নতুন Pod ready না হলে পুরোনোটি নামে না। ক্যাপস্টোনের প্রথম খারাপ release-এ ঠিক এটিই বাঁচিয়েছিল: নতুন Pod কখনো ready হয়নি, পুরোনো তিনটি চলল, ট্রাফিকে একটিও ভুল নেই।

ফলো-আপ: “PDB কি rolling update থামায়?” — না, PDB শুধু eviction-এর জন্য।

উত্তর: না। progressDeadlineSeconds পার হলে শুধু একটি condition বদলায়: Progressing=False, reason ProgressDeadlineExceeded. এটি মোট সময়ের সীমা নয়, শেষ অগ্রগতির পরের সময়। Default ৬০০ সেকেন্ড। সিদ্ধান্ত আপনার বা pipeline-এর।

পুরো ঘটনাটি অংশ ৮-এর চতুর্থ drill-এ আছে।

উত্তর: Pod Terminating হয়, পাশাপাশি Service থেকে সরে, preStop চলে, তারপর SIGTERM, আর সীমা ফুরালে SIGKILL. ডিফল্ট grace period ৩০ সেকেন্ড। App যদি SIGTERM সামলায় না, তাহলে চলমান request ভাঙে। ক্যাপস্টোনের app SIGTERM পেয়ে /healthz-এ 503 দেয় আর ৩ সেকেন্ড কাজ শেষ করে: এটিই graceful shutdown.

ফলো-আপ: “--grace-period=0 --force?” — শেষ উপায়। API থেকে Pod মুছলেও node-এ process চলতে পারে, kubectl নিজেই সতর্ক করে।

উত্তর: kubectl debug দিয়ে ephemeral container জুড়ে দিন। পর্ব ৪৩-এর run-এ exec দিল executable file not found in $PATH, exit 127. kubectl debug nosh --image=alpine:3.20 --target=app চলন্ত Pod-এ নতুন container জুড়ল, Pod restart হয়নি, RESTARTS ০.

ফলো-আপ: “সবাইকে এই অধিকার দেবেন?” — না, RBAC দিয়ে সীমিত রাখুন।

উত্তর: Role এক namespace-এর। ClusterRole namespace-হীন, আর RoleBinding দিয়ে এক namespace-এও ব্যবহার করা যায়। RBAC শুধু অনুমতি যোগ করে: deny নিয়ম নেই, যা দেওয়া হয়নি তা বন্ধ।

যাচাই করুন kubectl auth can-i list pods -n abcl-kx --as=$SA দিয়ে। পর্ব ৪৯-এর আসল run-এ list pods yes, কিন্তু delete pods আর get secrets no. আর RoleBinding নিজের namespace-এর বাইরে খাটেনি।

ফলো-আপ: “৪০১ আর ৪০৩?” — ৪০১: পরিচয় গৃহীত হয়নি। ৪০৩: পরিচয় মিলেছে, অনুমতি নেই।

উত্তর: না বলব, আর সংখ্যা দেখাব। পর্ব ৪৯-এর run-এ এমন wildcard Role-এ app get secrets, create rolebindings আর create pods/exec সবই পেল। অর্থাৎ app দখল হলে namespace-এর সব Secret পড়া যায়, নিজেকে আরও অনুমতিও দেওয়া যায়। Error-এ লেখা resource আর verb দেখে শুধু সেটুকুই দিন, আর auth can-i দিয়ে যাচাই করুন। এটিই least privilege.

উত্তর: State config-কে বাস্তবের id-র সাথে মেলায়, metadata রাখে, আর plan দ্রুত করে। ভূমি অফিসের খতিয়ানের মতো: কোন দলিলের জমি কোনটি। Secret-ও এতে খোলা লেখায় থাকতে পারে। তাই backend-এ encryption আর ছোট অনুমতি লাগে, আর state ফাইল Git-এ রাখবেন না।

ফলো-আপ: “terraform plan “No changes” মানে সব ঠিক?” — মানে Terraform যা জানে তা ঠিক। হাতে বানানো জিনিস সে দেখে না।

উত্তর: আগে শেষ লাইন: Plan: … to add, … to change, … to destroy, আর সেটি আপনার edit-এর সাথে মানায় কি না। তারপর must be replaced, will be destroyed, আর # forces replacement. Replace গোনা হয় ১ add আর ১ destroy হিসেবে।

terraform plan -out=v1.plan আর terraform apply v1.plan দিলে যা review হয়েছে ঠিক তাই চলে। State বদলে গেলে Terraform plan-টিকে stale বলে থামে।

ফলো-আপ: “~> 3.4 মানে?” — 3.4 বা ওপরে, তবে 4.0-এর নিচে।

উত্তর: বাস্তব আর config-এর অমিল, সাধারণত হাতের বদলে। Terraform নিজে সারাক্ষণ দেখে না, চালালে তবেই দেখে। পর্ব ৫৩-এর আসল run-এ kubectl patch-এর পরে terraform plan -refresh-only দেখাল:

Note: Objects have changed outside of Terraform
  ~ "LOG_LEVEL" = "info" -> "debug"

plan -detailed-exitcode দেয় ০ (বদল নেই), ১ (error), ২ (বদল আছে)। রাতের pipeline-এ এটি চালালে drift-এর alert পাওয়া যায়।

হাতের বদল ভুল হলে apply দিয়ে ফেরান। ঠিক হলে code বদলান। শুধু apply -refresh-only দিলে state বদলায়, কিন্তু পরের plan আবার বদল দেখায়: ওই run-এ তাই 1 to change.

উত্তর: স্থির পরিচয় দরকার হলে for_each. count-এ পরিচয় হলো অবস্থান, তাই তালিকার মাঝখান মুছলে পরের সব সরে যায়। পর্ব ৫২-এর আসল run-এ khulna মুছতে count ২টি জিনিস মুছে ১টি নতুন বানাল, আর for_each মুছল শুধু ১টি। Database হলে ডেটা যেত।

ফলো-আপ: “count কখন ঠিক?” — একই রকম কপি, অথবা শর্তে থাকা-না-থাকা, যেমন count = var.enabled ? 1 : 0.

উত্তর: না। আগে Lock Info পড়ুন: কে ধরে আছেন, কখন থেকে। Lock-এর কাজই দুজনের একসাথে লেখা আটকানো। এটি ত্রুটি নয়, সুরক্ষা। CI-তে -lock-timeout=60s দিলে Terraform অপেক্ষা করে।

-lock=false সুরক্ষাটিই খুলে ফেলে। force-unlock শুধু তখন, যখন নিশ্চিত যে holder সত্যিই মৃত, আর ID নিজের চোখে দেখেছেন। পর্ব ৫৩-এর run-এ ভুল ID দিলে সে কিছু করেনি: lock id … does not match existing lock.

উত্তর: পর্ব ৫৩-এ এটি ইচ্ছা করে ঘটানো হয়েছিল। Holder রয়ে গেল, Job চলছিল। force-unlock-এর পরে plan বলল 1 to add, কারণ state-এ Job লেখা হয়নি। apply দিল jobs.batch "boighor-reindex" already exists. সমাধান terraform import.

অর্থাৎ ক্রম: (১) runner সত্যিই মৃত, নিশ্চিত করা; (২) সঠিক ID-তে force-unlock; (৩) plan পড়া; (৪) বাস্তবে যা তৈরি হয়েছে তা import; (৫) আবার plan-এ শূন্য দেখা।

উত্তর: Lock state-কে বাঁচায়, পুরোনো code থেকে বাঁচায় না। পর্ব ৫৩-এর উদাহরণে রাফি Job যোগ করে apply করলেন। মিতুর code-এ Job নেই, অথচ state-এ আছে, তাই তাঁর plan সেটি মুছতে চাইল। তাই apply হোক CI থেকে, main branch-এর সর্বশেষ code নিয়ে, আর plan পড়া বাধ্যতামূলক।

উত্তর: moved ব্লক দিয়ে: এটি infrastructure না ছুঁয়ে state-এর ঠিকানা বদলায়, plan-এ শূন্য দেখুন। state rm শুধু Terraform-কে ভুলিয়ে দেয়, জিনিসটি বাস্তবে থাকে। destroy বাস্তবের জিনিস মোছে। পর্ব ৫৩-এ state rm-এর পরে apply দিল configmaps "boighor-config" already exists.

উত্তর: ক্যাপস্টোনে এটি চালিয়ে দেখা হয়েছে: image বদলে গেল, কিন্তু Terraform তা জানে না। পরের plan-এ drift ধরা পড়ল, আর ~ image লাইন আবার নতুন SHA-তে ফেরাতে চাইল। পরের apply ভাঙা version ফিরিয়ে আনত।

নিয়ম: জরুরি মুহূর্তে undo চলতে পারে, তবে পরে অবশ্যই variable বা Git-এ একই সিদ্ধান্ত লিখতে হবে। GitOps-এও একই কথা।

উত্তর: আগে প্রশ্ন: কতবার deploy, দলের আকার, downtime চলবে কি না। তারপর ক্রম: দ্রুত check আগে (lint, unit), ব্যর্থ হলে থামা। Multi-stage build, image-এর tag commit SHA. Smoke test, scan আর SBOM. Registry-তে push. Dev থেকে prod-এ একই digest promote. Prod-এ canary বা rolling, SLO দেখে এগোনো। Rollback মানে আগের digest.

নিরাপত্তা: দীর্ঘস্থায়ী key নয়, OIDC. Action পূর্ণ commit SHA-তে pin. ক্যাপস্টোনের pipeline.sh এই ধাপগুলোর ছোট রূপ।

ফলো-আপ: “Runner বাড়িয়েও সময় কমছে না কেন?” — সময় critical path-এ আটকে আছে, runner-এর লাইনে নয়।

উত্তর: পরীক্ষার ফল নির্দিষ্ট বাইটের। Prod-এর জন্য আবার build করলে বাইট বদলাতে পারে, তাই যা পরীক্ষিত তা আর চলে না। Config থাকে image-এর বাইরে, deploy-এর সময় আসে। Promotion-এ tag বা নথি বদলায়, digest নয়।

ফলো-আপ: “Rollback-এর শর্ত?” — পুরোনো digest registry-তে আছে, আর schema বা ডেটা পুরোনো কোডের সাথে মানানসই।

উত্তর: Blue-green দ্রুত ফেরে, কিন্তু blast radius ১০০%. Canary blast radius ছোট রাখে, কিন্তু দুই version দীর্ঘ সময় একসাথে চলে। Replica দিয়ে ১%-এ ১০০টি Pod লাগে, তাই L7 ওজন দিয়ে করুন।

ফলো-আপ: “Deploy আর release?” — Deploy কোড চালায়, release আচরণ খোলে। Flag দুটিকে আলাদা করে।

উত্তর: এক ধাপে নয়, কারণ rolling update-এ দুই version একসাথে চলে। Expand and contract: নতুন কলাম যোগ, দুই কলামেই লেখা, পুরোনো ডেটা backfill, পড়া নতুন কলামে, লেখা শুধু নতুনে, শেষে পুরোনো কলাম বাদ। প্রতিটি ধাপ আলাদা release, যাতে rollback সম্ভব থাকে।

উত্তর: Pull-এ cluster-এর ভেতরের agent Git থেকে পড়ে, তাই CI-এর হাতে cluster credential লাগে না। Rollback হলো git revert, আর controller সেটি মিলিয়ে নেয়। kubectl rollout undo চালালে সেটি নিজেই drift, Git আবার উল্টে দেয়।

Pull সব ঝুঁকি সরায় না: config repository-তে merge মানেই deploy, আর agent-এর হাতে cluster-এ বড় অনুমতি থাকে।

ফলো-আপ: “Sync আর health?” — Sync মানে Git-এর সাথে মিল, health মানে সত্যিই কাজ করছে। পর্ব ৬০-এর ভুল tag-এর commit-এ YAML ঠিক ছিল, ধরা পড়ল শুধু চালাতে গিয়ে।

উত্তর: SLI মাপ, SLO অভ্যন্তরীণ লক্ষ্য, SLA ফলাফলসহ চুক্তি। SLO সাধারণত SLA-র চেয়ে কড়া। ব্যবহারকারী CPU দেখেন না, তাই CPU ভালো SLI নয়। গড় latency-ও নয়, কারণ কিছু মানুষের কষ্ট গড়ে লুকিয়ে যায়। Page হবে ব্যবহারকারীর কষ্টে, ভেতরের কারণ থাকবে dashboard-এ।

ফলো-আপ: “RED আর USE?” — RED service-এর চোখে, USE resource-এর চোখে।

উত্তর: Burn = ০.০০৩ ÷ ০.০০১ = ৩. ৩০ ÷ ৩ = ১০ দিনে error budget শেষ। ১৪.৪ জাদু নয়: এই গতিতে ১ ঘণ্টায় ৩০ দিনের budget-এর ২% যায় (১৪.৪ × ১ ÷ ৭২০ = ০.০২). Google-এর SRE Workbook এই মানটি সূচনা হিসেবে দেখিয়েছে। আপনার service-এ অন্য মান ঠিক হতে পারে।

উত্তর: লম্বা জানালা বলে ক্ষতিটি অর্থবহ, ছোট জানালা বলে সমস্যা এখনো চলছে। ক্যাপস্টোনে ৫ মিনিটের burn ১৫.৭ হলেও ১ ঘণ্টার burn ছিল ৯.৯, তাই alert চুপ রইল। দুটিই সীমা পেরোলে for: 1m শেষে alert বাজল, apply-র ১ মিনিট ৪৬ সেকেন্ড পরে। ক্ষতি থামার পরে ৫ মিনিটের burn ১২.৪-এ নামতেই থামল, যদিও ১ ঘণ্টার burn তখনো ৪৭.৩.

উত্তর: Probe শুধু তার নিজের পথটুকু দেখে। ক্যাপস্টোনে নতুন বইয়ের rating ফাঁকা ছিল, তাই শূন্য দিয়ে ভাগ, কিন্তু /healthz সেই code ছোঁয়ই না, আর test দেখত শুধু প্রথম বই। বইগুলো পালা করে আসে, তাই প্রতি চারটিতে একটি ভাঙে। Burn হলো ০.২৫ ÷ ০.০০১ = ২৫০.

ধরল burn-rate alert. মোট ৮১১টি ব্যর্থ request, মাসিক budget-এর ১.৫৬%. Alert না থাকলে রাতের ৮ ঘণ্টায় ১,৪৪,০০০টি ভাঙত, budget-এর ২৭৮%.

ফলো-আপ: “কী বদলাবেন?” — প্রতিটি 5xx-এর কারণ log-এ লেখা, canary, আর সব বই ঘোরা test. ওই run-এ docker logs-এ কারণই ছিল না।

উত্তর: Incident commander পুরো ঘটনার মালিক, ops lead আসল পরিবর্তন করেন, comms lead সবাইকে জানান, scribe সময়সহ লেখেন। Commander terminal-এ ডুবে গেলে পুরো ছবি হারিয়ে যায়। ছোট দলে একজন দুই ভূমিকা নিতে পারেন, তবে commander আর ops এক হলে সমস্যা বাড়ে।

ফলো-আপ: “Severity-র কি সর্বজনীন মান আছে?” — না, দলভেদে আলাদা।

উত্তর: ভয় থাকলে তথ্য লুকায়, আর ব্যবস্থা না বদলালে একই ভুল ফেরে। প্রশ্নটি “কে ভুল করল” নয়, “সিস্টেম কেন ভুলটিকে এতদূর আসতে দিল”। ক্যাপস্টোনের ঘটনার পরে নতুন test আগে commit করে দেখা হলো, সে ভুলটি ধরে কি না। ধরল, pipeline_exit=1.

MTTA মানুষের স্বীকার পর্যন্ত, MTTR সেবা ফেরা পর্যন্ত। সংজ্ঞা দলভেদে বদলায়, তাই উল্লেখ করে বলুন। ওই ঘটনায় MTTD ১ মিনিট ৪৬ সেকেন্ড।

উত্তর: Metric বলে কিছু ভুল, আর কখন থেকে। Trace বলে অনুরোধটি কোন span-এ সময় নিল। Log বলে সেই জায়গায় ঠিক কী ঘটল। Exemplar থাকলে metric-এর মান থেকে সরাসরি একটি trace-এ যাওয়া যায়। Percentile মেলাতে histogram লাগে, কারণ bucket যোগ করা যায়।

ফলো-আপ: “Tail sampling কেন?” — শেষে ফল দেখে সিদ্ধান্ত নেয়, তাই ধীর আর ভুল trace রাখা যায়।

উত্তর: নামই মেলেনি, packet রওনাই হয়নি। dig বা getent, namespace-সহ পূর্ণ নাম, আর Kubernetes-এ CoreDNS Pod দেখুন। 502 মানে proxy বেঁচে আছে, পেছনের app সংযোগ নেয়নি বা অচল উত্তর দিয়েছে: proxy-র error log আর ss -tlnp দেখুন। Ingress controller থেকে 503 এলে সেই Service-এর ready Pod আর EndpointSlice দেখুন।

উত্তর: প্রথমে CPU throttling: লক্ষণ হলো latency বাড়ে, log-এ কিছু থাকে না (পর্ব ৪৮). nr_throttled বা container CPU throttle metric দেখুন। তারপর সারি: M/M/1 মডেলে ব্যবহার ০.৮ থেকে ০.৯ হলে গড় সময় দ্বিগুণ হয়। তাই নতুন version একটু বেশি CPU খেলেই latency অনেক বাড়তে পারে। তারপর নির্ভরতা: trace দেখুন কোন span বড় হয়েছে। সাথে নতুন কোডে N+1 query, ঠান্ডা cache আর কম connection.

সব ক্ষেত্রে আগের version-এ ফেরার পথ খোলা রাখুন, আর canary-তে old-new তুলনা করুন।

ফলো-আপ: “CPU limit তুলে দিলেই হবে?” — আগে মেপে দেখুন। অন্ধভাবে তুললে অন্যদের ক্ষতি হতে পারে।

উত্তর: Image নামছে, app চলছে, কিন্তু readiness পাস করছে না, তাই নতুন environment-এ পার্থক্য খুঁজুন। ক্যাপস্টোনের আসল run-এ ঠিক এটি হয়েছিল। Log বলল:

catalog cache failed: [Errno 30] Read-only file system: '/tmp/boighor-catalog.json'

ল্যাপটপের container-এ /tmp লেখা যায়, cluster-এ আমরাই read-only root filesystem দিয়েছিলাম। Terraform দিল Error: Deployment exceeded its progress deadline, আর max_unavailable = 0 পুরোনো Pod রেখে দিল, ট্রাফিকে ০টি ভুল। আগের SHA দিতেই ১ সেকেন্ডে rollback, কারণ পুরোনো Pod সরেইনি।

ফলো-আপ: “প্রতিরোধ?” — Smoke test-এ --read-only, আর Pod-এ emptyDir-এ লেখার জায়গা। RESTARTS 1 এসেছিল একই /healthz liveness-এও থাকায়।

উত্তর: এই নকশায় চেকারটি কোনো finding দেয়নি (নিজে পেস্ট করে দেখুন), তবে এটি চালিয়ে build করা হয়নি। Package আর version আপনার app অনুযায়ী বদলাবে।

FROM python:3.12-alpine AS deps
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt

FROM python:3.12-alpine
WORKDIR /app
COPY --from=deps /install /usr/local
COPY app.py .
USER 10001:10001
EXPOSE 8000
CMD ["python", "app.py"]

Version pin করা। requirements.txt আগে, তাই source বদলালে install আবার চলে না। Secret বাদ: সেটি চালুর সময় secret manager থেকে আসবে। শুধু দরকারি ফাইল COPY, সাথে .dockerignore. Non-root USER. Exec form CMD. curl-এর RUN বাদ, কারণ app-এর দরকার নেই বলে ধরে নিয়েছি: সত্যিই লাগলে একই RUN-এ update আর install.

ফলো-আপ: “এর পরে আরও শক্ত করতে?” — Base image digest-এ বাঁধা, আর চালানোর সময় read-only filesystem.

উত্তর: এই YAML parse করে যাচাই করা, cluster-এ চালানো হয়নি। সংখ্যাগুলো ক্যাপস্টোনের ধরনে, আপনার app মেপে ঠিক করবেন। /ready আর /healthz app-এ থাকতে হবে।

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
spec:
  replicas: 3
  selector:
    matchLabels:
      app: orders
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: orders
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: orders
          image: registry.example.com/orders:1a2b3c4d5e6f
          env:
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: orders-db
                  key: password
          ports:
            - name: http
              containerPort: 8080
          readinessProbe:
            httpGet:
              path: /ready
              port: http
          livenessProbe:
            httpGet:
              path: /healthz
              port: http
          resources:
            requests: {cpu: 20m, memory: 32Mi}
            limits: {cpu: 200m, memory: 64Mi}
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: [ALL]

Label মেলানো। Tag হলো commit SHA. Secret আলাদা object থেকে। Liveness শুধু process-এর নিজের অবস্থা দেখে, ডেটাবেস নয়, আর port এখন নাম ধরে। Readiness আলাদা। Request দিলে scheduler হিসাব করতে পারে। Non-root আর read-only. তিনটি replica আর maxUnavailable: 0.

ফলো-আপ: “Read-only হলে app /tmp-এ লিখবে কোথায়?” — emptyDir volume mount করে দিন। ক্যাপস্টোনের প্রথম খারাপ release ঠিক এখানেই ভেঙেছিল।

উত্তর: যা চালিয়ে দেখানো যায় তা আগে: চলমান পথ, test, পরিষ্কার README. চকচকে জিনিস পরে। পাঁচ টুলের অর্ধেক কাজের চেয়ে দুই টুলের পূর্ণ কাজ ভালো। যা বাদ দিলেন তা লিখে রাখুন, সাথে “সময় পেলে কীভাবে করতাম”।

উত্তর: কাল্পনিক উদাহরণ। S: “একটি শিক্ষানবিশ পদে আমাদের ছোট অ্যাপের config আমি বদলেছিলাম।” T: “Connection সংখ্যা কমানোর দায়িত্ব ছিল আমার।” A: “আমি ৫০ থেকে ৫ করলাম, পরীক্ষা না করে। Error বাড়তেই নিজে জানালাম, আগের মানে ফেরালাম, তারপর log থেকে কারণ বের করলাম।” R: “মিনিট দশেকের মধ্যে সেবা ফিরল। আমি config-বদলের জন্য review আর একটি alert যোগ করলাম।”

লক্ষ করুন: দোষ অন্যের ঘাড়ে নেই, নিজের কাজ স্পষ্ট, শেষে ব্যবস্থার বদল।

উত্তর: কাল্পনিক উদাহরণ। S: “একজন সহকর্মী সব deploy blue-green করতে চাইলেন, আমি চাইলাম canary.” T: “দলকে একটি সিদ্ধান্তে আসতে হবে।” A: “আমরা দুটিরই ঝুঁকি, খরচ আর দুই version-এর সামঞ্জস্য লিখলাম, আর ঠিক করলাম কোন মাপে সিদ্ধান্ত হবে।” R: “কম ট্রাফিকের service-এ canary-র নমুনা যথেষ্ট ছিল না, তাই সেখানে তাঁর পথই বেছে নিলাম।”

এখানে শক্তি হলো নিজের মত বদলানোর ক্ষমতা।

উত্তর: Runbook খুলব, প্রভাব মাপব, আর দেরি না করে সাহায্য ডাকব। একা ঘণ্টাখানেক লড়াই করা বীরত্ব নয়। সময়সহ নোট রাখব, আর প্রভাব বড় হলে rollback-কে প্রথম বিকল্প ধরব। পরদিন runbook-এ ফাঁক থাকলে তা পূরণ করব।