কোন DevOps প্রকৌশলী নেই. কে তাহলে বিদ্যমান, এবং এটা দিয়ে কি করতে হবে?

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

এই পোস্টে আমি কীভাবে আমরা জীবনের এই মুহুর্তে এসেছি, DevOps আসলে কী এবং এখন এটির সাথে কী করতে হবে সে সম্পর্কে কিছু কথা বলতে চাই।

এই ধরনের শূন্যপদগুলিকে প্রতিটি সম্ভাব্য উপায়ে নিন্দা করা যেতে পারে, তবে সত্যটি রয়ে গেছে: তাদের মধ্যে অনেকগুলি রয়েছে এবং এই মুহুর্তে বাজারটি এভাবেই কাজ করে। আমরা একটি ডেভপস সম্মেলন করেছি এবং প্রকাশ্যে ঘোষণা করেছি: "DevOops - DevOps ইঞ্জিনিয়ারদের জন্য নয়।" এটি অনেকের কাছে অদ্ভুত এবং বন্য বলে মনে হবে: কেন যারা সম্পূর্ণ বাণিজ্যিক ইভেন্ট করছেন তারা বাজারের বিরুদ্ধে যান। এখন আমরা সবকিছু ব্যাখ্যা করব।

সংস্কৃতি এবং প্রক্রিয়া সম্পর্কে

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

উদাহরণস্বরূপ, একটি সিস্টেম অ্যাডমিনিস্ট্রেটর এবং পরিষেবা পরিচালনার জন্য একটি SRE পদ্ধতির মধ্যে পার্থক্য বর্ণনা করা বিখ্যাত Google SRE বই শুরু হয়. মধ্যে আকর্ষণীয় গবেষণা করা হয়েছে DORA জরিপ — এটা স্পষ্ট যে সেরা ডেভেলপাররা কোনো না কোনোভাবে প্রতি ঘণ্টায় একবারের চেয়ে দ্রুত উৎপাদনে নতুন পরিবর্তন আনতে পারে। তারা তাদের হাত দিয়ে 10% এর বেশি পরীক্ষা করে না (এটি থেকে দেখা যায় গত বছরের DORA) তাঁরা কীভাবে এটি করে? প্রতিবেদনের শিরোনামগুলির মধ্যে একটি বলে "এক্সেল বা ডাই"। পরীক্ষার প্রসঙ্গে এই পরিসংখ্যানগুলির বিশদ আলোচনার জন্য, আপনি বারুচ সদোগুরস্কির মূল বক্তব্যটি উল্লেখ করতে পারেন “আমাদের DevOps আছে। আসুন সকল পরীক্ষার্থীদের বরখাস্ত করি।" আমাদের অন্য সম্মেলনে, হাইজেনবাগ।

"যখন কমরেডদের মধ্যে কোন চুক্তি হয় না,
তাদের ব্যবসা ভালো যাবে না,
এবং তার থেকে কিছুই বের হবে না, শুধুমাত্র ময়দা।
এক সময় একটি রাজহাঁস, একটি ক্রেফিশ এবং একটি পাইক ..."

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

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

দুষ্ট চক্র

"devops ইঞ্জিনিয়ারিং" এর শৃঙ্খলা তখন কোথা থেকে এল? আমরা একটি সংস্করণ আছে! DevOps ধারনাগুলি ভাল ছিল-এতই ভাল যে তারা তাদের নিজস্ব সাফল্যের শিকার হয়েছিল। কিছু ছায়াময় নিয়োগকারী এবং মানব পাচারকারী, যাদের নিজস্ব পরিবেশ রয়েছে, এই পুরো বিষয়টিকে ঘিরে ঘুরতে শুরু করেছে।

