Чому веб-сайти (навіть цей) іноді "вниз для обслуговування"?

Я особисто ніколи цього не робив. Я не розумію, чому так багато сайтів, якщо ви займаєтеся розробкою на сервері розробок, чому б вам коли-небудь потрібно було закрити свій виробничий сайт?

Я завжди цікавився цим.

Що вони роблять за цей час, для чого потрібно це робити?

Великий запуск для будь-якого великого масштабу полягає в тому, що якщо хтось змінює схеми баз даних, для запуску зазвичай існують декілька великих, неприємних сценаріїв обслуговування.

Тепер це може зайняти секунду або близько того, щоб запустити ваш набір даних про розробку. Але коли ви починаєте вимірювати дані в терабайт і петабайт, навіть додавання одного стовпчика до таблиці може зайняти години.

Тож незалежно від того, наскільки швидким та автоматизованим є розгортання, у вас все ще виникають проблеми зі збереженням даних. Якщо ви плануєте дуже добре, ви можете встановити дзеркало для читання сайту, поки ви проходите цей процес, але для багатьох сайтів лише для читання безглуздо і, таким чином, не варто докладати зусиль.

Існує низка причин, чому ви можете зняти сайт для обслуговування. Назвати декілька:

• Зміни бази даних
• Зміни DAL
• Оновлення послуг

Якщо ваш сайт не є статичним, під час оновлення логіки ви хочете зняти його, інакше люди, які потрапляють на ваш сайт, можуть отримати помилки або несподівану поведінку.

Крім того, якщо ви торкаєтесь web.config (в ASP.NET) для свого сайту, вам слід спершу зняти його для обслуговування, оскільки це вибухне сеансом для користувачів. Таким чином, якби вони опинилися посеред чогось, це було б втрачено.

Ну це якимось абстрактне питання - я навіть бачив сайти, які замість HTTP 500 використовували "Вниз для обслуговування".

Для веб-сайтів іноді потрібно зробити оновлення. Наприклад, якщо ви змінюєте базу даних, ви не хочете, щоб за цей час жоден інший користувач торкався цієї бази даних. Якщо база даних офлайн, сайт також повинен бути вимкнено, оскільки показ SqlException не дуже приємний. Іншою причиною є певна несправність HW або збій системи (наприклад, витоку ресурсів), що вимагає додатків або навіть перезавантаження системи.

Одного разу я брав участь у вдосконаленні системи Інтернет-банкінгу в одному з найбільших банків моєї країни. Весь процес оновлення веб-сайтів, середнього рівня та баз даних займав три дні, коли система була офлайн для клієнтів. Він також включав повне резервне копіювання всього, щоб у разі відмови систему можна було повернути до старої версії.

Сервери потребують запуску патчів, а для багатьох операційних систем ці патчі потребують перезавантаження. Так що це одна категорія простою. Багато компаній планують перезавантажити з патчів для низького часу використання, наприклад, у неділю вранці. Якщо патчів немає, вони все одно перезавантажують сервери в регулярно запланований час технічного обслуговування (це похмілля від NT4 днів, коли певні лічильники переповнювались кожні півтора тижні, тому перезавантаження щотижня запобігало виникненню інших помилок).

Одна компанія, над якою я працював, ще в кінці 90-х років створила сайт електронної комерції, який приносив більше 1 000 000 доларів продажів на місяць. Хтось рекламував неправильну таблицю податків на сервері виробничої бази даних. Ліком було відновити сервер db з резервного копіювання та застосувати транзакції з часу останньої резервної копії. Це зайняло кілька годин, протягом яких веб-сайт був недоступний для прийому замовлень. Оскільки порція замовлень та статичні брошури з продажу товарів працювали на одному сайті та були нероздільними, обидва повинні були зійти.

В одній компанії, над якою я працював, був неправильний текст, вставлений у неправильне місце, і генеральний директор перекинувся, і веб-сайт був знятий "для обслуговування", в той час як макет і текст були "виправлені", а відповідний потерпілий звинуватив і звільнив.

Хоча інші відповіді правильні, ви завжди можете уникнути простоїв, використовуючи правильну архітектуру. Але це коштує, і ця вартість може не варто: година простою коштує амазону чи інфраструктуру, що стоїть за NASDAQ, багато. Переповнення стека ? Швидше за все, не так вже й багато.

