- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
А с чего Вы решили, что человеку, который готовится заплатить 50-150$/мес (см. разведку цен в начале топика) - в действительности нужен этот самый "не превышающий часа" срок?
Проекту, которому действительно нужна оперативная поддержка - несложно заплатить куда больше... А если кто-то обещает всем подряд подобные сроки реакции за 20$ в месяц - это полностью проблемы обещающего.
Потому что я знаю сторонние фирмы, которые предоставляют указанный часовой срок реакции за эти деньги, и весьма логично, что если проект переезжает на сервер, то ему нужны стабильность и надёжность работы.
Boris A Dolgov добавил 09.07.2011 в 18:48
Ну дык, наверно, не постоянно звонят. А если таки настолько достали, что каждую ночь звонят - наверно чересчур "одмин" переусердствовал с числом своих клиентов по тарифам "за еду", нет? И/или попросту выполняет работу плохо.
С риском, что администратор "заболеет" (например, его трамвай переедет - с летальным исходом) - это Вы верно заметили. Если хотите застраховаться от такого форс-мажора: оговаривайте например как-то документирование работы администратором, чтобы всегда, в принципе, можно было сменить работника.
Увы, предугадать количество звонков и их время почти невозможно - и из-за этого есть возможность не уложиться в указанный срок.
Именно поэтому я считаю, что при работе с частным админом нельзя оперировать понятием "реакция в течении часа 24/7", а можно оперировать только понятием "сделаю когда смогу, но постараюсь почти всегда примерно за час".
Boris A Dolgov добавил 09.07.2011 в 18:49
Boris A Dolgov, Вы набираете столько сколько берут, или вы набираете столько серверов, сколько можете вести в нормальном режиме?
Я не набираю серверы, потому что считаю, что мой сон и отдых стоят дороже, чем за него готовы заплатить большинство заказчиков :)
Andreyka, совершенно верно.
Помимо прочего, разумно поинтересоваться вкладом человека в используемый дистрибутив. Это публичная информация (если Вам представились) - можно пошерстить и багтрекер дистрибутива и поискать сопровождаемые человеком пакеты.
Кстати да. Вообще, участие в любом серьезном проекте - уже показывает уровень. Не обязательно опенсорсном. Гугл как бы не совсем опенсорс, но опыта дает достаточно, например.
Andreyka добавил 09-07-2011 в 18:52
поздравляю, ты превратился в Андрейку - вместо объективных советов, рекламируешь себя.
Ну вот не надо вот этого. Если вопрос правильный, задан конкретно и по существу, с указанием всех необходимых данных - я даю полезные советы.
Andreyka добавил 09-07-2011 в 18:54
Я не набираю серверы, потому что считаю, что мой сон и отдых стоят дороже, чем за него готовы заплатить большинство заказчиков :)
А я считаю, что если сервер настроить грамотно и заходить раз в месяц, то этого вполне достаточно, чтоб избежать разных внештатных ситуаций, падений и смсок.
А я считаю, что если сервер настроить грамотно и заходить раз в месяц, то этого вполне достаточно, чтоб избежать разных внештатных ситуаций, падений и смсок.
Как сервер не настроишь, это не спасёт от падения датацентра, DDoS-атаки, краха жесткого диска или ещё чего-нибудь, что требует время на выяснение причин падения.
поздравляю, ты превратился в Андрейку - вместо объективных советов, рекламируешь себя.
Почему? Не только себя - только в одном Debian около тыщи разработчиков. А еще есть ubunta, да и другие дистрибутивы, не говоря уже о *BSD.
Я имею ввиду затраты по поддержке, неизбежные проблемы совместимости с остальными пакетами дистрибутива, которые постоянно меняются.
Если пакет входит в дистрибутив - Вы автоматически принимаете на себя эти затраты. Или его выпилят обратно. Все в равной мере относится и к приватной сборке - или у клиентов дистрибутив обновлять категорически не надо?
Купили мы тут одно приложение к опенсорсной штуке, но фактически все не так как в коммерческом софте. Стоимость поддержки не раскладывается на всех клиентов.
Купили Вы, видимо, просто неудачую поделку. Все без проблем "раскладывается" - почему нет? Если нет никаких вменяемых условий поддержки (напр., по исправлению багов) - в этом виноват не только разработчик, но и покупатель (нефиг было).
Потому что я знаю сторонние фирмы, которые предоставляют указанный часовой срок реакции за эти деньги, и весьма логично, что если проект переезжает на сервер, то ему нужны стабильность и надёжность работы.
"Логично" будет конкретное требование по "стабильности и надежности" - выраженное в xxx минутах/часах допустимого простоя yyy раз в месяц, скажем. А Ваша логика категорически не годится для перевода в конкретную денюжку: "стабильно и надежно" без цифирок - это просто маркетинг.
Увы, предугадать количество звонков и их время почти невозможно - и из-за этого есть возможность не уложиться в указанный срок.
"Угадать" - не надо. Надо математику немного знать, после чего моделирование подобных ситуаций и конкретные оценки - для Вас не составят труда.
"Логично" будет конкретное требование по "стабильности и надежности" - выраженное в xxx минутах/часах допустимого простоя yyy раз в месяц, скажем. А Ваша логика категорически не годится для перевода в конкретную денюжку: "стабильно и надежно" без цифирок - это просто маркетинг.
Мы сейчас договор составляем или обсуждаем фактический состав услуги администрирования? Клиент хочет именно стабильности и надежности, а получает их гарантию в устраиваевующем его объеме с помощью всяких SLA и гарантий аптайма.
Хотя, я считаю определение "отреагировать на падение сервера/сервиса в течении часа в любое время решением проблемы либо сообщением о том, что она находится на более высоком уровне (датацентра или оборудования)" достаточно строгим и понятным.
Почему? Не только себя - только в одном Debian около тыщи разработчиков. А еще есть ubunta, да и другие дистрибутивы, не говоря уже о *BSD.
насколько эта тысяча человек сможет удовлетворить мировой (!) спрос администрирования серверов за 150$/мес ? реально смотри на вещи с точки зрения нанимателя, а не с точки зрения "гипотетического Андрейки".
"Угадать" - не надо. Надо математику немного знать, после чего моделирование подобных ситуаций и конкретные оценки - для Вас не составят труда.
Предложите какую-нибудь тривиальную модель и посчитайте в её рамках вероятность этого события.
Disclaimer: я ни в коем случае не наезжаю на математику, а лишь хочу сказать, что для получения адекватных результатов нужно строить весьма сложные модели, а смысла в этом особого нет -- ведь мы не на атомной станции работаем.
Хотя, я считаю определение "отреагировать на падение сервера/сервиса в течении часа в любое время решением проблемы либо сообщением о том, что она находится на более высоком уровне (датацентра или оборудования)" достаточно строгим и понятным.
Это достаточно строго и понятно - фуфло.
Отреагировать на событие - да. Локализовать проблему - весьма вероятно. Решить - вероятно нет. И от количества администраторов в команде это не сильно зависит, увы (Вы даже пример выше привели).
Потому и нужны SLA, в которых оговариваются сроки прежде всего 1) и 2), да и 3) - тоже. Причем сроки 3) могут в разы разниться, по сравнению с 1) и 2), в зависимости от характера проблемы.
насколько эта тысяча человек сможет удовлетворить мировой (!) спрос администрирования серверов за 150$/мес ?
Так не дебиан один. Есть куча самого разнообразного открытого ПО и дистрибутивов. Я просто предложил критерий проверки профессионализма работника - не более.
Предложите какую-нибудь тривиальную модель и посчитайте в её рамках вероятность этого события.
А это причем здесь? Речь ведь шла о гораздо более простой ситуации: скажем у Вас есть два совершенно независимых клиента, в разных ДЦ, разное оборудование. Вы оговорили одинаковое SLA для них - какова вероятность того, что проблемы у них возникнут одновременно и работа над одной будет мешать выполнению условий SLA для другого? Как это зависит от условий SLA? А если у Вас 10 клиентов? А если 100?
Как сервер не настроишь, это не спасёт от падения датацентра, DDoS-атаки, краха жесткого диска или ещё чего-нибудь, что требует время на выяснение причин падения.
Сервер можно подоготовить к школьному DDOS, поставить raid для защиты от краха жесткого диска. Да и дата-центры не умирают каждый месяц.
Это достаточно строго и понятно - фуфло.
Отреагировать на событие - да. Локализовать проблему - весьма вероятно. Решить - вероятно нет. И от количества администраторов в команде это не сильно зависит, увы (Вы даже пример выше привели).
Потому и нужны SLA, в которых оговариваются сроки прежде всего 1) и 2), да и 3) - тоже. Причем сроки 3) могут в разы разниться, по сравнению с 1) и 2), в зависимости от характера проблемы.
Не совсем понял, что Вы имеете ввиду. Я, вроде бы, оговорил сроки решения администраторской проблемы, а сколько времени из него они будут спать, а сколько -- локализовывать -- это уже их проблемы.
А это причем здесь? Речь ведь шла о гораздо более простой ситуации: скажем у Вас есть два совершенно независимых клиента, в разных ДЦ, разное оборудование. Вы оговорили одинаковое SLA для них - какова вероятность того, что проблемы у них возникнут одновременно и работа над одной будет мешать выполнению условий SLA для другого? Как это зависит от условий SLA? А если у Вас 10 клиентов? А если 100?
Если Вы дадите мне распределение времени решения проблемы, которая у каждого пользователя возникает в единичный промежуток времени, то я, наверно, смогу посчитать матожидание количества нарушенных SLA за указанный период в зависимости от количества пользователей. Я не считаю это распределение тривиальным, но можно попробовать взять что-нибудь с большим пиком в нуле и нормальным распределением с пиком в 30 минутах дальше.
Однако, есть мнение, что количество невыполненых SLA должно стремиться к нулю :)
Boris A Dolgov добавил 09.07.2011 в 21:49
Сервер можно подоготовить к школьному DDOS, поставить raid для защиты от краха жесткого диска. Да и дата-центры не умирают каждый месяц.
Сами поедете ставить RAID клиенту? :)
Можно ли просуммировать Ваше мнение как "мониторинг не нужен, потому что все его события предусматриваются заранее"? В принципе, логично, но сервера почему-то падают.