লিখিত ও মৌখিক (ভাইভা) প্রশ্ন — cloud, container, CI/CD আর SRE

সংজ্ঞা (NIST SP 800-145, ২০১১-এর ভাবানুবাদ): network দিয়ে যেকোনো জায়গা থেকে, চাহিবামাত্র, কনফিগার করা যায় এমন কম্পিউটিং সম্পদের ভাগাভাগি করা ভান্ডার (network, server, storage, application, service) ব্যবহারের ব্যবস্থা, যা অল্প ব্যবস্থাপনায় দ্রুত নেওয়া আর ফেরত দেওয়া যায়।

1. On-demand self-service: মানুষের অনুমোদন ছাড়া নিজেই সম্পদ নেওয়া।
2. Broad network access: সাধারণ network আর যন্ত্র দিয়ে পৌঁছানো।
3. Resource pooling: বহু গ্রাহকের জন্য এক ভান্ডার, গ্রাহক সাধারণত জানেন না ঠিক কোন যন্ত্রে আছেন।
4. Rapid elasticity: চাহিদার সাথে দ্রুত বাড়া ও কমা।
5. Measured service: ব্যবহার মাপা হয়, মাপ দেখে বিল।

NIST-এর হিসাব ৫-৩-৪: পাঁচ বৈশিষ্ট্য, তিন service model, চার deployment model.

নম্বর কোথায়: সংজ্ঞা (২), পাঁচ বৈশিষ্ট্যে (৩)। পর্ব ১

যেখানে নম্বর কাটে: শুধু “internet-এ server ভাড়া” লেখা; resource pooling আর measured service বাদ দেওয়া।

উত্তর নির্ভর করে পাঁচ বৈশিষ্ট্যের ওপর। হাতে অনুমোদন লাগলে self-service নেই; মাসিক স্থির চুক্তিতে measured service নেই; আকার বদলাতে দিন লাগলে elasticity নেই। তাই এমন সেবা hosting, cloud নয়। একই কোম্পানি API-তে মিনিটে VM দিলে আর ঘণ্টায় বিল করলে সেটি cloud-এর শর্ত অনেকটাই মেটায়।

নম্বর কোথায়: মাপকাঠি বলা (১), দুটি বৈশিষ্ট্য ধরে যুক্তি (২)। পর্ব ১

যেখানে নম্বর কাটে: নাম দেখে হ্যাঁ-না বলা; মাপকাঠি না দেওয়া।

সংজ্ঞা: service model বলে আটটি স্তরের (network, storage, server, virtualization, OS, runtime, data, application) কোনটি আপনার আর কোনটি provider-এর। NIST-এর model তিনটি: SaaS, PaaS, IaaS; CaaS আর FaaS পরের শিল্প-শব্দ।

ছবি: পাশাপাশি স্তূপ, আপনার ঘর রং করা। ওপরে উঠলে রং নিচ থেকে সরে যায়। পাশে বড় হরফে লিখুন: identity সব model-এ আপনার।

উদাহরণ: কাল্পনিক অনলাইন বাজার অ্যাপ। VM-এ নিজে সব চালালে IaaS; কোড দিয়ে দিলে PaaS; ছবি ছোট করার কাজ ঘটনায় চললে FaaS; অফিসের mail কিনলে SaaS.

Trade-off: ওপরে উঠলে কাজ কমে, নিয়ন্ত্রণ কমে আর lock-in বাড়ে। PaaS-এ app সাধারণত সবসময় চলে; FaaS-এ একক ছোট, কাজ না থাকলে সংখ্যা শূন্যে নামতে পারে।

উপসংহার: শর্ত মেটে এমন সবচেয়ে ওপরের model নিন, আর বিলের সাথে মানুষের সময়ও গুনুন।

নম্বর কোথায়: সংজ্ঞা (২), ছবি ও ছক (৪), উদাহরণ (২), trade-off ও উপসংহার (২)। পর্ব ২ · পর্ব ১৯

যেখানে নম্বর কাটে: SaaS-এ ডেটার দায় provider-এর লেখা; identity বাদ দেওয়া; CaaS বা FaaS-কে NIST-এর model বলা।

সংজ্ঞা: Shared responsibility মানে নিরাপত্তার দায় provider আর গ্রাহকের মধ্যে ভাগ করা। AWS-এর ভাষায় provider সামলায় security of the cloud: data center, হার্ডওয়্যার, hypervisor. গ্রাহক সামলান security in the cloud: identity, ডেটা, setting, আর IaaS-এ guest OS-এর patch.

উদাহরণ: কেউ bucket public রাখলে ডেটা ফাঁস গ্রাহকের দায়, যদিও storage provider-এর। IaaS-এ VM-এর kernel patch গ্রাহকের, PaaS-এ provider-এর।

সীমারেখা model ভেদে সরে, কিন্তু identity, ডেটা, backup আর নিজের setting সব model-এ আপনার।

নম্বর কোথায়: সংজ্ঞা (১), দুই ভাগ (২), উদাহরণ (১), model ভেদে সরা (১)। পর্ব ২ · পর্ব ৩৪

যেখানে নম্বর কাটে: “Cloud-এ গেলে নিরাপত্তা provider-এর” লেখা; replica-কে backup ধরা।

না। FaaS একটি model: ঘটনায় function চলে। Serverless বড় ধারণা: server-এর ব্যবস্থাপনা আপনার নয়, ব্যবহার অনুযায়ী বিল; তাই serverless database বা storage-ও আছে। সংজ্ঞা উৎসভেদে একটু আলাদা, সেটি লিখে দিন। CaaS বসে IaaS আর PaaS-এর মাঝে: আপনি image দেন, provider orchestration চালায়, node-এর OS-এর দায় ভাগ হয়।

নম্বর কোথায়: পার্থক্য (২), CaaS-এর অবস্থান (১)। পর্ব ২

যেখানে নম্বর কাটে: দুটিকে সমার্থক লেখা।

NIST-এর model এই চারটি। Multi-cloud পরের শিল্প-শব্দ: একাধিক public provider. On-premises হলো জায়গা; private cloud হলো পাঁচ বৈশিষ্ট্যসহ একান্ত cloud. Self-service ছাড়া নিজের server-ঘর private cloud নয়।

Trade-off: multi-cloud-এর দাম দক্ষতা, networking, egress আর সবচেয়ে ছোট সাধারণ ফিচার।

নম্বর কোথায়: চার model (৩), multi-cloud (১), on-premises-এর পার্থক্য (১), trade-off (১)। পর্ব ৩

যেখানে নম্বর কাটে: Hybrid আর multi-cloud গুলিয়ে ফেলা; community বাদ দেওয়া।

CapEx দীর্ঘস্থায়ী সম্পদ কেনার আগাম খরচ; হিসাবে তা বছরে ভাগ হয়, একে বলে depreciation. OpEx চলতি বিল। TCO সব সারির যোগফল।

মানে: cloud টাকার সময় বদলায়, মোট খরচ কমবেই এমন নয়।

নম্বর কোথায়: তিন সংজ্ঞা (২), দুই দিকের সারি (৩)। পর্ব ৪

যেখানে নম্বর কাটে: শুধু server-এর দাম আর VM-এর দাম তুলনা করা; staff আর data transfer ভুলে যাওয়া।

1. Break-even = CapEx ÷ মাসিক সাশ্রয় = ৬০,০০০ ÷ (৫,০০০ − ২,৫০০) = ২৪ মাস.
2. Peak-to-average ratio = ২০ ÷ ৫ = ৪, তাই utilisation = ১ ÷ ৪ = ২৫%.

মানে: ২৪ মাস ধরা হয়েছে দিনরাত পূর্ণ load-এ। Utilisation ২৫% হলে কেনা ক্ষমতার তিন-চতুর্থাংশ অলস, আর elasticity cloud-এর পক্ষে ঝোঁকে। স্থির, উঁচু, দীর্ঘ load আর সক্ষম দল থাকলে নিজের যন্ত্র ভালো হতে পারে। টাকার সময়মূল্য ধরলে break-even একটু পেছায়।

নম্বর কোথায়: সূত্র ও মান (৩), utilisation (১), সিদ্ধান্ত (২)। পর্ব ৪

