Grundlegendes zu den Datenanforderungen für die Erstbewertung - AWS Präskriptive Leitlinien
Datenquellen und DatenanforderungenBewertung des Bedarfs an Discovery-Tools

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Grundlegendes zu den Datenanforderungen für die Erstbewertung

Die Datenerfassung kann viel Zeit in Anspruch nehmen und leicht zu einem Hindernis werden, wenn nicht klar ist, welche Daten wann benötigt werden. Der Schlüssel liegt darin, das Gleichgewicht zwischen dem, was zu wenig ist, und dem, was zu viel ist, für die Ergebnisse dieser Phase zu verstehen. Um sich auf die Daten und die Genauigkeit zu konzentrieren, die für diese frühe Phase der Portfoliobewertung erforderlich sind, sollten Sie bei der Datenerhebung einen iterativen Ansatz verfolgen.

Datenquellen und Datenanforderungen

Der erste Schritt besteht darin, Ihre Datenquellen zu identifizieren. Identifizieren Sie zunächst die wichtigsten Stakeholder in Ihrem Unternehmen, die die Datenanforderungen erfüllen können. Dabei handelt es sich in der Regel um Mitglieder der Teams für Servicemanagement, Betrieb, Kapazitätsplanung, Überwachung und Support sowie um die Anwendungseigentümer. Richten Sie Arbeitssitzungen mit Mitgliedern dieser Gruppen ein. Kommunizieren Sie die Datenanforderungen und besorgen Sie sich eine Liste mit Tools und vorhandener Dokumentation, die die Daten bereitstellen können.

Verwenden Sie als Leitfaden für diese Konversationen die folgenden Fragen:

  • Wie genau und aktuell ist der aktuelle Infrastruktur- und Anwendungsbestand? Wissen wir beispielsweise bereits, wo die Lücken bestehen, was die Unternehmenskonfigurationsmanagement-Datenbank (CMDB) angeht?

  • Verfügen wir über aktive Tools und Prozesse, die die CMDB (oder ein gleichwertiges System) auf dem neuesten Stand halten? Wenn ja, wie oft wird sie aktualisiert? Was ist das letzte Aktualisierungsdatum?

  • Enthält application-to-infrastructure das aktuelle Inventar, z. B. die CMDB, eine Zuordnung? Ist jedes Infrastruktur-Asset einer Anwendung zugeordnet? Ist jede Anwendung der Infrastruktur zugeordnet?

  • Enthält das Inventar einen Katalog mit Lizenzen und Lizenzvereinbarungen für jedes Produkt?

  • Enthält das Inventar Abhängigkeitsdaten? Beachten Sie das Vorhandensein von Kommunikationsdaten wie Server zu Server, Anwendung zu Anwendung, Anwendung oder Server zu Datenbank.

  • Welche anderen Tools, die Anwendungs- und Infrastrukturinformationen bereitstellen können, sind in der Umgebung verfügbar? Beachten Sie, dass es Leistungs-, Überwachungs- und Verwaltungstools gibt, die als Datenquelle verwendet werden können.

  • Was sind die verschiedenen Standorte, z. B. Rechenzentren, an denen unsere Anwendungen und Infrastruktur gehostet werden?

Nachdem diese Fragen beantwortet wurden, listen Sie Ihre identifizierten Datenquellen auf. Weisen Sie dann jedem von ihnen ein gewisses Maß an Treue oder Vertrauen zu. Daten, die vor Kurzem (innerhalb von 30 Tagen) aus aktiven programmatischen Quellen wie Tools validiert wurden, weisen ein Höchstmaß an Genauigkeit auf. Statische Daten gelten als weniger originalgetreu und weniger vertrauenswürdig. Beispiele für statische Daten sind Dokumente, Arbeitsmappen, manuell aktualisierte CMDBs oder andere nicht programmgesteuert verwaltete Datensätze oder deren letztes Aktualisierungsdatum älter als 60 Tage ist.

