Narracja klienta
W module Wprowadzenie udostępniliśmy narrację dla firmy Tailwind Traders. Centralny zespół operacyjny i zespół ds. platformy w firmie Tailwind Traders są doświadczeni w zarządzaniu istniejącymi centrami danych firmy. Trwający projekt migracji dwóch centrów danych na platformę Azure już uwidacznia kilka krytycznych krzywych uczenia się, których nie można rozwiązać w bieżącym zestawie umiejętności firmy.
Ważne ograniczenia
W tej chwili firma postawiła wysoki priorytet migracji i spełnia ograniczenia czasowe, aby wydostać się z centrum danych. Ze względu na ten priorytet biznesowy zespoły biznesowe i IT mają przestarzałe wymagania dotyczące zabezpieczeń i zgodności, dopóki nie będą mogły ukończyć opracowywania podstawowej platformy w chmurze.
Ponieważ firma Tailwind Traders jest nowym użytkownikiem chmury, kilku członków zespołu ds. operacji, platformy lub administratorów IT jest doświadczonych w chmurze. Firma chce powoli przechodzić do nowoczesnych operacji, zabezpieczeń i ładu, ale nadal potrzebuje podstawy chmury, która może być skalowana w celu spełnienia tych potrzeb, ponieważ stają się ważniejsze.
W przeszłości firma Tailwind Traders działała wyłącznie z perspektywy centralnych operacji. W związku z tym zespoły obciążeń nie mogą wchodzić w interakcje ze środowiskami produkcyjnymi. Firma nie ma łatwego sposobu mapowania zasobów (maszyn wirtualnych, danych i aplikacji) na zdefiniowane obciążenia, więc granice każdego obciążenia mogą być czasami niejasne.
Wyrównanie do stref docelowych platformy Azure
Zespoły ds. operacji i platform zgodziły się na następujące dostosowanie:
- Koncepcyjna architektura stref docelowych platformy Azure będzie służyć jako długoterminowa wizja przyszłego stanu środowiska chmury. Wszystkie zespoły, których dotyczy problem, będą używać tej architektury jako podstawy do tworzenia umiejętności w chmurze i konfigurowania środowiska chmury.
- Zespoły będą używać akceleratora strefy docelowej platformy Azure, aby rozpocząć pracę z konfiguracją środowiska.
- Jeśli zespoły muszą dostosować swoje środowisko w przyszłości, będą używać jednej z niestandardowych opcji implementacji, które są dostosowane do lub rozszerzają początkowe wdrożenie oparte na akceleratorze.
Odchylenie od standardowych wskazówek dotyczących strefy docelowej platformy Azure
Poniższa lista przedstawia, w jaki sposób ograniczenia spowodowały, że firma Tailwind Traders odbiega od zasad projektowania stref docelowych platformy Azure wraz z wpływem każdej decyzji:
Nadzór oparty na zasadach: firma Tailwind Traders nie automatycznie historycznie zautomatyzowała swoich zasad firmowych. Ze względu na presję na szybkie migrowanie centrum danych firma zdecydowała się zminimalizować ilość ładu — w tym w początkowym wdrożeniu strefy docelowej.
Firma zobowiązała się również do ukończenia modułu Learn na temat metodologii ład w przewodniku Cloud Adoption Framework po skonfigurowaniu środowiska początkowego. Ograniczenia personelu IT przeznaczone do migracji do chmury są dużym czynnikiem dla tego odchylenia. To odchylenie jest dodatkowo wymuszane przez odporność biznesową i IT na pełne ład w chmurze lub "Azure Ops".
Demokratyzacja subskrypcji: centralny zespół operacyjny zachowa odpowiedzialność za operacje produkcyjne dla wszystkich obciążeń. Ten zespół rzadko zezwala zespołowi ds. obciążeń na dostęp do środowiska produkcyjnego, więc nie jest zgodna z zasadą projektowania demokratyzacji subskrypcji.
Jeśli zespół ds. obciążeń wymaga odchylenia, centralny zespół operacyjny rozważy dedykowaną strefę docelową dla poszczególnych obciążeń w poszczególnych przypadkach. W przeciwnym razie firma Tailwind Traders jest zdecydowanie zaangażowana w utrzymanie centralnych operacji i będzie miała ograniczone wystąpienia obciążeń w izolowanych środowiskach produkcyjnych (lub strefach docelowych aplikacji).
Model usługi skoncentrowany na aplikacji: procesy związane z awarią mogą uwzględniać obciążenia, szczególnie w przypadku zasobów obsługujących obciążenia o znaczeniu krytycznym. Jednak poza awariami centralny zespół operacyjny nie rozróżnia obciążeń i aplikacji na potrzeby procesów zarządzania operacjami. Podstawowe procesy zespołu działają, zarządzają zmianami i optymalizują wszystkie zasoby w taki sam sposób, niezależnie od granic obciążeń lub architektury. Biorąc pod uwagę ograniczenia czasowe dla tej migracji, nie jest możliwe zdefiniowanie granic aplikacji przez firmę Tailwind Traders i ustanowienie modelu usługi skoncentrowanej na aplikacji.
Wiele terminów na powyższej liście zostanie wyjaśnione w kolejnych lekcjach tego modułu Learn. Kilka z nich znajduje odzwierciedlenie w notatkach, aby stworzyć możliwości nauczania.
Te odchylenia nie są odbierane od porozumienia wyrównania. Jednak te odchylenia będą mieć wpływ na niektóre opcje wdrażania akceleratora strefy docelowej platformy Azure. Te odchylenia będą również mieć wpływ na projekt poszczególnych stref docelowych aplikacji, które są wdrażane po rozpoczęciu migracji zasobów do chmury.
Te odchylenia będą również wymagać od zespołów firmy Tailwind Traders ukończenia modułów Learn dotyczących zarządzania, zabezpieczeń i ładu w przewodniku Cloud Adoption Framework po wdrożeniu początkowego środowiska.
Dodatkowe ograniczenia
Następujące dodatkowe ograniczenia mogą mieć wpływ na decyzje firmy Tailwind.
Operacje
Centralny zespół operacyjny opracował w sposób organiczny zestaw procesów i mechanizmów kontroli do zarządzania ogólnym portfelem. Zespół zależy od programu System Center Operations Manager i programu Microsoft Configuration Manager na potrzeby linii bazowej operacji.
Zespół zintegrował również najlepsze narzędzia do zarządzania maszynami wirtualnymi, śledzenia zdarzeń i konfiguracji, monitorowania sieci, operacji zabezpieczeń i kontroli ładu, między innymi narzędzi. Większość tych narzędzi ma wbudowaną integrację z platformą Azure, która miała wpływ na decyzję o użyciu platformy Azure jako podstawowego dostawcy chmury firmy. Obsługa tych narzędzi wymaga znacznej mocy i kapitału.
Narzędzia do obsługi operacji
Licencjonowanie narzędzi do zarządzania operacjami (w tym funkcji hypervisor) zużywa ponad 20 procent budżetu IT na twarde koszty. Nowy dyrektor ds. systemów informatycznych (CIO) zakwestionował zespół do ponownego oceny tych narzędzi i procesów w celu znalezienia alternatyw dla operacji w chmurze lub ujednoliconych operacji. Dyrektor ds. systemów informatycznych będzie obserwować zmniejszenie wydatków związanych z narzędziami jako wczesny wskaźnik sukcesu w tej migracji.
Procesy operacji
Menedżer IT poprosił dwóch nowych pracowników o pomoc zespołowi ds. operacji centralnych. Pomogą one zrównoważyć obciążenie zespołu przeciążonego. W szczególności będą one obsługiwać praktyki dotyczące ciągłości działania i odzyskiwania po awarii (BCDR) oraz procesy zgodności poprawek.
Firma nie jest gotowa do pełnego przejścia na operacje natywne dla chmury, zwłaszcza w przypadku aplikacji o krytycznym znaczeniu. Dyrektor ds. systemów informatycznych uważa, że niektóre inwestycje w narzędzia do obsługi operacji natywnych dla chmury pomogą zmniejszyć obciążenie centralnego zespołu ds. operacji, przenosząc niektóre z tych obowiązków do dostawcy usług w chmurze.
Dyrektor ds. systemów informatycznych będzie obserwować zmiany operacyjne w celu poprawy zadowolenia pracowników i zmniejszenia obciążenia w centralnym zespole operacyjnym. Dyrektor ds. systemów informatycznych będzie również żądać częstych aktualizacji sposobu, w jaki plan wdrożenia wpływa na proces BCDR i działania związane z stosowaniem poprawek.
Umowa dotycząca poziomu usług
Pomimo całej ciężkiej pracy i kosztów związanych z operacjami zespół okresowo nie spełnia umowy dotyczącej poziomu usług (SLA) 90 procent czasu pracy dla systemów o znaczeniu krytycznym w podstawowym centrum danych. Jest to kosztowna troska o dyrektor ds. systemów informatycznych i dyrektora generalnego (CEO). Nieaktualny sprzęt i zaległy cykl odświeżania w centrum danych spowodowały częste, ale krótkie przestoje.
Mimo że firma niechętnie zaakceptowała tę umowę SLA, nowy dyrektor ds. systemów informatycznych nie jest pod wrażeniem. Niezależnie od oszczędności finansowych dyrektor ds. systemów informatycznych oczekuje, że centralny zespół operacyjny dostarczy znacznie wyższą umowę SLA po migracji.
Innowacje w zakresie handlu detalicznego
Narracja klienta z modułu Wprowadzenie wprowadziła Cię do zespołu ds. innowacji detalicznych w firmie Tailwind Traders. Ten zespół był pierwotnie startupem, który firma Tailwind Traders nabyła. Oryginalny dyrektor generalny startupu jest teraz dyrektorem generalnym Firmy Tailwind (CTO). Cel certyfikacji nadal działa w tym dziale, takim jak startup, poprzez ustalanie priorytetów eksperymentów i innowacji.
Bieżące procesy zarządzania operacjami wymagają, aby wszystkie nowe innowacje od tego zespołu przechodziły przez proces wydawania. Centralny zespół operacyjny w ramach IT przegląda architekturę pod kątem kwestii związanych z zabezpieczeniami, ładem i zarządzaniem operacjami. Gdy zespół jest komfortowo z rozwiązaniem, zwalnia rozwiązanie w centralnie zarządzanym środowisku produkcyjnym. Oczekuje się, że ten proces będzie kontynuowany w chmurze.
Zarządzanie tożsamościami
Usługa Active Directory to magazyn tożsamości i podstawowe narzędzie do uwierzytelniania i kontroli dostępu w centrach danych firmy Tailwind Traders. Firma użyła niektórych najlepszych systemów do rozszerzania tożsamości na rozwiązanie uwierzytelniania wieloskładnikowego. Firma ma również tożsamości federacyjne, aby wdrożyć swoje rozwiązanie platformy Microsoft 365. Jednak nawet w przypadku tych usług usługa Active Directory jest sposobem zarządzania tożsamością przez firmę Tailwind Traders.
W chmurze firma ma teraz więcej opcji, takich jak Microsoft Entra ID lub Microsoft Entra Domain Services działających w infrastrukturze infrastruktury jako usługi (IaaS). Centralny zespół operacyjny stara się porównać opcje i wybrać najlepsze rozwiązanie tożsamości dla planów wdrażania chmury.
Topologia sieci i łączność
Firma Tailwind Traders używa wieloprotokolowych linii przełączania etykiet (MPLS) do łączenia swoich centrów danych i magazynów fizycznych. Cały ruch internetowy jest kierowany przez podstawowe centrum danych. Ze względu na konflikty protokołu internetowego (IP) między dwoma centrami danych ruch jest izolowany, a routing jest zależny od złożonych tabel routingu. Łączność zewnętrzna z centrum danych lub biurem firmowym jest dostarczana za pośrednictwem wirtualnej sieci prywatnej. Ta łączność jest ograniczona i zniechęcana.
Podstawowe i pomocnicze centra danych mają spójne schematy adresów IP, które są utrzymywane i uporządkowane wyraźnie. Trzecie centrum danych zawiera 50 różnych bloków adresów IP z małą spójnością i nie ma jasnego planu organizacji lub segmentacji. Ciągłe cykle innowacji są ograniczone do trzeciego centrum danych, ale mogą one stanowić problemy z definiowaniem topologii sieci i routingu w chmurze.
Organizacja zasobów
Segmentacja zasobów między poszczególnymi centrami danych potraktowała każdą kolekcję obciążeń jako duży blok zasobów. Każda kolekcja została następnie podzielona przez profil ryzyka w celu utworzenia izolowanych i kontrolowanych segmentów w celu umożliwienia ograniczonego przepływu sieci między obciążeniami. Obciążenia wymagające dowolnego połączenia sieciowego przychodzącego z dowolnej niechronionej sieci są izolowane do co najmniej jednego segmentu sieci obwodowej każdego centrum danych.
Poza tą podstawową organizacją istnieją niespójności w bazie danych zarządzania konfiguracją, dlatego trudno jest określić, które zasoby są skojarzone z obciążeniami. Właściciele obciążeń i łańcuchy eskalacji zdarzeń są dobrze zdefiniowane dla obciążeń o znaczeniu krytycznym, ale brakuje ich w przypadku większości innych obciążeń.
W przypadku mniej krytycznych obciążeń często identyfikowany właściciel jest byłym pracownikiem firmy Tailwind Traders. Mapowanie konfiguracji często odwołuje się do maszyn wirtualnych, które zostały zakończone. Podobnie ponad 30 procent obsługiwanych zasobów nie jest wyraźnie mapowanych na pojedyncze obciążenie. Firma będzie wymagać praktyki podczas migracji, aby zapewnić analizę zależności i odpowiednią organizację zasobów.