Cloud ইন্টারভিউ — ধারণা, architecture আর পরিস্থিতিভিত্তিক সমস্যা

শক্তিশালী উত্তর: আগে বাদ, পরে বাছাই। প্রথমে শর্ত দিয়ে ছাঁকি: run time কত, GPU লাগবে কি না, OS-এ বিশেষ কিছু, state আছে কি না, দলের দক্ষতা কত। যা টিকে থাকে, তার মধ্যে সবচেয়ে হালকা বিকল্প নিই, কারণ ওপরের স্তরে আমার কাজ কম। সাধারণ API-তে PaaS বা container service দিয়ে শুরু করতাম। ট্রাফিক খুব কম আর ফাঁকে ফাঁকে হলে FaaS সস্তা হতে পারে। স্থির উঁচু load-এ VM বা container সস্তা হতে পারে।

দুর্বল উত্তর দেখতে যেমন: “Kubernetes, কারণ সবাই ব্যবহার করে।” Kubernetes একটি বিনিয়োগ, মান নির্ধারক নয়।

ফলো-আপ:

• “FaaS থেকে VM কখন সস্তা?” → Crossover = স্থির মাসিক বিল ÷ প্রতি request-এর পুরো দাম। Gateway, log আর মানুষের সময়ও ধরতে হবে।

শক্তিশালী উত্তর: Vertical scaling মানে একই machine বড় করা। Horizontal মানে machine-এর সংখ্যা বাড়ানো। Vertical সহজ, কোড বদলায় না, কিন্তু সীমা আছে, আর সাধারণত restart লাগে। Horizontal-এ সীমা অনেক দূরে, এক machine পড়লেও সেবা চলে, কিন্তু app-কে stateless হতে হয়। তাই app স্তরে horizontal, আর database-এ আগে vertical ও read replica, এটিই সাধারণ পথ।

দুর্বল উত্তর দেখতে যেমন: “Horizontal সবসময় ভালো।” Database-এ লেখা ভাগ করা অনেক কঠিন কাজ।

শক্তিশালী উত্তর: Target tracking-এর সূত্র: desired = ⌈current × metric ÷ target⌉, তারপর min আর max-এ আটকানো। এখানে ৬ × ১৫০ ÷ ৬০ = ১৫। সমস্যা হলো CPU ১০০%-এ আটকে যায়, তাই আসল চাপ লুকায়, আর কয়েক দফা লাগে। তাই I/O-নির্ভর app-এ requests per target বা queue depth ভালো signal.

ফলো-আপ:

• “Cooldown আর warm-up?” → Cooldown দুই সিদ্ধান্তের বিরতি; warm-up নতুন instance তৈরি হওয়ার সময়।
• “হঠাৎ ভিড়ে autoscaling কেন হারে?” → Boot-এর দেরিতে অনুরোধ হারায়। জানা ভিড়ে scheduled scaling আর target-এ headroom রাখি।

শক্তিশালী উত্তর: Group সম্ভবত শুধু instance-এর health check শুনছে। VM চলছে, তাই সে সুস্থ বলে ধরছে। App সাড়া দিচ্ছে কি না, তা জানে load balancer. সমাধান: group-কে load balancer-এর health check শোনানো, আর grace period ঠিক রাখা, যাতে boot-এর সময়েই instance বাদ না পড়ে।

শক্তিশালী উত্তর: থামলে আবার চালানো যায়, ভাগ করা যায়, আর সময়ে ছাড় আছে এমন কাজে: batch, CI, render, stateless worker. Checkpoint রাখি আর একাধিক pool ব্যবহার করি। ৭০%-এর মতো বাঁচতে পারে, তবে হার provider-ভেদে আলাদা। রাখব না stateful কাজ, ডেটার একমাত্র copy, আর থামানো যায় না এমন কাজ।

দুর্বল উত্তর দেখতে যেমন: “Database-এও spot, ৭০% বাঁচবে।” একটি reclaim-এ সেবা আর ডেটা দুটোই ঝুঁকিতে।

শক্তিশালী উত্তর: Cold start হলো নতুন environment-এর init-এর দেরি। কম ট্রাফিকে এটি স্বাভাবিক। Package আর init ছোট করে, snapshot বা provisioned concurrency দিয়ে কমানো যায়। Concurrency = rate × duration = ২০০ × ০.৫ = ১০০। Database ধীর হলে duration বাড়ে, তাই concurrency-ও বাড়ে, আর সীমা আগে সেখানেই কামড়ায়।

ফলো-আপ:

• “Reserved আর provisioned concurrency?” → Reserved জায়গা ও ছাদ, আগে থেকে কিছু চালু রাখে না। Provisioned আগে init করে রাখা, যার বিল অলসেও চলে।

শক্তিশালী উত্তর: L4 IP আর port দেখে দ্রুত সংযোগ ভাগ করে; HTTP পড়ে না। L7 HTTP পড়ে, তাই path বা host দেখে rule চালাতে পারে, TLS শেষ করতে পারে। ওয়েব app-এ সাধারণত L7, আর অ-HTTP বা খুব বেশি সংযোগের কাজে L4.

ফলো-আপ:

• “Target unhealthy হতে কত সময়?” → সর্বোচ্চ প্রায় U × I + T, যেমন ২ × ১০ + ৫ = ২৫ সেকেন্ড।

শক্তিশালী উত্তর: Stateless instance যেকোনো সময় বদলানো যায়, তাই autoscaling, rolling deploy আর AZ হারানো সহজ হয়। Session থাকবে বাইরের store-এ, যেমন Redis বা database-এ, আর ফাইল থাকবে object storage-এ। Sticky session সাময়িক সমাধান: instance পড়লে সেই session হারায়, আর ভার অসমান হয়।