Die Datengenauigkeitsstufen in der folgenden Tabelle dienen als Beispiele. Wir empfehlen Ihnen, die Anforderungen Ihres Unternehmens im Hinblick auf die maximale Toleranz gegenüber Annahmen und die damit verbundenen Risiken zu bewerten, um zu ermitteln, welches Maß an Genauigkeit angemessen ist. In der Tabelle bezieht sich institutionelles Wissen auf alle Informationen über Anwendungen und Infrastruktur, die nicht dokumentiert sind.

Datenquellen

Grad der Treue

Abdeckung des Portfolios

Kommentare

Institutionelles Wissen

Niedrig — Bis zu 25% der korrekten Daten, 75% der angenommenen Werte oder Daten sind älter als 150 Tage.

Niedrig

Selten, konzentriert sich auf kritische Anwendungen

Wissensdatenbank

Mittel bis niedrig — 35-40% der korrekten Daten, 65-60% angenommene Werte oder Daten sind 120-150 Tage alt.

Mittelschwer

Manuell verwaltete, inkonsistente Detaillierungsgrade

CMDB

Mittel: ~ 50% der korrekten Daten, ~ 50% angenommene Werte oder Daten sind 90-120 Tage alt.

Mittelschwer

Enthält Daten aus gemischten Quellen, mehrere Datenlücken

VMware vCenter-Exporte

Mittel bis hoch — 75-80% der korrekten Daten, 25-20% angenommene Werte oder Daten sind 60-90 Tage alt.

Hoch

Deckt 90% des virtualisierten Bestands ab

Überwachung der Anwendungsleistung

Hoch — Überwiegend genaue Daten, ~ 5% der angenommenen Werte oder Daten sind 0-60 Tage alt.

Niedrig

Beschränkt auf kritische Produktionssysteme (deckt 15% des Anwendungsportfolios ab)

In den folgenden Tabellen sind die erforderlichen und optionalen Datenattribute für jede Anlageklasse (Anwendungen, Infrastruktur, Netzwerke und Migration), die spezifische Aktivität (Inventar oder Geschäftsszenario) und die empfohlene Datentreue für diese Bewertungsphase aufgeführt. In den Tabellen werden die folgenden Abkürzungen verwendet:

  • R, für erforderlich

  • (D), für direktionale Geschäftsszenarien, erforderlich für Vergleiche der Gesamtbetriebskosten (TCO) und zielgerichtete Geschäftsfälle

  • (F), für einen vollständigen, zielgerichteten Geschäftsszenario, erforderlich für Vergleiche der Gesamtbetriebskosten und für zielgerichtete Geschäftsszenarien, die Migrations- und Modernisierungskosten beinhalten

  • O, für optional

  • N/A, für nicht zutreffend

Anwendungen

Attributname

Beschreibung

Inventar und Priorisierung

Geschäftsszenario

Empfohlene Treuestufe (mindestens)

Eindeutige Kennung

Zum Beispiel Anwendungs-ID. In der Regel in bestehenden CMDBs oder anderen internen Inventaren und Kontrollsystemen verfügbar. Erwägen Sie die Erstellung einzigartiger IDs Produkte, wann immer diese in Ihrer Organisation nicht definiert sind.

R

R (D)

Hoch

Anwendungsname

Name, unter dem diese Anwendung Ihrer Organisation bekannt ist. Geben Sie gegebenenfalls den Handelsnamen off-the-shelf (COTS) und den Produktnamen an.

R

R (D)

Mittel-Hoch

Ist COTS?

Ja oder Nein. Ob es sich um eine kommerzielle Anwendung oder eine interne Entwicklung handelt

R

R (D)

Mittel-Hoch

COTS-Produkt und Version

Name und Version des kommerziellen Softwareprodukts

R

R (D)

Mittelschwer

Beschreibung

Primäre Anwendungsfunktion und Kontext

R

O

Mittelschwer

Kritikalität

Zum Beispiel eine strategische oder umsatzgenerierende Anwendung oder die Unterstützung einer wichtigen Funktion

R

O

Mittel-Hoch

Typ

Zum Beispiel Datenbank, Kundenbeziehungsmanagement (CRM), Webanwendung, Multimedia, gemeinsam genutzter IT-Service

R

O

Mittelschwer

Umgebung

Zum Beispiel Produktion, Vorproduktion, Entwicklung, Test, Sandbox

