Welche Schritte unternehmen Sie, um ein neues Tool, eine neue Programmiersprache oder eine neue Abhängigkeit in Ihre Umgebung einzuführen? In diesem Artikel werde ich einen Rahmen aus sechs Fragen durchgehen, den ich verwende, um diese Feststellungen zu treffen.
Welches Problem versuche ich zu lösen?
Wir alle verstricken uns in die Kleinigkeiten des unmittelbar anstehenden Problems. Eine ehrliche, kritische Bewertung hilft, allgemeinere Ursachen aufzudecken und Mikrooptimierungen zu verhindern.
[Das könnte Ihnen auch gefallen: Sechs Bereitstellungsschritte für Linux-Dienste und die zugehörigen Tools]
Angenommen, Sie haben Probleme mit Ihrem Konfigurationsverwaltungssystem. Tägliche operative Aufgaben dauern länger als sie sollten, und die Arbeit mit der Sprache ist schwierig. Ein neues Konfigurationsmanagementsystem könnte diese Bedenken zerstreuen, aber stellen Sie sicher, dass Sie sich den Kontext dieses Systems genauer ansehen. Vielleicht löst der Wechsel von virtuellen Maschinen zu unveränderlichen Containern diese Probleme und mehr in Ihrer Umgebung, während es den gleichen Arbeitsaufwand bedeutet. An dieser Stelle sollten Sie auch die Machbarkeit umfassenderer Lösungen prüfen. Möglicherweise entscheiden Sie, dass dies aufgrund mangelnder organisatorischer Kenntnisse in Bezug auf Container derzeit kein durchführbares Projekt für die Organisation ist, aber wenn Sie diesen Kompromiss gewissenhaft akzeptieren, können Sie Container für das nächste Quartal auf eine Roadmap setzen.
Diese intellektuelle Übung hilft Ihnen, die Grundursachen aufzuschlüsseln und Kernprobleme zu lösen, nicht die Symptome größerer Probleme. Dies wird nicht immer möglich sein, aber treffen Sie diese Entscheidung bewusst.
Löst dieses Tool dieses Problem?
Nachdem wir das Problem identifiziert haben, ist es an der Zeit, uns selbst und das ausgewählte Tool kritisch zu prüfen.
Eine bestimmte Technologie mag ansprechend erscheinen, weil sie neu ist, weil Sie einen coolen Blogbeitrag darüber gelesen haben oder derjenige sein möchten, der einen Konferenzvortrag hält. Schnickschnack kann nett sein, aber das Tool muss die Kernprobleme lösen, die Sie in der ersten Frage identifiziert haben.
Was gebe ich auf?
Das Tool wird das Problem tatsächlich lösen, und wir wissen, dass wir das Richtige lösen Problem, aber was sind die Kompromisse?
Diese Überlegungen können rein technischer Natur sein. Wird das Fehlen von Observability-Tools ein effizientes Debugging in der Produktion verhindern? Macht es die Closed-Source-Natur dieses Tools schwieriger, subtile Fehler aufzuspüren? Ist die Verwaltung einer weiteren Abhängigkeit die betrieblichen Vorteile der Verwendung dieses Tools wert?
Geben Sie außerdem die größeren organisatorischen, geschäftlichen und rechtlichen Kontexte an, in denen Sie tätig sind.
Geben Sie die Kontrolle über einen kritischen Geschäftsablauf an einen Drittanbieter ab? Wenn dieser Anbieter seine API-Kosten verdoppelt, kann sich Ihr Unternehmen das leisten und ist es bereit zu akzeptieren? Sind Sie damit vertraut, dass Closed-Source-Tools mit sensiblen proprietären Informationen umgehen? Erschwert die Softwarelizenzierung die kommerzielle Nutzung?
Auch wenn es keine einfachen Fragen zu beantworten sind, erspart es Ihnen später viel Ärger, wenn Sie sich die Zeit nehmen, diese im Voraus zu bewerten.
Ist das Projekt oder der Anbieter gesund?
Diese Frage kommt mit dem Zusatz "für den Ausgleich Ihrer Anforderungen". Wenn Sie nur ein Tool benötigen, um Ihr Team über einen vier- bis sechsmonatigen Buckel bis zum Projekt X zu bringen vollständig ist, wird diese Frage weniger wichtig. Wenn es sich um eine mehrjährige Verpflichtung handelt und das Tool einen kritischen Geschäftsablauf steuert, ist dies ein Problem.
Nutzen Sie bei diesem Schritt alle verfügbaren Ressourcen. Wenn es sich bei der Lösung um Open Source handelt, sehen Sie sich den Commit-Verlauf, Mailinglisten und Forumsdiskussionen zu dieser Software an. Scheint die Community effektiv zu kommunizieren und gut zusammenzuarbeiten, oder gibt es offensichtliche Unterschiede zwischen den Community-Mitgliedern? Wenn Teil Ihres Kaufs ein Supportvertrag ist, nutzen Sie diesen Support während der Proof-of-Concept-Phase. Entspricht es Ihren Erwartungen? Ist die Qualität des Supports die Kosten wert?
Stellen Sie sicher, dass Sie auch bei der Bewertung von Open-Source-Tools einen Schritt über GitHub-Stars und -Forks hinausgehen. Etwas könnte auf die Titelseite eines Nachrichtenaggregators gelangen und einige Tage lang Aufmerksamkeit erregen, aber ein genauerer Blick könnte zeigen, dass nur ein paar Kernentwickler tatsächlich an einem Projekt arbeiten und sie Schwierigkeiten hatten, Beiträge von außen zu finden. Vielleicht ist ein Tool Open Source, aber ein vom Unternehmen finanziertes Team treibt die Kernentwicklung voran, und die Unterstützung wird wahrscheinlich eingestellt, wenn diese Organisation das Projekt aufgibt. Vielleicht hat sich die API alle sechs Monate geändert, was den Leuten, die frühere Versionen übernommen haben, viel Ärger bereitet.
Was sind die Risiken?
Als Technologe verstehen Sie, dass nichts jemals nach Plan läuft. Netzwerke fallen aus, Laufwerke fallen aus, Server werden neu gestartet, Zeilen im Rechenzentrum verlieren Strom, ganze AWS-Regionen werden unzugänglich oder BGP-Hijacks leiten Hunderte von Terabyte an Internetverkehr um.
Fragen Sie sich, wie dieses Werkzeug versagen könnte und was die Auswirkungen wären. Wenn Sie Ihrer CI/CD-Pipeline ein Produkt eines Sicherheitsanbieters hinzufügen, was passiert, wenn der Anbieter ausfällt?
Dies bringt sowohl technische als auch betriebswirtschaftliche Überlegungen mit sich. Gehen die CI/CD-Pipelines einfach aus, weil sie den Anbieter nicht erreichen können, oder haben Sie einen „Fehler beim Öffnen“ und lassen die Pipeline mit einer Warnung abschließen? Dies ist ein technisches Problem, aber letztendlich eine geschäftliche Entscheidung. Sind Sie bereit, mit einer Änderung, die den Sicherheitsscan in diesem Szenario umgangen hat, in die Produktion zu gehen?
Offensichtlich wird diese Aufgabe schwieriger, wenn wir die Komplexität des Systems erhöhen. Glücklicherweise konsolidieren Websites wie k8s.af beispielhafte Ausfallszenarien. Diese öffentlichen Postmortems sind sehr hilfreich, um zu verstehen, wie eine Software ausfallen kann und wie man dieses Szenario plant.
Wie hoch sind die Kosten?
Die Hauptüberlegungen hier sind die Arbeitszeit des Mitarbeiters und gegebenenfalls die Kosten des Anbieters. Ist diese SaaS-App billiger als mehr Personal? Wenn Sie mit diesem neuen CI/CD-Tool jedem Entwickler im Team zwei Stunden pro Tag einsparen, amortisiert sich das im nächsten Geschäftsjahr?
Zugegeben, nicht alles muss kostensparend sein. Vielleicht ist es nicht kostenneutral, wenn Sie dem Entwicklerteam ein paar Stunden am Tag sparen, aber Sie entfernen einen großen Blocker in ihrem täglichen Arbeitsablauf, und sie wären viel glücklicher darüber. Dieses Glück ist wahrscheinlich die finanziellen Kosten wert. Das Onboarding neuer Entwickler ist kostspielig, unterschätzen Sie also nicht den Wert einer erhöhten Bindung, wenn Sie diese Berechnungen durchführen.
[ Ein kostenloser Leitfaden von Red Hat:5 Schritte zur Automatisierung Ihres Unternehmens. ]
Abschluss
Ich hoffe, Sie fanden diesen Rahmen aufschlussreich, und ich ermutige Sie, ihn in Ihre eigenen Entscheidungsprozesse einzubeziehen. Es gibt keinen einheitlichen Rahmen, der für alle Entscheidungen funktioniert. Vergessen Sie nicht, dass Sie manchmal Ihrem Bauchgefühl folgen und eine Entscheidung treffen müssen. Ein standardisierter Prozess wie dieser hilft jedoch dabei, zwischen den Zeiten zu unterscheiden, in denen Sie eine Entscheidung kritisch analysieren können, und in denen Sie diesen Sprung wagen müssen.