Um dieses Thema zu beenden: Stimmt es, dass Betriebs- und Wartungsarbeiten nicht mehr durchgeführt werden können?

Letzten Freitag hatten Ma Chi und Lai Wei einen Online-Austausch. Das Thema war: Sind Betriebs- und Wartungsstellen wirklich nicht mehr verfügbar? Als Gastgeber bin ich sowohl der Initiator als auch der Moderator :) Ich habe sehr davon profitiert, den beiden Veteranen zuzuhören, wie sie einige ihrer jeweiligen Meinungen äußerten. Nehmen Sie es unbedingt noch heute auf, um es nicht zu vergessen. Es kann als Rückblick auf die Live-Übertragung betrachtet werden.

Über die Werkzeugplattform

Die Werkzeugplattform wird einen Teil der Arbeitskräfte ersetzen. Das ist eigentlich offensichtlich und bedarf keiner Einführung.

Aber wer wird die Tool-Plattform bauen? Das ist einen Blick wert. Überwachungssysteme, CI/CD-Plattformen, Chaos-Engineering-Plattformen, Middleware-Dienste usw. sind alle Plattformen und werden von Platform Engineer, auch PE genannt, erstellt. PE ist offensichtlich in viele Gruppen unterteilt, und jede PE-Gruppe ist für eine begrenzte Anzahl von Plattformen verantwortlich. Diese verstreuten PE-Teams können zu einem großen Team zusammengefasst werden, beispielsweise dem Infrastrukturteam, oder sie können in mehrere Teams aufgeteilt werden. Beispielsweise kann das PE-Team für die technische Leistung in einer Abteilung (z. B. der Abteilung für Leistungstechnik) untergebracht werden ), Datenbank und Big Data sind in einer Abteilung (z. B. der Datenabteilung) und die mit der Stabilitätssicherung verbundenen PE-Teams in einer Abteilung (z. B. der Betriebs- und Wartungsabteilung) untergebracht.

Die Aufteilung dieser Organisation kann in verschiedenen Unternehmen unterschiedlich sein. Die Beziehung ist nicht sehr groß. Der Schlüssel ist, wie das PE-Team seine Arbeit ausführen soll. Der Kern des PE-Teams muss Folgendes tun:

• Eine nützliche Plattform aufbauen, die es dem Forschungs- und Entwicklungsteam des Unternehmens ermöglicht, Self-Service anzubieten.
• Die Plattform sollte Best Practices sammeln. Die Plattform muss das Unternehmen zufriedenstellen, muss aber auch über Best Practices der Branche verfügen. Wenn die Geschäftsanforderungen im Widerspruch zu den Best Practices der Branche stehen, sollten sich die Best Practices der Branche so weit wie möglich durchsetzen, wenn dies kurzfristig wirklich unmöglich ist , es sollte auch formulieren Wir müssen den Plan Schritt für Schritt umsetzen und danach streben, ihn in Zukunft zu erreichen. Andernfalls wird es auf der Plattformseite immer unangenehmer Am Ende wird es überwältigt und es wird ein Chaos sein. Wir müssen alle Möglichkeiten finden, Spezifikationen umzusetzen, anstatt Regeln und Vorschriften zu verwenden Eine Spezifikation, die von Geschäftsprogrammen verlangt, keine lokalen Festplatten zum Speichern von Statusdaten zu verwenden. Sie haben dies nicht als Red-Line-Gesetz verkündet, aber es sagt der Geschäftsseite eindeutig, dass der Container regelmäßig neu gestartet wird, damit der Container driften kann! Tatsächlich sollten Benutzer von AWS wissen, dass virtuelle AWS-Maschinen manchmal aus unerklärlichen Gründen neu gestartet werden. Es liegt in der Verantwortung der Anwendungsentwickler, hochverfügbare Anwendungen für eine unzuverlässige Infrastruktur bereitzustellen Architekten, die gut in Datenbanken sind, sind möglicherweise nicht gut in Hadoop, Architekten, die gut in Hadoop sind, sind möglicherweise nicht gut in Beobachtbarkeitssystemen, und Architekten, die gut in Beobachtbarkeitssystemen sind, sind möglicherweise nicht gut in Chaos Engineering.
• Aber nicht alle Plattformen werden über Nacht erstellt. Was ist, wenn Sie diese Plattformen noch nicht haben? Das Unternehmen sollte zuerst einen COE einstellen und diesen als Unternehmensberater fungieren lassen, während er die Fähigkeiten der Plattform aufbaut. Das Geschäft entwickelt sich schnell und die Eigenentwicklung der Plattform ist zu langsam. Es kann auch sein, dass es Lösungen von externen Lieferanten sucht . Auch das COE selbst kann je nach Situation externe Lösungen suchen.
• Über externe Anbieter

