Как задокументировать стратегию обновления коммерческого программного обеспечения?


11

Мы не обновляли нашу СУБД или серверную ОС в течение почти десятилетия. Еще одному критически важному программному пакету уже более двух десятилетий, и его поставщик не поддерживал большую часть этого времени. Некоторые из нашего руководства считают, что это хорошо - мы сэкономили кучу денег, не покупая обновления! Сейчас критически важная часть программного обеспечения нуждается в обновлении, но новая версия не будет поддерживать устаревшие десятилетия. Теперь некоторые из нас теряют голову, пытаясь понять, как обновить все сразу с минимальным временем простоя.

Чтобы избежать этого в будущем, некоторые из нас рассматривают возможность создания документа о стратегическом плане в области ИТ (который будет вписываться в план организации, предусматривающий выделение элементов в более крупном документе, связанном с ИТ ... возможно, что делает ИТ-документ тактическимпланировать?) в надежде, что мы сможем принять его как часть общего стратегического плана агентства. Я вызвался попробовать собрать раздел «Управление жизненным циклом программного обеспечения» (или что-то в этом роде), чтобы решить проблему, отмеченную выше (с вероятными ошибками в отдельном документе от стратегического плана). Почти все поставщики программного обеспечения публикуют жизненные циклы и планы устаревания для своих продуктов, и достаточно просто определить «точку отсчета» для каждого компонента программного обеспечения, учитывая эту информацию вместе с потребностями нашей организации. Сложная часть (во всяком случае, для меня) - объединить план каждой части во что-то более сплоченное.

Как я могу документировать, что настольные клиенты A, B, C ... зависят от настольных OS X и RDBMS Y, что, в свою очередь, зависит от серверной OS Z, и тогда вот как мы держим их всех в «сладких местах»? Должны быть книги, но все мои поиски в Google привели меня к тактике обновления одного программного обеспечения, а не к стратегии определения того, когда применять эту тактику.


7
Я уверен, что кто-то скоро придет, чтобы попробовать это, но я думаю, что нельзя упускать один момент: если компания не тратит деньги на модернизацию, это ставит бизнес под угрозу . Одна из вещей, которую мы должны сделать, - информировать руководство о рисках, связанных с отсутствием обновления.
Майкл Хэмптон

3
Жаргонный термин для отсрочки обновления заключается в том, что вы наращиваете «технологический долг»; откладывая регулярное обслуживание и обновления, вы, по-видимому, сэкономите немного денег в краткосрочной перспективе, но когда в конечном итоге вам понадобится выполнить техническое обслуживание после многих лет пренебрежения, вам все равно придется платить за пайпер: часто сроки будут неудачными, поставщики не будут у вас есть поддерживаемый путь немедленного обновления с $CURRENT-version minus 20 yearsдо $CURRENT-versionи т. д., и вы, вероятно, придете к выводу: это были не фактические сбережения, а РАСХОДЫ , которые придется заплатить в будущем .
HBruijn

1
Управление жизненным циклом является неблагодарной необходимостью в любой зрелой среде и PITA для организации. Удачи!
HBruijn

Ответы:


7

Похоже, вы пытаетесь решить много проблем одновременно (и это не выглядит хорошей идеей).

Из того, что я прочитал:

  • устаревшие ОС и приложения
  • нет долгосрочной стратегии
  • проблемы с документированием вашей инфраструктуры
  • срочно необходимо обновить критическую часть инфраструктуры

Обновление "критической части программного обеспечения"

Ваша инфраструктура устарела из-за чьего-то решения легко понять. Возможно, это казалось хорошей идеей в прошлом. Это сводится к тому, что Майкл Хэмптон написал в комментариях: Для менеджмента вы говорите о плюсах и минусах (рисках). Так что, если руководство готово пойти на риск, тогда хорошо (что бы вы ни думали об этом лично), и теперь это их обязанность. Но кто-то из айтишников должен сказать им, каковы риски.

Итак, первое, на что я бы обратил внимание: знали ли менеджеры о рисках устаревшего программного обеспечения? Им сказали?

