২৯ সেপ, ২০২৫·5 মিনিট
ওয়ার্নার ভোগেলসের 'তুমি বানাও, তুমি চালাও' ব্যাখ্যা
জানুন ওয়ার্নার ভোগেলস ‘তুমি বানাও, তুমি চালাও’ বলতে কী বোঝাতে চেয়েছিলেন এবং এটি কীভাবে ব্যবহার করবেন: মালিকানা, অন-কল, SLO, ইনসিডেন্ট রেসপন্স এবং নিরাপদ রিলিজ।
জানুন ওয়ার্নার ভোগেলস ‘তুমি বানাও, তুমি চালাও’ বলতে কী বোঝাতে চেয়েছিলেন এবং এটি কীভাবে ব্যবহার করবেন: মালিকানা, অন-কল, SLO, ইনসিডেন্ট রেসপন্স এবং নিরাপদ রিলিজ।
“তুমি বানাও, তুমি চালাও” এমন একটা বাক্য যা টিকিয়ে থাকে কারণ এটা সরাসরি। এটা মোটিভেশন পোস্টারের কথা নয় বা ‘আরও DevOps হওয়া’ নয়। এটা দায়িত্ব সম্পর্কে একটি স্পষ্ট বিবৃতি: যে টিম কোনো সার্ভিস শিপ করে, সেই টিমই প্রোডাকশনে সেই সার্ভিস কেমন আচরণ করে তার জন্যও accountable থাকে।
প্র্যাকটিক্যালি, এর মানে যে প্রোডাক্ট টিমটি ফিচার ডিজাইন করে এবং কোড লেখে, সেই একই টিম:
এটার মানে সবাই হঠাৎ ইনফ্রা এক্সপার্ট হয়ে যাবে না। বরং ফিডব্যাক লুপ বাস্তব: যদি তুমি এমন কিছু রিলিজ করো যা আউটেজ, পেজার নয়েজ বা কাস্টমার কষ্ট বাড়ায়, তোমার টিম তা সরাসরি অনুভব করবে—এবং দ্রুত শিখবে।
এই দর্শনটা বলা সহজ কিন্তু বাস্তবে আনা কঠিন যদি না তুমি এটাকে একটি অপারেটিং মডেল হিসেবে স্পষ্ট প্রত্যাশাসহ নাও। “চালাও” সাধারণত অন-কল থাকা (কোনো না কোনো রূপে), ইনসিডেন্ট রেসপন্সে মালিকানা, রানবুক লেখা, ড্যাশবোর্ড রক্ষণাবেক্ষণ এবং সার্ভিস ধারাবাহিকভাবে উন্নত করার কাজগুলো অন্তর্ভুক্ত করে।
এটা কনস্ট্রেইন্টও ধারণ করে: তুমি টিমকে “চালাতে” বলতে পারো না যদি না তাদের কাছে সমস্যা ঠিক করার টুল, অ্যাক্সেস ও কর্তৃত্ব থাকে—এবং রোডম্যাপে সে কাজ করার সময়ও না থাকে।
“তুমি বানাও, তুমি চালাও” এর আগে অনেক কোম্পানি সফটওয়্যার কাজকে রিলে রেস হিসেবে সাজাতো: ডেভেলপাররা কোড লিখে, তারপর সেটি অপস টিমকে ‘ওভার দ্য ওয়াল’ ছুঁড়ে দিতো যাতে তারা ডিপ্লয় ও চালায়।
হ্যান্ডঅফটা একটি স্বল্প-মেয়াদি সমস্যা সমাধান করে—কেউ ছিল অভিজ্ঞ যারা প্রোডাকশন দেখছে—কিন্তু সেটা বড় সমস্যা তৈরি করে।
যদি আলাদা অপস টিম প্রোডাকশন নিজে চালায়, ডেভেলপাররা প্রায়ই সমস্যা দেরিতে (বা কখনোই) জানে। একটা বাগ সারাদিন পর একটি অস্পষ্ট টিকিট হিসেবে আসতে পারে: “সার্ভিস স্লো” বা “CPU বেশি।” তখন প্রসঙ্গ হারায়, লগ রোটেট হয়ে গেছে, এবং পরিবর্তন করা লোকটি চলে গেছে।
হ্যান্ডঅফ মালিকানাও অস্পষ্ট করে দেয়। আউটেজ হলে ডেভেলপার ভাবতে পারে “অপস দেখে নেবে,” আর অপস ভাবতে পারে “ডেভ শিপ করেছে ঝুঁকিপূর্ণ কিছু।” ফলাফল পূর্বানুমিত: দীর্ঘ ইনসিডেন্ট রেজলিউশন, বারবার হওয়া ব্যর্থতা মোড, এবং এমন একটি সংস্কৃতি যেখানে টিমগুলো স্থানীয়ভাবে অপ্টিমাইজ করে গ্রাহক অভিজ্ঞতার জন্য নয়।
“তুমি বানাও, তুমি চালাও” লুপটাকে সঙ্কুচিত করে। যে টিম চেঞ্জ শিপ করে, সেটাই প্রোডাকশনে কেমন আচরণ করে তার দায়বদ্ধ। সেটা নিম্নোক্ত বাস্তব পরিবর্তনকে অনুপ্রাণিত করে: পরিষ্কার অ্যালার্ট, নিরাপদ রোলআউট, ভাল ড্যাশবোর্ড, এবং এমন কোড যা অপারেট করা সহজ।
বিপরীতমুখীভাবে, এটা প্রায়ই দ্রুত ডেলিভারির দিকে নিয়ে যায়। যখন টিমগুলো তাদের রিলিজ প্রসেসে বিশ্বাস রাখে এবং প্রোডাকশন আচরণ বুঝে, তারা ছোট পরিবর্তনগুলো বেশি ঘন ঘন শিপ করতে পারে—এর ফলে ভুলের ব্লাস্ট রেডিয়াস কমে এবং সমস্যা ডায়াগনোস করা সহজ হয়।
সব প্রতিষ্ঠান সমান স্টাফিং, কমপ্লায়েন্স চাহিদা বা লেগ্যাসি সিস্টেম দিয়ে শুরু করে না। এই দর্শনটা একটি দিকনির্দেশ, স্ইচ নয়। অনেক টিম ধীরে ধীরে গ্রহণ করে—শেয়ারড অন-কল দিয়ে শুরু করে, betere observability, এবং পরিষ্কার সার্ভিস সীমানা—তারপর পূর্ণ এন্ড-টু-এন্ড মালিকানায় যায়।
ওয়ার্নার ভোগেলস, অ্যামাজনের CTO, ‘You build it, you run it’ বাক্যটি প্রসারিত করেছেন বলতে যে কিভাবে অ্যামাজন (এবং পরে AWS) টিমগুলোকে সফটওয়্যারকে একটি প্রোজেক্ট হিসেবে নয় বরং একটি সার্ভিস হিসেবে ভাবতে চেয়েছিল।
মূল পরিবর্তনটি প্রযুক্তিগত হওয়ার চেয়ে মনস্তাত্ত্বিকও ছিল। যখন একটি টিম জানে তাদেরকে ফেইলিউরের জন্য পেজ করা হবে, তখন ডিজাইন সিদ্ধান্ত বদলে যায়। তুমি সচেতন হও যে ভালো ডিফল্ট, পরিষ্কার অ্যালার্টিং, গ্রেসফুল ডিগ্রেডেশন এবং এমন ডিপ্লয় পথ দরকার যা রোলব্যাক করা যায়। অর্থাৎ, বিল্ডিংয়ে জীবনের ঝামেলা পরিকল্পনার অংশ।
AWS-যুগের সার্ভিস চিন্তা নির্ভরযোগ্যতা এবং গতিকে অপরিহার্য করেছে। ক্লাউড কাস্টমাররা প্রত্যাশা করে API ঘন্টা-রাউন্ড উপলব্ধ থাকবে, এবং তারা প্রত্যাশা করে উন্নতি ধারাবাহিকভাবে আসবে—ত্রৈমাসিক বড় রিলিজ নয়।
সে চাপ উৎসাহিত করেছে:
এই দর্শনটি বৃহত্তর DevOps আন্দোলনের সঙ্গে অছিবদ্ধ: ডিভ এবং অপসের গ্যাপ বন্ধ করা, হ্যান্ডঅফ কমানো, এবং আউটকাম (অ্যাভেইলেবিলিটি, লেটেন্সি, সাপোর্ট লোড) ডেভেলপমেন্ট লুপের অংশ করা। এটা ছোট স্বায়ত্তশাসিত টিমের সঙ্গে সঙ্গতিপূর্ণ যা স্বাধীনভাবে শিপ করতে পারে।
অ্যামাজনের পদ্ধতিটা কপি করার টেমপ্লেট হিসেবে দেখা লোভনীয়, কিন্তু “তুমি বানাও, তুমি চালাও” একটি দিকনির্দেশ—কঠোর অর্গ চার্ট নয়। তোমার টিম সাইজ, রেগুলেটরি কন্ডিশন, প্রোডাক্ট ম্যাচুরিটি, এবং আপটাইম প্রয়োজনীয়তা অনুযায়ী অভিযোজন দরকার হবে—শেয়ারড অন-কল, প্ল্যাটফর্ম সাপোর্ট, বা ধাপে-ধাপে গ্রহণ ইত্যাদি।
প্র্যাকটিক্যাল অনুবাদ জানতে চান? জাম্প করুন /blog/how-to-adopt-you-build-it-you-run-it-step-by-step।
“তুমি বানাও, তুমি চালাও” আসলে মালিকানা সম্পর্কে একটি বিবৃতি। যদি তোমার টিম কোনো সার্ভিস শিপ করে, তোমার টিম বাস্তব জগতে সেই সার্ভিস কেমন আচরণ করে তার দায় নেবে—শুধু রিলিজ ডে-র টেস্ট পাস করা নয়।
সার্ভিস চালানো মানে পুরো-শেষ পর্যন্ত আউটকাম নিয়ে চিন্তা করা:
সাধারণ সপ্তাহে “চালাও” হিরোইকসের চেয়ে রুটিন অপারেশনের দিকে বেশি।
এই মডেল কাজ করে শুধুমাত্র যখন দায়বদ্ধতা মানে “আমরা ফিক্স নেব”, না যে “আমরা কাউকে সাজা দেব।” যখন কিছু ভেঙে যায়, লক্ষ্য হলো বুঝা যে সিস্টেমে কি ছিল যা তাতে পৌঁছতে দিল—মিসিং অ্যালার্ট, অস্পষ্ট লিমিট, ঝুঁকিপূর্ণ ডিপ্লয়—এবং সেই শর্তগুলো উন্নত করা।
মালিকানা তখনই জটিল হয় যখন সার্ভিস অনির্দিষ্ট। সার্ভিস সীমানা (এটি কি করে, উপর কি নির্ভর করে, কী অঙ্গীকার করে) নির্ধারণ করুন এবং একটি নামকরা মালিক টিম নিযুক্ত করুন। সেই স্পষ্টতা হ্যান্ডঅফ কমায়, ইনসিডেন্ট রেসপন্স দ্রুত করে, এবং যখন নির্ভরযোগ্যতা এবং ফিচারের মধ্যে প্রতিযোগিতা হয় তখন অগ্রাধিকার স্পষ্ট করে।
অন-কল “তুমি বানাও, তুমি চালাও”-এর কেন্দ্রীয় অংশ কারণ এটি ফিডব্যাক লুপ বন্ধ করে। যখন যে টিমটি চেঞ্জ শিপ করে সেটাই অপারেশনাল প্রভাবও অনুভব করে (লেটেন্সি স্পাইক, ব্যর্থ ডিপ্লয়, কাস্টমার শিকাগুলো), অগ্রাধিকারগুলো স্পষ্ট হয়: নির্ভরযোগ্যতা কাজ আর “আরও কারো সমস্যা” নয়, এবং বেশি শিপ করার দ্রুততম পথ প্রায়ই সিস্টেমকে শান্ত করা।
স্বাস্থ্যকর অন-কল মূলত পূর্বানুমেয়তা ও সাপোর্টের ব্যাপার।
সেভারিটি লেভেল নির্ধারণ করুন যাতে সিস্টেম প্রতিটি ত্রুটির জন্য পেজ করে না।
একটি সহজ নিয়ম: যদি কাউকে জাগানো ফলাফল বদলাবে না, তা টিকিট হওয়া উচিত, পেজ না।
অন-কল শাস্তি নয়; এটা একটি সিগনাল। প্রতিটি গোলমাল অ্যালার্ট, বারবার হওয়া ব্যর্থতা, বা ম্যানুয়াল ফিক্সই ইঞ্জিনিয়ারিং কাজে ফিডব্যাক হওয়া উচিত: ভালো অ্যালার্ট, অটোমেশন, নিরাপদ রিলিজ, এবং সিস্টেম পরিবর্তন যাতে আর পেজ করার প্রয়োজন না পড়ে।
যদি “তুমি চালাও” বাস্তবে থাকে, টিমগুলোকে একটা শেয়ার্ড উপায় দরকার নির্ভরযোগ্যতা নিয়ে কথা বলার—বিনা আবেগের। SLI, SLO, এবং এরর বাজেট সেই স্পষ্ট লক্ষ্য ও ফেয়ার ট্রেড-অফ দেয় দ্রুততা এবং স্থিতিশীলতার মধ্যে।
মনে রাখার সহজ উপায়: SLI = মেট্রিক, SLO = টার্গেট, SLA = বাইরের অঙ্গীকার।
ভালো SLI নির্দিষ্ট এবং ব্যবহারকারীর অভিজ্ঞতার সাথে সংযুক্ত, যেমন:
এরর বাজেট হলো সেই পরিমাণ “খারাপ” যা তোমরা SLO পূরণকালে ভোগ করতে পারো (উদাহরণ: SLO 99.9% হলে মাসিক এরর বাজেট 0.1% ডাউনটাইম)।
সার্ভিস সুস্থ থাকলে এবং তুমি বাজেটের মধ্যে থাকলে টিমগুলো বেশি ডেলিভারি ঝুঁকি নিতে পারে (ফিচার, এক্সপেরিমেন্ট)। যখন বাজেট দ্রুত জ্বলছে, নির্ভরযোগ্যতা কাজকে অগ্রাধিকার দেয়া হয়।
SLOগুলো নির্ভরযোগ্যতাকে প্ল্যানিং ইনপুটে পরিণত করে। যদি তোমার এরর বাজেট কম থাকে, পরবর্তী স্প্রিন্টে রেট লিমিটিং, নিরাপদ রোলআউট, বা ফ্লেকি ডিপেন্ডেন্সি ফিক্স করতে হবে—কারণ SLO মিস করার একটি স্পষ্ট খরচ আছে। বাজেট পর্যাপ্ত থাকলে পণ্য কাজ অগ্রাধিকার পেতে পারে।
“তুমি বানাও, তুমি চালাও” তখনই কাজ করবে যখন প্রোডাকশনে শিপ করা রুটিন হবে—উচ্চ-ঝুঁকির ইভেন্ট নয়। লক্ষ্য হলো লঞ্চের আগে অনিশ্চয়তা কমানো এবং লঞ্চের পরে ব্লাস্ট রেডিয়াস সীমাবদ্ধ রাখা।
একটি সার্ভিস “রেডি” বিবেচিত হওয়ার আগে সাধারণত কিছু অপারেশনাল বেসিক থাকা দরকার:
সবকিছু একসাথে প্রত্যেকের কাছে রিলিজ করার বদলে, প্রগ্রেসিভ ডেলিভারি প্রভাব সীমাবদ্ধ করে:
টিম যদি রোলব্যাক স্ট্যান্ডার্ডাইজ করে, তা প্রথম শ্রেণীর ক্ষমতা হিসেবে বিবেচনা করুন: যত দ্রুত নিরাপদে রিভার্ট করতে পারবে, ‘তুমি চালাও’ তত বাস্তবসম্মত হবে।
দুইটি টেস্ট “অজানা অজানা” কমায়:
হালকা রাখুন: রেপো বা টিকেট টেমপ্লেটে এক-পাতার চেকলিস্ট (উদাহরণ: “Observability,” “On-call readiness,” “Data protection,” “Rollback plan,” “Capacity tested,” “Runbooks linked”)। “নট রেডি” হওয়া স্বাভাবিক রাখুন—প্রোডাকশনে শিখে নেওয়ার চেয়ে এটা অনেক ভালো।
ইনসিডেন্টগুলো সেই জায়গা যেখানে “তুমি চালাও” বাস্তবে আসে: একটি সার্ভিস degragde হয়েছে, কাস্টমার নোটিস করে, এবং টিম দ্রুত ও স্পষ্টভাবে রেসপন্ড করতে হয়। লক্ষ্য হিরোইকস নয়—বরং একট
এটার অর্থ হলো যে যে টিমটি কোনো সার্ভিস ডিজাইন, তৈরি ও ডিপ্লয় করে, একই টিম লাইভ হওয়ার পরে সেটার জন্যও দায়বদ্ধ: মনিটরিং, অন-কল রেসপন্স, ইনসিডেন্ট ফলো-আপ এবং নির্ভরযোগ্যতা উন্নয়ন।
এটা একটি দায়িত্বগত মডেল (স্বচ্ছ মালিকানা), কোনো নির্দিষ্ট টুল বা চাকরির শিরোনামে বদল নয়।
এটার মানে প্রতিটি ইঞ্জিনিয়ারকে পুরোপুরি ইনফ্রাস্ট্রাকচার এক্সপার্ট হতে হবে—না।
এটা বোঝায়:
সেপারেট অপস টিম থাকলে ফিডব্যাক দেরিতে আসে এবং দায়িত্ব অস্পষ্ট থাকে: ডেভেলপাররা প্রোডাকশনের কষ্ট অনুভব নাও করতে পারে, আর অপসের কাছে সাম্প্রতিক পরিবর্তনের প্রসঙ্গ নাও থাকতে পারে।
শেষ পর্যন্ত এন্ড-টু-এন্ড মালিকানা সাধারণত উন্নত করে:
“চালাও” সাধারণত অন্তর্ভুক্ত করে:
মানবিক অন-কল ডিজাইন করতে হয়৷
শুরু করুন সদয় ডিফল্ট দিয়ে:
ভালো অন-কল সিস্টেমের লক্ষ্য হলো পরবর্তী মাসে পেজ কমানো, নইলে হিরোইকসকে স্বাভাবিক করা নয়।
সরল নিয়ম: যদি কাউকে জাগানো ফলাফল বদলায় না, এটা টিকেট হওয়া উচিত, পেজ নয়।
প্রায়োগিকভাবে:
এসএলআই/এসএলও/এরর বাজেটগুলো নির্ধারণ করায়:
বাজেট দ্রুত জ্বললে গুরুত্বপ্রাপ্ত রিলায়বিলিটি কাজকে অগ্রাধিকার দিন; বাজেট ভাল থাকলে ফিচার শিপ করা যায় বেশি ঝুঁকি নিয়ে।
রিলিজ অনুশীলনগুলো যা অনিশ্চয়তা ও ব্লাস্ট রেডিয়াস কমায়:
ইনসিডেন্টগুলোতে একটি পুনরাবৃত্তযোগ্য ওয়ার্কফ্লো চালান:
তারপর ব্লেমলেস পোস্টমর্টেম লিখুন, যা সিস্টেম এবং প্রক্রিয়ার দুর্বলতার দিকে মনোযোগ দেয়, ব্যক্তিকে শামে না দিয়ে। ফলো-আপ গুলো হওয়া উচিত:
প্ল্যাটফর্ম টিমগুলো 'paved roads' দিয়ে টিমদের সহজভাবে মালিকানা নেওয়ার সুযোগ করে দেয়। কাজটি হলো প্রোডাক্ট টিমের পরিবর্তে প্রোডাকশন চালানো না—বরং এমন একটি পথ দেওয়া যাতে প্রোডাক্ট টিমরা পুনরাবৃত্তি করে অপারেশন গঠন না করে।
প্রাইমারী সীমা: