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

Мы встречались с обоими персонажами. Пурист, который любит теоретизировать о «конвейерах данных с расчетом на будущее», «современной архитектуре данных», «лучших практиках» — все это аккуратно помещено в Death by PowerPoint. Он настоящий сторонник правил. Назовем его сторонником Стивом. Вы с нетерпением ждете следующей встречи по архитектуре, на которой вы будете взволнованы и поражены тем, что мы собираемся реализовать дальше. А с другой стороны, герой, деятель, парень (или девушка), который выполняет работу в 2 часа ночи, чтобы ввести данные в производство. Назовем ее прагматичной Пруденс. Это совсем другое (и более страшное) слайд-шоу, которое она может скомпилировать. Поместите то, что она знает, в PowerPoint, пролистайте ее, и вы можете получить что-то похожее на фильм Уэса Крэйвена.

Эти двое не говорят друг о друге с любовью, по крайней мере, наедине.

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

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

Итак, как мы все тянем в одном направлении? Я очень ценю статью бывших коллег о том, как архитекторы данных (пуристы) могут ошибаться и что ответственность за доставку является критически важной предпосылкой. ¹ Это то, что заставляет двух персонажей сидеть за одним столом. Убедиться, что пурист несет ответственность за запуск хорошо продуманного решения в производство, и, таким образом, добавить немного прагматизма в словарный запас Стива.

Теперь, когда мы сидим за одним столом, давайте начнем говорить на одном языке. Я сосредоточусь на одном из аспектов, с которым, я уверен, оба согласятся и оценят… автоматизация.

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

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

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

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

Противники автоматизации часто делятся этой картиной:

Они не совсем неправы. Такова реальность мемов. Они смешны только потому, что в них есть доля правды.

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

Сделайте паузу и подумайте немного: спросите себя: ненавижу ли я неэффективность? Думаю, первым ответом всегда будет «да, конечно», но подумайте об этом. Для себя я бы перефразировал вопрос так: постоянно ли я оказываюсь в ситуации, говорящей: «Я действительно думаю, что мы решили эту проблему пару месяцев назад, почему мы снова об этом думаем?» Это чувство меня до глубины души беспокоит, оно меня волнует, раздражает и всякое другое «съедает». Те, кто работал бы со мной, знают, что на этом этапе я становлюсь чрезвычайно педантичным и почти роботизированным. Должен. Решать. Неэффективность. Сейчас.

Настройка основы может занять больше времени, чем ожидалось, а идентификация и создание шаблонов повторяющихся шаблонов займет больше времени, чем ручное выполнение в первый раз. Может быть, даже 2-й, может быть, даже 3-й, а может быть… ок, ладно, вы меня поняли. В какой-то момент автоматизация превзойдет ручное, но только если у вас есть дисциплина, чтобы придерживаться процесса.

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

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

В моих беседах с клиентами каждый раз в обязательном порядке всплывают термины Data Ops, Dev Ops, CI/CD. Автоматизация является ключевым элементом Data Ops и Dev Ops. Я не всегда могу спросить своих клиентов, действительно ли это то, что им нужно, или это то, что предложил их Стив, но потребность очевидна. Инструменты должны иметь возможность интегрироваться с Jenkins, GitHub и т. д. Все должно быть доступно для сценариев. Нам нужны красивые внешние интерфейсы для разработки, но мы хотим, чтобы интерфейсы командной строки работали и развертывались.

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

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

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

1. Thomas, J., 2021. The rise and fall of data architecture. [online] ITWeb. Available at: <https://www.itweb.co.za/content/o1Jr5Mx9AxPqKdWL> [Accessed 24 November 2021].
2.WIRE, B., 2021. Data Engineers Are Burned Out and Calling for DataOps. [online] Businesswire.com. Available at: <https://www.businesswire.com/news/home/20211019005858/en/Data-Engineers-Are-Burned-Out-and-Calling-for-DataOps> [Accessed 24 November 2021].