Migracja platformy pocztowej nie została ukończona, gdy do skrzynki odbiorczej administratora dotarła wiadomość testowa. Aplikacja musi jeszcze stworzyć odpowiednie zgłoszenie, przesłać je zamierzoną trasą, obsłużyć awarie i dotrzeć do wymaganych odbiorców. Zbuduj plan przejścia wokół tych wyników, tak aby ważne wiadomości nie znikały pomiędzy zespołami zajmującymi się aplikacjami i pocztą.
Spisuj każdą zależność powiadomienia
Zapisz zadanie aplikacji, wyzwalacz, harmonogram, odbiorców, krytyczność, właściciela, punkt końcowy, metodę uwierzytelniania, tożsamość nadawców, kolejkę ponownych prób i miejsce docelowe przetwarzania zwrotów. Uwzględnij dostęp do sieci, certyfikaty, referencje poświadczeń i zależności DNS bez kopiowania sekretów. Odróżnij generowanie poczty od transportu poczty; zatrzymanego harmonogramu nie można naprawić poprzez zmianę SPF.
Metody dostawców są różne. Dokumenty firmy Microsoft uwierzytelnione przesyłanie przez klienta, przekazywanie SMTP i bezpośrednie wysyłanie to odrębne opcje z różnymi wymaganiami wstępnymi i zakresem odbiorców. Wskazówki dotyczące poczty aplikacji firmy Microsoft. Wybierz aktualnie obsługiwaną trasę zgodnie z rzeczywistymi możliwościami aplikacji i wymaganiami dotyczącymi miejsca docelowego. Nie zakładaj, że licencja skrzynki pocztowej lub aktualizacja MX powoduje migrację konfiguracji przesyłania.
Projektuj współistnienie bez dublowania stanowisk pracy
Dla każdej zależności podaj nazwę starej i nowej trasy, kto może ją przełączyć i jak ją przywrócić. Zdecyduj, który harmonogram jest autorytatywny podczas współistnienia. Zachowanie starej trasy do przywrócenia nie oznacza, że oba programy planujące powinny emitować to samo powiadomienie. Użyj identyfikatora zdarzenia na poziomie aplikacji, aby uzgodnić próby, jeśli aplikacja go obsługuje, mając jednocześnie świadomość, że sam identyfikator nie gwarantuje deduplikacji SMTP .
Utrzymuj uprawnienia równoległe o wąskim zakresie i czasie. Nowa trasa wymaga zamierzonej uwierzytelnionej i dopasowanej tożsamości, a nie po prostu podpisu dowolnego dostawcy. RFC 9989. Zachowaj niezbędne klucze do podpisu i selektor dostępność wiadomości w dalszym ciągu przesyłanych w ramach planu emerytalnego.
Sprawdź zduplikowane próby i niekompletne ślady
Załóżmy, że zdarzenie otrzymania ma dwie próby przesłania podczas współistnienia, podczas gdy inne otrzymane powiadomienie nie ma odpowiedniego rekordu wyzwalacza aplikacji. Pierwszy wymaga planowania i ponownego sprawdzenia; dwie próby nie dowodzą dwóch dostarczonych wiadomości. Drugie wymaga rekonstrukcji śledzenia lub wyraźnej luki w rejestrowaniu, a nie wymyślonego zdarzenia aplikacji. Przed wybraniem działań naprawczych skoreluj trasę, znaczniki czasu i dowody odbiorcy.
Są to obserwacje hipotetyczne, a nie dostarczona księga lub wykonany czek. Zachowaj starą trasę do autoryzowanego odtwarzania, nie zezwalając obu programom planującym na generowanie tego samego zdarzenia. Przed zadeklarowaniem akceptacji zbierz wygenerowanie aplikacji, zamierzone przesłanie, rzeczywistą obserwację odbiorcy i wspierane testy obsługi awarii jako oddzielne dowody. Kompletnie wyglądający formularz nie może poświadczyć nieprzetestowanej aplikacji.
Przetestuj całą ścieżkę
Korzystaj z zatwierdzonych odbiorców i reprezentatywnych szablonów. Uruchom aplikację normalnie, zachowaj jej identyfikator zdarzenia i dziennik zadań, sprawdź dowody przesłania lub przekazania i przechwyć otrzymaną wiadomość od miejsca docelowego. Sprawdź oczekiwaną treść i ostateczne wyniki uwierzytelnienia odbiorcy. Zapisz czas i trasę testu, aby współistnienie nie przesłaniało, który system go dostarczył.
Ćwicz przejściowy błąd przesyłania, zachowanie ponawiania i dozwolony przypadek nieprawidłowego odbiorcy, jeśli obsługuje to środowisko testowe. Sprawdź, kto odbiera i przetwarza zwroty. Sprawdź oddzielnie miejsca docelowe wewnętrzne i zewnętrzne. Po zaakceptowaniu transakcji SMTP może nadal wystąpić błąd dostarczenia; pomyślny test odbiorcy nie sprawdza możliwości obsługi błędów przez aplikację.
Eksportuj dowody przed wycofaniem starej usługi
Zachowaj autoryzowaną konfigurację bazową, mapę zależności, stan kolejki, wyniki testów i odpowiednie dzienniki operacyjne z określoną decyzją dotyczącą przechowywania. Sprawdź, czy dowody pozostaną czytelne po zakończeniu dostępu do starej platformy. Eksportuj tylko to, co jest potrzebne i przechowuj dane uwierzytelniające poza pakietem.
Ustal wyraźne kryteria wyjścia: wykonanie kluczowych zaplanowanych zadań, kontrola ryzyka duplikacji, sprawdzenie dowodów odbiorcy, potwierdzenie obsługi odbić i przetestowanie przywrócenia starej trasy lub świadoma rezygnacja z niej przez odpowiedzialnego właściciela. Jeśli comiesięczne zadanie nie zostało uruchomione, zapisz tę lukę, zamiast ogłaszać zakończenie migracji. Wycofaj stare autoryzacje i punkty końcowe poprzez zatwierdzoną kontrolę zmian po zamknięciu ich zależności.