শক্তিশালী উত্তর: ঠিকানা আর ভাগ করার ধরনে। Block: block নম্বর, সাধারণত এক VM-এর disk, database-এ ভালো। File: path, অনেক VM একই ফোল্ডার দেখে। Object: key, HTTP-তে পুরো জিনিস, ছবি, backup, log-এ ভালো। সন্দেহ হলে object দিয়ে শুরু করি।

ফলো-আপ:

• “Object storage-এ database নয় কেন?” → অংশবিশেষ বদলানো যায় না, latency বেশি, আর প্রতি অনুরোধে দাম লাগে।

শক্তিশালী উত্তর: না। Durability মানে ডেটা টিকে থাকা; availability মানে এখন পাওয়া। Bucket সাময়িক বন্ধ থাকলেও ডেটা হারায় না। এগারো nine একটি নকশা-লক্ষ্য: ১ কোটি object-এ গড়ে ১০,০০০ বছরে একটি হারানো। এটি ভুল করে মোছার বিমা নয়।

শক্তিশালী উত্তর: ৩,০০০ × ১৬ KB = ৪৮ MB/s, যদি volume-এর MB/s সীমা তার বেশি হয়। সবচেয়ে ছোট সীমাই আসল সীমা। তাই volume-এর IOPS, volume-এর MB/s, VM-এর নিজের সীমা আর queue depth, চারটিই দেখি।

শক্তিশালী উত্তর: Version ID ছাড়া DELETE দিলে delete marker বসে, ডেটা থাকে। Version ID দিলে সেই version স্থায়ীভাবে মোছে। বিল না কমার সাধারণ কারণ: noncurrent version জমছে, অসমাপ্ত multipart পড়ে আছে, অথবা ছোট object সরানোর ফি বেশি।

শক্তিশালী উত্তর: অ্যাপ ক্রেতার অনুমতি যাচাই করে ছোট মেয়াদের presigned URL বানায়। ফাইল সরাসরি storage থেকে যায়, server-এর memory আর network বাঁচে। URL কোনো ব্যবহারকারীর সাথে বাঁধা নয়: যাঁর হাতে থাকে, তিনিই মেয়াদ পর্যন্ত কাজটি করতে পারেন। তাই মেয়াদ ছোট, আর URL log-এ লিখি না।

দুর্বল উত্তর দেখতে যেমন: “Bucket public করে দিই, URL তো কেউ জানে না।” এটি নিরাপত্তা নয়।

শক্তিশালী উত্তর: RPO মাপে কত ডেটা হারানো চলে, পেছনের দিকে। RTO মাপে কত সময় বন্ধ থাকা চলে, সামনের দিকে। Backup লাগে: replica হার্ডওয়্যার হারানো সামলায়, কিন্তু ভুল DELETE আর ransomware-ও কপি করে। ভুল থেকে ফেরায় PITR আর পরীক্ষিত restore.

ফলো-আপ:

• “ঘণ্টায় backup, পৌঁছাতে ১০ মিনিট; সবচেয়ে খারাপ RPO?” → ৬০ + ১০ = ৭০ মিনিট।

শক্তিশালী উত্তর: Standby availability-র জন্য, সাধারণত synchronous, আর query নেয় না। Read replica read scaling-এর জন্য, সাধারণত asynchronous, তাই stale read হতে পারে। একটি অন্যটির বিকল্প নয়।

ফলো-আপ:

• “লেখার পরেই নিজের লেখা দেখাবেন কীভাবে?” → Read-your-writes: লেখার পর নিজের পড়া primary-তে, অথবা replica-র LSN মিলিয়ে পড়া।

শক্তিশালী উত্তর: গুনি: ৪০ × ২০ = ৮০০, সীমার ওপরে। সবচেয়ে বড় নিরাপদ pool = ৪৮০ ÷ ৪০ = ১২। Surge-এর সময়ের instance-ও ধরি। তারপর database proxy ভাবি: অনেক client connection অল্প server connection-এ মেলে। সীমা বাড়ানো শেষ উপায়, কারণ প্রতিটি connection memory খায়।

দুর্বল উত্তর দেখতে যেমন: “max_connections ১০ গুণ করে দিই।” সমস্যাটি মেটে না, শুধু database-এর memory-তে সরে যায়।

শক্তিশালী উত্তর: এক-দুই মিনিটের ফাঁক ধরে নিই। App-এর দায়: ছোট timeout, jitter-সহ backoff, DNS TTL মানা, মরা connection বাতিল, আর লেখায় idempotency key, যাতে retry-তে দুটি অর্ডার না হয়। Retry-র সীমা না থাকলে ফিরে আসা database আবার ডুবে যায় (retry storm).

ফলো-আপ:

• “Primary ফিরে এসে লেখা নিলে?” → Split-brain; তাই fencing.

শক্তিশালী উত্তর: শুরু হয় query shape থেকে, জনপ্রিয়তা থেকে নয়। অনিশ্চিত join আর transaction হলে relational. জানা key দিয়ে বিপুল পড়া-লেখা হলে key-value বা document. NoSQL-এ আগে access pattern, পরে key, কারণ সীমা বসে partition-এ, মোট table-এ নয়। প্রতিটি নতুন store নতুন operational burden, তাই কম store দিয়ে শুরু করি।

ফলো-আপ:

• “মোট capacity থাকার পরও throttle কেন?” → Hot partition: ভার এক partition-এ জমেছে।

