কোড হিসাবে অবকাঠামো: এক্সপি ব্যবহার করে কীভাবে সমস্যাগুলি কাটিয়ে উঠতে হয়

হ্যালো, হাবর! পূর্বে, আমি কোড প্যারাডাইম হিসাবে অবকাঠামোর জীবন সম্পর্কে অভিযোগ করেছি এবং বর্তমান পরিস্থিতি সমাধানের জন্য কিছু অফার করিনি। আজ আমি আপনাকে বলতে ফিরে এসেছি কোন পন্থা এবং অনুশীলনগুলি আপনাকে হতাশার অতল গহ্বর থেকে বাঁচতে এবং পরিস্থিতিকে সঠিক দিকে নিয়ে যেতে সাহায্য করবে।

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

আমরা কে, কোথায় আছি এবং আমাদের কি সমস্যা আছে

আমরা বর্তমানে Sre অনবোর্ডিং টিমে আছি, যেটিতে ছয়জন প্রোগ্রামার এবং তিনজন অবকাঠামো প্রকৌশলী রয়েছে। আমরা সবাই ইনফ্রাস্ট্রাকচারকে কোড (IaC) হিসাবে লেখার চেষ্টা করছি। আমরা এটি করি কারণ আমরা মূলত জানি কীভাবে কোড লিখতে হয় এবং "গড়ের উপরে" বিকাশকারী হওয়ার ইতিহাস রয়েছে।

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

প্রযুক্তি স্ট্যাক আমরা আমাদের IaC ব্যবহার করি।

• সম্পদ তৈরির জন্য Terraform.
• ছবি একত্রিত করার জন্য প্যাকার. এগুলো হল Windows, CentOS 7 ইমেজ।
• Jsonnet drone.io-তে একটি শক্তিশালী বিল্ড তৈরি করতে, সেইসাথে প্যাকার json এবং আমাদের টেরাফর্ম মডিউল তৈরি করতে।
• আকাশী নীল।
• ছবি প্রস্তুত করার সময় উত্তরযোগ্য।
• অক্জিলিয়ারী সার্ভিস এবং প্রভিশনিং স্ক্রিপ্টের জন্য পাইথন।
• এবং এই সব VSCode মধ্যে প্লাগইন সঙ্গে দলের সদস্যদের মধ্যে ভাগ করা.

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

আমরা বর্তমানে নিম্নলিখিত IaC সমস্যাগুলির সাথে লড়াই করছি:

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

উদ্ধারের জন্য এক্সট্রিম প্রোগ্রামিং (এক্সপি)

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

আপনার শিল্পে XP পদ্ধতির প্রযোজ্যতা পরীক্ষা করা হচ্ছেXP যে পরিবেশের জন্য উপযুক্ত এবং এটি আমাদের সাথে কীভাবে সম্পর্কিত তা এখানে একটি বর্ণনা রয়েছে:

1. গতিশীলভাবে সফ্টওয়্যার প্রয়োজনীয়তা পরিবর্তন. শেষ লক্ষ্য কী তা আমাদের কাছে পরিষ্কার ছিল। কিন্তু বিস্তারিত ভিন্ন হতে পারে। আমরা নিজেরাই সিদ্ধান্ত নিই যে আমাদের কোথায় ট্যাক্সি করতে হবে, তাই প্রয়োজনীয়তা পর্যায়ক্রমে পরিবর্তিত হয় (প্রধানত নিজেদের দ্বারা)। যদি আমরা এসআরই টিম নিই, যেটি নিজেই অটোমেশন করে এবং নিজেই প্রয়োজনীয়তা এবং কাজের সুযোগ সীমিত করে, তাহলে এই পয়েন্টটি ভালভাবে মানায়।

