Hallo Habr! Und wieder ist Alexey Pristavko in Kontakt.

Im Gegensatz zu meinen vorherigen Artikeln werden wir heute über Menschen sprechen. Die Helden des Tages sind der Operationsdienst, dessen Interessen ich vertrete, und der Entwicklungsdienst.

Die koordinierte Arbeit dieser Dienste ist der Schlüssel für einen erfolgreichen Start und einen reibungslosen „Flug“ des erstellten Dienstes. Aber wie meine (und nicht nur) Erfahrung zeigt, kann praktisch kein Projekt ohne Konflikte und Meinungsverschiedenheiten auskommen, deren Opfer ein unschuldiger Dienst ist.

In diesem Artikel werde ich versuchen, die folgenden Fragen zu beantworten:

• Wie wirken sich Entwicklungsmethoden und -prozesse auf den Betrieb aus?
• Was treibt jede Seite des Konflikts an?
• Was ist die Hauptursache für die Meinungsverschiedenheit?

Willkommen bei Katze!

Was sind die Herausforderungen für Dienstleistungen?

Wir werden die Abteilungen besser kennenlernen und mit dem Betriebsservice beginnen (es ist auch ein Support-Service). Warum wird dieses schreckliche Tier gebraucht, welche Aufgabe erfüllt es und "für wen" funktioniert es?

Die Hauptaufgabe des Betriebsdienstes besteht darin , das Servicelevel zu verwalten , dh den Betrieb des IT-Systems im Rahmen des SLA aufrechtzuerhalten.
Der Betrieb sollte im Rahmen einer Vereinbarung mit dem Kunden - normalerweise mit dem Unternehmen - einen ständigen Zugriff auf den Service und dessen ordnungsgemäße Funktionsweise ermöglichen.

Hier ist die Lösung für dieses Problem:

• Incident Management: Wiederherstellung der Geschäftsfunktion während eines Unfalls;
  
• Problemmanagement: Behandlung der wahrscheinlichen Ursachen von Unfällen und Zwischenfällen;
  
• Konfigurationsmanagement: Sammeln von Informationen und Analysieren von Software- und Infrastrukturbetriebsparametern;
  
• Änderungsmanagement: Minimierung des Risikos von Problemen und Unfällen bei Änderungen.
  

Verständlich ist auch die Rolle des Entwicklungsdienstes - die erstmalige Erstellung eines IT-Dienstes und die Einführung neuer Funktionen auf Wunsch des Kunden.

Sicherlich haben Sie bereits Verdacht auf die Reibungspunkte von Entwicklern und Support, denn wo es Überschneidungen von Aufgaben gibt, gibt es Konflikte. Aber beeilen Sie sich nicht zu Schlussfolgerungen. Die ewige Debatte zwischen Entwicklern und Administratoren ist weit entfernt vom Epizentrum der „Schlachten“.

Wo wachsen Meinungsverschiedenheiten?

Der „Krieg“ von Programmierern und Administratoren ist keine Konfrontation menschlicher Interessen, sondern eine Konfrontation von Diensten.



Das Problem liegt in den Prioritäten und der Motivation dieser Dienste. In seiner allgemeinsten Form kann dies wie folgt beschrieben werden:

• Das Entwicklungsteam möchte die Technologie der ersten Frische (berufliche Entwicklung, Interesse) nutzen und die Arbeit so schnell wie möglich erledigen (externe Motivation).
  

• Der Betrieb interessiert sich für die stabilsten Technologien (ihre Probleme sind bekannt und haben allgemein akzeptierte Lösungen) und detaillierte Erklärungen, was bei Problemen mit der entwickelten Software zu tun ist (externe Motivation für die Geschwindigkeit der Fehlerbehebung).
  

Gleichzeitig ist es wichtig zu verstehen, dass nicht nur Entwickler neue Funktionen "gesehen" haben und nicht immer ausschließlich Administratoren die Gefallenen aufziehen.

