Ist es notwendig, die Bereitstellung in der Produktion zu bestimmten Zeiten zu verbieten? Oder wurde die # NoDeployFriday- Bewegung zu einem Relikt der Zeit, als es keine umfassenden Integrationstests und keine kontinuierliche Bereitstellung gab?

In Ihrem Team stehen Sie möglicherweise vor dem gleichen Dilemma. Wer hat Recht und wer ist schuld? Ist es eine vernünftige Strategie, die Bereitstellung freitags abzubrechen, um Risiken zu reduzieren, oder ist es eine schlechte Kultur, die uns daran hindert, bessere und stabilere Systeme zu schaffen?

Ding Ding

Ich bin mir sicher, dass Ingenieure, die das Glück hatten, „in Kontakt“ zu sein, ihre freien Tage aufgrund all der Änderungen am Freitag verloren haben. Ich war auch in dieser Situation. Ein Anruf, wenn Sie mit Ihrer Familie oder mitten in der Nacht abreisen und Sie über den Absturz der Anwendung informieren. Nachdem Sie in den Computer eingestiegen sind und die schnell wachsenden Protokolle überprüft haben, wird deutlich, dass alles durch eine seltene, nicht behandelte Ausnahme ruiniert wurde. Ekelhaft.

Die Analyse zeigt, dass für das Szenario, das zum Ausfall führte, keine Tests geschrieben wurden, anscheinend weil dies nicht als wahrscheinlich angesehen wurde. Nach einer Reihe langwieriger Telefonanrufe mit anderen Ingenieuren auf der Suche nach einer besseren Möglichkeit, die Änderungen rückgängig zu machen und alles zu beheben, funktioniert das System wieder. Fuh.

Am Montag findet ein Fünf-Warum-Treffen statt.

" Lassen Sie uns einfach freitags aufhören zu implementieren. Dann wird am Wochenende alles stabil funktionieren, und nächste Woche werden wir nach allen Arten von Veröffentlichungen auf der Hut sein ."

Alle nicken. Wenn etwas am Donnerstag nicht vor Mittag in Betrieb geht, wartet es bis Montagmorgen. Schädigt oder hilft dieser Ansatz?


Wie Sie wissen, sind Twitter-Aussagen oft sehr subjektiv. Obwohl das Verbot von Freitagsveröffentlichungen vernünftig erscheint, wird jemand schnell darauf hinweisen, dass dies aufgrund der Fragilität der Plattform, die auf schlechte Test- und Bereitstellungsprozesse zurückzuführen ist, nur eine Krücke ist.

Einige schlagen sogar vor, dass Sie ruhige Bereitstellungen mehr mögen als das Wochenende selbst:


Andere Benutzer glauben, dass die Implementierung von Funktionsflags eine mögliche Lösung sein könnte.


Dieser Benutzer ist der Ansicht, dass Probleme einer riskanten Bereitstellung aufgrund der Prozesse und Tools, die uns heute zur Verfügung stehen, nicht auftreten sollten.

Wer trifft die Entscheidungen?

All dieser Meinungsaustausch zeigt, dass wir als Gemeinschaft von Ingenieuren überhaupt nicht zustimmen können und nicht unbedingt miteinander übereinstimmen müssen. Wer hätte das gedacht. Diese Situation zeigt wahrscheinlich auch, dass das Gesamtbild mit #NoDeployFriday solche Nuancen enthält, die sich auf Twitter nicht allzu gut widerspiegeln. Stimmt es, dass wir alle eine kontinuierliche Bereitstellung anwenden müssen, sonst machen wir es „falsch“?

Bei einer solchen Entscheidung gibt es einen psychologischen Aspekt. Die Feindseligkeit gegenüber Freitagsveröffentlichungen beruht auf der Angst, während der Woche Fehler zu machen (aufgrund von Müdigkeit oder Eile), die Schaden anrichten können, während die meisten Mitarbeiter zwei Tage ruhen. Infolgedessen kann ein Freitag-Commit, das ein potenzielles Problem enthält, das Wochenende für eine Reihe von Personen verderben: Dienstingenieure, andere Ingenieure, die aus der Ferne zur Lösung des Problems beitragen, und möglicherweise Infrastrukturspezialisten, die beschädigte Daten wiederherstellen müssen. Wenn sich der Fehler als schwerwiegend herausstellt, sind möglicherweise auch andere Mitarbeiter des Unternehmens in die Situation involviert, die Kunden kontaktieren und Schäden minimieren müssen.

