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