স্কেলাবিলিটি নিয়ে কখন ভাবনা শুরু করবেন? [বন্ধ]


10

আমি একটি মজার কিন্তু ভয়ানক সমস্যা হচ্ছে। আমি একটি নতুন (আইফোন) অ্যাপ্লিকেশন চালু করতে চলেছি। এটি আমার নিজস্ব কাস্টম ব্যাকএন্ডে চলছে একটি টার্ন ভিত্তিক মাল্টিপ্লেয়ার গেম। তবে আমি আরম্ভ করতে ভয় পাচ্ছি।

কিছু কারণে, আমি মনে করি এটি কিছু বড় হতে পারে এবং এর জনপ্রিয়তা আমার দরিদ্র একাকী একক সার্ভার + মাইএসকিউএল ডাটাবেসকে হত্যা করবে।

একদিকে আমি ভাবছি যে এটি যদি বাড়ছে তবে আমি আরও ভালভাবে প্রস্তুত হয়েছি এবং এরই মধ্যে একটি স্কেবলযোগ্য অবকাঠামো তৈরি করেছি।

অন্যদিকে আমি কেবল বিশ্বে এটি বেরিয়ে আসার মতো অনুভব করি এবং দেখুন কী ঘটে।

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

আমি বিশেষজ্ঞ বা এটির সাথে অভিজ্ঞতাযুক্ত ব্যক্তিদের কাছ থেকে এ সম্পর্কে কিছু মতামত শুনতে পছন্দ করব। ধন্যবাদ!


1
দেখে মনে হচ্ছে সবাই এই উক্তিটির প্রথম অংশটি মিস করেছে: "আমাদের ছোট দক্ষতাগুলি ভুলে যাওয়া উচিত, সময়ের প্রায় 97% বলতে হবে" ... ছোট দক্ষতা + 97%
গাই স্যারটন

এটি একটি সমস্যা হয়ে উঠুক, এটি ভেঙে না থাকলে এটি ঠিক করবেন না। আমি এমন কয়েক ডজন প্রকল্প দেখেছি যেখানে লোকেরা স্কেলিবিলিটি উদ্বেগের সাথে ঝুলিয়ে রাখা হয়েছিল। অনুমান করো কি হয়েছিল? প্রকল্পের অনেকগুলি কখনই এটি দরজা থেকে সরিয়ে দেয় না।
কোডার্ট

"প্রায় 97% সময় বলুন" অপ্টিমাইজেশন প্রক্রিয়াটির অকাল অপ্টিমাইজেশনের মতো শোনাচ্ছে। ;) </kidding>
রব

উত্তর:


22

এটি আসলে বেশ সহজ পছন্দ।

এখনই, আপনার শূন্য ব্যবহারকারী রয়েছে এবং স্কেলাবিলিটি কোনও সমস্যা নয়।

আদর্শভাবে, আপনি এমন লক্ষ্যে পৌঁছাতে চান যেখানে আপনার মিলিয়ন মিলিয়ন ব্যবহারকারী রয়েছে এবং স্কেলাবিলিটি একটি সমস্যা হয়ে দাঁড়িয়েছে।

এখনই, আপনার কোনও স্কেলিবিলিটি সমস্যা নেই; আপনার ব্যবহারকারীর সংখ্যা আছে। আপনি যদি স্কেল্যাবিলিটি সমস্যা নিয়ে কাজ করেন তবে আপনি ব্যবহারকারীর সংখ্যাটি ঠিক করতে পারবেন না, যার অর্থ আপনি এখনও নেই এমন একটি সমস্যার সমাধান করেছেন, এবং আপনার যে সমস্যা রয়েছে তা আপনি সমাধান করতে পারবেন না। সর্বাধিক সম্ভাব্য ফলাফলটি হ'ল আপনার পণ্যটি এটি তৈরি করবে না এবং আপনার সমস্ত কাজ অকার্যকর হবে।

আপনি যদি ব্যবহারকারীর সংখ্যা নিয়ে কাজ করেন, আপনি এখনই আপনার সমস্যার সমাধান করবেন এবং তারপরে আপনি পরবর্তী সমস্যাটির দিকে মনোনিবেশ করতে পারেন, যা স্কেলিবিলিটি হতে পারে।

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

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


6

অপ্টিমাইজেশনের প্রয়োজন জানা না হওয়া পর্যন্ত অপ্টিমাইজ করার কোনও কারণ নেই। আপনি কীভাবে জানবেন যে অপটিমাইজেশন প্রয়োজন? আপনি মাপুন।

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


6

টিএল; ডিআর কোডের প্রথম লাইনটি লেখার আগে আপনার স্কেলিবিলিটি সম্পর্কে চিন্তা করা উচিত।

আগেরটা আগে. স্ক্যালাবিলিটি! = অপ্টিমাইজেশন

কোডের প্রথম লাইনটি লেখার আগে আপনার স্কেল্যাবিলিটি সম্পর্কে চিন্তা করা উচিত। এর অর্থ এই নয় যে আপনার খেলাটি হিট হওয়ার সম্ভাবনা ছাড়াই আপনি কিছু বিশাল অবকাঠামো তৈরি করেন। স্কেলিবিলিটি সম্পর্কে চিন্তাভাবনার অর্থ:

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

কিন্তু শোনাচ্ছে মত যদি আপনি ইতিমধ্যেই একটি কোডবেস আছে। প্রশ্ন এখন স্কেলিং কখন শুরু করবেন। এটি সম্পূর্ণভাবে আপনার কোডের উপর নির্ভরশীল।

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