• Administratoren sind aktiv am Entwicklungsprozess beteiligt - beim Aufbau der Infrastruktur, der Fehlertoleranz und der Skalierbarkeit, bei der Vorbereitung der Erstkonfigurationen und im Idealfall bei der Vorbereitung der Softwareanforderungen. All dies wird als Lösungsentwicklungsprozess bezeichnet (verwechseln Sie es nicht mit direktem Code-Schreiben!).
  

• Programmierer sind aktiv an der Operation beteiligt. Sie korrigieren Softwarefehler, führen Systemoptimierungen und technische Verbesserungen durch, um dem SLA-System zu entsprechen, dh sie lösen das Problem der Zugänglichkeit des endgültigen IT-Service.
  

Der Konflikt zwischen Programmierern und Administratoren wächst durch die Substitution von Konzepten:

• Entwicklung → Kodierung;
  
• Unterstützung → Verwaltung von Anwendungsdiensten.
  

Das Verschieben der Unterordnungsstruktur auf professioneller Basis (und nicht auf funktionaler Basis) führt immer zu Konflikten. Administratoren und Programmierer arbeiten in der Regel in völlig unterschiedlichen Teams und manchmal auch in Abteilungen und sind als Betrieb bzw. Entwicklung motiviert.

Infolgedessen sind Programmierer aus der Entwicklungsabteilung, die "gezwungen" sind, alte Fehler zu beheben oder, Gott bewahre, Dokumentation zu schreiben, unglücklich. Administratoren aus dem Betrieb sind ebenfalls empört, die gebeten werden, schnell einen Flügel zu werfen, um einen neuen Server für Entwickler zu erstellen oder ihnen mit Ratschlägen zu helfen.

Jede der Parteien sieht dies nicht als gemeinsame Lösung des Problems, sondern als Ablenkung von ihren eigenen Aufgaben, die auch ohne dieses Ziel nicht sichtbar sind.

Wir dürfen aber den Kunden nicht vergessen, denn er ist zwar indirekt, aber auch Konfliktbeteiligter. In der Regel braucht er einen etablierten und stabilen Service. Ein bloßer Code, selbst der beste, ist für den Kunden außerhalb des Systems völlig nutzlos. Er hat im Grunde ein anderes Bild von der Welt:



Ein Standardkunde hat keine Aufgabe zu erstellen, zu schreiben oder, sorry, Herr, zu implementieren. Der Kunde möchte ein Geschäftsproblem mit dem magischen Knopf „Alles gut machen“ lösen, während die IT vorschreibt, dass es eine spezifische Lösung bietet.

Werfen wir einen Blick auf alle Seiten des Konflikts:



Dies ist natürlich nur der häufigste Teil der funktionalen und betrieblichen Anforderungen.

Wir haben also herausgefunden, dass es immer noch drei Konfliktparteien gibt : Entwicklung, Betrieb und den Kunden. Darüber hinaus ist es der Kunde, der größtenteils ein "Provokateur" ist und die Verantwortung zwischen den Teams teilt. Dies ist an sich nicht schlecht, und wenn es nicht die allgemein akzeptierte Trennung von Teams und Verantwortlichkeiten zwischen ihnen gäbe, wäre dies ein überschaubarer Konflikt.

Wir wissen jedoch bereits, dass beide Dienste nicht autark sind. Sie sind durch eine „Service“ -Sperre getrennt und müssen gleichzeitig nicht nur auf dem Gebiet der Übertragung von Verantwortung entsprechend den Lebensphasen des Produkts untereinander interagieren, sondern sich auch aktiv an der Lösung der Probleme des jeweils anderen beteiligen.

Ein weiterer Aspekt des Einflusses des Kunden ist seine Strategie und Methodik der Geschäftsentwicklung. In diesem Fall geht es darum, nicht zu verstehen, wie der Prozess der Entwicklung einer bestimmten IT-Lösung aussieht. Ohne ein solches Verständnis verlangt der Kunde oft, eine Katze zum Wal zu machen und sie dann mit Flügeln zu versehen. Und immer ist alles dringend. Manchmal ist dies durch die Situation und die Innovation der Idee gerechtfertigt, manchmal ist es eine Folge des Wettlaufs um den Marktführer und des hastigen Kopierens. Die Gründe mögen sehr unterschiedlich sein, aber das Ergebnis ist einer.

