понедельник, 21 сентября 2009 г.

Смысл и предназначение Microsoft Office SharePoint Server

О Microsoft Office SharePoint Server, внедренном на предприятии (часто внедренном стихийно), довольно часто можно услышать смешанные отзывы – часто говорят, что система непонятно для чего предназначенная, трудноадминистрируемая и прочее.
Часто приводят в пример свободное ПО, предназначенное для узких целей – к примеру, средства для организации Интернет-форумов – и говорят о них как о замене SharePoint. Мол, «для коллективных обсуждений удобнее пользоваться таким-то таким-то форумом, и просто и быстро и и администрировать проще».
В общем, отзывов очень много и все разные. Хотелось бы резюмировать несколько аспектов моего видения данного продукта… Дело в том, что компания Microsoft в разработке и позиционировании многих своих продуктах руководствуется принципом платформы, или, если хотите – конструктора. Касается это не только MOSS; яркий пример – продукты System Center, скажем, System Center Operations Manager. Инсталлировав этот продукт «из коробки» - мы мало что получим кроме минимальных данных о доступности базовых сервисов, на которые мы его «натравим». Полезность близка к нулю. А в другой ситуации, когда мы используем проектный подход в пику стихийному использованию, то есть: проводим исследование потребностей и требований, формируем концепцию решения мониторинга и управления ИТ-инфраструктурой, расписываем сценарии инсталляции, администрирования и эксплуатации, сформировав системные требования для данной конкретной ситуации – мы получаем решение, а не инсталляцию продукта. Это решение представляет собой идею, стратегию, воплощенную при помощи какой-то платформы-конструктора. В общем, это почти то же самое, о чем я говорил в предыдущем посте про хорошую AD и плохую AD.
О платформе какого рода следует говорить касательно MOSS? Есть много замечательных картинок, вроде приведенной мной, которая, собственно, все и объясняет:

Итак, SharePoint – это платформа для организации:
1. Совместной работы
2. Корпоративного портала
3. Управления содержимым
4. Управления бизнес-процессами
5. Бизнес-анализа
6. Корпоративного поиска
Итак, стоит пораздумать над тем, что MOSS – это в первую очередь платформа-конструктор для реализации с помощью ее средств самых различных решений по вышеуказанным направлениям. И эту платформу можно оттачивать и настраивать под самые различные нужды, и уже потом – судить о быстродействии, эффективности и простоте использования. И самое главное в самом начале – понять, что же мы хотим получить в итоге, какую систему, для решения каких задач.



А еще MOSS очень интересно рассматривать в качестве платформы интеграции бизнес-приложений! Но это, как писали братья Стругацкие, уже совсем другая история… И совсем другой пост, который, возможно, тут появится в скором времени… Можно делать заявки :)






А что же происходит в не самом лучшем случае? Представьте такую ситуацию – Вы купили партию стройматериалов: цемент, камень, брус, кирпич, арматура, песок, пеноблоки, стекло, доски, шифер… огромную кучу всего подряд. Затем пытаемся использовать эти материалы сразу как есть: шифером пытаемся укрыться от дождя, доски пытаемся сложить вокруг себя так, чтобы не дуло и не морозило, а пеноблоки начинаем класть, не посчитав их количество и не представляя, что хотим из них сложить в итоге. Ну, какие отзывы мы услышим от того, кто всем этим будет заниматься? :)









Ну вот, собственно, такие мысли о предназначении ПО и стройматериалов :) Удачи Вам и бесперебойного функционирования Вашей ИТ-инфраструктуры, а главное – светлой и ясной погоды в личной жизни!

понедельник, 14 сентября 2009 г.

Active Directory - что такое хорошо и что такое плохо.

Эникейщик к нам пришел
И сказал нам кроха:
"Active Directory - хорошо,
А развернули плохо."

Мы часто слышим "плохая AD", "грамотная AD", "кривая AD" и много других самых разнообразных эпитетов в адрес того или иного частного случая развертывания данной службы каталогов. Если попытаться спросить, что же означает на деле то или иное определение - то администратор (а зачастую, как бы ни было печально, и инженер) с трудом могут сформулировать, "что такое хорошо и что такое плохо".
Попытаемся прикинуть данные определения хотя бы на верхнем уровне. Итак, что же такое оптимальная структура AD?
Это служба каталогов Microsoft Active Directory, которая:

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


