TGViewer
Записки IT специалиста Записки IT специалиста @interface31 · 8.99K subscribers
Post #5411 2.72K
Зависит ли стоимость поддержки от сложности ПО?

В обсуждениях проскочило мнение, что мол отказ от FreeBSD произошел потому, что система требовала более высокого уровня квалификации админов и, следовательно, обходилась значительно дороже Linux в оплате труда.

Мы занимаемся аутсорсом давно, очень давно и с подобными вопросам сталкиваемся постоянно. Поэтому решили высказать свое видение ситуации.

Начнем, как всегда, сначала. Пока организация невелика и у нее один-два-три сервера, то ни о какой инфраструктуре, как стройной системе речи не идет. Каждый сервер индивидуален и неповторим и сочетает в себе причудливый набор ролей. Почему? Да просто так исторически сложилось.

И админит это все некий человек-оркестр, который параллельно еще вытаскивает застрявшую бумагу из принтера, заправляет картриджи и утирает пользователям сопли.

А стоят на этих серверах может все что угодно, это зависит от того, что именно этот человек-оркестр знает и умеет. Бизнесу на это как-то все равно, потому как на затраты это никак не влияет. Человек-оркестр получает среднюю по рынку зарплату, а если чем-то недоволен, то за забором очередь таких стоит.

Новый человек-оркестр может даже сказать, что тут все неправильно и нужно все переделать. И даже переделает. Но и на это бизнесу плевать, так как переделывать он это будет сугубо в рамках своей зарплаты. А простой в час-два? Да никто и не заметит особо.

По мере роста бизнеса у нас будет расти количество серверов (не важно, физических или виртуальных), но еще быстрее будет расти количество рабочих станций, периферии и всего такого прочего.

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

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

А также появляется необходимость в разделении труда. Потому как человек-оркестр разорваться не может и нужны отдельные специалисты по серверам, по бизнес-приложениям и, наконец, по поддержке.

Далее происходит анализ и выбор единой платформы. Это может быть и Windows, и Linux, и FreeBSD, да и вообще что угодно. Хороший специалист для любой из систем стоит дорого. А дешево вы получите очередного человека-оркестра.

И с утверждением, что человек-оркестр для Windows стоит дешевле такого же «специалиста» для Linux, а он уже будет дешевле «специалиста» по FreeBSD я соглашусь. Но если мы берем действительно квалифицированных специалистов, то они будут стоит дорого, вне зависимости от платформы.

После того, как количество серверов перестанет измеряться единицами, а начнет измеряться десятками станет абсолютно понятно, что ручное администрирование серверов – зло. Оно крадет время дорогих и штучных специалистов.

Поэтому снова унификация и автоматизация, автоматизация и унификация. Инструментов для этого хватает, есть даже отдельная концепция – инфраструктура как код. В любом случае, если что-то можно не делать руками – это нужно не делать руками.

А дальше мы можем расти хоть до сотен, хоть до тысяч серверов. Если инфраструктура унифицирована и автоматизирована, то это не будет требовать кратного увеличения штата администраторов.

И на определенном этапе становится полностью безразлично, что у нас там крутится под капотом. Все равно, нам понадобится несколько (в штучном количестве) крутых спецов, а остальной штат – обычные среднестатистические спецы по стандартному прайсу.

Таким образом влияния сложности освоения какого-либо программного продукта на стоимость IT-инфраструктуры практически нет. На начальном этапе это будет человек-оркестр за стандартный прайс.

Во взрослой инфраструктуре – это ряд крутых спецов за хорошие деньги, но раскидав эту сумму на инфраструктуру выходят копейки.
  • 👍 41
  • ❤ 7
  • 🤮 1
More from @interface31
  1. Oct 3, 2026Как узнать все смонтированные файловые системы? Раньше можно было сказать: загляните в /et…
  2. Oct 3, 2026Автоматический перезапуск Aspia в Docker Не так давно мы рассказывали, как запустить попул…
  3. Oct 3, 2026Post #6834
  4. Oct 2, 2026До первого сервис-пака не ставить На фоне некоторых коллег, которые бегут ставить свежий с…
  5. Oct 2, 2026Post #6832
  6. Oct 2, 2026Без лишнего шума и пыли вышла Aspia 3.0. Ключевые изменения в выжимке ниже: 1️⃣ Архитектур…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →