ওয়েবিনারের ট্রান্সক্রিপশন "এসআরই - হাইপ নাকি ভবিষ্যত?"

ওয়েবিনারে খারাপ অডিও আছে, তাই আমরা এটি প্রতিলিপি করেছি।

আমার নাম মেদভেদেভ এডুয়ার্ড। আজ আমি এসআরই কী, কীভাবে এসআরই উপস্থিত হয়েছিল, এসআরই ইঞ্জিনিয়ারদের কাজের মানদণ্ড কী, নির্ভরযোগ্যতার মানদণ্ড সম্পর্কে কিছুটা, এর পর্যবেক্ষণ সম্পর্কে একটু কথা বলব। আমরা শীর্ষে হাঁটব, কারণ আপনি এক ঘন্টার মধ্যে বেশি কিছু বলতে পারবেন না, তবে আমি অতিরিক্ত পর্যালোচনার জন্য উপকরণ দেব এবং আমরা সবাই আপনার জন্য অপেক্ষা করছি Slurme SRE. জানুয়ারির শেষে মস্কোতে।

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

সমস্যা হল আমাদের কাছে DevOps-এর একটি স্পষ্ট সংজ্ঞা এবং DevOps-এর সুস্পষ্ট বাস্তবায়ন নেই। আমি 2 বছর আগে ইয়েকাটেরিনবার্গে একটি সম্মেলনে বক্তৃতা করেছি, এবং এখন পর্যন্ত DevOps বিভাগটি "DevOps কী" রিপোর্ট দিয়ে শুরু হয়েছিল। 2017 সালে, Devops প্রায় 10 বছর বয়সী, কিন্তু আমরা এখনও এটি কি তর্ক করছি। এবং এটি একটি খুব অদ্ভুত পরিস্থিতি যা গুগল কয়েক বছর আগে সমাধান করার চেষ্টা করেছিল।

2016 সালে, Google Site Reliability Engineering নামে একটি বই প্রকাশ করেছে। এবং প্রকৃতপক্ষে, এই বইটি দিয়েই SRE আন্দোলন শুরু হয়েছিল। SRE হল একটি নির্দিষ্ট কোম্পানিতে DevOps দৃষ্টান্তের একটি নির্দিষ্ট বাস্তবায়ন। SRE ইঞ্জিনিয়াররা নিশ্চিত করতে প্রতিশ্রুতিবদ্ধ যে সিস্টেমগুলি নির্ভরযোগ্যভাবে কাজ করে। তারা বেশিরভাগ ডেভেলপারদের কাছ থেকে আসে, কখনও কখনও একটি শক্তিশালী বিকাশের পটভূমি সহ প্রশাসক। এবং সিস্টেম অ্যাডমিনিস্ট্রেটররা যা করতেন তারা তাই করে, কিন্তু কোডের পরিপ্রেক্ষিতে সিস্টেমের বিকাশ এবং জ্ঞানের একটি শক্তিশালী পটভূমি এই সত্যের দিকে পরিচালিত করে যে এই লোকেরা রুটিন প্রশাসনিক কাজের দিকে ঝুঁকছে না, তবে অটোমেশনের দিকে ঝুঁকছে।

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

তারা জিজ্ঞাসা করে যে SRE এবং devops এর মধ্যে পার্থক্য বর্ণনা করা হবে কিনা। তিনি শুধু বর্ণনা করা হয়েছে. আমরা সংস্থায় SRE এর স্থান সম্পর্কে কথা বলতে পারি। এই ক্লাসিক DevOps পদ্ধতির বিপরীতে, যেখানে Ops এখনও একটি পৃথক বিভাগ, SRE হল উন্নয়ন দলের অংশ। তারা পণ্য বিকাশের সাথে জড়িত। এমনকি একটি পদ্ধতি রয়েছে যেখানে SRE হল একটি ভূমিকা যা এক বিকাশকারী থেকে অন্যের কাছে যায়। তারা কোড রিভিউতে একইভাবে অংশগ্রহণ করে, যেমন, ইউএক্স ডিজাইনার, নিজেরাই ডেভেলপার, কখনও কখনও প্রোডাক্ট ম্যানেজার। এসআরই একই স্তরে কাজ করে। আমাদের তাদের অনুমোদন করতে হবে, আমাদের তাদের পর্যালোচনা করতে হবে, যাতে প্রতিটি স্থাপনার জন্য SRE বলে: “ঠিক আছে, এই স্থাপনা, এই পণ্যটি নির্ভরযোগ্যতাকে নেতিবাচকভাবে প্রভাবিত করবে না। এবং যদি তা করে তবে কিছু গ্রহণযোগ্য সীমার মধ্যে। আমরা এ বিষয়েও কথা বলব।

তদনুসারে, কোড পরিবর্তন করার জন্য SRE-এর একটি ভেটো রয়েছে। এবং সাধারণভাবে, যদি SRE ভুলভাবে প্রয়োগ করা হয় তবে এটি কিছু ধরণের ছোট দ্বন্দ্বের দিকে নিয়ে যায়। সাইট রিলায়েবিলিটি ইঞ্জিনিয়ারিং সম্পর্কে একই বইতে, অনেকগুলি অংশ, এমনকি একটিও নয়, কীভাবে এই দ্বন্দ্বগুলি এড়ানো যায় তা বলুন।

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

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

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

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

এই সব ভুল, অবশ্যই. এবং এই লোকেরা প্রায়শই অনুশীলনে এই জাতীয় কোড দ্বারা কামড়ানো হয়, কারণ জিনিসগুলি ভেঙে যায়। জিনিসগুলি কখনও কখনও সবচেয়ে অপ্রত্যাশিত উপায়ে ভেঙে যায়। কখনও কখনও লোকেরা বলে না, এটি কখনই হবে না। এবং এটা সব সময় ঘটে. এটা প্রায়ই যথেষ্ট ঘটবে. আর এই কারণেই কেউ কখনও 100% প্রাপ্যতার জন্য চেষ্টা করে না, কারণ 100% প্রাপ্যতা কখনই ঘটে না। এটাই আদর্শ। এবং তাই, যখন আমরা একটি পরিষেবার প্রাপ্যতা সম্পর্কে কথা বলি, তখন আমরা সর্বদা নাইন সম্পর্কে কথা বলি। 2 নাইন, 3 নাইন, 4 নাইন, 5 নাইন। যদি আমরা এটিকে ডাউনটাইমে অনুবাদ করি, তাহলে, উদাহরণস্বরূপ, 5 নাইন, তাহলে এটি প্রতি বছর 5 মিনিটের ডাউনটাইমের চেয়ে একটু বেশি, 2 নাইন হল ডাউনটাইমের 3,5 দিন।

কিন্তু এটা স্পষ্ট যে কিছু সময়ে POI, বিনিয়োগে রিটার্ন কমে যায়। দুই নাইন থেকে তিন নাইনে যাওয়া মানে ৩ দিনের বেশি কম ডাউনটাইম। চার নাইন থেকে পাঁচে যাওয়া ডাউনটাইম প্রতি বছর 3 মিনিট কমিয়ে দেয়। এবং এটি দেখা যাচ্ছে যে ব্যবসার জন্য এটি সমালোচনামূলক নাও হতে পারে। এবং সাধারণভাবে, প্রয়োজনীয় নির্ভরযোগ্যতা একটি প্রযুক্তিগত সমস্যা নয়, প্রথমত, এটি একটি ব্যবসায়িক সমস্যা, এটি একটি পণ্য সমস্যা। পণ্যের ব্যবহারকারীদের জন্য কোন স্তরের ডাউনটাইম গ্রহণযোগ্য, তারা কী প্রত্যাশা করে, তারা কত টাকা দেয়, উদাহরণস্বরূপ, তারা কত টাকা হারায়, সিস্টেম কত টাকা হারায়।

এখানে একটি গুরুত্বপূর্ণ প্রশ্ন হল বাকি উপাদানগুলির নির্ভরযোগ্যতা কি। কারণ 4 এবং 5 নাইনের মধ্যে পার্থক্য 2 নাইনের নির্ভরযোগ্যতার সাথে একটি স্মার্টফোনে দৃশ্যমান হবে না। মোটামুটিভাবে বলতে গেলে, বছরে 10 বার আপনার পরিষেবাতে একটি স্মার্টফোনে কিছু ব্রেক হলে, সম্ভবত 8 বার OS এর দিকে ব্রেকডাউন ঘটেছে। ব্যবহারকারী এটিতে অভ্যস্ত, এবং বছরে আরও একবার মনোযোগ দেবেন না। ক্রমবর্ধমান নির্ভরযোগ্যতা এবং মুনাফা বৃদ্ধির মূল্যের মধ্যে সম্পর্ক স্থাপন করা প্রয়োজন।
শুধু এসআরই-এর বইতে ৩ নাইন থেকে ৪ নাইন বাড়ানোর একটি ভালো উদাহরণ রয়েছে। এটা দেখা যাচ্ছে যে প্রাপ্যতা বৃদ্ধি 4% এর চেয়ে একটু কম। এবং যদি পরিষেবার রাজস্ব বছরে $3 মিলিয়ন হয়, তাহলে রাজস্ব বৃদ্ধি $0,1। একটি নয় দ্বারা ক্রয়ক্ষমতা বাড়ানোর জন্য যদি আমাদের বছরে $1-এর কম খরচ হয়, তবে এই বৃদ্ধি আর্থিক অর্থবোধ করে। যদি এটি বছরে 900 ডলারের বেশি খরচ করে, তবে এটি আর অর্থবোধ করে না, কারণ রাজস্ব বৃদ্ধি কেবল শ্রম খরচ, সম্পদ খরচের জন্য ক্ষতিপূরণ দেয় না। এবং 900 নাইনই আমাদের জন্য যথেষ্ট হবে।

