Zuverlässigkeitsverwaltung
Produktionsdienste sind zwar nicht in einem Dev/Test-Abonnement enthalten, aber Sie könnten andere Phasen in Ihrem Azure Dev/Test-Abonnement verwenden, um die Zuverlässigkeit in der Produktion sicherzustellen.
Wenn Sie Organization Dev/Test-Abonnements verwenden, müssen Sie sich entscheiden, wie Sie die folgenden Aufgaben erfolgreich erledigen:
- Kontrolldaten
- Steuern von Sicherheit und Zugriff
- Verwalten der Uptime dieses Produktionssystems
In der Regel gibt es verschiedene Bereitstellungsphasen, die Sie vor der Produktionsphase durchlaufen: Freigabe, QA, Integration, Staging und Failover. Je nachdem, wie Ihr Unternehmen diese Phasen definiert, könnte sich die Verwendung eines Organization Dev/Test-Abonnements ändern.
Wenn Sie unternehmenskritische Dienste wie Anwendungen für Kunden ausführen, verwenden Sie kein Dev/Test-Abonnement. Für Dev/Test-Abonnements gibt es keine SLA mit finanzieller Absicherung. Diese Abonnements sind für Tests und die Entwicklung vor der Produktionsphase vorgesehen.
Site Reliability Engineering (SRE)
Weitere Informationen zur Zuverlässigkeitstechnik und -verwaltung finden Sie in Artikeln, die sich mit Site Reliability Engineering beschäftigen. Dies ist eine technische Disziplin, mit der Organisationen dabei unterstützt werden sollen, im Kontext ihrer Systeme, Dienste und Produkte eine angemessene Zuverlässigkeit zu erzielen.
Wie sich SRE und DevOps unterscheiden, wird in diesem Bereich noch diskutiert. Zu den weitgehend offensichtlichen Unterschieden gehören folgende:
- SRE ist eine technische Disziplin, die auf Zuverlässigkeit ausgerichtet ist. DevOps ist eine kulturelle Bewegung, die sich aus der Idee heraus entwickelt hat, die Silos aufzubrechen, die in Entwicklungs- und Betriebsorganisationen vorliegen.
- SRE kann der Name einer Rolle sein (Beispielsatz: I’m a site reliability engineer (SRE). Bei DevOps ist dies nicht möglich.
- SRE ist in der Regel präskriptiv. DevOps ist dies absichtlich nicht. Die nahezu universelle Einführung von Continuous Integration/Continuous Delivery und agilen Prinzipien ist das, was DevOps am nächsten kommt.
Weitere Informationen zur Praxis im Zusammenhang mit SRE finden Sie unter den folgenden Links:
- SRE im Kontext
- Wichtige SRE-Prinzipien und -Methoden: Erfolgszyklus
- Wichtige SRE-Prinzipien und -Methoden: Die menschliche Seite von SRE
- Erste Schritte mit SRE
Vereinbarungen zum Service Level
Enterprise Dev/Test ist ausschließlich für die Entwicklung und das Testen Ihrer Anwendungen konzipiert. Bei Verwendung des Abonnements gibt es keine SLA mit finanzieller Absicherung.
Verwenden verschiedener Typen von Dev/Test-Abonnements
Unabhängig davon, ob Sie monatliche Azure-Gutschriften für Visual Studio-Abonnenten, Enterprise Dev/Test-Abonnements oder ein Dev/Test Pay-As-You-Go-Abonnement (PAYG) benötigen, finden Sie problemlos Angebote, die sich für Einzelpersonen oder ein Team eignen.
Verwalten einzelner Gutschriftabonnements
Azure-Gutschriften in Visual Studio sind ein individueller Vorteil für einzelne Dev/Test-Entwickler*innen und die Inner-Loop-Entwicklung. Gutschriften können nicht für Entwickler*innen gebündelt werden. Gutschriftabonnements sind weiterhin Azure-Abonnements, aber es handelt sich um ein bestimmtes Azure-Angebot. Verwalten Sie Ihre Gutschriftabonnements auf die gleiche Weise wie andere Azure-Abonnements, damit Sie in Gruppen und Teams arbeiten können. Sie können einzelne Ausgabenlimits für eine Kreditkarte entfernen. Dies ist auch möglich, wenn für das Enterprise Dev/Test-Abonnement die ausgewählte Kaufmethode Ihres Unternehmens verwendet wird.
Für Inner-Loop-Entwickleraktivitäten werden häufig Gutschriften verwendet, danach findet aber ein Wechsel zu Azure Dev/Test-Abonnements (Enterprise oder Organization) und der nutzungsbasierten Bezahlungsmethode statt. Auf diese Weise können Sie Inner-Loop-Aktivitäten im Rahmen von DevOps-Prozessen mit Ihrem individuellen Gutschriftabonnement ausführen. In der äußeren DevOps-Schleife befinden sich Nichtproduktionsziele in Enterprise Dev/Test - prod goes to prod.
Verwalten Sie Ihre Gutschriftabonnements, Enterprise Dev/Test-Abonnements sowie PAYG-Abonnements, und teilen Sie Ihre Entwickler*innen in Verwaltungsgruppen ein, die jeweils eine eindeutige Hierarchie aufweisen.
Verwenden von Azure Dev/Test-Angeboten für Organisationen
Wenn Sie ein Azure Dev/Test-Abonnement für Organisationen benötigen, stehen Ihnen zwei Angebote zur Verfügung.
Jede Option bietet spezifische Rabatte und erfordert ein Visual Studio-Abonnement.
Mit jedem Abonnementangebot können Sie dafür sorgen, dass Ihr Team über die benötigten Dev/Test-Umgebungen mit vorkonfigurierten virtuellen Maschinen in der Cloud verfügt. Erstellen Sie mehrere Azure-Abonnements, und verwalten Sie sie über ein Konto. Sie können isolierte Umgebungen verwalten und eine separate Rechnung für verschiedene Projekte oder Teams anfordern.
Enterprise Dev/Test-Abonnements erfordern ein Enterprise Agreement (EA). Dev/Test Pay-As-You-Go-Abonnements erfordern kein EA, können aber mit einem Enterprise Agreement-Konto genutzt werden.
Warum sollte ich PAYG-Angebote bzw. Enterprise Dev/Test-Angebote nutzen?
Ein Dev/Test Pay-As-You-Go-Angebot ist möglicherweise die richtige Wahl, wenn Sie Visual Studio-Abonnent sind. Im Gegensatz zu Gutschriftabonnements für die individuelle Nutzung eignen sich PAYG-Angebote ideal für die Teamentwicklung, und diese Abonnements ermöglichen es Ihnen, mehrere Benutzer*innen innerhalb eines Abonnements zu verwalten. Ein Dev/Test Pay-As-You-Go-Angebot eignet sich möglicherweise in den folgenden Fällen:
- Sie verfügen über kein Enterprise Agreement. In diesem Fall können Sie nur ein PAYG-Konto mit einer Visual Studio-Lizenz erstellen.
- Sie erstellen ein Enterprise Agreement, müssen aber ein Abonnement einrichten, das nicht die Vereinbarung Ihrer Organisation verwendet. Möglicherweise verwalten Sie ein spezifisches Projekt, für das ein eigenes Abonnement erforderlich ist, oder Sie müssen eine isolierte Umgebung erstellen, die separat für Projekte oder Teams abgerechnet wird.
- Sie bevorzugen es, Identitäten isoliert zu verwalten. Möglicherweise müssen bestimmte Identitäten von anderen getrennt bleiben, um den Zugriff auf Daten, Ressourcen und Apps zu schützen.