Як уникнути простоїв:

• вимкнення сторінок, що обслуговують обладнання: якщо у вас є проксі-сервери перед веб-сайтом, ви можете замість цього розмістити їх у режимі офлайн, не впливаючи на користувача
• перенастроювання серверів: те саме, що вище
• оновлення / зміна даних у базах даних: ви можете перевести веб-сайт у режим лише для читання тощо ...

Взагалі, в шаруватій архітектурі, чим ближче до "вершини" ви, тим важче уникнути простоїв, те саме, що і для статей (веб-сервер проти бази даних).

Сайт може запланувати регулярний час простою, навіть якщо нічого не робити щоразу, коли запланований час простою. Роблячи таким чином, вони отримують користувачі звикли до того , що сайт буде вниз в протягом певної кількості часу кожен так часто , так що , коли робота дійсно потрібно зробити, користувачі не скаржаться так багато.

У цьому також є психологічна та маркетингова сторона. У деяких випадках (я наважуся сказати більшість випадків, але я не такий сміливий * g *) читання "Вниз для обслуговування" також може означати "Сервер вийшов з ладу або вийшов з експлуатації з будь-якої іншої причини".

Я бачив це досить часто. Зазвичай, як розробник, ви хочете "справжніх" повідомлень про помилки, які говорять приблизно так: "На жаль, зараз ми відчуваємо високе завантаження, і не всі запити можуть бути оброблені", але деякі люди з маркетингу скажуть вам "чувак, ви не можете скажіть замовнику, що у нас є проблеми. Скажіть їм, що ми проводимо планове обслуговування - це буде виглядати набагато краще ".

Тож "Вниз для технічного обслуговування" часто є лише черговим терміном "поза експлуатацією".

Жоден сервер НЕ ПОТРІБНІ, щоб перейти на технічне обслуговування. Ви можете уникати цього будь-чого, будь-якого масштабу, зміни БД, оновлення сервера тощо.

Проблема полягає в тому, що створити та підтримувати систему для простоїв у певному масштабі дуже дорого. Вам потрібна надмірність скрізь, збалансування завантаження скрізь, реплікація даних, синхронізація. Це важкі проблеми.

По суті, вам потрібно досягти рівня можливості випустити Netflix Chaos Monkey в prod, щоб бути впевненим, що він працює, навіть якщо частина вашої системи зайнята оновленням або просто не синхронізована. Це, безумовно, можливо. Це також дуже дорого, вимагає багато часу і багато експертів для роботи над проблемою.

Переміщення сайту в режимі обслуговування може бути обраним вами посередництвом, тому що ви не хочете вкладати стільки коштів, щоб уникнути того, щоб раз на час забирати сайт.

Економіка.

Звичайно, якщо ви обираєте дорогу часу вниз вниз, ваш сайт отримає більше, ніж просто доступність, він також отримає надійність, оскільки ці найкращі практики служать обом цілям.

Я не розумію, чому так багато сайтів, якщо ви займаєтеся розробкою на сервері розробок, чому б вам коли-небудь потрібно було закрити свій виробничий сайт?

Лайно буває. Якщо ви не робите якоїсь форми математичної перевірки своїх результатів ( і ваші характеристики є дійсними ), як би ви не були обережні, лайно трапляється.

Крім того, бувають випадки, коли вам доведеться змінити ключовий елемент вашої інфраструктури (скажімо, зміни в структурі вашої бази даних), які вимагають простою.

Якщо ви не розробляєте критичну систему (скажімо, систему п’ять дев'ять чи шість дев'ять ), відповідальною та економічно вигідною справою є побудова системи з прийняттям простоїв як частини реальності.

Крім того, ви переймете цей принцип далі, зробивши керований час керованим і придатним до планування (або, принаймні, виявленого) з чітким розумінням та процедурою ефективного відновлення.

Колись наш веб-сайт був зламаний (старий сервер IIS6 та Windows 2003 кілька років тому). поки ми працювали над реставрацією, ми поміщали сторінку "на обслуговування" на кілька годин ....