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

У меня немного подгорела жопа, простите. Это случилось давно, поэтому постараюсь быть объективным.

Мы тут ворвались с ноги в банк и написали АБС. Это, если что, ядро банка. Я рассказывал, что мы были отвлечены от облака корпоративными проектами, так вот это один из них. Про то, что там под капотом, расскажу позже отдельно — сейчас система на стейджинге и будет там ещё где-то полгода минимум, но базовый функционал уже работает.

Но сегодня не про это.

Если вы делаете проект такого масштаба в корпорации — тем более в банке, — то внезапно может выясниться, что вам там не очень-то и рады.

Потому что если проект заверится, то свои тёплые места потеряют самые разные ИТ-шаманы. Ну, это которые разговаривают с вождём так: «Хочешь прогневать духов? Нашлю дождь, и останешься без урожая». ИТ-шаман разговаривает с бизнесом так же, только вместо духов у него легаси, которое он не документировал.

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

Я знал, что так будет, но не ждал, что там всё настолько нагло.

И да, я был очень зол несколько месяцев. А в этой истории мы — заинтересованная сторона. Мы предлагали банку собственную инфраструктуру и новую банковскую систему, а люди, о которых пойдёт речь, этому сопротивлялись. Поэтому я постараюсь отделять то, что мы видели, от того, что я думаю о причинах.

Как мы туда попали

Над банками недавно навис цифровой рубль. Его поддержка обязательна по закону: системно значимые банки должны работать с ним с 1 сентября 2026 года, банки с универсальной лицензией — с 2027-го, остальные — с 2028-го. Для банка это означает доработку АБС, доработку дистанционного обслуживания, криптографию и сертификацию.

Публичные оценки такого проекта — от 100 до 300 миллионов рублей на банк. Предложения вендоров, которые видели мы, лежали в диапазоне от 180 до 220 миллионов.

Правление посмотрело на эти бюджеты и спросило: «А можно что-нибудь придумать?»

Нас позвали поговорить, потому что знали, что мы за разработчики ещё с прошлой биографии.

Первый контакт

Бизнес хотел разговаривать. ИТ-департамент и департамент ИБ встретили нас сопротивлением, которое продолжалось от первой встречи до демонстрации первой версии работающей системы.

Директор по ИБ сразу обозначил, что любая покупка проходит только через его одобрение. Дальше шла серия вопросов: «А есть ли у вас это? А вот это? А будет ли оно дешевле и лучше, чем у них?» На каждый мы отвечали «есть». Вопросы не особо заканчивались.

ИТ-департамент выбрал другую тактику: «Ну, S3 для бэкапов мы бы у вас, наверное, взяли. Всё остальное не нужно».

Когда мы заговорили про АБС, аргументы стали ещё громче: это занимает десять лет, у этих ребят ничего нет, они не справятся. Мы попробовали разобрать возражения по существу.

И знаете, что?

Оказывается, каждое из них, если применить его к действующим подрядчикам банка, работает больше против них, чем против нас!

Настоящих технических причин сопротивляться мы так и не услышали. Поэтому я думаю, что причины были личные. Точнее — эмоциональные.

Инфра

• Серверы — платформа пятнадцатилетней давности, давно снятая производителем с поддержки. Это нормально, у нас санкции и легаси, так много где. Их поддерживают специально обученные ещё в 90-х люди.

• Гипервизор отстал от актуальной версии на несколько поколений, и современные версии на это железо не встанут. Это тоже нормально для банка. Где-то там живут скрипты, которые никто не трогает с 2013 года.

• В базе данных действующей АБС 58 тысяч таблиц. Тысяч, Карл!