কল্পনা করুন: গতকাল আপনি খিমকিতে শাওয়ারমা তৈরি করছেন, এবং আজ আপনি ইতিমধ্যে একজন বড় লোক, একজন সিনিয়র নিয়োগকারী। প্রার্থীদের অনুসন্ধান এবং নির্বাচন করার একটি সম্পূর্ণ প্রক্রিয়া রয়েছে, সবকিছু সহজ নয়, আপনাকে বুঝতে হবে। ধরা যাক একটি বিভাগের প্রধান বলেছেন: X-এ একজন বিশেষজ্ঞ খুঁজুন। আমরা X-কে "ইঞ্জিনিয়ার" শব্দটি বরাদ্দ করি, এবং আমাদের কাজ শেষ। লিনাক্স প্রয়োজন? ঠিক আছে, এটি অবশ্যই একজন লিনাক্স ইঞ্জিনিয়ার, আপনি যদি DevOps চান তবে একজন DevOps ইঞ্জিনিয়ার। খালি পদটি শুধুমাত্র একটি শিরোনাম নয়, কিছু পাঠ্যও ভিতরে প্রবেশ করতে হবে। আপনার কল্পনার উপর নির্ভর করে Google থেকে কীওয়ার্ডের একটি সেট প্রবেশ করানো সবচেয়ে সহজ উপায়। DevOps দুটি শব্দ নিয়ে গঠিত - "Dev" এবং "Ops", যার মানে হল যে আমাদের ডেভেলপার এবং অ্যাডমিনিস্ট্রেটরদের সাথে সম্পর্কিত কীওয়ার্ডগুলিকে একত্রে আঠালো করতে হবে, সবগুলোকে এক গাদা করে দিতে হবে। এভাবেই 42টি প্রোগ্রামিং ল্যাঙ্গুয়েজ এবং কুবারনেটস এবং সোয়ার্ম একসাথে ব্যবহার করার 20 বছরের দক্ষতা সম্পর্কে শূন্যপদগুলি উপস্থিত হয়। ওয়ার্কিং ডায়াগ্রাম।

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

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

তাই আমাদের চাহিদা ও সরবরাহ আছে। একটি দুষ্ট বৃত্ত যা নিজেকে খাওয়ায়। এটির বিরুদ্ধে আমরা লড়াই করছি (যার মধ্যে DevOops সম্মেলন তৈরি করে)।

অবশ্যই, সিস্টেম অ্যাডমিনিস্ট্রেটরদের পাশাপাশি যারা নিজেদের "devops" নামকরণ করেছেন, সেখানে অন্যান্য অংশগ্রহণকারীরা রয়েছে - উদাহরণস্বরূপ, পেশাদার SREs বা অবকাঠামো-এ-কোড বিকাশকারীরা।

DevOps-এ লোকেরা কী করে (সত্যিই)

তাই আপনি DevOps অনুশীলন শিখতে এবং প্রয়োগ করতে এগিয়ে যেতে চান। কিন্তু এটা কিভাবে করবেন, কোন দিকে তাকাবেন? স্পষ্টতই, আপনার জনপ্রিয় কীওয়ার্ডগুলির উপর অন্ধভাবে নির্ভর করা উচিত নয়।

চাকরি থাকলে কাউকে করতে হবে। আমরা ইতিমধ্যে জানতে পেরেছি যে এরা "ডেপস ইঞ্জিনিয়ার" নয়, তাহলে কারা? এটি অবস্থানের ক্ষেত্রে নয়, কাজের নির্দিষ্ট ক্ষেত্রের পরিপ্রেক্ষিতে এটি প্রণয়ন করা আরও সঠিক বলে মনে হয়।

প্রথমত, আপনি DevOps-প্রক্রিয়া এবং সংস্কৃতির হৃদয়কে সম্বোধন করতে পারেন। সংস্কৃতি একটি ধীর এবং কঠিন ব্যবসা, এবং যদিও এটি ঐতিহ্যগতভাবে পরিচালকদের দায়িত্ব, প্রোগ্রামার থেকে প্রশাসক পর্যন্ত প্রত্যেকেই কোনও না কোনও উপায়ে জড়িত। মাস দুয়েক আগে টিম লিস্টার একটি সাক্ষাৎকারে বলেছেন:

