Поддерживать и развивать то, что есть, как происходит везде и по всюду.  Тыкать редхатом во все it проекты без разбора это не профессионально

оки, я собрал на коленке LFS, понаписал конфигов и распихал всякие самосборные из сорса бинарники по всем дырам. потом уволился (или убился об стенку).

приходит другой админ, смотрит на это чудо велосипедостроения, и имеет три выхода
1. попытаться во всем этом разобраться, если КАЖДЫЙ шаг не был документирован, то это почти невозможно
2. все снести и поднять свое - нормально или велосипед - это уже каждый ССЗБ
3. оставить как есть и приносить до конца своих дней в жертву по черному козлу, чтоб все не упало, и что страшнее - чтоб не пришлось менять или апдейтить.

когда-то давно, я так поднял qmail для нескольких сотен пользователей. через месяц другой клиент попросил мейл сервер, и я немного подумав, все таки поставил ему зимбру.
на сегодняшний день, те кто сидел на первом сервере, давно доросли до собственного админа, который долго мне названивал за советами, а потом плюнул и поставил exchange. а клиент с  зимброй (а тот момент четвертой) и сегодня сидит на зимбре, только уже на восьмой, серверр был два раза заменен (апгрейды железа по мере возрастания надобности), апгрейды софта всегда работали, и данные с первого дня до сих пор там. юзеров тоже уже не 120 а 1300. в первом случае, они потеряли почти две недели без почты. сколько это в деньгах для фирмы которая полагается на почту мне очень трудно представить. во втором случае, апгрейды раз в пару лет, с даунтаймом в полчаса.

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

На работе на серверах Debian 7. На домашнем сервере и на рабочей машине Gentoo. Если Debian 8 в стабильную ветку выйдет с systemd то буду пытать начальство на предмет железа помощней и ставить генту. Собсна ни кого не хочу обидеть, но если бы на работе было норм железо давно была бы гента. Просто так получилось что свое знакомство с Linux я начал с Gentoo и привык к ней. Debian мне нравиться для простеньких задач типа шлюз, маршрутизатор, проксик и т.д. его как винду "Next -> Next -> ok" ставишь и он работает, генту для таких задач, даже stage4, разворачивать лень xD

А вы для такой системы документацию писать не будете???! Я бы для такой системы, как минимум для себя, написай бы доку ибо через месяц что-то отвалиться я ж нифига не вспомню что я там крутил!

P.S. Извиняюсь за ошибки.

Во многих конторах так и происходит потому, что
1. Нет оптимального дистрибутива
2. Нет управления it
3. Недостаточная кометенция тех, кто прикладывает к it руку

Да, LFS это ты загнул в целом. Но идея понятна. Идём в гугл и видим 100500 админских бложиков с рецептами на центосах: configure && make && make install, запуск сервисов через rc.local и т.д и т.п. 21 век однако. Но, дистрибутив -то не причем, правильно?

1. ~90% в soho и smb ничего не документируется
2. Согласен
3. ~70% в soho и smb
Я к чему? Я к тому, что бесмысленно говорить, что RH это оптимум, а всё остальное сливать в унитаз.  Из примеров видно: самая большая проблема - человеческий фактор.

Ну, не совсем. Софт - это кирпичи. Сам по себе он мало чем полезен, как правило. Обычно хотят такой функционал, который упирается в сзязывание десятка софта в единую систему. Вот это процесс связывания и есть то, кто  никто толком не знает кроме того, кто это делал.

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

RH приносит стабильность и стандартизацию. Вы правы, проблемы человеческого фактора нельзя решать техническими средствами, но если дать человеческому фактору адекватные инструменты с одной стороны, и жестко ограничить в идиотизме^W самодеятельности с другой (а это и есть стандартизация) остальное уже получает возможность встать не места само по себе, за неимением возможности уйти из под контроля. Элементарное огранничение на горожение зоопарка из ОС уже сильно упрощает жизнь, стандартизируемся на определенном наборе софта, желательно стандартного, без экзотики, и вуаля - огромная куча проблем исчезает сама по себе, или, если все нормально планировать - не имеет возможности появиться.
RH не панацея, но набор решений отлично покрывает нужды практически любых организаций, так что стандартизация уже готова, из той самой коробки. Добавляем возможность ставить центос там где бюджет жмет, сертификацию админов (причем вполне настоящую, а не бумажки как MCSE) и получаем тот самый, стандартизированный, легкопроизводимы процесс айти.

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

при знании продукта - легко и играючи. я вот oVirt или Zimbra, могу за час развернуть в полноценный production, потому что делал это много, часто, и продукт знаю досконально. сейчас делаю автоматические установки openstack - все было сложно поначалу, но процесс только ускоряется по мере того как все меньше приходится смотреть в документацию (и да, в код тоже к сожалению)

это интеграторы. или по терминологии RH solution architects. Но они опять же подгоняют готовые решения стараясь свести кастомизацию к минимуму, а не разрабатывают велосипеды

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

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

должны быть стандарты и управление. без этого все превращается в дикий абсурд. я сейчас ковыряю openstack, в котором нет конкретного лидера, и это изрядная проблема. программисты проводят 90% времени не в написании кода, а в спорах по поводу того нужен ли их фичер или патч. старый, корявый код отстаивается авторами, которые ни armorácia не смыслят в виртуализации и облаках, но которые были в проекте раньше, а значит и авторитет у них выше.
короче бардак ужаснейший, хотя и стандартизация кое-какая есть. если бы и ее не было, мне страшно подумать насколько все было бы плохо

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

тот же Фабрис Беллар, убил кучу времени на бесполезный порт qemu на javascript, просто потому что ему было интересно, остановив реально нужную разработку оптимизации использования hugepages в qemu. все уже давно сделано, но тогда это могло сорвать сроки поставки версии