Итак, вы создаете это решение с интенсивным использованием данных для своего проекта по машинному обучению / аналитике данных / корпоративной трансформации или тестирования продукта... Независимо от того, где вы находитесь, если вы работаете в области проектирования данных, это, откровенно говоря, важное чтение.
Организации часто хотят прыгнуть в это пространство, не рассматривая сначала основы. Это гораздо больше, чем просто подготовка данных. Организация, которая несерьезно относится к качеству данных, также несерьезно относится к управлению данными и их целостности.
Далее следует практическое руководство для технических директоров, инженеров по данным, специалистов по данным, их команд, предпринимателей и деловых людей. Я также изложу важные соображения как с точки зрения результатов бизнеса, так и с точки зрения основных подходов и принципов, которые вам необходимо учитывать в этой области.
Обо мне и этой статье
В качестве технического директора-консультанта я работал с рядом стартапов, каждый из которых рассматривает решения, основанные на данных, возможности машинного обучения и требования к обработке данных. В основном в секторах с высокими требованиями, таких как финансовые услуги и здравоохранение, где точность данных имеет решающее значение для успеха бизнеса, репутации, соответствия и безопасности.
Для подавляющего большинства предприятий в этой сфере данные — это их интеллектуальная собственность, это знания, на основе которых им необходимо строить и развивать свои возможности. Это также имеет решающее значение для монетизации, поскольку все больше и больше программного обеспечения на стороне приложений становится товаром, что делает IP доступным через API за плату, что становится все более привлекательной бизнес-моделью.
Инжиниринг данных — MVP для предприятия
Чтобы добиться целостности данных, в первую очередь необходимо сосредоточиться на качестве данных. Для любого новичка в этом пространстве это действительно приоритет номер 1.
Ключевой аспект решения проблемы качества данных — начать как можно раньше и не бегать, пока не научишься ходить. Типичный сценарий — это стартап-команда, которая создает MVP, а бизнесмены говорят о данных, не понимая их функции, и влияют либо технически, либо с точки зрения бизнес-результатов. Добавляются источники извлечения данных, становится грязно, ничего не планируется, и, честно говоря, всех этих проблем с выполнением можно было бы избежать.
Начните с основ
В AWS озеро данных — это просто корзины S3, соединенные вместе, потому что озеро данных — это централизованный репозиторий, предназначенный для хранения, обработки и защиты больших объемов структурированных, частично структурированных и неструктурированных данных. Он может хранить данные в собственном формате и обрабатывать любые их разновидности, игнорируя ограничения по размеру. Что ж, это также то, что делает хранилище объектов, то есть корзина S3.
Озера данных позволяют импортировать любое количество данных, собирать их из нескольких источников и перемещать в озеро данных в исходном формате. Этот процесс обеспечивает высокую гибкость масштабирования и экономит время при определении структур данных, схемы и преобразований.
По моему собственному опыту, люди просто верят, что вы можете бросить что угодно в Datalake, а затем это можно просто включить в какое-то аналитическое решение, которое покажет вам волшебные точные результаты без каких-либо усилий…
О, мой сладкий летний ребенок, как это наивно…
Перво-наперво.
Написание схемы данных
Немного сложно определить, как хранить ваши данные, если вы не знаете, какие запросы вы хотите выполнять. Любой, у кого есть MVP вместе, должен знать это. Чем раньше вы задокументируете это, тем лучше вы окажетесь. Это действительно довольно быстро разрешает множество аргументов от инженерных групп. Поскольку типы запросов будут определять типы баз данных, а также вам потребуется масштабировать их и, возможно, со временем добавлять новые типы запросов, это также будет определять, что вы выберете для начального хранилища, и станет первой частью вашей дорожной карты.
Как вы документируете это, зависит от вас. Некоторые решения БД позволяют вам экспортировать вашу схему, что даст вам стартовую десятку. Еще одна вещь, которая имеет решающее значение, - это определение отношений ваших сущностей. Создание диаграммы для этого - действительно хорошее упражнение для бэкэнд-программистов, если вы находитесь на ранней стадии бизнеса, выполнение этого как групповое действие или просмотр этого как группового действия может быть действительно полезным для формирования коллективного понимания данных. модель в вашей команде.
Затем это необходимо будет периодически пересматривать и учитывать в соответствии с вашими непосредственными потребностями в бизнесе и долгосрочными целями. Также важно сделать это до того, как вы приступите к созданию своего первого конвейера данных.
Создание вашей первой воронки
Когда у вас нет огромных объемов данных для приема, преобразования и потребления, но вы ожидаете, что это будет будущим архитектурным требованием, это тот момент, когда нужно начать рассматривать возможность создания начального конвейера.
Главное — обеспечить отделение необработанных данных от чистых, преобразованных и потребляемых (минимум x3 корзины S3, однако ссылку на архитектуру см. ниже). Следующая проблема заключается в том, как вы перемещаете данные по конвейеру. Предполагая, что у вас нет требований к потреблению данных «в реальном времени» или «почти в реальном времени», а потребление и обработка данных довольно ограничены, существует ряд подходов, которые вы можете использовать для перемещения данных между сегментами. Многие из этих подходов не требуют существенного обучения. Как только вы масштабируетесь до больших объемов данных и обработки данных, это становится серьезной задачей и требует большого изучения сложных продуктов и наборов инструментов (например, Apache Spark, AWS Glue), чтобы эффективно решать ее. Это то, что нужно планировать, и инженеры должны постепенно учиться (или, предпочтительно, нанимать опытных специалистов), чтобы быть эффективными. Кривая обучения этим корпоративным решениям откровенно сложна.
Но что верно в любом сценарии, так это то, что вы должны начать с одного или двух вариантов использования и решить, как вы будете его масштабировать. Это так же актуально и важно как для крупных корпораций, так и для начинающих компаний.
Архитектура и техническая дорожная карта являются ключевыми; понимание необходимого минимума для удовлетворения ваших бизнес-требований сейчас и план того, как вы будете постепенно двигаться к более долгосрочной цели.
Запуск на ранней стадии — ограниченные объемы данных
Конечно, существует множество разных подходов, в зависимости от вашего варианта использования, но вот несколько простых руководств для начала.
Для начинающих стартапов/прототипов продуктов и легкого обучения:
Базовый конвейер данных с использованием пошаговых функций:
Автоматизация конвейера данных с помощью Lambda
https://medium.com/codex/automating-an-end-to-end-data-pipeline-on-aws-cloud-7b5489e2925d
Как только вы решили перейти к корпоративному масштабу и у вас есть требования для преобразования больших объемов данных, вы можете начать с настройки каталога данных Glue и внедрения своего первого Glue Crawler. Начните на ранней стадии кривой обучения и постепенно, по мере возможности, наращивайте ее с течением времени.
https://docs.aws.amazon.com/glue/latest/ug/tutorial-add-crawler.html
Запуск более поздней стадии — увеличение объемов данных
Хороший базовый паттерн проектирования — (независимо от того, будете ли вы использовать serverless или нет)
Это взято из Serverless Data Pipelines — см. сообщение в блоге и ссылки на технические документы здесь: https://aws.amazon.com/blogs/big-data/aws-serverless-data-analytics-pipeline-reference-architecture/
Мне нравится serverless, но это не всегда уместно. Предполагая, что у вас есть много асинхронных задач, запускаемых событиями, это может быть правильным подходом для вашего продукта. Однако для большинства команд это большой скачок к полностью бессерверному подходу… см. подводные камни.
Другие инструменты/решения и службы для конвейеров данных и приема данных в масштабе теперь могут сильно различаться в зависимости от вашего варианта использования, поэтому здесь представлено сочетание решений с открытым исходным кодом и управляемых решений.
Обработка данных в масштабе
Конечно, это очень зависит от вашего варианта использования, но вот некоторые из самых популярных решений на рынке. Убедитесь, что вы работаете с кем-то, имеющим опыт в этой области, чтобы убедиться, что вы выбрали правильный инструмент для правильного контекста. Ошибки здесь обходятся дорого не только с точки зрения инфраструктуры, но и с точки зрения времени обучения для отдельных лиц и целых команд.
Важное слово о стоимости…
Масштабная обработка данных требует больших затрат. Убедитесь, что вы сопоставляете все, что можно оптимизировать с точки зрения экономической эффективности, и используете такие вещи, как спотовые экземпляры, для непроизводственных рабочих нагрузок. В частности, потоковая передача данных является дорогостоящей. Действительно ли пользователям нужны данные «в реальном времени»? Или приятно иметь? Внимательно изучите АБСОЛЮТНЫЕ требования.
Существуют ориентиры для предприятий SaaS, согласно которым стоимость инфраструктуры не должна превышать 10% от ARR для бизнеса. Это для бизнеса на ранней стадии, который не генерирует достаточного оборота, часто совершенно нереалистично, а тяжелые продукты и решения для анализа данных и машинного обучения будут дорогостоящими в настройке и обслуживании. Просто нереально думать, что это точно впишется в 10% ARR. Ни у кого из тех, кто имеет опыт ведения реального бизнеса в этой области, нет таких нереалистичных ожиданий. Опытные специалисты стоят дорого, равно как и большие вычислительные нагрузки.
Открытый исходный код не обязательно поможет вам. Накладные расходы очень высоки (и никогда не учитываются одержимыми ОС), это действительно из-за бесконечного обслуживания, исправлений безопасности и сложной настройки, для которых командам требуется много времени и усилий (эти дополнительные накладные расходы скрыты). ОС в принципе великолепна и может сэкономить вам деньги, но вы должны учитывать кривую обучения и дополнительные усилия по обслуживанию.
Некоторые часто используемые продукты и решения для рассмотрения (в зависимости от вашего варианта использования, конечно, см. Ниже).
Apache Spark — это распределенная система обработки с открытым исходным кодом, используемая для рабочих нагрузок больших данных. Он использует кэширование в памяти и оптимизированное выполнение запросов для быстрых запросов к данным любого размера. Хорошая потенциальная комбинация с Kinesis для обработки данных в реальном времени и рабочих нагрузок, для которых AWS предлагает управляемую интеграцию.
Apache Flink — механизм распределенной обработки и масштабируемая платформа для анализа данных. Вы можете использовать Flink для крупномасштабной обработки потоков данных и предоставления аналитических сведений об обработанных данных в режиме реального времени с помощью приложения для потоковой передачи.
Apache Hadoop — это платформа с открытым исходным кодом, которая используется для эффективного хранения и обработки больших наборов данных размером от гигабайт до петабайт данных. Вместо того, чтобы использовать один большой компьютер для хранения и обработки данных, Hadoop позволяет объединять несколько компьютеров в кластеры для более быстрого параллельного анализа массивных наборов данных. Подобно Spark, но в некоторых ключевых отличиях Spark использует оперативную память (ОЗУ) вместо чтения и записи промежуточных данных на диски. Hadoop хранит данные в нескольких источниках и обрабатывает их пакетами с помощью MapReduce.
AWS Kinesis. Amazon Kinesis Data Streams можно использовать для сбора и обработки больших потоков записей данных в режиме реального времени. Вы можете создавать приложения для обработки данных, известные как приложения Kinesis Data Streams. Типичное приложение Kinesis Data Streams считывает данные из потока данных в виде записей данных. Это часть семейства связанных продуктов, которые предназначены для различных вариантов использования в масштабе.
AWS EMR (ранее называвшаяся Amazon Elastic MapReduce) – это управляемая кластерная платформа для запуска платформ для работы с большими данными, таких как Apache Hadoop и Apache Spark. Он выполняет некоторые функции ETL, аналогичные Glue, однако EMR является более настраиваемым решением.
AWS Glue.AWS Glue — это полностью управляемый сервис ETL для подготовки и загрузки данных для аналитики. Вы можете создать и запустить начальное задание ETL несколькими щелчками мыши в Консоли управления AWS. Glue использует свою параллельную обработку, чтобы выполнять большие рабочие нагрузки быстрее, чем Lambda (разработчики часто путаются здесь). Однако Glue — непростое решение для освоения, и большую часть конфигурации необходимо настроить с помощью Cloud CLI (функции облачной консоли на самом деле ограничены).
Snowflake.snowflake — это облачное хранилище данных, предназначенное для запросов и хранения данных на основе SQL. Его часто путают с Hadoop (принципиально другое решение, см. выше), поэтому он упоминается здесь. Это было бы лучше по сравнению с решением для хранения данных AWS Redshift.
Google Big Query — это действительно Redshift или альтернатива Snowflake. Я не уверен, почему люди путают это с решениями для обработки данных для того, что вам нужно…
Google Dataflow.Dataflow – это полностью управляемая служба потоковой аналитики, которая сводит к минимуму задержки, время обработки и затраты благодаря автоматическому масштабированию и пакетной обработке. Его также можно использовать для рабочих нагрузок ETL и там, где Spark Streaming может не подходить для приложений, требующих обработки данных с малой задержкой. Решением, которое следует рассмотреть, является Google Dataflow.
Конвейеры данных с Google Cloud
Введение в пакетные конвейеры Google Cloud здесь:
https://www.cloudskillsboost.google/course_templates/53
Фабрика данных Azure — решение ETL имеет функции, аналогичные AWS Glue, а также некоторые принципиальные отличия. В фабрике данных можно создавать конвейеры — краткое руководство приведено ниже.
https://learn.microsoft.com/en-us/azure/data-factory/quickstart-get-started
Azure Synapse — еще одна альтернатива Redshift/snowflake.
Мне нравятся инфраструктурные продукты Microsoft, поскольку они зачастую более гибкие и многонастраиваемые, чем многие предложения AWS. В то время как Google очень хорошо предлагает подход, ориентированный на разработчиков. Однако с предложениями Microsoft и Google за пределами крупных корпоративных сред Enterprise затраты высоки. Это связано с тем, что их решения намеренно упакованы в группы продуктов для продажи крупным корпорациям. Затраты на AWS всегда высоки только тогда, когда инженеры понятия не имеют, как настраивать и запускать эти сервисы. Эти знания являются ключом к управлению затратами (не говоря уже о хорошей безопасности).
Краткое описание подхода к конвейеру данных с использованием Apache Spark и Airflow.
https://towardsdatascience.com/how-to-build-data-engineering-pipelines-at-scale-6f4dd3746e7e
Подводные камни
Стартапы, в частности, действительно испытывают трудности, когда им приходится учитывать масштабы предприятия. Я видел предприятия с простым веб-приложением и ограниченным приемом данных, когда команды младших инженеров усердно внедряли сетку данных только для того, чтобы позже от нее отказались, когда действующее (и неадекватно квалифицированное) руководство уйдет…
Архитектура
Чтобы качественно выполнять свою работу в качестве лидера, вам нужна архитектура, соответствующая бизнесу и сценарию. Но ожидание неподходящих решений — очень распространенная ошибка, очень распространенная среди неопытных команд, но также часто случается и с опытными инженерами. Одна из проблем заключается в том, что инженерные команды хотят повысить квалификацию и видят в этом возможность сделать это, поскольку они видят что-то ожидаемое в дорожной карте.
Кривая обучения
Изучение корпоративных решений требует времени, терпения и обучения на рабочем месте необходимо сочетать с руководством старших инженеров, которые со временем могут обучать менее опытных членов команды. Предполагая, что ваш бизнес хорошо финансируется, и его масштабирование следует рассматривать как эволюционный подход с течением времени. По общему признанию, это не роскошь, которая всегда возможна в стартапах.
Управление качеством
Еще одна серьезная ошибка заключается в том, что вы не рассматриваете управление качеством данных на ранней стадии (отсюда и эта статья). Встраивание этого является абсолютно ключевым для развития интеллектуальной собственности для важных данных, а также для выпуска продукции хорошего качества.
Основные архитектурные сдвиги — переход на бессерверные решения
Предполагать, что только потому, что вы «хорошо это знаете», это подходит и просто для других людей в команде... это ошибка. Переход к серьезному архитектурному сдвигу, такому как Serverless, — это большой скачок даже для опытной команды. Считать, что с этим справится неопытная команда, — выдавать желаемое за действительное. Опять же, либо необходимо получить много опытной поддержки, либо использовать постепенный подход к развитию решения для этой архитектуры. Переход на бессерверные технологии, как и переход на микросервисы, был популярен, плохо применялся во многих сценариях и был неправильно понят. Убедитесь, что это подходит для вашего сценария. Ни один подход не идеален…
Понимание показателей качества
Итак, чтобы начать здесь, нужно сначала понять типы проблем, которые могут возникнуть. Это то, что вам нужно сделать как команде разработчиков, — записать требования к обработке данных и качеству ДЛЯ КАЖДОГО ИСТОЧНИКА ДАННЫХ. Они должны быть отображены в вашем конвейере. Чем раньше вы это сделаете, тем лучше вы сможете снизить количество ошибок.
Это определит вашу стратегию.
Сопоставление требований целостности данных
Это должно быть определено для конкретного варианта использования и сценария, однако я перечислил некоторые из возможных проблем с качеством данных, с которыми вы, вероятно, столкнетесь, и как подойти к каждой области.
Ложные срабатывания
Теперь это довольно распространенный сценарий в кибербезопасности, когда вы сканируете уязвимости, и на рынке есть ряд инструментов для сканирования для этого. Однако это также сценарий машинного обучения. Чтобы устранить их (или уменьшить их), вам необходимо убедиться, что они правильно определены. Просмотрите свой набор данных, чтобы определить, имеет ли место смещение или дрейф, удалите все правила, которые вам не нужны, и настройте правила для любых конкретных пороговых значений среды.
Отсутствующие поля
Эти поля отсутствуют в слое потребления? Или из-за того, что вы извлекли записи данных из API, в котором либо плохие записи данных, либо добавлены новые поля? Одно можно сказать наверняка: у вас должна быть определенная схема данных и понимание того, какие запросы вам нужно выполнять.
Недостающие данные
Не все записи данных согласованы, что делать, если поля просто отсутствуют? Как это будет обрабатываться в вашем решении для потребления данных? Как проверить наличие отсутствующих записей данных?
Многозначность
Данные, которые извлекаются из API, часто приходится извлекать всю запись данных, а затем устранять неоднозначность полей данных, требуемых из исходного источника необработанных данных. Это часто может также нуждаться в преобразовании. Вам нужно будет убедиться, что все данные, которые извлекаются и преобразуются, имеют один и тот же тип данных после преобразования.
Поврежденные данные
SQL имеет встроенные инструменты для проверки поврежденных файлов, на рынке есть и другие специальные наборы инструментов для автоматизации оценки данных, однако часто может потребоваться ручная проверка качества. Мониторинг
Преобразование данных
Такие решения, как AWS Glue, идеально подходят для преобразования больших объемов данных, однако для небольших объемов, не требующих масштабирования, можно запускать сценарии на Python и использовать фреймы данных. Для корпоративных рабочих нагрузок вам потребуются такие инструменты, как Glue.
Неверный тип данных
Это настолько элементарно, что команды на ранних стадиях ошибаются. Крайне важно, чтобы ваша схема данных была задокументирована, ваши запросы были задокументированы, а ваши инженерные группы оценили языки и платформы, используемые для обеспечения эффективности этих запросов. Типы данных сильно различаются между языками программирования, некоторые из них являются гибкими и позволяют использовать данные, даже если это неправильный «тип».
Повторение
Опять же, здесь вы можете запустить инструменты для обнаружения повторяющихся записей данных. В самом простом случае выполняются сценарии для выявления возможного повторения в наборах данных, а также для ручной проверки и удаления дубликатов.
Метаданные
Вам нужно будет иметь возможность запрашивать свои данные, а для этого вам необходимо формализовать уровень управления данными. Этому способствуют такие решения AWS, как Lake Formation и AWS Glue Data Catalog.
Управление данными
Управление данными означает установление внутренних стандартов — политик данных, — которые применяются к тому, как данные собираются, хранятся, обрабатываются и удаляются. Он определяет, кто может получить доступ к каким видам данных и какие виды данных находятся под управлением. Важно не только понимать, как использовать такие инструменты, как Glue Data Catalogue, но и иметь задокументированные подходы к сбору, хранению и обработке данных, а также обеспечить понимание этого бизнес-персоналом и техническим персоналом. Вам нужно будет определить это для каждого источника данных, типа данных и решения для хранения/потребления.
Краткое руководство по управлению данными от AWS здесь:
https://aws.amazon.com/what-is/data-governance/
Инструменты для управления качеством данных
Для бизнес-предложений на ранней стадии MVP реально многое можно сделать с помощью сценариев Python, лямбда-выражений, пошаговых функций и фреймов данных. Однако, как только вы начнете масштабироваться, они будут очень ограничительными, и вам нужно будет нанять архитектора и начать рассматривать инструменты в своей технологической дорожной карте.
Большой список библиотек Python с качеством данных с открытым исходным кодом можно найти здесь:
Если у вас ранняя стадия бизнеса, MVP или что-то подобное, я бы порекомендовал начать именно с этого.
Однако, как только вы начнете масштабироваться, вам потребуются промышленные инструменты. Для больших данных вы можете рассмотреть такие решения, как Apache Griffin или AWS Deequ (который поддерживает Apache Spark, если вы хотите обрабатывать корпоративные данные). Однако теперь это было заменено Glue Data Quality.
https://docs.aws.amazon.com/glue/latest/ug/gs-data-quality-chapter.html
Другие инструменты, о которых стоит подумать…
Масштаб предприятия и целостность данных
Для компаний на ранней стадии с ограниченным предложением качество данных так же важно, как и для организаций на более поздних стадиях. Но по мере масштабирования вашего бизнеса до корпоративного уровня вам необходимо начать учитывать целостность данных во всех ваших бизнес-функциях.
Так…. что мы подразумеваем под целостностью данных?
«Целостность данных — это общая точность, полнота и непротиворечивость данных. Целостность данных также относится к безопасности данных в отношении соблюдения нормативных требований, таких как соответствие GDPR, и безопасности. Он поддерживается набором процессов, правил и стандартов, реализованных на этапе проектирования».
Существует ряд линз, которые необходимо применять, чтобы ваши данные были и оставались полными, точными и надежными.
Физическая целостность
Как ваши данные хранятся, управляются и извлекаются? Если ваш центр обработки данных выйдет из строя, если в вашем здании отключится электричество (если у вас есть какие-либо частные сетевые серверы на месте), если выйдет из строя дисковый накопитель. Или, если кто-то просто сошел с ума и каким-то образом удалит или скомпрометирует ваши данные… каковы ваши механизмы для решения этой проблемы?
Контракты и бизнес/киберстрахование на случай отключения сети и центра обработки данных. Обучение и процедуры для персонала для обеспечения безопасности и минимизации основных человеческих ошибок. Процедуры эскалации, если что-то пойдет не так. Кто несет ответственность, как вы будете это решать? Задокументируйте возможные сценарии и устраняйте риски один за другим.
Логическая целостность
Логическая целостность также защищает данные от человеческих ошибок и хакеров, но совершенно иначе, чем физическая целостность.
- Целостность объекта – основывается на создании первичных ключей, чтобы гарантировать, что данные не будут перечислены более одного раза и что ни одно поле в таблице не будет пустым.
- Ссылочная целостность. Ссылочная целостность относится к серии процессов, обеспечивающих единообразное хранение и использование данных. Правила могут быть встроены в вашу БД и, например: могут включать ограничения, которые устраняют такие вещи, как ввод повторяющихся данных, гарантируют точность ввода данных и/или запрещают ввод данных, которые не применяются.
- Целостность домена. Целостность домена — это совокупность процессов, обеспечивающих точность каждой части данных в домене. Так, например: применение ограничений и других мер, которые ограничивают формат, тип и объем вводимых данных.
- Целостность, определяемая пользователем. Определяемая пользователем целостность включает в себя правила и ограничения, созданные пользователем в соответствии с его конкретными потребностями. Это может быть включение конкретных бизнес-правил, которые необходимо учитывать и включать в меры по обеспечению целостности данных.
Чем не является целостность данных
Это часто путают с безопасностью данных и качеством данных, однако каждый термин имеет свое значение.
Целостность данных — это не безопасность данных
Безопасность данных — это совокупность мер, политик, решений и процедур, гарантирующих, что данные не будут повреждены или использованы для злонамеренного использования.
Целостность данных — это не качество данных
Соответствуют ли данные в вашей базе данных установленным компанией стандартам и потребностям вашего бизнеса? Качество данных отвечает этому и должно соответствовать вашему предложению продукта.
Целостность данных и соответствие требованиям
Целостность данных является ключом к соблюдению правил защиты данных (например, GDPR). В связи с увеличением количества нормативных требований на рынках важно иметь внутреннюю карту всех требований соответствия, уровней риска и подходов к аудиту, а также обеспечивать постоянное соблюдение требований. Целостность ваших данных является ключом к этому подходу.
Заключение
Каждая из этих областей заслуживает отдельной статьи. Если вы не знаете, с чего начать с анализа данных или машинного обучения, я надеюсь, что это был полезный старт для десяти. Как технический директор-консультант, я чаще всего вижу, что техническое лидерство постоянно терпит неудачу, не учитывая контекст, поскольку большинство технических лидеров в основном были бывшими разработчиками программного обеспечения, а роль технического директора действительно становится бизнес-ролью, как только вы масштабируетесь. Отсутствие базовых навыков реализации проектов/программ и знаний об архитектуре усугубляет эту проблему для многих инженеров-руководителей.
Тем не менее, основа всех хороших инженерных разработок заключается в том, чтобы сначала прибить основы и убедиться, что они надежны и последовательны.
Если это ваша первая попытка масштабирования, я могу честно сказать, что это искусство, основанное на опыте. Тот, который вы со временем улучшите. Так вот мои наилучшие пожелания и удачи.