Das Problem ist, dass sich eine solche Strategie in ständigen Experimenten und der Notwendigkeit niederschlägt, in kürzester Zeit Ergebnisse zu erzielen. Dieser Ansatz versetzt uns in den Abgrund einer kontinuierlichen Entwicklung anstelle einer Arbeit, die auf ein bestimmtes Ergebnis abzielt. Im Prinzip wird das letzte Problem von Unternehmensarchitekten gelöst, aber Sie werden diese Leute am Nachmittag nicht mit Feuer finden.

Entwicklungsprozesse

Endlich waren wir fast an dem Punkt angelangt, an dem alles in Ordnung war. Was ist der Schlüssel zum Servicebetrieb?

1. Transparenz der Verbesserungen. Um Änderungen zu verwalten, müssen Sie verstehen, was, wie und warum sie durchgeführt wurden.
   
2. Dokumentation zur Arbeits- und Wartungslogik. Idealerweise in Form von Anweisungen. Der Schlüssel zur Einhaltung der SLA ist nicht nur die Zuverlässigkeit, sondern auch ein klares Verständnis dessen, was und wie zu tun ist, was für alle Darsteller vorhanden sein sollte. „Mündliches Wissen“ ist hier nicht geeignet - sehr oft arbeiten Menschen in Schichten im Betrieb, und es ist einfach unmöglich, alles zu sammeln und alles zu erklären. Und das Gedächtnis in einer stressigen Situation (und ein Unfall ist immer Stress) kann versagen.
   
3. Ein klares Übertragungsverfahren zur Unterstützung der neuen Version mit Prüfung ihrer Betriebseigenschaften und dem korrekten Betrieb der Funktion. Auf einfache Weise - Regression und Stresstests. Die einfache Funktionalität der neuen Funktionalität regt den Betrieb im geringsten an: Das Entwicklungsteam selbst wird die fehlgeschlagene Garantieversion beheben. Aber der eingeführte Fehler in der alten Funktionalität sollte die Operation, wenn nicht von selbst beseitigen, dann zumindest verarbeiten, manchmal die Schuld der Entwicklung beweisen.
   
4. Eine Gelegenheit, Ihre Anforderungen auf die Arbeit eines neuen Projekts zu übertragen. Es ist die Entwicklung, die die wichtigsten Betriebsmerkmale festlegt. Wenn die Software beispielsweise nicht weiß, wie sie in einem Cluster arbeiten soll, kann der Vorgang sie nicht unabhängig voneinander wirklich zuverlässig machen.
   

Was ist der Betriebsservice und warum ist es für jemanden wichtig, wie das Entwicklungsteam arbeitet? Wir haben es herausgefunden. Kommen wir zum interessantesten Teil - wir werden die verschiedenen Entwicklungsmethoden und ihre Auswirkungen auf den Betriebsservice analysieren.

Beginnen wir mit den Klassikern: Wasserfallmodelle.

Wasserfall

Waterfall konzentriert sich auf die Bereitstellung vollständiger und anspruchsvoller Funktionen. Das Release-Modell ist zyklisch. Der Zyklus dauert mehrere Wochen (äußerst selten) bis zu Quartalen und sechs Monaten. Fast immer gibt es eine konsistente Sammlung von Anforderungen, deren Analyse, Entwicklung einer Lösungsarchitektur, Bewertung ihrer Dauer, Planung und am Ende umfassende Regressionstests.

Die Einhaltung der Betriebsinteressen hängt von der konkreten Umsetzung ab. Da in der Regel die erforderlichen Phasen hervorgehoben werden, werden bei diesem Prozess alle Anforderungen und formalen Verfahren für die Übergabe an den Betrieb einschließlich der Dokumentation berücksichtigt.

Die Hauptprobleme Wasserfall für den Kunden ist die Dauer der Iterationen und die lange Stabilisierung nach der Freigabe. Manchmal muss der Kunde mehrere Monate warten, bis ein Produkt in dem Produkt erscheint, dessen Erstellung eine Woche dauert.

