С вопросами можно обращаться ко мне через форму контакты.

Менеджер: “Как дела с нашей большой проблемой X?”
Инженер:” Мы открыли кейс номер CS221134 в ТехПоддержке!”
“Хорошо, что привлечены правильные ресурсы, проблема скоро будет решена!” - думает менеджер.
“Наконец-то у нас есть универсальная отмазка для любых сложных случаев!” - думает инженер.

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

Есть два правила, которые надо знать и соблюдать, работая по любым кейсам(даже если это кейсы в вашей внутренней системе HelpDesk):

• Один кейс – одна проблема.
• Непрерывная коммуникация между инеженерами заказчика и тех. поддержки.

Одна проблема – один кейс, основное правило любой эффективной службы поддержки

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

Из правила есть два важных следствия:

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

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

Непрерывная коммуникация между техподдержкой и заказчиком – ключевой элемент оперативного решения проблем

В эпиграф вынесено очень распространенное ошибочное ожидание многих людей от общения с техподдержкой: “Мы эскалировали проблему в тех. поддержку! Теперь это не наша проблема!”

Проблема как была вашей, так вашей и остается, у вас лишь появился ресурс, который может помочь решить эту проблему. Можно провести аналогию с доктором: ангина у пациента – это больше проблема пациента, чем доктора. 

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

Активно надо писать вопросы в кейс: правильно ли мы поняли, вот мы вам выслали и т.п. Иначе более общительные владельцы кейсов будут в приоритете – т.к. они общаются, высылают данные и задают вопросы.

Почему пишу именно так? Потому что в общем случае любой кейс в любой ТП имеет два статуса:

• мяч на стороне заказчика
• мяч на стороне тех. поддержки

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

Еженедельный анализ активности по кейсу в ТП – необходимое условие для эффективной работы с внешней службой технической поддержки

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

Если вы ИТ-менеджер, то обязательно лично еженедельно контролируйте прогресс решения проблем и запрашивайте логи из службы ТП. Может оказаться, что о важных деталях вашего кейса никто и не в курсе, а от этого может многое зависеть в решении инцидента.

В рамках премьер поддержки подобную работу делает менеджер поддржки, т.е. он контролирует:

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

Основные изменения ConfigMgr SP2 получили следующие компоненты:

• Out of Band Management
• Operating System Deployment
• Asset Intelligence
• Client Changes

SCCM SP2: Сразу доступен более быстрый клиент и возможность подключить AI Sync Point БЕЗ сертификата!

Изменения в работе с AMT, новая функциональность Win7 – это все требует дополнительного изучения и настройки, а вот парочку полезных вещей из SP2 вы можете получить сразу после установки.

Во-первых, это возможность подключить AI Sync Point к он-лайн базе Microsoft без установки сертификата, которые ранее надо было запрашивать отдельно. Я лично приветствую это начинание и рекомендую всем у кого есть SCCM обновиться до SP2 и использовать новую функциональность для более удобной работы с данными инвентаризации.

Вторая приятная вещь – это улучшение скорости работы клиента. В предыдущих версиях ConfigMgr 2007 была встроена 2-х минутная задержка после получения новой политики перед ёё применением. Эта задержка теперь убрана, чтобы клинет работал быстрее и реально, и видимо для пользователя.  Это важно для управления AppV приложениями, а также при назначении Advertisment на Logon пользователя.

В качестве доп. бонуса у клиента появилась поддержка Remote Tools для x64 версий Windows 2003 и Windows XP. App-V 4.6, который входит в пакет SP2, теперь также поддерживает x64 клиентов.

Полезные ссылки по теме

• What’s new in SCCM SP2 on Technet
• Скачать SP2 для System Center Configuration Manager 2007
• Анонос ConfigMgr SP2 в блоге SystemCenter

Приехал в гости к ребятам на север, где нужна помощь по организации автоматизированной инвентаризации, используя System Center Configuration Manager 2007 R2. Установка самого сервера и клиентов в основном домене у коллег получилась успешно: все работает, отчеты формируются, пакеты разворачивает и даже ОС по сети устанавливает.