শক্তিশালী উত্তর: DB-র ভার = (১ − h) × মোট। Miss ১০% থেকে ৩০%, অর্থাৎ ভার ৩ গুণ। তাই hit ratio নয়, miss দিয়ে ভাবি। Cache পড়লে কী হবে, সেই হিসাব আগে রাখি: cold cache-এ শুরুতে সবই miss, আর cache stampede-এ একই key-এর জন্য সবাই database-এ ছোটে।

শক্তিশালী উত্তর: Region একটি ভৌগোলিক এলাকা; AZ তার ভেতরের বিচ্ছিন্ন অংশ। Multi-AZ এক region-এ, কাছাকাছি, তাই সাধারণত synchronous. Multi-region দূরে, সাধারণত asynchronous, তাই RPO শূন্যের বেশি হতে পারে। আগে multi-AZ, তারপর হিসাব করে অন্য region.

দুর্বল উত্তর দেখতে যেমন: “দুটিই করে দিই, বেশি নিরাপদ।” লক্ষ্য না জেনে খরচ আর জটিলতা বাড়ে, আর খারাপ deploy দুই জায়গাতেই পৌঁছাতে পারে।

শক্তিশালী উত্তর: Route table-এ internet gateway-এর route. অন্য কোনো সুইচ নেই। Instance-এর ইন্টারনেট পেতে public IP-ও লাগে। NAT-এর route থাকলে private, কোনো পথ না থাকলে isolated.

দুর্বল উত্তর দেখতে যেমন: “Subnet তৈরির সময় public টিক দিলে।” টিকটি সাধারণত শুধু auto-assign IP-র, আসল পরিচয় route.

শক্তিশালী উত্তর: IGW 1:1 অনুবাদ করে, দুই দিক থেকেই সংযোগ শুরু হতে পারে। NAT অনেকে-থেকে-একে অনুবাদ করে, সংযোগ শুরু হয় শুধু ভেতর থেকে। AWS-ধরনের নকশায় NAT public subnet-এ বসে, কারণ তার নিজের ইন্টারনেট পথ লাগে। প্রতি AZ-এ একটি রাখি, যাতে এক AZ পড়লে অন্যরা না আটকায়।

ফলো-আপ:

• “NAT-এর বিল কমাবেন কীভাবে?” → Flow log দেখে বড় গন্তব্য খুঁজি; একই region-এর storage-এ endpoint দিই।

শক্তিশালী উত্তর: Security group interface-এ বসে, stateful, শুধু allow. NACL subnet-এ বসে, stateless, ছোট নম্বর আগে, allow ও deny দুটোই। AWS-ধরনে security group-এ deny নেই, তাই একটি IP আটকাতে NACL-এ ছোট নম্বরের deny বা WAF.

ফলো-আপ:

• “Inbound 443 খোলা, তবু timeout?” → NACL-এ ephemeral port-এর outbound নিয়ম আছে কি না দেখি। Route আর host firewall-ও।
• “Autoscaling-এ DB-র নিয়ম কী হবে?” → উৎস app-এর security group, IP নয়।

শক্তিশালী উত্তর: Timeout মানে packet পথে হারাচ্ছে বা উত্তর ফিরছে না, প্রায়ই firewall বা route. Refused মানে server পর্যন্ত পৌঁছেছি, কিন্তু সেই port-এ কেউ শুনছে না। এই একটি শব্দ দেখেই খোঁজার দিক বদলে যায়।

শক্তিশালী উত্তর: /24 দিয়ে, কারণ longest-prefix match: একাধিক route মিললে সবচেয়ে লম্বা prefix জেতে, লেখার ক্রম নয়। এজন্যই পরে endpoint যোগ করলে পুরোনো NAT route না মুছেও storage-এর traffic সরে আসে।

শক্তিশালী উত্তর: Peering transitive নয়, তাই সব জোড়া লাগলে full mesh: ৮ × ৭ ÷ ২ = ২৮টি link. Transit hub-এ ৮টি attachment, তবে ঘণ্টা আর GB-র বিল আছে। অল্প VPC আর বেশি traffic হলে peering, অনেক VPC হলে hub. CIDR মিললে route ঠিক করা যায় না। সমাধান: ঠিকানা নতুন করে সাজানো, অথবা শুধু একটি service খোলার জন্য PrivateLink ধরনের পথ।

শক্তিশালী উত্তর: সবচেয়ে খারাপ সময় I × F + TTL: check-এর ব্যবধান × ব্যর্থতার সংখ্যা + TTL. ৩০ × ৩ + ৬০ = ১৫০ সেকেন্ড, app-এর নিজের cache ছাড়া। Propagation মানে resolver-এর cache-এর মেয়াদ শেষ হওয়া। Cutover-এর অন্তত এক পুরোনো TTL আগে TTL কমাই। খুব ছোট TTL রাখলে query আর বিল বাড়ে।

শক্তিশালী উত্তর: CDN ব্যবহারকারীর কাছে content রাখে, origin-এর ভার কমায়। WAF অনুরোধ পড়ে ক্ষতিকর নমুনা আটকায়। Load balancer সুস্থ target-এ অনুরোধ ভাগ করে। Edge-এ যত আগে অনুরোধ শেষ হয়, তত ভালো। Origin-এর ভার = মোট × (১ − h).

ফলো-আপ:

• “নতুন WAF rule কীভাবে ছাড়বেন?” → Count mode-এ বসিয়ে log পড়া, সরু ছাড়, তারপর block আর alert.

শক্তিশালী উত্তর: Authentication: আপনি কে। Authorization: আপনি কী পারেন। HTTP-তে 401 আর 403 এই দুটির সাথে মেলে। প্রতিটি অনুরোধ principal, action, resource আর condition দিয়ে বিচার হয়, আর ডিফল্ট উত্তর deny.