2. নতুন প্রযুক্তি ব্যবহার করে নির্দিষ্ট সময়ের প্রকল্পের কারণে সৃষ্ট ঝুঁকি। আমাদের কাছে অজানা কিছু জিনিস ব্যবহার করার সময় আমরা ঝুঁকির সম্মুখীন হতে পারি। এবং এটি আমাদের ক্ষেত্রে 100%। আমাদের পুরো প্রকল্পটি এমন প্রযুক্তির ব্যবহার ছিল যা আমরা সম্পূর্ণরূপে পরিচিত ছিলাম না। সাধারণভাবে, এটি একটি ধ্রুবক সমস্যা, কারণ ... অবকাঠামো খাতে প্রতিনিয়ত অনেক নতুন প্রযুক্তির উদ্ভব হচ্ছে।

3,4। ছোট, সহ-অবস্থিত বর্ধিত উন্নয়ন দল। আপনি যে স্বয়ংক্রিয় প্রযুক্তি ব্যবহার করছেন তা ইউনিট এবং কার্যকরী পরীক্ষার অনুমতি দেয়। এই দুটি পয়েন্ট আমাদের পুরোপুরি উপযুক্ত নয়। প্রথমত, আমরা একটি সমন্বিত দল নই, এবং দ্বিতীয়ত, আমাদের মধ্যে নয়জন আছে, যাকে একটি বড় দল হিসেবে বিবেচনা করা যেতে পারে। যদিও, একটি "বড়" দলের কিছু সংজ্ঞা অনুযায়ী, অনেক 14+ লোক।

আসুন কিছু এক্সপি অনুশীলন দেখি এবং কীভাবে তারা প্রতিক্রিয়ার গতি এবং গুণমানকে প্রভাবিত করে।

XP ফিডব্যাক লুপ নীতি

আমার বোঝার মধ্যে, প্রতিক্রিয়া হল প্রশ্নের উত্তর, আমি কি সঠিক কাজ করছি, আমরা কি সেখানে যাচ্ছি? XP এর জন্য একটি ঐশ্বরিক স্কিম আছে: একটি সময় প্রতিক্রিয়া লুপ। মজার বিষয় হল যে আমরা যত কম, তত দ্রুত আমরা প্রয়োজনীয় প্রশ্নের উত্তর দিতে ওএস পেতে সক্ষম হব।

এটি আলোচনার জন্য একটি বরং আকর্ষণীয় বিষয়, যে আমাদের আইটি শিল্পে দ্রুত একটি ওএস পাওয়া সম্ভব। কল্পনা করুন যে ছয় মাস ধরে একটি প্রকল্প করা কতটা বেদনাদায়ক এবং তবেই খুঁজে বের করুন যে একেবারে শুরুতে একটি ভুল ছিল। এটি ডিজাইনে এবং জটিল সিস্টেমের যেকোনো নির্মাণে ঘটে।

IaC এর ক্ষেত্রে, প্রতিক্রিয়া আমাদের সাহায্য করে। আমি অবিলম্বে উপরের চিত্রটিতে একটি ছোট সামঞ্জস্য করব: রিলিজ প্ল্যানের একটি মাসিক চক্র নেই, তবে দিনে কয়েকবার ঘটে। এই OS চক্রের সাথে আবদ্ধ কিছু অনুশীলন রয়েছে যা আমরা আরও বিশদে দেখব।

গুরুত্বপূর্ণ: প্রতিক্রিয়া উপরে বর্ণিত সমস্ত সমস্যার সমাধান হতে পারে। এক্সপি অনুশীলনের সাথে মিলিত, এটি আপনাকে হতাশার অতল গহ্বর থেকে বের করে আনতে পারে।

কীভাবে নিজেকে হতাশার অতল গহ্বর থেকে বের করে আনবেন: তিনটি অনুশীলন

পরীক্ষা

এক্সপি ফিডব্যাক লুপে পরীক্ষাগুলি দুবার উল্লেখ করা হয়েছে। এটা ঠিক যে মত না. এগুলি সম্পূর্ণ এক্সট্রিম প্রোগ্রামিং কৌশলের জন্য অত্যন্ত গুরুত্বপূর্ণ।

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

একটি ক্লাসিক টেস্টিং পিরামিড রয়েছে, যা দেখায় যে আরও পরীক্ষা হওয়া উচিত।

