Сбер попробовал жить без поддержки Microsoft, Nvidia, VMware

Сбер попробовал жить без поддержки Microsoft, Nvidia, VMware

Сбер попробовал жить без поддержки Microsoft, Nvidia, VMware

По данным «Ъ», в Сбере на прошлой неделе провели учения, сымитировав отключение поддержки Microsoft, Nvidia, VMware, SAP в ИТ-инфраструктуре компании. Подобный сценарий вероятен: американские власти могут ввести ограничения на экспорт ИТ-технологий в Россию, которую они винят в эскалации напряженности на Украине.

По словам репортеров, об учениях в Сбере они узнали из источников в правительстве и на рынке вычислительной техники. Новостному изданию также стало известно, что банк планирует масштабную закупку серверов и систем хранения данных и рассматривает возможность замены оборудования Nvidia отечественными аналогами.

Тем не менее, на вопрос «Ъ» о подготовке к возможным санкциям США в Сбере и других крупных банках не ответили. Представители Microsoft, Nvidia, SAP ситуацию комментировать отказались, Oracle и Intel на запросы не ответили.

Информация о возможной блокировке доступа РФ к поставкам американской электроники просочилась в СМИ в середине прошлого месяца. Как оказалось, в ходе встречи с представителями п/п-отрасли чиновники из Совета национальной безопасности США порекомендовали готовиться к таким мерам, которые могут быть приняты «в случае нападения Москвы на Украину».

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

Опрошенные «Ъ» представители ИТ-отрасли считают необходимым форсировать импортозамещение в условиях обострения внешнеполитической ситуации. В InfoWatch отметили, что во многих случаях зарубежный софт уже имеет отечественные аналоги, однако для тех, кто еще не приступил к замене систем, резкий переход будет болезненным.

Проводник Windows падал не из-за Microsoft, виноват оказался деинсталлятор

Инженер Microsoft Рэймонд Чен рассказал любопытную историю отладки загадочных падений Проводника. Сначала всё выглядело так, будто в Windows внезапно появился неприятный баг. Но виновником оказалась вовсе не Microsoft, а сторонний деинсталлятор.

Проблема проявилась как резкий всплеск сбоев Проводника. Инженеры начали изучать дампы и заметили странную деталь: падала 32-битная версия программы, запущенная на 64-битных системах Windows.

Такая версия Проводника всё ещё есть в Windows ради совместимости со старыми приложениями. Обычно современные системы почти не используют этот путь. Но в данном случае сторонний деинсталлятор каким-то образом заставлял систему обращаться именно к этому устаревшему компоненту.

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

Поскольку процесс повторялся в цикле, повреждение памяти постепенно накапливалось. В какой-то момент указатель стека уезжал в область активного кода, и Проводник падал.

Со стороны всё выглядело как типичная системная ошибка: софт снова и снова аварийно завершал работу, создавая ощущение, что проблема в самой Windows. На деле операционная система лишь показывала последствия ошибки в стороннем ПО.

Чен напомнил важную вещь: в экосистеме Windows с миллиардами устройств и огромным количеством приложений далеко не каждый сбой компонента Microsoft означает баг в Windows. Сторонние программы тоже могут ломать системные процессы, особенно если неправильно используют низкоуровневые API.

RSS: Новости на портале Anti-Malware.ru