Почему доступ к базе знаний — это важно и как продолжать работу после прекращение поддержки зарубежных производителей.
После ухода из России зарубежных поставщиков программного обеспечения часть отечественных компаний продолжили использовать их сервисы. Причина в том, что производители не остановили работу ПО программного обеспечения, а «всего лишь» отказались от обслуживания и выпуска обновлений в отношении продуктов, проданных российским потребителям. Поэтому некоторые компании продолжают пользоваться уже купленными лицензиями. Важно осознавать минусы и риски такого решения. Один из них — отсутствие доступа к базе знаний производителя.
Что такое база знаний производителя
База знаний — это библиотека статей, описание причин проблем и вариантов их решений, накопленные производителем. Как правило, в нее входят документы, справки, гайды и руководства, инструкции, спецификации, обучающие материалы, шаблоны и другие материалы. Все материалы собираются в едином месте с удаленным доступом для сотрудников, партнеров или клиентов. При этом администратор базы знаний может настраивать уровни доступа, предоставляя отдельным категориям лиц или даже конкретным людям доступ к нужным им документам.
Наполнением и актуализацией базы знаний занимаются специалисты, которые отвечают за свои направления. Например, HR-служба добавляет бланки заявлений и материалы для новых работников, менеджеры по продуктам — гайды, инженеры — инструкции.
Важная часть базы знаний поставщиков IT-решений — база данных известных ошибок (Known Error Database) и важных исправлений (Errata) . Именно к ним в первую очередь обращаются потребители решения при возникновении проблем с продуктом производителя. Задача Known Error Database — предоставить инструкции для максимально быстрой идентификации и решения проблемы. Ее использование помогает свести к минимуму время простоя из-за возникающих проблем. А также гарантирует вариант решения проблемы, который не будет служить причиной возникновения новых проблем, что характерно при решении методом «научного тыка».
База известных ошибок включает:
● описание проблемы. Сюда входит описание ситуации, при которой эта проблема возникает, причины и условия ее появления, а также признаки, однозначно идентифицирующие проблему;
● скриншоты. Изображения помогают производителю лучше описать проблему для пользователя;
● описание решения проблемы. Как правило, пошаговая инструкция, состоящая из текста, видео, скриншотов и изображений. Нередко производитель визуализирует такое описание с помощью блок-схемы.
Производитель регулярно обновляет базу известных ошибок, добавляя в нее новые описания и заменяя устаревшие знания актуальными.
Прекращение поддержки зарубежных производителей
К концу 2022 года свыше 1000 иностранных компаний объявили об уходе или приостановке работы в России. Часть поставщиков ушли из-за требований регуляторов в своих странах, часть — из-за сложностей с оплатой. При этом у российских компаний остались оплаченные услуги, и не все готовы смиренно сидеть и никак не реагировать на проблему. Поэтому многие зарубежные компании не ушли из нашей страны полностью, а прекратили выпуск обновлений, остановили обслуживание, закрыли доступ к базам знаний.
На сегодняшний день из России ушли или приостановили деятельность:
- американский поставщик корпоративного сетевого оборудования Cisco;
- американский производитель компьютеров и крупнейший поставщик серверов Dell;
- американский производитель программного и аппаратного обеспечения Oracle;
- немецкий производитель программного обеспечения SAP;
- американский разработчик ПО для виртуализации VMware;
- американский разработчик компьютерных игр Blizzard;
- французский разработчик компьютерных игр Ubisoft;
- американский производитель процессоров и чипсетов AMD;
- компания по разработке беспроводных средств связи Qualcomm;
- международный создатель инструментов для разработки JetBrains и другие.
В настоящий момент большая часть этих компаний прекратила продление лицензий для российских компаний, а также остановила поддержку своих продуктов и закрыла доступ к собственной базе знаний.
К чему может привести отсутствие доступа к базе знаний
Может показаться, что отсутствие доступа к базе знаний — несущественная проблема на фоне ухода мировых гигантов с российского рынка. В конце-концов у отечественных компаний есть штат специалистов, на который возлагается надежда. Сотрудники, которые раньше уже работали с зарубежными сервисами, смогут организовать обслуживание и устранить неисправности своими силами. Однако не все так просто и однозначно. Вот несколько потенциальных проблем, с которыми рискуют столкнуться пользователи зарубежных решений.
Сложности с поиском эффективного решения. Без доступа к обновлениям и базе знаний от производителя не всегда удастся оперативно устранять уязвимости. Способ решения проблемы, указанный в базе знаний, практически всегда будет гарантировано проще, удобнее и эффективнее, чем тот, который специалист отыщет самостоятельно или «в интернете». Поэтому отсутствие доступа приведет к неэффективным решениям, на поиск которых будет тратиться рабочее время специалиста.
Иллюзия корректности самостоятельно найденного решения является куда более серьезной угрозой для информационной системы, так как в сложных информационных системах решение и его видимость зачастую не тождественны. Устранение симптомов не тождественно устранению причины проблемы, а зачастую может еще и усугублять эту причину, внедряя в информационную систему бомбу замедленного действия. Производители решений корпоративного уровня не особо спешат признаваться в том, что истинной причиной проблемы была «детская ошибка». Поэтому нередко такую причину «маскируют» за витиеватыми формулировками, связь которых с устранением источника проблемы неочевидна.
Решение проблем будет занимать больше времени. Одна из задач базы знаний — экономить время клиентов при решении проблем. Поиск причины проблемы и собственного решения может занять время, из-за чего время простоя увеличится. Все это чревато финансовыми потерями для компании. Нередко SLA строится на базе заявленных производителем значений RTO/RPO (допустимая потеря данных и допустимое время восстановления данных) . При отсутствии доступа к базе знаний достичь этих целевых показателей уже не получится.
Некоторые проблемы могут оказаться нерешаемыми. Отдельные баги бывают настолько специфическими, что возникают только при очень сложной совокупности условий. Это значит, что даже у опытного специалиста не будет необходимых инструментов для решения проблемы.
Пример: продукт Oracle database и ошибки ORA-600/ORA-7445. Данные коды ошибок со времен версий 7.X (90-ые годы) обозначены как «Внутренняя ошибка». Их настоящие причины можно узнать только исходя из совокупности дополнительных параметров, указанных вместе с этой ошибкой в лог-файле, и с использованием инструмента, доступного на сайте производителя. При отсутствии доступа к этому инструменту поиск причины проблемы и гарантированного решения практически невозможен. Поиск уникального случая в интернете также может окончиться ничем, так как совокупность факторов в данном случае — это не более чем совокупность числовых значений. При использовании ORA-600/ORA-7445/ORA-700 Error Look-up Tool однозначная идентификация проблемы и пути ее корректного решения занимают пару минут.
Даже самые опытные специалисты не заменят регулярно обновляющуюся базу знаний производителя и инструменты диагностики внутренних проблем, истинные причины возникновения которых производитель не горит желанием выставлять на публичное обозрение. В результате складывается ситуация, при которой компания не может полноценно управлять собственной инфраструктурой.
Пример такой ситуации — обнаружение критической уязвимости в Oracle JDeveloper, которая затрагивала все системы на ADF Faces. Уязвимость получила название CVE-2022-21445 и почти максимальную оценку 9,8 по шкале CVSS. Благодаря ей злоумышленники могли запустить выполнение кода во взломанной системе. Компания потратила шесть месяцев на устранение CVE-2022-21445. За это время была обнаружена SSRF-уязвимость CVE-2022-21497 (8,1 по шкале CVSS) , которая могла использоваться совместно с CVE-2022-21445. В июле 2022 года компания выпустила обновления для исправления 349 уязвимостей с рекомендациями как можно быстрее применить их для защиты системы от хакеров.
Также в конце 2021 года специалисты в области информационной безопасности нашли критическую уязвимость CVE-2021-44228, связанную с библиотекой Log4j, с уровнем угрозы 10 из 10. Она могла затронуть разработчиков, которые пишут на Java, и их клиентов. Критическая уязвимость была устранена в обновлениях библиотеки Log4j, однако остались решения с уязвимыми модулями.
Таким образом, компании, которые не могут своевременно вносить обновления и пользоваться базой данных для получения подробных инструкций, остаются в зоне риска даже после того, как производитель устранил уязвимости и, как это принято в области инфобезопасности, опубликовал детали уязвимости и возможности эксплуатации.
Решение проблемы
Уязвимости и периодически возникающие проблемы бывают даже у лучших решений крупнейших производителей. Это неизбежно и раньше все решалось быстро и просто — через базу знаний производителя. Сейчас компании обращаются за помощью к интегратору и содержат собственный штат специалистов. Однако без доступа к базе знаний производителя такое решение больше похоже на самообман, нежели на действенный вариант решения возникающих проблем.
Более дальновидным решением для российских компаний может стать переход на решения отечественных разработчиков. Некоторые из них можно внедрять параллельно с использованием зарубежных аналогов, чтобы избежать эффектов резкой смены IT-ландшафта. И такие примеры в России уже есть. Например, компания Serverspace параллельно с эксплуатацией платформы для виртуализации американской компании VMware своевременно внедрила российскую гиперконвергентную платформу vStack. Подобный шаг не только помог снизить риски из-за отсутствия доступа к базе знаний VMware, но и помог Serverspace подняться на уровень топ-1 по производительности виртуальных машин.
Несмотря на то, что программное обеспечение зарубежных компаний продолжает работать в России, пользователи могут столкнуться с серьезными проблемами. Сбои происходят у всех, и иногда единственный способ быстро устранить проблему — воспользоваться пошаговыми инструкциями в базе знаний производителя. Без доступа к этой базе российские компании могут столкнуться с неустранимыми проблемами: увеличением времени простоя и срывом SLA. Возможным решением может стать постепенный переход на отечественное ПО, который уже начался в крупных российских компаниях.