Intuitiv wird jeder das spüren: Europäische und amerikanische Unternehmen sind eher bereit, SaaS-Dienste zu kaufen, während inländische Unternehmen eher bereit sind, ihre eigenen Dienste auf Basis von Open Source aufzubauen. Liegt es daran, dass die inländische Firmenphilosophie nicht gut ist? Nicht wirklich. Das Kernproblem ist der Mangel an zuverlässigen ToB-Unternehmen und -Produkten in vielen inländischen Bereichen. Stellen Sie sich vor, ein ToB-Unternehmen könnte Partei A Folgendes bieten:

Ausgezeichnete, fortschrittliche Methodik

Stabile, benutzerfreundliche Produkte

• Ausgezeichnetes, stabiles Kundenerfolgsteam, das Kunden hilft, die besten Lösungen besser in die Praxis umzusetzen
• in Bezug auf Vom Preis her ist es günstiger als die eigene Personalrekrutierung und Selbstrecherche von Partei A
• Solange das Gehirn des CXO nicht kaputt ist, wird er sich auf jeden Fall dafür entscheiden, einen solchen externen Lieferanten einzuführen. Aber gibt es ein solches ToB-Unternehmen? Das ist ein großes Fragezeichen. Wir haben Kuaimao Nebula gegründet, um unseren Kunden Observability-Produkte anzubieten, und sind bestrebt, ein solcher Lieferant zu werden. Ich hoffe, dass die ToB-Kollegen in der Branche zusammenarbeiten werden!
• Um auf das Thema Berufswahl einzugehen: Auch wenn es derzeit in einem bestimmten Segment möglicherweise keinen guten Anbieter gibt, wie sieht es in 3 Jahren aus? Wie sieht es in 5 Jahren aus? Hat das Ausland bereits die Führung übernommen? Gibt es Lieferanten mit gutem Potenzial in China? Wenn du es schon hast, Bruder, traust du dich dann trotzdem, dich weiterhin diesem Nischenfeld zu widmen? Hätten wir im Voraus einige Pläne machen sollen?

Natürlich sind wir bei unseren Vorhersagen für die Zukunft meist zu optimistisch oder zu pessimistisch. Wenn es um Zeitschätzungen geht, treffen wir in der Regel sowohl zu frühe als auch zu späte Vorhersagen. Das ist richtig, Bruder, es hängt davon ab, wie du urteilst.

Über die Notfall-Fehlerbehandlung

Sollte die OnCall-Fehlerreaktion von der Forschung und Entwicklung übernommen werden? Oder Betrieb und Wartung? Diese Frage ist sehr interessant. Ma Chi glaubt, dass 80 % der Online-Fehler auf Änderungen zurückzuführen sind, die von der Forschung und Entwicklung vorgenommen werden, und dass die Forschung und Entwicklung offensichtlich besser auf OnCall-Fehler reagieren kann, was bedeutet, dass die Forschung und Entwicklung schneller auf 80 % der Probleme reagieren kann.

Geschäftsforschung und -entwicklung sind wie folgt: Datenbankänderungen, grundlegende Netzwerkänderungen und Zugriffsschichtänderungen sind für die Person, die die Änderung vornimmt, sinnvoller, auf den Fehleralarm ihres eigenen Dienstes zu reagieren.

Tatsächlich hängt dies von zwei Voraussetzungen ab:

1. Überwachung und Beobachtbarkeit sind gut genug und Probleme, die durch Änderungen verursacht werden, können über diese Plattform rechtzeitig erkannt werden. Ich hoffe, dass jedes Unternehmen über einen vollständigen Satz an Beobachtbarkeit verfügt Beobachtungssystem
2. Die durch Änderungen verursachten Probleme werden sofort sichtbar. Wenn die durch einige Änderungen verursachten Probleme erst eine Woche später auftreten, wird es für die Person, die die Änderung vorgenommen hat, schwierig sein, an sich selbst zu zweifeln

Tatsächlich können wir Behandeln Sie die Änderung in zwei Situationen. Die anschließende Überwachung der Dienststabilität liegt in der Verantwortung der Person, die die Änderung vorgenommen hat, und sollte separat behandelt werden. Wer sollte also den täglichen OnCall übernehmen? Es sollten diejenigen sein, die direkt an der Fehlerlokalisierung und -unterbrechung beteiligt sein können. Der Grund liegt auf der Hand. Wenn die OnCall-Person einen Alarm erhält und andere kontaktieren muss, ist die Aktualität der Fehlerunterbrechung zu gering.