Честно говоря, я чувствую, что вы, вероятно, не найдете в этом ничего полезного, поэтому я бы не стал тратить на это слишком много времени. Это просто то, что может помочь вам по принципу «мы говорили вам за последние пять лет».

Я бы просто сделал анализ того, что действительно означает выполнение этого обновления. Подготовьте простую электронную таблицу с указанием действий и продолжительности их выполнения (если вы не знаете, дайте точную оценку и подчеркните, что вы точно не знаете). Но помните, что эта «задача обновления» не очень хорошо определена, это невозможно сделать как fix-time / fix-price.

Создание таких списков также поможет вам разобраться в проблеме в целом. Далее нужно создать журнал рисков и список необходимых вам ресурсов.

В конце вы должны иметь список действий, список рисков, список материалов / людей, которые вам нужны. Одним словом, не относитесь к обновлению как к повседневной проблеме, делайте это как ПРОЕКТ. Это позволит вам иметь хоть какой-то контроль над острой потребностью вашей компании.

Если у вас есть проблемы с анализом того, какие действия необходимо выполнить, вы можете попробовать какую-то карту ума (мой любимый вариант xMind), а затем преобразовать ее в более формальный документ.

Обратите внимание, что если у вас есть несколько вариантов того, как выполнить обновление, вы должны дать своим менеджерам описание возможных решений (если их больше), которые суммируются в нескольких предложениях, включая стоимость, результат и риск; в идеале упоминание того варианта, который вы рекомендуете и почему. Потому что окончательный выбор остается за ними - в конце концов, они менеджеры.

Может быть, в данном конкретном случае: упомянуть, что обновление может быть невозможно вообще.

Нет долгосрочной стратегии

Создание стратегического плана не поможет вам сейчас. Это совсем не поможет, если это документ, созданный в вашем ИТ-отделе. Стратегический план - это то, что должно быть привязано к потребностям бизнеса.

Пример бизнес-потребности: через два года мы откроем новые офисы в Китае и Австралии.

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

Если дела пойдут хорошо, у вас может быть стратегия, может быть ... через несколько месяцев? Так около полугода, пока все не согласовано?

Поддержание и документирование вашей инфраструктуры

Это наследие прошлого, и теперь вам нужно что-то менять. Расставлять приоритеты. Составьте список вещей, которые вы хотите / должны сделать сейчас, чтобы обновить большинство вещей. Выберите, что может подождать, составьте сырую дорожную карту. (Эта дорожная карта должна быть частью вашей ИТ-стратегии, если она у вас есть.)

Если вы обновляете что-то, что прошло хорошо, относитесь к этому как к повседневному делу. Если вы обрабатываете что-то, что может пойти плохо («большое» с точки зрения затраченного времени, выделенных людей и т. Д.), Рассматривайте это как проект.

Существуют инструменты, которые могут помочь вам с документацией и служебными зависимостями - CMDB (например, iTop). Но чтобы заставить его работать, может потребоваться некоторое время, и вам все еще нужен инструмент для документирования Лучшая идея - создать вики для документации, где каждый может начать документировать / делать заметки. Вы можете настроить вики за полчаса, так что это очень эффективный способ начать работу.

Личное примечание: Обновление старой версии ОС будет огромной PITA, не говоря уже о (вероятно, плохой / отсутствующей) документации. Не проще ли заново установить серверы, перенести приложения и документировать все с самого начала?


Я все еще должен прочитать ваш ответ более внимательно, но сначала. , , Re «Создание стратегического плана вам сейчас не поможет»: история с нынешним poopstorm была предназначена только для иллюстрации проблемы. Мы рассматриваем это как воду под мостом и пытаемся составить план действий, чтобы предотвратить будущие фекальные осадки. Мне нужно отредактировать свой вопрос, чтобы сделать это более понятным.
Финг Ликсон

1
Да, я знаю, что ты имеешь в виду. Но я думаю, что если вы вырежете это конкретное предложение, остальная часть ответа останется в силе. :)
Fiisch
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.