Архив

Архив Февраль 2011

ИТ-проекты: национальный подход

27 февраля 2011

В Этой-Удивительной-Стране почему-то принято либо ничего не делать, либо делать через самую что ни на есть задницу: ни с кем ничего не согласовывая, медленно, некачественно, неэффективно и согласно собственным убеждениям (в то время как давно придуманы и используются отраслевые стандарты). Особенно заметно это проявляется в части ИТ, когда на предприятии сидит во главе департамента типовой кандидат на получение справки о врожденном идиотизме, и, собственно, всячески изгаляется на производственной среде, постоянно чего-то выдумывая и внедряя. Таких, к несчастью, много, а т.к. свои эксперименты они проводят «на живую», бизнес, пригревший их по недогляду, ощутимо страдает.

Вступление не без намека на реальную ситуацию. Теперь «тело» истории, внимайте: территориально распределенное торговое предприятие. Головной офис в СПб, филиалы в Москве, Казани и еще черт знает где общим числом 8 штук. Количество сотрудников (с компьютерами) — под 4 сотни. ИТ-инфраструктура, мягко говоря, не очень. Где-то Windows и AD, где-то Linux с Samba и Squid, а где-то и вовсе роутер для домашнего использования и 5 ноутбуков, выходящих через него в Интернет. Между Москвой и СПб — какой-никакой, но VPN, хотя домены AD разные, да без всяких изысков вроде доверительных отношений и общей ИТ-инфраструктуры. Никаких стандартов, никаких процедур, никаких SLA и KPI (хотя KPI должны разрабатывать кадровики, ИТ-специалисты обязаны как минимум этому способствовать), никаких систем и регламентов. Ключевые сервисы — телефония (Panasonic), 1С (1С) и почта (хостинг-провайдер, cPanel и много-много вручную создаваемых и управляемых ящиков). 1С, кстати, на dedicated-сервере в датацентре. Business-critical, даже мудак у руля ДИТ это понимал и ответственность за существование 1С на себя не брал. Но вот с почтой было паскудно…

Я вообще плохо себе представляю, чем ИТ-специалисты руководствуются, внедряя сервисы, не использующие единый центр аутентификации (читай, когда для входа в компьютер логин-пароль один, в почту — другой, в 1С — третий, на корпоративный сайт — четвертый и т. д.). Во-первых, это неудобно пользователям. Во-вторых, таким образом плодятся десятки точек администрирования, которые надо вменяемым образом сопровождать (т.е. вести документацию, обслуживать). Но все-таки они чем-то руководствуются, сервисы внедряют, а потом стонут, плачут и рыдают, пытаясь как-то со всей этой махиной сладить.

Так и тут: 400 почтовых ящиков, созданных в ПУ хостинг-провайдера, созданных без применения единого стандарта наименования. 400 логинов, 400 паролей. И таблица в Excel, в которой весь этот шлак кое-как задокументирован. Начальнику ДИТ это, конечно, шибко не нравилось, и он родил идею: внедряем, блядь, Exchange. Купил 2007-й Enterprise и стал внедрять.

Сперва Exchange не внедрился. Возникли какие-то ошибки установки, а перезапуск setup.com выдал месседж, что, мол, Exchange в инфраструктуре уже присутствует, а посему ставить новую копию уже как бы и незачем. Т.к. начальник ДИТ про Exchange имел весьма жидкие знания, он начал грешить на домен AD (глючит, мол). Ладно. Скоро сказка сказывается, не скоро дело делается. Переустановили AD в Питерском офисе. Запустили setup — Exchange встал. Epic, блядь, win. Ценой титанических усилий сисадминов, правда, но все-таки win. Дальше Exchange стали конфигурировать, и почта ходить перестала. Совсем. А компания торговая. Для торговой компании почта имеет ключевое значение. Счет-то, блядь, как отправить заказчику?! По факсу?! Отчет руководству как передать?!?! С личного ящика писать?!?! Актами сверки перед сдачей НДС как обменяться?!?!?! Курьерами?!?!?! В общем, апокалипсис.

Сферический мудак в вакууме

Начальник ДИТ не знал, что ящики в Exchange создаются для активных учетных записей пользователей в AD, а не для любого рандомного рыла на планете. Он не знал, что для отправки почты требуется настроенная внутренняя инфраструктура DNS (ну хотя бы MX-запись). Он не знал, что опубликовать OWA и OutlookAnywhere довольно сложно, если нет ISA Server. Он не знал, что для OutlookAnywhere требуется сервер сертификатов. Он не знал, что региональные DNS обновляются несколько дольше, чем Питерские и Московские, и что офис в Казани даже через 3 дня не знал о смене MX-записей на стороне провайдера. А потом узнал, и когда MX-записи вернули на место, Казань еще 3 дня пыталась слать почту через IP-адрес Exchange, который к тому моменту уже был выведен из эксплуатации.

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

Теперь кратко суть: начальник ДИТ провел разведку боем, настроив send/recieve-коннекторы в Exchange, опубликовав SMTP наружу и сразу же поменяв MX-записи у регистратора домена. То, что в таком режиме нихуя не заработает, он узнал лишь тогда, когда не заработало, и еще 2 дня силился сообразить, где он допустил ошибку, и истерично вносил изменения в разные компоненты Exchange, никоим образом к проблеме не относящиеся. А потом скомандовал «назад». Получил выговор, финансовое взыскание и ушел в отпуск приводить себя в тонус водкой.

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

Default , , ,

Beavis Prototype

20 февраля 2011

«Служба профилей пользователей препятствует входу в систему»

17 февраля 2011

Проблема: Доменный пользователь не может авторизоваться на своем компьютере. После ввода учетных данных, возникает ошибка: «Служба «Служба профилей пользователей» препятствует входу в систему. Невозможно загрузить профиль пользователя». ОС — Windows 7 (судя по всему, такой же проблеме подвержена и Vista).

Решение: входим в систему локальным или доменным администратором (кем пустит, собственно). Открываем regedit.exe. В разделе HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList наличествует несколько подразделов, названия которых соответствуют ID пользователей, зарегистрированнных в системе. Визуально можно сопоставить нечитаемый ID с ключем «ProfileImagePath», который определяет путь к профилю (например, C:\Users\Fedoseyev). Находим нужный подраздел с целевым ProfileImagePath и… обнаруживаем в названии подраздела «.bak» на конце. Удаляем .bak, просматриваем содержимое остальных ID в поисках проблемных профилей (например, с путем C:\Users\TEMP), вычищаем их. Теперь можно перезаходить в систему с привычным профилем. Вуаля.

Default ,

Муки выбора

3 февраля 2011