Wenn wir die Position eines Idealisten einnehmen, können wir davon ausgehen, dass in einer idealen Welt mit perfektem Code, perfekter Testabdeckung und perfekter Qualitätssicherung keine Änderungen zu einem Problem führen können. Aber wir sind Menschen, und Menschen neigen dazu, Fehler zu machen. Es wird immer einige seltsame Grenzfälle geben, die während der Entwicklung nicht geschlossen werden. Das ist das Leben. Die # NoDeployFriday-Bewegung ist also zumindest theoretisch sinnvoll. Dies ist jedoch nur ein blindes Werkzeug. Ich glaube, dass es notwendig ist, die vorgenommenen Änderungen in Abhängigkeit von der Situation zu bewerten, und a priori ist es notwendig, von der Tatsache auszugehen, dass wir an jedem Tag, auch freitags, bereitstellen, aber gleichzeitig in der Lage sein sollten, die Änderungen zu isolieren, die bis Montag warten sollten.

Es gibt einige Themen, die wir diskutieren können. Ich habe sie in Kategorien unterteilt:

1. Den „Radius der Zerstörung“ der Veränderung verstehen.
   
2. Die Solidität des Bereitstellungsprozesses.
   
3. Die Fähigkeit, Fehler automatisch zu erkennen.
   
4. Wie lange dauert es, um Probleme zu lösen?
   

Lassen Sie uns jetzt diskutieren.

Den "Radius der Zerstörung" verstehen

Wenn die Online-Speere über Freitagsveröffentlichungen wieder zu brechen beginnen, vergessen sie immer das Wichtige - die Natur der Änderungen. Es gibt keine identischen Änderungen in der Codebasis. Einige Commits regeln die Schnittstelle ein wenig und nichts weiter; andere überarbeiten Hunderte von Klassen, ohne die Funktionalität des Programms zu beeinträchtigen; Wieder andere ändern Datenbankschemata und nehmen wesentliche Änderungen am Prozess des Echtzeit-Datenverbrauchs vor. Vierte können eine Instanz neu starten, während Fünftel einen Kaskadenneustart aller Arten von Diensten initiieren können.

Mit Blick auf den Code sollten Ingenieure eine gute Vorstellung vom „Radius der Zerstörung“ der vorgenommenen Änderungen haben. Welcher Teil des Codes und der Anwendung ist betroffen? Was könnte fallen, wenn der neue Code abstürzt? Ist es nur ein Klick auf eine Schaltfläche, der einen Fehler auslöst, oder gehen alle neuen Einträge verloren? Wird eine Änderung an einem einzelnen isolierten Dienst vorgenommen oder ändern sich viele Dienste und Abhängigkeiten gleichzeitig?

Ich kann mir nicht vorstellen, wer sich weigern wird, Änderungen mit einem kleinen "Zerstörungsradius" und einem einfachen Einsatz an einem beliebigen Wochentag vorzunehmen. Gleichzeitig sollten größere Änderungen - insbesondere im Zusammenhang mit der Speicherinfrastruktur - sorgfältiger durchgeführt werden, möglicherweise zu einem Zeitpunkt, an dem weniger Benutzer online sind. Es ist sogar noch besser, wenn solche umfangreichen Änderungen parallel in Betrieb genommen werden, um ihre Arbeit unter realer Last zu testen und zu bewerten, und niemand wird davon erfahren.

Hier müssen Sie je nach Situation Entscheidungen treffen. Ist jedem Ingenieur der „Radius der Zerstörung“ von Änderungen in der Produktionsumgebung und nicht nur in der Entwicklungsumgebung bekannt? Wenn nicht, warum? Ist es möglich, die Dokumentation, Schulung und Anzeige der Auswirkungen von Codeänderungen in der Produktion zu verbessern?

Ist der "Radius der Zerstörung" klein? Start am Freitag.

Ist der "Radius der Zerstörung" groß? Warten Sie bis Montag.

Die Solidität des Bereitstellungsprozesses