এটি অবশ্যই একটি সরলীকৃত উদাহরণ যেখানে সমস্ত অনুরোধ সমান। এবং 3 নাইন থেকে 4 নাইনে যাওয়া যথেষ্ট সহজ, কিন্তু একই সময়ে, উদাহরণস্বরূপ, 2 নাইন থেকে 3 তে যাওয়া, এটি ইতিমধ্যে 9 হাজার ডলারের সঞ্চয়, এটি আর্থিক অর্থবোধ করতে পারে। স্বাভাবিকভাবেই, বাস্তবে, নিবন্ধকরণের অনুরোধের ব্যর্থতা পৃষ্ঠাটি প্রদর্শন করতে ব্যর্থতার চেয়ে খারাপ, অনুরোধের বিভিন্ন ওজন রয়েছে। ব্যবসায়িক দৃষ্টিকোণ থেকে তাদের একটি সম্পূর্ণ ভিন্ন মানদণ্ড থাকতে পারে, তবে যাইহোক, একটি নিয়ম হিসাবে, যদি আমরা কিছু নির্দিষ্ট পরিষেবার কথা না বলি তবে এটি একটি মোটামুটি নির্ভরযোগ্য আনুমানিক।
আমরা একটি প্রশ্ন পেয়েছি যে পরিষেবার জন্য একটি আর্কিটেকচারাল সমাধান বেছে নেওয়ার সময় SRE সমন্বয়কারীদের মধ্যে একজন কিনা। বিদ্যমান অবকাঠামোতে একীকরণের পরিপ্রেক্ষিতে বলা যাক, যাতে এর স্থায়িত্বের কোনো ক্ষতি না হয়। হ্যাঁ, এসআরই, একইভাবে অনুরোধ, প্রতিশ্রুতি, রিলিজ আর্কিটেকচার, নতুন পরিষেবার প্রবর্তন, মাইক্রোসার্ভিসেস, নতুন সমাধান বাস্তবায়নকে প্রভাবিত করে। আগে কেন বললাম যে অভিজ্ঞতা দরকার, যোগ্যতা দরকার। আসলে, SRE হল যেকোনো আর্কিটেকচারাল এবং সফ্টওয়্যার সমাধানের ব্লকিং ভয়েসগুলির মধ্যে একটি। তদনুসারে, একজন প্রকৌশলী হিসাবে একজন এসআরইকে প্রথমেই কেবল বুঝতে হবে না, বরং কিছু নির্দিষ্ট সিদ্ধান্ত কীভাবে নির্ভরযোগ্যতা, স্থিতিশীলতাকে প্রভাবিত করবে তা বুঝতে হবে এবং বুঝতে হবে এটি কীভাবে ব্যবসায়ের প্রয়োজনের সাথে সম্পর্কিত, এবং কোন দৃষ্টিকোণ থেকে এটি গ্রহণযোগ্য হতে পারে এবং যা না।

অতএব, এখন আমরা কেবল নির্ভরযোগ্যতার মানদণ্ড সম্পর্কে কথা বলতে পারি, যা ঐতিহ্যগতভাবে SRE তে SLA (সার্ভিস লেভেল এগ্রিমেন্ট) হিসাবে সংজ্ঞায়িত করা হয়েছে। সম্ভবত একটি পরিচিত শব্দ. SLI (সার্ভিস লেভেল ইন্ডিকেটর)। এসএলও (সার্ভিস লেভেল অবজেক্টিভ)। পরিষেবা স্তর চুক্তি সম্ভবত একটি প্রতীকী শব্দ, বিশেষ করে যদি আপনি নেটওয়ার্কের সাথে, প্রদানকারীদের সাথে, হোস্টিংয়ের সাথে কাজ করেন৷ এটি একটি সাধারণ চুক্তি যা আপনার সম্পূর্ণ পরিষেবার কার্যকারিতা, জরিমানা, ত্রুটির জন্য কিছু শাস্তি, মেট্রিক্স, মানদণ্ড বর্ণনা করে। এবং SLI হল প্রাপ্যতা মেট্রিক নিজেই। অর্থাৎ, SLI কী হতে পারে: পরিষেবা থেকে প্রতিক্রিয়া সময়, শতাংশ হিসাবে ত্রুটির সংখ্যা। এটি ব্যান্ডউইথ হতে পারে যদি এটি কিছু ধরণের ফাইল হোস্টিং হয়। যখন এটি স্বীকৃতি অ্যালগরিদম আসে, নির্দেশক হতে পারে, উদাহরণস্বরূপ, এমনকি উত্তরের সঠিকতা। SLO (সার্ভিস লেভেল অবজেক্টিভ) হল, যথাক্রমে, SLI সূচক, এর মান এবং সময়কালের সংমিশ্রণ।