শক্তিশালী উত্তর: Role. Instance role-এ স্থায়ী secret নেই, credential নিজে থেকে মরে, audit log-এ session আলাদা থাকে। Kubernetes-এ workload identity, CI-তে OIDC. মানুষের জন্য SSO, group আর শক্ত MFA.

দুর্বল উত্তর দেখতে যেমন: “Key-টি environment variable-এ রাখব।” এটি শুধু স্থায়ী key-র জায়গা বদলানো।

শক্তিশালী উত্তর: Explicit Deny জেতে, statement-এর ক্রম যাই হোক। Implicit deny মানে কোনো Allow নেই; Allow যোগ করলে উঠে যায়। Explicit Deny কোনো Allow ওলটাতে পারে না। কার্যকর অনুমতি স্তরগুলোর ছেদ: identity, boundary, session আর guardrail.

ফলো-আপ:

• “SCP কি অনুমতি দেয়?” → না, সর্বোচ্চ সীমা টানে।

শক্তিশালী উত্তর: Trust policy বলে কে role পরতে পারবে; permission policy বলে পরে কী করতে পারবে। Cross-account-এ দুই পক্ষের Allow চাই: caller-এর identity policy আর resource বা role-এর দিকের policy. Same-account-এ সাধারণত এক পক্ষই যথেষ্ট।

ফলো-আপ:

• “External ID কী ঠেকায়?” → Confused deputy: তৃতীয় পক্ষ যেন অন্য গ্রাহকের কথায় আপনার role না পরে।

শক্তিশালী উত্তর: Least privilege একটি চক্র: ছোট শুরু, audit log, lint, simulator, তারপর ধাপে ধাপে বাদ। Dev-এ চওড়া sandbox আর guardrail, prod-এ সরু role. ৯০ দিনের log দেখে অব্যবহৃত অনুমতি বাদ দিই, তবে বছরে একবারের কাজের কথা মালিককে জিজ্ঞেস করি, কারণ log শুধু বলে কী ঘটেছে। জরুরি প্রবেশের জন্য break-glass রাখি।

দুর্বল উত্তর দেখতে যেমন: “Access denied এলে * দিয়ে দিই, পরে সরাব।” পরে আর সরে না।

ফলো-আপ:

• “Wildcard-এর ঝুঁকি?” → Provider নতুন action আনলে s3:Get* নিজে থেকেই বড় হয়, policy কেউ না ছুঁলেও।

শক্তিশালী উত্তর: Provider সামলায় security of the cloud: হার্ডওয়্যার, hypervisor. গ্রাহক সামলান security in the cloud. IaaS-এ guest OS patch গ্রাহকের। ওপরের model-এ কাজ কমে, কিন্তু identity, ডেটা, backup আর নিজের সেটিং সব model-এ আপনার।

শক্তিশালী উত্তর: হ্যাঁ। অনুমতি থাকলে সেবা নিজেই ডেটা খুলে দেয়। Encryption at rest চুরি যাওয়া disk থেকে বাঁচায়, ভুল অনুমতি থেকে নয়। এনক্রিপশন অনুমতির বিকল্প নয়।

ফলো-আপ:

• “Envelope encryption কেন?” → বড় ডেটা KMS-এ না পাঠিয়ে দ্রুত encrypt করা। Data key ডেটা লক করে, KEK data key লক করে।

শক্তিশালী উত্তর: কোড, image, log বা user data-তে নয়। Secret manager-এ, আর app পড়বে নিজের পরিচয় দিয়ে। বদলাতে দুটি version একসাথে বৈধ রাখি, overlap ≥ TTL + rollout. ফাঁস হলে আগে বাতিল, তারপর তদন্ত, শেষে history.

শক্তিশালী উত্তর: হাতছাড়া হওয়া account থেকে প্রমাণ মোছা আটকাতে। সব region থেকে আলাদা, সুরক্ষিত account-এ পাঠাই। CSPM ভুল সেটিং খোঁজে; threat detection চলমান সন্দেহজনক আচরণ দেখে। Finding কারও কাছে না পৌঁছালে মূল্যহীন, তাই মালিক আর alert লাগে।

ফলো-আপ:

• “Data event কি নিজে থেকে থাকে?” → সাধারণত না, আলাদা করে চালু করতে হয়, খরচও আছে।

শক্তিশালী উত্তর: মুছে ফেলা নয়। Traffic থেকে সরানো, network বিচ্ছিন্ন করা, credential বাতিল আর প্রমাণ রাখা। আলাদা করুন, প্রমাণ রাখুন, credential বদলান, নতুন করে বানান। পুরোনো server ফেরানো নয়, IaC আর golden image থেকে বানানো, কারণ অনুপ্রবেশের পথটিও ফিরে আসতে পারে। Incident-এ সাধারণত আগে rollback, কিন্তু নিরাপত্তার ঘটনায় প্রমাণ আগে ভাবতে হয়।

দুর্বল উত্তর দেখতে যেমন: “VM terminate করে নতুন চালাই।” প্রমাণ গেল, কীভাবে ঢুকল তা অজানা রইল।

শক্তিশালী উত্তর: CapEx আগাম সম্পদ কেনা, OpEx চলতি বিল। TCO সব সারির যোগ: বিদ্যুৎ, staff, বাড়তি ক্ষমতা, transfer, support আর অলস resource. স্থির, উঁচু, দীর্ঘ load আর সক্ষম দল থাকলে নিজের হার্ডওয়্যার সস্তা হতে পারে। ওঠানামার load-এ elasticity জেতে। Peak ২০, গড় ৫ হলে কেনা ক্ষমতার utilisation ২৫%.