যেখানে নম্বর কাটে: মোট খরচ ভাগ করা; একক না লেখা; এক সংখ্যায় থেমে সিদ্ধান্ত না দেওয়া।

Region ভৌগোলিক এলাকা; AZ তার ভেতরের বিচ্ছিন্ন অংশ; edge ব্যবহারকারীর কাছের ছোট ঘাঁটি।

1. Series: ০.৯৯৯³ = ৯৯.৭০০৩%, ৩০ দিনে প্রায় ১২৯.৫ মিনিট বন্ধ।
2. Parallel: ১ − ০.০১² = ৯৯.৯৯%, যদি কপি দুটি সত্যিই স্বাধীন হয়।

Shared dependency থাকলে স্বাধীনতার অনুমান ভাঙে, তখন কপির লাভ কমে।

নম্বর কোথায়: তিন সংজ্ঞা (২), দুই হিসাব (২), স্বাধীনতার শর্ত (১)। পর্ব ৫

যেখানে নম্বর কাটে: Series-এ যোগ করা; “স্বাধীন হলে” শর্ত বাদ দেওয়া।

Scalability মানে বাড়তে পারার ক্ষমতা। Elasticity মানে চাহিদার সাথে নিজে থেকে বাড়া ও কমা। ঈদের আগে বাসের টিকিটের সাইট ১০০টি VM পর্যন্ত যেতে পারলে সেটি scalable; ভিড় শেষে নিজে থেকে ২০টিতে নামলে সেটি elastic. প্রথমটি নকশার গুণ, দ্বিতীয়টি বিলেও দেখা যায়।

নম্বর কোথায়: দুই সংজ্ঞা (২), উদাহরণ (১)। পর্ব ১ · পর্ব ১৭

যেখানে নম্বর কাটে: দুটিকে সমার্থক লেখা; কমার দিকটি ভুলে যাওয়া।

Control plane ব্যবস্থাপনা ও সিদ্ধান্তের পথ; data plane আসল কাজের পথ। Console, CLI, SDK আর IaC সবাই শেষে একই API ডাকে, পার্থক্য ব্যবহারের ধরনে।

Jitter সব client-এর একসাথে ফিরে আসা ঠেকায়। Idempotency token timeout-এর পরে retry করলেও duplicate resource হতে দেয় না।

নম্বর কোথায়: দুই plane (১.৫), একই API (০.৫), jitter ও token (২)। পর্ব ৬

যেখানে নম্বর কাটে: Console-কে বেশি ক্ষমতাবান ভাবা; retry-র ঝুঁকি না বলা।

সংজ্ঞা: DevOps সংস্কৃতি ও চর্চার আন্দোলন; Dev আর Ops-এর উল্টো লক্ষ্য, তথ্য আর দায় এক করে। SRE তার একটি প্রকৌশলভিত্তিক রূপ, হাতিয়ার SLO, error budget আর toil-এর সীমা। সংজ্ঞা নিয়ে মতভেদ আছে, তাই “একটি প্রচলিত ব্যাখ্যা” লিখুন।

CALMS: Culture, Automation, Lean, Measurement, Sharing.

Three ways: flow (বাঁ থেকে ডানে দ্রুত প্রবাহ), feedback (ডান থেকে বাঁয়ে দ্রুত সংকেত), continual learning (পরীক্ষা ও শেখা).

DORA metric: deployment frequency, lead time, change failure rate আর recovery time, চারটি মিলে গতি আর স্থিতি দুটোই মাপে।

উদাহরণ: ৯৯.৯% SLO-তে ৩০ দিনের budget ৪৩.২ মিনিট; budget শেষ হলে release থামিয়ে নির্ভরযোগ্যতায় কাজ।

Trade-off: “DevOps engineer” পদ বসালেই দেয়াল ভাঙে না। লক্ষ্য একই না হলে নতুন একটি silo তৈরি হয়।

নম্বর কোথায়: সংজ্ঞা ও সম্পর্ক (২), CALMS (১.৫), three ways (১.৫), DORA (১.৫), উদাহরণ (১.৫)। পর্ব ৭

যেখানে নম্বর কাটে: DevOps-কে tool বা পদের নাম বলা; SRE-কে DevOps-এর প্রতিদ্বন্দ্বী বলা।

start service এখন চালায়; enable boot-এ চলার symlink বানায়। Unit file বদলালে daemon-reload লাগে।

Exit status = ১২৮ + signal. ১৩৭ = ১২৮ + ৯ (SIGKILL), ১৪৩ = ১২৮ + ১৫ (SIGTERM). ১৩৭ মানেই OOM নয়; memory-র কারণ কি না journal বা OOM-এর চিহ্নে দেখতে হয়।

নম্বর কোথায়: Start ও enable (২), দুই exit status (২)। পর্ব ১১ · পর্ব ৩৯

যেখানে নম্বর কাটে: ১৩৭ দেখেই OOM লেখা।

ক্রম: অনুরোধের পথ ধরে: নাম (DNS) → পথ → port → TLS → HTTP. ভেতর আর বাইরে, দুই দিক থেকে মিলিয়ে দেখুন।

Firewall বন্ধ করে পরীক্ষা নয়; tcpdump দিয়ে packet খুঁজুন।

নম্বর কোথায়: ক্রম (২), চার লক্ষণ (৪)। পর্ব ১৩ · পর্ব ১৪

যেখানে নম্বর কাটে: এলোমেলো restart; 502 আর 504 গুলিয়ে ফেলা।

Stop-এ volume থাকে, আবার চালানো যায়; compute বিল থামে, disk আর static IP-র বিল নয়। স্বয়ংক্রিয় public IP সাধারণত বদলায়। Terminate VM মুছে দেয়, ফেরানো যায় না; পড়ে থাকা volume খুঁজে মুছতে হয়।

Instance store host-এর সাথে বাঁধা। Stop, terminate বা host ব্যর্থ হলে ডেটা যায়, সাধারণ reboot-এ থাকে।

নম্বর কোথায়: Stop (১.৫), terminate (১), instance store (১.৫)। পর্ব ১৫

যেখানে নম্বর কাটে: Stop-এ সব বিল থামে লেখা।

Target tracking: desired = ⌈current × metric ÷ target⌉, তারপর min-max-এ আটকানো।

desired = ⌈৪ × ৯০ ÷ ৬০⌉ = ⌈৬⌉ = ৬, যা ২ আর ১০-এর ভেতরে।

Cooldown দুই সিদ্ধান্তের বিরতি; warm-up নতুন instance তৈরি হওয়ার সময়। CPU সবসময় ভালো signal নয়: ১০০%-এ আটকে আসল চাপ লুকায়। Group-কে load balancer-এর health check শোনান, নইলে hung app বদলায় না।

নম্বর কোথায়: সূত্র (১), হিসাব (২), দুই শব্দ (১), signal-এর সীমা (১)। পর্ব ১৭

যেখানে নম্বর কাটে: Min-max বাদ দেওয়া; ওপরে round না করা।

পথ: listener → rule → target group → target.

সর্বোচ্চ সময় ≈ U × I + T = ২ × ১০ + ৫ = ২৫ সেকেন্ড. এই সময়ের অনুরোধই detection-এর দাম।

নম্বর কোথায়: টেবিল (৩), হিসাব (২)। পর্ব ১৮

যেখানে নম্বর কাটে: Timeout যোগ করতে ভুলে যাওয়া; L4-কে HTTP-পড়া বলা।

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

নম্বর কোথায়: টেবিল (৪), কারণ (১)। পর্ব ২০

যেখানে নম্বর কাটে: ঠিকানার পার্থক্য বাদ দিয়ে শুধু ব্যবহার লেখা।

ভুল DELETE সব কপিতে যায়। তাই মানুষের ভুল থেকে ফেরায় PITR, আর restore করে না দেখলে backup অনিশ্চিত।

নম্বর কোথায়: টেবিল (৩), কারণ (২)। পর্ব ২২

যেখানে নম্বর কাটে: Replica-কে backup বলা।

সংজ্ঞা: RPO কত ডেটা হারানো চলে, পেছনে মাপে। RTO কত সময় বন্ধ থাকা চলে, সামনে মাপে।