ধরা যাক SLA এরকম হতে পারে। পরিষেবাটি সারা বছরের 99,95% সময় পাওয়া যায়। অথবা 99টি ক্রিটিক্যাল সাপোর্ট টিকিট প্রতি ত্রৈমাসিকে 3 ঘন্টার মধ্যে বন্ধ হয়ে যাবে। অথবা 85% অনুরোধ প্রতি মাসে 1,5 সেকেন্ডের মধ্যে উত্তর দেওয়া হবে। অর্থাৎ, আমরা ধীরে ধীরে বুঝতে পারি যে ত্রুটি এবং ব্যর্থতা খুবই স্বাভাবিক। এটি একটি গ্রহণযোগ্য পরিস্থিতি, আমরা এটির পরিকল্পনা করছি, এমনকি আমরা এটিকে কিছুটা হলেও গণনা করছি। অর্থাৎ, এসআরই এমন সিস্টেম তৈরি করে যা ভুল করতে পারে, যা অবশ্যই ত্রুটির প্রতি সাড়া দিতে হবে, যা অবশ্যই তাদের বিবেচনায় নিতে হবে। এবং যখনই সম্ভব, তাদের এমনভাবে ত্রুটিগুলি পরিচালনা করা উচিত যাতে ব্যবহারকারী হয় সেগুলি লক্ষ্য না করে, বা নোটিশ করে, তবে কিছু ধরণের সমাধান রয়েছে, যার কারণে সবকিছু সম্পূর্ণরূপে পড়ে যাবে না।

উদাহরণস্বরূপ, যদি আপনি YouTube-এ একটি ভিডিও আপলোড করেন, এবং YouTube তা অবিলম্বে রূপান্তর করতে না পারে, যদি ভিডিওটি খুব বড় হয়, যদি বিন্যাসটি সর্বোত্তম না হয়, তাহলে অনুরোধটি স্বাভাবিকভাবেই টাইমআউটের সাথে ব্যর্থ হবে না, YouTube একটি 502 ত্রুটি দেবে না , YouTube বলবে: “আমরা সবকিছু তৈরি করেছি, আপনার ভিডিও প্রক্রিয়া করা হচ্ছে। এটি প্রায় 10 মিনিটের মধ্যে প্রস্তুত হবে।" এটি করুণাময় অবক্ষয়ের নীতি, যা পরিচিত, উদাহরণস্বরূপ, সামনের দিকের বিকাশ থেকে, যদি আপনি কখনও এটি করে থাকেন।

পরবর্তী শর্তাবলী যেগুলি সম্পর্কে আমরা কথা বলব, যা নির্ভরযোগ্যতার সাথে, ত্রুটি সহ, প্রত্যাশা সহ কাজ করার জন্য খুবই গুরুত্বপূর্ণ, হল MTBF এবং MTTR৷ MTBF হল ব্যর্থতার মধ্যবর্তী সময়। MTTR মানে পুনরুদ্ধারের সময়, পুনরুদ্ধারের গড় সময়। অর্থাৎ, ত্রুটিটি আবিষ্কৃত হওয়ার মুহূর্ত থেকে, পরিষেবাটি সম্পূর্ণ স্বাভাবিক ক্রিয়াকলাপে পুনরুদ্ধারের মুহূর্ত পর্যন্ত ত্রুটিটি উপস্থিত হওয়ার মুহূর্ত পর্যন্ত কত সময় কেটে গেছে। MTBF প্রধানত কোড মানের উপর কাজ দ্বারা স্থির করা হয়. অর্থাৎ, সত্য যে SREs "না" বলতে পারে। এবং আপনার পুরো দলের বোঝার প্রয়োজন যে SRE যখন "না" বলে, তখন সে এটা বলে না কারণ সে ক্ষতিকর, নয় কারণ সে খারাপ, কিন্তু অন্যথায় সবাই ক্ষতিগ্রস্ত হবে।

