5 основных проблем в процессе разработки продуктов для инфраструктуры электронной почты

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

В связи с этим, по оценкам Radicati Group Inc., общее количество отправленных электронных писем приблизится к 400 миллиардам в 2027 году. Ожидается, что число пользователей во всем мире достигнет 5 миллиардов в том же году.

Поскольку объем почтового трафика продолжает расти, трудно отрицать важность надежной и надежной инфраструктуры электронной почты.

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

1: Масштабируемость

Соревнование

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

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

• Потеря производительности
• Снижение удовлетворенности клиентов
• Возможные финансовые потери
• Падение рейтинга авторитетности домена
• Сбросить репутацию отправителя

Решения:

• Облачная инфраструктура
• Балансировка нагрузки

Использование облачной инфраструктуры

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

Звучит многообещающе, но как это работает на самом деле?

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

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

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

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

Реализация балансировки нагрузки

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

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

Поскольку рабочие нагрузки распределяются между несколькими серверами, объем почтового трафика не ограничивает ни один отдельный сервер. Таким образом, вероятность перебоев в обслуживании и узких мест значительно ниже.

Более того, алгоритмы балансировки нагрузки можно использовать для динамической настройки распределения рабочих нагрузок, как правило, на основе двух факторов:

1. Количество запросов.
2. Вычислительная мощность каждого сервера.

Строительство адской платформы для размещения

Еще в 2012 году процесс разработки продуктов Airbnb находился на ключевом этапе.

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

Airbnb оказался перед рискованным выбором: нанять более 1000 человек в течение года или создать автоматизированную структуру для обработки крайних случаев.

Да, они выбрали второе.

Джонатану Голдену, менеджеру по продукту Airbnb в то время, пришлось безжалостно расставлять приоритеты. Основная цель состояла в том, чтобы создать план автоматизированного облачного решения (бэкенд-фреймворк), которое будет обрабатывать и классифицировать крайние случаи.

Имея структуру, Airbnb быстро разблокировали и продолжили масштабировать от 300% до 600% в год. Обратите внимание, что эти проценты относятся к раннему экспоненциальному росту Airbnb.

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

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

2: Безопасность

Соревнование

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

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

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

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

Решения:

• Шифрование
• Безопасные протоколы
• Регулярные обновления мер безопасности

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

Как?

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

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

Ранее мы упоминали SSL и TLS, которые шифруют движущиеся данные (данные в пути). Но компаниям также необходимо рассмотреть вопрос о шифровании данных в состоянии покоя и установить разные уровни доступа к этим данным.

«Пинки, обещай, мы тебя не взломаем!»

Это несколько негативное экономическое обоснование, но оно ясно показывает, что всегда есть два аспекта безопасности — программное обеспечение и люди.

В январе 2023 года в Mailchimp произошло нарушение безопасности (третье за ​​12 месяцев), в результате чего были раскрыты конфиденциальные данные 133 клиентов. А социальная инженерия была стратегией, которую мошенники использовали для получения доступа к конфиденциальной информации.

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

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

3: Надежность

Соревнование

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

Почему?

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

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

Решение:

• Внедрение систем резервирования и резервирования
• Регулярный мониторинг инфраструктуры

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

Затем регулярный мониторинг инфраструктуры предоставляет метрики, которые позволяют разработчикам обнаруживать и устранять проблемы до того, как они станут реальными проблемами. Это можно сделать с помощью инструментов мониторинга и регулярных проверок системы. Или, иногда, команды разработчиков могут применять SWOT-анализ во время тестирования концепции, чтобы определить наилучшие подходы.

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

1. Если процессы начинают потреблять больше памяти.
2. Если есть определенные проблемы с обработкой/вычислениями данных.
3. В случае 500 кодов ответов.

Эти аварийные сигналы относятся к внутренней поддержке архитектуры и оперативному управлению продуктами; оба из них должны быть установлены в процессе разработки программного обеспечения или при запуске программного продукта.

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

Как это сделали гиганты

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

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

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

4: Совместимость

Соревнование

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

Как правило, интеграция должна включать:

