ওয়েবসাইটগুলি (এমনকি এটিও) কখনও কখনও "রক্ষণাবেক্ষণের জন্য ডাউন" হয় কেন?


36

আমি ব্যক্তিগতভাবে এটি কখনও করি নি। এতগুলি সাইট কেন করে তা আমি বুঝতে পারি না, আপনি যদি একটি ডেভলপমেন্ট সার্ভারে আপনার বিকাশ করেন তবে আপনাকে কেন কখনও প্রযোজনার সাইটটি বন্ধ করার দরকার পড়বে?

আমি সবসময় এই সম্পর্কে ভাবছি।

তারা এই সময়ে কী করছে, এটি করার কী প্রয়োজন?


56
তারা সার্ভারগুলিতে ভ্যাকুয়াম টিউবগুলি প্রতিস্থাপন করছে।
মিপাদি

11
আমি ভেবেছিলাম তারা পাঞ্চকার্ডগুলি স্ট্যাক করছে।
ক্রিস্টোফার মাহান

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

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

1
আমার জিজ্ঞাসা করতে দেখা যায় যে 'একটি ডাটাবেস-ব্যাক ওয়েব অ্যাপে শূন্য (পরিকল্পিত) ডাউনটাইম অর্জনের জন্য আমি কী কৌশলগুলি ব্যবহার করতে পারি?' বিশেষত আপগ্রেডগুলির জন্য যেগুলি ডিবি স্কিমা পরিবর্তনের প্রয়োজন: সফ্টওয়্যারেনজেনারিং.স্ট্যাকেক্সেঞ্জিং
স্টিফেন

উত্তর:


59

বড় স্কেল সহ যে কোনও কিছুর জন্য বিগ কিকার হ'ল যদি কোনওভাবে ডেটাবেস স্কিমগুলি পরিবর্তন করা হয় তবে কারও কাছে সাধারণত কিছু বড়, কদর্য রক্ষণাবেক্ষণ স্ক্রিপ্ট থাকে।

এখন, এটি আপনার বিকাশ ডেটাসেটের সাথে চালাতে এক সেকেন্ড সময় নিতে পারে। তবে আপনি যখন টেরাবাইট এবং পেটাবাইটে ডেটা পরিমাপ শুরু করেন, এমনকি কোনও টেবিলে একটি কলাম যুক্ত করতে কয়েক ঘন্টা সময় নিতে পারে।

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


3
+1 - কেবল পঠনযোগ্য স্ট্যাক ওভারফ্লো খুব ভাল হবে না। গুগলে আপনি খুঁজে পেতে পারবেন না এমন খুব বেশি কিছু ঘটবে না :)
corsiKa

10
@ গ্লোকোডার: আপনি যখন গুগলে অনুসন্ধান করেন, তখন আপনি এসও উত্তর খুঁজে পাবেন।
ডোনাল ফেলো

@ ডোনাল যে ঠিক আমার বক্তব্য ছিল।
কর্সিকা 16

