Comments 35
Плюсик Вам, однозначно. Интересная статья, для первого раза планировка инфраструктуры очень неплоха. Внедрение новых программно-аппаратных комлексов — вообще штука интересная, и всегда небольшой (или большой) праздник для сисадмина. По себе знаю.
+1
Читал с удовольствием. Спасибо :)
Может на каких-то моментах поподробнее остановиться?
Может на каких-то моментах поподробнее остановиться?
0
Старался кратко обобщить имеющийся опыт. Далее можно подробнее рассмотреть конкретные моменты. Какие именно интересны?
0
Ну и на внедрениях можно остановится поподробнее, ведь не все так гладко проходит, как нам хочется.
Да и правильному диалогу между ИТ и бизнесом могли бы поучить на практических примерах. Было бы интересно.
Да и правильному диалогу между ИТ и бизнесом могли бы поучить на практических примерах. Было бы интересно.
0
На внедрении чего именно стоит остановиться подробнее? В принципе, можно сказать, что все процессы внедрения у нас проходили вполне гладко и, как раз так, как и хотелось. Скорее всего, этому способствовало предварительное изучение материалов Technet и подобной технической литературы.
Правильному диалогу поучить не готов, но могу озвучить некоторые свои соображения. Необходимо в понятной форме донести до руководства суть проблемы и красочно описать сопутствующие тому риски. Предложить конкретное решение проблемы с четко очерченными рамками бюджета. Рассказать о новых возможностях, преимуществах и экономической эффективности вашего решения. Аргументировать свой выбор, ссылаясь на мировые практики, общепринятые стандарты, успешный опыт коллег или конкурентов, на мнение внешнего приглашенного эксперта (в случае, если недостаточно собственного веса) и т.д. Предложить сделать выбор, т.е. снять с себя ответственность и переложить ее на руководство, объяснив при этом, что только в случае согласия, вы лично можете гарантировать отсутствие рисков. Как то так…
Когда меня приглашают на зарождающийся проект в качестве внешнего эксперта, мне достаточно просто, мне априори доверяют. Я открываю ноутбук и показываю, как легко удаленно работать с информацией (это удаленный доступ к порталу SharePoint, к почтовому ящику Exchange через HTTPS, это полноценный Outlook, это и VPN с тяжелыми приложениями через RDP и любыми другими задачами). А это, обычно, первостепенная задача руководства – получать доступ к ресурсам ИС из любого места. Далее, я показываю внушительную (толстую) документацию, где много цветных картинок (приятные глазу, схемы Visio). После этого, обычно, руководство желает, чтобы у них тоже всенепременно была документация и, обязательно, с «красивыми картинками».
Следующим шагом, изучаются задачи предприятия и проводится технический аудит сервисов, результатом которого является подробный отчет с описанием имеющимися отклонений и рекомендациями по устранению. Обычно, прикладывается предложение, включающее общий дизайн будущей инфраструктуры и предварительные расчеты стоимости. Это, примерно, 20 страниц текста и 2-3 схемы на выходе. В очередной раз проводится встреча, где популярно, с примерами, объясняется суть отчета об аудите и предложения. После этого, чаще всего, руководство спешно выделяет средства. Как то так…
Правильному диалогу поучить не готов, но могу озвучить некоторые свои соображения. Необходимо в понятной форме донести до руководства суть проблемы и красочно описать сопутствующие тому риски. Предложить конкретное решение проблемы с четко очерченными рамками бюджета. Рассказать о новых возможностях, преимуществах и экономической эффективности вашего решения. Аргументировать свой выбор, ссылаясь на мировые практики, общепринятые стандарты, успешный опыт коллег или конкурентов, на мнение внешнего приглашенного эксперта (в случае, если недостаточно собственного веса) и т.д. Предложить сделать выбор, т.е. снять с себя ответственность и переложить ее на руководство, объяснив при этом, что только в случае согласия, вы лично можете гарантировать отсутствие рисков. Как то так…
Когда меня приглашают на зарождающийся проект в качестве внешнего эксперта, мне достаточно просто, мне априори доверяют. Я открываю ноутбук и показываю, как легко удаленно работать с информацией (это удаленный доступ к порталу SharePoint, к почтовому ящику Exchange через HTTPS, это полноценный Outlook, это и VPN с тяжелыми приложениями через RDP и любыми другими задачами). А это, обычно, первостепенная задача руководства – получать доступ к ресурсам ИС из любого места. Далее, я показываю внушительную (толстую) документацию, где много цветных картинок (приятные глазу, схемы Visio). После этого, обычно, руководство желает, чтобы у них тоже всенепременно была документация и, обязательно, с «красивыми картинками».
Следующим шагом, изучаются задачи предприятия и проводится технический аудит сервисов, результатом которого является подробный отчет с описанием имеющимися отклонений и рекомендациями по устранению. Обычно, прикладывается предложение, включающее общий дизайн будущей инфраструктуры и предварительные расчеты стоимости. Это, примерно, 20 страниц текста и 2-3 схемы на выходе. В очередной раз проводится встреча, где популярно, с примерами, объясняется суть отчета об аудите и предложения. После этого, чаще всего, руководство спешно выделяет средства. Как то так…
+1
вам работа в кувейте не интересна системным администратором? :)
+2
Хотелось уточнить — какое количество пользователей на текущий момент в вашей организации?
+1
всем бы такое понимающее и платежеспособное руководство.
+2
Интересное замечание.
На мой взгляд, основная проблема «понимающее и платежеспособное руководство» заключается, именно, в отсутствии диалога между представителями ИТ и руководством. То, что я зачастую вижу, это ИТ не может донести до руководства свое видение, преимущества предлагаемых решений, объективно показать имеющиеся отклонения и риски, с ними связанные, в формате «просто о сложном». Особенно большой трудностью для ИТ является разговор на «языке финансовых показателей», столь привычный бизнесу. Отсутствует понимание руководством ИТ, что является главной предпосылкой к недоверию… Недавний мой проект «Организация комплекса мероприятий по модернизации и оптимизации ИТ-инфраструктуры компании» в одной развивающейся компании, наглядно показал, как некогда весьма прижимистый собственник, способен инвестировать миллионы в ИТ.
На мой взгляд, основная проблема «понимающее и платежеспособное руководство» заключается, именно, в отсутствии диалога между представителями ИТ и руководством. То, что я зачастую вижу, это ИТ не может донести до руководства свое видение, преимущества предлагаемых решений, объективно показать имеющиеся отклонения и риски, с ними связанные, в формате «просто о сложном». Особенно большой трудностью для ИТ является разговор на «языке финансовых показателей», столь привычный бизнесу. Отсутствует понимание руководством ИТ, что является главной предпосылкой к недоверию… Недавний мой проект «Организация комплекса мероприятий по модернизации и оптимизации ИТ-инфраструктуры компании» в одной развивающейся компании, наглядно показал, как некогда весьма прижимистый собственник, способен инвестировать миллионы в ИТ.
+3
Достаточно интересная статься, особенно понравилось понимание руководства в нужности в ИТ и его финансировании, без этого всей красоты не было бы. Ведь к сожалению даже простой организации из-за отсутствия простого кондиционера в серверной не всегда открывает кошелек.
+1
ну и бюрократию вы у себя развили
куча журналов куча отчетов
куча журналов куча отчетов
-2
Дааа… Мощно… Мой первый плюсик безоговорочно достается вам :)
А можно ссыль на сайт, просто любопытно — где такие рукастые ИТ-шники работают :)
А можно ссыль на сайт, просто любопытно — где такие рукастые ИТ-шники работают :)
+1
А расскажите, какой у вас СЭД на SharePoint используется?
0
Статья, безусловно, интересная и полезная как пример использования возможностей SharePoint.
Фактически автор реализовал функционал дорогих ITIL продуктов на базе SharePoint. Жалко не приведены скриншоты.
Но, я все таки считаю, что данные и логику всего этого хозяйства правильнее организовать в виде отдельного приложения на основе SQL Server, а SharePoint использовать как Front-End. Правда, здесь уже нужно будет привлекать разработчиков.
Не могли бы вы дать ссылку на ваш интернет сайт на базе SharePoint. Укромно так. :) Дабы избежать хабраэффекта.
Фактически автор реализовал функционал дорогих ITIL продуктов на базе SharePoint. Жалко не приведены скриншоты.
Но, я все таки считаю, что данные и логику всего этого хозяйства правильнее организовать в виде отдельного приложения на основе SQL Server, а SharePoint использовать как Front-End. Правда, здесь уже нужно будет привлекать разработчиков.
Не могли бы вы дать ссылку на ваш интернет сайт на базе SharePoint. Укромно так. :) Дабы избежать хабраэффекта.
0
А как документацию составляли? Шаблоны были? Или разрабатывали? Можно посмотреть? =)
0
Наша документация — результат нескольких попыток «систематизировать и описать». Первые варианты были ужасны… Никаких шаблонов не было и подсмотреть было не у кого… Скажу только, что ключевым элементом, является сервис, предоставляемый клиенту. То, что я видел впоследствии у других, опиралось на ключевой элемент сервер.
Есть схемы с описаниями общего дизайна инфраструктуры, списки используемого оборудования и ПО, схемы размещения оборудования и описания, логические схемы размещения сервисов и служб (зависимости), основные настройки серверов. А далее документы сгруппированы по сервисам — описание, схемы (если нужно), настройки, специфика, организация резервного копирования и т.д. Например, сервис физических коммуникаций имеет территориальную схему (где, какой кабель, протяженность, пропускная способность) с пояснением и схемы подключения оборудования (где, какие VLAN'ы, агрегированные группы, клиентские порты) по точкам коммутации с пояснениями, конечно же…
Основная задача документации — подробно описать то, что отличает текущую реализацию от конфигураций «по умолчанию».
Вообще, наверно, разработка документации — тема отдельной статьи.
Есть схемы с описаниями общего дизайна инфраструктуры, списки используемого оборудования и ПО, схемы размещения оборудования и описания, логические схемы размещения сервисов и служб (зависимости), основные настройки серверов. А далее документы сгруппированы по сервисам — описание, схемы (если нужно), настройки, специфика, организация резервного копирования и т.д. Например, сервис физических коммуникаций имеет территориальную схему (где, какой кабель, протяженность, пропускная способность) с пояснением и схемы подключения оборудования (где, какие VLAN'ы, агрегированные группы, клиентские порты) по точкам коммутации с пояснениями, конечно же…
Основная задача документации — подробно описать то, что отличает текущую реализацию от конфигураций «по умолчанию».
Вообще, наверно, разработка документации — тема отдельной статьи.
0
Было бы неплохо все же разделить раздел «Управление ИТ – это система» на абзацы. Тяжеловато читать.
0
:) а я в свое время 4 месяца выбивал у руководства простенький сервер под контролер домена… сеть тогда была 50+ машин и все это в воркгруп :(
0
Спасибо за статьи, отличное описание ИТ-системы. Побольше бы таких специалистов!
Хочу только отметить, вам очень повезло, что изначально инфраструктуры на предприятии практически не было — строить самому намного проще, чем переделывать уже имеющуюся помойку.
Хочу только отметить, вам очень повезло, что изначально инфраструктуры на предприятии практически не было — строить самому намного проще, чем переделывать уже имеющуюся помойку.
0
Проще всего строить с нуля и единовременно, т.е:
— провели заказчику аудит, сделали предложение
— согласовали концепцию, бюджет мероприятия
— заказали оборудование, ПО
— разработали документацию, согласовали
— развернули сервисы, протестировали и сдали
— мигрировали данные и запустили в эксплуатацию
— актуализировали документацию и сдали
— отпустили заказчика в свободное плавание и оказываем техническую поддержку
а старой «уже имеющейся помойкой» можно и пренебречь (обычно).
В нашем же случае, внедрения происходили поэтапно (очень растянуто по времени), реактивно (латание «дыр»), неорганизованно (отсутствие четкого планирования) и без отрыва от производства (останавливать работу нельзя). В таких условиях очень сложно получить приемлемый результат.
— провели заказчику аудит, сделали предложение
— согласовали концепцию, бюджет мероприятия
— заказали оборудование, ПО
— разработали документацию, согласовали
— развернули сервисы, протестировали и сдали
— мигрировали данные и запустили в эксплуатацию
— актуализировали документацию и сдали
— отпустили заказчика в свободное плавание и оказываем техническую поддержку
а старой «уже имеющейся помойкой» можно и пренебречь (обычно).
В нашем же случае, внедрения происходили поэтапно (очень растянуто по времени), реактивно (латание «дыр»), неорганизованно (отсутствие четкого планирования) и без отрыва от производства (останавливать работу нельзя). В таких условиях очень сложно получить приемлемый результат.
+1
Очень хороший цикл топиков :)
Единственное что так и не заметил — а данные/настройки и т.д. вы куда-то резервируете/архивируете?
Единственное что так и не заметил — а данные/настройки и т.д. вы куда-то резервируете/архивируете?
0
Конечно архивируем, в сетевое хранилище для резервных копий… БД, данные состояния систем, прочие настройки (которые умеют выгружаться) по расписанию посредством NTBackup. А далее, все это, с помощью скриптов упаковывается в архивы (имя-дата). Необходимое количество резервных копий хранится и циклично перезаписывается следующими. Все, что необходимо хранить дольше, периодически записывается на DVD.
0
UFO just landed and posted this here
прям как про себя прочитал, только мне еще телефонию привесили
0
Sign up to leave a comment.
История одной инфраструктуры. Решения MS. Часть 3