| Einführung | SRE ist die Abkürzung für Site Reliability Engineering. Es handelt sich um ein neues Betriebs- und Wartungsmodell, das aus dem internen technischen Supportprozess für Produkte von Google hervorgegangen ist und den Verantwortungsbereich der neuen Position definiert. Im Gegensatz zum herkömmlichen Betriebs- und Wartungsmodell legt SRE den Schwerpunkt auf automatisierte Systeme und befürwortet die Entwicklung einiger szenariobasierter automatisierter Betriebs- und Wartungstools durch Software-Engineering-Methoden, um sich wiederholende und manuelle Vorgänge zu ersetzen. In diesem Chat werden wir die Entwicklung der SRE-Automatisierung anhand einiger Fälle ausländischer SRE-Praktiken vorstellen. |
Inhalt umfasst:
Der Wert automatisierter Systeme für SREs;
Die Entwicklung von Automatisierungssystemen;
SRE-Automatisierungsanwendungsfälle ausländischer Internetunternehmen;
Automatisierungspraxis im häuslichen Betriebs- und Wartungsbereich.
Der Vizepräsident von Google SRE ist Ben Treynor. Als er 2003 in das Unternehmen eintrat, bestand seine erste Aufgabe darin, ein siebenköpfiges „Produktionsbetriebs- und Wartungsteam“ zusammenzustellen. Doch bald stellte er fest, dass das traditionelle Betriebs- und Wartungsmodell aufgrund der Geschwindigkeit der Zunahme von Google-Maschinen die Anforderungen an zuverlässigen Betrieb und Wartung nicht schnell erfüllen konnte. Da er selbst ein leitender Softwareentwickler ist, hat er dieses Betriebs- und Wartungsteam wie ein Forschungs- und Entwicklungsteam aufgebaut. Wir haben viele F&E-Ingenieure eingestellt, die über Entwicklungskapazitäten und einige Kenntnisse im Systemmanagement verfügen. Das Wichtigste ist, dass sie sich wiederholende Arbeiten verabscheuen. Sie verfestigen einige Best Practices, Methoden, Prozesse und Methoden in Code und verwenden diese Methode, um die Skalierungserweiterung und die zunehmende Komplexität zu bewältigen.
2. Der Wert des Automatisierungssystems für SRE Typische SRE-Aktivitäten sind in vier Teile unterteilt: Software-Engineering, System-Engineering, Trivia und Prozesslast. Darunter können wir sehen, dass es eine Art von Arbeit gibt, die in direktem Zusammenhang mit den täglichen Betriebs- und Wartungsdiensten steht, die jedoch in SRE als ineffiziente Arbeit definiert wird und Google immer noch ein spezielles Wort verwendet – Mühe, um sie zu beschreiben.
Trivia ist manuelle, sich wiederholende und taktische Arbeit in Betriebs- und Wartungsdiensten. Sein Wachstum verläuft linear mit dem Wachstum der Dienstleistungen. Dieser Teil der Arbeit kann automatisiert werden. Google hat öffentlich vorgeschlagen, dass SREs sicherstellen sollten, dass mindestens 50 % ihrer Zeit für Software-Engineering-Projekte aufgewendet werden, denn wenn sie nicht kontrolliert werden, werden triviale Dinge immer zahlreicher und nehmen schnell den größten Teil der Zeit des SRE-Personals in Anspruch. Die Aufgabe, triviale Dinge zu reduzieren und den Leistungsumfang zu erweitern, ist das E (Engineering) in SRE.
Aus diesem Video können wir ersehen, dass der Wert der Automatisierung für SRE hauptsächlich auf zwei Aspekten beruht: Leistung und Effizienz. Wenn es um Automatisierung geht, denken viele Menschen zuerst an die Verbesserung der Effizienz. Tatsächlich legen SRE-Mitarbeiter im Vergleich zur bloßen Effizienzsteigerung Wert auf das Gleichgewicht zwischen Systemleistung, Geschwindigkeit und Flexibilität. Die Automatisierung stellt die Systemleistung sicher, indem sie durch manuelle Ausführung im Betrieb verursachte Inkonsistenzen beseitigt und „eine konsistente Ausführung von Verfahren mit einem klaren Umfang und bekannten Schritten“ gewährleistet.
Automatisierungssysteme können eine skalierbare und breit anwendbare Plattform bieten. Die Plattform kann Probleme zentralisieren, Systemfehler in großem Umfang bewältigen und Aufgaben kontinuierlicher und häufiger ausführen als Menschen. Und da die Plattform ihre eigenen Leistungsindikatoren offenlegen kann, kann sie uns auch dabei helfen, Details zu entdecken, die im vorherigen Prozess nicht leicht erkennbar waren. Die Grundlage der Plattformisierung liegt natürlich in der richtigen Gestaltung und Umsetzung. Für uns ist es einfacher zu verstehen, welche Effizienzsteigerung die Automatisierung mit sich bringt. Obwohl wir häufig den Aufwand und die Zeit vergleichen und analysieren, die für das Schreiben eines automatisierten Programms aufgewendet werden, und den Teil, der durch den Wegfall manueller Arbeit eingespart wird, sollten wir erkennen, dass nach der Implementierung der Automatisierung ein bestimmter Vorgang vom spezifischen Bediener entkoppelt wird. Wenn wir also fortfahren, wann Gemessen sollte der durch die Automatisierung eingesparte Zeit- und Arbeitsaufwand allen Benutzern zugute kommen.
Joseph Bironas, ein SRE, der für den Online-Prozess des Google-Rechenzentrumsclusters verantwortlich ist, sagte einmal: „Wenn wir weiterhin Prozesse und Lösungen produzieren, die nicht automatisiert werden können, werden wir weiterhin Leute brauchen, die die Systemwartung durchführen. Wenn wir Leute einstellen müssen.“ Es ist, als würde man die Maschinen mit menschlichem Blut, Schweiß und Tränen füttern. Es ist wie eine Matrix-Welt ohne Spezialeffekte, aber voller wütender Systemadministratoren
3. Die Entwicklung der Automatisierung
Der Automatisierungsprozess von Google SRE hat die oben genannten Phasen durchlaufen. Die erste Stufe ist eine Nicht-Automatisierungsstufe, die vollständig auf manuellen Vorgängen basiert und dann extern verwaltete systemspezifische Automatisierungsskripte für den Betrieb verwendet. Die spezifische Systemautomatisierung entwickelt sich schrittweise zu einer allgemeinen Systemautomatisierung und ersetzt dann extern verwaltete Automatisierungssysteme durch intern verwaltete Automatisierung Das automatisierte System entwickelte sich schließlich zu einem automatisierten System, das in die Betriebs- und Wartungsplattform integriert ist und keine manuelle Auslösung erfordert.4. SRE-Automatisierungsanwendungsfälle ausländischer Internetunternehmen
Googles Ressourcenverwaltungssystem Borg ist ein typisches automatisiertes Anwendungsfreigabesystem, das Google SRE seit langem verwendet. Warum ist Ressourcenmanagement so wichtig? Weil der Umfang zu groß ist, werden die Betriebskosten zum einzigen Hindernis für die Entwicklung. Technisch gesehen ist ein einheitliches Ressourcenmanagementsystem sehr schwierig zu implementieren, und die Qualität der Infrastruktur bestimmt die Leistungsfähigkeit dieses Systems. Insbesondere in einer verteilten Umgebung sind die Anforderungen an physische Server in verschiedenen Geschäftsszenarien nicht genau gleich. Voraussetzung dafür, dass Googles Borg ein einheitliches Ressourcenmanagement erreicht, ist die Unterstützung von Kerntechnologien wie GoogleFS, BigTable, Chubby, GSLB usw. SRE ist der Nutzer dieses Systems und gibt ständig Feedback und verbessert die Nutzung des Borg-Systems für die Systemzuverlässigkeit . Anforderungen, bisher ist Borg immer noch das von Google intern verwendete Anwendungsveröffentlichungssystem.Erstens ist das Borg-System eine vollständig geschichtete Systemarchitektur. Vom einfachsten Dateisystem bis zum Top-Load-Offloading ist jede Ebene des Technologie-Stacks innerhalb von Google einzigartig. Der Vorteil besteht darin, dass Erfahrungen gesammelt und wiederverwendet werden können. Auch die Systemarchitektur inländischer Unternehmen durchläuft im Entwicklungsprozess eine hierarchische Organisationsstruktur. Abgesehen von menschlichen Faktoren werden viele Hierarchien durch die Kombination mehrerer Systeme aufgebaut. Oberflächlich betrachtet haben wir die Kosten gesenkt, aber in Wirklichkeit haben wir die Kosten für die Personalwartung erhöht. An diesem Punkt können wir die Weiterentwicklung ausländischer Systeme außer Acht lassen. Was sollten wir bei der Auswahl der Technologie tun? Erfahrungsgemäß ist das einschichtige System, das aus mehreren von Kollegen gemeinsam genutzten Open-Source-Systemen besteht, eine Abkürzungsmethode mit offensichtlichen kurzfristigen Auswirkungen. Sobald sich das Geschäft eines Unternehmens rasant entwickelt, ist jedes Refactoring ein verheerendes Werkzeug für den Umschwung und den Neuanfang. Aufgrund meiner Erfahrung in verschiedenen Unternehmenssystemen, ob groß oder klein, verstehe ich diese Dynamik des Wandels zutiefst. Bei SRE besteht die Idee des Werkzeugwechsels nicht darin, alte Open-Source-Tools durch neue Open-Source-Tools zu ersetzen, sondern unsere Zuverlässigkeitsanforderungen sollten die Anzahl der Tool-Auswahlen vereinfachen und auf dieser Grundlage wirklich unsere eigenen Bedürfnisse berücksichtigen Am Ende müssen wir den Weg zu selbstentwickelten Automatisierungssystemen gehen.
Zweitens ist die Infrastrukturtechnologie des Borg-Systems nicht etwas überflüssig? Offensichtlich kann der technologische Fortschritt die SRE-Methodik nicht ersetzen. Das beliebteste DevOps-Konzept in der Branche enthält derzeit keine weiteren Beschreibungen von Kosten und Zuverlässigkeit, sondern konzentriert sich auf verschiedene Praktiken wie Automatisierung und Verbesserung der Produktivität. Diese Praktiken können das Kernproblem der nachhaltigen Entwicklung von Geschäftsszenarien nicht lösen, nämlich die Kontrolle und Balance zwischen Geschäftszuverlässigkeit und Kostenkontrolle. Die SRE-Methode besteht darin, maximale Geschäftsvorteile bei niedrigsten Kosten zu erzielen. Daher wird für die SRE-Position ein Systembetriebs- und Wartungsingenieur eingestellt, der Code schreiben kann. Wenn Sie nur Betrieb und Wartung durchführen, können Sie definitiv keinen reinen Entwickler behalten. Daher sollten wir unseren kognitiven Spielraum erhöhen und das aktuelle interne Geschäftssystem des Unternehmens aus der Perspektive des Software-Engineerings lösen. Aus der persönlichen Erfahrung des Autors sind wir ein Technologieunternehmen, das Produkte entwickelt, darunter Testsysteme, Projektmanagementsysteme, Prozesskontrollsysteme, Freigabesysteme usw. Egal wie groß oder klein Ihr Unternehmen ist, Sie werden es brauchen. Ohne einen SRE-Treiber würden wir ein Tool wählen, um die Lücke zu schließen. Allerdings sind die Systeme nicht miteinander verbunden, und niemand intern kann die Iteration dieser Angelegenheit wirklich vorantreiben. Schließlich lassen wir dieses Problem einfach durch Betrieb und Wartung oder Entwicklung lösen. Die tatsächliche Situation ist, dass dieses Problem nicht vollständig gelöst werden kann.
Drittens ist SRE überall in ausländischen Internetunternehmen zu sehen, aber in China gibt es nur sehr wenige solcher Positionen oder die Verbreitung von Ideen. Liegt das an kulturellen Unterschieden? Der Autor ist der Ansicht, dass die Entwicklungsgeschwindigkeit im Prozess der kontinuierlichen Weiterentwicklung des inländischen Betriebs- und Wartungssystems definitiv langsamer ist als das derzeitige kognitive Niveau im Ausland. Aber mit dem Aufstieg von Taobao ist die technische Supportabteilung von Alibaba tatsächlich der beste Nachweis für inländisches SRE. Die Vorteile von SRE liegen auf der Hand, allerdings wird es sehr schwierig sein, das Unternehmen bei kleinen und mittleren Unternehmen bekannt zu machen. Das Kernproblem besteht darin, dass das System ausländischer technischer Dienstleister sehr solide ist. Wenn kleine und mittlere Unternehmen eine SRE-Transformation durchführen möchten, können sie auf die Lösungen einer großen Anzahl technischer Dienstleister zurückgreifen. Und Unternehmen sind bereit, einen Teil der Kosten für den Vorforschungsprozess solcher Technologien auszugeben. Inländische Unternehmen erwarten den Kauf ausgereifter Technologien und sind nicht bereit, Energie in die Infrastruktur zu investieren. Die Kostenkontrolle basiert auch auf Arbeitskostenüberlegungen, und es ist für Technologieanbieter schwierig, Handlungsspielraum zu haben. In einer solchen misslichen Lage kann die Entwicklung des Cloud-Computing-Geschäfts eine schmierende Rolle spielen. Mit anderen Worten: Die Shared Technology Economy könnte eine Möglichkeit für die Umsetzung von SRE in China sein. Beispielsweise ist Shuren Cloud, wo der Autor arbeitet, eine leichtgewichtige Anwendungsverwaltungsplattform, die das SRE-Konzept durch die Zusammenarbeit mit Unternehmen vervollständigt und den von Unternehmen geforderten Plattformaufbau vervollständigt. In diesem Kooperationsprozess dient das entwickelte System als Mehrwert und wird von der Shuren Cloud Platform in anderen Unternehmen gefördert, um eine Win-Win-Situation zu erreichen. Den Ergebnissen zufolge haben Unternehmen erfolgreiche SRE-Praxisergebnisse erzielt und technische Dienstleister haben Möglichkeiten zur SRE-Praxis gewonnen.
Viertens nutzen SREs Werkzeuge gut. Die Änderung in der Art und Weise, wie wir Probleme lösen, von der Problemlösung zur eingehenden Analyse des Problems und zur Bereitstellung eines Modells und einer Checkliste zur Lösung des Problems. Beispielsweise bietet SRE von Netflix eine Checkliste für SRE bei der Lösung der Linux-Systemleistung:
5. Automatisierungspraxis im häuslichen Betriebs- und WartungsbereichDer Autor beschränkt sich auf die schnelle Iteration der Entwicklung im häuslichen Betriebs- und Wartungsbereich und wird den aktuellen Stand der Automatisierungspraxis anhand der drei Bereiche mit der größten Besorgnis als Durchbruchspunkt aufschlüsseln.
1. Überwachung und Alarm
Es gibt viele Arten von Haushaltsüberwachungs- und Alarmtools, aber es gibt nur sehr wenige beliebte Lösungen, die implementiert werden können. Das von traditionellen Unternehmen am häufigsten verwendete Tool ist Zabbix. Darüber hinaus ist auch Open-Falcon, das von Xiaomi in China entwickelte Open-Source-Internet-Überwachungstool für Unternehmen, eine Option. In beiden Szenarien führt jedoch kein Weg an einer sehr direkten Frage vorbei: Wie können Sie Ihr Problem auf dem kürzesten Weg analysieren und das eigentliche Problem im Geschäftsszenario lösen? Aus Sicht der Überwachung gibt es mehrere Dimensionen: Systemebene, Geschäftsebene und Serviceebene. Bei der Behandlung von Problemen aus Sicht von SRE ist die Kapazitätsplanung der erste Schritt und nicht die Planung auf der Grundlage verschiedener Systemverzögerungen, die auf a priori-Erfahrungen basieren. Die Werkzeuge waren also von Anfang an nicht das schwierigste Problem. Nehmen Sie als Beispiel Zabbix. Die Dimensionen, die überwacht werden können, sind der Zustand des Systems, die QPS der Datenbank und der Speicher von Redis. Wenn die Website jedoch langsamer wird, kann ich aus Überwachungssicht nichts tun. Um das Problem zu ermitteln und zu lösen, ist eine vollständige Linkanalyse erforderlich. Wenn wir die DevOps-Erfahrung verfolgen, ist es unwahrscheinlich, dass wir diese Art von Frage stellen. Wenn jedoch ein Problem auftritt, wie kann der Server automatisch gewechselt oder die Kapazität automatisch erweitert werden, um das Problem zu lösen? Die Kostenkontrolle ist in einem DevOps-Szenario nicht kontrollierbar. Manager können nur Budgetkosten erzwingen, und weder Upstream noch Downstream können vollständig verstehen, wie viel der Geschäftsbetrieb kostet.
2. Protokollüberwachung
Inländische Protokollüberwachung nutzt in großem Umfang den ELK-Technologie-Stack (Elasticsearch, Logstash und Kibana). Dieser Technologie-Stack erfreut sich großer Beliebtheit und hat auch zahlreiche interne Protokollprobleme in Unternehmen gelöst. In tatsächlichen Szenarien ist die Verwaltung von Geschäftsprotokollen jedoch immer noch sehr mühsam. Eine davon ist die Abfrage von Echtzeitprotokollen und die zweite die Aggregation historischer Protokolle. Wie kann die Protokollabfrage effektiv genutzt werden? Das Qunar-Betriebs- und Wartungsteam hat eine Methode vorgestellt, mit der Entwickler auf Anfrage ELK-Dienste für interne Abteilungen bereitstellen können, um jederzeit ihre eigenen Geschäftsprotokolle abzufragen und zu analysieren. Protokoll. Nach Abschluss der Abfrage wird die ELK-Dienstinstanz automatisch zerstört. Der Autor glaubt, dass dieser innovative Ansatz tatsächlich die Praxis des SRE-Denkens ist.
3. Kontinuierliches Integrations- und Release-System
Das am häufigsten verwendete Tool für den Hausbetrieb und die Wartung ist die Verwendung von Jenkins zur Vervollständigung der kontinuierlichen Integration und Freigabe. Aber wir hören oft auf, intensiv zu üben, solange wir Jenkins verwenden können. Aus SRE-Sicht analysieren wir zunächst die geschäftlichen Schwachstellen der kontinuierlichen Integration, da während des Prozesses der kontinuierlichen Integration das Testsystem verbunden wird. Daher ist der Autor der Ansicht, dass der Zweck der kontinuierlichen Integration darin besteht, die Produktqualität kontinuierlich zu verbessern. Mit Blick auf die Kernziele kontrollieren wir nicht nur, wie Jenkins-Jobs verwaltet werden, sondern auch, ob die Effizienz des Testens verbessert und die Integrationszeit verkürzt werden kann. Die Erstellung einer Zielliste und deren anschließende Einbindung in den SRE-Verbesserungsprozess wird sicherlich zu unterschiedlichen Ergebnissen führen. Kontinuierliches Publizieren ist ein weiteres Thema. Tatsächlich besteht das Problem darin, dass Benutzer das Publizieren nicht vollständig verstehen. Die Veröffentlichung umfasst Graustufen-Veröffentlichung, Test-Veröffentlichung, fortlaufende Veröffentlichung, Rollback-Veröffentlichung und andere Szenarien. Und jedes Szenario sollte umkehrbar sein. Wie lässt sich dieses Problem lösen? Jenkins allein kann dieses Problem nicht lösen. Sie benötigen erweiterte Tools, um es zu lösen, beispielsweise die Unterstützung einer Reihe leichter Anwendungsverwaltungsplattformen.
6. ZusammenfassungGemessen an der Entwicklungsgeschichte der Branche ist die Technologiestandardisierung ein unvermeidlicher Evolutionsprozess, und die Betriebs- und Wartungsautomatisierung ist tatsächlich eine Manifestation der Standardisierung. Ab dem ersten Schritt des Einstiegs in SRE sollten Arbeitsverantwortungen geklärt und geklärt sowie zu lösende Probleme in einer Checkliste dokumentiert werden. Ermöglichen Sie eine schnelle Umsetzung im Unternehmen. Der nächste Schritt besteht darin, diese Geschäftsindikatoren und -szenarien zu visualisieren, um dem Unternehmen dabei zu helfen, die Betriebskosten zu senken und die Ziele des Servicesystems zu quantifizieren. Für leistungsfähige Unternehmen werden die Schnittstellen verschiedener Ressourcen während des Entwicklungsprozesses vereinheitlicht. Nach Erfahrung des Autors sollte er in kleinen Schritten wiederholt und entsprechend den tatsächlichen Ergebnissen umgesetzt werden. Denn die Plattformisierung unabhängig von den Kosten ist nur eine glorreiche politische Errungenschaft und löst das Kostenproblem nicht wirksam. Die höchste Form der Automatisierung ist definitiv ein intelligentes System, aber aus Sicht des Autors hat vielleicht jeder zu viele Science-Fiction-Filme gesehen, was den Zweck der Softwareentwicklung verwässert hat, nämlich den Einsatz wissenschaftlicher Methoden zur Maximierung des Softwarenutzens. Aber es handelt sich definitiv nicht um ein hochintelligentes Selbstheilungssystem. Nach Ansicht des Autors stellt dieses künstliche Intelligenzsystem eine weitere Dimension der Softwareentwicklung dar, genau wie der Vergleich zwischen Nokia-Mobiltelefonen und Apple-Mobiltelefonen. Das SRE-Modell löst, wie die aktuelle Toolkette sinnvoll genutzt werden kann, um den Wert von Nokia-Mobiltelefonen zu maximieren Telefone, anstatt durch ein künstliches Intelligenzsystem ersetzt zu werden. Vielleicht wird SRE eines Tages in der Zukunft direkt in den Ruhestand gehen und Roboter das gesamte Betriebs- und Wartungssystem ersetzen lassen, aber SRE wird letztendlich tiefe Spuren in der Geschichte der Technologie hinterlassen.
Das obige ist der detaillierte Inhalt vonAnwendung der automatisierten Evolution in SRE. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