1
গুগল বিশাল এবং নিশ্চিত একটি বিশাল ডাটাবেস আছে; গুগলের জন্য আমি কখনই "রক্ষণাবেক্ষণের জন্য নীচে" দেখি না? (
গুগল.কম

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

7

রক্ষণাবেক্ষণের জন্য আপনি কোনও সাইট নামতে চান এমন বিভিন্ন কারণ রয়েছে। কয়েকটি নাম রাখার জন্য:

  • ডাটাবেস পরিবর্তন
  • ডাল পরিবর্তন
  • পরিষেবাগুলি আপডেট করা হচ্ছে

মূলত, যদি আপনার সাইটটি স্থির না হয়, লজিক আপডেট করার সময় আপনি এটিকে নামাতে চান অন্যথায় আপনার সাইটে আঘাতকারী লোকেরা ত্রুটি বা অপ্রত্যাশিত আচরণ পেতে পারে।

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


2
"ইন-প্রসেস" সেশনের স্থিতি ব্যবহার করে সেশনটি নষ্ট হবে। আপনি যদি প্রক্রিয়া সেশন স্থিতির বাইরে ব্যবহার করেন তবে ওয়েবকনফিগ পরিবর্তন করা থাকলে সেশনটি হারাবে না।
অ্যান্থনি

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

7

ভাল এটি কোনওভাবে বিমূর্ত প্রশ্ন - এমনকি এমন সাইটগুলি আমি দেখেছি যা এইচটিটিপি 500 এর পরিবর্তে "ডাউন ফর মেইনটেন্যান্স" ব্যবহার করেছে।

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

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


2
এইচটিটিপি 503 (500 এর পরিবর্তে) "রক্ষণাবেক্ষণের জন্য ডাউন" এর সঠিক স্থিতি কোড নয়?
নুবোক

4

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

আমি যে সংস্থার জন্য কাজ করেছি তার ৯০ এর দশকের শেষের দিকে একটি ই-কমার্স সাইট ছিল যা প্রতি মাসে sales 1,000,000 এরও বেশি বিক্রি করেছিল। কেউ প্রোডাকশন ডাটাবেস সার্ভারে ভুল ট্যাক্স টেবিল প্রচার করেছে। নিরাময়টি ছিল ব্যাকআপ থেকে ডিবি সার্ভারটি পুনরুদ্ধার করা, এবং শেষ ব্যাকআপ থেকে লেনদেনগুলি প্রয়োগ করা। এটি বেশ কয়েক ঘন্টা সময় নিয়েছিল, এই সময়টিতে ওয়েবসাইটটি অর্ডার নিতে অনুপলব্ধ ছিল। যেহেতু আদেশ অংশ এবং স্থির বিক্রয় ব্রোশিওর একই সাইটটিতে চলছে এবং অবিচ্ছেদ্য ছিল, তাই উভয়কেই নামতে হয়েছিল।

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


এমনকি এটি যথাযথ লোড ব্যালেন্সিং
দিয়েও

4

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

কীভাবে ডাউনটাইম এড়ানো যায়:

  • হার্ডওয়্যার পরিবেশনকারী পৃষ্ঠাগুলি বন্ধ করে দিচ্ছে: আপনার ওয়েবসাইটের সামনে যদি আপনার প্রক্সি থাকে তবে ব্যবহারকারীর কোনও প্রভাব ছাড়াই আপনি সেগুলি অফলাইনে রেখে দিতে পারেন
  • সার্ভারগুলি পুনরায় কনফিগার করা: উপরের মতো
  • ডাটাবেসে ডেটা আপডেট / পরিবর্তন করা: আপনি নিজের ওয়েবসাইটকে কেবল পঠন মোডে রাখতে পারেন ইত্যাদি ...

সাধারণত, একটি স্তরযুক্ত আর্কিটেকচারে, আপনি যে "শীর্ষ" এর নিকটবর্তী হন, রাষ্ট্রীয় (ওয়েবসভার বনাম ডাটাবেস) এর জন্য ডাউনটাইম এড়াতে এটি সবচেয়ে কঠিন।


4
ন্যাসডাকের সময়সূচী ডাউনটাইমের প্রায় 14 ঘন্টা সময় নেই?
পিটার টেলর

3

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


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

3

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

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

সুতরাং "রক্ষণাবেক্ষণের জন্য ডাউন" প্রায়শই "চাকরির বাইরে থাকা" এর আরেকটি শব্দ।


2

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

সমস্যাটি হ'ল 0-ডাউনটাইম সিস্টেমটি একটি নির্দিষ্ট স্কেলে তৈরি এবং রক্ষণাবেক্ষণের জন্য খুব ব্যয়বহুল। আপনার যেকোন জায়গায় রিডানডেন্সি দরকার, সর্বত্র ভারসাম্য ভারসাম্য, ডেটা প্রতিলিপি, সিঙ্ক্রোনাইজেশন। এগুলি কঠিন সমস্যা।

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

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

অর্থনীতি।

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


0

এতগুলি সাইট কেন করে তা আমি বুঝতে পারি না, আপনি যদি একটি ডেভলপমেন্ট সার্ভারে আপনার বিকাশ করেন তবে আপনাকে কেন কখনও প্রযোজনার সাইটটি বন্ধ করার দরকার পড়বে?

বিষ্ঠা ঘটে। আপনি যদি আপনার বিতরণযোগ্যদের গাণিতিক যাচাইয়ের কোনও ফর্ম না করেন ( এবং আপনার চশমাগুলি বৈধ ) তবে আপনি যতটা সতর্ক থাকুন না কেন, ছিটেফোঁটা হয়।

এছাড়াও, এমন সময় আছে যখন আপনাকে আপনার অবকাঠামোর মূল অংশে পরিবর্তন করতে হবে (বলুন, আপনার ডাটাবেস কাঠামোর পরিবর্তন) যার জন্য ডাউন-টাইম দরকার হয়।

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

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


1
গাণিতিক যাচাইকরণ কোনও চঞ্চলতা নয়; কখনও কখনও আপনি দেখতে পেয়েছেন যা যাচাই করেছেন তা যাচাই করতে চেয়েছিলেন তা নয়।
ডোনাল ফেলো

সত্য। তবে আমি যুক্তি দিয়েছি যে সমস্যাটি নির্দিষ্টকরণের আনুষ্ঠানিক যাচাইকরণের সাথে নয়, তবে সেই চশমাগুলির বৈধতার সাথে। যদি আপনার চশমাগুলি অবৈধ হয়, তবে স্পষ্টতই সমস্ত কিছু সেখান থেকে বিচ্ছিন্ন হয়ে যাবে, তবে চশমাগুলির বৈধতা ( "আমরা কি সত্যই উদ্দেশ্যমূলক ব্যবহারকারীর দ্বারা প্রয়োজনীয় উদ্দেশ্যে প্রয়োজনীয় জিনিসটি তৈরি করছি" ), যা যাচাইকরণের কেন্দ্রবিন্দু নয় (* "প্রদত্ত এই চশমা, আমরা কি এই জিনিসটি সঠিকভাবে তৈরি করছি, বা এটি নির্মিত যেতে পারে? "), অনানুষ্ঠানিক বা অন্যথায়। আমি অনুমান করি যে আমার
এটির

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

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

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

-2

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

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