- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Не совсем понял, что Вы имеете ввиду. Я, вроде бы, оговорил сроки решения администраторской проблемы, а сколько времени из него они будут спать, а сколько -- локализовывать -- это уже их проблемы.
На мой взгляд разумно 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, Саморекламу - в сторону, я в курсях ;).
Ну а к чему тогда судить о дежурствах и что у нас не организовано?))