Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

А у вас есть план провала проекта и отката к предыдущим системам?

А у вас есть план провала проекта и отката к предыдущим системам?

Внедрять новые ИТ-системы — просто. Запустил install.exe, ответил на десяток вопросов в мастере и вот уже у пользователя новая система. Осталось только перенести в нее пользовательские данные, процедуры и процессы и убедиться, что все работает. В этом месте обычно случается  «Упс!».

Чем сложнее в ИТ-системы, тем больше вероятность, что с первой попытки решение не заработает.

Впрочем, есть и другие причины отказаться от новых ИТ-систем:

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

 Объективных причин для прекращения ИТ-проекта может быть множество. В конце-концов ИТ-компания может просто не справиться со своей работой. И вот тут очень важно за время внедрения не разрушить бизнес клиента.

Что делать? Общее правило миграции ИТ-систем: «Семь раз отмерь — один отрежь».

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

Создавайте план отката изменений. На тестовом стенде необходимо отработать и документировать не только процесс миграции ИТ-систем, но и откат к предыдущему решению.

Резервное копирование. Сначала сохраняем работающую систему — затем делаем обновление. Наличие резервной копии позволяет значительно снизить риск неправильного развертывании новых версий и обновлений.

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

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

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

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

Дополнительные материалы

Комментарии (19)

  • Аватар

    Чижиков Владимир [Skif Swarogich], 16 февраля 2011, 20:44

    0
    Внедрять новые ИТ-системы — просто. Запустил ...
    Я думаю стоит заменить фразу на "инсталлировать новые ИТ-системы". Всё же внедрение это более чем инсталляция ПО.
  • Аватар

    Савчук Виктор [TigerS], 16 февраля 2011, 22:05

    0
    Внедрял много, хоть и достаточно простые проекты.
    По этой теме, я так понимаю, главное - миграция (переход на новую систему с сохранением старых данных)
    Главных принципов было несколько:
    1)первому внедрению предшествует определенный период параллельного ведения СУБД (и сравнение результатов по важным параметрам). Да. Нужно надавить на руководство клиента - премировать сотрудников, занимающихся двойной работой. А что делать? ... ах, да. Можно конечно заранее завысить стоимость проекта и премировать из собственных средств ;)
    2)введению любой новой версии предшествует бекап строй БД, исполняемого файла и настроек
    3)любая новая версия (миграция) обкатывается на "сообщниках" (наиболее ответственная группа пользователей, работа которых напрямую зависит от внедряемого ПО). Как этих сообщников заиметь - уже отдельная тема  :)  Период обкатки зависит от сложности изменений (обычно хватало 1...5 дней)
    4)обеспечить достаточно легкий возврат к предыдущей, работоспособной версии, самим пользователем (исключая случаи серьезных изменений в структуре БД).  Иногда только вернешься от клиента - уже звонят - выявлена ошибка. Как нам работать до вашего приезда?  ;).  Нам хватало батника (вернее ярлыка на батник) на раб.столе юзеров.
  • Аватар

    Давлицаров Андрей Рустемович [Tomi], 16 февраля 2011, 22:07

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

      Рубинштейн Кирилл [krubinshteyn], 17 февраля 2011, 11:57

      0
      небольшой оффтоп: у вас что на рабочих станциях? Линукс/Виндовз или МСВС (что вроде как fork-нутый линукс для военных)?
      • Аватар

        Котельников Илья [iluha], 17 февраля 2011, 14:45

        0
        Кирилл, а ты с какой целью интересуешься?
        Через 15 минут тебе в дверь позвонят приятные молодые люди и ответят на все-все вопросы :)
        • Аватар

          Рубинштейн Кирилл [krubinshteyn], 17 февраля 2011, 14:50

          0
          мне кажется, что после фразы "...я работаю сисадмином на военной станции..." в дата-центр за серваками отправилась бравая-команда людей, работающих сисадминами в других интересных организациях:). Правда, дата-центр в германии, так что у нас ещё есть время пообщаться.
          • Аватар

            Давлицаров Андрей Рустемович [Tomi], 17 февраля 2011, 23:09

            0
            Кирилл, рад, что вы знаете, что существует такое "чудо", как МСВС - вынужден был сталкиваться. Она разрешена у нас к использованию. Винды - нет. Название, видимо, кому-то не понравилось и подать платить за океан не захотелось. Их дело. У нас нормальный цельнотянутый SPARC. Надеюсь, понимаете, какая техника в России существует: цельнотянутая и кусочно-содраная по технологии изготовления. Выпускается вполне официальной компанией Московский центр СПАРК-технологий - МЦСТ. Он рекомендован кем надо (их целая комиссия) мне вместе с его SunOS и доработками гомельских коллег КБ системного программирования (КБСП) - одна из лучших компаний по работе с ядрами систем в Беларуси. Это про инструментарий.
            С точки зрения страхов про "молодых людей". Пять лет назад у нас появился новый ФСБ-шник. Лысый, круглый и шустрый. Первый приказ, который он издал - запретить вносить на объект флэшки, ноутбуки и пользоваться мобильниками. Но на станции нет телефоннойсвязи. Поэтому все равно все переговоры идет по мобильной связи - работать то надо.  С ним в паре появился высокий, тонкий, и тоже лысый. Я сразу окрестил эту пару по журналистской привычке "ФСБ-шной братвой". Прошло время. Сейчас не мешают. Да и военные, которые с нами работают их инстинктивно недолюбливают - предупреждают о появлении на объекте.
             

  • Аватар

    Котельников Илья [iluha], 17 февраля 2011, 10:23

    0
    При внедрении любого проекта всегда есть "точка невозврата", откуда уже нельзя откатиться на старую систему.
    Но пока Вы до нее не дошли, безусловно, стоит поддерживать жизнеспособность старой системы и держать запасной план. Важный момент, кстати, не особо распространяться на счет наличия этого запасного плана. Пусть он будет вашим тузом в рукаве.
    Когда о возможности отката знает слишком много людей, многократно возрастает риск саботажа...
  • Аватар

    Яковлев Андрей Михайлович [swtws], 17 февраля 2011, 14:43

    0

    К последнему пункту. Пользователей надо предупредить, что грядет неизбежное глобальное Изменение, каковое вызовет кучу инцидентов, чего избежать нет никакой силы-возможности. То есть это как стихийное бедствие.  План отката изменения всегда должен быть, но на практике через гору инцидентов, жалоб, скандалов, обещаний больше никогда не связываться наступает Светлое Будущее. Человеческий консерватизм и нежелание учиться часто создают больше проблем чем несовместимость нового офиса и старых на-коленке-писаных скриптов. Их также на коленке и переписывают. Критичность простоя даже у крупных компаний сильно завышена. Во фразе "мы потеряли 10 клиентов, которые были готовы..." означает, что   это были потенциальные клиенты клиенты и их потеря могла произойти и так.
    Из практики. Авария (не изменение) привела двухнедельному простою. Сорвался один постоянный клиент - ох и мата было в сторону поставщиков железа. На самом деле у этого клиента конкуренты  фирмы имели лобби и далее все понятно.

    • Аватар

      Котельников Илья [iluha], 17 февраля 2011, 14:54

      0
      Да, меня всегда забавляли переговоры, начинавшиеся со слов
      "Час простоя нашего офиса стоит N-миллионов рублей"...
      Так и подмывает после этого губозакаточную машинку таким "милионникам" подарить :)
      На практике простой - это когда вместо того, чтобы вяло жевать сопли и создавать видимость рабочей деятельности, сотрудники начинают к любимому жеванию соплей добавлять звонки начальству (периодичность 5-15 минут) с жалобой о невозможности работать.
      • Аватар

        Яковлев Андрей Михайлович [swtws], 17 февраля 2011, 17:13

        0
        Илья, Решение за 1 час  - N %  от проблемы простоя 8 часов, и сразу простой дешевеет. Как и данные - сдох RAID - данные ну очень ценные (бэкап откатит на утро), гуд,  10% от стоимости, но не менее 9000 руб. И данные обесцениваются до нуля.
        Поэтому реально планы аварийного восстановления и дополнительную плату за грамотный план изменений (с откатом, как и положено по "лучшим практикам") деньги получить сложно. 
      • Аватар

        Савчук Виктор [TigerS], 17 февраля 2011, 17:20

        0
        ----На практике простой - это когда вместо того, чтобы вяло жевать сопли и создавать видимость рабочей деятельности, сотрудники начинают к любимому жеванию соплей добавлять звонки начальству (периодичность 5-15 минут) с жалобой о невозможности работать.

        А вот это кстати не факт.
        Я внедрял и вел СУБД абонотдела БТИ (Бюро Технической Инвентаризации).
        Очереди там никогда не кончались. Так что при любом простое, кроме прямых денежных убытков для БТИ, еще и админам было что слушать от стоящих в очередях людей  :)
        Поэтому все внедрения новых версий проводились часика за два до начала работы отдела. С тройной перестраховкой.
        Бекап базы делался каждые 10 минут  :)
        При этом еще данные за сегодняшний день паралельно с внесением в основную БД - заносились в простенький текстовый файлик. Если основная БД рухнет (было как-то такое) - всегда можно по быстрому поднять версию за предыдущие 10 мин. А уж вечером довнести
        потерянные квитанции.
        Вот такая "военная" перестраховка была. Как говорится было "сделано с любовью"...  и заботой о себе любимом :)
        Правда написанию такого сценария предшествовали неоднократно набитые шишки со старой БД на dBase.