কিভাবে এই কাঠামো একটি IaC প্রকল্পে আমাদের জন্য প্রযোজ্য? আসলে... মোটেও না।

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

  ইন্টিগ্রেশন পরীক্ষাগুলি এইরকম দেখায়।

  
  
  ড্রোন সিআই-তে ছবি তৈরি করার সময় এটি একটি উদাহরণ। তাদের কাছে পৌঁছানোর জন্য, প্যাকার ইমেজ গঠনের জন্য আপনাকে 30 মিনিট অপেক্ষা করতে হবে, তারপরে তাদের পাস করার জন্য আরও 15 মিনিট অপেক্ষা করতে হবে। কিন্তু তারা বিদ্যমান!

  ছবি যাচাইকরণ অ্যালগরিদম

  1. প্যাকারকে প্রথমে ছবিটি সম্পূর্ণভাবে প্রস্তুত করতে হবে।
  2. পরীক্ষার পাশে একটি স্থানীয় রাজ্যের সাথে একটি টেরাফর্ম রয়েছে, যা আমরা এই চিত্রটি স্থাপন করতে ব্যবহার করি।
  3. উন্মোচন করার সময়, ছবিটির সাথে কাজ করা সহজ করতে কাছাকাছি একটি ছোট মডিউল ব্যবহার করা হয়।
  4. একবার ইমেজ থেকে VM স্থাপন করা হলে, চেক শুরু হতে পারে। মূলত, চেক গাড়ী দ্বারা বাহিত হয়. এটি স্টার্টআপে স্ক্রিপ্টগুলি কীভাবে কাজ করে এবং ডেমনগুলি কীভাবে কাজ করে তা পরীক্ষা করে। এটি করার জন্য, ssh বা winrm-এর মাধ্যমে আমরা নতুন উত্থাপিত মেশিনে লগ ইন করি এবং কনফিগারেশন স্ট্যাটাস বা পরিষেবাগুলি চালু আছে কিনা তা পরীক্ষা করি।

• টেরাফর্মের জন্য মডিউলগুলিতে ইন্টিগ্রেশন পরীক্ষার সাথে পরিস্থিতি একই রকম। এই ধরনের পরীক্ষার বৈশিষ্ট্যগুলি ব্যাখ্যা করে এখানে একটি ছোট টেবিল রয়েছে।

  
  
  পাইপলাইনে প্রতিক্রিয়া প্রায় 40 মিনিট। সবকিছু খুব দীর্ঘ সময়ের জন্য ঘটে। এটি রিগ্রেশনের জন্য ব্যবহার করা যেতে পারে, তবে নতুন বিকাশের জন্য এটি সাধারণত অবাস্তব। আপনি যদি এটির জন্য খুব প্রস্তুত হন, চলমান স্ক্রিপ্টগুলি প্রস্তুত করুন, তাহলে আপনি এটি 10 ​​মিনিটে কমাতে পারেন। কিন্তু এগুলি এখনও ইউনিট পরীক্ষা নয়, যা 5 সেকেন্ডে 100 টুকরা করে।

চিত্র বা টেরাফর্ম মডিউলগুলি একত্রিত করার সময় ইউনিট পরীক্ষার অনুপস্থিতি কাজটিকে আলাদা পরিষেবাগুলিতে স্থানান্তরিত করতে উত্সাহিত করে যা কেবল REST বা পাইথন স্ক্রিপ্টের মাধ্যমে চালানো যেতে পারে।

উদাহরণস্বরূপ, আমাদের নিশ্চিত করা দরকার যে ভার্চুয়াল মেশিনটি শুরু হলে, এটি পরিষেবাতে নিজেকে নিবন্ধিত করে স্কেলএফটি, এবং ভার্চুয়াল মেশিনটি ধ্বংস হয়ে গেলে, এটি নিজেই মুছে ফেলে।

যেহেতু আমাদের একটি পরিষেবা হিসাবে ScaleFT আছে, তাই আমরা API এর মাধ্যমে এটির সাথে কাজ করতে বাধ্য হই। সেখানে একটি মোড়ক লেখা ছিল যা আপনি টেনে বলতে পারেন: "যাও এবং এটি এবং এটি মুছুন।" এটি সমস্ত প্রয়োজনীয় সেটিংস এবং অ্যাক্সেস সংরক্ষণ করে।

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

