- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Не совсем понял, что Вы имеете ввиду. Я, вроде бы, оговорил сроки решения администраторской проблемы, а сколько времени из него они будут спать, а сколько -- локализовывать -- это уже их проблемы.
На мой взгляд разумно 1) оповестить клиентов в срок, что проблемой занимаются 2) определили ее источник и оценили приблизительные сроки решения. Эти этапы разумно жестко ограничивать во времени.
А обещать заранее, что починят все что угодно в 1 час - только болтуны могут. Максимальные сроки решения проблем, конечно, можно попытаться оговорить и ограничить. Да и то, только в случае ограниченного списка нештатных ситуаций (что Вы будете делать, когда райд накроется, а клиент не позаботился о бекапе на отдельный дисковый массив, несмотря на указанные ему риски?). И эти сроки в разы будут больше часа.
Если Вы дадите мне распределение ...
Не могу отказать Вам в праве забрать свое нормальное распределение :) Дисперсию можно поставить побольше - порядка часа и больше. Можно поточнее оценить из своего опыта. В общем, ничего сложного не должно быть - любой толковый студент сварганит более-менее разумную модельку для простой оценки.
Однако, есть мнение, что количество невыполненых SLA должно стремиться к нулю :)
Есть мнение, а есть реальный мир - в котором даже людей убивают, несмотря на законы, которыми это четко воспрещается :(
Но, наверно, уже можно своей денюшкой рискнуть на выплату каких-то компенсаций, если вероятность нарушения SLA по подобному сценарию у Вас получится где-нибудь на уровне 0.001, верно?
На мой взгляд разумно 1) оповестить клиентов в срок, что проблемой занимаются 2) определили ее источник и оценили приблизительные сроки решения. Эти этапы разумно жестко ограничивать во времени.
А обещать заранее, что починят все что угодно в 1 час - только болтуны могут. Максимальные сроки решения проблем, конечно, можно попытаться оговорить и ограничить. Да и то, только в случае ограниченного списка нештатных ситуаций (что Вы будете делать, когда райд накроется, а клиент не позаботился о бекапе на отдельный дисковый массив, несмотря на указанные ему риски?). И эти сроки в разы будут больше часа.
Клиенту нужно не знать, что кто-то работает, а решение проблемы (можете называть это маркетингом, но это действительно так).
В принципе, мы говорим примерно одно и то же -- только Вы называете это тремя этапами и разновидностями проблем, а я -- сроком решения проблемы, зависящей от админа и решением проблемы, от него не зависящей.
Наверно, при составлении договора Ваша точка зрения более правильная.
Проинтегрировал Ваше нормальное распределение ;) При 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 -- в этом случае получается, что один админ в пять раз хуже команды.
😮
Сами поедете ставить RAID клиенту? :)
Можно ли просуммировать Ваше мнение как "мониторинг не нужен, потому что все его события предусматриваются заранее"? В принципе, логично, но сервера почему-то падают.
Зачем ехать? В процессе установки ОС я ставлю софтрейд. Надо только иметь пару дисков.
Если у тебя сервера падают, то я конечно сочувствую, но нельзя же быть таким эгоцентристом.
При SLA в 3 часа, мат.ожидании в 2 и дисперсии в час получается 0.32Up нарушений SLA в год, где U - количетво пользователей, а p - мат. ожидание количества срабатываний мониторинга в сутки. Забавно получается -- при 10 пользователях и срабатывании раз в 3 дня получается всего 1 нарушение SLA в год.
Можно считать, что эта прикидка была правильной для фирмы администрирования.
Теперь посмотрим на администратора, который спит 6 часов в день. Это значит, что 1/4 суток он не отвечает на события мониторинга, и они нарушают SLA, и тогда количество его нарушений равно U*(1/4)*p*365! Что почти в 300 раз больше и за год сделает 300 нарушений - почти по нарушению в сутки! Получается, что фрилансер, который спит 6 часов в день, в триста раз хуже компании из двух админов, которые покрывают всё время?
Ничего общего с реальностью. Фрилансер может проснуться когда угодно, и уснуть когда угодно. У него есть стимул работать лучше - его не будут будить. Фирма же - ну как... "Я работаю за зарплату, война-войной и обед по расписанию" - думаю, о многом говорит. Лично я, почему-то, просыпаюсь и среди ночи. А еще надо ли говорить, что рабочий день у иных людей бывает по 36-48 часов и т.п.
Да ни о чём не говорит. У нас, от кого это нужно, просыпаются и ночью в выходные.
Himiko, То есть у вас в организации не организовано ночное дежурство. Все ясно.
Raistlin добавил 11.07.2011 в 08:46
Boris A Dolgov, Чего вы там говорили, что ночью организации реагируют лучше? Вот живой пример.
Я три года работал начальником такой организации, но это корпоративный уровень. Обычным хостингам он не по карману.
Himiko, То есть у вас в организации не организовано ночное дежурство. Все ясно.
А вот ничего не ясно.
Я уже писал, что саппорт - одно, ответственный специалист за проект - другое.
Простые вопросы может решать саппорт, а критичные - ответственный специалист, которого разбудят хоть ночью. А он в свою очередь в идеале знает проект и максимально быстро всё решит.
Himiko, Саморекламу - в сторону, я в курсях ;).
Himiko, Саморекламу - в сторону, я в курсях ;).
Ну а к чему тогда судить о дежурствах и что у нас не организовано?))