Gastbeitrag von Tim Yocum, Ops Director bei Komponieren . Compose ist ein Datenbankdienst, der produktionsbereite, automatisch skalierende MongoDB- und Elasticsearch-Datenbanken bereitstellt.

Compose-Benutzer vertrauen darauf, dass unser Team sich um ihre Daten und Datenbanken kümmert. Unsere intelligente Infrastruktur und unsere klugen Mitarbeiter sind rund um die Uhr bereit, auf Warnmeldungen zu reagieren und alle Probleme zu lösen. Das ist Teil des Compose-Versprechens. Wir glauben jedoch, dass unsere Benutzer aus der Art und Weise, wie wir mit diesen Warnmeldungen umgehen, eine Lehre ziehen können.

Wachstum schafft Komplexität

Ein typischer Compose-Kunde hat zwei Hauptteile in seinem Stack: seinen Datenspeicher und seine Anwendung. Während die meisten Datenspeichervorfälle und -warnungen von uns behandelt werden, stellen wir fest, dass es oft keine Möglichkeit gibt, dass es in der Anwendung einen Mechanismus zum Generieren und Behandeln von Warnungen gibt. Das ist nicht beabsichtigt; leider sind es schon früh ihre eigenen Kunden, die sie wissen lassen, dass ihr System nicht funktioniert, und sie müssen organisch skalieren, um diese Beschwerden zu bearbeiten, sie in Probleme mit Ihrer Anwendung zu übersetzen, die Probleme zu priorisieren und das Problem zu lösen.

Wenn Sie jedoch Ihre Systeme und Ihr Unternehmen vergrößern, bedeutet diese organische Skalierung eine Belastung für Ihre Mitarbeiter und wirkt sich auf die Reaktionszeiten und die Qualität der Triage aus. Die Architektur Ihrer Anwendung wird komplexer, da es mehr bewegliche Teile und mehr Subsysteme gibt. An diesem Punkt erhalten wir häufig Anrufe zu Datenbankproblemen, die sich jedoch weiter oben im Stack des Kunden, in der Anwendung, herausstellen.

Rauchmelder

Einige Ihrer Systemkomponenten sind möglicherweise bereits mit Instrumenten oder Überwachungssystemen ausgestattet, sodass Sie eine Reihe von Warnmeldungen von Ihren Systemen erhalten. Durch Hinzufügen weiterer Instrumente können Sie die blinden Flecken abdecken. Andere Systeme können auch Leistungsmesswerte und regelmäßige Prüfungen bereitstellen. Indem Sie all dies in die Gleichung einbeziehen, können Sie für so viel Warnmeldungstransparenz und -sensibilität wie möglich sorgen.

Aber dann wird Ihnen klar, dass Sie mehr Alarme erstellt haben, die Ihre Mitarbeiter bearbeiten müssen. Es wird viel Lärm geben, weil Sie normalerweise feststellen werden, dass jeder einzelne Fehler einen Welleneffekt hat, der Alarme in verschiedenen Systemen auslöst. Einige der Fehler werden wie Rauchmelder sein, die ohne ersichtlichen Grund laut klingeln, während andere nur einen Alarm auslösen, aber massive Auswirkungen haben. Darüber hinaus erhalten Sie diese Alarme möglicherweise von mehreren Überwachungssystemen, die an verschiedene Personen gebunden sind. Sie könnten versucht sein, Ihr eigenes Alarmverwaltungssystem aufzubauen … aber das ist eine weitere Komponente, die überwacht werden muss, und Sie werden mehr Zeit mit der Entwicklung der Systemüberwachung verbringen als mit dem Ausbau Ihres Unternehmens.

Beantworten von Warnmeldungen bei Compose

Bei Compose besteht unser Geschäft darin, unseren Kunden Datenbankprobleme zu übermitteln, weshalb wir PagerDuty verwenden. Unsere älteren Nagios- und neueren Sensu-Serverüberwachungssysteme sind beide in PagerDuty integriert, um über den Gesamtzustand der Server zu berichten. Wir verwenden dann unser eigenes Compose-Plugin, um unsere Produktionssysteme auf High-Lock- und Stepdown-Ereignisse zu überwachen und diese ebenfalls in Warnungen umzuwandeln. Wir haben ein Premium-Support-Angebot und verwenden PagerDuty , um schnelle Antworten auf seine 911-Kontaktpunkte sicherzustellen. Unsere 911-Support-E-Mails werden von den E-Mail-Hooks von PagerDuty abgeholt, während die 911-Anrufe über Twilio an PagerDuty weitergeleitet werden und diese Anrufe ebenfalls in Warnungen umwandeln.

Nachdem die bei PagerDuty gesammelten, zusammengestellten und deduplizierten Warnmeldungen vorliegen, verwenden wir das Rotationsmanagement, um zwei gleichzeitig überlappende Rotationen von Supportmitarbeitern abzuwickeln. Der Hauptrotationsleiter ist der primäre Kontakt und der zweite ist ein Backup-Kontakt. Die Planung überschneidet sich, und wenn es Aufgaben gibt, die am besten von zwei Personen erledigt werden, können wir den primären und den sekundären Kontakt in die Aufgabe einbeziehen.

Wir fügen dieser Mischung dann das Betriebsteam hinzu, das als zusätzliches Backup fungiert. Schließlich stellen wir sicher, dass die geplanten Wartungsarbeiten die Bereitschaftsleute nicht unnötig alarmieren – niemand wird gerne beim Abendessen aufgeweckt oder gestört, nur um dann festzustellen, dass alles in Ordnung ist. Wir haben Skripte, die wir aufrufen, indem wir hubot die Hosts und Dienste herunterfahren und sicherstellen, dass Warnungen dieser Systeme in Nagios und Sensu erfasst und nicht an PagerDuty weitergeleitet werden.

PagerDuty ist zu einem unverzichtbaren Teil des Compose-Betriebs geworden. Früher mussten wir mehrere Systeme manuell überprüfen und einen Kalender verwenden, um den Bereitschaftsdienst zu planen. Jetzt sind wir effektiver, nicht nur, weil wir rechtzeitig Warnmeldungen erhalten, sondern auch, weil es uns intern hilft, die Last der Bereitstellung von qualitativ hochwertigem Support zu verteilen. Wir möchten es nicht mehr missen. – Ben Wyrosdick, Mitbegründer von Compose