পরীক্ষার ফলাফল: ইউনিট পরীক্ষা, যা এক মিনিটের মধ্যে OS দিতে হবে, তা দেয় না। এবং পিরামিডের উচ্চতর পরীক্ষাগুলি কার্যকর, তবে সমস্যাগুলির একটি অংশই কভার করে।

জোড় প্রোগ্রামিং

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

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

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

নীচে IaC-তে কাজ করার ক্ষেত্রে জোড়া প্রোগ্রামিং শৈলী এবং তাদের প্রযোজ্যতা রয়েছে:

1. ক্লাসিক, অভিজ্ঞ+অভিজ্ঞ, টাইমার দ্বারা পরিবর্তন। দুটি ভূমিকা - ড্রাইভার এবং নেভিগেটর। দুইজন মানুষ. তারা একই কোডে কাজ করে এবং একটি নির্দিষ্ট পূর্বনির্ধারিত সময়ের পরে ভূমিকা পরিবর্তন করে।

আসুন শৈলীর সাথে আমাদের সমস্যার সামঞ্জস্য বিবেচনা করি:

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

IaC-তে এই স্টাইল ব্যবহার করার প্রধান সমস্যা হল কাজের অসম গতি। ঐতিহ্যগত সফ্টওয়্যার উন্নয়নে, আপনার একটি খুব অভিন্ন আন্দোলন আছে। আপনি পাঁচ মিনিট ব্যয় করে N লিখতে পারেন। 10 মিনিট ব্যয় করুন এবং 2N, 15 মিনিট - 3N লিখুন। এখানে আপনি পাঁচ মিনিট ব্যয় করতে পারেন এবং N লিখতে পারেন, এবং তারপরে আরও 30 মিনিট ব্যয় করে N এর দশমাংশ লিখতে পারেন। এখানে আপনি কিছুই জানেন না, আপনি আটকে আছেন, বোকা। তদন্তে সময় লাগে এবং প্রোগ্রামিং থেকে বিভ্রান্ত হয়।

উপসংহার: বিশুদ্ধ আকারে এটি আমাদের জন্য উপযুক্ত নয়।

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

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

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

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

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

উপসংহার: এটি সম্ভাব্যভাবে ব্যবহার করা যেতে পারে, আমরা চেষ্টা করা ছেড়ে দিচ্ছি না।

4. মোবিং, ঝাঁকুনি এবং সমস্ত পরিচিত কিন্তু তালিকাভুক্ত শৈলী নয় আমরা এটা বিবেচনা না, কারণ আমরা এটি চেষ্টা করিনি এবং আমাদের কাজের প্রসঙ্গে এটি সম্পর্কে কথা বলা অসম্ভব।

জোড়া প্রোগ্রামিং ব্যবহার করার সাধারণ ফলাফল:

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

5. এই সত্ত্বেও, সাফল্য ছিল. আমরা আমাদের নিজস্ব পদ্ধতি "কনভারজেন্স - ডাইভারজেন্স" নিয়ে এসেছি। আমি সংক্ষেপে বর্ণনা করব কিভাবে এটি কাজ করে।

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

পরিকল্পনা এবং যোগাযোগ

অনুশীলনের শেষ ব্লক যার মাধ্যমে OS সমস্যাগুলি সমাধান করা হয় তা হল কাজগুলির সাথে কাজ করার সংগঠন। এর মধ্যে অভিজ্ঞতার আদান-প্রদানও অন্তর্ভুক্ত যা জুটির কাজের বাইরে। আসুন তিনটি অনুশীলন দেখি:

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

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

কাজের ভিজ্যুয়াল ভিশনের সুবিধা:

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

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

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

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

একে অপরের কাছে করা কাজটি প্রদর্শন এবং তারপর আলোচনা করার মধ্যে সমাধান পাওয়া গেছে। আমরা সপ্তাহে একবার এক ঘন্টার জন্য দেখা করি এবং আমরা গত সপ্তাহে যে কাজগুলি করেছি তার সমাধানগুলির বিশদ বিবরণ দেখাই৷