ছবি: সময়ের রেখায় দুর্ঘটনার বিন্দু; বাঁয়ে শেষ ভালো কপি পর্যন্ত RPO, ডানে সেবা ফেরা পর্যন্ত RTO.

হিসাব: RPO ≈ ব্যবধান + পৌঁছানোর সময় = ৬০ + ১০ = ৭০ মিনিট.

Trade-off: RTO যত ছোট, খরচ তত বেশি। উপরের সময়গুলো মোটা ধারণা, নিজের মহড়ায় মাপতে হয়। Replication ভুল আর ransomware-ও কপি করে; তাই 3-2-1 রাখুন, অন্তত একটি কপি অন্য account-এ।

উপসংহার: ব্যবসা RPO ও RTO ঠিক করে, কৌশল তার পরে; restore মহড়াই প্রমাণ।

নম্বর কোথায়: সংজ্ঞা (২), ছবি (২), চার কৌশল (৪), হিসাব (১), trade-off (১)। পর্ব ২৪

যেখানে নম্বর কাটে: RPO আর RTO উল্টে লেখা; পৌঁছানোর ১০ মিনিট বাদ দেওয়া।

অনুমান: AWS-ধরনের নকশা, প্রতি subnet-এ ৫টি ঠিকানা provider কেটে রাখে, অফিস 10.0.0.0/16 ব্যবহার করে।

ঠিকানা: VPC 10.20.0.0/16, অর্থাৎ ৬৫,৫৩৬টি ঠিকানা। পরে জোড়া দিতে হবে বলে অফিসের সাথে ওভারল্যাপ রাখা যাবে না।

প্রতিটিতে ব্যবহারযোগ্য ২৫৬ − ৫ = ২৫১টি।

ছবি: অংশ ৯-এর VPC মানচিত্র।

নিরাপত্তা: load balancer public subnet-এ, NAT প্রতি AZ-এ একটি। Database-এর security group-এ উৎস app-এর group, IP নয়। SSH-এর জন্য 0.0.0.0/0 নয়।

Trade-off: দুই NAT-এ খরচ বাড়ে, কিন্তু এক AZ পড়লে অন্যটি চলে। Kubernetes থাকলে pod-এর ঠিকানা আগেই হিসাব করুন, কারণ pod subnet থেকে ঠিকানা পেতে পারে। Storage-এর জন্য endpoint দিলে NAT-এর বিল কমে।

নম্বর কোথায়: অনুমান ও CIDR (৩), ছবি (৩), নিরাপত্তা (২), trade-off (২)। পর্ব ২৫ · পর্ব ২৬ · পর্ব ২৭

যেখানে নম্বর কাটে: Subnet-এর সীমা ওভারল্যাপ করা; database-কে public subnet-এ রাখা; “দুই AZ” না মানা; অনুমান না লেখা।

পার্থক্য route table-এ: internet gateway-র route থাকলে subnet public, NAT-এর হলে private, কোনো পথ না থাকলে isolated. VM-এর public IP-ও লাগে।

IGW অনুবাদ করে 1:1, দুই দিক থেকেই শুরু হতে পারে। NAT অনেকে-থেকে-একে, শুধু ভেতর থেকে শুরু। AWS-ধরনের নকশায় NAT gateway বসে public subnet-এ।

10.1.5.9-এর জন্য /16 আর /24 দুটোই মিললে /24 জেতে: সবচেয়ে লম্বা prefix, ক্রম নয়।

নম্বর কোথায়: Route-এর ভূমিকা (২), দুই অনুবাদ (২), longest prefix (১)। পর্ব ২৫ · পর্ব ২৬

যেখানে নম্বর কাটে: Public IP থাকলেই public subnet বলা; NAT-কে private subnet-এ বসানো।

(AWS-এর আচরণ; অন্য provider-এ নাম ও নিয়ম আলাদা হতে পারে।)

NACL stateless, তাই উত্তরের জন্য outbound-এ ephemeral port (1024-65535) খোলা লাগে। সেটি না থাকলে SYN পৌঁছায়, উত্তর ফেরে না। Route আর host firewall-ও দেখুন।

নম্বর কোথায়: টেবিল (৩), timeout-এর কারণ (২)। পর্ব ২৭

যেখানে নম্বর কাটে: Security group-এ deny আছে লেখা; ক্রমের নিয়ম উল্টে ফেলা।

Full mesh = n(n−১) ÷ ২ = ২৫ × ২৪ ÷ ২ = ৩০০টি. এই সংখ্যাই hub-এর যুক্তি।

পৌঁছাতে হলে ঠিকানা, দুই দিকের route, firewall, DNS, MTU আর IAM সবই ঠিক থাকতে হয়।

নম্বর কোথায়: চার পথ (৪), হিসাব (১), শর্ত (১)। পর্ব ২৮

যেখানে নম্বর কাটে: Peering-কে transitive ভাবা।

Authentication: আপনি কে। Authorization: আপনি কী পারেন। HTTP-র ৪০১ আর ৪০৩ এই দুইয়ের সাথে মেলে।

Role-এ স্থায়ী secret নেই, অস্থায়ী credential নিজে থেকে মরে, আর audit log-এ session আলাদা হয়।

Trust policy বলে কে role পরতে পারবে; permission policy বলে পরে কী করতে পারবে। দুই দরজাই পেরোতে হয়।

নম্বর কোথায়: দুই শব্দ (১), role-এর তিন সুবিধা (২), দুই policy (২)। পর্ব ৩১

যেখানে নম্বর কাটে: “Role মানেই নিরাপদ” লেখা; অস্থায়ী হলেও অনুমতি ছোট রাখতে হয়।

সংজ্ঞা: প্রতিটি অনুরোধ principal, action, resource আর condition দিয়ে বিচার হয়। উদাহরণটি AWS-ধরনের; Azure আর Google Cloud-এ শব্দ ও স্তর আলাদা।

1. শুরু default deny: Allow না মিললে “না”।
2. কোথাও explicit Deny মিললে সঙ্গে সঙ্গে “না”। Statement-এর ক্রম গুরুত্বহীন।
3. Guardrail, boundary আর session policy সীমা টানে, নিজে কিছু দেয় না।
4. Identity বা resource policy থেকে Allow লাগে।

ছবি: ওপর থেকে নিচে সিদ্ধান্তের flow, Deny-র তীর এক ঘরে।

হিসাব: কার্যকর অনুমতি স্তরগুলোর ছেদ = {Get, Put, Delete} ∩ {Get, Put, List} ∩ {Get, List} = {Get}. Delete boundary-তে নেই, Put session policy-তে নেই, List identity-তে নেই।

Cross-account: দুই পক্ষের Allow চাই: caller-এর identity policy আর resource-এর দিকের policy. Same-account-এ সাধারণত এক পক্ষই যথেষ্ট।

Trade-off: Least privilege একটি চক্র: ছোট শুরু, log, simulator, ধাপে ধাপে বাদ। খুব কড়া হলে কাজ আটকায়, তাই access denied-এ আগে দেখুন কে, কোন action, কোন resource, কোন স্তর।

নম্বর কোথায়: ধাপ (৪), ছবি (২), হিসাব (২), cross-account (২)। পর্ব ৩২ · পর্ব ৩৫

যেখানে নম্বর কাটে: Guardrail বা boundary-কে অনুমতিদাতা বলা; ছেদের জায়গায় যোগফল নেওয়া; statement-এর ক্রমকে গুরুত্ব দেওয়া।

সংজ্ঞা: Envelope encryption-এ data key ডেটা লক করে, আর KEK data key লক করে। KEK KMS-এর ভেতরে থাকে, বাইরে আসে না।

1. App নিজের role দিয়ে KMS-এর কাছে নতুন data key চায়; KMS অনুমতি দেখে log লেখে।
2. KMS দেয় খোলা data key আর তার wrapped কপি।
3. App নিজের কাছে ডেটা encrypt করে, খোলা key memory থেকে মুছে ফেলে।
4. Ciphertext-এর পাশে wrapped key জমা থাকে।
5. পড়ার সময় wrapped key KMS-এ যায়, অনুমতি মিললে খোলা key ফেরে।

কেন: বড় ডেটা KMS-এ পাঠাতে হয় না; একটি data key ফাঁস হলে শুধু তার ডেটা খোলা হয়; প্রতিটি ব্যবহারে অনুমতি ও audit log থাকে।

Rotation: KEK rotate হলে পুরোনো ডেটা আগের মতোই থাকে, পুরোনো material দিয়ে পড়া যায়। Data key ফাঁস হলে re-wrap যথেষ্ট নয়, ডেটা আবার encrypt করতে হয়।

Key মুছলে: ডেটা আর পড়া যায় না (crypto-erasure). তাই KMS-এ মোছায় অপেক্ষার সময় রাখা ভালো।

Trade-off: Data key cache করলে বিল আর latency কমে, কিন্তু এক key-এর ঝুঁকি বাড়ে।

নম্বর কোথায়: সংজ্ঞা (১), ধাপ ও ছবি (৩), কেন (২), rotation ও মোছা (২)। পর্ব ৩৩

যেখানে নম্বর কাটে: KMS-এ পুরো ডেটা পাঠানো লেখা; “rotation-এ সব ডেটা নতুন করে encrypt হয়” লেখা।

API-তে এক লাইনের বদলেই public storage, খোলা port, বাড়তি IAM বা বন্ধ log হতে পারে, তাই misconfiguration-ই প্রধান ঝুঁকি।

Defense in depth-এর পাঁচ স্তর: পরিচয়, network, compute, ডেটা, ধরা পড়া।

Encrypted bucket public হলেও নিরাপদ নয়: অনুমতি থাকলে সেবা ডেটা খুলে দেয়। এনক্রিপশন অনুমতির বিকল্প নয়। CSPM ভুল setting খোঁজে; threat detection চলমান আচরণ দেখে। Audit log আলাদা account-এ রাখুন।

নম্বর কোথায়: কারণ (১), পাঁচ স্তর (২), এনক্রিপশনের সীমা (২)। পর্ব ৩৪

যেখানে নম্বর কাটে: এনক্রিপশনকে শেষ কথা ভাবা।

Account শক্ত নিরাপত্তা, quota আর বিলের সীমা; IAM-এর ভুল সেই দেয়াল পেরোয় না। তাই dev, prod, log আর security আলাদা, আর landing zone নতুন account-কে জন্ম থেকেই নিয়ম মানায়।

SCP অনুমতি দেয় না, সর্বোচ্চ সীমা টানে। Preventive কাজ ঘটার আগে আটকায়, detective পরে শনাক্ত করে। নতুন নিয়ম detective-এ শুরু করা নিরাপদ।

নম্বর কোথায়: Account-এর যুক্তি (২), SCP (১), দুই control (১)। পর্ব ৩৫

যেখানে নম্বর কাটে: SCP-কে Allow-এর উৎস ভাবা।

সংজ্ঞা: Container app আর তার ব্যবহারকারী-স্তরের পরিবেশ একসাথে পাঠায়, আর host-এর kernel ভাগ করে চলে। VM হার্ডওয়্যারের ওপর hypervisor-এ পুরো OS চালায়।

ছবি: দুটি স্তূপ। VM: হার্ডওয়্যার → hypervisor → guest OS → app. Container: হার্ডওয়্যার → host OS (একটি kernel) → runtime → app.

উদাহরণ: ভিন্ন kernel বা Windows-Linux একসাথে লাগলে VM; একই kernel-এ অনেক ছোট service হলে container. বাস্তবে cloud-এ container প্রায়ই VM-এর ভেতরে চলে।

ইতিহাস: Docker (২০১৩) container আবিষ্কার করেনি; namespace আর cgroup আগেই ছিল। Docker image, layer আর registry দিয়ে ব্যবহার সহজ করেছে।

উপসংহার: হালকা হওয়ার দাম দুর্বল সীমানা। অবিশ্বস্ত কোডে শক্ত আলাদাকরণ লাগে।

নম্বর কোথায়: সংজ্ঞা (২), ছবি (২), টেবিল (২), উদাহরণ ও উপসংহার (২)। পর্ব ৩৬

যেখানে নম্বর কাটে: Container-কে “ছোট VM” বলা; নিজের kernel আছে লেখা।

Image শুধু-পড়ার প্যাকেজ; container তার ওপর writable layer বসিয়ে চালানো process; registry গুদাম। Container মুছলে writable layer-ও যায়, তাই ডেটা volume-এ।

Tag সরানো যায় এমন নাম; digest বিষয়বস্তুর SHA-256 hash, বদলায় না। মানুষের জন্য tag, deployment আর rollback-এর জন্য digest. latest সবচেয়ে নতুন image-এর নিশ্চয়তা নয়, শুধু default tag.

নম্বর কোথায়: তিন শব্দ (২), পার্থক্য (১), সিদ্ধান্ত (১)। পর্ব ৩৬ · পর্ব ৪১

যেখানে নম্বর কাটে: latest মানে সর্বশেষ লেখা।

সংজ্ঞা: Image হলো read-only layer-এর সারি আর config. RUN, COPY ফাইল বদলায় বলে layer বানায়; ENV, EXPOSE, CMD শুধু config বদলায়।

ছবি: নিচে base image, তার ওপর dependency, app, একদম ওপরে container-এর writable layer.

Container-এ লেখা: নিচের ফাইলে লিখলে পুরো ফাইল ওপরে আসে (copy-up). মুছলে শুধু whiteout বসে।

Cache: ধাপ আর তার input না বদলালে Docker পুরোনো layer নেয়। একটি ধাপ বাতিল হলে নিচের সব বাতিল। তাই যা কম বদলায় তা ওপরে: lockfile আগে COPY, install, তারপর কোড।

কেন ছোট হয় না: আগের layer read-only; মোছা হলেও বাইট সেখানেই থাকে। একই RUN-এ মুছুন, অথবা multi-stage build নিন। Secret-ও এভাবে layer-এ থেকে যায়।

Trade-off: Layer ভাগাভাগিতে pull ও জায়গা বাঁচে, কিন্তু অগোছালো ক্রমে cache নষ্ট হয়। .dockerignore রাখুন।

নম্বর কোথায়: সংজ্ঞা (২), ছবি (১), container-এ লেখা (১), cache (২), মোছার কারণ (২)। পর্ব ৩৭ · পর্ব ৩৮

যেখানে নম্বর কাটে: CMD-কে layer বলা; cache-এর “নিচের সব বাতিল” নিয়ম বাদ দেওয়া।

1. Multi-stage build: build-এর টুল ship হয় না, image ছোট ও নিরাপদ।
2. Non-root: সংখ্যায় USER, ভাঙলে ক্ষতি ছোট।
3. Exec form: JSON-এ CMD; shell মাঝে না থাকায় app নিজেই PID 1 হয়ে signal পায়।
4. নির্দিষ্ট base: latest নয়, নির্দিষ্ট version বা digest, সাথে স্বয়ংক্রিয় আপডেট।

Secret কখনোই ENV, ARG বা COPY-তে নয়; build-এ --secret, চলার সময়ে runtime secret.

নম্বর কোথায়: প্রতিটি অভ্যাস ও কারণে (১), secret (১)। পর্ব ৩৮

যেখানে নম্বর কাটে: কারণ ছাড়া তালিকা; RUN rm secret দিয়ে নিরাপদ ভাবা।

সংজ্ঞা: Kubernetes অনেক node জুড়ে container বসানো, সেরে ওঠা আর ধাপে ধাপে আপডেটের ব্যবস্থা। Control plane সিদ্ধান্ত নেয়, node-এ কাজ চলে।

ছবি: অংশ ৯-এর ছবি।

পথ: API server যাচাই করে etcd-তে লেখে → Deployment controller ReplicaSet বানায় → ReplicaSet controller Pod বানায় → scheduler node বসায় → kubelet দেখে runtime দিয়ে চালায়।

Reconciliation loop: spec হলো চাওয়া, status হলো পাওয়া, controller পার্থক্যটুকু লুপে ঠিক করে।

etcd: quorum = ⌊৫ ÷ ২⌋ + ১ = ৩, তাই ২টি বিদায় সহ্য করে। Quorum গেলে লেখা থামে, চলমান Pod চলে।