শক্তিশালী উত্তর: Break-even utilisation = ১ − ছাড় = ৬০%. সময়ের ৬০%-এর বেশি চললে লাভ। তাই অঙ্গীকার নিই baseline-এর মাপে, peak-এর মাপে নয়; ওপরের অংশ on-demand, আর থামানো যায় এমন কাজ spot. আগে rightsizing, পরে অঙ্গীকার।

ফলো-আপ:

• “Coverage ১০০% কেন ভালো নয়?” → বাড়তি অংশ (১ − ছাড়)-এর কম সময় চললে লোকসান।

শক্তিশালী উত্তর: বিল = ব্যবহার × দর। আগে ব্যবহার: অলস resource মুছি, rightsize করি, dev রাতে বন্ধ রাখি। তারপর দর: commitment আর spot. CPU ও memory দুটোই দেখি, আর rollback-এর শর্ত আগে লিখি। নিরাপত্তার সারি কাটি না: backup, log, multi-AZ. শেষে unit cost দেখি, কারণ ব্যবসা বাড়লে বিল বাড়া খারাপ নয়।

দুর্বল উত্তর দেখতে যেমন: “সব VM-এ ৩ বছরের অঙ্গীকার।” অপচয়টিকেই তিন বছরের জন্য বেঁধে ফেলা।

শক্তিশালী উত্তর: Egress, zone পার, region পার, আর NAT-এর প্রতি GB. উদাহরণ, অনুমিত দরে: ২টি NAT, ঘণ্টায় $০.০৫ করে ৭২০ ঘণ্টা = $৭২। ১২,০০০ GB × $০.০৫ = $৬০০। Bucket-এর traffic endpoint-এ নিলে processing অনেক কমে। “টাকা বাঁচাতে” এক NAT রাখলে উল্টো ফল হতে পারে, কারণ অর্ধেক traffic AZ পার হয়।

শক্তিশালী উত্তর: ৯৯.৯৫% মানে মাসে ২১.৬ মিনিট। একক AZ-এ হিসাবটি মেলে না, ২৬৭.৬ মিনিট। তাই তিন AZ, সামনে load balancer আর CDN, private subnet-এ autoscaling-সহ stateless app, data subnet-এ standby-সহ managed database. Session Redis-এ, ফাইল object storage-এ। Copy স্বাধীন হলে ৮.৭ মিনিট, আর correlated failure ধরলে ১১.৩-এর মতো। তাই ধীর rollout, rollback, PITR আর multi-AZ ছাড়াও ভুল-deploy ঠেকানোর ব্যবস্থা। অনুমিত দরে মাসে প্রায় $১,০৬৬। Multi-region এই লক্ষ্যে দরকার নয়, যদি না region-ব্যর্থতাকে লক্ষ্যের মধ্যে ধরা হয়।

দুর্বল উত্তর দেখতে যেমন: “Multi-AZ দিলেই ৯৯.৯৯%.” Copy বাড়লেই availability বাড়ে না: correlated failure b × u কমে না।

ফলো-আপ:

• “Database-এর standby কেন read-এ ব্যবহার করবেন না?” → Standby সাধারণত query নেয় না। Read বাড়াতে আলাদা replica.

শক্তিশালী উত্তর: অনুমান বলে শুরু: তিন AZ, তিন স্তর, অফিসের সাথে VPN, আর ভবিষ্যতে Kubernetes. CIDR বাছি এমনভাবে যাতে অফিস বা অন্য VPC-র সাথে না মেলে। Public-এ LB আর AZ-পিছু NAT, private-এ app, data-তে database, যার route-এ ইন্টারনেট নেই। Security group chain: LB-তে 443, app-এ উৎস sg-lb, DB-তে উৎস sg-app. Admin-এর জন্য session manager, inbound SSH নয়। Storage-এ endpoint, flow log চালু, পুরো জিনিস IaC-তে।

দুর্বল উত্তর দেখতে যেমন: “সব কিছু একটি public subnet-এ, firewall দিয়ে আটকে দেব।” একটি ভুল নিয়মেই database ইন্টারনেটে।

ফলো-আপ:

• “NAT কি তিনটিই লাগবে?” → খরচ বনাম AZ-স্বাধীনতা। একটি NAT-এ সেই AZ পড়লে সব private subnet-এর বাইরের পথ যায়, আর zone-পার বিলও বাড়ে।
• “Database subnet-এ NAT নেই, patch কীভাবে?” → Managed হলে provider করে। নিজের হলে ভেতরের mirror বা endpoint.

শক্তিশালী উত্তর: ⌈৫০০ × ১.৩⌉ = ৬৫০, সাথে ৫টি কাটা ঠিকানা = ৬৫৫। ২⁹ = ৫১২ কম, ২¹⁰ = ১,০২৪ যথেষ্ট, তাই /22. AWS আর Azure-এ ৫টি কাটা, Google-এ ৪টি; docs-এ মিলিয়ে নিন। Pod যদি subnet থেকে ঠিকানা পায়, তবে সংখ্যাটি অনেক বড় হবে।

শক্তিশালী উত্তর: আগে লক্ষ্য জিজ্ঞেস করি, কারণ উত্তর RTO আর RPO-র ওপর দাঁড়িয়ে। সব সেবার লক্ষ্য এক নয়: অর্ডারের ডেটা আর পুরোনো report আলাদা স্তরে। ধরি RTO ১ ঘণ্টা, RPO ২ মিনিট। তাহলে pilot light: অন্য region-এ চালু database replica, app বন্ধ, IaC আর image প্রস্তুত, quota আগে থেকে বাড়ানো। চার ধাপের সিঁড়ির সবচেয়ে সস্তা যে ধাপ লক্ষ্য মেটায়, সেটিই নিই।