Мы поначалу считали себя немного самозванцами и не могли понять, зачем столько таблиц. Потому что, как ни крути, у нас в инсталляции их на приближенных к реальным тестам их сейчас меньше 60. Не тысяч, а просто 60 единиц. Ладно, там ещё зависимости — справочники, история и отчётность, допустим, в их архитектуре это дает ещё несколько сотен. Откуда взялись остальные 57 с лишним тысяч, мы узнали чуть-чуть позже и не до конца. Если очень коротко — когда речь заходит о деньгах, — выгоднее каждый раз делать новый модуль с доработкой. Похоже, за 15 лет днище АБС обросло ракушками.

За действующую АБС банк заплатил очень много. Очень.

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

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

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

Мы сначала думали, что это ад, но потом начали погружаться глубже.

Мясной прокси

С 1 сентября 2026 года действует новый порядок, по которому Социальный фонд может запрашивать у банков справки о счетах и остатках и выписки по счетам организаций и предпринимателей в электронном виде, а банк отвечает через систему межведомственного электронного взаимодействия.

Мы у себя сделали для этого сервис: интерфейс, ролевая модель, история запросов. Ему нужны данные из действующей АБС, причём в стабильном виде, чтобы разные сотрудники не доставали их разными способами. Правильное решение — добавить в АБС два отчёта. Отчёт — это шаблон на внутреннем языке вендора поверх SQL. Он собирает записи из тысяч таблиц и выгружает их в табличные и текстовые форматы.

В банке работает специалист, который пришёл от вендора АБС и отвечает за её эксплуатацию. Его обычная схема, когда нужен новый отчёт, выглядит так: написать запрос вендору, вендор сделает отчёт, банк вендору заплатит, специалист подключит результат и попросит премию.

В этот раз отчёт написали мы. У себя мы делали CI/CD-конвейер за 10 минут. Дальше специальный человек работал прокси между нами и системой — с пингом 3 дня он копипастил это на сторону банка. Ладно, я могу понять, если там меры ИБ и всё такое, — но до них ещё дело не дошло даже!

Второй удивительный персонаж — человек, который замкнул на себе знание обо всей инфраструктуре: какие серверы, какие виртуальные машины, как устроена коммутация, как настроены сети, что куда проксируется. Естественно, никакой документации нет, всё это знает он один. Хотя документировать это входит в его должностные обязанности.

Его внутренний рабочий номер переадресован домой. Набираешь внутренний номер — звонишь ему на физический телефон дома (да, они остались), если он не отвечает — на сотовый.

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

Короче, каждую платёжку операционист в зале открывает как документ и читает глазами. Его задача — сделать проверки: соответствует ли номер счёта типу клиента, есть ли в реквизитах «ИП» там, где оно должно быть, корректное ли назначение платежа или там «Вася, спасибо за отличный вечер и шлюх!». Не знаю, почему так нельзя, но в любом случае человек проверяет это вручную, по каждому документу, каждый день.

Почему? Потому что у них нет интеграции! Они где-то пару лет назад забили такой костыль, думая, что через пару недель доделают. Немного задержались.

Ну и ещё один отдел считает кучу данных на своей стороне, потому что незаконченная интеграция не даёт взять их из системы.

Ааааааа!

Как выглядела идиллия, пока не ворвались мы

Рынок АБС поделён между несколькими вендорами. Системы у них закрыты. На каждое новое требование регулятора вендор выпускает отдельный модуль со своей ценой покупки, ценой внедрения и ценой поддержки. А требования, если что, приходят регулярно. В нашем случае только за право пользоваться такой системой банк платил, по нашей оценке, от 20 миллионов в год, не считая покупки и внедрения.

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

До нашего появления счета приносили, и их оплачивали без разговоров. С нашим появлением у каждого счёта возник вопрос: «А зачем?» Почти все счета после этого вопроса развернулись.

Что стало дальше

Мы показали банку работающую версию новой АБС вместе с системой дистанционного обслуживания. Впереди внедрение и миграция — это проект на месяцы. ИТ-департамент уже перестраивается. Вопрос теперь в том, кто из его сотрудников перестроится вместе с ним, а кто пойдёт устраиваться обратно к вендору.