Wenn das Ergebnis weit von den Erwartungen entfernt ist, muss der Kunde bis zum Ende eines neuen Zyklus oder sogar zwei durchhalten. Regelmäßig an seiner Stelle ist der Betriebsdienst. Und die technische Funktionalität ist meistens die letzte in der Reihe.

Jede große Freisetzung geht mit einer Reihe von Fehlern einher, die während der Stabilisierungsphase beseitigt werden. Normalerweise wird es für alle Beteiligten zur Hölle - die Entwicklung ist gezwungen, Ausbeutung zu betreiben, die Operation akzeptiert Vorfälle und treibt ihre Entwicklung voran, um die Beseitigung mit allen Mitteln zu gewährleisten, und der Kunde, der all dieses Durcheinander und das verlorene Geld betrachtet, reißt sich die Haare aus.

Trotz alledem ist Waterfall aus betrieblicher Sicht der einheitlichste und vorhersehbarste methodische Prozess, in den Sie sich integrieren können. Im Allgemeinen sind weder die Dauer des Zyklus noch die Stabilisierung des Betriebs besonders betroffen. Je mehr Zeit zwischen den Veröffentlichungen vergeht, desto länger können Sie ruhig arbeiten - und das ist immer ein Plus. Wenn Sie sich sicher sind, dass sich in den nächsten sechs Monaten nichts ändern wird, ist es außerdem viel einfacher, Ihre Arbeit in den Prozess einzubeziehen.

Leider sind Kunden sehr oft gegen Waterfall und fordern, die Entwicklung des Projekts zu beschleunigen. Um diesem Wunsch willen werden flexiblere Methoden geboren.

Agil

Wie Sie verstehen, ist der Wasserfall formal eine sehr lange Zeit und beinhaltet eine Menge Dokumentation, die jeder immer betrügt . Und der Kunde benötigt alles auf einmal. Als Antwort auf diese Probleme haben Programmierer ein agiles Manifest entwickelt:

● Menschen und Interaktion sind wichtiger als Prozesse und Werkzeuge.
Es ist schwer, damit zu streiten. Natürlich sind die Menschen wichtiger. Vergessen Sie aber nicht die Prozesse. Es sind die Prozesse, die die Interaktion standardisieren und regulieren. Außerdem werden Sie nur in der Öffentlichkeit nicht weit kommen. Zumindest mögen Menschen es, krank zu sein, sich zu entspannen und manchmal aufzuhören.

● Ein funktionierendes Produkt ist wichtiger als eine umfassende Dokumentation.
Dies gilt auch. Aber es gibt noch eine andere Frage: Wie gut und wie lange funktioniert das Produkt ohne Dokumentation? Höchstwahrscheinlich nicht sehr lange. Aber es ist gut oder nicht - es wird aufgrund des Fehlens der Quelle nicht funktionieren. Und dann müssen Sie die Taktik befolgen, in die sich viele verliebt haben. "Ich konnte es nicht herausfinden - von Grund auf neu schreiben." Aber es ist immer lang, teuer und im Allgemeinen keine Tatsache, dass das Ergebnis besser ausfällt.

● Die Zusammenarbeit mit dem Kunden ist wichtiger als die Aushandlung der Vertragsbedingungen.
Und wieder, ja, wichtiger. Aber wie können wir ohne Einigung über die Vertragsbedingungen verstehen, was und wie zu tun ist? Wie kann man gegenseitiges Missverständnis überwinden, außer wie man durch ein klar definiertes Dokument kommuniziert und zustimmt? Natürlich ist der Vertrag auch kein Allheilmittel, aber er ist viel zuverlässiger als die Methode aus den neunziger Jahren:

- Vasya, verstehst du mich?
- Na ja, Bruder.

● Die Bereitschaft zur Veränderung ist wichtiger als das Befolgen des ursprünglichen Plans.
Dies gilt jedoch nur in einem Fall: Wenn der ursprüngliche Plan ein vollständiges Protokoll war und das, was sie erstellen wollten, stellte sich heraus, dass niemand benötigt wurde. Sie geben einen Unternehmensarchitekten in jede Hand!

