Перехід з Amazon SES на YourTrend

Як перейти з Amazon SES на YourTrend

Перенесення поштової інфраструктури — це не дизайнерська вправа. Це послідовність перевірок, замін і терплячого тестування. Якщо ви шукаєте, як перейти з Amazon SES на YourTrend, почніть із тих компонентів, які реально надсилають листи, бо все інше може почекати ще день; саме так проходить практична міграція з Amazon SES на YourTrend.

Amazon SES часто використовується в більшій кількості місць, ніж команди пам’ятають. Один застосунок може напряму викликати API, інший — використовувати SMTP, а третій — надсилати повідомлення з фонової задачі, яку ніхто не відкривав місяцями. Саме це й потрібно мапувати першим.

1. Підтвердьте обсяг міграції SES для поштової інфраструктури

Складіть технічний інвентар, перш ніж щось змінювати. Перелічіть кожен домен для надсилання, верифіковану ідентичність, SMTP-облікові дані, API-ключ, шаблон, правило для відмов, правило для скарг і шлях у коді, який викликає SES. Якщо список неточний, міграція теж буде неточною.

Тримайте обсяг конкретним. Запишіть, які продуктові області надсилають транзакційні листи, які — скидання пароля, які — рахунки, а які — внутрішні сповіщення. Один застосунок може приховувати шість поштових потоків, і кожен із них може зламатися по-різному, якщо припустити, що всі вони однакові.

Відстежуйте ті можливості SES, які ви справді використовуєте, а не ті, що колись сподобалися вам у демо. Одній команді може бути потрібне лише базове надсилання та журнали подій. Іншій — обробка suppression, кастомний MAIL FROM або регіональні endpoint-и. Тут допомагають цифри: порахуйте ідентичності, шаблони, застосунки, cron-задачі. Три підрахунки кращі за одну здогадку.

Не поспішайте з цим кроком. Пропущений вебхук або стара тестова поштова скринька можуть створити тиху відмову, яка проявиться лише після перемикання. Тихі збої — найгірші.

2. Вирішіть, які можливості Amazon SES потрібно замінити першими

Не кожну функцію SES потрібно замінювати в перший день. Деяким командам спочатку потрібен лише шлях надсилання, тоді як обробка відмов і скарг може ще короткий час залишатися в SES. Це рішення має бути явним, а не випадковим.

Почніть із найвужчого аналізу розривів. З’ясуйте, які функції SES блокують виробниче використання YourTrend, які можна поставити на паузу на 7 днів, а які мають лишатися активними, доки не буде перенесено останній застосунок. Саме тут міграція стає практичною, а не абстрактною.

Немає призу за одночасне перенесення всього. Якщо YourTrend спочатку оброблятиме транзакційні листи, а вже потім маркетингові, так і скажіть. Якщо SES залишиться для однієї застарілої системи, поки решта перейде, задокументуйте цей виняток і вкажіть дату.

Не забувайте про ризики. Скидання пароля, яке не працює 10 хвилин, одразу б’є по користувачах. Щотижневий дайджест, що затримався на одну годину, — ні. Ця різниця важлива, і саме вона має визначати порядок міграції.

3. Співставте потоки надсилання SES із точками входу YourTrend

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

По черзі зіставте скидання пароля, чеки, повідомлення про доставку, сповіщення про обліковий запис і подальші звернення до підтримки. Якщо повідомлення генерується подією в застосунку, визначте точну подію. Якщо повідомлення генерується cron-задачею, визначте точний графік. Якщо повідомлення надсилається вручну з адмін-панелі, занотуйте й це.

Для команд, які вже покладаються на подієве надсилання листів, структура важить не менше за контент. YourTrend має отримувати той самий сигнал, який раніше отримував SES, навіть якщо транспорт зміниться. Якщо вам потрібна відправна точка для проєктування подій, дивіться події вебхука електронної пошти.

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