Недавно я наблюдал похожую развязку в другом банке. Туда пришла похожая команда, провела аудит и начала задавать вопросы: «Этот чем занимается? А этого зачем держите?»

Главного шамана уволили одним днём.

Он до последнего был уверен, что на нём держится весь банк. А банк при этом годами платил за лицензии, которыми никто не пользовался, и за железо, которое по факту никому не было нужно.

И да, если вы сейчас подумали, что модные-динамичные-современные выжили опытного дедушку и через год всё развалится, — нет. Это было больше года назад, и там наконец-то доделали все нужные интеграции, и ничего, клиринг ни разу не подвис. До этого в банковской сфере был похожий переход по железу с P-машин IBM на x86-машины, и тоже более-менее нормально прошёл. Со скрипом, уволенными, трагедиями и граблями новых технологий (ведь x86-архитектура ещё молодая, правильно?), но прошёл.

Теперь давайте поговорим про сам ИТ-шаманизм.

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

• Настаивайте, чтобы всё делалось по определённым каналам. Никогда не допускайте коротких путей ради ускорения решений.

• Передавайте все вопросы в комитеты для дальнейшего изучения. Делайте комитеты как можно больше — никогда не меньше 5 человек.

• Призывайте к осторожности. Будьте благоразумны и призывайте коллег избегать спешки.

• Тревожьтесь о правомерности любого решения: входит ли оно в полномочия группы.

• Добейтесь, чтобы всё утверждали трое там, где хватило бы одного.

• Применяйте все правила до последней буквы.

• Никогда не передавайте свои навыки и опыт новому работнику.

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

Если что, я не утверждаю, что кто-то в банке вредил намеренно. Скорее, это одно из побочных свойств системы в целом.

В книге 1963 года французский социолог Мишель Крозье описал предприятие, которое назвал «Промышленной монополией» (на самом деле это государственная табачно-спичечная монополия SEITA). Узкое место было в ремонте станков. Формальной власти у ремонтников не было. Фактически цехом управляли они. Общий принцип Крозье: кто контролирует единственный источник неопределённости в организации, где всё остальное предсказуемо, тот имеет власть над всеми, кого эта неопределённость касается. Он писал: «Никто не может понять, что они делают, и проверить их».

Как только знание эксперта удаётся оцифровать или хотя бы задокументировать до процесса, его власть исчезает. Поэтому эксперту выгодно, чтобы документации не случилось. Отсюда неописанное легаси, инструкции в голове и «только я знаю, как это работает».

Экономисты Шлейфер и Вишни в 1989 году описали ту же стратегию у менеджеров и назвали её окапыванием. Это когда секретарь ведёт файлы так, чтобы никто не смог в них разобраться. То есть он использует ресурсы работодателя, чтобы стать незаменимым.

Теперь с кем мы столкнулись на проекте.

Типажи

Вахтёр. Это человек, который наращивает административный вес в компании. Он отвечает за одно из, скажем, сотни согласований. Если он будет согласовывать быстро и чётко, он быстро будет терять власть. Его задача — затруднить согласования так, чтобы другие отделы шли ему на уступки и повышали привилегии. Если он станет незаменимым — его ценность устремится к бесконечности.

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

Шаман. Это единственный человек, который знает, как всё устроено. Наш хранитель, к счастью, никому не угрожал. Краевой случай — Терри Чайлдс, администратор городской сети Сан-Франциско. В 2008-м его отстранили, потом он 12 дней не отдавал пароли. Сеть работала, но город не мог ею управлять. Апелляционный суд в решении пересказывает позицию обвинения: Чайлдс «сделал себя единой точкой отказа». Взыскание почти полутора миллионов долларов суд оставил в силе. Сисадмин нормально так хлопнул дверью: получил четыре года, из которых больше двух к моменту приговора уже отсидел.

Если что, положение Банка России 850-П обязывает банки принимать меры против зависимости операционной надёжности от работников с «уникальными знаниями, опытом и компетенцией», которых нет у других сотрудников.