ঘটনার দিনে ক্রম: বাইরে থেকে চালানো health check-এ ধরা, disaster ঘোষণা, fencing, replica promote, database বড় করা, VM চালু, smoke test, তারপর DNS. প্রতি ত্রৈমাসিকে game day করি, না হলে পরিকল্পনাটি শুধু কাগজ। Failback-এর পরিকল্পনাও লিখি।

দুর্বল উত্তর দেখতে যেমন: “Active-active করে দেব, সমস্যা শেষ।” লক্ষ্য না জেনে সবচেয়ে দামি ধাপ, আর দুই region-এ একসাথে লেখার সমস্যার উত্তর নেই।

ফলো-আপ:

• “Alert ব্যবস্থা নিজেই ওই region-এ থাকলে?” → তাই monitoring নষ্ট region-এর বাইরে রাখি।
• “Region হয়তো দুই মিনিটে ফিরবে, ঘোষণা কখন?” → Runbook-এ আগে লেখা নিয়ম আর দায়িত্বপ্রাপ্ত মানুষ।
• “অন্য region-এ VM না পেলে?” → Quota অনুমতি, capacity আলাদা। এই ঝুঁকিই warm standby-র পক্ষে যুক্তি।

শক্তিশালী উত্তর: আগে আকার, change rate আর লক্ষ্য জিজ্ঞেস করি। ক্রম: TTL আগে কমানো → snapshot দিয়ে initial load → CDC দিয়ে পরিবর্তন ধরা → মহড়া → go বা no-go → source read-only → বাকি শূন্য, সারি আর checksum মেলানো → sequence এগিয়ে নেওয়া → reverse replication → দিক বদল। এতে কোর্সের উদাহরণে লেখা-বিরতি ৩ মিনিট, আর পড়া একবারও থামেনি। ফেরার শর্ত আগে লিখি: যেমন error টানা ৫ মিনিট ২%-এর ওপরে।

দুর্বল উত্তর দেখতে যেমন: “Weekend-এ dump নিয়ে restore করব।” কয়েক ঘণ্টার downtime, আর ফেরার পথ নেই।

ফলো-আপ:

• “Sequence কেন আলাদা?” → Logical replication এটি আনে না; না এগোলে নতুন সারিতে id-সংঘর্ষ।
• “Reverse replication কেন?” → Rollback-এ cutover-এর পরের অর্ডার না হারাতে।
• “App আর DB আলাদা wave-এ সরালে?” → Chatty হলে প্রতি query-তে RTT যোগ হয়। ১২০ query × ৪১ ms-এ পাতা ৫ সেকেন্ড ছাড়ায়। তাই একই move group.

শক্তিশালী উত্তর: আগে মাপ: কোন পথ, কত ঘণ্টা। তারপর প্রতি স্তর ধরে হিসাব, কারণ autoscaling শুধু app সামলায়। App: ৪ থেকে ৩৪, আর AZ হারানো ধরলে ৫১। Quota আর capacity আগেই। Database: connection ১,০২০ হয়ে যায়, তাই pool ছোট বা proxy; read ভার cache আর CDN-এ, লেখা queue-তে যেখানে সম্ভব। Boot দেরির জন্য sale-এর আগেই scheduled scaling. ধাপে ধাপে load test. সেদিন kill switch, waiting room, deploy বন্ধ, on-call বেশি। পরে min নামানো আর unit cost.

দুর্বল উত্তর দেখতে যেমন: “Autoscaling চালু আছে, সমস্যা নেই।” Database, quota আর boot-এর দেরি তিনটিই বাদ।

ফলো-আপ:

• “Payment gateway সীমা দিলে?” → Queue আর rate limit; অর্ডার নিয়ে পরে নিশ্চিত করা, idempotency key-সহ।
• “Serverless হলে সমস্যা শেষ?” → না। Concurrency-র সীমা আর downstream আগে পড়ে।

শক্তিশালী উত্তর: আগে কারণ জিজ্ঞেস করি। Multi-cloud যুক্তিসঙ্গত যদি লিখিত শর্ত, পণ্যের প্রয়োজন, acquisition থাকে, অথবা হিসাবে ক্ষতি খরচকে ছাড়ায়। নইলে খরচ বাড়ে: কোর্সের অনুমিত হিসাবে বছরে মোট খরচ multi-AZ-এ $১,৮৮,৭৬০ আর multi-cloud-এ $৪,৬৭,২৫৭, অথচ availability ৯৯.৯৮% থেকে মাত্র ৯৯.৯৮৮%. Lock-in-এর স্তর ডেটা, API আর দক্ষতা। Container, খোলা format, পাতলা adapter আর পরীক্ষিত exit plan দিয়ে কমাই; সব কিছুতে abstraction নয়।

শক্তিশালী উত্তর: Packet-এর পথ ধরে এগোই। “Timed out” না “refused”, আগে পড়ি। dig দিয়ে DNS বাদ দিই। OS-এ default route দেখি। তারপর cloud-এর দিকে: security group আর NACL, subnet কোন route table-এ যুক্ত, সেখানে 0.0.0.0/0 কোথায়, NAT চালু কি না, NAT public subnet-এ কি না, তার নিজের table-এ IGW আছে কি না, আর VPC-তে IGW যুক্ত কি না। প্রতি ধাপে একটি জিনিস বাদ দিই। শেষে flow log দিয়ে প্রমাণ, ঠিক করা, যাচাই, আর IaC-তে লেখা।