R

R (D)

Mittel-Hoch

Einhaltung gesetzlicher Vorschriften und Vorschriften

Für den Workload geltende Frameworks (z. B. HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) und regulatorische Anforderungen

R

R (D)

Mittel-Hoch

Abhängigkeiten

Upstream- und Downstream-Abhängigkeiten zu internen und externen Anwendungen oder Diensten. Nichttechnische Abhängigkeiten wie betriebliche Elemente (z. B. Wartungszyklen)

O

O

Mittel-Niedrig

Kartierung der Infrastruktur

Zuordnung zu physischen und/oder virtuellen Ressourcen, aus denen die Anwendung besteht

O

O

Mittelschwer

License

Lizenztyp für Standardsoftware (z. B. Microsoft SQL Server Enterprise)

O

R

Mittel-Hoch

Kosten

Kosten für Softwarelizenzen, Softwarebetrieb und Wartung

N/A

O

Mittelschwer

Infrastruktur

Name des Attributs

Beschreibung

Inventar und Priorisierung

Geschäftsszenario

Empfohlene Treuestufe (mindestens)

Eindeutige Kennung

Zum Beispiel Server-ID. In der Regel in bestehenden CMDBs oder anderen internen Inventar- und Kontrollsystemen verfügbar. Ziehen Sie es in Betracht IDs , einzigartige Produkte zu erstellen, wann immer diese in Ihrer Organisation nicht definiert sind.

R

R

Hoch

Name des Netzwerks

Assetname im Netzwerk (z. B. Hostname)

R

O

Mittel-Hoch

DNS-Name (vollqualifizierter Domänenname oder FQDN)

DNS-Name

O

O

Mittelschwer

IP-Adresse und Netzmaske

Interne und/oder öffentliche IP-Adressen

R

O

Mittel-Hoch

Asset type (Objekttyp)

Physischer oder virtueller Server, Hypervisor, Container, Gerät, Datenbankinstanz usw.

R

R

Mittel-Hoch

Produktname

Kommerzieller Anbieter und Produktname (z. B. IBM Power Systems VMware ESXi, Exadata)

R

R

Mittelschwer

Betriebssystem

Zum Beispiel REHL 8, Windows Server 2019, AIX 6.1

R

R

Mittel-Hoch

Konfiguration

Zugewiesene CPU, Anzahl der Kerne, Threads pro Kern, Gesamtspeicher, Netzwerkkarten

R

R

Mittel-Hoch

Auslastung

Spitzenwert und Durchschnitt der CPU, des Arbeitsspeichers und des Speichers. Durchsatz der Datenbankinstanz.

R

O

Mittel-Hoch

License

Art der Warenlizenz (z. B. RHEL Standard)

R

R

Mittelschwer

Handelt es sich um eine gemeinsame Infrastruktur?

Ja oder Nein, um Infrastrukturdienste zu bezeichnen, die gemeinsam genutzte Dienste wie Authentifizierungsanbieter, Überwachungssysteme, Backup-Dienste und ähnliche Dienste bereitstellen

R

R (D)

Mittelschwer

Zuordnung von Anwendungen

Anwendungen oder Anwendungskomponenten, die in dieser Infrastruktur ausgeführt werden

O

O

Mittelschwer

Kosten

Vollständige Kosten für Bare-Metal-Server, einschließlich Hardware, Wartung, Betrieb, Speicher (SAN, NAS, Object), Betriebssystemlizenz, Anteil an Rackspace und Gemeinkosten für Rechenzentren

N/A

O

Mittel-Hoch

Netzwerke

Name des Attributs

Beschreibung

Inventar und Priorisierung

Geschäftsszenario

Empfohlene Treuestufe (mindestens)

Größe des Rohres (Mb/s), redundancy (Y/N)

Aktuelle WAN-Link-Spezifikationen (z. B. 1000 MB/s redundant)

O

R

Mittelschwer

Link-Nutzung

Spitzen- und Durchschnittsauslastung, ausgehende Datenübertragung (GB/Monat)

O

R

Mittelschwer

Latenz (ms)

Aktuelle Latenz zwischen verbundenen Standorten.

