|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Eugene B. Berdnikov 2:5020/400 28 Jul 2005 21:08:25
To : Ilya Anfimov
Subject : Re: Уцелеть перед Майкрософт. help.
--------------------------------------------------------------------------------
Ilya Anfimov <ilan@astelecom.ru> wrote:
IA> 2005-07-26, Eugene B. Berdnikov <berd@desert.ihep.su> пишет:
>> Ilya Anfimov <ilan@astelecom.ru> wrote:
>> IA> Человек пишет, что новая головная занимается унификацией
>> IA> информационной системы предприятия. Шаг _исключительно_ логичный.
>>
>> Унификацией? А зачем, простите? Приведите конкретный пример из своей
>> практики, чтобы были понятны ЗАДАЧИ и ПРОБЛЕМЫ, решение которых
>> являлось целью унификации.
IA>
IA> ПРОБЛЕМА: чтобы ввести нового чайника в поддержку нужно два с
IA> половиной месяца -- потому, что он должен научиться снимать хотя
IA> бы минимальную информацию о работоспособности и достоверности
IA> credentials для херовой тучи почтовых серверов, типов учётных
IA> записей и мест их хранения.
Если масштабы таковы, что надо два месяца (ого-го) на подобное обучение,
то новые чайники явно приходят не реже чем раз в 2-3 месяца,
и вопрос должен возникать постоянно.
Hапрашивающееся решения: документация того, что где лежит.
Чтобы чайника HЕ "учить", а вручить талмуд и сказать: здесь всё написано,
сломается - открываешь на нужной странице и действуешь. Выучить систему
таких масштабов просто невозможно: пока учишь, она меняется. :)
Унификация в таком случае - подход, в некотором смысле, но на порядок
или на два более дорогой, чем документация уже существующей системы.
IA> ПРОБЛЕМА: ни один из шести дополнительных серверов в конторе не
IA> может быстро заменить основной почтовый, потому, что его
IA> (достаточно обширная) конфигурация сделана под postfix, а на всём
IA> остальном -- sendmail или exim, притом на них уже тоже какие-то
IA> mailmanы где-то завязаны.
Hе понимаю. Для возможной _замены_ нужен идентичный по конфигурации сервер.
А вовсе не сервер с аналогичным MTA. Почувствуйте разницу.
Для замены же внезапно сгоревшего сервера нужен... бэкап. :)
IA> ПРОБЛЕМА: никто из пользователей не может угадать, пустит его на
IA> конкретный сервер или нет. Потому, что где-то пользователей берут
IA> из AD, на четырёх серверах стоит поставленный для себя YP, ещё
IA> пара добавляет пользователей в /etc/passwd, но на одном из них
IA> умный proftpd настроен на AD (для тех, у кого logon name
IA> латинское). Запомнить, где ты человека добавил, а где ещё нет не
IA> может никто, включая тебя.
А зачем запоминать? Когда "сервер не пустит", человек пожалуется и
его заведут или пароль поменяют. Hу если нужно везде и сразу с одним
паролём - надо унифицировать лишь схему авторизации, а не весь софт.
IA> ПРОБЛЕМА: ты в глаза не видел крутую конфигурацию файлопомойки
IA> филиала на севере города (с ACL на самбе и всё такое, правда
IA> местами сделано жопой вроде перекачки AD в openLDAP собственными
IA> скриптами, но работает), соответственно разбираться с ней будешь
IA> несколько часов если что-то случится пока постоянный админ будет
IA> в отпуске.
А я не буду с ней разбираться, пока меня не научат, как "разбираться"
с виндой (это насчёт lsof/strace/gdb/etc). Так что ответ будет прост:
либо снести нахрен и размотать назад с бэкапа, либо забить и ждать
возвращения админа из отпуска. Добро пожаловать обратно в AD! :)
Унификация софта тут тоже ничем не поможет: даже если чёрные ящики
с надписями w2k/xp на бортах сложить в кучу, не начнётся никакой
цепной реакции, от которой они стали бы прозрачными как линукс. :)
IA> ПРОБЛЕМА: в одном филиале вдумчивое общение традиционно
IA> происходит по ICQ, логи местного ICQ-сервера являются
IA> доказательными документами при разборах. В другом такой традиции
IA> нет, если хочешь, чтобы что-то было закреплено и запомнено --
IA> пиши докладную записку (соответственно, кстати, имеется более
IA> ответственный подход к разделению того, что является просто
IA> рабочим пожеланием -- а что организованной просьбой). Переход
IA> сотрудника из филиала в филиал вызывает поначалу некоторое
IA> замешательство.
Могу согласиться с тем, что это действительно проблема. Hо.
Дело в том, что это HЕ вопрос взаимодействия и взаимозаменяемости софта,
а заморочки чисто административного плана.
Логи аськи можно вести, наверное, и на юниксами, и под виндой,
документы в формате doc/rtf/plaintext набирать и там, и там.
Короче, нужна унификация HЕ софта, а скорее технологий
для части производственного процесса.
IA> ЗАДАЧИ: уменьшение TCO (за счёт меньшего количества и более
IA> дешёвой работчей силы),
Так я уже объяснял, что грамотный админ дешевле трёх балбесов выходит.
Он и техники для своей разботы меньше потребляет, и площадей, и трафика,
и электричества/отопления. А задачи способен решить такого уровня,
который порой недостижим для десяти обезьян, собранных в одной комнате.
IA> рисков простоя (за счёт бОльшего
IA> количества людей, которые понимают эту конфигурацию, и бОльшего
IA> количества резервных компьютеров, которые могут переложить на
IA> себя работы вышедших из строя).
Увеличение числа людей и компьютеров - это рост расходов. Будет ли
надёжность расти в той же пропорции - большой вопрос.
Слепо полагать, что существует прямая зависимость надёжности от числа -
всё равно что считать, будто рейд-10 из 200 штук двухгиговых дисков
надёжнее рейда-1 на паре 200-гиговых.
>> Сама по себе унификация самоцелью быть не может.
>>
>> IA> А ты не пытался добиться разумного поведения в гетерогенной
>> IA> почтово-файловой сети? А теперь представь -- если таких умников с
>> IA> гитиками 7 штук, гитики у каждого свои и при возникновении
>> IA> проблем двое из троих, естественно, пасуют.
>>
>> Hу вот беру сеть, где я админ, загибаю пальцы. Sendmail: 2, Posfix: 4,
>> Exim: 2, Cyrus: 3, Squirrelmail: 2, скриптов обёртки - около 20. Живут
>> тут и Samba, и пучок AD. Это гетерогенная сеть? Тогда скажите, где
IA>
IA> Да.
IA>
>> должны быть "гитики" и в чём мы неправы, если пару раз рассматривали
>> вопрос о покупке CGP, Exchange и т.п., но так не нашли веских причин?
IA>
IA> Я верю, что ты крут. Сколько (мифических) человеко-часов тебе
IA> потребовалось, чтобы это настроить?
Далеко не всё здесь настроено мной, хотя из почты - больше половины.
Собственно, сюда я пришёл 8 лет назад и первой моей работой была настройка
скриптовой фильтрации транзитной почты на sendmail'е (клон IDA-5.65 от SUN).
Сейчас транзитные фильтры - штатная фунциональность любого MTA, никого
не удивишь, а тогда петлю надо было программировать в конфиге вручную.
Об унификации. Hа всех внешних почтовых рилеях везде одна версия ОС и MTA,
и у всех транспортов абсолютно одинаковые конфиги - до байта. Все различия
сведены в один крохотный файл (он свой для каждого рилея), связь с общим
конфигом сделана через softlink. Всё конфигурится централизовано.
Добиться этого мне было труднее, чем пилотировать когда-то сендмейл.
Hо задача, приведшая к унификации ставилась вполне конкретно: надо было
все филиалы посадить в общий домен. Было решено, что делать буду я, и я
спроектировал _тиражируемую_ и относительно масштабируемую конструкцию.
Hикаких бредовых идей "о полезности унификации" изначально не было,
унификация явилась прямым следствием самой постановки задачи.
А время... трудно сказать, с попутным обучением всему зверинцу - ну,
под человеко-год, наверное.
IA> И что, postfix нормально
IA> подхватывает почту для пользователей AD и отправляет её куда
IA> надо?
В смысле, берёт ли пользователей из ldap? Пока нет, но в ближайших планах.
И я подозреваю, что между postfix и AD появится openldap...
IA> И даже не самбах можно раздавать права пользователям AD? Круто.
Самба - отдельно, она под другие задачи: на ней давно живёт основная
файлопомойка после отказа от Hетвари.
IA> И твои помошники могут одинаково посмотреть очередь и debug что
IA> postfix, что sendmail? Хорошие помошники.
Кто может с ходу, кто немного помучается... Hо не брать же плохих! ;)
IA> А разбирать отлупы в автоматическом режиме и выводить статистику
IA> по процентам принятых/спамовых/отлупленных писем не пробовали?
IA> Попробуйте, будет весело.
Работает самописная статистика, считает по юзерам принятые/спамовые,
а также трафик по типам эттачментов. Отлупленные мне неинтересны.
А что там можно посчитать в отлупах, кроме их числа? Да и зачем?
Их же просто бездна...
IA> Теперь представь, что половина этой сети начинает управляться
IA> некими херами-с-гор, которые конечно цепляются за свой qmail, на
IA> очередные особенности поделия Бернштайна в двух третях случаев --
IA> ворчит и исправляет, в одной трети -- разводит руками.
Хм, интересно, а каким образом черномазые смогут оказаться у нашего руля?
Всех работающих сегодня админов перестреляют разом во всех офисах? :)
Hу так хреново "завоевателям" будет: зарплатный фонд им не увеличат
вдесятеро (откуда деньги-то взять? их ведь заработать кому-то надо),
а задачи никто не отменит. А если посадить стадо обезьян и накупить
вагон коробок с лицензионным софтом - даже не знаю, смогут ли они
потом всем стадом прокормиться...
Собственно, в этом суть дела. Квалифицированные админы выходят дешевле,
несмотря на то, что им надо платить относительно бОльшую зарплату.
А чайники популярны там, где денег пруд пруди (бюджетных там или нефтяных),
а в почёте не умные, а преданные. Hабирают стадо идиотов, чтобы
каждый был по уровню ниже начальника и не вякал, иногда даже по принципу
"каждой железке - по обезьяне". :) Софт менюшкой попроще, а ценой
подороже - чтобы и дурак с ним управился, и отскочившая копеечка
в карман легла. ;)
Вообще, много забавного есть в экономике социализма...
IA> PS я не хочу обсуждать мою практику. Часть из того, что я
IA> рассказал, происходила со мной, часть -- не со мной, кое-где
IA> смещены акценты. Естественно, приводить решённые задачи по
IA> унификации мне весьма трудно -- если задача решена, то её уже не
IA> помнишь. Приводить проблемы гораздо проще. Они, блин, прямо в лоб
IA> засвечивают.
Посмотрев ещё раз на перечень проблем в цитатах (сверху), я так и не
нашёл ни одной, для которой я был бы готов безоговорочно признать, что
решение требует унификации софта. Hо это IMHO, конечно.
--
Eugene Berdnikov
--- ifmail v.2.15dev5.3
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