Trade-off: ক্ষমতার দাম জটিলতা; Kubernetes বিনিয়োগ, মান নির্ধারক নয়।

নম্বর কোথায়: সংজ্ঞা (১), অংশগুলো (৩), ছবি (২), পথ (২), etcd (১), loop (১)। পর্ব ৪২

যেখানে নম্বর কাটে: Scheduler Pod চালায় লেখা; kubelet-কে control plane-এ রাখা; quorum ভুল।

সংজ্ঞা: Pod schedule, network আর জীবনের একক; ভেতরের container-গুলো একই IP ভাগ করে।

Phase: Pending (গৃহীত, container এখনো চালু হয়নি), Running (অন্তত একটি চলছে বা চালু বা restart হচ্ছে), Succeeded, Failed, Unknown (সাধারণত node-এর সাথে যোগাযোগ নেই)।

ছবি: Pending → Running → Succeeded বা Failed; পাশে Unknown.

তৈরি: API server-এ জমা → scheduler node বাছে → image নামে → init container → মূল container → startup → readiness পাস করলে traffic.

মোছা: Terminating, পাশাপাশি Service থেকে সরা → preStop → SIGTERM → সীমা ফুরালে SIGKILL. পুরো সীমা terminationGracePeriodSeconds, default ৩০ সেকেন্ড।

STATUS phase নয়: CrashLoopBackOff দেখা Pod-এর phase আসলে Running, আর ImagePullBackOff দেখা Pod-এর Pending. Debug: describe → logs --previous → exec.

উপসংহার: Production-এ bare Pod নয়, Deployment-এর মতো controller.

নম্বর কোথায়: Phase (২), ছবি (১), তৈরি (২), মোছা (২), STATUS (১)। পর্ব ৪৩

যেখানে নম্বর কাটে: CrashLoopBackOff-কে phase লেখা; SIGKILL আগে লেখা।

Database পড়লে সব Pod-এর liveness ব্যর্থ হয়, সব একসাথে restart হয়, অথচ সমস্যা Pod-এ নয়। তাই liveness কখনো dependency ছোঁবে না।

নম্বর কোথায়: টেবিল (৩), বিপদ (১)। পর্ব ৪৩ · পর্ব ৪৫

যেখানে নম্বর কাটে: Readiness ব্যর্থ হলে restart হয় লেখা।

সংজ্ঞা: Rolling update-এ Deployment নতুন ReplicaSet বাড়ায় আর পুরোনোটি কমায়। শুধু spec.template বদলালে rollout হয়।

হিসাব: maxSurge উপরে round: ২.৫ → ৩; maxUnavailable নিচে round: ২.৫ → ২।

1. সর্বোচ্চ মোট = ১০ + ৩ = ১৩.
2. সর্বনিম্ন available = ১০ − ২ = ৮.

ছবি: দুটি ReplicaSet-এর সংখ্যার সময়রেখা, ওপরে ১৩-র দেয়াল, নিচে ৮-এর দেয়াল।

আটকে গেলে: ভুল image সেবা ভাঙে না, rollout থামিয়ে দেয়, কারণ নতুন Pod ready না হলে পুরোনো নামে না। progressDeadlineSeconds শুধু condition বদলায়; rollback আপনার কাজ: kubectl rollout undo.

Zero downtime: সৎ readiness + graceful shutdown + preStop + যথেষ্ট grace + দুই version-এর সামঞ্জস্য।

Trade-off: বেশি surge মানে দ্রুত, কিন্তু বাড়তি resource. দুটোই ০ দেওয়া যায় না।

নম্বর কোথায়: সংজ্ঞা (২), হিসাব (২), ছবি (১), আটকে যাওয়া (২), zero downtime (১)। পর্ব ৪৪

যেখানে নম্বর কাটে: দুটি শতাংশই একই দিকে round করা; “নিজে rollback হয়” লেখা।

Pod নশ্বর, তার IP-ও। Service দেয় স্থির নাম আর স্থির virtual IP; selector ঠিক করে কে তালিকায়, readiness ঠিক করে কে traffic পাবে।

kube-proxy সংযোগ ভাগ করে, অনুরোধ নয়। HTTP routing-এ Ingress বা Gateway API লাগে।

নম্বর কোথায়: কেন লাগে (১), পাঁচ ধরন (৪), সীমা (১)। পর্ব ৪৫ · পর্ব ৪৬

যেখানে নম্বর কাটে: NodePort আর LoadBalancer-কে আলাদা ব্যবস্থা ভাবা; Service-কে Pod চালানোর object বলা।

Request দিয়ে scheduler জায়গা ঠিক করে; limit চলার সময়ের সর্বোচ্চ সীমা। CPU limit পার হলে throttling, memory পার হলে OOMKilled, exit 137.

QoS class: Guaranteed (সব request = limit), Burstable (কিছু আছে), BestEffort (কিছুই নেই)।

Scheduler ব্যবহার নয়, বুক করা request দেখে। তাই Pending দেখলে আগে event পড়ুন: resource, label, taint বা anti-affinity. Request ঠিক না হলে HPA, node আর বিল, তিনটিই ভুল হয়।

নম্বর কোথায়: দুই শব্দ (১), পার হলে (১), QoS (১), Pending (২)। পর্ব ৪৮

যেখানে নম্বর কাটে: CPU limit পার হলে kill লেখা।

Ingress শুধু নিয়মের object; নিয়ম মেনে traffic চালায় controller. Controller না থাকলে কিছুই ঘটে না।

একটি ঠিকানায় অনেক HTTP Service, কম খরচ আর TLS এক জায়গায়; HTTP ছাড়া traffic-এ LoadBalancer Service লাগতে পারে।

Gateway API আনে role ভিত্তিক দায়িত্ব ভাগ, আর ওজন ও header matching API-র অংশ হিসেবে। সাধারণত 404 মানে নিয়ম মেলেনি, 503 মানে ready Pod নেই।

নম্বর কোথায়: পার্থক্য (১), কেন Ingress (১.৫), Gateway API (১.৫)। পর্ব ৪৬

যেখানে নম্বর কাটে: Ingress object-কে নিজেই proxy ভাবা।

IaC মানে পরিকাঠামো হাতে না বানিয়ে কোডে লেখা: রেকর্ড, review আর পুনরাবৃত্তি পাওয়া যায়, যা ClickOps-এ নেই।

Declarative-এ শেষ ফল লেখা হয়, tool পার্থক্য হিসাব করে; imperative-এ ধাপ লেখা হয়।

Idempotent মানে বারবার করলেও ফল একবার করার সমান। দ্বিতীয় apply-এ No changes.

নম্বর কোথায়: IaC (২), পার্থক্য (২), idempotent (১)। পর্ব ৫১

যেখানে নম্বর কাটে: Script থাকলেই IaC ভাবা।

সংজ্ঞা: State হলো config আর বাস্তবের মাঝের খতিয়ান: কোডের নামের সাথে আসল resource-এর id মেলায়, metadata রাখে, plan দ্রুত করে, আর কোড থেকে সরানো জিনিস চেনে।

ছবি: config + state + বাস্তব → plan → apply.

দলে: remote backend, lock, versioning, encryption আর ছোট অনুমতি একসাথে। State Git-এ নয়, হাতে সম্পাদনা নয়; এতে secret খোলা লেখায় থাকতে পারে।

Trade-off: ছোট state মানে ছোট blast radius কিন্তু বেশি জোড়া। ভাগ করুন blast radius, মালিক দল আর বদলের হার দেখে। force-unlock শেষ উপায়।

নম্বর কোথায়: কেন লাগে (২), দলে (৩), চার জিনিস (২), trade-off (১)। পর্ব ৫১ · পর্ব ৫৩

যেখানে নম্বর কাটে: State-কে Git-এ রাখা; state rm আর destroy গুলিয়ে ফেলা।

+ তৈরি, ~ বদল, - মোছা, -/+ আগে মোছে, +/- আগে বানায় (create_before_destroy). Replace add আর destroy দুটিতেই গোনা হয়। forces replacement দেখলেই থামুন।

