Ein Einblick in die Zuverlässigkeit von Facebook-Diensten

Produktionsingenieure

2009. SRE

2010. SRO und AppOps

2012. Produktionsingenieure

2014. Schließung der SRO

• Wir sind immer in Teams eingebaut. Wir haben im Allgemeinen keine SRE-Suche, wie bei Google, sondern für jeden Suchdienst separat.
• Wir sind nicht in den Produkten , sondern nur in der Infrastruktur, die das Produkt selbst verwaltet.
• Wir sind oncall zusammen mit den Entwicklern.
• Wir haben etwas mehr Erfahrung mit Systemen und Netzwerken, daher konzentrieren wir uns darauf, Dienste zu überwachen und zu löschen, wenn sie hell brennen. Wir beheben Fehler im Voraus, die von Anfang an zu Abstürzen führen und die Architektur neuer Dienste beeinflussen können, damit diese später in der Produktion reibungslos funktionieren.

Überwachung

OBEN AUF

ATOP ist wunderschön, wir benutzen es ständig.

Malloc HTTP

Thrift message
HTTP/1.1 400
"HTTP" == 0x48545450

malloc("HTTP")
pid = fork(); // errno = ENOMEM

malloc("HTTP")
pid = fork(); // errno = ENOMEM

// 0: heuristic overcommit
vm.overcommit_memory = 0

FB303

Service FacebookService {
    map<string, i64> getCounters()
}

incrementCounter(string& key);

setCounter(string& key, int64_t value);

Beobachtbarkeit

Tauchen

• Eine Tabelle, die die Versionen von Binärdateien und Paketen zeigt, wie viel Speicher auf allen Millionen von Computern belegt ist. Auf jedem Host wird einmal pro Stunde eine PS erstellt und an Scuba gesendet.
• Alle dmesg, alle Speicherabbilder werden an andere Tabellen gesendet. Wir führen Perf einmal alle 10 Minuten auf jedem Computer aus, damit wir wissen, welche Stack-Traces wir auf dem Kernel haben und was die globale CPU laden kann.

PHP-Debug

Dashboards

Wie es funktioniert

Wenn Facebook lag

Incident Manager Portal

Verhütung

• Unter normaler Last kommt die Anforderung an, wird verarbeitet und an den Client zurückgegeben.
• Bei hoher Auslastung warten Anforderungen in einer Warteschlange, da alle Threads für die Verarbeitung von Anforderungen ausgelastet sind. Die Verzögerung nimmt zu, aber bisher ist alles in Ordnung.
• Die Linie wächst, die Last steigt. Irgendwann endet alles, was der Server auf dem Client ausführt, mit einem Antwortzeitlimit, und der Client fällt mit einem Fehler aus. Zu diesem Zeitpunkt kann das Ergebnis des Servers einfach weggeworfen werden.

Werkzeuge

• Integrierter Kubismus in das System.
• FBAR ist ein „Arbeitstier“, das kommt und repariert, sodass sich niemand Sorgen um ein kaputtes Auto macht. Dies ist die Hauptaufgabe des FBAR, aber jetzt hat es noch mehr Aufgaben.
• Coredumper , den wir mit zwei Kollegen geschrieben haben . Es überwacht Coredumps auf allen Maschinen und legt sie zusammen mit Stack-Traces mit allen Host-Informationen an einem Ort ab: Wo liegt sie, wie findet man welche Größe? Vor allem aber sind Stack-Traces kostenlos, ohne GDB mit BPF-Programmen zu starten.

Umfragen

"Die Hauptverantwortung der Systemsoftware muss darin bestehen, weiter zu laufen. Die Erbringung von Dienstleistungen sollte als vorteilhafter Nebeneffekt des fortgesetzten Betriebs angesehen werden »

• "Was passiert, wenn Ihr System 10% der Last erhält?" Wenn die Leute denken: "Aber wirklich, was?" - Einsichten erscheinen und viele regieren sogar ihre Systeme. Früher haben sie nicht darüber nachgedacht, aber nach der Frage gibt es einen Grund.
• "Wer ist der erste, der normalerweise Probleme mit Ihrem Dienst bemerkt - Sie oder Ihre Benutzer?" Entwickler beginnen sich zu erinnern, wann dies passiert ist und: "... Vielleicht müssen Sie Warnungen hinzufügen."
• "Was ist dein größter Oncall-Schmerz?" Dies ist ungewöhnlich für Entwickler, insbesondere für neue. Sie sagen sofort: „Wir haben viele Warnungen! Lassen Sie uns sie reinigen und diejenigen entfernen, die nicht der Fall sind. “
• "Wie häufig sind deine Veröffentlichungen?" Zuerst erinnern sie sich daran, dass sie es mit ihren Händen freigeben, und dann haben sie ihre eigene benutzerdefinierte Bereitstellung.

6-7 Saint HighLoad++, . (, , ).
telegram- . !