Guten Abend allerseits!
Die Intensität unserer Starts variiert von Monat zu Monat. Bevor die September-Studenten den zweiten Monat des Kurses
„Devops - Practices and Tools“ beendet haben , eröffnen wir den nächsten Stream. Wir sind also wieder bereit, nützliche Materialien zu diesem Thema mit Ihnen zu teilen und warten auf nicht weniger nützliche
offene Lektionen .
Heute werden wir uns den ersten Teil des Artikels ansehen, in dem erläutert wird, wie die Dokumentation es SRE-Teams ermöglicht, neue und vorhandene Services zu verwalten.
SRE (Site Reliability Engineering, grob übersetzt als „Gewährleistung der Zuverlässigkeit von Informationssystemen“, Spezialisten auf diesem Gebiet tragen die gleiche Abkürzung) - eine spezielle Disziplin, Denkweise und eine Reihe technischer Ansätze, um den reibungslosen Betrieb von Webprodukten und -diensten sicherzustellen. SRE stehen an der Schnittstelle von Softwareentwicklung und Systemtechnik, lösen Betriebsprobleme und entwickeln skalierbare, zuverlässige und effiziente Lösungen für das Design, die Erstellung und den Betrieb von verteilten Großsystemen.
Die Hauptziele von SRE:
- Überwachung und Erfassung von Metriken - Ermittlung des gewünschten Verhaltens des Dienstes, Untersuchung des tatsächlichen Verhaltens des Dienstes und Beseitigung der Unterschiede.
- Incident Response - Erkennung und effektive Reaktion auf Servicefehler, um die Serviceverfügbarkeit im Einklang mit der SLA (Service Level Agreement) zu halten.
- Kapazitätsplanung - Prognose des zukünftigen Bedarfs und Bereitstellung der erforderlichen Menge an Rechenressourcen an den entsprechenden Standorten, um diesen Bedarf zu decken.
- Service-Skalierung - Vorhersehbare Bereitstellung und Entfernung der Rechenleistung eines Service in einem Rechenzentrum, häufig aufgrund der Kapazitätsplanung.
- Änderungsmanagement - Ändern des Verhaltens eines Dienstes, ohne seine Zuverlässigkeit zu verlieren.
- Leistung - Design, Entwicklung und Engineering in Bezug auf Skalierung, Isolation, Latenz, Durchsatz und Effizienz.
Der Fokus von SRE liegt auf dem Lebenszyklus: von der Idee und dem Design über die Bereitstellung, den Betrieb, die Leistungsverbesserung bis hin zur Stilllegung.
Vor dem Start des SRE-Dienstes unterstützen sie ihn durch Beratung im Bereich der Systemarchitektur, entwickeln Softwareplattformen, Frameworks und Kapazitätspläne und führen eine Startüberprüfung durch.
Wenn ein Dienst bereits ausgeführt wird, wird er von SREs wie folgt unterstützt:
- Sie messen und überwachen die Verfügbarkeit, Latenz und den Gesamtzustand des Systems.
- Überprüfen Sie geplante Systemänderungen.
- Sie skalieren die Stabilität des Systems mithilfe einiger Mechanismen, beispielsweise der Automatisierung.
- Verbessern Sie das System, indem Sie Änderungen fördern, die auf eine höhere Zuverlässigkeit und Geschwindigkeit abzielen.
- Führen Sie eine Reaktion auf Vorfälle und eine „unschuldige“ Obduktion durch.
Wenn die Lebensdauer eines Dienstes bald endet, wird er vom SRE auf vorhersehbare Weise mit klarer Erklärung und vollständiger Dokumentation außer Betrieb genommen.
Ein ausgereiftes SRE-Team verfügt immer über eine vollständige Dokumentation für jede SRE-Funktion. Wenn Sie ein SRE-Team verwalten oder planen, es zu organisieren, hilft Ihnen dieser Artikel dabei, die Dokumentationsarten zu verstehen, die Ihr Team benötigt, und hilft Ihnen dabei, die Arbeit an der Dokumentation parallel zu anderen Aufgaben des Teams zu planen und zu priorisieren.
Geschichte von SRE
Bevor wir die Nuancen der SRE-Dokumentation diskutieren, schauen wir uns einen Tag im Leben von Zoe an, der neu hergestellten SRE.
Zoes zweite Schicht in der SRE-Rolle ist beim Flaggschiffprojekt von AcmeSale bei Acme Inc. im Gange. Während sie sich nur an das Team anpasst, beobachtet sie die Arbeit ihrer Kollegen und macht sich Notizen. Aber jetzt hat sie noch einen Pager.
Wie es das Glück wollte, ruft der Pager um 2:30 Uhr morgens an. Die Nachricht lautet "Job Ragnarok lehnte sich zurück", Zoe hat keine Ahnung, was das bedeutet. Sie blättert in ihren Notizen und findet einen Link zur Haupt-Dashboard-Seite. Alles sieht in Ordnung aus. Sie versucht, im Acme-Intranet ein Dokument zu finden, das auf Ragnarok verweist, und nach einigen kostbaren Minuten findet sie ein veraltetes Dokument zur Servicearchitektur, das sich als kritische Abhängigkeit für AcmeSale herausstellt.
Glücklicherweise gibt es in der Disco einen Link zur Seite „Ragnarok Ops“, auf der ein Link zu einem Dashboard mit nützlichen Grafiken gefunden wurde. Die Seite erwähnt auch das Ragtool-Skript, das wahrscheinlich zur Lösung des Problems beitragen kann, aber Zoe hört zum ersten Mal davon. Daher sendet sie eine Pager-Hilfeanforderung an eine andere SRE mit langjähriger Erfahrung in diesem Service und diesen Tools. Leider gibt es keine Antwort. Zoe überprüft die E-Mails und sieht eine Nachricht, dass ihre Kollegin wegen gesundheitlicher Probleme eine Stunde lang offline ist. Nachdem sie alle Vor- und Nachteile abgewogen hat, ruft sie ihren Techniker an, aber der Anruf geht in die Voicemail. Alles deutet darauf hin, dass Sie dieses Problem selbst lösen müssen.
Nachdem sie einige Zeit nach Informationen über das mysteriöse Ragtool-Skript gesucht hat, findet sie ein Dokument mit einer kurzen Beschreibung der Befehlszeilenparameter sowie des Ortes, an dem es zu finden ist. Sie startet ein Ragtool - startet neu und drückt hoffnungsvoll die Daumen. Nichts ändert sich, der Verkehr sinkt noch mehr. Sie schaut sich verzweifelt die restlichen Befehlszeilenoptionen an, ist sich aber nicht sicher, ob sie nicht noch mehr schaden werden. Schließlich entscheidet sie sich für ragtool - rebalance e - dc = atlanta, da die Grafiken zeigen, dass das Problem besonders im Rechenzentrum von Atlanta auftritt. Die Verkehrskurve schleicht sich langsam an und Zoe freut sich über den Sieg. Die MTTR (mittlere Reparaturzeit) beträgt 45 Minuten.
Am nächsten Tag führt Zoe eine Obduktion des Vorfalls durch. Dies liegt daran, dass sich das Problem als besonders groß herausstellte und zu Einkommensverlusten führte. Außerdem fordert der Manager mehr Post-Mortem-Sitzungen an. Sie fragt das Team, wie der Rest der Teilnehmer dieses Problem lösen würde, und hört drei verschiedene Ansätze. Es stellt sich heraus, dass ein einziger Fehlerbehebungsprozess einfach nicht existiert. Ihre Kollegen geben auch zu, dass die Benachrichtigung „zurückgelehnt“ nicht der beste Name ist und der Fehler aufgrund eines bekannten Fehlers aufgetreten ist, der einfach keine Priorität hatte.
Schließlich fragt Steve, ihr Techlid: „Welche Version von Ragtool hast du bekommen?“ Und stellt dann fest, dass die verwendete Version schrecklich alt ist. Vor einer Woche wurde eine neue Version veröffentlicht, zusammen mit einer völlig neuen Dokumentation, die alle Funktionen beschreibt und sogar erklärt, wie das Problem „Job Ragnarok lehnte sich zurück“ zu lösen ist. Diese Version würde die MTTR auf fünf Minuten reduzieren.
Die Existenz einer neuen Version von Ragtool ist eine Überraschung für die Hälfte des Teams, während die andere Hälfte die neue Version und Anleitung mehr oder weniger kennt. Die neueste Version des Skripts befindet sich in Steves Home-Verzeichnis, offensichtlich im Ordner bin /. Zoe fügt dies ihren Notizen für die zukünftige Verwendung hinzu, in der Hoffnung, den Rest der Schicht ruhig zu verfeinern. Sie fragt sich, ob der Techlide oder einer aus dem Team sich mit den im Post-Mortem diskutierten Problemen befassen wird oder ob alle zukünftigen SREs eine so schmerzhafte Erfahrung machen müssen.
Später an diesem Tag nimmt Zoe an einem Meeting teil, bei dem das SRE-Team mit dem Entwicklungsteam über die Übertragung des Dienstes kommuniziert. Steve leitet das Meeting, stellt einige der zuvor gestellten Fragen zu Betriebsverfahren und dem aktuellen Problem der Servicezuverlässigkeit und bittet Entwickler, Änderungen vorzunehmen, bevor das SRE-Team die Verantwortung für den Service übernehmen kann. Zoe war bereits bei mehreren Rallyes von Steve und anderen hochrangigen SREs. Sie versteht, dass die gestellten Fragen und die von den Entwicklern verteilten Aufgaben sehr unterschiedlich sind, je nachdem, wer das Meeting abhält und mit welchem Problem sich das SRE-Team letzte Woche befasst hat.
Zoe träumt heimlich von einheitlicheren Standards und Verfahren, versteht aber noch nicht, wie sie dieses Ziel erreichen kann. Später hört sie zwei Entwickler über die Kaffeemaschine lachen, dass viele Fragen lose mit dem Pager zusammenhängen und sie im Allgemeinen nicht verstehen, woher sie kommen. Zoe möchte, dass die Entwickler verstehen, dass SRE nicht nur einen Pager bei sich hat. Als Zoe zum Arbeitsplatz zurückkehrt, findet sie mehrere Tickets, die aussortiert werden müssen, und denkt nicht mehr darüber nach.
Glücklicherweise sind alle Charaktere und Ereignisse in dieser Geschichte erfunden. Überlegen Sie sich dennoch, ob dies etwas ähnelt, dem Sie in der Realität begegnet sind. Die Lösung für die Probleme dieses fiktiven Teams liegt auf der Hand, und im nächsten Abschnitt werden wir sie genauer diskutieren.
Die Bedeutung der Dokumentation
In den frühen Phasen der Existenz des SRE-Teams ist die Organisation in hohem Maße von der Arbeit einzelner hochqualifizierter Personen innerhalb des Teams abhängig. Das Team speichert wichtige Konzepte und Prinzipien der Ausbeutung als Körner des „Stammeswissens“, das mündlich an neue Mitglieder des Teams weitergegeben wird. Wenn diese Prinzipien nicht vereinheitlicht und nicht dokumentiert sind, müssen sie höchstwahrscheinlich irgendwann durch Versuch und Irrtum wieder schmerzhaft gelehrt werden. Manchmal führen Teammitglieder Betriebsabläufe als strenge Abfolge von Schritten durch, die von ihren Vorgängern in der fernen Vergangenheit definiert wurden, ohne die Ursache-Wirkungs-Beziehungen dieser Schritte zu verstehen. Wenn dies nicht gestoppt wird, werden die Prozesse fragmentiert und degenerieren. Es kostet das Team nur, zu wachsen, um neue Probleme zu lösen.
Das SRE-Team kann diesen Prozess verhindern, indem es qualitativ hochwertige Dokumentationen erstellt, die als Grundlage für das Wachstum solcher Teams dienen, und einen systematischen Ansatz für die Verwaltung neuer und unbekannter Dienste einführt. Diese Dokumente bewahren Stammeswissen in der Form, in der es leicht zu finden, zu pflegen und zu suchen ist. Neue Teammitglieder werden durch ein systematisches und durchdachtes Programm geschult. Dies sind die Markenzeichen des reifen SRE-Teams.
Der Rest dieses Artikels beschreibt die verschiedenen Arten von Dokumenten, die SRE während des Lebenszyklus eines unterstützten Dienstes erstellt.
DAS ENDE
Im
nächsten Teil werden wir alle diese Typen im Detail betrachten, aber jetzt warten wir auf Ihre Kommentare und Fragen und laden Sie auch zu
einer offenen Lektion ein .