Невелика примітка: команди часто виявляють, що “простий” шлях надсилання ніколи не був простим. Одне підтвердження замовлення може звертатися до сервісу ціноутворення, сервісу виконання замовлень і мовного сервісу ще до того, як потрапить до SES. Це нормально. Просто запишіть це.

4. Переналаштуйте автентифікацію та DNS для нового відправника

Перш ніж живі листи будуть переміщені, переналаштуйте записи домену, які підтверджують, що YourTrend має право надсилати від вашого імені. Зазвичай це SPF, DKIM і будь-які DNS-записи, пов’язані з трекінгом, які вимагає YourTrend; окремо перевірте налаштування SPF DKIM для YourTrend, щоб не створити паузу в доставці. Старі записи SES мають залишатися чинними, доки YourTrend не буде повністю верифіковано.

Якщо домен для надсилання спільний для кількох продуктів, будьте обережні. Одна невдала зміна DNS може вплинути на кілька поштових потоків одночасно. Зробіть записи точними, підтвердьте назви селекторів і перевірте, що значення TXT збігаються зі значеннями в обліковому записі YourTrend.

Якщо вам потрібне глибше нагадування про структуру автентифікації, перегляньте DKIM SPF DMARC що. Ця тема особливо актуальна, коли SES і YourTrend перетинаються в одному вікні перемикання.

Пам’ятайте, що поширення DNS — це не одноразова подія. Це може зайняти час, і цей час входить до плану міграції. Якщо можете, тестуйте з кількох мереж. Однієї перевірки недостатньо. Дві — краще. П’ять — безпечніше.

Зберігайте слід перевірок. Право власності на домен, узгодженість DKIM і будь-яке налаштування домену для відмов мають бути зафіксовані до перемикання надсилання. Якщо хтось запитає, чому змінилися записи, відповідь має бути в одному документі, а не розкиданою по тредах у Slack.

5. Оновіть код застосунку або налаштування інтеграції

Тепер замініть специфічні для SES параметри підключення на налаштування YourTrend. Це може означати нові API-ключі, інший SMTP hostname, інші облікові дані або нові виклики SDK. Зробіть спочатку найменшу безпечну зміну, а потім протестуйте.

Регіональні endpoint-и SES можуть ховатися в більшій кількості місць, ніж очікується. Перевірте файли конфігурації, змінні середовища, деплой-скрипти та CI-налаштування. Також перевірте кодову базу. Забутий endpoint у staging-задачі може пізніше створити плутанину, особливо якщо продакшн виглядає нормально.

Якщо ваш застосунок використовує SMTP, перед перемиканням трафіку підтвердьте налаштування relay і ліміти розміру повідомлень. Якщо використовується прямий API, підтвердьте повторні спроби та обробку помилок. Для команд, які хочуть практичну базу, цей гайд пояснює що означає SMTP relay для node.js.

Розгорніть нову інтеграцію контрольованим шляхом. Почніть із staging, потім із невеликої внутрішньої скриньки, потім із малозначущого транзакційного повідомлення, і лише після цього — з повним потоком. Така послідовність зменшує несподіванки. Вона також дає вашій команді реальний лог слід, а це цінніше за довгу нараду.

Тримайте старі облікові дані SES активними, доки не будете певні, що жоден виробничий шлях від них не залежить. Коли їх буде видалено, приховані задачі почнуть падати голосно. Це краще, ніж тихі збої, але все одно неприємно.

6. Перебудуйте шаблони та змінні повідомлень у YourTrend

Шаблони SES не завжди легко переносяться в іншу систему. Перебудуйте шар шаблонів у YourTrend, а не вставляйте старий контент бездумно. Логіка теми, назви плейсхолдерів, умовні блоки та форматування можуть поводитися інакше.