Also zunächst einmal sollten die Alarme in verschiedenen Kategorien verarbeitet werden. Verschiedene Personen OnCall verschiedene Alarme. Es ist unvernünftig, alle Alarme der Forschung und Entwicklung oder dem Betrieb und der Wartung zuzuordnen. Dieser absolute Ansatz ist unvernünftig.

Über die Änderungsfreigabe

Es besteht ein Konsens über das ultimative Ziel, das darin besteht, der Unternehmensforschung und -entwicklung die freie Veröffentlichung von Versionen zu ermöglichen, aber wir möchten auch kontrolliert werden, wir möchten sicher veröffentlichen und wir möchten die Geschäftskontinuität gewährleisten beim Loslassen. Dies stellt extrem hohe Anforderungen an das CI/CD-System.

Wenn es Ihnen egal ist: Wenn Sie die unterste Ebene des Systems ändern, müssen Sie lediglich ein Skript stapelweise auf mehreren Maschinen ausführen. Aber nachdem die oben genannten Anforderungen hinzugefügt wurden, wird es viel schwieriger und wird zu einem systematischen Projekt.

Auf der Seite der Unternehmensforschung und -entwicklung ist es notwendig, beobachtbare Punkte zu machen, und ein Überwachungssystem ist erforderlich, um Probleme rechtzeitig zu erkennen und den Freigabeprozess nach einem Alarm sogar automatisch zu blockieren. Es bedarf einiger Mittel zur Blue-Green-Freigabe und zur automatischen Code- und Sicherheitsscanfunktion. Es ist unangemessen, blindlings Forschung und Entwicklung zu fordern, um sicherzustellen, dass Änderungen rückgängig gemacht werden können Änderungen sind sicher. Der Grad der CI/CD-Fähigkeiten kann grundsätzlich Aufschluss über die technische Stärke des Unternehmens geben.

Wenn Ihr Unternehmen der Forschung und Entwicklung immer noch Frachtbriefe für Betrieb und Wartung zur Verfügung stellt und Betrieb und Wartung online abgewickelt werden, sollten Sie überlegen, ob dies sinnvoll ist. Natürlich ist der obige Ansatz eher ein Internet-Ansatz und möglicherweise nicht für alle Unternehmen geeignet. Diese Live-Übertragung liefert nur eine Idee, und Sie müssen selbst darüber nachdenken.

Natürlich, wie erreicht man diese ideale Situation? Wie sollten wir Schritt für Schritt vorgehen, bis dieser Idealzustand erreicht ist? Das Thema Zeit wurde in der Live-Übertragung nicht thematisiert. Wenn das Unternehmen für den Betrieb auf Kubernetes geeignet ist, ist es relativ einfach, ein solches System mit Kubernetes aufzubauen, und Sie können so schnell wie möglich Maßnahmen ergreifen. Wenn das Geschäft des Unternehmens in einer physischen Maschinen- oder virtuellen Maschinenumgebung ausgeführt werden muss, erstellen Sie zunächst eine einheitliche Plattform für die Änderungsfreigabe, schließen Sie dann die Lücken und verbessern Sie sie schrittweise.

Über Kostenoptimierung

Die beiden Gäste redeten nicht viel, aber alle waren in dieser Angelegenheit sehr vorsichtig. Erinnern Sie alle daran:

1. Menschen sind teurer als Hardware. Tun Sie niemals etwas, das 50 Millionen an Arbeitskräften kostet und 40 Millionen an Hardwarekosten einspart.
2. Lassen Sie genügend redundante Rechenleistung für das Unternehmen übrig, Nervös Das Budget für diese Charge wird nicht genehmigt. Wenn die Kapazität ausfällt, wird das Kundenerlebnis beeinträchtigt, die öffentliche Meinung wird negativ sein und der Gewinn wird die Verluste überwiegen Hardwarekosten von 3 Millionen, das Kaufvolumen beträgt 30 Millionen, um 3 Millionen Hardwarekosten einzusparen. Es ist wirklich scheiße
3. Zusammenfassung

Zu diesem Zeitpunkt ist das Plattformsystem noch nicht so vollständig. Die Verwendung der Self-Service-Plattform+COE+BP (Business Partner)-Architektur zum Aufbau eines Betriebs- und Wartungssystems scheint zuverlässig und umsetzbar zu sein. Wenn die Plattform in Zukunft gut genug ist, kann die Arbeitskraft von BP reduziert werden (BP hat nach und nach die Fähigkeit erlangt, COE durchzuführen). Wenn die Plattform weiterhin vollständig ist, kann der COE weiterhin reduziert werden Wartung und Forschung und Entwicklung sind möglicherweise nicht erforderlich.

Das obige ist der detaillierte Inhalt vonUm dieses Thema zu beenden: Stimmt es, dass Betriebs- und Wartungsarbeiten nicht mehr durchgeführt werden können?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!