“সংস্কৃতি সংগঠনের মূল মূল্যবোধ দ্বারা নির্ধারিত হয়। সাধারণত লোকেরা এটি লক্ষ্য করে না, তবে বহু বছর ধরে পরামর্শে কাজ করার পরে আমরা এটি লক্ষ্য করতে অভ্যস্ত। আপনি একটি কোম্পানিতে প্রবেশ করেন এবং আক্ষরিকভাবে কয়েক মিনিটের মধ্যে আপনি কী ঘটছে তা অনুভব করতে শুরু করেন। আমরা একে "গন্ধ" বলি। কখনও কখনও এই ঘ্রাণ সত্যিই ভাল. কখনও কখনও এটি বমি বমি ভাব সৃষ্টি করে। (...) আপনি একটি সংস্কৃতি পরিবর্তন করতে পারবেন না যতক্ষণ না নির্দিষ্ট কর্মের পিছনে মূল্যবোধ এবং বিশ্বাসগুলি বোঝা যায়। আচরণ পর্যবেক্ষণ করা সহজ, কিন্তু বিশ্বাস অনুসন্ধান করা কঠিন। কীভাবে জিনিসগুলি আরও জটিল হয়ে উঠছে তার একটি দুর্দান্ত উদাহরণ হল DevOps।"

অবশ্যই সমস্যাটির একটি প্রযুক্তিগত অংশ রয়েছে। যদি আপনার নতুন কোডটি এক মাসের মধ্যে পরীক্ষা করা হয়, কিন্তু মাত্র এক বছর পরে প্রকাশিত হয়, এবং এটির গতি বাড়ানো শারীরিকভাবে অসম্ভব, আপনি ভাল অনুশীলনগুলি মেনে চলতে পারবেন না। ভাল অনুশীলন ভাল সরঞ্জাম দ্বারা সমর্থিত হয়. উদাহরণস্বরূপ, ইনফ্রাস্ট্রাকচার-এজ-কোডের ধারণা মাথায় রেখে, আপনি AWS CloudFormation এবং Terraform থেকে Chef-Ansible-Puppet পর্যন্ত যেকোনো কিছু ব্যবহার করতে পারেন। আপনাকে জানতে হবে এবং এই সব করতে সক্ষম হতে হবে এবং এটি ইতিমধ্যেই বেশ একটি ইঞ্জিনিয়ারিং শৃঙ্খলা। কারণকে প্রভাবের সাথে বিভ্রান্ত না করা গুরুত্বপূর্ণ: প্রথমে আপনি SRE-এর নীতি অনুসারে কাজ করুন এবং শুধুমাত্র তারপর কিছু নির্দিষ্ট প্রযুক্তিগত সমাধানের আকারে এই নীতিগুলি বাস্তবায়ন করুন। একই সময়ে, এসআরই একটি অত্যন্ত ব্যাপক পদ্ধতি যা আপনাকে জেনকিন্স কীভাবে সেট আপ করতে হয় তা জানায় না, তবে প্রায় পাঁচটি মৌলিক নীতি:

• ভূমিকা এবং বিভাগের মধ্যে উন্নত যোগাযোগ
• কাজের একটি অবিচ্ছেদ্য অংশ হিসাবে ভুল স্বীকার
• ধীরে ধীরে পরিবর্তন করা
• টুলিং এবং অন্যান্য অটোমেশন ব্যবহার করে
• পরিমাপ করা যায় সবকিছু পরিমাপ করা

এটি কেবল কিছু বিবৃতি নয়, একটি নির্দিষ্ট কর্মের নির্দেশিকা. উদাহরণস্বরূপ, ত্রুটিগুলি গ্রহণ করার পথে, আপনাকে ঝুঁকিগুলি বুঝতে হবে, SLI (পরিষেবা স্তরের সূচক) এবং SLO (সেবা স্তরের উদ্দেশ্য), পোস্টমর্টেম লিখতে শিখুন এবং সেগুলিকে ভীতিকর না করে লিখতে শিখুন।

এসআরই শৃঙ্খলায়, সরঞ্জামের ব্যবহার সাফল্যের শুধুমাত্র একটি অংশ, যদিও এটি একটি গুরুত্বপূর্ণ। আমাদের ক্রমাগত প্রযুক্তিগতভাবে বিকাশ করতে হবে, বিশ্বে কী ঘটছে এবং কীভাবে এটি আমাদের কাজে প্রয়োগ করা যেতে পারে তা দেখতে হবে।

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

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

এই সব দিয়ে কি করবেন

প্রত্যেকে তাদের নিজস্ব উপায়ে এই সমস্যাগুলি সমাধান করে: উদাহরণস্বরূপ, আপনি দুষ্ট বৃত্ত ভাঙতে সাধারণ শূন্যপদ প্রকাশ করতে পারেন। আপনি DevOps এবং ক্লাউড নেটিভ এর মত শব্দের অর্থ কী তা খুঁজে বের করতে পারেন এবং সেগুলি সঠিকভাবে ব্যবহার করতে পারেন। আপনি DevOps-এ বিকাশ করতে পারেন এবং আপনার উদাহরণ দ্বারা সঠিক পন্থা প্রদর্শন করতে পারেন।