O

O

Mittelschwer

Kosten

Aktuelle Kosten pro Monat

N/A

O

Mittelschwer

Migration

Name des Attributs

Beschreibung

Inventar und Priorisierung

Geschäftsszenario

Empfohlene Treuestufe (mindestens)

Erneut hosten

Aufwand für Kunden und Partner für jeden Workload (Personentage), Kostensätze für Kunden und Partner pro Tag, Werkzeugkosten, Anzahl der Workloads

N/A

R (F)

Mittel-Hoch

Plattformwechsel

Aufwand für Kunden und Partner für jeden Workload (Personentage), Kostensätze für Kunden und Partner pro Tag, Anzahl der Workloads

N/A

R (F)

Mittel-Hoch

Refaktorieren

Aufwand für Kunden und Partner für jeden Workload (Personentage), Kostensätze für Kunden und Partner pro Tag, Anzahl der Workloads

N/A

O

Mittel-Hoch

Ausmustern

Anzahl der Server, durchschnittliche Stilllegungskosten

N/A

O

Mittel-Hoch

Landezone

Wiederverwendung vorhandener (J/N), Liste der benötigten AWS Regionen, Kosten

N/A

R (F)

Mittel-Hoch

Menschen und Veränderung

Anzahl der Mitarbeiter, die im Bereich Cloud-Betrieb und -Entwicklung geschult werden müssen, Schulungskosten pro Person, Kosten für Schulungszeit pro Person

N/A

R (F)

Mittel-Hoch

Dauer

Dauer der Workload-Migration im Rahmen des Geltungsbereichs (Monate)

O

R (F)

Mittel-Hoch

Parallele Kosten

Zeitrahmen und Geschwindigkeit, in der Ist-Kosten während der Migration wegfallen können

N/A

O

Mittel-Hoch

Zeitrahmen und Geschwindigkeit, in der AWS Produkte und Dienstleistungen sowie andere Infrastrukturkosten während der Migration eingeführt werden

N/A

O

Mittel-Hoch

Bewertung des Bedarfs an Discovery-Tools

Benötigt Ihr Unternehmen Discovery-Tools? Für die Portfoliobewertung sind zuverlässige up-to-date Daten über Anwendungen und Infrastruktur erforderlich. In der Anfangsphase der Portfoliobewertung können Annahmen verwendet werden, um Datenlücken zu schließen.

Wenn jedoch Fortschritte erzielt werden, ermöglichen präzise Daten die Erstellung erfolgreicher Migrationspläne und die korrekte Schätzung der Zielinfrastruktur, um die Kosten zu senken und den Nutzen zu maximieren. Es reduziert auch das Risiko, indem Implementierungen ermöglicht werden, die Abhängigkeiten berücksichtigen und Fallstricke bei der Migration vermeiden. Der Hauptanwendungsfall von Discovery-Tools in Cloud-Migrationsprogrammen besteht darin, Risiken zu reduzieren und das Vertrauensniveau in Daten durch folgende Maßnahmen zu erhöhen:

  • Automatisierte oder programmatische Datenerfassung, die zu validierten, äußerst vertrauenswürdigen Daten führt

  • Beschleunigung der Datenerfassungsrate, wodurch die Projektgeschwindigkeit verbessert und die Kosten gesenkt werden

  • Höhere Vollständigkeit der Daten, einschließlich Kommunikationsdaten und Abhängigkeiten, die normalerweise nicht verfügbar sind in CMDBs

  • Gewinnung von Erkenntnissen wie automatisierter Anwendungsidentifikation, Gesamtbetriebskostenanalyse, prognostizierten Ausführungsraten und Optimierungsempfehlungen

  • Zuverlässige Planung von Migrationswellen

Wenn unsicher ist, ob an einem bestimmten Standort Systeme vorhanden sind, können die meisten Erkennungstools Netzwerksubnetze scannen und die Systeme ausfindig machen, die auf Ping- oder SNMP-Anfragen (Simple Network Management Protocol) reagieren. Beachten Sie, dass nicht alle Netzwerk- oder Systemkonfigurationen Ping- oder SNMP-Verkehr zulassen. Besprechen Sie diese Optionen mit Ihren Netzwerk- und Technikteams.