Значит это ровно следующее: спроектирована структура AD, в которой учитывается существующая инфраструктура LAN предприятия, связи всех территориальных подразделений, а также заранее спланированы все изменения, которые в эту инфраструктуру придется внести перед внедрением AD. Как пример - от того, чтобы найти и исключить банальный "перехлест" адресации (если в компании существуют изолированные подсети с одинаковой адресацией - в тех подразделениях, которые планируются к объединению), вплоть до того, чтобы найти какое-нибудь отдаленное подразделение, где IP-адреса хостам выдаются вручную системными администраторами.
На этой стадии - стадии исследований - также необходимо уберечь себя от потенциальной дальнейшей беготни по поставщикам оборудования и ПО; необходимо тщательно продумать и спланировать закупки и спецификации аппаратного и программного обеспечения с учетом роста инфраструктуры и обеспечения ее отказоустойчивости.
Отдельной строкой необходимо подойти к исследованию организационной структуры предприятия, иерархии отделов, структуры подчинения, размещению ИТ-отделов и специалистов в филиалах и так далее - исходя из этого мы будем планировать количество лесов, доменов, а также количество и структуру Organizational Units.

И вот у нас появляются результаты предпроектных исследований, оформленные в красивый отчет. Но этого мало для начала внедрения. Нам необходимо, чтобы проектируемая структура AD соответствовала не только требованиям организации, но и рекомендациям и лучшим практикам от производителя - Microsoft, так как нам необходимо обеспечить еще и отказоустойчивость, масштабируемость и надежность внедренной Системы. Best practicies переписывать особой нужды не вижу - все они доступны в открытых источниках. Пользуясь случаем, хочу еще раз настоятельно порекомендовать к прохождению курсы от Microsoft по планированию, дизайну и проектированию архитектуры Active Directory. Собственно, разобравшись в ней, вы поймете, что все описанное в данном посте - лишь краткие заметки о замечательной, красивой и интересной работе - организации единой службы каталогов предприятия.

На все сказанное можно резонно возразить: "У нас AD развернута стихийно, на коленке - и все работает, все десять филиалов получают доступ к файловым серверам, принтерам, к корпоративному порталу и почте - и у нас все окей, ничего не отказывает, ничего не надо реконфигурировать и изменять, все крутится на одном контроллере домена и ничего не падает".
На это возражение я могу привести ряд ситуаций, над которыми прошу вас подумать:
  • Что вы будете делать, если не дай Бог (тот, в которого Вы верите) - полыхнет контроллер домена? Железо не вечно, а данные каталога имеют намного ценность намного более высокую, чем это железо. Как вы производите резервное копирование AD? Сколько раз и в скольких различных ситуациях вы тестировали аварийное восстановление служб каталогов? На сколько тысяч рублей будет урезана Ваша зарплата, если сотрудники предприятия на один день останутся без доступа к корпоративным ресурсам?
  • Какие Вы предпримете действия, если ваша компания будет приобретена другой компанией, или, дай вам Бог (тот, в которого Вы верите) - ваша компания приобретет пару-тройку предприятий? Выдержит ли ваша структура AD расширение и объединение с другими предприятиями-модулями? Сколько ночей Вам придется провести на работе, "руками" перенося данные о пользователях из другого домена?
  • Разрешения на ресурсы выдаются отдельным пользователям или группам пользователей? Если отдельным пользователям - представьте, сколько времени Вы убьете на выдачу разрешений на какой-нибудь узел корпоративного портала, когда ваша компания вырастет раза хотя бы в два.
  • И многое, многое, многое другое. Надеюсь, что у меня получилось разбудить Вашу фантазию! Проблемы с вводом новых сервисов, трудноотлавливаемые проблемы в работе бизнес-приложений, неработающие схемы аутентификации (привет, Kerberos!), головная боль с паролями пользователей и назначением им прав, разруливание ситуаций со сложным трастами между десятками доменов и вообще проблемы со ВСЕЙ ИТ-инфраструктурой... В общем, мрак и ужас.
Желаю Вам удачной работы и беспроблемного функционирования Вашей ИТ-инфраструктуры. Полюбите планировать изменения и нововведения - и ИТ-инфраструктура полюбит Вас и поможет успешно заниматься производственными задачами.
Хорошей погоды всем!

среда, 9 сентября 2009 г.

AIIM ECM Practitioner, MCTS и прочее интересное.

Здравствуйте.
17го сентября сего года отправляюсь в Москву с целью прохождения курса AIIM ECM Practitioner. С нетерпением жду сего события, программа обучения обещает быть весьма интересной. Рекомендую к ознакомлению:
http://www.docflow.ru/ecm_practitioner/
Также хотелось бы подчеркнуть, что данный именитый курс впервые читается в России. Более подробно с данным видом обучения можно ознакомиться у авторов:
http://www.aiim.org/Education/ECM-Enterprise-Content-Management-Training-Courses.aspx
На данный момент регистрация закончена, но если вдруг Вам очень хочется туда попасть - ко мне можно обратиться в комментариях, могу помочь с продлением регистрации.
В дальнейшем в блоге будет размещен отчет о курсе - краткое ревью, а также описание моего дальнейшего пути в части получения сертификата ECM Practitioner - по окончанию курса дается три попытки сдать экзамен в течение трех месяцев.
Надеюсь в ближайшем будущем присовокупить данные компетенции к своим MCTS и MCBMSS -) Пожелайте удачи)