Weniger zu bedenken: Verringerung der kognitiven Belastung für Entwickler

"Wenn man es baut, führt man es". Ich glaube an diese Idee. Teams, die ihre Produktionshilfe in sich tragen, bauen bessere Software. Aber irgendwo auf dem Weg, "Du führst es" wurde zu "Du musst Kubernetes verstehen, Helm, Terraform, IAM, Netzwerke, Beobachtbarkeit, Sicherheitsscan und drei CI-Systeme". Das ist viel zu tragen, zusätzlich zum eigentlichen Produktbau.

Dieses Gewicht hat einen Namen: kognitive Belastung.

Was bedeutet kognitive Belastung bei der Arbeit

Die Idee kommt von der Psychologie, und das Buch Teampotologien hat es in der Software populär gemacht. Jede Person und jedes Team hat eine begrenzte geistige Kapazität. Wenn zu viel davon für Dinge verwendet wird, die nicht ihre Hauptaufgabe sind, leidet ihre Hauptausgabe.

Es gibt ungefähr drei Arten:

• Eigene EigenschaftDie Komplexität des Problems selbst. Es ist schwierig, ein Zahlungssystem zu bauen. - Das ist gut.
• Ausländische: Komplexität, die nicht da sein muss. Verwirrende Werkzeuge, unklare Prozesse, zwölf Einsatzmöglichkeiten.
• Deutsch: die Anstrengung, Dinge zu lernen, die dich besser in deinem Job machen.

Die Aufgabe eines Plattformteams ist es, so viel Fremdlast wie möglich zu entfernen, damit Entwickler ihre Energie für die intrinsischen und germanischen Typen aufwenden können.

Wenn Ihre Entwickler Ihre gesamte Infrastruktur verstehen müssen, um eine Zeile Code zu ändern, ist die Infrastruktur das Problem.

Ich verstecke Kubernetes, vorsichtig.

Kubernetes ist ein perfektes Beispiel. Es ist leistungsfähig, aber ein einfacher Webservice benötigt eine Bereitstellung, einen Service, eine HTTPRoute oder Eintritt, eine ConfigMap, vielleicht einen HorizontalPodAutoscaler, einen PodDisruptionBudget, ein ServiceAccount, NetzwerkPolicies... Die meisten Entwickler müssen das nicht wissen.

Möglichkeiten, sie zu reduzieren:

• Eine gemeinsame Helm-Tabelle mit guten Standards. Die Werte-Datei des Entwicklers ist 15 Zeilen statt 300.
• Spezifikationen höherer Ebene Wie Score (eine Workload-Spezifikation, die beschreibt, was ein Dienst braucht, nicht wie es zu implementieren), oder Kro und Crossplane, um Ihre eigenen einfachen App - Die Ressource.
• Vorlagen Die Entwickler beginnen mit etwas, das funktioniert.

Das Wort "sanft" zählt. Verbergen Sie Kubernetes nicht so vollständig, dass das Debugging unmöglich wird. Machen Sie den einfachen Weg einfach und lassen Sie die Details für die Menschen, die sie brauchen, verfügbar sein.

Gute Standardeinstellungen schlagen gute Dokumentation

Jede Entscheidung, die Sie einen Entwickler machen lassen, ist ein kleines Stück Last. Die meisten haben eine vernünftige Antwort, die 90% der Zeit richtig ist.

Bringen Sie die Antworten auf die Plattform:

• Logs in einem strukturierten Format, automatisch versandt.
• Metriken und Tracing in der Basisbilder- oder Bibliothek eingerichtet.
• Ressourcenanfragen und -proben mit angemessenen Werten.
• Sicherheits-Einstellungen: Nicht-Root-Container, nur-lesbare Dateisystemen, Fähigkeiten fallen gelassen.
• Warnungen für die Grundlagen: Fehlerrate, Latenzzeit, Neustart.

Dokumentation ist immer noch wichtig, aber die beste Dokumentation ist die, die niemand lesen muss, weil die Standardvorgabe bereits richtig ist.

Zeichen, dass deine Plattform es noch schlimmer macht

Plattformteams können auch die kognitive Belastung erhöhen. Pass auf:

• Ein weiteres Werkzeug zum Lernen Das versteht nur das Plattformteam.
• Abstraktionen, die durchsickern: wenn etwas kaputt geht, müssen Entwickler sowohl die Abstraktion als auch alles darunter verstehen.
• Zu viele Möglichkeiten: "Sie können mit Option A, B oder C einsetzen" ist kein Selbstbedienung, es ist Hausaufgabe.
• Ständige Veränderung: eine neue Art, die Dinge jedes Quartal zu tun.

Fragen Sie Entwickler regelmäßig, was sie bremst. Wenn die Plattform auf dieser Liste steht, dann nehmen Sie es ernst.

Wie fängt man an?

Wählen Sie einen Bereich aus, in dem Entwickler am meisten kämpfen, oft die Konfiguration der Bereitstellung oder die Beobachtbarkeit. Reduzieren Sie die Anzahl der Dinge, die sie wissen müssen. Überprüfen Sie, ob Fragen an das Einsatzteam eingehen. Ich wiederhole.

Meine Meinung: Die beste Plattform ist die, die Entwickler kaum bemerken. Sie versenden einfach und die Dinge funktionieren.

Desly