Но радость от внедрения оказалась не очень долгой. Здесь исторически множество различных лесов AD связаны доверительными отношениями. Разворачивание клиентов по сети в другие домены и леса, используя консоль SCCM, не работает… логины и пароли проверяли, сетевые настройки тоже. Делают установку вручную – работает, делают установку по сети – нет.

Что-же приступим к диагностике. Первым делом скачиваем Trace32 из комплекта утилит SCCM Toolkit, использование этой утлиты переводит логи SCCM из сложночитаемого вида:

Waiting for change in directory "D:\Program Files\Microsoft Configuration Manager\inboxes\ccr.box" for queue "Incoming", (30 minute backup timeout).  $$<SMS_CLIENT_CONFIG_MANAGER><Mon Oct 19 13:53:21.125 2009 Якутское время (лето)><thread=3368 (0xD28)>

В более понятный для человек, плюс утилита автоматически отслеживает обновление лога и сразу показывает актуальную информацию. Загружаем в утилиту фай ccm.log, который находится в папке Logs установочной директори сервера SCCM. Затем запускаем установку по сети и видим:

======>Begin Processing request: "TZNDJGTM", machine name: "otherDomainPC" 

---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0) 
---> Attempting to connect to administrative share '\\otherDomainPC.contoso.ru\admin$' using account 'contoso\администратор'
---> The 'best-shot' account has now succeeded 3 times and failed 0 times. 
---> Connected to administrative share on machine otherDomainPC.contoso.ru using account 'contoso\администратор'
---> Attempting to make IPC connection to share \\otherDomainPC.contoso.ru\IPC$
---> Searching for SMSClientInstall.* under '\\otherDomainPC.contoso.ru\admin$\'
Submitted request successfully 
CWmi::Connect(): ConnectServer(Namespace) failed. - 0x800706ba
---> Unable to connect to WMI on remote machine "otherDomainPC", error = 0x800706ba. 
---> Deleting SMS Client Install Lock File '\\otherDomainPC.contoso.ru\admin$\SMSClientInstall.A01' 
Retry request id for "TZNDJGTM" set to "otherDomainPC_contoso_ru"

Странно, казалось бы доступ к ADMIN$ шаре у нас есть отличный, а вот доступ к WMI отваливается по ошибке, смотрим базу знаний и находим статью https://support.microsoft.com/kb/935677- это не наш случай, но сама фраза дает ключ к пониманию.

Error code 0x800706BA indicates that the remote procedure call (RPC) server is unavailable.

Проверяем доступность WMI, исопльзуя стандартные утилиты – похожая проблема, проверяем доступность машины по сети, используя короткое имя – ооопс, а доступа нет. Идем в настройки TCP/IP и добавляем наш соседний лес contoso.ru в список поиска DNS Suffix Search order. Проверяем установку клиентов по сети – все работает.

После тестрирования мы добавили в список DNS Suffix Search order все суффиксы соседних лесов и доменов, которые нам необходимы для установки агентов. Проверили установку клиентов из консоли SCCM – работает, клиенты устанваливаются и успешно подключаются к нашему серверу, предоставляя отчеты об инвентаризации.

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

Возможность назначать групповые политик на орг. подразделения (OU) - основное отличие от обычного контейнера AD. Для OU, как и для обычного контейнера, можно гибко задавать права доступа и делегировать управление. Забавный факт, в оснастке Windows 2008 Active Directory Users’n’Computers просто так создать контейнер из меню New не получится, на выбор только объекты или орг. подразделение.

Таким образом, задачи OU, помимо хранения объектов в Active Directory это
•    Делегирование управления другим администраторам компании
•    Назначение групповых политик

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

Разрабатывайте дерево OU в первую очередь для делегирования прав и удобства работы

Вопрос какова “правильная структура Active Directory” конечно стандартный и очень частый, но достаточно дискуссионный, так как у всех организаций разные уровни зрелости ИТ, и всегда есть свои особенности администрирования ИТ-систем. В частности, важно знать: сколько людей сопровождают AD, какое количество площадок, каким образом все организовано административно-нормативно, какие есть принятые политики безопасности.

По аналогии с известной моделью оптимизации ИТ-инфраструктуры (IO модель) типовая эволюция дерева OU в разных компаниях примерно такая: 

