Синдром «белой кости» в финтехе: почему Т-Банк спорит со мной, отвернувшись спиной?

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

Спустя ровно две недели, вечером 5 июня, Java-команда Т-Банка экстренно выкатывает на Хабре свой огромный «Java Digest #36». И там внезапно, как черт из табакерки, появляется целый детальный разбор узкой темы: «Анализируем heap-дампы с прода, не привлекая внимания безопасников».

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

Я, Игорь Чернов, на vc.ru прохожу как КиберДед и Дед-Пчеловод из Давлеканово. Мой аккаунт на Хабре — smel1-2 (который на старых мониторах из-за шрифтов Хабра читается как «шмел»). И я объясню ИТ-сообществу, почему они выбрали тактику трусливого корпоративного игнора и почему их свежий дайджест — это замаскированная техническая капитуляция предо мной.

В Т-Банке сидят сотни высокооплачиваемых мидлов и синьоров, которые привыкли слепо верить учебникам по Java и мыслить абстрактными шаблонами тяжелых фреймворков.

Когда Дед-Пчеловод из региона на древнем двухъядерном процессоре Athlon раскладывает физику процесса и наглядно показывает, что их хваленая многомиллионная корпоративная архитектура дает фатальный сбой, признать это публично для них — карьерная смерть.

Их эго не позволяет им написать: «КиберДед прав, у нас тут костыли». Им гораздо проще втихую собрать дайджест, надергать оттуда ответов на мои тезисы и выдать это за «плановые новости индустрии». Это классическая тактика защиты крупных брендов от независимых авторов.

В своей первой публикации я задал им жесткий вопрос: как вы защищаете персональные данные клиентов, когда сервер падает и сырой 64-гигабайтный снимок памяти (heap-dump) выгружается на жесткий диск?

Их «снисходительный» ответ в статье от 5 июня: они хвастаются утилитой hprof-redact, которая якобы эффективно в потоковом режиме затирает массивы char[] и byte[] в готовом файле дампа. Они преподносят это как технологический прорыв и очень ждут тикет JDK-8337517, где Oracle пытается встроить этот механизм в саму платформу Java.

Но они умалчивают о физике процесса, которую я вынес во вторую часть своего проекта, и совершают три критические архитектурные ошибки.

Ошибка №1: Паралич рантайма через Stop-The-World шторм. Когда их JVM ловит OutOfMemoryError, стандартный механизм останавливает все рабочие потоки банка. Наступает глухая пауза Stop-The-World. По их схеме, все 64 ГБ кучи перегоняются на диск под этой паузой. Пока терабайты пишутся на SSD, банк лежит в таймаутах, а клиенты ловят ошибки платежей. Мой нативный агент обнуляет строки прямо в оперативной памяти (RAM) в момент аварийного триггера, сжимая граф в 15 раз ДО записи на диск. Пауза для сервиса становится незаметной.

Ошибка №2: Бесполезный прогон фрагментированного мусора. При OOM куча Java дико фрагментирована, она забита миллионами «мертвых» объектов, которые сборщик мусора не успел очистить. Утилита hprof-redact тратит дефицитные ресурсы CPU на чтение и упаковку этого цифрового шума, создавая дикий затык на дисковой шине (I/O Bottleneck). Мой агент выполняет нативный триминг кучи еще в RAM — выгружает только живой ссылочный граф (GC Roots), полностью отбрасывая фрагментированный мусор. Чистый «скелет» весит 2–4 ГБ вместо 64 ГБ и улетает на SSD за секунду.

Ошибка №3: Временное окно уязвимости ИБ (Race Condition). Между моментом, когда JVM записала сырой файл на диск, и моментом, когда автоматизация натравит на него hprof-redact, всегда есть зазор в несколько секунд или минут. В это время на диске сервера в открытом виде лежат пароли и токены сессий клиентов. Любой сбой операционной системы в это окно — и сырой файл остается на носителе. Это комплаенс-катастрофа с миллиардными оборотными штрафами от регуляторов. Мой конвейер Piped Output связывает вывод RAM-агента напрямую с фильтром через системный буфер в оперативной памяти — физический файл на диске с первой же секунды пишется в защищенном виде. Промежуточного сырого файла на диске не существует физически.

Чтобы окончательно успокоить свое руководство и оправдать, почему банк сидит на тяжелой Java, они вставили в этот же дайджест сомнительную аналитику о том, что Node.js (платформа, на которой написана первая версия моего «Черного Треугольника») якобы «обошлась какому-то автору на 24 000 долларов дороже из-за утечек памяти, которые долго фиксили».

Это классический пиар-прием: разбавить жесткую критику своей Java-архитектуры встречным набросом на платформу оппонента, чтобы отвлечь внимание сообщества от собственных косяков с памятью.

Уважаемые техлиды Т-Банка. Вы можете сколько угодно делать вид, что брезгуете открытой дискуссией с независимым региональным разработчиком. Вы можете мариновать мой технический комментарий на премодерации Хабра (он висит в вашей админке под моим ником smel1-2 уже почти сутки, и вы трусливо боитесь его одобрить, потому что придется технически отдуваться перед всей аудиторией).

Но законы физики рантайма сильнее ваших корпоративных методичек. Исходный код моего ядра открыт на GitHub (ssmel63/obsidiant-black-triangle). Я официально отправил полный аудит вашей схемы на ваш закрытый шлюз безопасности bug-hunters@tbank.ru.

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