যদি আপনার কোডটি স্কেল করে না বা বাধা থাকে তবে আপনার কাজ করার দরকার আছে। আপনার বাধা কী এবং তা ঠিক করার দরকার fix "কখন" জানতে খুব কষ্ট হয় hard কিছু পরিষেবা মালভূমি, কিছু অবিচ্ছিন্নভাবে বৃদ্ধি পায়, এবং কিছু বিস্ফোরিত হয়। স্কেলিংয়ের মতো কিছুতে কখন সংস্থান ফেলবেন তা সিদ্ধান্ত নেওয়া সাধারণত ব্যবসায়ের একটি কাজ এবং এটি ঝুঁকির মূল্যায়ন।

আপনার অবস্থানে , আমি একটি "বিটা" হিসাবে প্রকাশ করতে এবং ব্যবহারকারীর প্রত্যাশা পরিচালনা করতে পারি। এইভাবে আমি পণ্যটি বের করতে পারি এবং এটি কীভাবে উদ্ভাসিত হয় তা দেখুন।


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

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

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

3

সুতরাং, স্কেবলিবিলিটি সম্পর্কে আপনার দু'বার চিন্তা করা উচিত।

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

দ্বিতীয়বার স্কেলাবিলিটি বিবেচনা করার সময় জিনিসগুলির অগ্রিম পর্যায়ে যথেষ্ট অগ্রহণযোগ্যভাবে ধীর হয়ে যায়। এর অর্থ আপনার "খুব ধীর" অর্থ কী এবং আপনার জিনিস বোঝার মধ্যে কীভাবে প্রতিক্রিয়া দেখায় তা আপনার জানতে হবে। আপনার যদি এমন কোনও পরিষেবা থাকে যার ড্রাইভার (সম্ভবত qps) প্রতি মাসে N% দ্বারা বৃদ্ধি পায় তবে আপনার সংস্থান ব্যবহারের লোড-স্কোয়ার বা লিনিয়ার লিনিয়ার থাকলে আপনার "95% মেশিন রিসোর্সস গ্রহণ করা" থেকে আলাদা সময় হবে।

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

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


2

আপনার বিবরণ থেকে মনে হচ্ছে দুটি সম্ভাব্য ফলাফল রয়েছে:

  • গেমটি একটি ব্যর্থতা এবং তারপরে আপনি যত্ন করবেন না।
  • গেমটি সফল এবং তারপরে আপনার ব্যাকএন্ড লোডের সাথে ডিল করতে সক্ষম হবে না এবং ফলাফলটি ব্যর্থতা হবে।

হুম।

নিজেকে জিজ্ঞাসা করার জন্য এখানে কিছু প্রশ্ন রয়েছে:

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

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


1

আপনার সার্ভারটি ব্যবহারকারীরা ইন্টারেক্টিভভাবে ব্যবহার করবে। এর অর্থ হ'ল ল্যাটেন্সি ব্যবহারকারী-অভিজ্ঞতাকে খুব গভীরভাবে প্রভাবিত করছে। খারাপ লেটেন্সি সবসময় খারাপ ব্যবহারকারী-অভিজ্ঞতার ফলস্বরূপ।

ব্রায়ান বর্ণিত হিসাবে কমপক্ষে কিছু অ্যাড-হক লোড-টেস্টিং করুন।


আরও গুরুতর পদ্ধতির

কিছু সিমুলেশন চলছে এবং আপনার ব্যবহারকারী-অভিজ্ঞতাকে (ক্ষুদ্রতর নেটওয়ার্কের বিলম্ব সিমুলেশন ব্যবহার করে বা আপনার অ্যাপ্লিকেশনটির অভ্যন্তরে কেবল ঘুমাতে হবে) কী কী বিলম্ব করবে তা সন্ধান করুন। এটি কী স্বচ্ছলতাটি লক্ষণীয় হয়ে উঠছে, বিরক্তিকর হয়ে উঠছে এবং অকেজো হয়ে উঠছে তা সন্ধান করুন।

তারপরে অপ্টিমাইজ করার দিকের প্রথম ধাপটি আসে। আপনার সার্ভারের জন্য একটি এসএলএ নিয়ে সিদ্ধান্ত নিন: উদাহরণস্বরূপ বিরক্তিকর বিলম্বের সাথে খারাপতম 10% কল এবং ব্যবহার্য অলসতায় 1% কল। এই সীমাবদ্ধতার সাথে আপনি আপনার সার্ভারের কতজন ব্যবহারকারীকে সমর্থন করতে পারেন তা জানতে লোড-টেস্টিং ব্যবহার করতে পারেন।

বিলম্বতা পরিমাপ না করে খাঁটি থ্রুপুট পরীক্ষা করা (বা কমপক্ষে স্বয়ংক্রিয়ভাবে লোড পরীক্ষার সময় সার্ভারটি ব্যবহার করা) কার্যকর নয় কারণ এটি আপনাকে বোঝায় না যে পরিমাপিত থ্রুটপুট সংখ্যাগুলি সহনীয় ব্যবহারকারী-অভিজ্ঞতার ফলস্বরূপ কিনা।

গিল তেনি দ্বারা বিলম্বিতা পরিমাপ সম্পর্কে একটি খুব সুন্দর উপস্থাপনা: http://www.infoq.com/preferencesations/latency-pitfalls


1

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

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

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


"স্থপতি, বিকাশকারী এবং আপনার সংস্থার লোকদের জিজ্ঞাসা করুন ..." - প্রশ্নের কোনও কিছুই ইঙ্গিত দেয় না যে এটি কোনও সংস্থার জন্য, এটি কেবল এই লোকের পক্ষের প্রকল্পের জন্য।
গ্রাহাম
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.