Демонстрация решения по управлению рисками и соответствием (Governance, Risk and Compliance Management Pack (GRC MP))
Спасибо Антону за подсказку по правильному названию и переводу.
TechEd Europe 2009 – Service Manager
Суть дела в следующем. Одним из критериев участия некоторых заказчиков в программе раннего ознакомления с SCSM (TAP – Technology Adoption Program), было использование ранних версий SCSM в реальной работе (“промышленная эксплуатация”, “production environment” и т.п.) Это подразумевает, что TAP-заказчики также будут иметь возможность переходить с беты 2 на более поздние бета- и финальную версии продукта. Незадолго до выпуска beta 2 мы нашли несколько багов, которые не давали выполнять такой апгрейд. Поэтому спустя месяц и было выпущено обновление Beta 2, в котором эти баги были устранены. Эти, а заодно и пара-тройка десятков других.
Обращаю ваше внимание на то, что “боевое” использование этой, или любой другой бета-версии SCSM поддерживается нами только для участников программы TAP. Это означает, что если ваша компания развернет SCSM и с ним возникнут проблемы, то у вас будет только неформальный (=негарантированный) канал поддержки через форум.
В обновление Beta 2 Update также включен “GRC Management Pack” (Governance, Regulations and Compliance). Многие, наверное, слышали про Sarbanes Oxley, HIPPA и т.д. Этот MP предназначен как раз для учета требований “регулирующих организаций” в IT. Подробней о GRC MP читайте здесь (англ.)
Наш партнер, канадская компания Provance Technologies Inc, также обновила бета-версию решения для управления ИТ-активами в среде SCSM. Подробности здесь.
По большому счету, если вас не волнует вопрос апгрейда и не интересен GRC MP, то вы можете тестировать и оригинальную бету 2. Существенных отличий в этом случае не будет. Если же вы хотите попробовать обновленную версию, то мы рекомендуем устанавливать ее с нуля, а не поверх какой-либо старой. Выложена она на все тот же сайт Connect, что и все предыдущие беты. Удачного тестирования!
Коллеги, в этом блоге начали появляться вопросы по установке, конфигурированию и использованию SCSM.
Увы, при всем моем желании у меня нет возможности отвечать на эти вопросы через блог:
- Это займет слишком много времени, которого и так не хватает
- SCSM как продукт еще не выпущен и официальной поддержки для него нет
- Неофициальная поддержка для тех, кто тестирует SCSM осуществляется через форум на английском языке (ссылка в “Полезных ресурсах”)
Цитата из к/ф “Берегись автомобиля”.
Да, поездочка получилась та еще – на три недели. Голландия-Франция-Германия-Россия. Удалось плотно пообщаться с двумя европейскими компаниями – участницами нашей программы “раннего ознакомления” – Technology Adoption Program (TAP). Одна из этих компаний уже использует продукт в реальной работе или, как часто любят говорить продвинутые айтишники, “в промышленной эксплуатации”. Интересно увидеть свое детище на практике …
Перед TechEd 2009 в Берлине мы провели двухдневную конференцию для таких заказчиков, на которой обсуждали вопросы “боевого применения” SCSM и планирование следующей версии.
Последняя часть поездки прошла в России. “Платформа 2010”, встречи с заказчиками, партнерами, сотрудниками Microsoft. Интерес к продукту очень велик. После часовой презентации на Платформе, я минут тридцать-сорок отвечал на вопросы на стенде System Center. Потом был вечерний круглый стол, который шел два с половиной часа вместо запланированного одного!!! Закончился он только тогда, когда сотрудники Центра Международной Торговли, где проходила конференция, стали недвусмысленно намекать, что пора закругляться и отключать технику :-)
Огромное спасибо сотрудникам Российского представительства Microsoft за приглашение на конференцию – она, на мой взгляд, получилась очень полезной и для участников, и для нашей команды. Кроме того, было очень приятно встретить моих бывших коллег, с которыми мы проработали вместе много лет. И небольшой отпуск в Москве и Самаре тоже совсем не помешал :-)
В общем, я вернулся. Ждите скорого продолжения серии про управление изменениями. Хотя … на этой неделе офис полупустой – Америка готовится к Thanksgiving Day (что-то вроде дня благодарения), на который народ разъезжается по родителям, жарит индейку непомерных размеров и т.п. Дальше и рождественские праздники не за горами. Но что-нибудь напишу …
Как же так, это уже вторая статья про управление изменениями с помощью SCSM, а про продукт еще ни слова не сказано? Скажу больше – в этой статье я, пожалуй, тоже ничего про продукт говорить не буду. Почему? А вот такие мы загадочные …
Говоря серьезно, продукт в процессе Change Management дает не более 30-50% успеха. Остальное – это дисциплина, дисциплина, и еще раз дисциплина. Можно это еще назвать “волей руководства” :-) Особенно это относится к организациям, только начинающим формализовывать свои процессы или находящимся в середине пути. Ну а поскольку такие организации и есть наш основной заказчик, то … давайте порассуждаем о подходах. Не переживайте, дойдет речь и до продукта … скоро … может быть …
Итак, представьте себе организацию, в которой администраторы приложений, системные и сетевые администраторы делают то, что считают правильным по своему собственному расписанию. Тут приходит новый, мудрый, и, наверное, еще неопытный IT менеджер и с порога заявляет “Мы будем жить теперь по-новому. Изменения вносить только через мой труп, шаг влево-шаг вправо – расстрел на месте”. Администраторы вежливо слушают, а про себя дружно говорят “Ага, щас!”. Возникает конфликт, и в нем явно будут пострадавшие. Будут ли победители – это вопрос. Какие-то процедуры внедрятся, что-то умрет своей смертью, чему-то помогут умереть … Вы не участвовали в таких инициативах? Я – нет, но видел их со стороны. Неприятное зрелище.
Другой подход – “неразрушающий”. Например, на первом этапе организация принимает правило “Сделал – запишись”. Это означает, что все внесенные изменения должны быть зарегистрированы в электронном или бумажном (зависит от организации) журнале. В простейшем виде это может быть файл Excel или текстовый документ.
На следующем этапе, через месяц-другой-третий, зарегистрированные изменения анализируются, и определяется категория изменений, для внесения которых требуется разрешение. На третьем этапе добавляются дополнительные процедуры – контроль тестирования, анализ рисков, утверждение службой безопасности, финансистами и т.д. и т.п. Этот подход гораздо более плавный, но и гораздо более медленный.
Во многих организациях чаще всего пытаются найти золотую середину, и сразу выделяют одну или несколько категорий изменений, которые должны находиться под пристальным вниманием. Примерами таких изменений могут быть крупные обновления компонент ключевых бизнес-систем, магистрального сетевого оборудования, массовые обновления клиентских компьютеров и т.п.
Вот и давайте предположим, что дальше мы будем иметь дело именно с такой компанией, которая шаг за шагом внедряет и развивает свой процесс управления изменениями.
Пусть для примера на первом этапе такая компания определяет всего три основных категории изменений:
- Стандартные
- Крупные
- Срочные
1. Стандартное изменение – это, как правило, периодически вносимое типовое изменение, которое уже многократно протестировано и риск от его внесения минимален. Нужно ли утверждать такое изменение, или нет – зависит от компании. В некоторых случаях компания может сказать что все стандартные изменения уже утверждены, в других – что требуется утверждение менеджером сотрудника, подающего заявку на изменение, и в третьем – что стандартные изменения должны быть утверждены менеджером по управлению изменениями.
Процедура, как говорил один доктор, проста до боли в позвоночнике:
- Подать заявку
- Утвердить заявку
- Исполнить заявку
- Закрыть заявку
2. Крупное изменение (как обобщение Minor/Major/Significant Changes). Ключевая характеристика такого изменения состоит в том, что оно должно утверждаться не одним сотрудником, а группой людей. В ITIL-овских терминах, и переводя на русский казенный язык, их называют Комитет по управлению изменениями. По-английски, соответственно, это Change Advisory Board, или CAB. Дальше я буду использовать именно эту аббревиатуру. В общем случае в CAB входят представители разных подразделений, принимающих участие в принятии решения – IT, финансы, безопасность, бизнес-подразделения. Пример процедуры для крупного изменения с подтверждением выполнения каждого этапа:
- Подать заявку
- Проанализировать и утвердить заявку менеджером по управлению изменениями
- Утвердить заявку комитетом по управлению изменениями
- Разработать решение
- Получить разрешение на тестирование
- Провести тестирование
- Получить разрешение на внедрение
- Провести внедрение
- Проанализировать результаты внедрения
- Закрыть заявку
Я опускаю ветвления в этом процессе. Если один из этапов завершается неудачно, то по решению менеджера либо комитета по управлению изменениями, этап может быть повторен, заявка может быть возвращена на один из предыдущих этапов, или все изменение может быть отменено. Кроме того, в конкретной организации в этот процесс могут быть добавлены дополнительные этапы, например, отдельное утверждение заявки непосредственным менеджером инициатора заявки.
3. Срочное изменение. Организация сама определяет, какое изменение является срочным. Например, любое изменение, которое должно быть внесено в IT-инфраструктуру быстрее чем за 24 часа, может считаться срочным. Такие изменения должны утвержаться отдельным “срочным” CAB-ом, или Emergency CAB (eCAB). В особо срочных случаях заявка может вноситься пост-фактум, уже после внесения изменения.
Процедура может быть аналогичной процедуре внесения крупного изменения, с упрощениями “по вкусу” конкретной организации.
В следующих статьях уже можно будет описать требования к продукту, вытекающие из этих подходов, и перейти наконец-то к самому продукту …
Поскольку в SCSM я отвечаю за решение для автоматизации процесса Change Management, то и рассказывать я буду больше всего именно о нём. Начну пожалуй, с общих организационных вопросов. Я не хочу слишком часто ссылаться на ITIL или MOF, поэтому описание это будет … скажем так: с точки зрения здравого смысла. Моего здравого смысла :-)
Для начала приведу простой пример из разряда ИТ-шных баек.
В одной крупной российской организации работал (и работает) очень опытный сетевой администратор А. Как-то ему нужно было произвести “перекоммутацию сетевых портов на сетевом устройстве”, а проще - вынуть провод из одного порта коммутатора, и переставить его в другой. В назначенное время А. идет в серверную, делает там что-то, возвращается на место …. Тут же взвывает система мониторинга, и минут через 5 на хелпдеск идут звонки пользователей о том, что сеть “лежит”. А. клянется-божится, что только вынул “назначенный провод”, … передумал, и воткнул его обратно, ничего не изменив. Вся ИТ-служба встает на уши, пытаясь обнаружить неисправность … В конце-концов, А. все-таки пошел в серверную и вернулся с виноватым видом: “Представляешь, я вынул провод, в это время меня кто-то окликнул, я обернулся, и одновременно, не глядя, ткнул этим проводом на прежнее место, и … попал в соседний порт!”… Вернул провод назад – все заработало.
Какие выводы можно сделать из этой ситуации?
- “У нас комендантский час”. Нечего проводить эксперименты и сами изменения на рабочей сети в рабочее время.
- “Покажите ваш мандат”. У потенциально опасных изменений должен быть утвержденный пошаговый план внесения изменений и отката назад в случае возникновения нештатных ситуаций.
- “Тренируйтесь на кошках”. Тестирования никто не отменял. Тестирования плана отката – в том числе.
- “Пантомима”. Перед внесением изменения неплохо провести тренировку с имитацией всех действий, в том числе проверку, все ли провода, гаечки-винтики, огнетушители-противогазы на месте :-) Забавная должна быть картина, не правда ли?
- “Правило четырех глаз”. Вносить такие изменения должны два человека. Один зачитывает очередной шаг из плана, второй его выполняет, первый контролирует результат. Если все нормально – переходят к следующему шагу, если нет – переходят на план отката.
- “Разбор полетов”, наказание невиновных и поощрение непричастных – обязателен для существенных изменений.
Конечно, такие действия для многих организаций выглядят довольно экстремальными. Но там, где от работоспособности ИТ-систем серьезно зависят доходы компании, а в некоторых случаях и жизни людей, дисциплина управления изменениями намного жестче. В этом цикле статей про Change Management в SCSM я попытаюсь использовать в качестве примера некую среднестатистическую организацию, не эксплуатирующую ядерные реакторы или оборудование для операционных в госпиталях, но тем не менее серьезно опирающуюся на ИТ в своей ежедневной деятельности.
Итак, зачем нужен процесс Change Management?
- Чтобы отфильтровать ненужные изменения
- Чтобы сделать процедуру внесения нужных изменений эффективной и безопасной.
1. Фильтрация ненужных изменений.
Профессия системного администратора – очень интересная! Так много всего хочется попробовать! А тут компанейские сервера, сетевые устройства, очень полезные книжки, интернет-форумы и блоги, которые только и говорят: “Измени настройки, и будет вам счастье!!!”. Спасибо, такого счастья вашей организации, скорее всего не надо. Изменения, которые не дают существенного улучшения в работе ИТ-систем для их пользователей, либо изменения, несущие неоправданный риск, скорее всего не должны вноситься. И первая задача процесса Change Management – убрать такие изменения из рассмотрения.
2. Эффективное и безопасное внесение необходимых изменений.
Если изменение необходимо, то внести его нужно так, чтобы потом не было мучительно больно за бесцельно прожитые годы. Это означает, что:
- Изменение должно вноситься в разумные сроки, как того требует бизнес
- Нужны процедуры для типовых видов изменений.
- Нужен анализ рисков, и их учет в этих процедурах.
- Нужен анализ последствий внесения изменения (разбор полетов) и учет ошибок.
- Нужна “политическая воля руководства” – а именно дисциплина, делающая исполнение этих правил обязательным.
Это не все. За исчерпывающим списком я отправлю вас в ITIL и MOF. Решение Change Management в SCSM помогает формализовать и автоматизировать многие из перечисленных выше пунктов. В чем SCSM не может помочь напрямую, так это в укреплении дисциплины в ИТ и воспитании воли руководства. О том как справиться с остальным – читайте в следующих статьях.
Нашел пару своих старых статей.
MOF дополняет ITIL, журнал “Открытые системы”, февраль 2004 года
Серия "ITIL-процессы на салфетке". Capacity Management на сайте itsmportal.ru.
Всего-то шесть лет назад …
Написано, наверное, резковато, но из песни слов не выкинешь. Что выросло – то выросло …
В старом советском фильме “Чапаев”, комиссар Фурманов спрашивал: “Василий Иваныч, а ты за какой Интернационал”? Я вспоминаю этот фрагмент каждый раз, когда меня спрашивают: “А какой подход лучше – ITIL, MOF или что-то еще”? Или: “С какой версией совместим ваш продукт?”.
Для меня этот вопрос - не слишком важный, и вот почему.
С одной стороны, я смотрю на него как IT-менеджер, занимавшийся в том числе и внедрением процессов “на стороне заказчика”. Мне, в принципе, было все равно, какая аббревиатура стоит в заголовке документа. Гораздо важнее было то, что в каждом из этих источников содержится “опыт-сын ошибок трудных”, накопленный другими организациями. Как говорят в армии, “Уставы писаны кровью”. Моя задача состояла в том, чтобы не проливать свою кровь, не тратить зря время и силы, а выбрать то, что будет полезно в моей компании, невзирая на источники. Поэтому мы брали то, что подходило нам, и наши процессы были именно нашими, а не айтиловскими, мофовскими и пр.
С другой стороны, работая в продуктовой группе, я вижу свою задачу в том, чтобы разработать инструмент, который удовлетворяет большинству разумных требований заказчиков. У меня на полке есть книги всех трех версий ITIL (да-да, начиная с первой – эти больше для хохмы, как и конвертик с Windows NT 3.1), есть доступ к электронным книгам по ITIL, ну и по определению к MOF-у тоже. Когда мы проектируем продукт, мы “обобщаем” информацию из разных источников, базируясь на собственном опыте, потребностях заказчиков, Microsoft IT, партнеров и коммерческих интересах Microsoft. И мнение этих авторов совсем не обязательно совпадает с мнением редакции!
Но! Для демонстрации возможностей продукта, для предоставления типового варианта автоматизации процессов, документирования, разрешения терминологических споров, мы берем за основу MOF. Тому есть несколько причин.
- Во-первых, MOF бесплатен. Т.е. скачивай с www.microsoft.com/mof и пользуйся. Любые ссылки на него, использование и пр. – да на здоровье! ITIL в его третьей версии изменил политику лицензирования, и теперь мы не имеем юридических прав использовать ITIL-овское содержание без дополнительных лицензий. А денежки нынче ой как считают …
- Во-вторых, как я уже писал выше, наш подход достаточно универсален. Хотите следовать ITIL-у с точностью до буквы – пожалуйста! ( Но я бы очень хотел увидеть организацию, которая сумела такое сделать. :-) ). Берите и модифицируйте наши решения, создавайте свои новые решения с нуля на платформе SCSM, трясите партнеров …
- В третьих, на вопрос про сертификацию продуктов PinkVerify, OGC и т.п. я, пожалуй, отвечать не возьмусь. Тут мы ориентируемся на наших заказчиков, и до тех пор пока существенная их часть не скажет “Продукты без сертификации “ЮЮЮ” покупать не будем”, мы сертифицировать SCSM тоже вряд ли будем. Кроме того, для ответов на глобальные вопросы бытия есть маркетинг, спрашивайте на форуме SCSM.
В общем, мне все равно, за какой вы Интернационал. Думаю, что мы справимся с любым. Есть желание подискутировать – пишите в комментариях.
С уважением, ВБ
Во вторник 13 октября, в час дня по “тутошнему” тихоокеанскому времени, либо в 12 часов в ночь со вторника на среду по московскому времени, мы проводим часовую “живую” презентацию возможностей по интеграции SCSM с другими системами, а именно с Active Directory, System Center Operations Manager и System Center Configuration Manager.
Выступают два сотрудника группы SCSM – мой шеф, Кейтан Гелани, и один из его подчиненных, а именно я. Кейтан покажет как данные из AD, SCCM и SCOM выглядят в SCSM, как алерты из SCOM попадают в SCSM и какой бардак они там устраивают, а я покажу, как можно автоматизировать функцию Change Management для отработки типовых заявок на включение пользователей в группы в AD. Интеграцию с функцией DCM решили не показывать – на нее не хватает времени.
Презентация опять не по-нашенски, но на продукт можно посмотреть и без знания английского (если вы достаточно заинтересованы, чтобы делать это в 12 часов ночи). Упор будет сделан не на слайды, а на показ живого продукта (ладно-ладно, беты 2). Вопросы можно задавать и по-русски (я пойму), но ответы будут по-английски. Кусочек этой презентации я наверняка покажу на “Платформе”.
Ссылка для регистрации тут. Запись трансляции через какое-то время выложат на сайте TechNet.
Приятного просмотра и спокойной ночи!
Сегодня была выпущена бета-2 System Center Service Manager 2010. После беты 2 в продукт почти ничего нового не добавляют, а в основном чинят баги, улучшают производительность и т.п. Хотя, если существенная часть заказчиков скажет “Без функции АБС ваш продукт – не продукт!”, то есть шанс получить и ее. Но очень небольшой …
Как ее добыть
Зарегистрируйтесь на сайте Connect www.connect.microsoft.com. Для этого нужен Live Passport. Откройте страничку Connection Directory:
Найдите на ней линк на Operations и Service Manager:
Дальше, думаю, уже понятно куда тыкать-кликать и что делать.
Файлы
· SMCDImage_amd64.exe (64-х битная консоль и серверная часть)
· SMCDImage_x86.exe (32-х битная консоль)
· OMMPsForTap.zip (дополнительные Management Packs для Service Manager. Перед установкой прочтите readme, чтобы понимать, на что вы идете :-)
· AuthoringTool.exe – консоль разработки
· SM_B2_Public.zip – документация
Поскольку это бета, то очень рекомендую почитать readme – там документируются наиболее критические ошибки, которые мы не успели поправить в этом релизе. Ну и читайте документацию!
Отклики
Свои отклики на русском языке вы можете оставлять на этом сайте в комментариях, слать их мне по почте (есть кнопочка EMail наверху).
Если у вас все хорошо с английским, то вы можете использовать раздел “Feedback” на сайте Connect, а также пообщаться с разработчиками в форуме (см. линк в разделе “Полезные ресурсы” в колонке слева).
Удачного тестирования!
Дэн Болдо из нашей команды записал серию видео роликов с демонстрациями функций портала пользователя. В роликах вы услышите следующие названия:
- End User Portal - “основной” портал, который видят пользователи
- Self-Service Provisioning Portal – компонента портала пользователя для “заказа” и установки программного обеспечения через System Center Configuration Manager
- Analyst Portal – портал для IT (не показан на этих демонстстрациях). Используется в основном в процессе Change Management для работы с нарядами на работы (в нашей интерпретации- Manual Activities), или утверждения запросов на изменения или этапов в процессе управления изменениями (у нас это называется Review Activities)
Если в процессе просмотра вы ткнете в кнопочку, которая на картинке ниже обведена красным, то увидите полноэкранное видео.
Итак, демо о семи частях:
| Часть первая, лирическая. Дэн показывает основные возможности портала пользователя. | |
| Часть вторая, инцидентная. Тот же автор демонстрирует, как послать свое “фи” в подразделение ИТ, используя портал. | |
| Часть третья, “вы сами виноваты”. То, как ИТ-подразделение увидит “фи” от пользователя в консоли SCSM. | |
| Часть четвертая, “Сделай сам”, подготовительный этап | |
| Пятая часть, “Сделай сам”, этап “Витрина” | |
| Мысли Дэна по поводу нашей системы SSSP (Self-Service Software Provisioning), она же подсистема для заказа установки программного обеспечения | |
| Размышления на тему пользовательского портала в SCSM 2010 | |
Еще одно видео про SCSM 2010
Мы начали выкладывать демонстрационные видео SCSM 2010. Пока они есть только на английском языке. Надеюсь, что аналогичные презентации на русском не за горами.
Этот ролик был снят на весенней конференции Microsoft Management Summit 2009.
Вслушивайтесь, всматривайтесь, наслаждайтесь, пугайтесь-ругайтесь – кому что :-)
