Управление риском отказа от обновления

Недавно я разговаривал с другом, работающим в государственной администрации. Он был очень счастлив, потому что они наконец-то перейдут на Java 8. Да, вы все правильно поняли.

Рассказываю это просто так является

Просто чтобы получить общее представление, в этой таблице показана дорожная карта поддержки версий Java (из Oracle Java SE Support Roadmap ):

N/A	Декабрь 2006 года	6	?	Декабрь 2015 года	Декабрь 2018 года
N/A	Июль 2011 года	7	?	Июль 2019 года	Июль 2022 года
N/A	Март 2014	8	?	Март 2022 года	Март 2025 года
❌	Сентябрь 2017 года	9	?	Март 2018 года	❌
❌	Март 2018 года	10	?	Сентябрь 2018 года	❌
✅	Сентябрь 2018 года	11	?	Сентябрь 2023 года	Сентябрь 2026 года
❌	Март 2019 года	12	?	Сентябрь 2019 года	❌

Цены на различные уровни поддержки не являются общедоступными , так как это зависит от множества факторов, специфичных для конкретного клиента. Достаточно сказать, что цена растет с каждым уровнем поддержки: например “расширенная поддержка” стоит дороже, чем “основная поддержка”.

Я сказал своему другу, что ему, вероятно, следует перейти на Java 11, чтобы перейти на версию LTS. Его ответ заключался в том, что они не могли перемещать все свои приложения (> 500) каждые 6 месяцев. Хотя это факт, он также квалифицируется как неуправляемый риск . Что произойдет, если будет обнаружена ошибка в JDK? Что, если это блокировщик, влияющий, скажем, на половину приложений?

Обратите внимание, что публичные обновления для Java 8 заканчиваются в сентябре 2017 года, уже три года назад!

Неявное или явное решение

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

Как руководитель технологического отдела, вы обязаны принимать решения, будучи максимально информированным – или предоставлять лицам, принимающим решения, необходимые данные для принятия таких решений. Например, в нынешней ситуации это означает, что на обсуждение должны быть вынесены по крайней мере следующие темы:

Прямой путь: ** Сколько стоит поддержка? т.е. запросить ценовое предложение у Oracle sales ** Как будет меняться стоимость с течением времени?
Задержка миграции: Сколько будет стоить перенос приложений на Java 11 вместо Java 8?
Альтернативы: ** Каковы возможные альтернативы? ** Существуют ли альтернативные поставщики JVM например, Azul, AdoptOpenJDK и т.д.? * * Какова их соответствующая политика поддержки? * * Каковы связанные с этим затраты? * * Какова стоимость тестирования образца портфолио приложений для проверки совместимости?
Подготовка к худшему: ** Сколько приложений имеют процедуру обеспечения непрерывности бизнеса? ** Сколько стоит выполнение этих процедур?

Конечно, это лишь пример возможных вопросов и ответов, которые могли бы помочь прийти к решению.

По сути, все это сводится к треугольнику управления рисками :

Серьезность риска: Каково влияние риска?
Вероятность возникновения риска
Затраты на смягчение последствий: Существует ли один или несколько способов снижения риска? Каковы связанные с ними затраты?

Вывод

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

В конце концов, легко игнорировать проблему: просто затолкать ее под ковер, и дело сделано. Но когда фекалии попадут на вращающееся рабочее колесо – а это произойдет, – начнется игра в вину. На этом этапе организация увязнет в поиске “первопричины”: это будет пустой тратой времени при отсутствии документированных решений. И это будет повторяться снова и снова.

Некоторые организации уже документируют свои решения относительно архитектуры . Компоненты инфраструктуры должны подвергаться одному и тому же процессу. Это следующий шаг по шкале сроков погашения в управлении техническим долгом.

Идти дальше:

Первоначально опубликовано на Фанат Java 14 июня 2020 года.

Оригинал: “https://dev.to/nfrankel/managing-the-risk-of-not-upgrading-111b”