Администрирование сервера

Я вот тоже эту мыслю не понял. Наверно была какая-то шутка юмора, может автор объяснит что имел в виду?

Все, гм, не так просто. Судя по тексту - Вы и сами уже засомневались в разумности полученных "результатов". Чтобы не засорять текст оффтопиком - приведу ниже попытку решения задачи и только намекну в каком направлении Вам тут пригодится ликбез: есть такой вещь в курсе теорвера, как теория массового обслуживания (на элементарном уровне есть, например в курсе Вентцеля).

Конкретно, то что Вам тут нужно - называется система массового обслуживания с ожиданием (если админ один и обрабатывает событие мониторинга - другие пришедшие в этот период становятся в очередь). Каждый работающий администратор в такой системе - это "канал" обслуживания. Т.е. команда и случай одного фрилансера - отличается только числом каналов.

Давайте попробуем что-то посчитать с цифрами, типа тех что Вы привели выше. Я принимаю следующие допущения:

• поступает стандартный, пуассоновский поток событий мониторинга с плотностью (среднее число событий за ед. времени) \lambda = 1 за 3 дня. Для нескольких клиентов N - число событий умножается в N раз, естественно.
• время обработки T события в среднем <T> = полчаса и распределено по показательному закону (коэффициент в показателе экспоненты \mu = 1/<T>). С нормальным распределением там что-то немарковское будет, так что я попроще...
• если событие не может быть тотчас обработано одним из n администраторов - оно ставится в очередь.

Для заданного числа клиентов - можно посчитать вероятность p_k (k<=n), с которой система будет в состоянии, когда загружено n администраторов и вероятность p_{n,s} (s>=1), когда есть очередь в s событий. См, например, цитированную выше книжку.

Какие у нас есть условия?

• Чтобы число заявок не возрастало неограничено в очереди, должно быть выполнено условие: \lambda / \mu < n
• Доля времени, которую система простаивает, приходящаяся на одного администратора. Грубо говоря, "доля достающегося сна": Ps = (n p_0 + (n-1) p_1 + ... + p_{n-1})/n. Будем считать, что админ не должен спать меньше Ts = 12 часов, т.е: Ps <= Ts/24 = 1/2
• Вероятность Wfail того, что обработка поступившего события нарушит SLA в X = 3 часов: Wfail ~ w0 = \exp(-\mu X), если у нас практически не бывает очередей (можно, конечно, и честно посчитать Wfail - тогда полученые ниже N будут чуть выше), для чего введем условие: Po = (1 - p_0 - p_1 - ... - p_n) < 5%. C нашими \mu и X: w0 = 0.0025, так что Wfail < 1% с запасом.

Вот что у меня получилось:

• один администратор способен обработать с такими условиями N < 33 клиентов
• n = 2, соответственно, N < 93 клиентов
• n = 3, N < 167

Во всех трех случаях, N лимитируется условием (с), а условия (a) и (b) - выполнены с большим запасом.

Сюрприза никакого нету - два человека на таком же уровне качества могут обработать приблизительно вдвое больше клиентов. А в пределе больших n - вероятность нарушения SLA тупо лимитируется w0 (т.е. тормознутостью работы одного админа).

Рад, что Вас эта очевидная глупость насторожила. Получается - что нет. Никакого бреда "хуже на два порядка" здесь, как видите, нет. В два раза, грубо говоря различие - по числу клиентов которые они могут обслужить одинаково качественно.

Но прежде всего - ничего общего с математикой ;)

Ну почему-ж? Уметь собрать и установить ПО так, как полагается - одно из основных для администратора. Типовая задача. А тут за Вас качество ее выполнения контролирует табун пользователей дистрибутива, команда QA со своими чекерами и далее - вплоть до upstream.

Потому, что таких немного наберется и полностью спрос они не покроют.

ну да развелось тут всяких :)

Специалистов реально мало, или они по уши в работе, что так и происходит, если бы я не делал так много ошибок грамматических, мне бы тоже предложили работать с клиентурой, в тех поддержке, атак я их распугаю🍿

Если б Вы одни грамматические ошибки делали...

некоторые вещи, вам будет сложно понять, проще улыбнитесь :)