Das Ergebnis der blinden Befolgung dieses Manifests ist, dass sich der Geschäftskunde selbst in einen Unternehmensarchitekten verwandeln muss (aber meistens verwandelt er sich in einen Kürbis). Dies ist nicht nur keine „Funktion“, die ihm eigen ist, sondern es ist auch notwendig, die IT zu verstehen.

Scrum

Scrum ist einer der ersten Versuche, Waterfall an die Ideologie des Agile-Manifests anzupassen.
Die Hauptmerkmale von Scrum:

• Arbeite in kurzen Sprints. Die Zusammensetzung des Sprints nach seinem Start wird nicht bearbeitet.
  
• Planung durch Einfügen einzelner User Stories in das Sprint-Wunschprotokoll. Auf dem Projektbesitzer - eine Auswahl aus dem "Projektprotokoll";
  
• Die Interessen des Kunden werden vom Projektverantwortlichen (Product Owner) vertreten;
  
• Das Entwicklungsteam besteht aus Spezialisten mit unterschiedlichen Profilen: Programmierern, Entwicklern, Architekten und Analysten. Das Team ist für das gesamte Ergebnis verantwortlich.
  
• Wir ersetzen Dokumentation und Korrespondenz durch tägliche Diskussionen des gesamten Teams über das Projekt.
  

Theoretisch ist dies ein ziemlich robuster Ansatz, der in vielerlei Hinsicht einer Miniaturversion von Waterfall ähnelt. In der Implementierungsphase treten Probleme auf. Leider führt SCRUM aufgrund seines kürzeren Zyklus dazu, dass die gesamte Funktion in einzelne Teile zerlegt wird und die Funktion bereits in der Phase der Sprintplanung in Teilen bereitgestellt wird. Ich schweige darüber, dass aus diesem Grund schon während des "Rennens" alles schief gehen kann. Kurze Sprints lassen keine Zeit für Manager und es wird extrem schwierig, herauszukommen.

Durch die ständige Neupriorisierung eines Features in seiner fertigen Form kann es sehr bald produktiv werden. Darüber hinaus ist es zum Zeitpunkt des Schreibens von UserStory äußerst schwierig, die Auswirkungen der geplanten Funktionalität auf das endgültige System zu bewerten, da ihr Status zum Zeitpunkt des Auftretens dieser Funktionalität nicht im Voraus bekannt ist.

Wie bedroht dies die Ausbeutung? Es ist nicht immer klar, was funktionieren soll, was nicht und wenn es funktioniert, wann. Dementsprechend werden Funktionstests durch Systemtests ersetzt, da die normale Regression viel Zeit in Anspruch nimmt. Dies fügt dem Produkt Fehler hinzu und verzögert deren Lösung.

Für den normalen Betrieb sollte der Betrieb:

• Teilnahme an SCRUM-Meetings;
  
• Ständig über die Arbeitssituationen der Entwicklung informiert;
  
• Kennen Sie Entwicklungspläne und Release-Status.
  

Andernfalls ist es unmöglich, Zeit mit der Annahme zu erfassen oder Kommentare abzugeben. Natürlich ist Ausbeutung äußerst selten, um all diesen Punkten zu folgen, und wenn dies der Fall ist, führt dies zu einer Eskalation des Konflikts. Selbst ein Produktbesitzer während eines SCRUM-Meetings kann Supportinteressen kurzsichtig ignorieren.

Kanban

Der nächste Schritt in der Entwicklung der Entwicklungsmethoden ist Kanban. Die ohnehin kurzen SCRUM-Zyklen schienen auch für das Geschäft zu lang. Sie können den Kunden verstehen: Sie möchten immer der Erste sein, der den coolsten Chip bekommt. Ja, und das Ändern von Plänen ist ineffizient. Es stellt sich heraus, dass der Aufwand etwas zu hoch ist.
Wie die Bauherren sagen, ist es einfacher, „an Ort und Stelle zu formen“.

Kanban ist eine IT-Implementierung der japanischen Lean-Manufacturing-Methodik. Aber es gibt eine Nuance: Bei Toyota werden Autos mit Kanban aus vorgefertigten Teilen zusammengebaut, während die Entwicklung in erster Linie auf Design beruht. Bei der Programmierung werden Teilefunktionen einfach kopiert, sie müssen nicht ständig „produziert“ werden.