আবার, অনেক নিবন্ধ আছে, অনেক পদ্ধতি আছে, অনেক উপায় আছে এমনকি খুব যে বইটিতে আমি প্রায়ই উল্লেখ করি, কীভাবে নিশ্চিত করা যায় যে অন্যান্য বিকাশকারীরা SRE ঘৃণা করতে শুরু করবেন না। অন্যদিকে, MTTR হল আপনার SLO (সার্ভিস লেভেল অবজেক্টিভ) নিয়ে কাজ করা। এবং এটি বেশিরভাগই অটোমেশন। কারণ, উদাহরণস্বরূপ, আমাদের SLO হল প্রতি ত্রৈমাসিক 4 নাইন এর আপটাইম। এর মানে হল যে 3 মাসে আমরা 13 মিনিট ডাউনটাইম দিতে পারি। এবং দেখা যাচ্ছে যে MTTR 13 মিনিটের বেশি হতে পারে না। যদি আমরা 13 মিনিটের মধ্যে কমপক্ষে 1 ডাউনটাইমের প্রতিক্রিয়া জানাই, তাহলে এর মানে হল যে আমরা ইতিমধ্যেই ত্রৈমাসিকের জন্য সম্পূর্ণ বাজেট শেষ করে ফেলেছি। আমরা SLO ভঙ্গ করছি। 13 মিনিট প্রতিক্রিয়া এবং একটি ক্র্যাশ ঠিক করার জন্য একটি মেশিনের জন্য অনেক, কিন্তু একটি মানুষের জন্য খুব ছোট। কারণ যতক্ষণ না একজন ব্যক্তি একটি সতর্কতা পায়, যতক্ষণ না সে প্রতিক্রিয়া জানায়, যতক্ষণ না সে ত্রুটিটি বুঝতে পারে, এটি ইতিমধ্যে বেশ কয়েক মিনিট। যতক্ষণ না একজন ব্যক্তি বুঝতে পারে কীভাবে এটি ঠিক করতে হবে, ঠিক কী ঠিক করতে হবে, কী করতে হবে, তারপরে এটি আরও কয়েক মিনিট। এবং প্রকৃতপক্ষে, এমনকি যদি আপনাকে কেবল সার্ভারটি পুনরায় চালু করতে হয়, যেমনটি দেখা যাচ্ছে, বা একটি নতুন নোড বাড়াতে হবে, তারপর ম্যানুয়ালি এমটিটিআর ইতিমধ্যেই প্রায় 7-8 মিনিট। প্রক্রিয়াটি স্বয়ংক্রিয় করার সময়, MTTR প্রায়শই এক সেকেন্ডে পৌঁছায়, কখনও কখনও মিলিসেকেন্ডে। গুগল সাধারণত মিলিসেকেন্ড সম্পর্কে কথা বলে, কিন্তু বাস্তবে, অবশ্যই, সবকিছু এত ভাল নয়।

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

আমাকে বিস্তারিত বলতে দাও. যদি প্রতি ত্রৈমাসিক SLO সময় অতিক্রম করা হয়, যদি ডাউনটাইম 13 মিনিট না হয়, কিন্তু 15 হয়, এর জন্য কে দায়ী হতে পারে? অবশ্যই, SRE দায়ী হতে পারে, কারণ তিনি স্পষ্টতই কিছু খারাপ প্রতিশ্রুতি বা স্থাপনা করেছেন। ডেটা সেন্টারের অ্যাডমিনিস্ট্রেটর এর জন্য দায়ী হতে পারে, কারণ তিনি হয়তো কোনো ধরনের অনির্ধারিত রক্ষণাবেক্ষণ করেছেন। যদি ডেটা সেন্টারের প্রশাসককে এর জন্য দায়ী করা হয়, তাহলে Ops-এর সেই ব্যক্তিকে দায়ী করা হবে, যিনি SLO সমন্বয় করার সময় রক্ষণাবেক্ষণের হিসাব করেননি। ম্যানেজার, টেকনিক্যাল ডিরেক্টর বা কেউ যিনি ডেটা সেন্টার চুক্তিতে স্বাক্ষর করেছেন এবং ডেটা সেন্টারের এসএলএ প্রয়োজনীয় ডাউনটাইমের জন্য ডিজাইন করা হয়নি এই বিষয়টিতে মনোযোগ দেননি এই জন্য দায়ী। তদনুসারে, এই পরিস্থিতিতে ধীরে ধীরে সমস্ত দায়ী। আর এর মানে হল এই পরিস্থিতিতে কাউকে দোষারোপ করে লাভ নেই। তবে অবশ্যই এটি সংশোধন করা প্রয়োজন। তাই পোস্টমর্টেম আছে। এবং আপনি যদি পড়েন, উদাহরণস্বরূপ, গিটহাব পোস্টমর্টেম, এবং এটি সর্বদা প্রতিটি ক্ষেত্রে একটি খুব আকর্ষণীয়, ছোট এবং অপ্রত্যাশিত গল্প, আপনি প্রতিস্থাপন করতে পারেন যে কেউ কখনও বলে না যে এই নির্দিষ্ট ব্যক্তিকে দোষ দেওয়া হয়েছিল। দোষ সবসময় নির্দিষ্ট অসম্পূর্ণ প্রক্রিয়ার উপর স্থাপন করা হয়.