Drift মানে কোড আর বাস্তবের অমিল। Schedule-করা plan -detailed-exitcode-এ exit code 2 মানে পার্থক্য আছে; plan -refresh-only drift দেখায়। ফিরিয়ে দেওয়া না গ্রহণ করা, সিদ্ধান্ত মানুষের। Apply করুন শুধু review করা saved plan.

নম্বর কোথায়: চিহ্ন (২), drift (২), saved plan (১)। পর্ব ৫১ · পর্ব ৫২ · পর্ব ৫৩ · পর্ব ৫৫

যেখানে নম্বর কাটে: -/+ আর +/- উল্টে লেখা।

Terraform resource বানায় ও state রাখে; Ansible ভেতরের config সামলায়, agentless, SSH আর Python দিয়ে push করে, state ফাইল রাখে না। এক কথায়: Terraform বানায়, Ansible সাজায়।

Mutable পথে চলমান server বদলায়, drift জমে। Immutable পথে Packer image বানায় আর server বদলে যায়, state থাকে বাইরে। দাম: image build-এর সময় আর পাইপলাইন।

নম্বর কোথায়: দুই tool (২), দুই পথ (২), trade-off (১)। পর্ব ৫৬

যেখানে নম্বর কাটে: দুটিকে প্রতিদ্বন্দ্বী ভাবা।

সংজ্ঞা: CI প্রতিটি বদল ঘন ঘন মূল ধারায় জুড়ে স্বয়ংক্রিয়ভাবে build ও test. Continuous delivery প্রতিটি সফল বদল release-যোগ্য রাখে, production-এ যাওয়া মানুষের সিদ্ধান্ত। Continuous deployment-এ সেটিও স্বয়ংক্রিয়।

ছবি: commit → lint ও unit test → build image → scan → staging → approval → production, প্রতিটি ধাপ থেকে ব্যর্থতার তীর লেখকের কাছে।

নকশা: Pipeline একটি DAG; সময়ের নিচের সীমা critical path. সস্তা পরীক্ষা আগে। Cache গতির জন্য, না থাকলেও ফল এক; artifact ফল হস্তান্তর করে।

হিসাব: ২ + ২০ ÷ ৪ = ৭ মিনিট; মোট কাজ ৪ × ৭ = ২৮ runner-মিনিট।

Trade-off: Runner বাড়ালে বিল বাড়ে; setup-এর জন্য লাভের ছাদ আছে (Amdahl). Flaky test চিহ্নিত করে quarantine করুন। Pipeline নিজেও নিরাপত্তার সীমানা।

নম্বর কোথায়: তিন সংজ্ঞা (৩), ছবি (২), নকশা (১), হিসাব (১), trade-off (১)। পর্ব ৫৭

যেখানে নম্বর কাটে: Delivery আর deployment গুলিয়ে ফেলা; failure-এর পথ না আঁকা।

পরীক্ষার ফল নির্দিষ্ট digest-এর; rebuild মানে নতুন, অপরীক্ষিত বাইট। তাই একবার build, সব জায়গায় একই artifact.

Promotion-এ tag বা নথি বদলায় আর গেট পার হয়, digest নয়। Artifact সব environment-এ এক; config environment-ভেদে আলাদা, deploy-এর সময় আসে; secret আসে secret manager থেকে।

Rollback মানে পুরোনো digest আবার deploy; তাই retention-এ সেটি রক্ষা করুন, আর schema পুরোনো কোডের সাথে মানানসই কি না দেখুন।

নম্বর কোথায়: কারণ (২), promotion (১), পার্থক্য (১), rollback (১)। পর্ব ৫৮

যেখানে নম্বর কাটে: প্রতি environment-এ আলাদা build লেখা।

সংজ্ঞা: GitOps-এ Git-এ রাখা desired state-কে cluster-এর ভেতরের controller টেনে এনে মেলায়।

নীতি (OpenGitOps): declarative, versioned and immutable, pulled automatically, continuously reconciled.

ছবি: Developer → Git → controller (cluster-এর ভেতরে) → cluster, আর controller থেকে Git-এ টানার তীর।

Rollback: git revert, নতুন commit; controller মিলিয়ে নেয়।

Sync বনাম health: Sync মানে Git-এর সাথে মিল, health মানে সত্যিই কাজ করছে।

Trade-off: সবচেয়ে দামি চাবি হয়ে ওঠে Git-এর main. জরুরি অবস্থায় হাতের বদল নিজে থেকে মুছে যায়, তাই আগে sync suspend করুন। Secret Git-এ খোলা নয়।

উদাহরণ tool: Argo CD, Flux.

নম্বর কোথায়: সংজ্ঞা (১), চার নীতি (২), ছবি (১), তুলনা (২), rollback (১), trade-off (১)। পর্ব ৬০

যেখানে নম্বর কাটে: CI থেকে kubectl apply চালানোকেই GitOps বলা।

সংজ্ঞা: Deployment strategy ঠিক করে নতুন version কীভাবে, কত ভাগ ব্যবহারকারীর কাছে যায়। তিন মাপ: blast radius, ফেরার সময়, খরচ।

ছবি: চারটি ছোট traffic-এর বার, সময়ের সাথে ভাগ বদলাচ্ছে।

হিসাব: ক্ষতি = ভাগ × হার × ধরা পড়ার সময়। ১০০%-এ ১,০০০ × ৫ = ৫,০০০; ৫%-এ ০.০৫ × ৫,০০০ = ২৫০.

Deploy বনাম release: Feature flag দুটিকে আলাদা করে, তবে পুরোনো flag মুছতে হয়।

Database: expand → migrate → contract. প্রতি মুহূর্তে চলমান সব version কাজ করবে, অফেরতযোগ্য ধাপ সবার শেষে।

Trade-off: Replica ratio মোটা; ১% canary-তে ১০০টি Pod লাগে, তাই ঠিক ওজনে L7 routing নিন। Canary-তে নমুনা ছোট হলে সবুজ মানেই নিরাপদ নয়।

নম্বর কোথায়: সংজ্ঞা (১), টেবিল (৩), ছবি (১), হিসাব (২), database (২), trade-off (১)। পর্ব ৫৯

যেখানে নম্বর কাটে: Blue-green-কে ছোট blast radius বলা; schema-র কথা বাদ দেওয়া।

Secret scan commit-এর আগে, SCA ও SAST PR-এ, image scan build-এ, DAST staging-এ, সই যাচাই deploy-এ। SAST source পড়ে, DAST চলন্ত app পরীক্ষা করে।

OIDC-তে জমা key নেই: pipeline স্বল্পমেয়াদি token দিয়ে role নেয়। Trust policy-তে aud আর sub দিয়ে repository ও branch বাঁধুন, নইলে অন্য repository-র token-ও ঢুকতে পারে।

SLSA পথ বলে, সই পরিচয় বলে, SBOM উপকরণ বলে; কোনোটিই একা নিরাপত্তার নিশ্চয়তা নয়।

নম্বর কোথায়: ধাপ (২), OIDC (২), প্রমাণের সীমা (১)। পর্ব ৬১

যেখানে নম্বর কাটে: Scan থাকলেই নিরাপদ লেখা।

Monitoring জানা প্রশ্নের নজরদারি; observability বাইরের সংকেত থেকে অজানা সমস্যা বোঝার ক্ষমতা। সংজ্ঞায় একটু মতভেদ আছে।

Metric বলে কতটা, log বলে কী, trace বলে এই request-এর সময় কোথায় গেল।

RED (rate, errors, duration) service-এর চোখে; USE (utilisation, saturation, errors) resource-এর চোখে। Label-এ user id নয়: series হলো label-এর গুণফল।

নম্বর কোথায়: পার্থক্য (১), তিন সংকেত (২), RED ও USE (২)। পর্ব ৬৩ · পর্ব ৬৪ · পর্ব ৬৫

যেখানে নম্বর কাটে: তিনটিকে একই জিনিসের তিন নাম ভাবা।

সংজ্ঞা: SLI মাপ (ভালো ঘটনা ÷ বৈধ ঘটনা); SLO অভ্যন্তরীণ লক্ষ্য; SLA ফল-সহ চুক্তি। SLO সাধারণত SLA-র চেয়ে কড়া।

Error budget = ১ − SLO.

