ресурс технический, а у вас получается теплое и мягкое
Существует десятки технических аргументов для переноса инфраструктуры компании в облако. Как и контраргументов. Их я готов обсуждать на техническом языке. Но автор в половине своей аргументации буквально говорит «у вас в компании сисадмин — вор, поэтому переходите к нам в облако». По тексту получается, что это самый сильный его аргумент. И он не технический.
Необходимость содержать в штате специалиста, который мог бы сервер собрать, настроить и в дальнейшем обслуживать
Враньё.
Постоянные страхи того, что что-то выйдет из строя пока этого специалиста нет на месте
Опять враньё или неправильно выбранный ЦОД
Не всегда возможно оперативно попасть на место размещения оборудования ночью или в выходной день для замены комплектующих
Непрофессиональная организация работы или неправильно выбранный ЦОД
Вам придется на веру принимать обещания системного администратора на тему сохранности данных в случае выхода из строя какого-либо диска
Отвратительно
Если что-то на сервере выходит из строя, потребуется несколько дней на выяснение причин, покупку нового комплектующего и его установку. Или же в лучшем случае 1 день если, разумеется, вы заранее все запасные комплектующие храните в непосредственной близости к самому серверу – это время пока ваш бизнес и все сотрудники не работают!
Или враньё или неправильная организация работы + неправильно выбранный ЦОД
Во время работы уже готового сервера недобросовестные системные администраторы могут симулировать выход из строя той или иной части сервера для ее замены и последующего присвоения списанной
Отвратительно
В момент закупки оборудования рекомендации системного администратора по месту их приобретения могут включать его собственный интерес
Просто мерзко.
Существует множество нормальных аргументов за переход от физики к виртуализации, на Хабре я читал несколько вполне аргументированных статей, в том числе с разбором — когда это стоит делать, а когда нет. Но аргументы в виде «нечистого на руку админа» — это за гранью добра и зла уже…
Коллеги. Я ничего не имею против виртуализации, но ваша аргументация за отказ от физики непрофессиональна и местами отвратительна. Складывается ощущение, что у автора богатый опыт обмана руководства.
Так это тоже важное примечание к вашей статье (кроме медленного канала).
Т.е. для того, чтобы посетитель сайта видел хоть какой-то эффект от применения данной технологии верстка сайта должна соответствовать следующим требованиям: 1)… 2)… 3)…
Мне кажется, что тенденция все-таки — First Meaningful Paint (FMP) — первая значимая отрисовка. Вы и сами знаете, что пользователь сильно не любит, когда страницу «колбасит» и чаще всего просто ждет полной отрисовки контента. Я говорю о посетителях сайта, а не о всяких там SEO-шных заморочках.
Вообще nazarpc понять гораздо легче, чем вас. На чем вы экономите? На двух запросах (css + js), которые потенциально могут вернуть 304? Тогда вопросы — а сколько изображений на типичной странице вашего сайта? Никаких счетчиков конечно же на странице нет?
Честно говоря, ваши рассуждения выглядят неубедительно, тем более, что они не подкреплены тестами.
Вы совершенно правы. Но в равной степени это должно относиться и РКН, который по закону должен блокировать телегамму, но почему то решил работать «по площадям» и накрыл всех «мирных жителей», которые стояли рядом. Статья 330 УК «Самоуправство»?
Ведь люди, которые это все затеяли, они же совершенно не понимают что именно они делают с реальным миром. Просто пришла идиотская команда от какого-то недоумка
На мой взгляд, это довольно оптимистичный вариант (хотя бы потому, что ситуацию в теории можно поправить). Гораздо хуже, если это элемент в какой-то многоходовке и люди прекрасно понимают, что они делают и зачем…
И гугло-яндекс-боты соответственно понижали вас поисковой выдаче =)
Да с чего бы вдруг? Вообще не вижу никакой связи. У нас был аналогичный и, по моему, единственный случай — набегал бот с User-Agent: WebIndex, создавал большую нагрузку и был заблокирован только из за этого. Остальных ботов это никак не коснулось, пусть сканят на здоровье.
А давайте, вы не будете гадать? Было бы вежливо попросить показать конфиги и на основании их уже строить какие-то умозаключения. Ну, отвечу в таком же стиле — с конфигами все нормально.
Я просто оставлю этот график мониторинга одного из бэкендов за год здесь. Простая замена mod_php на php-fpm на бэкенде и переход с prefork на event в связи с тем, что prefork стал не нужен, в январе без изменения производительности бэкенда. Видно, что добавили немного оперативки, но могли этого не делать.
Естественно на конфигурации apache+mod_php. Вы удивитесь, но на нагруженных тяжелых проектах разница — «разы». Завтра с работы попробую продемонстрировать наглядно — графиками munin (если интересно). Просто за счет отказа от mod_php на бэкенде нам на том же самом железе удавалось увеличивать производительность (количество обслуживаемых запросов в единицу времени) в несколько раз (естественно, с нормализацией) только за счет освобождения оперативной памяти.
Следующим шагом всегда шел отказ от Apache (что логично), если только не использовались специфические или самописные модули для него.
Враньё.
Опять враньё или неправильно выбранный ЦОД
Непрофессиональная организация работы или неправильно выбранный ЦОД
Отвратительно
Или враньё или неправильная организация работы + неправильно выбранный ЦОД
Отвратительно
Просто мерзко.
Существует множество нормальных аргументов за переход от физики к виртуализации, на Хабре я читал несколько вполне аргументированных статей, в том числе с разбором — когда это стоит делать, а когда нет. Но аргументы в виде «нечистого на руку админа» — это за гранью добра и зла уже…
UMD, Associate Professor
Director of Space Systems Laboratory
Department of Aerospace Engineering
Есть еще версия с пояснениями и примерами
И да… Этот текст имеет больше отношения к управлению разработкой (особенно в РКТ), чем многие модные сейчас методологии. Спасибо за перевод!
Т.е. для того, чтобы посетитель сайта видел хоть какой-то эффект от применения данной технологии верстка сайта должна соответствовать следующим требованиям: 1)… 2)… 3)…
Кмк, овчинка выделки точно не стоит.
Мне все-таки как то понятнее вот так:Источник, 5 лет статье
Честно говоря, ваши рассуждения выглядят неубедительно, тем более, что они не подкреплены тестами.
Я проверил blog.jetbrains.com Он действительно был блокирован несколько дней, но уже почти сутки, как доступен.
Я просто оставлю этот график мониторинга одного из бэкендов за год здесь. Простая замена mod_php на php-fpm на бэкенде и переход с prefork на event в связи с тем, что prefork стал не нужен, в январе без изменения производительности бэкенда. Видно, что добавили немного оперативки, но могли этого не делать.
Следующим шагом всегда шел отказ от Apache (что логично), если только не использовались специфические или самописные модули для него.