আসুন পরবর্তী প্রশ্নে এগিয়ে যাই। অটোমেশন। যখন আমি অন্যান্য প্রসঙ্গে অটোমেশন সম্পর্কে কথা বলি, তখন আমি প্রায়ই একটি সারণী উল্লেখ করি যা আপনাকে বলে যে আপনি কতক্ষণ কাজ করতে পারবেন তা স্বয়ংক্রিয় করার জন্য আপনি প্রকৃতপক্ষে সঞ্চয় করার চেয়ে বেশি সময় না নিয়ে। একটি snag আছে. ধরা হল যে যখন SRE গুলি একটি কাজকে স্বয়ংক্রিয় করে, তারা কেবল সময়ই বাঁচায় না, তারা অর্থও বাঁচায়, কারণ অটোমেশন সরাসরি MTTR কে প্রভাবিত করে৷ তারা সংরক্ষণ করে, তাই বলতে গেলে, কর্মচারী এবং বিকাশকারীদের মনোবল, যা একটি নিঃশেষযোগ্য সম্পদও। তারা রুটিন কমিয়ে দেয়। এবং এই সমস্ত কাজের উপর ইতিবাচক প্রভাব ফেলে এবং ফলস্বরূপ, ব্যবসায়, এমনকি যদি মনে হয় যে অটোমেশন সময় ব্যয়ের ক্ষেত্রে অর্থপূর্ণ নয়।

প্রকৃতপক্ষে, এটি প্রায় সবসময়ই থাকে এবং খুব কম ক্ষেত্রেই SRE-এর ভূমিকায় কিছু স্বয়ংক্রিয় হওয়া উচিত নয়। এরপরে আমরা এরর বাজেট, ত্রুটির জন্য বাজেট কাকে বলে সে সম্পর্কে কথা বলব। প্রকৃতপক্ষে, দেখা যাচ্ছে যে আপনি নিজের জন্য যে SLO সেট করেছেন তার চেয়ে যদি সবকিছু আপনার জন্য অনেক ভাল হয় তবে এটি খুব ভাল নয়। এটি বরং খারাপ, কারণ এসএলও কেবল নিম্ন হিসাবে নয়, আনুমানিক উপরের সীমা হিসাবেও কাজ করে। আপনি যখন নিজেকে 99% প্রাপ্যতার একটি SLO সেট করেন, এবং আসলে আপনার কাছে 99,99% থাকে, তখন দেখা যাচ্ছে যে আপনার কাছে পরীক্ষা-নিরীক্ষার জন্য কিছু জায়গা আছে যা ব্যবসার কোনো ক্ষতি করবে না, কারণ আপনি নিজেই এই সব একসাথে নির্ধারণ করেছেন, এবং আপনি এই স্থান ব্যবহার করবেন না. আপনার ভুলের জন্য একটি বাজেট আছে, যা আপনার ক্ষেত্রে ব্যবহৃত হয় না।

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

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

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

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

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

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

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

অর্থাৎ, এই প্রক্রিয়াগুলিকে মানককরণের সমস্ত প্রধান কাজ ইতিমধ্যে আপনার জন্য করা হয়েছে। আপনার কোম্পানিতে বিশেষভাবে SRE-এর ভূমিকা নির্ধারণ করা এবং এই সমস্ত অনুশীলনগুলি বাস্তবে বাস্তবায়ন করা শুরু করা আপনার জন্য অবশেষ, যা আবার, ইতিমধ্যেই বর্ণিত হয়েছে। অর্থাৎ, ছোট কোম্পানিগুলির জন্য দরকারী নীতিগুলি থেকে, এটি সর্বদা SLA, SLI, SLO এর সংজ্ঞা। আপনি যদি সফ্টওয়্যারের সাথে জড়িত না হন, তাহলে এগুলি হবে অভ্যন্তরীণ SLA এবং অভ্যন্তরীণ SLO, ত্রুটির জন্য একটি অভ্যন্তরীণ বাজেট৷ এটি প্রায় সর্বদা দলের মধ্যে এবং ব্যবসায়ের মধ্যে কিছু আকর্ষণীয় আলোচনার দিকে পরিচালিত করে, কারণ এটি দেখা যেতে পারে যে আপনি অবকাঠামোতে ব্যয় করেন, আদর্শ প্রক্রিয়াগুলির কোনও ধরণের সংগঠনে, আদর্শ পাইপলাইনটি প্রয়োজনের চেয়ে অনেক বেশি। এবং এই 4 টি নাইন যে আপনার আইটি বিভাগে আছে, আপনার এখন সত্যিই তাদের প্রয়োজন নেই। কিন্তু একই সময়ে, আপনি সময় ব্যয় করতে পারেন, অন্য কিছুতে ভুলের জন্য বাজেট ব্যয় করতে পারেন।