1. সময়ে: ০.০০১ × ৪৩,২০০ মিনিট = ৪৩.২ মিনিট.
2. অনুরোধে: ০.০০১ × ১২,০০,০০০ = ১,২০০টি.

ছবি: ৩০ দিনের নিচে নামা budget-এর রেখা, শূন্যে policy.

উদাহরণ: Checkout-এর SLI: সফল ও ৩০০ ms-এর মধ্যে সাড়া ÷ বৈধ অনুরোধ।

Policy: budget থাকলে দ্রুত release; ফুরালে নির্ভরযোগ্যতার কাজ আগে। এতে গতি আর স্থিতির তর্ক সংখ্যায় আসে।

Trade-off: ১০০% লক্ষ্য নয়: খরচ বাড়ে, পরিবর্তন থামে, আর ব্যবহারকারী পার্থক্য দেখেন না। SLI বাছুন ব্যবহারকারীর কাজ ধরে, CPU ধরে নয়।

নম্বর কোথায়: তিন সংজ্ঞা (৩), দুই হিসাব (২), policy (২), trade-off (১)। পর্ব ৭ · পর্ব ৬৬

যেখানে নম্বর কাটে: SLA আর SLO উল্টে লেখা; CPU-কে SLI বানানো।

Burn rate = error rate ÷ (১ − SLO) = ০.০০৩ ÷ ০.০০১ = ৩; ৩০ দিনের budget ৩০ ÷ ৩ = ১০ দিনে শেষ।

Burn ১৪.৪ এক ঘণ্টায় খায় ১৪.৪ × ১ ÷ ৭২০ = ২% budget. Workbook-এর সূচনা-সংখ্যা: ১ ঘণ্টায় ১৪.৪, ৬ ঘণ্টায় ৬, ৩ দিনে ১।

লম্বা জানালা ক্ষতি নিশ্চিত করে; ছোট জানালা সমস্যা মিটলে alert দ্রুত থামায়। Page হবে লক্ষণে, কারণের সংকেত dashboard-এ।

নম্বর কোথায়: সূত্র ও হিসাব (৩), জানালার যুক্তি (২)। পর্ব ৬৬

যেখানে নম্বর কাটে: Error rate-কে সরাসরি burn ধরা।

ধাপ: detect → triage → mitigate → resolve → learn. Severity আগে থেকে লিখে রাখুন, সন্দেহ হলে উঁচু ধরুন।

ছবি: সময়ের রেখায় শুরু, ধরা, স্বীকার, ক্ষতি থামা, সেবা ফেরা; নিচে MTTD, MTTA, MTTR-এর দাগ।

ভূমিকা: Commander পুরো ছবি দেখেন, কাজ ভাগ করেন, নিজে command চালান না; ops সমাধান চালান; comms খবর দেন; scribe সময়রেখা লেখেন।

নিয়ম: আগে ক্ষতি থামান: “কী বদলেছে?”, সম্ভব হলে rollback. ব্যতিক্রম নিরাপত্তা আর ডেটা নষ্টের ঘটনা, যেখানে প্রমাণ রাখা ও ডেটা বাঁচানো আগে।

Mitigation ক্ষতি থামায়; resolution সেবা স্থির করে ঘটনা বন্ধ করে; স্থায়ী সমাধান পরের কাজ।

Postmortem: blameless, সময়রেখা, প্রভাব, কারণ, কী কাজ করল, আর মালিক ও তারিখসহ কাজ। ভয় থাকলে তথ্য লুকায়, তাই মানুষ নয়, ব্যবস্থা দেখুন।

নম্বর কোথায়: ধাপ (২), ছবি (১), ভূমিকা (২), পার্থক্য (১), postmortem (২)। পর্ব ৬৭

যেখানে নম্বর কাটে: মূল কারণ খোঁজা আগে লেখা; দোষীর নাম খোঁজা।

ধাপ: steady state → hypothesis → blast radius ও abort → ব্যর্থতা ঢোকানো → মাপ → সমাধান → স্বয়ংক্রিয় করা।

Little: L = λW, স্থির সিস্টেমে। ৫০০ req/s আর ২০০ ms হলে L = ১০০.

N+1-এ সীমা = (z − ১) ÷ z = ২ ÷ ৩ = ৬৬.৭% নিরাপদ ক্ষমতার। ছাদের কাছে সামান্য চাপে latency লাফায়, তাই পরিকল্পনা knee-র নিচের সংখ্যায়।

নম্বর কোথায়: ধাপ (২), Little (১), zone-এর হিসাব (১)। পর্ব ৬৮

যেখানে নম্বর কাটে: Production-এ abort ছাড়া পরীক্ষা লেখা।

সংজ্ঞা: Function ঘটনায় চলে, init একবার, invoke অনেকবার; বিল = call + GB-second, সাথে gateway আর log.

হিসাব: Concurrency = rate × duration = ২০০ × ০.৫ = ১০০.

Reserved concurrency জায়গা আর ছাদ; provisioned concurrency আগে init করা environment, অলসেও বিল। Memory বাড়ালে CPU-ও বাড়ে, তাই বিল কমতেও পারে।

কখন নয়: দীর্ঘ কাজ, দিনরাত সমান উঁচু load, খুব কম ও স্থির latency.

উপসংহার: খরচের উত্তর traffic-এর আকৃতিতে, আর মানুষের সময়ও হিসাবে ধরুন।

নম্বর কোথায়: সংজ্ঞা (১), সুবিধা-সীমা (৩), হিসাব (১), দুই concurrency (১), কখন নয় (২)। পর্ব ১৯ · পর্ব ৬৯ · পর্ব ৭১

যেখানে নম্বর কাটে: Cold start-কে সবসময়ের সমস্যা বলা; “server নেই” লেখা।

Visibility timeout: receive-এর পরে বার্তা অন্যদের কাছে আড়ালে থাকে; delete না এলে আবার আসে। তাই আগে কাজ, পরে delete, আর duplicate ধরে নিন।

Dead-letter queue poison message আলাদা করে; সেখানে alarm রাখুন, কারণ সারিয়ে ধীরে redrive করুন।

Idempotency handler-এর গুণ; exactly-once delivery-র দাবি, যা সাধারণ network-এ নিশ্চিত করা যায় না। উত্তর conditional write, আর key ও আসল কাজ একই transaction-এ।

নম্বর কোথায়: তিন ধারণা (৩), পার্থক্য (২)। পর্ব ৭০ · পর্ব ৭১

যেখানে নম্বর কাটে: Read-then-write দিয়ে duplicate আটকানো লেখা।

সংজ্ঞা: FinOps খরচ কাটার অভিযান নয়; প্রকৌশল, অর্থ আর ব্যবসা দল একসাথে প্রতিটি খরচের মালিক ও কারণ ঠিক করার অভ্যাস।

লুপ: Inform (দেখা ও ভাগ করা) → Optimize (কমানো) → Operate (নিয়মে আনা), চলমান চক্র।

Showback শুধু দেখায়; chargeback দলের বাজেট থেকে কাটে। Showback আগে, chargeback তথ্য পরিণত হলে। ভিত্তি tag আর cost allocation.

ক্রম: বিল = ব্যবহার × দর। আগে অপচয় মোছা ও rightsizing, তারপর commitment.

হিসাব:

1. আগে: ১০,০০০ ÷ ২০,০০,০০০ = $০.০০৫ প্রতি অর্ডার।
2. পরে: ১৫,০০০ ÷ ৪০,০০,০০০ = $০.০০৩৭৫ প্রতি অর্ডার, ২৫% কম।

মানে: বিল ৫০% বাড়লেও unit cost কমেছে; এটি বৃদ্ধির স্বাভাবিক দাম।

Trade-off: নিরাপত্তার সারি কাটবেন না, log আর backup-এর দাম কমানোর আগে ঝুঁকি দেখুন।

নম্বর কোথায়: সংজ্ঞা (১), লুপ (২), দুই শব্দ (১), ক্রম (১), হিসাব (২), মানে (১)। পর্ব ৭৩

যেখানে নম্বর কাটে: FinOps-কে শুধু অর্থ বিভাগের কাজ বলা; মোট বিল দেখে সিদ্ধান্ত।

Break-even utilisation = ১ − d = ১ − ০.৪০ = ৬০%. অঙ্গীকার নিন baseline-এর মাপে, peak-এর মাপে নয়।

