Спасите меня из ада данных

Мельбурн, 9:59 утра, 9 октября 2024 года. Солнечный свет проникает через мои окна, освещая кружащиеся по моей гостиной пылинки. В моей руке чашка с чаем. Делаю глоток и наслаждаюсь вкусом.

Я пишу другому сениор-разработчику из команды, который, в отличие от меня, работает на полную ставку: «Я готов начать в 10»; таков наш обычай.

Минутная стрелка делает шаг.

Мельбурн, 10:00 утра, 9 октября 2024 года. Солнце мгновенно гаснет и заменяется пронзительно вопящим черепом, низко висящим в леденящем небе. Я бросаю взгляд на чай, он похож на кровь. Делаю глоток и наслаждаюсь вкусом.

Я пишу другому сениор-разработчику из команды: «Ты готов отправиться в Зону мучений?»¹; таков наш обычай.

▍ I. Зона мучений

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

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

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

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

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

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

Я уже повидал немало компаний и благодаря своему блогу имею доступ к достаточно большому количеству высших руководителей, поэтому знаю, что большинство корпоративных культур скатывается именно в это. Ужасные компании — это постоянные угрозы для разума, в которых ежедневно гнобят всех и каждого. В медианных компаниях (которые некоторые люди называют «хорошими», потому что не видели ничего лучше) нет непосредственного гнобления, но они всё равно состоят из людей, пытающихся убедить себя, что нормально целый день чувствовать себя лишённым сил или подчинённым. В моей жизни случались ситуации, когда мне приходилось сталкиваться с этим, но их вряд ли можно считать нормальными. Лучшими называют компании, в которых вы получаете хотя бы некоторые из вещей, нужных человеку, кроме денег на съём жилья².

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

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

Как бы то ни было, мне приходилось иметь дело с командой. Каждое утро ты наливаешь кофе, принимаешь участие в совещаниях, а с 10 утра мы вместе блуждаем по Зоне мучений не меньше трёх-четырёх часов. Руководство остаётся в блаженном неведении относительно того, что эта сила товарищества и взаимной психотерапии — единственное, благодаря чему система продолжает влачить своё существование.

▍ II. Я проиграл Зоне мучений

Сегодня у нас есть одна простая задача. Организация хочет знать:

1. Поступают ли данные в нашу систему?
2. Теряются ли какие-то данные?
3. Каждый источник данных в среднем проходит примерно тринадцать этапов — на скольких из них происходят заминки?

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

И именно здесь, уже спустя пять секунд, мы оказываемся затерянными в Зоне мучений.

Допустим, выбранный нами источник данных — это «Google Analytics». Мы ищем сохранённые логи для Google Analytics, ожидая увидеть примерно что-то такое:

А вот, что я на самом деле вижу в столбце Source; и да, всё действительно выглядит настолько плохо.

Это… явно не Google Analytics. Что это вообще такое? Похоже, кто-то просто сбросил в логи произвольный кусок JSON, но даже не целиком. У строк нет указателей конца. У нас должно быть примерно пятьдесят систем-источников, а сколько отдельных систем-источников отображается?.. ПЯТЬДЕСЯТ СЕМЬ ТЫСЯЧ?

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

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

Так, но что же происходит? Оказалось, мы встраиваем огромный объём метаданных в имена файлов, а создающие всё это лямбда-функции (разумеется, у нас serverless-архитектура, ведь надо обязательно быть на острие прогресса, чтобы израниться) используют для извлечения данных кучу регулярных выражений. К сожалению, поскольку у нас нет никаких тестов, кто-то написал код для скачивания данных, который передаёт функции логгинга большой блоб JSON вместо имени файла, и эта функция сказала: «Отлично, я просто вырежу регулярным выражением систему-источник из имени файла!» Только это было не имя файла, поэтому мы месяцами кидали в систему мусор.

Я нахожу нечто подобное каждый раз, когда мы входим в Зону мучений. Иногда мы хохочем до смеха над тем, что делали консультанты с зарплатой в две тысячи долларов в день.

Мы создали issue для компании, но поскольку устранения этой критической ошибки нет в доске Jira, а velocity не может снижаться, исправление логов посчитали менее важным, чем… парсинг… бессмысленных логов. Почему? На этот счёт у нас в команде есть ещё одна поговорка: «Не задавай вопросов, тебе же больнее будет».

Я сделал ещё один глубокий вдох.