তদনুসারে, মনিটরিং এবং মনিটরিং সংগঠন যে কোনো আকারের একটি কোম্পানির জন্য দরকারী। এবং সাধারণভাবে, এই ধরনের চিন্তাভাবনা, যেখানে ভুলগুলি গ্রহণযোগ্য কিছু, যেখানে একটি বাজেট আছে, যেখানে উদ্দেশ্য আছে, এটি আবার 3 জনের জন্য স্টার্টআপ থেকে শুরু করে যে কোনও আকারের কোম্পানির জন্য দরকারী।

প্রযুক্তিগত সূক্ষ্ম বিষয়ে কথা বলার শেষটি হল পর্যবেক্ষণ। কারণ আমরা যদি SLA, SLI, SLO সম্পর্কে কথা বলি, আমরা বাজেটের সাথে মানানসই কিনা, আমরা আমাদের উদ্দেশ্যগুলি মেনে চলছি কিনা এবং আমরা কীভাবে চূড়ান্ত SLA-কে প্রভাবিত করি তা পর্যবেক্ষণ না করে বুঝতে পারি না। আমি অনেকবার দেখেছি যে নিরীক্ষণ এভাবে হয়: কিছু মান আছে, উদাহরণস্বরূপ, সার্ভারের কাছে একটি অনুরোধের সময়, গড় সময় বা ডাটাবেসের অনুরোধের সংখ্যা। তার একটি প্রকৌশলী দ্বারা নির্ধারিত একটি মান আছে। যদি মেট্রিক আদর্শ থেকে বিচ্যুত হয়, তাহলে একটি ই-মেইল আসে। এটি একটি নিয়ম হিসাবে, একেবারেই অকেজো, কারণ এটি এমন একটি সতর্কতার দিকে নিয়ে যায়, নজরদারি থেকে বার্তাগুলির একটি আধিক্য, যখন একজন ব্যক্তিকে, প্রথমত, প্রতিবার তাদের ব্যাখ্যা করতে হবে, অর্থাৎ, মেট্রিকের মান মানে কিনা তা নির্ধারণ করতে হবে কিছু পদক্ষেপের প্রয়োজন। এবং দ্বিতীয়ত, তিনি কেবল এই সমস্ত সতর্কতাগুলি লক্ষ্য করা বন্ধ করে দেন, যখন মূলত তার কাছ থেকে কোনও পদক্ষেপের প্রয়োজন হয় না। এটি একটি ভাল মনিটরিং নিয়ম এবং যখন SRE প্রয়োগ করা হয় তখন প্রথম নিয়মটি হল যে বিজ্ঞপ্তিটি তখনই আসা উচিত যখন পদক্ষেপের প্রয়োজন হয়।

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

এই সমস্ত কিছুর একটি পার্শ্ব প্রতিক্রিয়া হিসাবে, যদি আমরা সংজ্ঞায়িত করে থাকি যে কোন ইভেন্টগুলির জন্য ক্রিয়া প্রয়োজন এবং এই ক্রিয়াগুলি কী হওয়া উচিত তা ভালভাবে বর্ণনা করেছি, এর অর্থ হল ক্রিয়াটি স্বয়ংক্রিয় হতে পারে। অর্থাৎ যা হয়। আমরা সতর্ক থেকে যাই. চলুন অ্যাকশনে যাই। আমরা এই কর্মের বর্ণনায় যাই। এবং তারপরে আমরা অটোমেশনে চলে যাই। অর্থাৎ যে কোনো অটোমেশন কোনো ঘটনার প্রতিক্রিয়া দিয়ে শুরু হয়।

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

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

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

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

