Два в коробке (если можно) и все в документации (всегда).
В ИТ-контексте «два в коробке» означают два сервера или компонента, которые предназначены для совместной работы, обеспечивая избыточность и повышенную надежность. Эта настройка может гарантировать, что в случае отказа одного компонента другой возьмет на себя его работу, тем самым поддерживая непрерывность обслуживания. Цель «два в одном» — обеспечить высокую доступность и аварийное восстановление. Это также относится к человеческим ролям в организации; однако это редко реализуется.
Давайте рассмотрим соответствующий пример Google Analytics. Мы все, вероятно, знаем человека в нашей компании или организации по имени, к которому обращаются за аналитикой. Это те, чьи отчеты или информационные панели названы в их честь — «Отчет Майка» или «Информационная панель Джейн». Конечно, есть и другие люди, которые разбираются в аналитике, но это настоящие чемпионы, которые, кажется, знают, как выполнить самые сложные задачи и уложиться в сроки. Проблема в том, что эти люди одиноки. Во многих случаях под давлением они ни с кем не работают, так как это может их замедлить, и именно здесь начинаются проблемы. Мы никогда не думаем, что потеряем этого человека. Я воздержусь от типичного «скажем, их сбил автобус» или приведу пример, использующий текущие возможности на рынке труда, и скажу что-то положительное, например «они выиграли в лотерею!», потому что мы все должны внести свой вклад, чтобы быть позитивными. в эти дни.
История
Наступает утро понедельника, и наш эксперт по аналитике и чемпион MJ подает заявление об отставке. MJ выиграл в лотерею и уже покинул страну без забот в мире. Команда и люди, которые знают MJ, взволнованы и завидуют, но работа должна продолжаться. Теперь ценность и реальность того, что делал MJ, должны быть поняты. MJ отвечал за окончательную публикацию и проверку аналитики. Казалось, что они всегда могли повысить эффективность или внести трудное изменение, прежде чем предоставлять аналитику всем. Никто на самом деле не заботился о том, как это было сделано, и был уверен в том, что это только что произошло, а MJ был индивидуальной рок-звездой Analytics, поэтому ему был предоставлен определенный уровень автономии. Теперь, когда команда начинает собирать по частям, запросы, ежедневные проблемы, запросы на модификации, они в растерянности и начинают карабкаться. Отчеты/панели мониторинга находятся в неизвестном состоянии; некоторые активы не обновлялись в выходные, и мы не знаем, почему; люди спрашивают, что происходит и когда что-то будет исправлено, правки, которые, по словам MJ, были сделаны, не отображаются, и мы понятия не имеем, почему. Команда выглядит плохо. Это катастрофа, и теперь мы все ненавидим MJ.
Уроки
Есть несколько простых и очевидных выводов.
- Никогда не позволяйте человеку работать в одиночку. Звучит неплохо, но в небольших agile-командах у нас нет ни времени, ни людей, чтобы реализовать это. Люди приходят и уходят, задач много, так что разделяй и властвуй во имя продуктивности.
- Каждый должен делиться своими знаниями. Тоже звучит хорошо, но делимся ли мы с нужным человеком или людьми? Имейте в виду, что многие победители лотереи являются коллегами. Проведение сессий по обмену знаниями также отнимает время от задач, и большинство людей инвестируют в навыки и знания только тогда, когда это необходимо.
Итак, какие есть реальные решения, которые каждый может внедрить и отстоять?
Начнем с управления конфигурациями. Мы будем использовать это как общий термин для нескольких похожих тем.
- Управление изменениями: Процесс планирования, внедрения и контроля изменений в программных системах структурированным и систематическим образом. Этот процесс направлен на то, чтобы изменения вносились контролируемым и эффективным образом (с возможностью отмены) с минимальным нарушением существующей системы и максимальной выгодой для организации.
- Управление Проектом: Планирование, организация и контроль проектов разработки программного обеспечения для обеспечения их своевременного завершения в рамках бюджета и в соответствии с желаемыми стандартами качества. Он включает в себя координацию ресурсов, действий и задач на протяжении всего жизненного цикла разработки программного обеспечения для достижения целей проекта и выпуска программного продукта в соответствии с графиком.
- Непрерывная интеграция и непрерывная доставка (CI/CD): Процесс автоматизации создания, тестирования и развертывания программного обеспечения. Непрерывная интеграция требует регулярного объединения изменений кода в общий репозиторий и выполнения автоматических тестов для обнаружения ошибок на ранних этапах процесса разработки. Непрерывная доставка/развертывание включает в себя автоматический выпуск протестированных и проверенных изменений кода в рабочую среду, что позволяет быстро и часто выпускать новые функции и улучшения.
- Контроль версий: Процесс управления изменениями исходного кода и других программных артефактов с течением времени с помощью специализированных программных инструментов. Это позволяет разработчикам совместно работать над кодовой базой, вести полную историю изменений и экспериментировать с новыми функциями, не затрагивая основную кодовую базу.
Все вышеперечисленное относится к хорошей практике разработки программного обеспечения. Аналитика, которая управляет бизнесом, заслуживает не меньшего, поскольку она имеет решающее значение для принятия решений. Все аналитические активы (задания ETL, семантические определения, определения метрик, отчеты, информационные панели, истории и т. д.) — это просто фрагменты кода с визуальным интерфейсом для проектирования, и, казалось бы, незначительные изменения могут вызвать хаос в работе.
Использование управления конфигурацией помогает нам поддерживать работу в хорошем состоянии. Активы имеют версии, поэтому мы можем видеть, что произошло за время их существования, мы знаем, кто над чем работает, а также о достигнутом прогрессе и сроках, и мы знаем, что производство будет продолжаться. Что не охвачено никаким чистым процессом, так это передача знаний и понимание того, почему вещи такие, какие они есть.
У каждой системы, базы данных и инструмента аналитики есть свои особенности. Вещи, которые заставляют их двигаться быстрее или медленнее, предметы, которые заставляют их вести себя определенным образом или приносят желаемый результат. Это могут быть настройки на системном или глобальном уровне или вещи в дизайне активов, которые заставляют их работать так, как должны. Проблема в том, что большинство из этих вещей узнаются со временем, и не всегда есть место для их документирования. Даже когда мы переходим на облачные системы, где мы больше не контролируем, как выполняется приложение, и мы полагаемся на поставщика, чтобы сделать его как можно быстрее, настройка определений продолжается в наших активах, чтобы открыть именно то, что мы ищем. Это знание необходимо зафиксировать и поделиться им, сделав его доступным для других. Эти знания должны быть необходимы как часть документации активов и должны стать неотъемлемой частью контроля версий и проверки CI / CD и процесса утверждения, а в некоторых случаях даже как часть контрольного списка перед публикацией того, что нужно делать, а что нет. делать.
Нет волшебных ответов или искусственного интеллекта, чтобы скрыть ярлыки в наших аналитических процессах или их отсутствие. Независимо от размера команды, которая поддерживает поток данных и аналитики, инвестиции в систему для отслеживания изменений, версий всех активов и помощи в документировании процесса разработки и накоплении знаний являются обязательными. Инвестиции в процессы и время заранее сэкономят массу потраченного времени позже на выяснение вещей, чтобы поддерживать здоровое состояние нашей аналитики. Всякое случается, и лучше всего иметь страховой полис для MJ и других победителей лотереи.
