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