Weitere Phasen der Bewertung und Migration des Anwendungsportfolios hängen in hohem Maße von genauen Informationen zur Abhängigkeitszuweisung ab. Die Zuordnung von Abhängigkeiten vermittelt ein Verständnis der Infrastruktur und Konfiguration, die erforderlich sein werden AWS (z. B. Sicherheitsgruppen, Instanztypen, Kontoplatzierung und Netzwerk-Routing). Es hilft auch bei der Gruppierung von Anwendungen, die gleichzeitig verschoben werden müssen (z. B. Anwendungen, die über Netzwerke mit niedriger Latenz kommunizieren müssen). Darüber hinaus liefert die Zuordnung von Abhängigkeiten Informationen zur Weiterentwicklung des Geschäftsszenarios.

Bei der Entscheidung für ein Discovery-Tool ist es wichtig, alle Phasen des Bewertungsprozesses zu berücksichtigen und die Datenanforderungen zu antizipieren. Datenlücken können zu Hindernissen werden. Daher ist es wichtig, diese zu antizipieren, indem future Datenanforderungen und Datenquellen analysiert werden. Die Erfahrung in diesem Bereich zeigt, dass die meisten ins Stocken geratenen Migrationsprojekte nur über einen begrenzten Datensatz verfügen, in dem die betreffenden Anwendungen, die zugehörige Infrastruktur und ihre Abhängigkeiten nicht eindeutig identifiziert werden. Diese mangelnde Identifizierung kann zu falschen Kennzahlen, Entscheidungen und Verzögerungen führen. Die Beschaffung von up-to-date Daten ist der erste Schritt zu erfolgreichen Migrationsprojekten.

Wie wähle ich ein Discovery-Tool aus?

Verschiedene Discovery-Tools auf dem Markt bieten unterschiedliche Funktionen und Fähigkeiten. Berücksichtigen Sie Ihre Anforderungen. Und entscheiden Sie sich für die für Ihr Unternehmen am besten geeignete Option. Die häufigsten Faktoren bei der Entscheidung für ein Discovery-Tool für Migrationen sind die folgenden:

Sicherheit

  • Was ist die Authentifizierungsmethode für den Zugriff auf das Tool-Daten-Repository oder die Analyse-Engines?

  • Wer kann auf die Daten zugreifen und welche Sicherheitskontrollen gibt es für den Zugriff auf das Tool?

  • Wie sammelt das Tool Daten? Benötigt es spezielle Anmeldeinformationen?

  • Welche Anmeldeinformationen und Zugriffsebene benötigt das Tool, um auf meine Systeme zuzugreifen und Daten abzurufen?

  • Wie werden Daten zwischen den Komponenten des Tools übertragen?

  • Unterstützt das Tool die Datenverschlüsselung im Ruhezustand und bei der Übertragung?

  • Sind Daten in einer einzigen Komponente innerhalb oder außerhalb meiner Umgebung zentralisiert?

  • Was sind die Netzwerk- und Firewallanforderungen?

Stellen Sie sicher, dass Sicherheitsteams frühzeitig in Gespräche über Discovery-Tools einbezogen werden.

Datensouveränität

  • Wo werden die Daten gespeichert und verarbeitet?

  • Verwendet das Tool ein Software-as-a-Service-Modell (SaaS)?

  • Hat es die Möglichkeit, alle Daten innerhalb der Grenzen meiner Umgebung aufzubewahren?

  • Können Daten überprüft werden, bevor sie die Grenzen meines Unternehmens verlassen?

Berücksichtigen Sie die Anforderungen Ihres Unternehmens in Bezug auf die Anforderungen an die Datenresidenz.

Architektur

  • Welche Infrastruktur ist erforderlich und was sind die verschiedenen Komponenten?

  • Ist mehr als eine Architektur verfügbar?

  • Unterstützt das Tool die Installation von Komponenten in luftverriegelten Sicherheitszonen?

Leistung

  • Welche Auswirkungen hat die Datenerfassung auf meine Systeme?

