Основы доверия в инженерии

Обычно про инженерию говорят как про техническую дисциплину. Мы фокусируемся на технической стороне — алгоритмы, структуры данных, распределённые системы, правильный partition key и так далее.

Смотреть на это так — не ошибка, но под этим слоем скрывается другая история.

Инженерия держится на доверии.

Я не имею в виду это в каком-то философском смысле. Я имею в виду это буквально. Всё, что ты назвал бы "работой" — архитектурная диаграмма, CI/CD-пайплайн, on-call дежурства, промо-пакет — на самом деле подменяет собой вопрос, кому и чему ты можешь доверять.

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

Сейчас покажу, почему это так.

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

Это и есть доверие.

И с ним никто не начинает.

Когда кто-то в первый раз ревьюит твой пул-реквест, он читает каждую строку, потому что у него ещё нет модели тебя. Он не знает, тестируешь ли ты edge-кейсы, или ты из тех, кто глотает ошибку через try/except: pass и идёт обедать. Поэтому он делает полное ревью — медленное, подозрительное, придирчивое. Кажется, что тебя не уважают, но на самом деле тебя просто ещё не знают.

Потом ты начинаешь работать. Пишешь тесты. Оставляешь комментарий, объясняющий странный хак, вместо того чтобы заставлять спрашивать. Сам помечаешь рискованные изменения раньше, чем их найдут. Не споришь, когда неправ — и постепенно модель тебя у ревьюера обновляется с "неизвестное качество" до "я доверяю Кириллу, этот человек сам ловит свои ошибки". После этого твои пул-реквесты будут проходить быстро. Когда ты говоришь "это срочно, нужны глаза в течение десяти минут" — их дают, потому что ты не говоришь так, если это неправда.

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

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

Большинство инженеров думают, что менеджер сначала должен заслужить их доверие, но на самом деле карьеру двигает то, что менеджер может доверить тебе неопределённость.

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

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

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

У меня было и то, и другое. Хорошая версия ощущалась как прикрытие с воздуха. Плохая — будто каждый 1:1 был допросом. Я оставался тем же человеком, и код оставался тем же кодом в обоих случаях. Единственной переменной было доверие — и именно оно решало, потрачу я день на то, чтобы создать что-то новое, или на то, чтобы защищаться.

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

Любой инструмент, к которому тянешься не задумываясь — это инструмент, которому ты доверяешь. Ты пишешь git commit и доверяешь, что он молча не сожрёт половину твоих изменений. Запускаешь Spark-джобу и доверяешь, что df.count() — это реальный счётчик, а не приближение. Вся твоя карьера построена на инструментах, которые ты в какой-то момент тихо перестал перепроверять.

Понимаешь, к чему я веду?

AI — тот же самый вопрос, только в большем масштабе. Когда люди спорят, доверять ли LLM писать код, на самом деле они задают тот же вопрос, на который мы уже ответили для компиляторов, ORM и автоскейлеров: сколько можно отдать на аутсорс, прежде чем потеряешь понимание собственной системы?

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

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

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

Доверие к зависимостям транзитивно, а ты почти ничего из этого не подписывал. Твоя библиотека логирования доверяет парсеру, который доверяет алгоритму сжатия, который поддерживает человек, переставший отвечать на issues в 2019 году. Ты не аудировал это дерево. Никто не аудирует это дерево. Мы доверяем ему, потому что оно популярное. Мы называем "четыре миллиона скачиваний" due diligence, хотя на самом деле это просто толпа, договорившаяся тоже не проверять.

И масштаб — не доказательство безопасности. Когда left-pad сняли с публикации, одиннадцать строк кода за одну ночь сломали сборки половины интернета. Когда ударил Log4Shell, каждая команда на Земле потратила выходные, доказывая отрицательное. Бэкдор в xz был тише и хуже: атакующий не обошёл модель доверия — он её заслужил, годами чистых коммитов, пока репутация одного мейнтейнера не стала самой уязвимостью.

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

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

Вся ценность data-платформы — в доверии к её цифрам, это и есть настоящий продукт, а всё остальное — просто сантехника у него на службе.

Я видел, как команда сожгла три недели, гоняясь за "плохими данными" в дашборде метрик. Не то чтобы данные были драматически неправильными — они были просто чуть-чуть не такими, ровно настолько, чтобы бизнес тихо перестал доверять цифрам, а вместе с ними и команде за ними. Каждая джоба отрабатывала зелёным, каждый тест проходил, а проблема была в race condition: два запланированных запуска пересеклись, оба одновременно долбились в одну и ту же временную таблицу, и один молча перезаписал другой. Три недели неверных цифр укатились в прод, прежде чем кто-то заметил. Пайплайн ни разу не сообщил, что врёт.

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

Именно поэтому настоящая работа дата-инженерии — производство доверия к цифрам. Переместить байты из точки A в точку B — это лёгкая часть. Каждый инструмент, вокруг которого мы одержимо строим процесс, на самом деле про доверие.

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

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

"Как именно" может меняться, но под этим "как" всегда один и тот же результат: кто-то решает, что больше не обязан проверять работу. Вот что такое доверие, везде. Его медленно зарабатывают и быстро теряют, и оно стоит больше, чем почти любое техническое решение, которое ты примешь. А тихие сбои — сломанное, которое выглядит нормально — наносят больше всего вреда, потому что тратят это разрешение ещё до того, как кто-то догадывается посмотреть.

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

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