Chef ist ein leistungsstarkes Betriebstool – seine Flexibilität und Automatisierungsfähigkeiten machen es in Organisationen mit umfangreichen Servicebereitstellungen äußerst beliebt. Unser eigener Ranjib Dey wurde eingeladen, bei Chefs jährlicher Konferenz, ChefConf, zu sprechen, die im April stattfand. Hier sind einige der Highlights von Ranjibs Vortrag „How To Mock a Mockingbird“ (benannt nach einem Buch über mathematische Philosophie).

Gehen Sie davon aus, dass Dinge kaputt gehen

„Design für Fehler“ ist vielleicht eine prägnantere Art, diesen Punkt auszudrücken. Es ist ein grundlegender Teil der PagerDuty Geschichte – PagerDuty wurde basierend auf dem Prinzip entwickelt, dass Krisen für alle Betriebsteams unvermeidlich sind. Unsere Rolle besteht darin, den Umgang mit diesen Krisen ein wenig angenehmer zu gestalten.

Ranjib schlägt vor, dass Entwickler Fehler als gegeben hinnehmen. Was DevOps-Teams tun können, um Fehler zu vermeiden, so Ranjib weiter, ist, sich darum zu bemühen, Fehler so „kostengünstig und isoliert“ wie möglich zu machen.

Design ist wichtig

Wenn die Planung für den Fall eines Ausfalls das „Warum“ in Ranjibs Diskussion ist (wie in „Warum sollte ich Ranjib ernst nehmen?“), ist das Code-Design das „Wie“. In einer Umgebung, in der Dinge kaputt gehen, ist die Risikominderung durch Design die beste Verteidigung gegen Ausfallzeiten.

In der Praxis bedeutet das laut Ranjib, den Code, den Sie bereitstellen, zu minimieren. Eine höhere Codekomplexität erschwert nicht nur das Testen, sondern schlankerer Code kann auch schneller ersetzt werden, wenn Fehler auftreten (was wiederum unvermeidlich ist).

„Alles, was in der Theorie komplex ist, wird schwer zu testen sein.“

Intelligent testen

Wie Sie Ihre Codebasis validieren, hängt eng mit dem tatsächlichen Erscheinungsbild des Codes zusammen. Das heißt, Ihre Testprozesse hängen von der Stärke des Codedesigns ab.

Ihr Code sollte beispielsweise in Happy-Path-Szenariotests gut funktionieren. Happy-Path-Szenarien, auch Akzeptanztests genannt, messen die Codeleistung in normalen Anwendungsfällen.

Das Codedesign wird erst dann wirklich validiert, wenn Ihre Dienste unter Stress gesetzt werden – und die beste Methode hierfür ist das Unit-Testing. Unit-Testing ist nicht nur sehr schnell, bemerkt Ranjib, sondern kann (im Idealfall) auch 80 bis 90 Prozent aller Fehler aufdecken. Das macht es zu einer besonders intelligenten Validierungsstrategie im Vergleich zu Akzeptanztests, die zwar umfassend, aber langsam sind (und eine steile Lernkurve mit sich bringen).

Ein weiterer Beleg für den Wert von Unit-Tests sei ihre Rolle bei der Durchsetzung der Codebasis-Konsistenz, so Ranjib weiter. Schnelle Unit-Tests helfen dabei, die Konventionalität im Code-Design aufrechtzuerhalten. Aus diesem Grund sollten Unit-Tests als grundlegende Testmethode betrachtet werden.

„Unit-Tests sind für die langfristige Wartbarkeit von unschätzbarem Wert.“

Kommunizieren Sie für optimale Ergebnisse

Wir sind Verfechter von Unit-Tests, weil sie Entwicklern ermöglichen, ihren Code von Anfang bis Ende zu verwalten (mit Unterstützung von Ops). In einer Umgebung, in der Entwickler und Ops auf gemeinsame Ziele hinarbeiten, ist Zusammenarbeit enorm wichtig – und damit Zusammenarbeit gedeihen kann, müssen alle miteinander kommunizieren.

Da Kommunikation ein entscheidender Bestandteil der DevOps-Kultur ist, sollte laut Ranjib der Abbau von Wissenssilos Priorität haben. Gutes Design ist das wichtigste Element gesunder Codebasen (wie in Ranjibs erstem Punkt dargelegt), und Design kann nicht gedeihen, wenn die Teams ihr Wissen nicht miteinander teilen.

„Kommunikation wird das Design beeinflussen.“

Machen Sie sich mit der Komplexität vertraut

Zwei von Ranjibs Folien illustrierten die Bedeutung der Kommunikation – eine zeigte eine typische Referenzcode-Topologie und die nächste ein Bild von einem Teller Spaghetti. Referenztopologien, argumentiert Ranjib, erfassen nicht alle Abhängigkeiten und Betriebsdienste, die in Bereitstellungen enthalten sind. Echte Topologien, so führt er weiter aus, ähneln viel mehr dieser Masse Spaghetti.

Ganz einfach: Moderne Codebasen werden zu komplex sein, um sie auf einfache Weise zu kommunizieren. Und die fehlertolerantesten Topologien werden skalenfrei sein – das heißt, sie enthalten eine Vielzahl von Knoten und Speichen, sodass kein einzelnes Element abhängig von einem anderen „verknüpft“ ist.

Die Idee, nicht zu wissen, wie alles in Ihrer Codebasis verbunden ist (und damit einverstanden zu sein), wurde von Netflix-Site-Reliability-Ingenieur Corey Bertram vorgebracht, als er im März bei PagerDuty HQ vorbeischaute. Coreys Vortrag veranschaulichte die Natur von Bereitstellungen und schlug vor, dass Die Annahme einer Zen-Haltung ist die einzig logische Antwort zu ihrer wilden Komplexität.

„Niemand weiß genau, wie eine fehlertolerante Netzwerkarchitektur aussehen sollte.“