Kompatibilität und Umfang

  • Unterstützt das Tool alle oder die meisten meiner Produkte und Versionen? Lesen Sie die Dokumentation des Tools, um zu überprüfen, ob die unterstützten Plattformen mit den aktuellen Informationen zu Ihrem Anwendungsbereich übereinstimmen.

  • Werden die meisten meiner Betriebssysteme für die Datenerfassung unterstützt? Wenn Sie Ihre Betriebssystemversionen nicht kennen, versuchen Sie, die Liste der Erkennungstools auf diejenigen zu beschränken, die ein breiteres Spektrum unterstützter Systeme anbieten.

Methoden zur Erfassung

  • Muss für das Tool auf jedem Zielsystem ein Agent installiert werden?

  • Unterstützt es Bereitstellungen ohne Agenten?

  • Bieten Agenten und ohne Agenten dieselben Funktionen?

  • Was ist der Inkassoprozess?

Funktionen

  • Welche Funktionen sind verfügbar?

  • Kann es die Gesamtbetriebskosten (TCO) und die geschätzte AWS Cloud Betriebsrate berechnen?

  • Unterstützt es die Migrationsplanung?

  • Misst es die Leistung?

  • Kann es eine AWS Zielinfrastruktur empfehlen?

  • Führt es eine Abhängigkeitszuweisung durch?

  • Welches Maß an Abhängigkeitszuweisung bietet es?

  • Bietet es API-Zugriff? (Kann zum Beispiel programmgesteuert darauf zugegriffen werden, um Daten abzurufen?)

Erwägen Sie Tools mit starken Funktionen zur Zuordnung von Anwendungs- und Infrastrukturabhängigkeiten und solche, die Anwendungen anhand von Kommunikationsmustern ableiten können.

Kosten

  • Was ist das Lizenzmodell?

  • Wie viel kostet die Lizenzierung?

  • Gilt der Preis für jeden Server? Handelt es sich um eine gestaffelte Preisgestaltung?

  • Gibt es Optionen mit eingeschränkten Funktionen, die auf Abruf lizenziert werden können?

Discovery-Tools werden in der Regel während des gesamten Lebenszyklus von Migrationsprojekten eingesetzt. Wenn Ihr Budget begrenzt ist, sollten Sie mindestens 6 Monate in Betracht ziehen. Das Fehlen von Discovery-Tools führt jedoch in der Regel zu höherem manuellen Aufwand und internen Kosten.

Modell Support

  • Welche Support-Stufen werden standardmäßig bereitgestellt?

  • Ist ein Supportplan verfügbar?

  • Wie sind die Reaktionszeiten bei Vorfällen?

Professionelle Dienstleistungen

  • Bietet der Anbieter professionelle Dienstleistungen zur Analyse von Discovery-Ergebnissen an?

  • Können sie die Elemente dieses Leitfadens behandeln?

  • Gibt es Rabatte oder Pakete für Tooling+-Services?

Tipp

Verwenden Sie die Website Discovery, Planning and Recommendation, um Discovery-Tools zu finden und zu testen.

Empfohlene Funktionen für das Discovery-Tool

Um zu vermeiden, dass Daten aus mehreren Tools im Laufe der Zeit bereitgestellt und kombiniert werden, sollte ein Discovery-Tool die folgenden Mindestfunktionen abdecken:

  • Software — Das Discovery-Tool sollte in der Lage sein, laufende Prozesse und installierte Software zu identifizieren.

  • Zuordnung von Abhängigkeiten — Es sollte in der Lage sein, Netzwerkverbindungsinformationen zu sammeln und eingehende und ausgehende Abhängigkeitszuordnungen der Server und laufenden Anwendungen zu erstellen. Außerdem sollte das Erkennungstool in der Lage sein, auf der Grundlage von Kommunikationsmustern auf Anwendungen aus Infrastrukturgruppen zu schließen.

  • Profil- und Konfigurationserkennung — Es sollte in der Lage sein, das Infrastrukturprofil wie die CPU-Familie (z. B. x86, PowerPC), die Anzahl der CPU-Kerne, die Speichergröße, die Anzahl der Festplatten und Größe sowie die Netzwerkschnittstellen zu melden.

  • Erkennung von Netzwerkspeichern — Es sollte in der Lage sein, Netzwerkfreigaben von Netzwerkspeichern (NAS) zu erkennen und ein Profil zu erstellen.

  • Leistung — Es sollte in der Lage sein, Spitzen- und Durchschnittsauslastung von CPU, Arbeitsspeicher, Festplatte und Netzwerk zu melden.

  • Lückenanalyse — Sie sollte Einblicke in die Menge und Genauigkeit der Daten liefern können.

  • Netzwerk-Scanning — Es sollte in der Lage sein, Netzwerk-Subnetze zu scannen und unbekannte Infrastrukturressourcen zu entdecken.

  • Berichterstattung — Es sollte in der Lage sein, den Status der Erfassung und Analyse zu ermitteln.

  • API-Zugriff — Es sollte in der Lage sein, programmatische Mittel für den Zugriff auf gesammelte Daten bereitzustellen.