প্রদর্শনের সময়, টাস্কের বিশদ প্রকাশ করা এবং এর ক্রিয়াকলাপ প্রদর্শন করতে ভুলবেন না।

একটি চেকলিস্ট ব্যবহার করে প্রতিবেদনটি পরিচালনা করা যেতে পারে।1. প্রসঙ্গে লিখুন। কাজটি কোথা থেকে এসেছে, কেন এটি এমনকি প্রয়োজনীয় ছিল?

2. আগে কীভাবে সমস্যাটি সমাধান করা হয়েছিল? উদাহরণস্বরূপ, বিশাল মাউস ক্লিক করা প্রয়োজন ছিল, বা কিছু করা অসম্ভব ছিল।

3. আমরা কিভাবে এটা উন্নত. উদাহরণস্বরূপ: "দেখুন, এখন স্ক্রিপ্টোসিক আছে, এখানে রিডমি আছে।"

4. দেখান কিভাবে এটি কাজ করে। কিছু ব্যবহারকারীর দৃশ্য সরাসরি বাস্তবায়ন করার পরামর্শ দেওয়া হয়। আমি X চাই, আমি Y করি, আমি Y (বা Z) দেখতে পাচ্ছি। উদাহরণস্বরূপ, আমি NGINX স্থাপন করি, url ধূমপান করি এবং 200 OK পাই। যদি ক্রিয়াটি দীর্ঘ হয় তবে এটি আগে থেকে প্রস্তুত করুন যাতে আপনি এটি পরে দেখাতে পারেন। এটি ভঙ্গুর হলে ডেমোর এক ঘন্টা আগে এটিকে খুব বেশি না ভাঙার পরামর্শ দেওয়া হয়।

5. ব্যাখ্যা করুন যে সমস্যাটি কতটা সফলভাবে সমাধান করা হয়েছে, কোন অসুবিধাগুলি রয়ে গেছে, কোনটি সম্পূর্ণ হয়নি, ভবিষ্যতে কোন উন্নতি সম্ভব। উদাহরণস্বরূপ, এখন CLI, তারপর CI তে সম্পূর্ণ অটোমেশন থাকবে।

প্রতিটি স্পিকারের জন্য এটি 5-10 মিনিট রাখার পরামর্শ দেওয়া হয়। যদি আপনার বক্তৃতা স্পষ্টতই গুরুত্বপূর্ণ হয় এবং আরও বেশি সময় নেয়, তাহলে sre-টেকওভার চ্যানেলে এটিকে আগে থেকেই সমন্বয় করুন।

মুখোমুখি অংশের পরে থ্রেডে সর্বদা একটি আলোচনা থাকে। আমাদের কাজগুলিতে আমাদের প্রয়োজনীয় প্রতিক্রিয়া এখানেই উপস্থিত হয়।

ফলস্বরূপ, যা ঘটছে তার উপযোগিতা নির্ধারণের জন্য একটি জরিপ করা হয়। এটি বক্তৃতার সারাংশ এবং কাজের গুরুত্ব সম্পর্কে প্রতিক্রিয়া।

দীর্ঘ উপসংহার এবং পরবর্তী কি

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

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

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

OS-কে প্রভাবিত করার উচ্চ-স্তরের উপায় - পরিকল্পনা এবং কাজগুলির সাথে কাজ করা সুনির্দিষ্টভাবে প্রভাব তৈরি করে: উচ্চ-মানের জ্ঞান বিনিময় এবং উন্নত উন্নয়ন গুণমান।

এক লাইনে সংক্ষিপ্ত উপসংহার

• HR অনুশীলনকারীরা IaC-তে কাজ করে, কিন্তু কম দক্ষতার সাথে।
• যা কাজ করে তা শক্তিশালী করুন।
• আপনার নিজস্ব ক্ষতিপূরণমূলক প্রক্রিয়া এবং অনুশীলন নিয়ে আসুন।

উত্স: www.habr.com