দুর্বল উত্তর দেখতে যেমন: “NAT gateway restart করব।” কারণ না জেনে বদল, আর NAT-এ এমন কোনো বোতামও সাধারণত নেই।

ফলো-আপ:

• “Storage-এ যেতেই সমস্যা?” → Endpoint-এর route, endpoint policy বা bucket policy দেখি।

শক্তিশালী উত্তর: আগে নিশ্চিত হই, দেখে, না বদলে। তারপর public পথ বন্ধ করি। ডেটা মুছি না, log আর policy-র ইতিহাস রাখি। Access log আর audit log দেখে পরিধি বের করি। ফাইলে credential থাকলে বদলাই। নিরাপত্তা, আইন আর মালিককে জানাই। শেষে প্রতিরোধ: organization-স্তরে block, alert, presigned URL.

দুর্বল উত্তর দেখতে যেমন: “Bucket মুছে দেব।” প্রমাণ গেল, ক্ষতির পরিধি অজানা রইল, আর কোনো app ভাঙতে পারে।

ফলো-আপ:

• “Encrypted ছিল তো?” → তাতে কিছু বদলায় না; অনুমতি থাকলে সেবা খুলে দেয়।

শক্তিশালী উত্তর: আগে নিশ্চিত হই, এটি হাতছাড়া হওয়া account নয়: অচেনা region, অচেনা identity, বড় GPU থাকলে সেটি নিরাপত্তার ঘটনা, আর key বাতিল আগে। না হলে বিল ভেঙে দেখি: service, তারপর line item, তারপর tag ধরে, দিন ধরে। কবে থেকে বাড়ল, সেদিন কী deploy হয়েছিল। তারপর মালিকের সাথে কথা। ঠিক করি, আর শেষে anomaly alert, budget alert, tag আর মাসিক review বসাই। Unit cost দেখি, কারণ ব্যবসা বাড়লেও বিল বাড়ে।

দুর্বল উত্তর দেখতে যেমন: “সবচেয়ে বড় VM বন্ধ করে দিই।” সবচেয়ে বড় সারি হয়তো একটুও বদলায়নি।

ফলো-আপ:

• “Budget alert থাকলে তো থামত?” → না। Budget alert জানায়, থামায় না। আর প্রকৃত খরচের alert দেরিতে বাজে; forecast আগে বাজে।

শক্তিশালী উত্তর: 502: target ভাঙা উত্তর দিয়েছে বা সংযোগ কেটেছে; keep-alive, crash, TLS-এর অমিল দেখি। মাঝেমধ্যে 502 হলে প্রায়ই target-এর keep-alive LB-র idle timeout-এর চেয়ে ছোট। 503: পাঠানোর মতো target নেই, তাই healthy target-এর সংখ্যা। 504: target সময়ের মধ্যে উত্তর দেয়নি বা সংযোগ হয়নি; ধীর query বা firewall. 500 হলে app নিজেই error দিয়েছে।

দুর্বল উত্তর দেখতে যেমন: “Timeout ৩,৬০০ সেকেন্ড করে দেব।” আসল ধীরতা লুকায়।

শক্তিশালী উত্তর: Timeout, তাই পথ। DNS ঠিকানা কোথায় দেখাচ্ছে। Security group-এ port 5432-এর উৎস app-এর group কি না। NACL, route, আর দুটি subnet একই VPC-তে বা জোড়া কি না। Flow log-এ REJECT দেখি। Refused হলে database চলছে কি না, password error হলে পৌঁছেছি, সমস্যা identity-তে।

নিচের নমুনা flow log দেখুন। নিজের তৈরি করা সহজ log, আসল format-এর সব field এখানে নেই।

শক্তিশালী উত্তর: বড় অনুমতি নয়; আগে পড়ি: কে, কোন action, কোন resource, কোন স্তর। সাধারণ কারণ: resource-এর ঠিকানা ভুল (ListBucket bucket-এর ওপর, GetObject object-এর ওপর), condition মেলেনি, ভুল role পরা, guardrail বা boundary-র সীমা, cross-account-এ অন্য পক্ষের Allow নেই, অথবা KMS key-এর অনুমতি নেই। Audit log আর policy simulator দিয়ে যাচাই করি।

শক্তিশালী উত্তর: আগে ক্ষতি: SLO পোড়াচ্ছে কি? পোড়ালে rollback, কারণ আগে ক্ষতি থামানো, পরে কারণ। তারপর তুলনা: p50 না p99, সব route না একটি, সব AZ না একটি। Trace দিয়ে দেখি সময় কোন span-এ গেল। সাধারণ কারণ: নতুন query-তে index নেই, বাড়তি N+1, cache key বদলে cold cache, নতুন dependency, CPU limit-এ throttling. একবারে একটি তত্ত্ব।

Situation: “আমাদের ছোট দলের staging-এ একটি security group বদলেছিলাম। Task: একজন সহকর্মীর জন্য database খোলা দরকার ছিল। Action: আমি নতুন নিয়ম যোগ করার বদলে পুরোনোটি সম্পাদনা করলাম, আর app-এর সংযোগ কেটে গেল। Alert দেখেই দলকে বললাম ভুলটি আমার, আগের নিয়ম ফিরিয়ে দিলাম। পরে নিয়মগুলো Terraform-এ আনলাম, আর ‘আগে যোগ, পরে বাদ’ চেকলিস্টে লিখলাম। Result: staging ২০ মিনিট বন্ধ ছিল, আর পরের ছয় মাসে একই ভুল আর হয়নি।”