Ну ладно, мы продолжим работать вместо того, чтобы устранять критичный баг в продакшене. Мы не можем выполнять запросы данных Google Analytics на основании системы-источника, так что выберем что-то другое. Мы можем получать данные из Twitter раз в два часа, и этот столбец Source не поломан. Чтобы начать работать над этим, нам нужно просто настроить соответствующие события логов. То есть у нас будет один лог, говорящий «я скачал данные с Twitter» и второй, сообщающий «я проверил, что там всё правильно», а мне останется лишь связать их вместе.

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

Чтобы потом можно было просто сделать так:

select   event,   success from   log_table where event_id = 1 and source = 'twitter'

Тогда я буду видеть, что всё происходит правильно.

Но я не могу найти столбец event_id и ничего, похожего на него. Я связался со специалистом по этой системе, и мне сообщили, что нужно использовать столбец awslog. Я посмотрел на него.

Он выглядел так:

Ну, во-первых, что это за хрень? Во-вторых, что это за хрень? В-третьих, ну, вы поняли. Почему просто не хранить это всё в реляционном формате? Почему это всё в одном столбце? Откуда такая ненависть именно ко мне?

Не задавай вопросов, тебе же больнее будет.

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

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

▍ III. С меня хватит

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

Но постойте, мы получаем эти данные раз в два часа, то есть хоть я и могу найти все операции получения данных из Twitter за 11 марта, мне не удастся отличить строки, полученные в 8 часов от строк, полученных в 14 часов. Этот непонятный столбец awslog идентифицирует данные с точностью до дня, а не до часа. У нас есть другой столбец, который выполняет логгинг точного времени запуска лямбда-функции вплоть до секунды, но каждый этап выполняется в немного различающееся время, а для каждого источника требуется своё количество времени в зависимости от размера файла.

Я написал команде: «Есть идеи, как идентифицировать конкретные запуски, если не предполагать, что выполнялся только один запуск за день?»

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

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

Как мы работали таким образом два года? На эту систему потратили миллионы долларов. Наш CTO, не написавший ни строки кода, раз в несколько месяцев выходил на сцену и просто лгал людям в глаза о том, чего CTO даже не может понять; он притворялся, что всё это работает и что мы лидеры в данной отрасли. Затем наше ПО купили друзья слушателей (я знаю это, потому что рекрутёры постоянно связывались со мной и спрашивали, смогу ли я руководить работой с ним). Почти каждый крупный бизнес в Мельбурне рванул покупать наш инструментарий, инструменты наподобие Snowflake и Databricks, потому что наша отрасль притворяется, что всё это важнее, чем нанимать компетентных людей и относиться к ним по-человечески. Я могу создать более совершенную систему на древнем ноутбуке, мне бы хватило подключения к Интернету и электронных таблиц. Это займёт у меня максимум месяц.

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

Поразмыслив, человек, только что сказавший, что логи никак нельзя привязать к событиям, добавил:

«Кстати, есть вероятность, что в некоторых из логов содержится неправильная информация. Например, Validated: True — это на самом деле прописанные в лямбда-функциях строки, а писавшие их люди имели в виду что-то типа File Landed: True, но допустили ошибки».

Я онемел, а второй сениор истерически засмеялся.

Мельбурн, 11:30, 9 октября 2024 года. Ветер — это ураган невидимых ножей, пронзающий птиц в небе. Я бросаю взгляд на чай, он превратился в чистую ненависть. Делаю глоток и наслаждаюсь вкусом.

«Эй, ты ещё там?», — отвечает мой напарник.

«Да. Да. Послушай, я всё. Увольняюсь сегодня».

«Что? А как же декабрь?»

«К декабрю я бы дописал первый ужасный черновик книги, если бы не тратил время на всё это».

«… Справедливо».

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

Я подписал документы на увольнение в 14:00.

▍ IV. Благословенная свобода

Мельбурн, 15:00, 9 октября 2024 года. Я позвонил своему директору, очень компетентному человеку, и объяснил, почему все разработчики втайне хотят уволиться, и закончил подписывать бумажки. Последним днём моей работы будет 5 ноября 2024. Теперь моей единственной должностью будет директор в моей собственной консалтинговой фирме, а в январе начнётся обратный отсчёт моих накоплений. Бросаю взгляд на чай, и он выглядит, как чай. Я делаю глоток и наслаждаюсь вкусом.

---

1. Мы действительно говорим это каждое утро. ↩
2. Те, кто стремится заработать все деньги, вероятно, тоже не оказывают себе хорошую услугу.↩

Telegram-канал со скидками, розыгрышами призов и новостями IT 💻