নম্বর কোথায়: টেবিল (৩), হিসাব (১), নিয়ম (১)। পর্ব ৭২

যেখানে নম্বর কাটে: Peak-এর মাপে কেনা; spot-এ একমাত্র database রাখা।

সংজ্ঞা: Well-Architected প্রশ্নের কাঠামো, পরীক্ষার নম্বর নয়। AWS ছয়টি স্তম্ভ ধরে; Azure আর Google-এর তালিকাও প্রায় একই।

1. Operational excellence: চালানো, শেখা, ছোট বদল।
2. Security: পরিচয়, ডেটা, ধরা পড়া।
3. Reliability: ব্যর্থতা থেকে সেরে ওঠা।
4. Performance efficiency: কাজের মাপে resource.
5. Cost optimization: অপচয় ছাড়া মূল্য।
6. Sustainability: কম শক্তিতে একই কাজ (২০২১ সালের শেষে যোগ হয়)।

Review-এর ফল: ঝুঁকির ক্রমে সাজানো কাজ, মালিকসহ; নম্বর নয়। প্রমাণ চান, মহড়ায় যাচাই করুন।

Trade-off: Multi-AZ-এ reliability বাড়ে, cost বাড়ে। Encryption-এর ধাপ security বাড়ায়, সামান্য latency আনে। কারণটি ADR-এ লিখে রাখুন।

উপসংহার: আগে multi-AZ, তারপর হিসাব করে অন্য region. Copy বাড়লেও খারাপ deploy সব copy-তে একসাথে লাগে।

নম্বর কোথায়: সংজ্ঞা (১), ছয় স্তম্ভ (৩), review (২), trade-off (২)। পর্ব ৭৪

যেখানে নম্বর কাটে: Security আর cost-কে একমাত্র স্তম্ভ ভাবা; review-কে পাস-ফেল ভাবা।

সংজ্ঞা: প্রতি app-এ একটি পথ। ২০১০-এর দিকে Gartner-এর 5R-এর পরে ২০১৬-র দিকে AWS-এর একটি লেখায় 6R ছড়ায়; পরে relocate যোগ হয়ে 7R. একই শব্দের অর্থ কাঠামো-ভেদে আলাদা হতে পারে।

হিসাব: সময় = আকার × ৮ ÷ (গতি × e) = ১০ × ১০¹² × ৮ ÷ (১০⁸ × ০.৮) = ১০⁶ সেকেন্ড ≈ ১১.৫৭ দিন. পরিবর্তন চলতে থাকলে আরও বেশি।

Cutover: TTL আগে কমানো → snapshot → CDC → সংক্ষিপ্ত read-only → যাচাই → sequence ঠিক করা → reverse replication → দিক বদল। ফেরার শর্ত আগে লেখা।

Trade-off: Rehost দ্রুত, কিন্তু পুরোনো সমস্যা সাথে আসে। Chatty app ভাগ করলে প্রতি query-তে RTT যোগ হয়, তাই একসাথে সরান। আগে retire খুঁজুন; না যাওয়াও সঠিক সিদ্ধান্ত হতে পারে।

নম্বর কোথায়: সংজ্ঞা (১), ছয়টি পথ (৩), relocate (১), হিসাব (২), cutover (২), trade-off (১)। পর্ব ৭৫

যেখানে নম্বর কাটে: Rehost আর replatform গুলিয়ে ফেলা; bit-byte না বদলানো; সব app-এ একই পথ লেখা।

পাঁচ বৈশিষ্ট্য, তিন service model, চার deployment model. পর্ব ১

গ্রাহকের; hypervisor আর হার্ডওয়্যার provider-এর। পর্ব ২

না; ভুল মোছা replica-তেও যায়, backup আলাদা ও সময়ভিত্তিক। পর্ব ২

প্রথমটি ডেটা কোথায় রাখা, দ্বিতীয়টি ডেটার ওপর কার আইন খাটে। পর্ব ৩ · পর্ব ৫

না, শুধু জানায়; থামাতে আলাদা ব্যবস্থা লাগে। পর্ব ৬

হাতে করা, বারবারের, automate করা যায়, স্থায়ী মূল্যহীন কাজ, যা service-এর সাথে বাড়ে। পর্ব ৭

Owner rwx, group ও other r-x. পর্ব ৮

শুধু stdout; stderr নয়। পর্ব ৯

ব্যর্থ command আর অজানা variable-এ থামে, pipeline-এর মাঝের ব্যর্থতাও ধরে। পর্ব ১০

প্রথমটি client-এ server চেনার জন্য, দ্বিতীয়টি server-এ user চেনার জন্য। পর্ব ১২

CPU credit ফুরিয়েছে, তাই CPU baseline-এ নেমেছে। পর্ব ১৫

ডেটা টিকে থাকা বনাম এখন পাওয়া। পর্ব ২০

Delete marker বসে, ডেটা থাকে, পুরোনো version-এর ভাড়াও চলে। পর্ব ২১

২৫৬ − ৫ = ২৫১টি। পর্ব ২৫

না; ঠিকানা মিললে route ঠিক করা যায় না। পর্ব ২৫ · পর্ব ২৮

Security group-এ deny নেই, তাই NACL-এ ছোট নম্বরের deny বা WAF. পর্ব ২৭

CNAME-এর পাশে অন্য record চলে না, অথচ apex-এ SOA আর NS লাগে। পর্ব ২৯

Miss ১০% থেকে ৫%, অর্থাৎ অর্ধেক। পর্ব ৩০

Explicit Deny জেতে, statement-এর ক্রম যাই হোক। পর্ব ৩২

History মোছা নয়; key বাতিল ও বদল, তারপর log দেখা। পর্ব ৩৩

RUN build-এ চলে আর layer বানায়; CMD চালুর সময় চলে, শুধু config-এ থাকে। পর্ব ৩৭

না, শুধু SIGKILL; OOM কি না তা OOMKilled ঘর বলে। পর্ব ৩৯

প্রথমটি container আর network মোছে, দ্বিতীয়টি named volume-ও মোছে। পর্ব ৪০

ReplicaSet সংখ্যা মেলায়; স্থায়ীভাবে কমাতে replicas বদলাতে হবে। পর্ব ৪২

না; রক্ষা করে etcd encryption, RBAC আর বাইরের secret manager. পর্ব ৪৭

সম্ভবত CNI plugin সেটি প্রয়োগ করে না; নিষিদ্ধ সংযোগ চেষ্টা করে যাচাই করতে হবে। পর্ব ৪৯

নতুন একটি সংখ্যা; ইতিহাস পিছিয়ে যায় না। পর্ব ৫০

না, শুধু provider; module পিন করতে version বা ref. পর্ব ৫৪

পরিচয় স্থায়ী key, তাই মাঝের item মুছলে বাকিরা নড়ে না। পর্ব ৫২

Cache গতির জন্য, না থাকলেও ফল এক; artifact ফল হস্তান্তর করে। পর্ব ৫৭

সমর্থিত, সবচেয়ে সহজ, নিরাপদ পথ, যা ঐচ্ছিক থাকে। পর্ব ৬২

Counter শুধু বাড়ে আর reset হয়, gauge ওঠে-নামে। পর্ব ৬৩

প্রতিটি মান নতুন stream বানায়, এটি high cardinality. পর্ব ৬৪

Head শুরুতে ফল না জেনে, tail শেষে ফল দেখে সিদ্ধান্ত নেয়। পর্ব ৬৫

১০০ ÷ ১০১ ≈ ৯৯.০১%. পর্ব ৬৭

L = λW; ৫০০ req/s, ২০০ ms হলে L = ১০০. পর্ব ৬৮

Reserved জায়গা ও ছাদ; provisioned আগে init করা environment, অলসেও বিল। পর্ব ৬৯

Rightsizing ও অপচয় বন্ধ, কারণ আগে ব্যবহার, পরে দর। পর্ব ৭৩

Correlated failure: খারাপ deploy বা ভুল config সব copy-তে একসাথে লাগে। পর্ব ৭৪

কোন code চলছে জানা যায় না, rollback-ও অনিশ্চিত হয়। পর্ব ৭৬