1. «Базовый уровень» - пользователей складываем в папку Users, иногда в специально созданные один или два контейнера OU без особого смысла. О том, что такое OU в теории никто ничего не знает, зачем завели - не помнят (достаточно много компаний). 
2. «Стандартизованный уровень» - структура OU повторяет штатное расписание компании… ну без комментариев, кроме одного – иногда бывает, что такая «штатка» куда точнее отражает реальность, чем например известные документы в отделе кадров. Распространенность – многие компании, считающие себя продвинутыми в AD, но без географических особенностей. Скажем честно, усилия, которые тратятся на поддержание такой структуры, как правило, неоправданные. 
3. «Рациональный уровень» - структура OU сформирована с учетом количества администраторов и делегирования полномочий на первом уровне вложенности, как правило, это география, а дальше повторяет штатное расписание из «стандартизованного уровня». Смысл в том, что в региональных отделениях компании есть свои админы, которые должны следить за своими пользователями – так что OU первого уровня заводят по географии, которая может несколько отличатся от структуры компании, но часто к ней крайне близка. 
4. «Динамический уровень». Структура OU организована так, чтобы с минимальными усилиями решать известные задачи администрирования пользователей, компьютеров и групп, при этом имея возможность предлагать людям инструменты для гибкой самостоятельной работы.

По внешнему виду «динамическая» структура может оказаться весьма непростой для понимания новому человеку. Как пример, у нас мало кто из пользователей знает как выглядит дерево орг. подразделений, но есть спец. сайт для обычных людей, который дает возможность практически кому угодно создавать и добавлять группы AD или создавать рассылки Exchange, а также управлять членством людей в них простым и понятным способом для людей.

Организация OU на примере структуры AD -  встречается и в Windows SBS, и в больших распределенных каталогах Active Directory

За основу для проектированы своего дерева OU в Active Directory имеет смысл взять стандартный подход, который использует Microsoft в своих решениях. Этот подход можно увидеть и в реализации дерева OU MyBusiness в Small Business Server, и в больших штучных проектных решения MCS для конкретных заказчиков.

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

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

Помните, что делегировать доступ лучше всего, используя ролевую модель администрирования, т.е. предоставлять доступ для специально созданных ролевых групп безопасности, куда затем включать учетные записи администраторов. Для делегирования доступа, конечно же, надо использовать удобный, надежный и простой Мастер делегирования прав доступа Active Directory, который запускается из контекстного меню оснастки Active Directory Users’n’Computers.

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

Лучшее решение – решение удобное в реальной работе

Свою структуру можно создать вручную, можно ее существенно расширить или наоборот упростить по сравнении с примером на картинке. Иногда есть смысл использовать скрипты для генерации дерева OU из штатного расписания, а можно внедрить полноценное решение по оптимизации работы с идентификационной информацией, например MS Identity Lifecycle Management.

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

Успехов.

Для домашнего чтения

• Делегирование полномочий в службе каталогов Active Directory
• Создание схемы подразделений (OU)
• Делегирование администрирования с помощью объектов подразделений (OU)

В последние пару недель мне задают разные вопросы и даже высылают резюме люди, которые желают работать GTSC инженером в Москве или менеджером поддержки Premier Support.  К сожалению, далеко не все замечают, что в вакансии стоит обязательное требование к уровню сертификации Microsoft.

Очень многие ИТ-специалисты и руководители считают, что лишь знания решают все, а сертификат – это просто дорогая бумажка, которую можно не покупать – ведь это только для понта! Такое заблуждение - очень правильное и полезное, отлично помогает разумным людям при выборе кандидатов для собеседования. Смотрите сами, из сотни резюме всего 5-10 от сертифицированных MCSE или MCITP, так что получается как в известном кадровом анекдоте из эпиграфа.

IT сертификаты сильно помогают при устройстве на хорошую работу!

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

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

Людей, которые сдали хотя бы полный трек MCSA не много, а если мы посмотрим на MCSE, то их просто катастрофически мало в масштабах страны. Новые же сертификаты по Windows 2008 и Vista есть фактически у единиц в вашем городе, а может быть вы будете первым сертифицированным специалистом.

Судя по популярности достаточно простого поста о ролях контроллера домена, у нас очень мало людей, которые могут ответить на простые вопросы: что такое домен Active Directory(бонус-левел, почему каталог-директория называется активная?), есть ли в AD Самый Главный Сервер и почему? :)

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

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