Zusätzliche zu berücksichtigende Funktionen

  • Analyse der Gesamtbetriebskosten für einen Kostenvergleich zwischen den aktuellen Kosten vor Ort und den voraussichtlichen AWS Kosten.

  • Lizenzanalyse und Optimierungsempfehlungen für Microsoft SQL Server- und Oracle-Systeme in Rehost- und Replattform-Szenarien.

  • Empfehlung zur Migrationsstrategie (Kann das Discovery-Tool Standardempfehlungen vom Typ R auf der Grundlage der aktuellen Technologie aussprechen?)

  • Inventarexport (in CSV oder ein ähnliches Format)

  • Empfehlung zur richtigen Dimensionierung (kann sie beispielsweise eine empfohlene AWS Zielinfrastruktur abbilden?)

  • Visualisierung von Abhängigkeiten (kann die Zuordnung von Abhängigkeiten beispielsweise in einem grafischen Modus visualisiert werden?)

  • Architekturansicht (können beispielsweise Architekturdiagramme automatisch erstellt werden?)

  • Priorisierung von Anwendungen (Kann es Anwendungs- und Infrastrukturattributen Gewicht oder Relevanz zuweisen, um Priorisierungskriterien für die Migration festzulegen?)

  • Wellenplanung (z. B. empfohlene Anwendungsgruppen und die Möglichkeit, Migrationswellenpläne zu erstellen)

  • Schätzung der Migrationskosten (Schätzung des Migrationsaufwands)

Überlegungen zur Bereitstellung

Nachdem Sie ein Discovery-Tool ausgewählt und erworben haben, sollten Sie sich die folgenden Fragen stellen, um Gespräche mit den Teams anzuregen, die für die Implementierung des Tools in Ihrem Unternehmen verantwortlich sind:

  • Werden Server oder Anwendungen von einem Drittanbieter betrieben? Dies könnte die beteiligten Teams und die Einhaltung der einzuhaltenden Prozesse vorschreiben.

  • Was ist das allgemeine Verfahren, um die Genehmigung für den Einsatz von Discovery-Tools zu erhalten?

  • Was ist der wichtigste Authentifizierungsprozess für den Zugriff auf Systeme wie Server, Container, Speicher und Datenbanken? Sind Serveranmeldedaten lokal oder zentralisiert? Wie erfolgt das Abrufen von Anmeldeinformationen? Für die Erfassung von Daten aus Ihren Systemen (z. B. Containern, virtuellen oder physischen Servern, Hypervisoren und Datenbanken) sind Anmeldeinformationen erforderlich. Die Beschaffung von Anmeldeinformationen für das Discovery-Tool, mit dem eine Verbindung zu den einzelnen Ressourcen hergestellt werden kann, kann schwierig sein, insbesondere wenn diese Ressourcen nicht zentralisiert sind.

  • Wie sind die Sicherheitszonen im Netzwerk umrissen? Sind Netzwerkdiagramme verfügbar?

  • Wie wird das Anfordern von Firewallregeln in den Rechenzentren durchgeführt?

  • Was sind die aktuellen Service Level Agreements (SLAs) für den Support in Bezug auf den Betrieb von Rechenzentren (Installation von Discovery-Tools, Firewall-Anfragen)?