Eine Möglichkeit, Risiken zu reduzieren, besteht darin, den Bereitstellungsprozess kontinuierlich zu verbessern. Wenn ein Spezialist zum Starten einer neuen Version der Anwendung immer noch wissen muss, welches Skript ausgeführt werden soll, welche Datei und wo kopiert werden soll, ist es an der Zeit, mit der Automatisierung zu beginnen. In den letzten Jahren sind die Werkzeuge in diesem Bereich weit fortgeschritten. Wir verwenden häufig Jenkins Pipeline und Concourse . Mit ihnen können Sie die Assembly-, Test- und Bereitstellungs-Pipelines direkt mit Code festlegen.

Der Prozess der vollständigen Bereitstellung ist eine interessante Sache. Sie können einen Schritt zurücktreten und versuchen, zu abstrahieren, was von der Initialisierung der Pull-Anforderung bis zur Inbetriebnahme der Anwendung geschehen soll. Eine Beschreibung aller Schritte im Code, z. B. in den oben genannten Tools, hilft Ihnen dabei, die Definitionen von Schritten zu verallgemeinern und in allen Anwendungen wiederzuverwenden. Darüber hinaus wird es für Sie interessant sein, einige seltsame oder faule Entscheidungen zu notieren, die Sie einmal getroffen und mit denen Sie sich versöhnt haben.

An jeden Ingenieur, der die beiden vorhergehenden Absätze gelesen und im Stil von „Natürlich! Das machen wir schon seit Jahren! “ Ich kann garantieren, dass weitere 9 andere ihre Anwendungsinfrastruktur präsentierten und verzog das Gesicht, um zu erkennen, wie viel Arbeit erforderlich ist, um das System auf eine moderne Bereitstellungspipeline zu übertragen. Dies bedeutet, dass Sie moderne Tools nutzen müssen, die nicht nur eine kontinuierliche Integration durchführen, sondern es Ihnen auch ermöglichen, dem Produkt kontinuierlich Fehler zu liefern. Die Ingenieure müssen lediglich den Knopf für die Inbetriebnahme drücken (oder dies sogar automatisch tun, wenn Sie mutig genug sind).

Die Verbesserung des Einsatzförderers erfordert die Einbeziehung und das entsprechende Personal - dies ist definitiv kein Nebenprojekt. Eine gute Lösung wäre, ein Team zur Verbesserung der internen Tools hervorzuheben. Wenn sie die vorhandenen Probleme immer noch nicht kennen - und sie wissen es wahrscheinlich -, können Sie Informationen zu den schmerzhaftesten Situationen im Zusammenhang mit dem Freigabeprozess sammeln und diese dann zusammen mit anderen priorisieren und beheben. Langsam aber sicher wird sich die Situation verbessern: Der Code wird schneller und mit weniger Problemen in Betrieb gehen. Immer mehr Menschen werden in der Lage sein, bessere Ansätze zu lernen und selbst Verbesserungen vorzunehmen. Wenn sich die Situation verbessert, werden die Ansätze in Teams verteilt und dieses neue Projekt wird korrekt abgeschlossen, ohne dass die üblichen schlechten Gewohnheiten kopiert werden.

Ab dem Zeitpunkt der Zusammenführung sollte die Pull-Anforderung für das Commit automatisiert werden, damit Sie nicht einmal darüber nachdenken müssen. Dies hilft nicht nur, die tatsächlichen Probleme bei der Qualitätssicherung zu isolieren, da die einzige Variable der geänderte Code ist, sondern macht das Schreiben des Codes auch viel angenehmer. Die Inbetriebnahme erfolgt dezentral, was die persönliche Autonomie und Verantwortung erhöht. Dies führt wiederum zu bewussteren Entscheidungen darüber, wann und wie neuer Code eingeführt werden soll.

Zuverlässiger Einsatzförderer? Am Freitag ausrollen.

Skripte manuell kopieren? Warten Sie bis Montag.

Fähigkeit, Fehler zu erkennen

Die Inbetriebnahme wird nicht beendet, nachdem der Code funktioniert. Wenn etwas schief geht, müssen wir darüber Bescheid wissen, und es ist ratsam, dass wir darüber informiert werden und nicht selbst nach Informationen suchen müssen. Dazu müssen Sie Anwendungsprotokolle automatisch auf Fehler scannen, wichtige Metriken explizit verfolgen (z. B. die Anzahl der pro Sekunde verarbeiteten Nachrichten oder den Anteil der Fehler) sowie ein Warnsystem, das Ingenieure über kritische Probleme informiert und für bestimmte Metriken einen negativen Trend anzeigt.