আমরা একটি সম্মেলন করছি DevOops 2020 মস্কো, যা আমরা এইমাত্র যে বিষয়গুলি নিয়ে কথা বলেছি তার গভীরে অনুসন্ধান করার সুযোগ দেয়৷ এই জন্য রিপোর্টের বিভিন্ন গ্রুপ আছে:

• প্রক্রিয়া এবং সংস্কৃতি;
• সাইট নির্ভরযোগ্যতা প্রকৌশল;
• ক্লাউড নেটিভ;

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

স্পষ্টতই, কনফারেন্সে আপনি একবারে তিনটি ট্র্যাকে যেতে পারবেন না, তাই আমরা প্রোগ্রামটি এমনভাবে সংগঠিত করি যাতে প্রতিটি সময় স্লটে প্রতিটি স্বাদের জন্য বিষয় থাকে।

আপনি একটি DevOps প্রকৌশলী হলে কি করতে হবে তা বুঝতে বাকি আছে! প্রথমত, আপনি আসলে কি করেন তা নির্ধারণ করার চেষ্টা করুন। সাধারণত তারা এই শব্দটিকে কল করতে পছন্দ করে:

• বিকাশকারীরা যারা অবকাঠামো নিয়ে কাজ করে। SRE এবং ক্লাউড নেটিভ সম্পর্কে রিপোর্টের গ্রুপগুলি আপনার জন্য সবচেয়ে উপযুক্ত।
• সিস্টেম অ্যাডমিনিস্ট্রেটর। এটা এখানে আরো জটিল. DevOops সিস্টেম প্রশাসন সম্পর্কে নয়। সৌভাগ্যবশত, সিস্টেম অ্যাডমিনিস্ট্রেশনের বিষয়ে প্রচুর চমৎকার সম্মেলন, বই, নিবন্ধ, ইন্টারনেটে ভিডিও ইত্যাদি রয়েছে। অন্যদিকে, আপনি যদি সংস্কৃতি এবং প্রক্রিয়াগুলি বোঝার ক্ষেত্রে, ক্লাউড টেকনোলজি এবং ক্লাউড নেটিভের সাথে জীবনের বিবরণ সম্পর্কে শেখার ক্ষেত্রে নিজেকে বিকাশ করতে আগ্রহী হন, তাহলে আমরা আপনাকে দেখে খুশি হব! এই ভেবে দেখুন: আপনি প্রশাসন করছেন, তারপর আপনি কি করবেন? হঠাৎ একটি অপ্রীতিকর পরিস্থিতিতে নিজেকে খুঁজে পাওয়া এড়াতে, আপনার এখনই শিখতে হবে।

আরেকটি বিকল্প আছে: আপনি অবিরত থাকুন এবং দাবি করতে থাকুন যে আপনিই বিশেষ করে একজন DevOps ইঞ্জিনিয়ার এবং অন্য কিছু না, যাই হোক না কেন মানে. তাহলে আমাদের আপনাকে হতাশ করতে হবে, DevOops DevOps ইঞ্জিনিয়ারদের জন্য একটি সম্মেলন নয়!

থেকে স্লাইড কনস্ট্যান্টিন ডিনারের প্রতিবেদন মিউনিখে

DevOops 2020 মস্কো 29-30 এপ্রিল মস্কোতে অনুষ্ঠিত হবে, টিকিট ইতিমধ্যে উপলব্ধ রয়েছে অফিসিয়াল ওয়েবসাইটে ক্রয় করুন.

বিকল্পভাবে, আপনি পারেন আপনার রিপোর্ট জমা দিন 8 ফেব্রুয়ারি পর্যন্ত। অনুগ্রহ করে মনে রাখবেন যে ফর্মটি পূরণ করার সময়, আপনাকে অবশ্যই লক্ষ্য শ্রোতা নির্বাচন করতে হবে যারা আপনার প্রতিবেদন থেকে সর্বাধিক উপকৃত হবে (তালিকার ভিতরে একটি চমক পুঁতে আছে).

উত্স: www.habr.com