Как задокументировать стратегию обновления коммерческого программного обеспечения?
Мы не обновляли нашу СУБД или серверную ОС в течение почти десятилетия. Еще одному критически важному программному пакету уже более двух десятилетий, и в течение большей части времени его поставщик не поддерживал его. Некоторые из нашего руководства считают, что это хорошо - мы сэкономили кучу денег, не покупая обновления! Сейчас критически важная часть программного обеспечения нуждается в обновлении, но новая версия не будет поддерживать устаревшие десятилетия. Теперь некоторые из нас теряют голову, пытаясь понять, как обновить все сразу с минимальными затратами времени.
Чтобы избежать этого в будущем, некоторые из нас рассматривают возможность создания документа о стратегическом плане в области ИТ (который будет вписываться в план организации, включающий элементы более крупного документа, связанного с ИТ... возможно, что делает ИТ-документ тактическим планом?) в надежде, что мы сможем принять его как часть общего стратегического плана агентства. Я вызвался попробовать собрать раздел "Управление жизненным циклом программного обеспечения" (или что-то в этом роде), чтобы решить проблему, отмеченную выше (с вероятными ошибками в отдельном документе от стратегического плана). Почти все поставщики программного обеспечения публикуют жизненные циклы и планы устаревания для своих продуктов, и достаточно просто определить "точку отсчета" для каждого компонента программного обеспечения, учитывая эту информацию вместе с потребностями нашей организации. Сложная часть (во всяком случае, для меня) - объединить план каждой части во что-то более сплоченное.
Как я могу документировать, что настольные клиенты A,B,C... зависят от настольных OS X и RDBMS Y, что, в свою очередь, зависит от серверной OS Z, и тогда вот как мы держим их всех в "сладких местах"? Должны быть книги, но все мои поиски в Google привели меня к тактике обновления отдельного программного обеспечения, а не к стратегии определения того, когда применять эту тактику.
1 ответ
Похоже, вы пытаетесь решить много проблем одновременно (и это не выглядит хорошей идеей).
Из того, что я прочитал:
- устаревшие ОС и приложения
- нет долгосрочной стратегии
- проблемы с документированием вашей инфраструктуры
- срочно необходимо обновить критическую часть инфраструктуры
Обновление "критически важной части программного обеспечения"
Ваша инфраструктура устарела из-за чьего-то решения легко понять. Возможно, это казалось хорошей идеей в прошлом. Это сводится к тому, что Майкл Хэмптон написал в комментариях: Для менеджмента вы говорите о плюсах и минусах (рисках). Так что, если руководство готово пойти на риск, тогда хорошо (что бы вы ни думали об этом лично), и теперь это их обязанность. Но кто-то из айтишников должен сказать им, каковы риски.
Итак, первое, на что я бы обратил внимание: знали ли менеджеры о рисках устаревшего программного обеспечения? Им сказали?
Честно говоря, я чувствую, что вы, вероятно, не найдете в этом ничего полезного, поэтому я бы не стал тратить на это слишком много времени. Это просто то, что может помочь вам по принципу "мы говорили вам за последние пять лет".
Я бы просто сделал анализ того, что действительно означает выполнение этого обновления. Подготовьте простую электронную таблицу с указанием действий и продолжительности их выполнения (если вы не знаете, дайте точную оценку и подчеркните, что вы точно не знаете). Но помните, что эта "задача обновления" не очень хорошо определена, это невозможно сделать как fix-time/fix-price.
Создание таких списков также поможет вам разобраться в проблеме в целом. Далее нужно создать журнал рисков и список необходимых вам ресурсов.
В конце вы должны иметь список действий, список рисков, список материалов / людей, которые вам нужны. Одним словом, не воспринимайте обновление как повседневную проблему, делайте это как ПРОЕКТ. Это позволит вам иметь хоть какой-то контроль над острой потребностью вашей компании.
Если у вас есть проблемы с анализом того, какие действия необходимо выполнить, вы можете попробовать какую-то карту памяти (мой любимый вариант xMind), а затем преобразовать ее в более формальный документ.
Обратите внимание, что если у вас есть несколько вариантов того, как выполнить обновление, вы должны дать своим менеджерам описание возможных решений (если их больше), которые суммируются в нескольких предложениях, включая стоимость, результат и риск; в идеале упоминание варианта, который вы рекомендуете и почему. Потому что окончательный выбор остается за ними - в конце концов, они менеджеры.
Может быть, в данном конкретном случае: упомянуть, что обновление может быть невозможно вообще.
Нет долгосрочной стратегии
Создание стратегического плана не поможет вам сейчас. Это совсем не поможет, если это документ, созданный в вашем ИТ-отделе. Стратегический план - это то, что необходимо привязать к потребностям бизнеса.
Пример бизнес-потребности: через два года мы откроем новые офисы в Китае и Австралии.
Полученные ИТ-задачи: будьте готовы к тому, что новые сотрудники получат наставления, создайте инфраструктуру в зарубежных офисах, проведите обучение новых сотрудников (возможно, с использованием их родного языка), обеспечьте безопасное соединение этих офисов с центральным офисом, ...
Если дела пойдут хорошо, у вас может быть стратегия, может быть... через несколько месяцев? Так около полугода, пока все не согласовано?
Поддержание и документирование вашей инфраструктуры
Это наследие прошлого, и теперь вам нужно что-то менять. Расставлять приоритеты. Составьте список вещей, которые вы хотите / должны сделать сейчас, чтобы обновить большинство вещей. Выберите, что может подождать, составьте сырую дорожную карту. (Эта дорожная карта должна быть частью вашей ИТ-стратегии, если она у вас есть.)
Если вы обновляете что-то, что прошло хорошо, воспринимайте это как повседневный бизнес. Если вы обрабатываете что-то, что может пойти плохо ("большое" с точки зрения потраченного времени, выделенных людей и т. Д.), Рассматривайте это как проект.
Существуют инструменты, которые могут помочь вам с документацией и служебными зависимостями - CMDB (например, iTop). Но чтобы заставить его работать, может потребоваться некоторое время, и вам все еще нужен инструмент для документирования. Лучшая идея - создать вики для документации, где каждый может начать документировать / делать заметки. Вы можете настроить вики за полчаса, так что это очень эффективный способ начать работу.
Личное примечание: Обновление старой версии ОС будет огромной PITA, не говоря уже о (вероятно, плохой / отсутствующей) документации. Не проще ли заново установить серверы, перенести приложения и документировать все с самого начала?