1. Управление взаимоотношениями с клиентами (CRM)
2. Планирование ресурсов предприятия (ERP)
3. Хранилище данных

Какая польза?

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

Сразу отметим, что этот аспект следует учитывать при мозговом штурме концепции продукта. И стоит сопоставить варианты интеграции с тем, что доступно на целевом рынке.

Решение:

• Открытые стандарты
• Кроссплатформенная совместимость

Открытые стандарты — это общедоступные спецификации, которые позволяют различным системам работать вместе.

Ключевые открытые стандарты для инфраструктуры электронной почты включают в себя простой протокол передачи почты (SMTP), почтовый протокол версии 3 (POP3) и протокол доступа к сообщениям в Интернете (IMAP).

Что касается совместимости, инфраструктура электронной почты должна быть разработана для работы с различными операционными системами (Windows, macOS и Linux), а также с различными веб-браузерами (Google Chrome, Mozilla Firefox, Safari и т. д.).

Однако внедрение открытых стандартов и обеспечение кросс-платформенной совместимости не обходится без проблем. Возьмем, к примеру, SMTP, разработчикам часто приходится вносить в него определенные коррективы и, возможно, даже добавлять шифрование. Чтобы легко добиться этого и других исправлений для конкретных продуктов, рекомендуется использовать взаимосвязанные платформы, такие как AWS.

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

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

Отрежь нам немного Slack

Если вы считаете, что Slack удалось заново изобрести то, как мы сотрудничаем, вы не ошибетесь. Но вопрос в том, как они это сделали.

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

Во-первых, планка входа в Slack очень низкая. Тем не менее, он охватывает большинство случаев использования, которые вы можете себе представить. Затем перенести ваши команды в Slack довольно просто. Управление пользователями не вызывает затруднений, а список интеграций можно продолжать и продолжать…

В зависимости от размера и масштаба вашего бизнеса вы можете подключить Jira, Notion, Coda, приложения Google и многое другое, чтобы иметь все уведомления и каналы данных под одной крышей. И все это в течение нескольких дней или даже часов.

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

5: Управление ожиданиями в отношении производительности

Соревнование

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

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

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

• Легко использовать
• Доступ с нескольких устройств
• Уметь обрабатывать трафик электронной почты в масштабе

Решение:

• Тестирование
• Оптимизация
• Четкое общение
• Петли обратной связи

Рискуя констатировать очевидное, регулярное тестирование и оптимизация должны быть неотъемлемой частью любого процесса разработки продукта. Это может включать проведение опросов, фокус-групп, A/B-тестирование для сбора отзывов пользователей и т. д.

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

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

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

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

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

Битва гигантов

Как упоминалось ранее, в этом разделе рассматриваются области, в которых Microsoft, возможно, не оправдала ожиданий по производительности, уступив место конкурентам. В этом есть небольшая история, связанная как с Apple, так и с Google.

К моменту выпуска MPP (Защита конфиденциальности почты) в сентябре 2021 года Apple уже обогнала Google по доле рынка почтовых клиентов. В то время доля Apple была близка к 59 %, доля Google — около 28 %, а доля Microsoft Outlook значительно отставала — около 5 %.

Теперь, каковы могут быть причины, по которым Microsoft потерпела поражение?

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

Google запустил Gmail 1 апреля, почти два десятилетия назад. И Microsoft не потребовалось много времени, чтобы понять, что это не первоапрельская шутка. Отец Windows прилагал все усилия, чтобы оставаться доминирующим в течение десяти лет. Но как только Gmail захватил рынок в 2015 году, Outlook по большей части пошел по нисходящей спирали.

Но почему?

Можно с уверенностью утверждать, что причинами являются неудовлетворительные ожидания производительности. По сути, Gmail был быстрее и проще в использовании, а также предлагал гораздо более оптимизированный интерфейс. В сочетании с большим количеством функций и гораздо большим объемом памяти (1 ГБ — в 500 раз больше, чем у Outlook того времени), неудивительно, что Gmail победил.

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

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

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

Создавайте хорошие продукты

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

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

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