Почніть із шаблонів із найбільшим обсягом. Скидання пароля. Чек. Оновлення про доставку. Саме ці три зазвичай виявляють найбільше проблем із відображенням, бо залежать від змінних, часових позначок або короткого динамічного тексту. Перевірте вигляд на десктопі та мобільному. Потім перевірте ще раз у plain text.

Зберігайте бізнес-контент, а не старий синтаксис. Якщо в SES використовувався один формат плейсхолдера, а в YourTrend — інший, ретельно зіставте кожну змінну. Одного відсутнього номера замовлення достатньо, щоб з’явився запит у підтримку.

Поки ви тут, перегляньте довжину тексту та перенесення рядків. Шаблон, який виглядав охайно в SES, після міграції може переноситися незручно. Це не косметика, якщо код або посилання зміщується нижче першого екрану. Невеликі зміни можуть створювати великий шум у підтримці.

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

7. Перевірте доставку, відмови та обробку подій після перемикання

Після перенесення трафіку уважно стежте за першими 24 годинами. Відправляйте тести на реальні поштові провайдери, а не лише на внутрішні акаунти. Перевіряйте логи, message ID, часові позначки та callback-и подій. Спочатку шукайте одну річ: чи доставляє YourTrend ті самі повідомлення, які раніше доставляв SES?

Потім перевірте обробку відмов. Hard bounce, soft bounce, скарги та відкладені доставки мають потрапляти туди, куди ваша команда очікує. Якщо ні — виправте це негайно. Зламаний шлях для відмов створює другу проблему поверх першої.

Моніторинг подій тут дуже важливий. Підтвердження доставки, відкриття, якщо ви їх відстежуєте, і події з помилками мають бути достатньо видимими для роботи операційної команди. Якщо потрібен сфокусований гайд, читайте обробка bounce повідомлень email. Виправити обробку подій у перший день простіше, ніж на 14-й.

Перевірте й нетипові випадки. Надішліть на невалідну скриньку. Надішліть на домен із відомою чутливістю до фільтрів. Надішліть лист із довгою темою й ще один — із короткою. Такі тести показують, чи змінила міграція поведінку там, де щасливий сценарій цього ніколи не покаже.

Тримайте короткий список перевірок: 1) повідомлення отримано, 2) заголовки коректні, 3) подію відмови записано, 4) шлях скарги видимий, 5) поведінка повторних спроб прийнятна. П’яти перевірок достатньо, щоб виявити більшість помилок міграції до того, як це зроблять клієнти.

8. Безпечно виведіть Amazon SES з експлуатації

Не вимикайте SES у момент, коли YourTrend надішле свій перший лист. Зачекайте, доки новий шлях буде перевірено на реальному трафіку, а ваша команда підтвердить, що жоден активний процес досі не вказує на SES. Поспішне вимкнення може перетворити вирішену міграцію на новий простій.

Спочатку видаліть невикористовувані облікові дані SES. Потім виведіть зі строю старі посилання в застосунках. І лише після цього очищайте DNS-записи, що належали SES, і навіть тоді — тільки коли ви впевнені, що жоден крок верифікації ще від них не залежить. Порядок має значення.

Документуйте новий виробничий шлях. Вкажіть відправника, домен, спосіб інтеграції, власника шаблонів і людину, яка може змінювати облікові дані. Цей документ допомагає під час змін у команді, аудитів і наступного інциденту. Він також економить час, коли хтось знову питає, як перейти з Amazon SES на YourTrend.

Ще одна перевірка може врятувати від хаосу: знайдіть SES у файлах деплою, змінних середовища та внутрішніх wiki-сторінках. Залишені облікові дані — це не дрібниця. Це майбутній сюрприз.

Якщо ваша команда зберігає логіку suppression або відписки поза поштовою платформою, переконайтеся, що ці списки теж переїхали. Старі записи не мають зависати в невизначеності. Якщо потрібне окреме посилання, дивіться що таке список виключення електронної пошти і чому важливі найкращі практики email unsubscribe.