- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Все еще считаете, что у вас нет ошибки?
Дорогой, сдай сначала сессию, а потом компостируй мозг своими гениальными познаниями теорвера людям с двумя техническими высшими.
yesRuslik, по идеи чем больше фронтендов тем выше отказоустойчивость(есть 3 "слоя": dns хостинг, фронтенд, основные сервера; и по идеи вероятность отказа всей системы - произведение вероятностей отказа всех "слоёв", дублирование фронтенда улучшает отказоустойчивость "слоя" фронтендов и ведёт к увеличению общей отказоустойчивости).
Опять же правильно "почти".
Вероятность успешной работы системы = произведение вероятностей успешной работы всех систем.
Вероятность сбоя сложной системы = 1 - вероятность успешной работы.
====
Если сбой уже наступил - используется более дискретный подход:
Ждем поднятия этого сервиса (если не критическая ошибка бекенда)?
Переключаемся на уже поднятый запасной сервис, с отставанием по данным (синхронизация по времени)?
Поднимаемся из резервной копии на еще не запущенный запасной сервис ?
ПРИЧЕМ!!
потеря информации за дельта T может быть дороже лишних 30 минут простоя.
Потому банки категорически предпочитают "полежать" лишних 30 минут, чем раскатывать бакапы. А хостеры наоборот.
Пока в голове созрел вот такой вот план:
1) DNS переведём на сервис, который позволяет делать "DNS+failover"(если можно получить скорость отключения нерабочего фронтенда порядка минуты).
2) В качестве параллельных фронтендов будут два VPS
3) Фронтенды будут подтягивать сайты с двух серверов(один основной и один дублирующий).
Хороший план. Коварный.
1. Получить скорость отключения порядка минуты можно....
Но на практике будет 2-4 минуты (ибо "бюрократия" :) ).
И еще момент - при каждом обращении к странице броузер не посылает новые запросы в DNS.
Если клиент УЖЕ находился на сайте в момент аварии - переключение DNS ему поможет не слишком эффективно.
При этом за минуту можно успеть поднять фронтенд.
2. Надежность VPS по определению ниже чем надежность оборудования, на котором он базируется.
Конечно его в одном месте можно быстро погасить, в другом поднять, но факт "сбоя" уже
случился и система завертелась.
А синхронная перезагрузка 2-х VPS-ов? Как себя должна вести система?
3. Синхронизация (причем, простите за тавтологию - синхронная) данных между основным и дублирующим сервером, и взаимная смена ролей - это основной гемор в вашем проекте.
З.Ы. У меня второе высшее как раз защита информации. Включает в себя анализ рисков и т.д.
ЕСЛИ ваш проект действительно денежный - могу вам на платной основе помочь действительно корректно посчитать ваши риски и прикинуть оптимальный аптайм с средства борьбы за него.
И еще момент - при каждом обращении к странице броузер не посылает новые запросы в DNS.
Однако, IE посылает, ЕСЛИ произошла ошибка подключения.
Другие браузеры по-разному, в целом достаточно практично. Где-то было исследование.
Дорогой, сдай сначала сессию, а потом компостируй мозг своими гениальными познаниями теорвера людям с двумя техническими высшими.
Если вы таким образом заявляете про свои два технических высших, то могу только с сожалением предположить, что ваши годы учебы потрачены впустую: ладно уже пробелы в математике, но вы показываете и недопустимое остутсвие навыков анализа проблем и ошибок.
Лучше не вынимайте свои дипломы и мантию академика бобруйской международной академии наук, а примите или опровергните доказательство ошибки в вашем расчете, это будет достовернее:
Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту или за час. Вы уверены, что с вероятностью 26% получите отказ? Обратитесь 520 раз за час - по вашей методике подсчета вероятность отказа будет 92%. Повторяйте эту серию обращений каждый час в течение года, у вас все эти разы вероятность отказа должна быть 92%. Все еще считаете, что у вас нет ошибки?
Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту или за час. Вы уверены, что с вероятностью 26% получите отказ? Обратитесь 520 раз за час - по вашей методике подсчета вероятность отказа будет 92%. Повторяйте эту серию обращений каждый час в течение года, у вас все эти разы вероятность отказа должна быть 92%. Все еще считаете, что у вас нет ошибки?
Если за один час имеем 99,5% аптайма, то имеем простоя в этот час цельных 18 секунд.
и при этом каждые 7 секунд проверяем состояние сайта.
Вот и подумай, с какой вероятностью эти 18 секунд простоя пролетят мимо проверок, которые происходят каждые 7 секунд...
Садись, два. На пересдачу.
---------- Добавлено 15.06.2012 в 16:15 ----------
Однако, IE посылает, ЕСЛИ произошла ошибка подключения.
Другие браузеры по-разному, в целом достаточно практично. Где-то было исследование.
Честно - не знал. Это хорошо характеризует разработчиков броузеров :).
Пруфлинк не найдете, с исследованиями?
Если за один час имеем 99,5% аптайма, то имеем простоя в этот час цельных 18 секунд.
и при этом каждые 7 секунд проверяем состояние сайта.
Вот и подумай, с какой вероятностью эти 18 секунд простоя пролетят мимо проверок, которые происходят каждые 7 секунд...
Садись, два. На пересдачу.
а ничего что эти 18 секунд могут располагаться в этом часе как угодно, хоть подряд, хоть частями? и так же с какой радости раз в 7 секунд? просто 52 раза, и эти разы могу размещаться как удогно. 18 секунд в начале часа, а 52 раза в конце, не может быть? так вот вероятность как раз и должна показать ШАНС ИХ СОВПАДЕНИЯ.
Короче cvss прав
Вероятность отказа для 99.5% аптайма - 0.005. Вероятность захода бота на главную страницу при периодичности раз в неделю и 10 секунд на выполнение запроса - 0.0000165. Вероятность одновременного происхождения обоих событий равна произведению - 0.0000000825.
Обратитесь 520 раз за час - по вашей методике подсчета вероятность отказа будет 92%. Повторяйте эту серию обращений каждый час в течение года, у вас все эти разы вероятность отказа должна быть 92%. Все еще считаете, что у вас нет ошибки?
Да, если каждый час будет 18 секунд простоя, то каждый час я увижу хоть одну ошибку, с вероятностью 92%. Или не увижу ни одной ошибки, с вероятностью 8%.
Да, если каждый час будет 18 секунд простоя, то каждый час я увижу хоть одну ошибку, с вероятностью 92%. Или не увижу ни одной ошибки, с вероятностью 8%.
Это хлеб по-английски...
Задам наводящий вопрос-загадку:
Монетку подбросили 100 раз и все сто раз выпал орел.
Какова вероятность (по вашему методу расчета) что на 101 раз выпадет орел?
а ничего что эти 18 секунд могут располагаться в этом часе как угодно, хоть подряд, хоть частями? и так же с какой радости раз в 7 секунд? просто 52 раза, и эти разы могу размещаться как удогно. 18 секунд в начале часа, а 52 раза в конце, не может быть? так вот вероятность как раз и должна показать ШАНС ИХ СОВПАДЕНИЯ.
Короче cvss прав
не 52 а 520 проверок. _в час_ . при аптайме 99.5% Хоть бы условие прочитали, о котором речь.... иксперты.
Или просто троли ? :)
---------- Добавлено 15.06.2012 в 16:34 ----------
Это хлеб по-английски...
Задам наводящий вопрос-загадку:
Монетку подбросили 100 раз и все сто раз выпал орел.
Какова вероятность (по вашему методу расчета) что на 101 раз выпадет орел?
Если у монетки не 2 орла - то 49,999%.
оставим 0,002% на то, что монетка может упасть на ребро.
не 52 а 520 проверок. _в час_ . при аптайме 99.5% Хоть бы условие прочитали, о котором речь.... иксперты.
Или просто троли ?
да хоть 1552 смысл тот же, почему вы считаете что проверки разместятся равномерно в течение часа и на основании этого ложного решения считаете вероятность?
нужно учесть вариации размещения проверок и от этого плясать
Если у монетки не 2 орла - то 49,999%.
оставим 0,002% на то, что монетка может упасть на ребро.
ну вот, а почему с проверками у вас получается что вероятность попадания следующих проверок зависит от предыдущих?