Если б Вы одни грамматические ошибки делали...
Я вот тоже эту мыслю не понял. Наверно была какая-то шутка юмора, может автор объяснит что имел в виду?
Все, гм, не так просто. Судя по тексту - Вы и сами уже засомневались в разумности полученных "результатов". Чтобы не засорять текст оффтопиком - приведу ниже попытку решения задачи и только намекну в каком направлении Вам тут пригодится ликбез: есть такой вещь в курсе теорвера, как теория массового обслуживания (на элементарном уровне есть, например в курсе Вентцеля).
Конкретно, то что Вам тут нужно - называется система массового обслуживания с ожиданием (если админ один и обрабатывает событие мониторинга - другие пришедшие в этот период становятся в очередь). Каждый работающий администратор в такой системе - это "канал" обслуживания. Т.е. команда и случай одного фрилансера - отличается только числом каналов.
Давайте попробуем что-то посчитать с цифрами, типа тех что Вы привели выше. Я принимаю следующие допущения:
Для заданного числа клиентов - можно посчитать вероятность p_k (k<=n), с которой система будет в состоянии, когда загружено n администраторов и вероятность p_{n,s} (s>=1), когда есть очередь в s событий. См, например, цитированную выше книжку.
Какие у нас есть условия?
Вот что у меня получилось:
Во всех трех случаях, N лимитируется условием (с), а условия (a) и (b) - выполнены с большим запасом.
Сюрприза никакого нету - два человека на таком же уровне качества могут обработать приблизительно вдвое больше клиентов. А в пределе больших n - вероятность нарушения SLA тупо лимитируется w0 (т.е. тормознутостью работы одного админа).
Рад, что Вас эта очевидная глупость насторожила. Получается - что нет. Никакого бреда "хуже на два порядка" здесь, как видите, нет. В два раза, грубо говоря различие - по числу клиентов которые они могут обслужить одинаково качественно.
Но прежде всего - ничего общего с математикой ;)
Ну почему-ж? Уметь собрать и установить ПО так, как полагается - одно из основных для администратора. Типовая задача. А тут за Вас качество ее выполнения контролирует табун пользователей дистрибутива, команда QA со своими чекерами и далее - вплоть до upstream.
На мой взгляд разумно 1) оповестить клиентов в срок, что проблемой занимаются 2) определили ее источник и оценили приблизительные сроки решения. Эти этапы разумно жестко ограничивать во времени.
А обещать заранее, что починят все что угодно в 1 час - только болтуны могут. Максимальные сроки решения проблем, конечно, можно попытаться оговорить и ограничить. Да и то, только в случае ограниченного списка нештатных ситуаций (что Вы будете делать, когда райд накроется, а клиент не позаботился о бекапе на отдельный дисковый массив, несмотря на указанные ему риски?). И эти сроки в разы будут больше часа.
Не могу отказать Вам в праве забрать свое нормальное распределение :) Дисперсию можно поставить побольше - порядка часа и больше. Можно поточнее оценить из своего опыта. В общем, ничего сложного не должно быть - любой толковый студент сварганит более-менее разумную модельку для простой оценки.
Есть мнение, а есть реальный мир - в котором даже людей убивают, несмотря на законы, которыми это четко воспрещается :(
Но, наверно, уже можно своей денюшкой рискнуть на выплату каких-то компенсаций, если вероятность нарушения SLA по подобному сценарию у Вас получится где-нибудь на уровне 0.001, верно?
Это достаточно строго и понятно - фуфло.
Отреагировать на событие - да. Локализовать проблему - весьма вероятно. Решить - вероятно нет. И от количества администраторов в команде это не сильно зависит, увы (Вы даже пример выше привели).
Потому и нужны SLA, в которых оговариваются сроки прежде всего 1) и 2), да и 3) - тоже. Причем сроки 3) могут в разы разниться, по сравнению с 1) и 2), в зависимости от характера проблемы.
Так не дебиан один. Есть куча самого разнообразного открытого ПО и дистрибутивов. Я просто предложил критерий проверки профессионализма работника - не более.
А это причем здесь? Речь ведь шла о гораздо более простой ситуации: скажем у Вас есть два совершенно независимых клиента, в разных ДЦ, разное оборудование. Вы оговорили одинаковое SLA для них - какова вероятность того, что проблемы у них возникнут одновременно и работа над одной будет мешать выполнению условий SLA для другого? Как это зависит от условий SLA? А если у Вас 10 клиентов? А если 100?
Почему? Не только себя - только в одном Debian около тыщи разработчиков. А еще есть ubunta, да и другие дистрибутивы, не говоря уже о *BSD.
Если пакет входит в дистрибутив - Вы автоматически принимаете на себя эти затраты. Или его выпилят обратно. Все в равной мере относится и к приватной сборке - или у клиентов дистрибутив обновлять категорически не надо?
Купили Вы, видимо, просто неудачую поделку. Все без проблем "раскладывается" - почему нет? Если нет никаких вменяемых условий поддержки (напр., по исправлению багов) - в этом виноват не только разработчик, но и покупатель (нефиг было).
"Логично" будет конкретное требование по "стабильности и надежности" - выраженное в xxx минутах/часах допустимого простоя yyy раз в месяц, скажем. А Ваша логика категорически не годится для перевода в конкретную денюжку: "стабильно и надежно" без цифирок - это просто маркетинг.
"Угадать" - не надо. Надо математику немного знать, после чего моделирование подобных ситуаций и конкретные оценки - для Вас не составят труда.
Т.е. как это: **тесь дальше сами, уважаемый клиент?
Публичных - с десяток.
Ну дык, наверно, не постоянно звонят. А если таки настолько достали, что каждую ночь звонят - наверно чересчур "одмин" переусердствовал с числом своих клиентов по тарифам "за еду", нет? И/или попросту выполняет работу плохо.
С риском, что администратор "заболеет" (например, его трамвай переедет - с летальным исходом) - это Вы верно заметили. Если хотите застраховаться от такого форс-мажора: оговаривайте например как-то документирование работы администратором, чтобы всегда, в принципе, можно было сменить работника.
Вовсе не издеваюсь. Как еще убедиться, что человек действительно хорошо знаком с дистрибутивом, сможет запаковать устанавливаемый софт нормально и т.п.? Что умеет идентифицировать проблему, работать с багами в софте/конфигурации?
Я просто предложил еще один способ (которым, кстати, весьма активно пользуются очень приличные буржуйские работодатели) получения представления о том, что собой представляет Ваш потенциальный администратор.
Думаю, это чуть больше чем "отзывы" типовых клиентов раздела "услуг и предложений" на серче - "большие" дистрибутивы (напр. debian, ubuntu) имеют определенный контроль качества пакетов, проверяют соблюдение своих стандартов. "Попасть" туда случайной, безграмотной работе - не так просто.
Andreyka, совершенно верно.
Помимо прочего, разумно поинтересоваться вкладом человека в используемый дистрибутив. Это публичная информация (если Вам представились) - можно пошерстить и багтрекер дистрибутива и поискать сопровождаемые человеком пакеты.
Бегите от таких "частников". Нормальные люди документируют свою работу, а в голове помойку не устраивают.
Кстати, показатель: если человек берется за сопровождение любого сервера на одинаковых условиях (вне зависимости от ОС, установленного дистрибутива), что предложат - дело нечистое. Зоопарк сопровождать на порядок труднее - либо данный исполнитель этого пока еще не понимает, либо врет клиентам о качестве своих услуг.
Показатель, конечно. Если цена неадекватно низкая - человек скорее всего просто некомпетентен.
Там есть где-то и без LVM статья.
Вообще, LVM в данном хавту - будет проблемой только если делать по нему абсолютно бездумно. Если это Ваш случай - Вам категорически стоит завязывать с хавту и начинать читать нормальную системную документацию, благо info grub никто не отменил.
А еще в Debian есть:
http://www.debian.org/doc/
в частности:
http://www.debian.org/doc/manuals/debian-reference/
и до кучи:
http://wiki.debian.org/
"Ну и дура" (с) не помню чье
