Ich würde mich über eine Diskussion in den Kommentaren unter dem Artikel freuen: Fragen, Meinungen, Widerlegungen!
Es sind bekannt
Bei Lamoda habe ich mich dem Team angeschlossen, das an der Unterstützung und Entwicklung des Auftragsabwicklungssystems arbeitet. Nichts ist klar, aber schrecklich interessant.
Nach einem kleinen, aber ehrgeizigen Webstudio, in dem ich zuvor gearbeitet habe, war ich beeindruckt von der Ernsthaftigkeit in einem großen Unternehmen. Arrangierte Entwicklungsprozesse schienen ein perfekt polierter Mechanismus zu sein. Strenge, aber Coaching-Code-Überprüfungen durch den Leiter und die Teammitglieder sind für ein derart komplexes und wichtiges System unerlässlich. Für mich flogen Punktaufgaben, die buchstäblich ein oder zwei Dateien betrafen, nicht mehr. Der größte Teil der Codebasis und des Systemverhaltens wurde mir durch den Nebel des Krieges verborgen.
Nach ungefähr einem Monat erledigte ich eine der ersten Aufgaben im Zusammenhang mit echten Änderungen an einem funktionierenden System. Sein Kern bestand darin, dem Bericht über die Rückgabe von Geldern an den Kunden ein Feld hinzuzufügen. Codeüberprüfungen, Komponententests, QS-Techniker beim Testen der Version - alles sah in Ordnung aus. Da das System groß und komplex war, wurden wir gemäß den Vorschriften zweimal pro Woche freigelassen - und am Donnerstag ging meine Aufgabe in die Produktion. Den größten Teil des Tages war der Release-Ingenieur damit beschäftigt, den Code zu erstellen und einzuführen, gefolgt von einem zwanghaften Wechsel zwischen Registerkarten mit Überwachungsdiagrammen, Fehlern, Warteschlangen und Protokollen - alles, was auf ein Problem hinweisen könnte. Aber alles sah gut aus. Der Code wurde in den Hauptzweig eingefügt und verteilt, um andere Aufgaben zu erledigen.
Die Stille in den Protokollen und der Überwachung verbirgt einen schrecklichen Fehler: Die Datenbankabfrage hat eine falsche Anzahl von Zeilen zurückgegeben. Der Gesamtbetrag, der zurückgegeben werden musste, war um ein Vielfaches höher als der tatsächliche Betrag ... Aber wir haben dies erst am Montag erfahren. Ich erinnere mich noch daran, wie müde und vorwurfsvoll der Tech Lead mich ansah, als wir am nächsten Morgen mit dem Büroaufzug fuhren. Er fing den Fehler bis drei Uhr morgens auf und bereitete das Update für die Veröffentlichung vor. Und das Unternehmen litt unter einigen Auswirkungen meines Fehlers. Dies war mein erster kritischer Fehler, aber weit entfernt vom letzten. Die Leute machen Fehler und machen es die ganze Zeit.
Imbiss Nr. 1:Geschäftsprozesse und Daten stehen an erster Stelle. Es ist wichtig, die Daten, mit denen das System arbeitet, genau zu beachten. Bestimmen Sie, womit Sie es zu tun haben, bevor Sie Änderungen vornehmen. Verstehen Sie den Kontext, in dem Anpassungen vorgenommen werden. Betrachten Sie das zu lösende Problem immer aus der Perspektive des Kontexts über der Ebene. Mit anderen Worten, verstehen Sie klar, was in Bezug auf den Geschäftsprozess geschieht und wer der Verbraucher der betroffenen Modelle ist. Die Struktur einer Anwendung kann beliebig viele Abstraktionsebenen und unterschiedliche Qualitätsstufen der Abstraktionen selbst aufweisen. Dies bedeutet jedoch überhaupt nichts, wenn das Modell oder der Geschäftsprozess als Ganzes fehlerhaft sind.
Ich arbeitete weiterhin im selben Team, sammelte Erfahrungen und sechs Monate später warf ich im Team-Stand-up einen Satz, der im Allgemeinen verstand, wie unser Auftragsabwicklungssystem funktioniert.
Natürlich habe ich mich geirrt.
Die Komplexität großer Systeme sollte niemals unterschätzt werden. Der amerikanische Politiker Donald Rumsfeld hat dazu sehr gut gesagt:
... wie wir wissen, gibt es berühmte bekannte; Es gibt Dinge, die wir wissen, die wir kennen. Wir wissen auch, dass es unbekannte Unbekannte gibt; Das heißt, wir wissen, dass es einige Dinge gibt, die wir nicht wissen. Es gibt aber auch unbekannte Unbekannte - solche, die wir nicht kennen, die wir nicht kennen. Und wenn Sie sich die Geschichte unseres Landes und anderer freier Länder ansehen, ist die letzte Kategorie normalerweise schwierig.
Takeaway # 2: Wenn Sie mit komplexen Systemen arbeiten, ist es wichtig zu verstehen, was wir über sie wissen, was wir nicht wissen und was ihr Verhalten nicht einmal errät. Dabei geht es nicht nur um das Toolkit und die Verfolgung des Trends „Überwachung in Richtung Beobachtbarkeit“ , sondern auch um das Abhängigkeitsmanagement und die Risikobewertung im Design. Bevor Sie sich beispielsweise für die Verwendung einer coolen Trenddatenbank für ein kritisches System entscheiden, empfehle ich Ihnen dringend, sich an diese Website zu halten. Langetechnology.club
Alles ist kaputt
Nach zwei Jahren Arbeit mit dem Auftragsabwicklungssystem kann ich sagen, dass ich ungefähr 80% der Bewerbung mit Vertrauen kenne. Das heißt, über jedes Modul des Systems verstehe ich, wie es funktioniert, und ich kann Änderungen vornehmen. Ich weiß, welche Geschäftsprozesse sich in einem bestimmten Modell widerspiegeln, wie sie miteinander verbunden sind und sich gegenseitig beeinflussen. Ich habe die Integration in das Zahlungsverarbeitungssystem durchgeführt, das vom benachbarten Team entworfen wurde. Zusätzlich zur Integration war es notwendig, das Erbe des alten Codes loszuwerden, da Zahlungen zuvor Teil unseres Systems waren - diese Aufgabe war mein letztes und größtes Refactoring eines großen Moduls. Alles verlief so reibungslos, dass es nicht einmal interessant war.
Gleichzeitig braute sich in mir als Entwickler ein Konflikt zusammen. Ich habe ehrlich gesagt nicht verstanden, warum unser Auftragsabwicklungssystem, das für den Betrieb unseres gesamten Geschäfts so wichtig ist, so fragil ist. Die benachbarten großen Systeme waren ebenso zerbrechlich. Nach all den Erfahrungen, die ich in zwei Jahren Arbeit gesammelt habe, schien es, dass eine gewisse Zuverlässigkeit komplexer Systeme nur bei der Durchführung von Standardtests zu erwarten ist. Und wenn Sie versuchen, die Änderungen vorzunehmen, die Ihr Unternehmen erfordert, fallen die Dinge beim ersten drastischen Manöver eines unglücklichen Entwicklers auseinander.
Als ich über all das nachdachte, stieß ich auf den Artikel Alles ist kaputt , in dem der Autor über das gleiche Problem schreibt, aber in noch größerem Maßstab (und auch über das gleiche, aber aus einem anderen Blickwinkel - Software-Ernüchterung). Jedes Mal, wenn ich aufgeregt bin, wenn ich von außen eine Bestätigung meiner inneren Gefühle finde - so fühlte ich nach dem Lesen des Artikels endlich, wie meine vage Unzufriedenheit zu einer lebendigen und offensichtlichen Einsicht wurde:
Software ist so schlecht, weil sie so komplex ist.
Wir mussten für ein Beispiel in unserer Arbeit nicht weit gehen: In diesem Moment haben wir mit nur ein paar Polen die Erstellung eines Auftrags für eine Weile vollständig gebrochen.
Unsere großen und wichtigen Systeme sind so schlecht, weil sie nicht in unsere Köpfe passen! Und alle Geschäftsprozesse, die innerhalb der Systeme geschlossen sind, passen nicht in die Köpfe von Managern und Analysten - und im Allgemeinen gibt es keine solche Person, die verstehen würde, wie alles zusammenarbeitet.
Takeaway # 3: Beim Entwerfen von Systemen ist es wichtig, deren kognitive Belastung zu berücksichtigen. Es besteht aus der Komplexität technischer Lösungen sowie Modellen und Prozessen des Fachgebiets. Gut konzipierte Systeme haben eine hohe kognitive Belastung des Themenbereichs und geringe technische Lösungen.Idealerweise sollte ein einzelnes System eine kognitive Belastung haben, mit der eine Person umgehen kann.
Okay, das Problem ist klar. Nehmen wir jedoch an, wir haben die Möglichkeit, ein übermäßig komplexes und daher schlechtes System neu zu schreiben und es zu vereinfachen. Worauf sollten Sie noch achten? In der Kybernetik gibt es den Conant-Ashby-Satz:
Ein guter Regulator eines Systems muss ein Modell dieses Systems haben. Guter Regulator
Die Bedeutung dieses Theorems ist, dass wir, wenn wir ein Objekt steuern wollen, ein gutes (genaues und verständliches) Modell dieses Objekts benötigen. Und je komplexer das Objekt oder je weniger Informationen darüber sind, desto schwieriger ist es, ein gutes Modell davon zu erhalten - und dies wirkt sich negativ auf das Management aus.
Ich denke, nur sehr wenige Menschen würden nicht zustimmen, dass alle unsere Dienstleistungen Vorbilder sind. Aber was modellieren wir? Es ist sehr wichtig, auf Geschäftsprozesse zu achten und nicht nur den Zustand, sondern auch das Verhalten zu modellieren.
Ende 2017 wechselte ich zum neuen CORE-Team. Dieses Team wurde dann speziell gebildet, um die Aufgaben der IT-Strategie zur Zerlegung monolithischer Systeme auszuführen. Unser Hauptziel war es, dieses sehr große, aber fragile Auftragsabwicklungssystem zu reduzieren (Voice-Over: Dann wussten die Samurai nicht, dass dieser Weg einen Anfang, aber kein Ende hatte!).
Es war eine neue Erfahrung für mich. Ein Team mit völlig anderen Prinzipien und Denkweisen. Entscheidungen wurden schnell getroffen, es gab Experimente und das Recht, Fehler zu machen. Die Balance war perfekt: Wir haben versucht, dort zurückzurollen, wo die Auswirkungen minimal waren, aber wir haben jeden Schritt für kritische Momente im Detail vorgeschrieben.
Wir haben einen neuen Service geschrieben, um Aufträge von Grund auf in einer anderen Sprache zu erstellen (als PHP-Entwickler haben wir zu Golang gewechselt). Wir haben das erste Ergebnis ausgewertet und erneut geschrieben. Der Schwerpunkt lag auf Einfachheit und Zuverlässigkeit. Sie stellten das Datenmodell in den Mittelpunkt und bauten die gesamte Architektur auf. Das Ergebnis ist ein zuverlässiger und belastbarer Service. Wir haben es geschafft, es mithilfe des experimentellen Mechanismus fehlerfrei in Betrieb zu nehmen. Im Laufe der Zeit hat sich das konstruierte System mehr als einmal bewährt.
Imbiss Nr. 4:Alle Modelle sind falsch, aber einige sind nützlich. Die Modellierung von Zuständen reicht nicht aus, um korrekte und stabile Systeme zu erstellen. Es ist notwendig, das Verhalten zu betrachten: Kommunikationsmuster, Ereignisströme, wer für diese oder jene Daten verantwortlich ist. Sie sollten nach Beziehungen zwischen Daten suchen und auf die Gründe für diese Beziehungen achten.
Es dreht sich alles um das Dum Dum Da Da Dum Dum
An meiner Universität gab es einen Kurs in mathematischer Analyse, der von einem außerordentlichen Professor und einem Doktoranden unterrichtet wurde. Elena Nikolaevna. Sie war sehr streng, aber fair. Während der Tests stießen wir hin und wieder auf Probleme, für deren Lösung es notwendig war, die Vorlesungen ein wenig zu "verdrehen" - um einen unabhängigen Schritt zum Verständnis des Materials zu machen. Und bei der Abschlussprüfung, die ich übrigens das zweite Mal bestanden habe, musste ich Flexibilität beim Denken zeigen und meine Intuition einsetzen, um das Problem als „gut“ zu lösen. Hier ist die Regel, dass E.N. Sie erzählte uns den ganzen Kurs, den ich zehn Jahre später benutze:
Wenn Sie nicht wissen, was Sie tun sollen, tun Sie, was Sie wissen.
Deshalb war ich stolz darauf, Matan gut zu kennen. Weil nach den Standards von E.N. Es reicht nicht aus, das Material zu kennen, aber es ist auch wichtig, es zu verstehen, um etwas Neues synthetisieren zu können.
Takeaway Nr. 5: Je weiter Sie gehen, desto mehr Verantwortung müssen Sie übernehmen und desto mehr Entscheidungen müssen Sie treffen. In einem bestimmten Moment verschwindet das absolute Vertrauen als Kategorie, sondern die Kunst des Gleichgewichts folgt dem Mut, einen Schritt zu tun.
Es kommt eine Zeit, in der es keine richtige Person in Ihrer Nähe gibt, die die bestehende Unsicherheit beseitigen könnte. Sie müssen die Risiken selbst einschätzen und Verantwortung für sich selbst übernehmen. Treffen Sie Entscheidungen angesichts der Unsicherheit.
In der zweiten Hälfte des Jahres 2018 leitete unser Team das Projekt Geschenkgutscheine. Anfangs war ich für die Entwicklung in und um die Verarbeitung verantwortlich. Später, Ende des Jahres, übernahm die technische Leitung des gesamten Projekts die Aufgabe, das Kräfteverhältnis wiederherzustellen, nachdem ein Teil des Teams gegangen war.
Die Regeln im Kopf und in der Weltordnung des Entwicklers platzten aus allen Nähten und brachen schließlich zusammen. Die Verantwortung für ein großes und komplexes Projekt hat mich von den idealistischen Vorstellungen über die Entwicklungswelt mit Konzepten und einem Regenbogen abgehalten. Die grausame Welt der Einschränkungen und gerade genug Lösungen erforderte ein Verständnis und eine Überarbeitung aller Ansätze und Regeln, denen ich folgte.
Imbiss Nr. 6:Impostor-Syndrom. Was ist, wenn ich ausgesetzt werde? Natürlich werden sie aussetzen, wenn nichts getan wird. Wenn Sie etwas Wichtiges tun, bemerken Sie nach einer Weile, dass es niemanden gibt, der Sie bloßstellt.
Divergenz und Konvergenz
In Übereinstimmung mit der Chronologie meines "Entwicklerpfades" sollte es aus technischer Sicht eine interessante Geschichte über das Projekt der persönlichen Richtlinien geben. In diesem Projekt haben wir die Echtzeit-Datenverarbeitung implementiert und "on the fly" die Prinzipien der Systemarchitektur geändert und auf "Events Driven Architecture" umgestellt. Aber darüber habe ich bereits einen separaten Bericht von der Highload '19 -Konferenz (und einen Artikel hier über Habré). Daher möchte ich Ihnen lieber etwas über die „hohen Angelegenheiten“ des technischen und nicht sehr des Managements erzählen.
Wenn ein Entwickler zum Senior heranwächst, was als "bereit, Verantwortung zu übernehmen und Entscheidungen autonom zu treffen" verstanden werden sollte, ist der nächste klassische Schritt die Teamführung. Ein Teamleiter ist eine Person, die hauptsächlich für das Team verantwortlich ist, d. H. für Menschen und Entwicklungsprozesse. Der Kunde kommt nicht zum Entwickler, er kommt zum Teamleiter und fragt auch nach den Verpflichtungen des Teamleiters.
Es stellt sich als paradox heraus - sobald ein Entwickler gewachsen ist, um selbständig als Ingenieur zu arbeiten, wird er in einen Sturm namens Management gestürzt.
Nein, vielleicht scheint dieser Weg für jemanden recht bequem zu sein, und der Übergang von extrem eindeutigen Algorithmen und Protokollen für die Interaktion von Computersystemen zur Koordination einer Gruppe von Menschen erscheint logisch. Aber es scheint mir, dass sich die meisten Gespräche in Profil-Chats und auf Konferenzen für Teamleiter nicht umsonst um das Konzept des „Schmerzes“ drehen.
Was ist der Schmerz eines Teamleiters? Liegt es nicht daran, dass ein Ingenieur für das Management verantwortlich ist ?! Nein, warum dies geschieht, ist verständlich - wir haben keine Schule für technisches Management als solche, und es wird davon ausgegangen, dass ein IT-Ingenieur ein Übermensch ist, der alles herausfinden kann, einschließlich einer so „einfachen“ Sache wie Management.
Aber ich entschied mich für den anderen Weg und wählte die Position eines technischen Leiters als nächsten Karriereschritt. Als Architekt arbeite ich mit Entwicklungsteams zusammen und jetzt höre ich von den Leuten, was ich vor einem Jahr selbst zu den Managern gesagt habe:
Warum sind die Anforderungen so schlecht entwickelt? Krückenlösungen! Welche zwei Wochen ?! Hier arbeite ich einen Monat.
Aber ehehei, jetzt ist es meine Aufgabe, solche Probleme zu lösen. Aber sobald Sie Ihr Denken in das Kosten-Nutzen-Paradigma umsetzen, stellen Sie fest, dass all diese Probleme nicht gelöst werden können - Sie über das dat-Leben!
Takeaway # 7: Eröffnung! Manager beschäftigen sich nicht mit Problemlösungen, sie kümmern sich um Unordnung.
Meine Aufgabe als technischer Leiter ist es, Unsicherheiten für das Entwicklungsteam zu beseitigen. Anforderungen nicht ausgearbeitet? Krückenlösungen? Bietet die Architektur nicht? Dies sind alles Signale für Systemzerbrechlichkeit und -divergenz.
Angenommen, die Aufgabeneinstellung im Auftragserstellungsservice sieht folgendermaßen aus:
Es ist erforderlich, das X-Feld und das Y-Feld hinzuzufügen. Es ist erforderlich, dass der Wert im Y'-Feld am Ausgang dem Z-Wert entspricht, wenn X 1 ist.
Das Problem liegt in der Anforderungserklärung. Der Fehler hierbei ist, dass völlig unklar ist, welchen Zustand des Systems Sie erreichen möchten. Vollständig definierte Schritte in der Anweisung führen zu Unsicherheiten während der Implementierung und des Betriebs.
Nach mehreren derartigen Aufgaben befindet sich der Dienst zur Auftragserstellung in einem ziemlich fragilen Zustand - und solche Fälle, in denen wir ein paar Felder hinzugefügt haben und alles kaputt gegangen ist, werden beginnen.
Ziel: Gewährleistung der Konvergenz der Systemzustände, der Kohärenz der Aufgabenstellung und der Verringerung der Unsicherheit zur Erreichung der Stabilität.
Die Menschen, die an der Repräsentationslinie arbeiten, bauen und aktualisieren ständig ihre Modelle dessen, was jenseits der Linie liegt. Diese Aktivitäten sind für die Ausfallsicherheit von Internet-Systemen von entscheidender Bedeutung und stellen eine wichtige Quelle für Anpassungsfähigkeit dar. Über der Linie, unter der Linie
Der Architekt muss die Einheit des sozio-technischen Systems verstehen. Sie können Prozesse oberhalb der Präsentationslinie so koordinieren, dass Systeme unterhalb der Präsentationslinie die Anforderungen an Korrektheit, Stabilität und Anpassungsfähigkeit erfüllen.
Takeaway # 8: Wenn die Regeln nicht mehr funktionieren, herzlichen Glückwunsch, haben Sie die Randbedingungen erreicht, unter denen das aktuelle Modell nicht mehr funktioniert. Es ist Zeit, Ihre Ideen zu überarbeiten und ein neues Modell zu finden, das den aktuellen Einschränkungen entspricht und es Ihnen ermöglicht, angemessene Prozesse und Regeln zu erstellen.
Weich ist einfach, Menschen sind hart!
Nicht wirklich. Dies wurde in einem Buch über Architektur geschrieben. Und je weiter ich gehe, desto öfter wiederhole ich dieses Buch.
Technische Konzepte, Algorithmen und Standards sind klar - Sie müssen sie nur nehmen und konsequent herausfinden. Ich versuche nicht, die Arbeit von Ingenieuren zu reduzieren - Algorithmen für verteilte Systeme sind äußerst komplex, wenn Sie solche Systeme nicht täglich erstellen. Meistens tritt die Hauptschwierigkeit, mit der wir im Arbeitsprozess konfrontiert sind, auf, wenn wir verstehen müssen, warum dieser oder jener Dienst einen solchen Abstraktionsgrad für die Domäne erfordert. Und das Problem wird oft durch die Tatsache verschärft, dass die Person, die den Dienst geschrieben hat, nicht da ist.
Einfach zu implementierende Algorithmen sind erfolgreicher als mathematisch genaue. Paxos ist mathematisch genau, aber nur mit der Beschreibung des Raft-Protokolls, das einfacher zu implementieren ist, wurde die praktische Anwendung von Konsensalgorithmen entwickelt.
Die Golang-Sprache wird als zu begrenzt kritisiert. Aber darauf sind Docker, Kubernetes und viele andere verteilte Systeme geschrieben. Ein gut konzipiertes System von Einschränkungen dient als Grundlage für erfolgreiche Systeme.
Alles wäre viel einfacher, wenn die Technologie nicht mit dem menschlichen Faktor rechnen müsste. Aber sie müssen. Jedes System in der IT, an dessen Bau und Wartung mehr als eine Person beteiligt ist, muss den menschlichen Faktor berücksichtigen.
Und hier entstehen Technologien an der Schnittstelle von Software und Menschen, die das Chaos strukturieren und komplexe Interaktionen beschreiben sollen. Domain Driven Design, Microservices, Agile - alle schaffen Einschränkungen, die die Prinzipien und Regeln der Interaktion beschreiben. Es erscheinen Strukturen, mit denen klar ist, wie man arbeitet. Mit dem Aufkommen solcher Technologien wird es jedoch nicht immer besser. Sehr oft stellt sich umgekehrt heraus - Was Geld nicht kaufen kann .
Takeaway # 9: Programme können und sollten einfach sein. Dazu müssen Sie die Bildung einer Ingenieurkultur stärken. Sie bestimmt letztendlich die Leistung der Dienstleistungen.
Lese liste
Bücher
Der Weg des Managers: Ein Leitfaden für Technologieführer, die sich in Wachstum und Wandel zurechtfinden, Camille Fournier - Link
Das elegante Puzzle: Systeme des technischen Managements, Will Larson - Link-
Team-Topologien: Organisation von Geschäfts- und Technologieteams für Fast Flow, Manuel Pais und Matthew Skelton - Link
aufrichtenden Software, Juval Löwy - Link
Denken in Systemen: Ein Primer, Donella Meadows - Referenz
Artikel
Mentale Modelle, Street Fernam - Link
Komplexität Bias: Warum Wir bevorzugen Komplizierte einfach. Fernam Street - Link
Was Geld nicht kaufen kann, LessWrong - Link
Ungewöhnlich wahrheitsorientiert werden, LessWrong -Link
Programmiergesetze und Realität: Wissen wir, was wir zu wissen glauben? - Link
Keine Silver Bullet Essenz und Unfälle des Software-Engineerings - Link
Die Kunst der Fehlerbehebung - Link
Von fragiler zu antifragiler Software - Link
Computer können verstanden werden - Link
Tuckman war falsch! (About Teams) - Referenz
Wie bei fast alles zum Scheitern verurteilt und noch ein großen Gewinn - Link
Einfachheit Vor Generalität, Verwendung Vor Wiederverwendung - Link
Einfachheit, Bitte - Ein Manifest für Software - Entwicklung - Link
- Software Design ist menschliche Beziehungen - Ein Link