Действительно опытный и умный человек может получить MCSE за 1 неделю

Для многих специалистов в нашей стране английский язык – это препятствие. В свое время, когда я сдал MCSE без спец. подготовки ровно за 2 дня, то языковой барьер подкосил некоторые оценки. Было время, что пару экзаменов из-за неверного понимания вопросов я просто завалил. Сейчас есть хорошие и адекватные экзамены на русском языке – попробуйте начать с них.

Итого по моему опыту:

• Если человек “в теме”, то он действительно может и без особой подготовки сдать MCSA с ходу, а на MCSE надо выделить пару-тройку недель чтения TechNet и блогов сотрудников Microsoft.
• Из всего вороха резюме, которые мне в жизни приходилось просматривать, людей, с законченным трэком MCSA, MCSE - единицы. Их резюме в первую очередь изучаешь более внимательно, с большой вероятностью именно эти люди приглашаются на собеседование в первую очередь.

Конечно собеседование, тесты, разговоры - это одинаково для всех. НО! Важно помнить, что цель отправки резюме - это попасть на следующий этап, т.е. получить приглашение на собеседование. Имея сертификацию, сделать это как минимум чуть легче. Более того, проходя тесты и подготовку к ним, растет и собственная “экспа”, что всегда приятно и полезно для роста по специальности.

Как-то так.

Полезные ссылки

• Стартовая страница для вопросов сертификации 
• Обзор программ сертификации Microsoft по названию
• Подготовка к экзамену: книги, статьи, ответы на вопросы
• Список экзаменов на русском языке
• К. Леонтьев: Путь к вершине… Как я стал Microsoft Certified Master и Microsoft Certified Architect.  must read для настоящих профи.

P.S> Кстати, не стесняйтесь задавать вопросы. Пока вакансии инженеров и менеджеров поддержки Premier Support в Microsoft все еще открыты, а это значит, что до сих пор достойных сертифицированных и руссифицированных кандидатов на данные должности по всей нашей большой стране мы еще не нашли.

• Вам что-то напоминают слова: 24x7, Active Directory, Exchange, System Center, SLA, ITIL, KB822158, TechNet. 
• И не только напоминают, а звучат как музыка?
• Вы можете сделать так, чтобы даже сбои происходили только по расписанию?
• А также, можете объяснить даже бабушке из соседнего подъезда не только механизм работы ваших систем,
  но и для чего это существует в жизни?

Менеджер поддержки (TAM) – ключевой элемент команды Microsoft Premier Support!

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

Именно менеджер поддержки TAM делает возможным то, что многим кажется невыполнимым. Работая с узким кругом постоянных заказчиков(обычно 4-5 крупных компаний), он является доверенным лицом Microsoft по всем вопросам безаварийной работы ИТ-систем.

Откликнуться и выслать резюме на вакансии в премьер поддержке можно здесь:

• HH.RU: ТАМ в Новосибирске
• HH.RU: ТАМ в Москве

Вопросы о том, как работается на подобной должности, можно задавать мне в почту, а еще у нас открыты 3 вакансии GTSC - инженера в Москве.

тех, кто ещё не терял очень важные файлы,

и тех, кто регулярно делает резервные копии.

“Есть ли у вас план аварийного восстановления основных ИТ-систем?” – это один из первых вопросов, который я задаю на встрече с новым заказчиком Premier Support.  Половина людей честно и сразу отвечает – нет! Со второй половиной приходится работать дальше, задавая следущие наводящие вопросы:

• Как давно вы восстанавливали всю систему из резервной копии?
• Использовали ли Вы при этом документацию из плана резервного копирования?
• Готовы ли вы восстановить, например, Active Directroy полностью в новую среду сегодня так, чтобы завтра, подключив к ноутбук директора, можно было войти в систему и сразу начать работать?

Обычно на последний вопрос все-таки следует ответ: “Нет!" Т.к. на такой эксперимент даже за ящик пива редко кто соглашается… Хотя и очень зря - это, по-сути, единственный метод проверки корректности резервного копирования и политики аварийного восстановления.