Человек вендора в штате. Это сотрудник банка (заказчика), который пришёл от поставщика и остаётся единственным каналом связи с ним. Чем больше заказчик покупает у вендора, тем больше получает и его сотрудник. Агент хуже действует в интересах нанимателя, когда его работу трудно оценить, а его самого дорого заменить. В нашем случае в банке ничего противозаконного мы не видели, просто это было, по моей оценке, сильно дороже, чем должно стоить. Но это субъективизм.

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

У крупных банков на поддержание работающего и обязательные доработки часто уходит до 70% технологического бюджета — это оценка Маккинси 2024 года.

Костыльщик. Это герой, который вручную закрывает разрыв, которого в архитектуре изначально не было. Вообще-то это положительный персонаж, он спасает систему от проблем. Ему реально тяжело. Он часто работает как лошадь. Но он держит всё на себе. «Каждый раз, когда мы позволяем Бренту починить то, что никто из нас не может повторить, Брент становится чуть умнее, а вся система — глупее», — говорит герой романа «Проект „Феникс“».

Пилильщик. Это уже конкретно злонамеренный тип, который делает проект за 10% бюджета, а остальное куда-то девается. Он же годами платит от лица заказчика за лицензии, которыми никто не пользуется. Появление таких людей закономерно: сама структура бюрократии заставляет подразделение запрашивать больше ресурсов, чем ему нужно. Подразделение знает свою настоящую себестоимость лучше, чем тот, кто даёт деньги, и пользуется этим.

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

Есть пара историй, подсказывающих, что я прав. Группа DORA много лет измеряет, как работают ИТ-команды. В 2019 выяснили, что компании, где значимые изменения утверждает внешний комитет или старший руководитель, в 2,6 раза чаще оказываются среди отстающих. Надёжнее от этого не становится: связи такого утверждения с меньшей долей сбойных изменений не нашли. Зато всё тормозит, изменения копятся в большие пачки, а такие пачки чаще ломаются, либо теряется время. Или вот британский финансовый регулятор. В обзоре 2021 года они разобрали больше миллиона изменений, внесённых за 2019 год в 23 финансовых компаниях. Комитеты одобрили больше 90% крупных изменений, которые рассматривали, а некоторые за год не отклонили ни одного. То есть по факту они их диспетчеризировали и роутили.

Консерватор. Системе, которая меняет баланс власти, сопротивляются те, кто власть теряет. Собственно, так и становятся консерваторами.

Это то, что сейчас случается с приходом ИИ-аугментированных команд. То, что старый ИТ-отдел планирует на 3 месяца, новые команды выкатывают за вечер. И я сейчас не про вайбкодинг, там получается одноразовый софт на выходе. Я именно про правильную разработку, где архитектура и решения — на опытном человеке, а вот техническая работа — на моделях под его управлением. И где код читается до строчки. Мы так работаем, например, — это не х20 вайбкодинга, конечно, но в итоге получается очень хорошо.

ИИ-шаманизм

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

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

Что мы с этим делали на проекте

1. Спрашивать «а зачем?» при получении каждого счёта и «чем он занимается?» про каждую должность. Обычно этого хватает, если задать вопрос необходимое и достаточное количество раз.

2. Согласования вывести в правило, а не в интуитивное решение кожаных. Да, это на практике не всегда реально, но в 90% случаев требования сформулированы достаточно чётко, и большую часть проблем так можно решить.

3. Требовать от ИБ проверяемых формулировок. По какому наблюдаемому показателю мы признаем эту меру ненужной?

4. Нельзя чинить одно и то же два раза. Рядом с хранителем сидит человек, который записывает. Хранитель говорит, что делать, сам ничего руками не делает вообще.

5. Убрать премии за чужую выручку. Сотрудник, который получает бонус за каждый заказ у вендора, будет заказывать у вендора.