ты и я разработчики? нет ты и я в курсе маркетинговых инструментов заложенных в приложение для оценки работы конкурентов и сервисов влияющих на доступность ? нет в статье явная проблема с логикой. технические данные не подтверждают однозначность утверждения ТС
квалификация никуда не делась, но для построения инфраструктур для малого и среднего бизнеса, о котором идет речь в статье, уже не требует высоких компетенций это стандартный путь ИТ - упрощение конечной поддержки, Low-code, снижение требований для системного администратора, упрощение администрирования и избыточности сервисов и т.п. чаще всего руководство как раз понимает что локальный ИТ не сравнится с командой Яндекс почты в которой есть сеньоры посильней местного, но по цене подписки.
ни у кого тут нет достоверной информации чтобы заявлять однозначно, в том числе и у ТС, даже указанных выше методичек никто не видел
я сразу навскидку встречно альтернативы по твоим тезисам: Приложение может проверять доступность конкурентов, чтобы выявить проблемы у пользователя с доступностью тг и прочих сервисов и предложением своего мессенджера. Может использовать публичные сервисы (ifconfig.me, ipify) как нейтральные индикаторы выхода в интернет, что уменьшить количество точек отказа архитектурно, регулярно вижу такое в проектах ( пинги восьмерок при доступности своих DNS серверов и прочее)
никаких никому оправданий очевидный же разрыв в логике
я специально искал вменяемый коммент вроде этого чтобы понять что я не один вижу тезисы из его двух статей: они могут = они делают безальтернативно
показано что MAX проверяет доступность хостов и статус VPN - значит цель Ловить пользователей с приватными VPN для РКН а как же гораздо более необходимое для любого приложения, сразу навскидку: -диагностика проблем подключения для улучшения UX ? -AB-тестирование доступности сервисов в разных регионах ?
большинство заказчиков от бизнеса не умеют эффективно управлять своим ИТ(статья во многом об этом) Зрелый подход - делегировать эту функцию перейдя на аутсорс. Бизнесу управлять моделью "поставщик - заказчик" гораздо больше понятней
можно сразу тезисами: 1. т.к. при наличии RAID не обязательно дублировать диски в резервном сервере . "фатальная ошибка , братан" (с). какой смысл этим всем заниматься если при прочих равных заложена деградация в отказоустойчивости? сильно отличается от 2. стойка для одного сервера , кондиционер , и прочее инженерное обеспечение в пересчете на один сервер для конечного клиента в подавляющих примерах дороже . покажи свою инфру и посчитаем) 3. риск. судя по тенденциям - минимальны, если только не AWS или подобное для минимизации используются отчуждаемые копии и DRP, все это в любом случае необходимо, даже в случае инфраструктуры на земле. 4. верно. но если допустить что стоимость миграции в оба направления то что это меняет в концептуально?
То есть, если исключить это звено - станет дешевле, при прочих равных. еще одна фатальная ошибка)
но тезисно статья написана явно для подхода другого уровня чем тезисы в твоем комментарии глобально конечно есть часть бизнеса который вообще не понимает что и сколько он теряет при простоях в 2 дня
учитывая рост облаков, расширение мощностей и в РФ и по всему миру - большинство зрелого ИТ как раз придерживается другого мнения практики практикам рознь)
цель статьи не стать истиной в последней инстанции это мнение. утверждения в ней небесусловны, как и твои аргументы. немалой части бизнес-заказчиков не хочется рисковать с refirbished, старым оборудованием. у меня лично немало примеров где требуется последнее поколение оборудования, без компромиссов другой части бизнес заказчиков вообще не хочется задумываться о зависимости бизнес процессов от ит инфраструктуры, они всецело доверяют своим ИТ( иногда зря) статья как я понял скорее для управленческой вертикали не инженерной, чтобы быть в контексте и начать спрашивать с ИТ
основываясь на моем опыте, также зависит от характеристик сервера, обычно мне достаются впервую очередь недостаточно производительные серверы, и доп нагрузка на дисковую подсистему ее снижает.
взрослый ИТ должен предоставить оценку расходов на содержание DRP и помочь бизнесу посчитать риски/потери в случае отсутствия DRP нередко DRP с оплатой трафика стоит дешевле чем один массовый инцидент с потерей данных.
ничего. также как и хостить сайт из дома/офиса но это по совокупности архитектурных (доступность, отказоустойчивость, масштабируемость, заложенные риски и пр) обычно незрелое решение.
Если у вас старый сервер, и вам комфортно с сервером - арендуйте новый сразу в ЦОДе, модель затрат сменится, и вы получите быстро работающую замену старому, хорошие каналы - и всё, что хотите.
Это дополнительная точка отказа и снижение отказоустойчивости/доступности. Если бизнес на такой риск готов и это с ним согласовано то отлично.
Так что рекомендация: сделайте аудит, и внимательно посчитайте и согласуйте решение с бизнесом.
отличная аргументация.
классно что есть люди полностью доверяющие тезисам в статье, настоящий инженерный подход)
ты и я разработчики? нет
ты и я в курсе маркетинговых инструментов заложенных в приложение для оценки работы конкурентов и сервисов влияющих на доступность ? нет
в статье явная проблема с логикой. технические данные не подтверждают однозначность утверждения ТС
квалификация никуда не делась, но для построения инфраструктур для малого и среднего бизнеса, о котором идет речь в статье, уже не требует высоких компетенций
это стандартный путь ИТ - упрощение конечной поддержки, Low-code, снижение требований для системного администратора, упрощение администрирования и избыточности сервисов и т.п.
чаще всего руководство как раз понимает что локальный ИТ не сравнится с командой Яндекс почты в которой есть сеньоры посильней местного, но по цене подписки.
ни у кого тут нет достоверной информации чтобы заявлять однозначно, в том числе и у ТС, даже указанных выше методичек никто не видел
я сразу навскидку встречно альтернативы по твоим тезисам:
Приложение может проверять доступность конкурентов, чтобы выявить проблемы у пользователя с доступностью тг и прочих сервисов и предложением своего мессенджера.
Может использовать публичные сервисы (
ifconfig.me,ipify) как нейтральные индикаторы выхода в интернет, что уменьшить количество точек отказа архитектурно, регулярно вижу такое в проектах ( пинги восьмерок при доступности своих DNS серверов и прочее)никаких никому оправданий
очевидный же разрыв в логике
я специально искал вменяемый коммент вроде этого чтобы понять что я не один вижу
тезисы из его двух статей: они могут = они делают
безальтернативно
показано что MAX проверяет доступность хостов и статус VPN - значит цель Ловить пользователей с приватными VPN для РКН
а как же гораздо более необходимое для любого приложения, сразу навскидку:
-диагностика проблем подключения для улучшения UX ?
-AB-тестирование доступности сервисов в разных регионах ?
манипуляция и эмоции точно есть
большинство заказчиков от бизнеса не умеют эффективно управлять своим ИТ(статья во многом об этом)
Зрелый подход - делегировать эту функцию перейдя на аутсорс.
Бизнесу управлять моделью "поставщик - заказчик" гораздо больше понятней
можно сразу тезисами:
1. т.к. при наличии RAID не обязательно дублировать диски в резервном сервере . "фатальная ошибка , братан" (с). какой смысл этим всем заниматься если при прочих равных заложена деградация в отказоустойчивости? сильно отличается от
2. стойка для одного сервера , кондиционер , и прочее инженерное обеспечение в пересчете на один сервер для конечного клиента в подавляющих примерах дороже . покажи свою инфру и посчитаем)
3. риск. судя по тенденциям - минимальны, если только не AWS или подобное
для минимизации используются отчуждаемые копии и DRP, все это в любом случае необходимо, даже в случае инфраструктуры на земле.
4. верно. но если допустить что стоимость миграции в оба направления то что это меняет в концептуально?
То есть, если исключить это звено - станет дешевле, при прочих равных.
еще одна фатальная ошибка)
но тезисно статья написана явно для подхода другого уровня чем тезисы в твоем комментарии
глобально конечно есть часть бизнеса который вообще не понимает что и сколько он теряет при простоях в 2 дня
учитывая рост облаков, расширение мощностей и в РФ и по всему миру - большинство зрелого ИТ как раз придерживается другого мнения
практики практикам рознь)
цель статьи не стать истиной в последней инстанции
это мнение. утверждения в ней небесусловны, как и твои аргументы.
немалой части бизнес-заказчиков не хочется рисковать с refirbished, старым оборудованием. у меня лично немало примеров где требуется последнее поколение оборудования, без компромиссов
другой части бизнес заказчиков вообще не хочется задумываться о зависимости бизнес процессов от ит инфраструктуры, они всецело доверяют своим ИТ( иногда зря)
статья как я понял скорее для управленческой вертикали не инженерной, чтобы быть в контексте и начать спрашивать с ИТ
вот тут подробней об этом
https://its.1c.ru/db/metod8dev/content/5837/hdoc
Да, если просто обновлять статистику, то надо чистить процедурный кэш. А вот ребилд индексов обновляет и план запросов.
основываясь на моем опыте, также зависит от характеристик сервера, обычно мне достаются впервую очередь недостаточно производительные серверы, и доп нагрузка на дисковую подсистему ее снижает.
тут требуется много уточнений, ситуации бывают разные
взрослый ИТ должен предоставить оценку расходов на содержание DRP и помочь бизнесу посчитать риски/потери в случае отсутствия DRP
нередко DRP с оплатой трафика стоит дешевле чем один массовый инцидент с потерей данных.
ничего.
также как и хостить сайт из дома/офиса
но это по совокупности архитектурных (доступность, отказоустойчивость, масштабируемость, заложенные риски и пр) обычно незрелое решение.
разве?)
а если это публикации web приложений?
а если связка RDS+SSL ?
и в среднем отказоустойчивей
и в среднем технологичней
если ответ по отчуждаемым копиям уже есть, то адаптировать DRP под облако не проблема.
но вопрос важный , да
Это дополнительная точка отказа и снижение отказоустойчивости/доступности. Если бизнес на такой риск готов и это с ним согласовано то отлично.
уточняю: этот вопрос нужно задавать при любой инфраструктуре (земля\облако)
очень интересно послушать развернуто