Kanban geht normalerweise Hand in Hand mit CI / CD-Prozessen. Hier gibt es keine Sprints, Aufgaben werden kontinuierlich geliefert, sobald sie fertig sind, es gibt strenge Einschränkungen hinsichtlich der Größe solcher Aufgaben. Aus diesem Grund wird eine komplexe Funktionalität in integraler Form fast nie bereitgestellt, da sie nicht in die Größe der Aufgabe passt.

Unter solchen Bedingungen wird die Dokumentation für das System wirklich veraltet, bevor es geschrieben wird, und verliert jeglichen Sinn, da es unmöglich ist, einen Zustand des produzierten (nämlich produzierten, aber nicht entwickelten) Systems festzulegen, in dem es wahr wäre.

Für den Betrieb bedeutet dies die Unfähigkeit, SLA bereitzustellen: Es gibt keine Dokumentation, und niemand weiß, wie das System funktioniert und wie es funktionieren sollte.

Vorhersehbarkeit und Gewährleistung des kontinuierlichen Betriebs sind die Grundlage für die Implementierung von SLA.

Bei diesem Ansatz gibt es jedoch normalerweise keinen Betriebsservice, sondern nur ein Entwicklungsteam, das regelmäßig durch Reparaturen und (manchmal) durch „technische Schulden“ abgelenkt wird. Aber niemand macht sich deswegen Sorgen, da die Pläne nicht brechen. Es ist schwierig zu stören, was nicht ist.

Wie von den Autoren des ursprünglichen Prozesses festgelegt, ist Kanban ideal für Operationen, bei denen die Planung durch eine Reaktion auf Reize ersetzt wird. So sieht beispielsweise die Arbeit mit Vorfällen aus. Wenn sie nicht funktioniert, werden wir sie beheben. In den meisten Fällen nach einem bekannten Verfahren. Kanban ist jedoch für die Entwicklung völlig ungeeignet, da es das Endergebnis nur schlecht impliziert. Die Wahl dieser Methode wird Sie zu einem endlosen Prozess verurteilen - "Wir haben gebaut, gebaut und bauen immer noch." Nicht so!

Devops

Natürlich ist DevOps keine Entwicklungsmethode als solche, aber ich kann nicht anders, als meine 5 Kopeken einzufügen und nicht über den häufigsten Versuch zu sprechen, einen Konflikt zwischen Betrieb und Entwicklung zu lösen.

Theoretisch handelt es sich bei DevOps um eine Reihe von Praktiken, die auf die aktive Interaktion von Entwicklungsspezialisten mit Spezialisten für Informationstechnologie und die gegenseitige Integration ihrer Arbeitsprozesse ineinander abzielen.

DevOps basiert auf der Idee einer engen gegenseitigen Abhängigkeit von Softwareentwicklung und -betrieb und soll Unternehmen dabei helfen, Softwareprodukte und -dienste schnell zu erstellen und zu aktualisieren. Wieder über die schnelle Erstellung und Aktualisierung. Aber diese Probleme auszunutzen, gibt es überhaupt nicht.

Infolgedessen wird DevOps zu einem Mittel, um das Entwicklungsteam vom Betriebsservice unabhängig zu machen, indem die erforderliche Entwicklungsverbindung hergestellt wird. Offensichtlich ist diese Lösung an sich einseitig und löst das Problem nur für eine der Parteien - die Entwicklung. Dies verschärft häufig nur den Konflikt und ermöglicht es der Entwicklung, den Servicevorgang vollständig zu ignorieren.

In der Praxis stoße ich am häufigsten auf zwei Implementierungen:

• Das Team der Betriebsadministratoren wird gepflegt und ist produktiv.
  

-, . , , , , , .

• , « — ».
  

. . DevOps-, , — . , .

, DevOps — , , , , , . . , SLA . () .

— . , . , .
DevOps , , , . - , , .

?

: , .
: -. - — , - .
: , , . , , .

DevOps — , . , , .

. !