SRE টুলস সম্পর্কে একটি প্রশ্ন ছিল। অর্থাৎ, বিশেষভাবে এমন কিছু আছে যা SREs ব্যবহার করবে যা অন্য সবাই করবে না। প্রকৃতপক্ষে, কিছু অত্যন্ত বিশেষায়িত ইউটিলিটি রয়েছে, এমন কিছু সফ্টওয়্যার রয়েছে যা, উদাহরণস্বরূপ, লোড অনুকরণ করে বা ক্যানারি A/B পরীক্ষায় নিযুক্ত থাকে। কিন্তু মূলত SRE টুলকিট হল যা আপনার ডেভেলপাররা ইতিমধ্যেই ব্যবহার করছেন। কারণ SRE সরাসরি উন্নয়ন দলের সাথে যোগাযোগ করে। এবং যদি আপনার কাছে বিভিন্ন সরঞ্জাম থাকে, তাহলে দেখা যাবে যে এটি সিঙ্ক্রোনাইজ হতে সময় নেয়। বিশেষ করে যদি SRE গুলি বড় দলে কাজ করে, বড় কোম্পানিতে যেখানে বেশ কয়েকটি দল থাকতে পারে, এটি কোম্পানি-ব্যাপী মানককরণ যা এখানে অনেক সাহায্য করবে, কারণ যদি 50 টি দলে 50 টি ভিন্ন ইউটিলিটি ব্যবহার করা হয়, তাহলে এর মানে হল SRE কে সেগুলি জানতে হবে সব এবং অবশ্যই এটি কখনই ঘটবে না। আর কাজের মান, মান নিয়ন্ত্রণে অন্তত কয়েকটি দল উল্লেখযোগ্য হারে কমে যাবে।

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

স্লার্ম এসআরই হল একটি তিন দিনের নিবিড় কোর্স যা আমি এখন যে বিষয়ে কথা বলছি তা নিয়ে কথা বলবে, তবে আরও গভীরতার সাথে, বাস্তব ক্ষেত্রে, অনুশীলনের সাথে, পুরো নিবিড়টি ব্যবহারিক কাজের লক্ষ্য। মানুষ দলে বিভক্ত হবে। আপনারা সবাই বাস্তব ক্ষেত্রে কাজ করবেন। সেই অনুযায়ী, আমাদের আছে Booking.com প্রশিক্ষক ইভান ক্রুগ্লোভ এবং বেন টাইলার। আমাদের কাছে সান ফ্রান্সিসকো থেকে গুগলের একটি চমৎকার ইউজিন বারাবাস আছে। এবং আমিও আপনাকে কিছু বলব। তাই আমাদের পরিদর্শন করতে ভুলবেন না.
সুতরাং, গ্রন্থপঞ্জি। SRE এর রেফারেন্স আছে। প্রথম একই বইতে, বা বরং SRE সম্পর্কে 2টি বইতে, Google দ্বারা লেখা। আরেকটা SLA, SLI, SLO এর উপর ছোট নিবন্ধ, যেখানে শর্তাবলী এবং তাদের আবেদনগুলি একটু বেশি বিস্তারিত। পরের 3টি বিভিন্ন কোম্পানিতে SRE-এর উপর রিপোর্ট। প্রথম - SRE এর কী, এটি Google-এর বেন ট্রেইনারের একটি মূল বক্তব্য। দ্বিতীয় - ড্রপবক্সে এসআরই. তৃতীয়টি আবার গুগলের কাছে এসআরই. থেকে চতুর্থ রিপোর্ট Netflix এ SRE, যার 5টি দেশে মাত্র 190 জন মূল SRE কর্মী রয়েছে৷ এই সবগুলি দেখা খুবই আকর্ষণীয়, কারণ যেভাবে DevOps মানে বিভিন্ন কোম্পানি এবং এমনকি বিভিন্ন দলের কাছে একেবারেই ভিন্ন জিনিস, SRE-এরও খুব আলাদা দায়িত্ব রয়েছে, এমনকি একই আকারের কোম্পানিতেও।

বিশৃঙ্খলা প্রকৌশল নীতির উপর আরও 2টি লিঙ্ক: (1), (2). এবং শেষে সিরিজ থেকে 3 টি তালিকা রয়েছে Awesome List about বিশৃঙ্খলা প্রকৌশল, সম্পর্কিত SRE এবং সম্বন্ধে SRE টুলকিট. SRE-তে তালিকাটি অবিশ্বাস্যভাবে বিশাল, এটি সব দিয়ে যাওয়ার প্রয়োজন নেই, প্রায় 200টি নিবন্ধ রয়েছে। আমি অত্যন্ত ক্ষমতা পরিকল্পনা এবং নির্দোষ পোস্টমর্টেম সম্পর্কে সেখান থেকে নিবন্ধ সুপারিশ.

আকর্ষণীয় নিবন্ধ: একটি জীবন পছন্দ হিসাবে SRE

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

PS: যারা পড়তে পছন্দ করেন তাদের জন্য এডুয়ার্ড রেফারেন্সের একটি তালিকা দিয়েছেন। যারা অনুশীলনে বুঝতে পছন্দ করেন তাদের স্বাগতম Slurme SRE.

উত্স: www.habr.com