Der Betrieb unterscheidet sich immer von der Entwicklung, und die Ingenieure müssen den Betrieb bestimmter Teile des Systems überwachen. Sie müssen Fragen zu jeder nachfolgenden Änderung beantworten: Hat sie das System beschleunigt oder verlangsamt? Es gibt mehr oder weniger Timeouts? Sind wir durch Prozessor oder E / A begrenzt?

Daten zu Metriken und Fehlern sollten an das Warnsystem übermittelt werden. Die Teams sollten in der Lage sein, festzustellen, welche Signale auf eine negative Situation hinweisen, und automatische Nachrichten darüber zu senden. Für unsere Teams und die schwerwiegendsten Vorfälle verwenden wir PagerDuty.

Durch die Messung der Metriken des Produktionssystems können Ingenieure nach jeder Bereitstellung feststellen, ob sich etwas zum Guten oder zum Schlechten geändert hat. Im schlimmsten Fall informiert das System automatisch jemanden über das Problem.

Gute Überwachung, Benachrichtigungen und Bereitschaftsspezialisten? Am Freitag bereitstellen.

Protokolle manuell über ssh anzeigen? Warten Sie bis Montag.

Wie lange dauert die Lösung von Problemen?

Das Hauptkriterium ist schließlich, wie lange es dauern wird, bis die Probleme behoben sind. Dies hängt teilweise vom „Schadensradius“ der vorgenommenen Änderungen ab. Selbst wenn Sie eine geleckte Bereitstellungspipeline haben, sind einige Änderungen schwer schnell zu beheben. Das Zurücksetzen von Änderungen im Datenextraktionssystem und im Suchindexschema erfordert möglicherweise eine mühsame Neuindizierung sowie das Korrigieren einer Codezeile. Die durchschnittliche Bereitstellung, Validierung, Korrektur und erneute Bereitstellung von CSS-Änderungen kann Minuten dauern, während größere Änderungen am Repository möglicherweise Arbeitstage erfordern.

Für alle Arbeiten innerhalb der Bereitstellungspipeline, die auf Makroebene die Zuverlässigkeit von Änderungen erhöhen können, sind keine Änderungen gleich, sodass Sie sie separat auswerten müssen. Wenn etwas schief geht, können wir es schnell beheben?

Ist es mit einem einzigen Wiederherstellungs-Commit vollständig behoben? Am Freitag bereitstellen.

Gibt es große Schwierigkeiten, wenn etwas schief geht? Warten Sie bis Montag.

Denken Sie selbst, entscheiden Sie selbst

Was ist meine Position bei #NoDeployFriday? Ich denke, es hängt alles von der Veröffentlichung ab. Änderungen mit einem kleinen „Trefferradius“, die leicht rückgängig gemacht werden können, können jederzeit und an jedem Tag bereitgestellt werden. Bei großen Änderungen, deren Auswirkungen im Produktionssystem genau überwacht werden müssen, empfehle ich dringend, bis Montag zu warten.

In der Tat liegt es an Ihnen, freitags bereitzustellen. Wenn Sie mit einem knarrenden und fragilen System arbeiten, vermeiden Sie am besten Freitags, bis Sie alles Notwendige getan haben, um den Bereitstellungsprozess zu verbessern. Stellen Sie nur sicher, dass Sie es tun, bürsten Sie es nicht ab. Die Ablehnung von Freitagsveröffentlichungen ist ein normaler Weg, um vorübergehende Infrastrukturfehler zu vertuschen. Dies ist eine angemessene Schadensreduzierung zum Wohle des Unternehmens. Es ist jedoch schlecht, wenn diese Regel ständige Mängel abdeckt.

Wenn Sie nicht sicher sind, welche Auswirkungen die Änderungen haben werden, verschieben Sie sie auf Montag. Überlegen Sie sich jedoch, was Sie beim nächsten Mal tun können, um diesen Effekt besser zu verstehen und die zugehörige Infrastruktur dafür zu verbessern. Wie immer im Leben hat jede Entscheidung ihre eigenen Nuancen. Die Lösungen sind nicht in „Schwarz“ und „Weiß“, in „Richtig“ und „Falsch“ unterteilt: Während wir alles für Unternehmen, Anwendungen und einander tun und unsere Systeme verbessern, machen wir alles gut.

Erfolgreiche Bereitstellung.