collaboration devops
Zusammenarbeit in DevOps:
Kleine Lieferschritte in DevOps wurde in unserem vorherigen Tutorial ausführlich erklärt.
Wir wissen, dass das Schlüsselmantra von DevOps die Zusammenarbeit ist und daher das Wort DevOps angekommen ist.
Durchlesen => Ausführliche DevOps-Tutorials
Die Zusammenarbeit besteht darin, sich zu einem einzigen Team zusammenzuschließen, um alle Probleme im Programm zu lösen. Dies behindert die Kundenorientierung bei der Zielerfassung des Programms und löst sie, indem sie so schnell wie möglich ohne Schuldzuweisungen als eigenes Problem betrachtet werden.
Durch die Zusammenarbeit lernen alle, miteinander zu sprechen, sich von Angesicht zu Angesicht zu treffen, sich in ihre Besprechungen und Diskussionen einzubeziehen, die Aufgaben des anderen zu verstehen, abhängig zu sein und Transparenz in der Arbeit zu haben und proaktiv zu arbeiten, um die Probleme zu vermeiden.
VIDEO Teil 2 Block 5: Zusammenarbeit - 15 Minuten 36 Sekunden
Transkript:
Der Begriff Zusammenarbeit wird in DevOps immer wieder wiederholt und das Devops-Mantra ist Zusammenarbeit. Lassen Sie uns also verstehen, was „Zusammenarbeit“ in der Softwareentwicklung und im DevOps-Kontext wirklich bedeutet.
Sobald eine Organisation sagt, dass wir DevOps implementieren, beginnt meiner Meinung nach automatisch das Denken an die Zusammenarbeit, das mit der Praxis der Entwickler verbunden ist, in allen Köpfen und macht sie fokussierter und aufmerksamer gegenüber der Zusammenarbeit, und sie haben das Gefühl, dass sie zusammenarbeiten müssen . Das ist die Magie der Zusammenarbeit.
Daher ist es für die Organisation und das Team sehr wichtig, die DevOps-Zusammenarbeit von Beginn des Projekts an zu initiieren. Das Team meine ich, Teammitglieder des Programms.
Ich werde einige Fälle erläutern, in denen ich gesehen habe, wie Dev mit Ops zusammenarbeitet und Ops mit dem Dev-Team zusammenarbeitet, damit wir wissen, was Zusammenarbeit im DevOps-Kontext tatsächlich bedeutet.
Dies ist die Darstellung der ersten Instanz.
Es gab einen Fall, in dem ein unbekanntes Problem im Installationsskript oder Konfigurationsskript auftrat, bei dem das Ops-Team eine Herausforderung bei der Installation der Software auf einem bestimmten Cluster-Setup in einer bestimmten Region fand.
Es warf einen unbekannten Fehler auf und war ein reines Produktionsproblem, das in der Entwicklungsumgebung nie aufgetreten ist, und das Betriebsteam hat wirklich viel Mühe darauf verwendet, sie selbst zu lösen, da es dachte, dass es etwas mit der Einrichtung zu tun hat und sie lösen müssen es, das für eine lange Zeit nicht gelöst wurde.
Dann mischte sich das Entwicklerteam sofort ein, ohne überhaupt zur Hilfe eingeladen zu werden. Obwohl die Zeitzone anders war, übernahm es die Kontrolle über den Produktionsstandort. Sie wissen, dass der Zugriff auf die Produktion im Allgemeinen nicht jedem gewährt wird. Ops teilt nur den Fehler Details oder andere Informationen, die das Team zum Debuggen benötigt.
Diese Situation ist jedoch erforderlich, um einem Mitglied des Entwicklerteams Zugang zu gewähren, das einige Stunden damit verbracht hat, das Problem live zu analysieren und sofortige Abhilfe zu schaffen. Daher wurde das Problem schnell behoben.
.net Interview Fragen mit Antworten
Dies ist der Fall der Zusammenarbeit, in der das Entwicklerteam das Problem freiwillig besaß und dem Ops-Team half, es zu lösen. Dies ist eine reine Instanz der Zusammenarbeit.
Lassen Sie mich in einem anderen Fall das Diagramm schematisch zeigen, das ich gezeichnet habe. Ein anderes Beispiel ist, dass die Dinge nach dem Software-Upgrade auf einer bestimmten Site für einige Tage ziemlich gut funktionierten. Plötzlich verlangsamte sich die Leistung der Anwendung.
Endbenutzer mussten aufgrund dieser Verlangsamung schwere Transaktionsverluste hinnehmen. Viele Reklamationsanrufe gingen an CSRs, ich meine, Kundendienstmitarbeiter, und diese wiederum begannen, mit dem Team über das Problem zu sprechen.
In diesem Fall kamen sofort sowohl das Dev- als auch das Ops-Team zusammen, und mit den Informationen und Telemetriedetails, die das Ops-Team dem Dev-Team zur Verfügung stellte, konnten sie das Problem debuggen und feststellen, dass es ein Problem mit dem Aspekt der Lastverteilung und gab daher war die Leistung langsam.
Beide Teams haben also zusammengearbeitet, um das Problem zu beheben und innerhalb weniger Stunden wieder zur Normalität zurückzukehren. Hier haben sich also sowohl der Entwickler als auch die Ops zusammengetan und zusammengearbeitet, um das Problem zu lösen, anstatt dass der Entwickler sein Ops-Problem sagte und Ops dachte, es sei das Problem von Dev, und das Entwicklerteam muss es prüfen und beheben.
Dies ist ein klarer Fall der Zusammenarbeit, bei dem jeder die Probleme besitzt, anstatt das Schuldspiel zu spielen, unabhängig davon, um welches Problem es sich handelt, oder Zeit damit zu verschwenden, herauszufinden, um welches Problem es sich handelt, wobei zu berücksichtigen ist, dass der Endbenutzer leidet und das Problem benötigt bald behoben werden.
Auch hier muss das Problem nicht nur in der Produktion liegen, es kann sich auch um ein einfaches internes Softwareentwicklungsproblem handeln, das so einfach ist wie das alltägliche Problem, ein Designproblem, ein Architekturproblem oder sogar ein einfaches Werkzeugproblem.
Jedes Problem im Zusammenhang mit dem Programm oder ein Problem, von dem das Team weiß, dass es dem Kunden Schaden zufügt oder das Programm verlangsamt, muss jedem gehören, anstatt das Problem zu isolieren, dass es sich um ein Entwicklungsproblem oder ein Betriebsproblem oder ein Testproblem handelt. und dazu beizutragen, dass es so schnell wie möglich angegangen wird, ist eine Zusammenarbeit.
So extrahieren Sie 7z-Dateien auf einem Mac
Die Zusammenarbeit im DevOps-Kontext besteht also darin, dass Entwicklung und Betrieb zusammenkommen und zusammenarbeiten, um das Problem so früh wie möglich zu lösen, wobei der Kundenfokus berücksichtigt wird.
Die Zusammenarbeit ist sowohl für Entwickler als auch für Ops von Bedeutung, da die Überwachung und Protokollierung sowie die Leistungsprüfung im Vordergrund stehen, um das Problem zu lösen, das insbesondere in der Produktion im Interesse des Endbenutzers auftritt.
ODER einfach, ich kann sagen, dass das gesamte Team, das ständig zusammenarbeitet, um das Problem zu lösen, um die Programmziele zu erreichen und die Kundenorientierung im Auge zu behalten, die Zusammenarbeit ist. Ich wiederhole, ständig zusammenzuarbeiten, um die Probleme zu lösen, um die Programmziele zu erreichen, wobei die Kundenorientierung im Auge behalten wird, ist die Zusammenarbeit.
Dann stellt sich die Frage, wie wir diese Zusammenarbeit entwickeln und wann wir die Zusammenarbeit zwischen dem Team initiieren müssen, das meilenweit voneinander entfernt sitzt.
Offensichtlich wissen wir, dass sowohl Dev als auch Ops nicht zusammen lokalisieren können. Das Ops-Team muss näher am Arbeitsplatz oder an den Rechenzentren sein, und der Entwickler muss näher am Softwareentwicklungszentrum sein. Wie erreichen wir die ständige Zusammenarbeit zwischen beiden Teams?
Zunächst einmal ist es für die Organisation und das Team sehr wichtig, die Zusammenarbeit mit DevOps von Beginn des Projekts an zu initiieren. Das Team, das ich hier meine, sind die Teammitglieder des Programms.
Das Üben einiger der folgenden Dinge würde dazu beitragen, die Lücke zwischen dem Team zu schließen und die Einschränkungen virtueller Teams zu überwinden, und hilft dabei, die Zusammenarbeit zu erreichen.
Lassen Sie uns also sehen, welche Praktiken zur Erreichung der Zusammenarbeit beitragen.
Beziehen Sie die Entwicklung in alle relevanten Besprechungen und Diskussionen des Betriebsteams ein und umgekehrt.
Dies bringt sie nicht nur zusammen, sondern hilft auch dabei, jeden ihrer Arbeitsbereiche, ihre täglichen Probleme und die Auswirkungen ihrer Arbeit auf einander zu verstehen und welche kritischen Dinge jeder beachten sollte, um die Probleme später und später zu vermeiden Dies bringt sie näher zusammen und leitet jedes Mal eine angenehme Diskussion untereinander ein.
Vor der Einführung der DevOps-Praxis war es dem Entwicklerteam nie wichtig, die Software an Operations zu liefern. Sie wissen, dass sie früher unwissend waren oder sich nie um Dinge wie Infrastruktur, Konfigurationen, Server-Setups, Netzwerkkonfigurationen, Überwachung von Live-Auftritten usw. kümmerten.
Früher dachten sie, dass all diese Aktivitäten in der Verantwortung des Operations-Teams liegen und das Entwicklerteam nie davon erfahren hat. Früher bedeutete die Lieferung für das Entwicklungsteam, dass sie nur an das Betriebsteam geliefert wurde. Bei der DevOps-Praxis bedeutet die Lieferung jedoch für die Produktion und nicht nur für den Betrieb.
In ähnlicher Weise kümmerten sich Ops nie um den Code, den das Entwicklungsteam produzierte. Bei Problemen mit der Softwareinstallation, der Funktionalität oder der Leistung in der Produktion haben sie das Geld einfach an das Entwicklungsteam weitergegeben und sie gebeten, es zu beheben und zurückzugeben.
Wenn Sie also die Arbeit des anderen kennen und ihre Aufgabe verstehen und das Problem des anderen während des gesamten Zyklus besitzen, kann das Team die Probleme schnell lösen.
Weil sie wissen, wo das Problem liegt und was im Programm passiert und was das Problem in der Produktion verursacht, und es daher ohne große Schwierigkeiten direkt beheben können.
Auswahl Sortieralgorithmus c ++
Zusammenarbeit bedeutet also, dass das Entwicklungsteam die Infrastruktur und Konfiguration verstehen muss und dass das Betriebsteam sich um Code, Qualität, Bereitstellung und Zeitpläne kümmern muss.
Das Verständnis der gegenseitigen Abhängigkeit hilft dabei, die Arbeit zu beschleunigen und pünktlich zu liefern.
Wie bei der Softwareinstallation ist das Betriebsteam auf ein Entwicklungsteam angewiesen, um alle Probleme im Zusammenhang mit der Installation zu lösen. In ähnlicher Weise hängt das Entwicklungsteam beim Codieren von vielen Voraussetzungen ab, die das Betriebsteam im Leben erfüllt, um während des Codierungsprozesses für Sorgfalt zu sorgen.
Ein weiterer Beispiel Ist das Testteam darauf angewiesen, dass das Betriebsteam Live-Beispieldaten aus der Produktion zum Testen bereitstellt? Umgebungskonfigurationsdetails, die in der Entwicklungsumgebung usw. eingerichtet werden sollen.
Daher müssen beide Teams zusammenarbeiten und die Abhängigkeit voneinander verstehen und die Daten oder Informationen rechtzeitig bereitstellen, ohne Verzögerungen zu verursachen, indem sie den Zeitzonenfaktor berücksichtigen.
Sorgen Sie für Transparenz, indem Sie die DevOps-Methoden wie Quellcodeverwaltung oder Versionskontrolle anwenden, die es dem Team ermöglichen, alles über das Programm zu verstehen und Missverständnisse zu vermeiden.
Dies bedeutet also im Grunde, die Transparenz innerhalb des Teams aufrechtzuerhalten.
Teammitglieder müssen sich nicht auf eine Person oder eine bestimmte Information verlassen müssen, wenn jemand die an einem bestimmten Knoten im Cluster eingerichtete Konfiguration wissen möchte, damit sie nicht warten müssen, bis das Betriebsteam aufwacht und Geben Sie diese Details an sie weiter, stattdessen können sie zum Versionskontrolltool gehen und diese Informationen abrufen und ihre Aufgabe ohne Verzögerung erledigen.
Voneinander zu lernen, insbesondere aus den Fehlern der anderen, ist das größte Merkmal der Zusammenarbeit. Damit sie diese Fehler, die bereits von jemand anderem gemacht wurden, nicht wiederholen.
Entwicklung lernt also aus dem Betrieb und Betrieb lernt aus der Entwicklung, sei es eine neue Technologie, ein neues Werkzeug oder etwas einfacher und besser. Wo sich beide auf derselben Seite befinden und daher zusammenarbeiten, indem sie voneinander lernen.
Der Betrieb hatte immer das Gefühl, dass das Entwicklerteam sehr langsam ist und nicht pünktlich liefern kann. Jetzt, da sie täglich mit dem Entwicklungsteam interagieren, verstehen sie, was die Verzögerung verursacht, sei es weniger Klarheit in der Anforderungen, Entwurfsproblem, Codierungsproblem oder ein anderes Werkzeugproblem.
Sogar sie werfen ein und liefern ihre wertvollen Vorschläge, um sie zu verbessern.
Im Falle eines Problems aus der Produktion oder vom Entwicklungsstandort führt DevOps eine Kultur ein, bei der das Problem zuerst behoben wird, anstatt herauszufinden, wer oder welches Team dieses Problem eingeführt hat. Daher versuchen alle, sich darauf zu konzentrieren, das Problem zu beheben, anstatt Zeit damit zu verschwenden, herauszufinden, wer das Problem verursacht hat.
Hören Sie also auf, die Schuld zu geben und jedes Problem als ihr eigenes zu betrachten, und melden Sie sich, um sie gemeinsam zu lösen und das Problem zu unterstützen. Die gegenseitige Unterstützung bei ihren Problemen ist wieder eine Zusammenarbeit.
Also, ich kann sagen, hör auf, das Spiel zu beschuldigen, Schuldzuweisungen sind wieder ein Merkmal der Zusammenarbeit.
Wenn jeder anfängt, gemeinsam in die gleiche Richtung zu denken, die gleiche Denkweise zu haben und an den gleichen Aspekten und Praktiken zu arbeiten, ist dies wieder eine Zusammenarbeit, wie wenn eine neue Funktion entwickelt wird. Jeder denkt darüber nach, wie man dies testet, wie man dies bereitstellt, wie man dies überwacht. ist eine Zusammenarbeit.
Das gemeinsame Denken innerhalb des Teams ist also wieder ein Merkmal der Zusammenarbeit.
Machen wir jetzt eine Pause und verstehen in unserem nächsten Video etwas mehr über die Zusammenarbeit.
PREV Tutorial | NÄCHSTES Tutorial
Literatur-Empfehlungen
- So entwickeln Sie die Zusammenarbeit in DevOps-Teams
- Bedeutung kleiner Inkremente von Lieferungen in DevOps
- Kontinuierliche Integration in DevOps
- Kontinuierliche Bereitstellung in DevOps
- Kontinuierliche Lieferung in DevOps
- DevOps-Automatisierung: Wie wird die Automatisierung in der DevOps-Praxis angewendet?
- DevOps Tutorial: Der ultimative Leitfaden für DevOps (25+ Tutorials)
- DevOps-Test-Tutorial: Wie wirkt sich DevOps auf QS-Tests aus?