কেন শক্তিশালী: ভুল স্বীকার, ক্ষতি থামানো, ব্যবস্থার পরিবর্তন, মাপা ফল। “আমি কখনো ভুল করিনি” বা অন্যকে দোষ দেওয়া সবচেয়ে দুর্বল উত্তর।

Situation: “একটি শখের project-এর মাসিক বিল হঠাৎ দ্বিগুণ হলো। Task: সেবা না ভেঙে কারণ বের করা। Action: আমি line item ধরে দুই মাস মেলালাম, দেখলাম NAT-এর processing বেড়েছে। Flow log-এ বড় গন্তব্য ছিল একই region-এর bucket. Endpoint দিলাম, আর একটি ভুলে যাওয়া VM মুছলাম। Result: বিল আগের জায়গায় ফিরল। Budget alert আর tag বসালাম, যা আগে ছিল না।”

লক্ষ করুন, এটি শখের project বলেই বলা হচ্ছে। ছোট কিন্তু সত্যিকারের ঘটনা বড় বানানো ঘটনার চেয়ে ভালো।

Situation: “একজন সিনিয়র ছোট একটি service-এর জন্য Kubernetes চাইছিলেন, আমি container service-এর পক্ষে। Task: ঝগড়া নয়, সিদ্ধান্ত। Action: আমি দুটি পথের খরচ, দলের দক্ষতা আর operational burden এক পাতায় লিখলাম। তাঁর যুক্তি ছিল ভবিষ্যতের বৃদ্ধি, সেটিও লিখলাম। একমত হলাম, কোন সংখ্যায় পৌঁছালে আবার ভাবব। Result: সিদ্ধান্তটি ADR-এ রইল। আমার মত জিতেছে তা বড় কথা নয়, শর্তটি লেখা থাকাই লাভ।”

Situation: “Deploy-এর পরে checkout-এ error বাড়ল, burn-rate alert বাজল। Task: আমি সেদিন on-call. Action: আমি ঘটনা ঘোষণা করলাম, সাম্প্রতিক বদল দেখলাম, আর কারণ না খুঁজেই আগে rollback করলাম। Status আপডেট দিতে একজনকে দায়িত্ব দিলাম। পরে দোষারোপহীন postmortem-এ দেখলাম test-এ এই ব্যবসার নিয়ম ছিল না। Result: ক্ষতি থামল কয়েক মিনিটে; একটি নতুন test আর একটি action item মালিকসহ যোগ হলো।”

অভিজ্ঞতা না থাকলে সৎভাবে ক্যাপস্টোন-এর ল্যাবের ঘটনা বলুন: ৮১১টি ব্যর্থ request, readiness সবুজ অথচ ব্যবহারকারী লাল। “এটি নিজের ল্যাবে” কথাটি আগে বলে দিন।

শক্তিশালী উত্তর: সোজা না বলুন, তারপর যা করেছেন তা সুনির্দিষ্টভাবে। কাল্পনিক নমুনা, আপনি শুধু নিজের সত্যি কাজটুকু বলবেন: “Production-এ চালাইনি। নিজের ল্যাবে একটি app container-এ তুলেছি, local Kubernetes-এ Terraform দিয়ে deploy করেছি, burn-rate alert বসিয়ে একটি খারাপ release ধরেছি আর rollback করেছি। আসল cloud account-এ এক দিনের জন্য নকশাটি তুলেছি, budget alert রেখে, সন্ধ্যায় মুছেছি। আসল চাপে কাজ করিনি, সেটিই শিখতে চাই।”

দুর্বল উত্তর দেখতে যেমন: “হ্যাঁ, AWS-এ অনেক কাজ করেছি।” Follow-up-এর দুটি প্রশ্নেই ধরা পড়ে, আর বিশ্বাস আর ফেরে না।

শেষের কথাটি জরুরি: কোন কাজ করেছেন, কোনটি পড়েছেন, কোনটি অনুমান, তা আলাদা রাখুন।

শক্তিশালী উত্তর: “এটি আমি জানি না” বলে থামবেন না, আবার বানাবেনও না। যেমন: “এই service আমি ব্যবহার করিনি। ধারণাটি যেভাবে বুঝি, সেভাবে ভাবছি… আর আমি docs-এ এটা যাচাই করতাম।” পরে জেনে নেওয়ার ইচ্ছা দেখান।

শক্তিশালী উত্তর: ছক: সমস্যা → নকশার একটি ছবি → দুটি সিদ্ধান্ত আর কারণ → একটি জিনিস যা ভেঙেছিল → কী বদলাতাম। যেমন: “Readiness সবুজ ছিল, অথচ ২৫% request ব্যর্থ। তাই burn-rate alert যোগ করলাম, যা ১ মিনিট ৪৬ সেকেন্ডে বাজল। সবচেয়ে বড় শিক্ষা: probe শুধু নিজের পথটুকু দেখে।” সব feature-এর তালিকা নয়, সিদ্ধান্তের গল্প।

দুর্বল উত্তর দেখতে যেমন: “Docker, Kubernetes, Terraform, Prometheus সব ব্যবহার করেছি।” এটি তালিকা, অভিজ্ঞতা নয়।

শক্তিশালী উত্তর: দুই ক্ষেত্রেই সৎ আর শান্ত থাকুন। না থাকলে: “এখনো নিইনি, হাতে-কলমে project-এ সময় দিয়েছি; এই দলের provider-এ প্রয়োজন হলে নিতে আগ্রহী।” থাকলে: “এটি আমাকে ধারণার মানচিত্র দিয়েছে। Production-এর চাপে কাজের অভিজ্ঞতা এর চেয়ে আলাদা, সেটি জানি।”