CL - вполне себе коробочный вариант. Как минимум два человека, которые тут отписались, точно используют его с ISPmanager, а может быть - больше.
К слову, ISPmanager научился распознавать CL в /etc/redhat-version на пару месяцев раньше cPanel :)
Boris A Dolgov добавил 10.07.2011 в 00:58
На один сервер - нельзя. Но можно держать несколько серверов с разными панелями. Как выше написал KM.UA, это заставляет помнить в два раза больше особенностей панелек, тратить в два раза больше времени на обучение, развертывание, автоматизацию и интеграцию. И ещё иметь в два раза больше NS-серверов :)
Клиенту нужно не знать, что кто-то работает, а решение проблемы (можете называть это маркетингом, но это действительно так).
В принципе, мы говорим примерно одно и то же -- только Вы называете это тремя этапами и разновидностями проблем, а я -- сроком решения проблемы, зависящей от админа и решением проблемы, от него не зависящей.
Наверно, при составлении договора Ваша точка зрения более правильная.
Проинтегрировал Ваше нормальное распределение ;) При SLA в 3 часа, мат.ожидании в 2 и дисперсии в час получается 0.32Up нарушений SLA в год, где U - количетво пользователей, а p - мат. ожидание количества срабатываний мониторинга в сутки. Забавно получается -- при 10 пользователях и срабатывании раз в 3 дня получается всего 1 нарушение SLA в год.
Можно считать, что эта прикидка была правильной для фирмы администрирования.
Теперь посмотрим на администратора, который спит 6 часов в день. Это значит, что 1/4 суток он не отвечает на события мониторинга, и они нарушают SLA, и тогда количество его нарушений равно U*(1/4)*p*365! Что почти в 300 раз больше и за год сделает 300 нарушений - почти по нарушению в сутки! Получается, что фрилансер, который спит 6 часов в день, в триста раз хуже компании из двух админов, которые покрывают всё время? :)
Я понимаю, что вторая модель натянута и из-за разбужения смсками совсем неправильная, но пока очевидного способа добавить выносливость отдельного человека не вижу. Разве что посчитать, что если четыре события подряд произошли с разницей в 6 часов друг с другом, то админ не высыпается и срывает последний SLA -- в этом случае получается, что один админ в пять раз хуже команды.
😮
И часто ломает данные, если серверы не подключены друг к другу прямым шнурком :) Тоже лично сталкивался, так что для гео-нужд это не работает.
Я даже верю, что ISPmanager может работать с софтом из исходников :) Вопрос в том, что разработчики считают стандартной политикой и для чего предоставляют инструменты из коробки и техподдержку.
В след. релизе ISPmanager обещали поддержку bsd acct из коробки. Моментальное использование, конечно, не получится, но вот среднее за последние 5/15 минут -- легко.
Или ставьте CloudLinux, который всё это сам делает и к которому скоро появится isp-плагин. (кстати, у меня есть подозрения, что в Вашем ТЗ Вы как раз и говорили о нём).
Не совсем понял, что Вы имеете ввиду. Я, вроде бы, оговорил сроки решения администраторской проблемы, а сколько времени из него они будут спать, а сколько -- локализовывать -- это уже их проблемы.
Если Вы дадите мне распределение времени решения проблемы, которая у каждого пользователя возникает в единичный промежуток времени, то я, наверно, смогу посчитать матожидание количества нарушенных SLA за указанный период в зависимости от количества пользователей. Я не считаю это распределение тривиальным, но можно попробовать взять что-нибудь с большим пиком в нуле и нормальным распределением с пиком в 30 минутах дальше.
Однако, есть мнение, что количество невыполненых SLA должно стремиться к нулю :)
Boris A Dolgov добавил 09.07.2011 в 21:49
Сами поедете ставить RAID клиенту? :)
Можно ли просуммировать Ваше мнение как "мониторинг не нужен, потому что все его события предусматриваются заранее"? В принципе, логично, но сервера почему-то падают.
Предложите какую-нибудь тривиальную модель и посчитайте в её рамках вероятность этого события.
Disclaimer: я ни в коем случае не наезжаю на математику, а лишь хочу сказать, что для получения адекватных результатов нужно строить весьма сложные модели, а смысла в этом особого нет -- ведь мы не на атомной станции работаем.
Мы сейчас договор составляем или обсуждаем фактический состав услуги администрирования? Клиент хочет именно стабильности и надежности, а получает их гарантию в устраиваевующем его объеме с помощью всяких SLA и гарантий аптайма.
Хотя, я считаю определение "отреагировать на падение сервера/сервиса в течении часа в любое время решением проблемы либо сообщением о том, что она находится на более высоком уровне (датацентра или оборудования)" достаточно строгим и понятным.
Как сервер не настроишь, это не спасёт от падения датацентра, DDoS-атаки, краха жесткого диска или ещё чего-нибудь, что требует время на выяснение причин падения.
Потому что я знаю сторонние фирмы, которые предоставляют указанный часовой срок реакции за эти деньги, и весьма логично, что если проект переезжает на сервер, то ему нужны стабильность и надёжность работы.
Boris A Dolgov добавил 09.07.2011 в 18:48
Увы, предугадать количество звонков и их время почти невозможно - и из-за этого есть возможность не уложиться в указанный срок.
Именно поэтому я считаю, что при работе с частным админом нельзя оперировать понятием "реакция в течении часа 24/7", а можно оперировать только понятием "сделаю когда смогу, но постараюсь почти всегда примерно за час".
Boris A Dolgov добавил 09.07.2011 в 18:49
Я не набираю серверы, потому что считаю, что мой сон и отдых стоят дороже, чем за него готовы заплатить большинство заказчиков :)