У нас в Premier есть весьма восстребованный класс услуг ”Создание и тестирование плана аварийного восстановления <для подставить название любимой системы Microsoft>”. В частности наиболее всотребованные две: по Acitve Directory и Exchange.

План аварийного восстановления Active Directory

“ADDR: Создание и тестирование плана аварийного восстановления службы Active Directory” от Premier Support включает в себя:

• Подробный пошаговый план аварийного восстановления в случае различных сбоев Active Directory, в частности:
  • Восстановление всего леса
  • Восстановление одного и/или нескольких доменов леса
  • Восстановление пользователей и членства их в группах
  • Восстановление групп и членства в группах
  • Восстановление организационных подразделений
  • Восстановление групповых политик
  • Восстановление объектов SYSVOL
  • Восстановление пользователей из “захоронений” (thombstone)
• Политику правильного резервного копирования Active Directory
• Тестовое восстановление Active Directory под руководстовм PFE-инженера Microsoft, используя план восстановления и проходя все сценарии.

Подобные процедуры несекретные и есть не только на английском языке, поэтому Вы можете сделать свой план восстановления Active Directroy самостоятельно, используя следующие полезные документы:

1. Аварийное восстановление пользователей и групп службы каталогов Active Directory, Джил Киркпатрик (Gil Kirkpatrick) - TechNET Magazine
2. Восстановление объектов-захоронений Active Directory, Джил Киркпатрик (Gil Kirkpatrick) - TechNET Magazine
3. Резервное копирование и восстановление Active Directory в Windows Server 2008, Джил Киркпатрик (Gil Kirkpatrick) - TechNET Magazine
4. Как перенести установленную систему Windows на другой компьютер – важный вопрос, надо изучить заранее, т.к. часто серверов идентичной конфигурации нет в наличии, а восстанавливать из резервной копии надо.

Помните, только регулярное тестовое восстановление из резервной копии дает гарантию работоспособности системы и политик Backup/Restore. В таком тестовом восстановлении необходимо работать именно по плану аварийного восстановления, чтобы проверить актуальность документов и внести необходимые исправления в случае расхождения реальной жизни и плана.

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

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

На данный момент планы по развитию Российской команды GTSC подразумевают принятие на работу 3-х инженеров по следующим специальностям:

1. Microsoft SQL Server
2. Messaging (Exchange 2003/2007, Unified Communications)
3. Windows Platform: Active Directory, DNS, DHCP (знание SMS/SCCM - большой плюс).

Ссылка на вакансию: https://hh.ru/vacancy/2305278 или оно же на Microsoft career site. Вопросы о вакансии, например, чем отличаются GTSC и PFE инженеры, можно написать также и мне – попробую ответить.

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

Коллеги! НЕ ПЛАНИРУЙТЕ изменения в пятницу и перед другими выходными днями.

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

Также, имеет смысл договоры внедрения заключать либо со сроком до 20го декабря, или уже сразу до 20 января. Т.к. договора со сроком 31 декабря выглядят красиво, но вынуждают работать в последние дни года, что  очень и очень опасно, т.к. корпоративы – алкоголь, утренний алказельцер и риск сорвать НГ полностью.

Итоги этого года и анонс на следующий.

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

В следующих постах я буду много писать об Active Directory с точки зрения беспроблемного сопровождения. Об обычной задаче, когда вы пришли на свою, возможно, новую работу и обнаружили там каталог AD: что следует менять сразу, что следует пробивать в виде проектов, а что может жить годами и не повляет ни на что, кроме личной самооценки?

Существует очень много книг и статей о том, как проектировать AD для сферической компании в вакууме, также, есть не мало книг о тонкостях работы с теми или иными инструментами Active Directory. Моя цель – заполнить нишу посередине, когда AD важная часть инфраструктуры, но отдельной команды или человека для его споровождения выделять не будут. Ответить на вопросы что стоит делать, считая, что вопрос КАК это делать уже раскрыт в других источниках.

Самым ценным постом по AD в этом году я считаю заметку о построении карты AD! Если у вас до сих пор нет карты своей инфраструктуры – сделайте ее первым делом после каникул, эффект видимый и большой, а трудозатрат – минимум.

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

А сейчас – дискотека с новым годом, коллеги!

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

Всех благ,

Сибирский ТАМ Виталий Ладыгин.