Технический Хаос: Операционная Беспомощность и Расходы, Оправдываемые Ложью

produceryoutubechannel.blogspot.com

View Original

Разработчик под ником Ludic*, автор технического блога Ludicity, сэкономил своей компании полмиллиона долларов за пять минут. Это больше, чем он заработал для работодателей за всю его карьеру, поскольку сфера деятельности, о которой далее пойдёт речь, — обман. Он всего лишь нажал на пять кнопок.

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

---

Предыстория

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

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

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

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

Это никогда не срабатывало. Нам сказали, что нужно дождаться развёртывания платформы расширенной аналитики (AAP). Сейчас, видите ли, декабрь, а запуск состоится в январе.

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

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

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

Это полный отстой

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

Я нанял своего друга (большого поклонника кумовства), и он в первый же день обнаружил в репозитории проекта файл, который удаляет прод с помощью наших конвейеров CI/CD, если он попадает не в ту папку. Файл поставляется в комплекте с ключом и паролем, необходимыми для учётной записи администратора. Создал его ведущий инженер, перешедший на новую должность до того, как грехи прошлого настигли его.

Все это скрепляется вместе с помощью электронных таблиц, которые разбираются Python, передаются в S3, разбираются Lambdas в другие S3, файлы S3 подхватываются MongoDB, затем записи MongoDB передаются другой Lambda в S3, файлы S3 попадают в Snowflake через Snowpipe, новые данные Snowflake преобразуются хранимой процедурой Javascript в реляционный формат... и именно так редактируется чей-либо доступ к базе данных. По сути, весь этот процесс — загрузка CSV-файла размером 2 КБ в базу данных, в которой заданы роли её пользователей.

Такой подход считается более контролируемым.

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

Каждая лямбда-функция, основа всех конвейеров ETL, начинается с counter = 1 , потому что одна из ранних итераций использовала счётчик, и люди просто копировали эту строку снова и снова. Старшие специалисты по обработке данных копировали эту строку снова и снова.

Наборы тестов в конвейерах CI/CD не работали месяцами, потому что кто-то во время отладки решил использовать Linux-команду tee для записи любых ошибок в stdout и в файл одновременно, а успешно выполненный tee перезаписывал код ошибки из неудачных тестов.

Чтобы получить доступ к паролю для любого API, который нам нужен, мы ищем что-то вроде service-password в сервисе AWS, который возвращает значение... service-password (то есть буквально все значения совпадают с ключами), а затем используем его для поиска фактического пароля в совершенно другом сервисе. Никто не знает, зачем мы это делаем.

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

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

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

Бюджет

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

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

Несколько фактов:

1. В качестве базы данных мы используем Snowflake, которая взимает плату в зависимости от количества компьютеров, которые используются для выполнения запросов.

2. Мы платим только за компьютеры, пока они включены.

3. Мы выполняем, вероятно, несколько тысяч запросов в неделю, в основном разработчики экспериментируют с небольшими твиками для отчетов PowerBI, которые никто не читает, и в среднем на их выполнение уходит около 2 секунд.

4. После каждого запроса компьютеры простаивают 10 минут.

Я заметил это примерно через месяц после прихода в команду и предложил, э-э... не заставлять компьютеры работать на два порядка дольше, чем нужно для каждого запроса. Я буквально не помню, что было сказано — какая-то Agile-ерунда про Discovery, но потом просто ничего не произошло.

Просто сделать!

Как бы то ни было, спустя несколько месяцев мне наконец выдали карточку с надписью «Discovery: Оптимизация расходов». Теперь мне нужно оптимизировать расходы, чтобы было что сказать на следующем стендапе, и, к счастью, я знаю, что именно делать! Я проверю свою гипотезу о том, что все это — больная шутка, и нажму на кнопку, которую, по моему тайному мнению, явно следовало нажать.

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

Царство хаоса

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

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

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

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

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

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

Последствия и выводы

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

Я прошу руководство о прибавке в 30 тысяч долларов после того, как сэкономил 500 тысяч, и мое сообщение до сих пор не прочитано. Подозреваю, что в итоге я получу либо ничего, либо 5 тысяч.

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

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

**Альтернативное название:**

"Технический Хаос: Операционная Беспомощность и Расходы, Оправдываемые Ложью"

**Вывод:**

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

**Теги:**

#ТехническийДолг #УправлениеДанными #Безопасность #Расходы #CI/CD #Snowflake #ОперационнаяНеэффективность

**Хэштеги:**

#ТехнологическийБеспорядок #ТехническиеПроблемы #БюджетныеТрудности #СекьюритиФейл #ITДрама #ОперационнаяХаос