Bevor Sie die Frage „Wie misst man Erfolg?“ Beantworten, müssen Sie verstehen, was „Erfolg“ für Sie bedeutet. Für Dev und Ops ist die Definition von Erfolg unterschiedlich. Für Dev ist ein erfolgreiches Projekt vollständig getestet. Zur Betriebsüberwachung. Tests und Überwachung sind erforderlich, aber Tests decken das Problem nie zu 100% ab, und eine Antwort von 200 über HTTP reicht nicht aus, um sicherzustellen, dass das System ordnungsgemäß funktioniert. Leon Fayer von RIT ++ verteidigte den Standpunkt, dass DevOps nicht zahlen, um sicherzustellen, dass sich alle Metriken in der Überwachung in der grünen Zone befinden. Sie zahlen, um Benutzer glücklich zu machen . Wenn Sie unzufrieden sind - das Geschäft verliert Geld und niemand kümmert sich darum, dass alles grün ist.
Unter einer Katze gibt es viele Beispiele aus der Praxis, die diesen Standpunkt belegen. Lassen Sie uns herausfinden, warum Sie das Geschäft verstehen, wie Sie den Erfolg aus geschäftlicher Sicht überwachen und warum normale Entwickler ihn benötigen.
Über den Sprecher: Leon Fayer wurde in einer einst freundlichen Republik geboren, wuchs aber in den USA auf. Ich habe vor vielen Jahren angefangen zu programmieren und während dieser Zeit arbeitete ich als Programmierer, Manager, den ich einfach nicht arbeitete. Teilnahme an Startups - einige waren erfolgreicher, andere nicht sehr erfolgreich.
Leon arbeitet seit vielen Jahren bei OmniTI. Dieses Unternehmen ist auf die Entwicklung skalierbarer Systeme spezialisiert, sodass Leon die einmalige Gelegenheit hat, Systeme für die meistbesuchten Websites der Welt zu entwerfen und zu bauen - Wikipedia, National Geographic, Weißes Haus, MTV usw.
Bevor Sie die Frage „Wie misst man Erfolg?“ Beantworten, müssen Sie verstehen, was „Erfolg“ für Sie bedeutet. Für jede Person ist die Antwort unterschiedlich.
Wenn Sie diesen Artikel lesen, sind Sie höchstwahrscheinlich an DevOps beteiligt. Bist du mehr Dev als Ops? Oder umgekehrt mehr Ops als Dev? Für Dev und Ops ist die Definition von Erfolg etwas anders: Für Dev ist natürlich Testen.
Testen
Erfolgreiches Testen bedeutet für mich als Programmierer, dass alles in Ordnung ist, alles in Ordnung ist, alles funktioniert - Sie können es in der Produktion ausführen. Das Problem ist, dass ich auch ein Zyniker bin und kein Fan von Tests als solchen. Nicht weil es schwierig ist und nicht weil es lang ist - sondern weil das Testen nicht das gibt, was ich will.
Verstehen Sie mich richtig, das Testen ist ein obligatorischer Prozess , es sollte in jedem Projekt enthalten sein, aber es reicht eindeutig nicht aus, um den Erfolg zu garantieren .
Es gibt viele verschiedene Testoptionen:
- Leistungstests;
- Benutzertests;
- automatische Prüfung ...
Wie viele Testmethoden verwenden Sie - 1, 2, 3, 5? Und was, Sie sind nachts nicht wach? Funktioniert alles in der Produktion?
Das Problem ist, dass das Testen die Illusion von Erfolg vermittelt . Es ist vorbestimmt: Wir wissen, dass der Zug Punkt A verlassen und Punkt B erreichen muss, dafür testen wir. Es gibt Optionen, die wir in Betracht ziehen. Wenn der Zug vom Lenkrad fällt oder kein Holz mehr hat, ist dies keine Überraschung. Aber wir testen zum Beispiel keinen Zugraub. Wir können dies nicht testen, da wir nicht wissen, dass eine solche Option möglich ist.
Es gibt einige Probleme, aufgrund derer das Testen einfach nicht ausreicht. Das erste ist natürlich ein Datenproblem . Die Tatsache, dass die Aufgabe lokal funktioniert, aber aus irgendeinem Grund nicht in der Produktion funktioniert, ist ein Standardproblem.
Egal wie sehr wir es versuchen. Es spielt keine Rolle, wie viele Replikationen wir leben - Entwicklung und Produktion werden niemals gleich sein. Wird es eine weitere Zeile in der Datenbank geben, wird es eine weitere zusätzliche Anfrage geben - es wird immer etwas in der Produktion sein, das wir nicht erwartet haben.
Wolfe + 585 - der längste Nachname der Welt:
Hubert Blaine
Wolfeschlegelsteinhausenbergerdorffwelchevoralternwaren-gewissenhaftschaferswessenschafewarenwohlgepflegeundsorgfaltigkeitbeschutzen-vorangreifendurchihrraubgierigfeindewelchevoralternzwolfhunderttausendjahres-vorandieerscheinenvonderersteerdemenschderraumschiffgenachtmittungsteinund- siebeniridiumelektrischmotorsgebrauchlichtalsseinursprungvonkraftgestartsein-langefahrthinzwischensternartigraumaufdersuchennachbarschaftdersternwelchege-habtbewohnbarplanetenkreisedrehensichundwohinderneuerassevonverstandig-menschlichkeitkonntefortpflanzenundsicherfreuenanlebenslanglichfreudeundruhe-mitnichteinfurchtvorangreifenvorandererintelligentgeschopfsvonhinzwischensternartigraum,
Sr.
Nur wenige Systeme überleben, wenn jemand einen solchen Nachnamen in das Formular eingibt. Ich kenne mindestens 5 verschiedene Punkte, an denen das gesamte System fliegen kann.
Daher ist das zweite Problem das Problem mit den Benutzern .
Das sind so interessante Leute, die alles kaputt machen. Wenn es keine Benutzer gäbe, wäre alles viel einfacher, um ehrlich zu sein.
Selbst wenn Ihre Benutzeroberfläche eine Schaltfläche enthält, finden sie dennoch eine Methode, um das zu brechen, was wir tun.
Das beste Beispiel ist World of Warcraft .
Für diejenigen, die es nicht wissen, ist dies ein Online-Spiel, das von 10 Millionen Menschen gespielt wird. Zu einer Zeit gab es ziemlich legendäre Fehler. Korrupte Blutwanze ist ein perfektes Beispiel dafür, wie Benutzer alles verderben.
Wie bei jedem Spielzeug tauchten in World of Warcraft ständig neue Inhalte, neue Ideen und neue Bosse auf. Einer der neuen Bosse verfluchte einen der 40 Spieler der Gruppe. Das Prinzip des Fluches war wie eine Zeitbombe - es nahm langsam das Leben aller um sich herum. Das heißt, es war notwendig, zur Seite zu rennen - es gab eine ganze Mechanik. Und alles war in Ordnung, bis irgendwann einer der Spieler beschloss, sich während der Schlacht in die Stadt zu teleportieren ...
In der Stadt lebten Tausende von Menschen aller Ebenen, auch die kleinsten. Nicht nur das, es gab immer noch Nicht-Spieler-Charaktere, die sich ebenfalls mit einem Fluch infizierten. Tagsüber waren die Server leer. Es war unmöglich, irgendwohin zu gehen, wo andere Spieler waren. Es wurde eine Wildpest im wahrsten Sinne des Wortes. Ich musste alle Server neu starten, um den Fluch zu beseitigen und die Mechanik zu ändern. Und das alles wegen eines Testers - ich weiß nicht einmal, wie ich es nennen soll.
Das dritte Hauptproblem ist das Problem mit der externen Abhängigkeit . Wir alle sind darauf gestoßen: Die API, von der Sie abhängig sind, funktioniert plötzlich nicht mehr. oder Sie beenden die Steuerung der API.
Aber es gibt ein größeres Problem damit. Externe Abhängigkeit kann nicht nur direkt, sondern auch indirekt sein. Wir alle verwenden jetzt OpenSource. Jedes OpenSource-Produkt hängt von einigen Bibliotheken ab, die ebenfalls OpenSource sind und von einer anderen Person unterstützt werden. Wenn etwas kaputt geht, bricht es nicht nur in diesem kleinen Modul, sondern in allem, was davon abhängt.
Das wahrscheinlich idealste Beispiel war vor kurzem, vor ungefähr einem Jahr - dies ist das linke Pad . Dies ist ein npm-Modul in node.js, das Leerzeichen vor der Zeichenfolge (am Anfang einer Zeile) verfügbar macht. Wir werden nicht diskutieren, warum dieses Modul hergestellt wurde. Es stellt sich jedoch heraus, dass es in vielen beliebten Modulen enthalten war. Irgendwann entschied der Autor, dass er genug hatte, entfernte dieses Modul von npm und 70% des in node.js geschriebenen Codes flogen.
Wenn Sie denken, dass dies ein Einzelfall ist, irren Sie sich.
Es gibt auch das is-odd-Modul, das jetzt in npm ist. Dieses Modul definiert eine gerade Zahl oder nicht.
Wir werden nicht die Tatsache diskutieren, dass 3 Millionen Menschen nicht wissen, wie man Parität / Seltsamkeit überprüft. Aber es gibt 12 weitere Module, die es verwenden! Und es ist nicht bekannt, wie viele dieser Module die Module noch verwenden. Wenn es Ihnen so vorkommt, als gäbe es nichts zu brechen - es gibt 5 Versionen!
Zurück zu unseren Schafen - es gibt viele weitere Möglichkeiten:
- Kurzsichtigkeit - wir wissen nicht, was in Zukunft passieren wird. Y2K ist ein perfektes Beispiel. Niemand dachte nur, dass im Jahr 2000 alles, was in Kobol geschrieben wurde, fliegen würde.
- Anzahl der Testoptionen .
Es gibt wieder ein gutes Beispiel für World of Warcraft - sie haben viele gute Beispiele zu diesem Thema.
Sechs Monate nach der Veröffentlichung des Spiels kamen Appelle, um zu unterstützen, dass einige Spieler nicht eine Höhle betreten konnten. Es stellte sich heraus, dass nur eine Version von Rasse und Geschlecht diese Höhle nicht betreten konnte - dies waren weibliche Tauren.
Warum hat es 6 Monate gedauert, diesen Fehler zu finden - schließlich spielen Millionen von Menschen? Weil Tauren eine fiktive Rasse ist, eine Mischung aus Mensch und Stier. Tauren Frau ist eine sprechende Kuh. Niemand wollte eine Kuh spielen, also erreichte 6 Monate lang keine einzige Person das maximale Level, um in die Höhle zu gehen und diesen Käfer zu finden. Dementsprechend hat es niemand getestet.
- Änderung der Quelldaten. Wir wissen wirklich nicht, was morgen passieren wird.
In jedem Fall gibt es nur wenige Tests. Tests ergeben jedoch keine 100% ige Abdeckung. Daher garantiert das Testen keinen Erfolg. Dies bringt uns allmählich zum zweiten Teil - Ops. Erfolg ist für die Ausbeutung die Überwachung .
Überwachung
Es gibt viele Gründe, warum eine Überwachung erforderlich ist:
- perfekter Code existiert nicht;
- Systeme werden immer komplexer;
- wachsende externe Abhängigkeit;
- Vorfreude -> Antwort;
- ...
Überwachung ist erforderlich, da sich alles ändert. Dies ist der Hauptgrund. Darüber hinaus ist es in der Produktion, dort ändert sich ständig alles, und wir müssen dies erkennen.
Was sollte die Überwachung abdecken? - Das war's! Dies ist eine kurze Antwort, die jedoch alles abdecken sollte.
Das ist alles ein bisschen abstrakt. Tatsächlich haben wir alle eine Checkliste, die wir überwachen:
- Infrastruktur
- Datenbanken
- Anwendungen
- Integrationspunkte;
- Bearbeitungszeit für Anfragen;
- laden;
- ...
Es kann eine Million Dinge geben. Viele sammeln Hunderte, Tausende und Zehntausende von Metriken auf ihren Systemen.
Wir werden dafür viele Metriken sammeln:
Natürlich übertreibe ich, aber alles, was wir aus Sicht von Ops brauchen, ist, dass HTTP 200 zurückgibt . Dies bedeutet, dass mit der Website alles in Ordnung ist. Sobald eine Site funktioniert, bedeutet dies, dass Datenbanken und Anwendungen funktionieren - alles ist in Ordnung. Aus Sicht von Ops ist Erfolg genau das: Alle Grafiken befinden sich in der grünen Zone, alles funktioniert korrekt - alles ist in Ordnung!
Jeder weiß, was Twitter ist. Sie verarbeiten 500 Millionen Tweets pro Tag - eine verrückte Zahl.
Sie sind aber auch für ihre Fehler bekannt. Fehler sind in ihrer Komplexität oder Leichtigkeit legendär - welche Seite zu betrachten ist.
Sie hatten einen Fehler: Die Website funktionierte, der Kunde konnte einen Tweet schreiben, auf eine Schaltfläche klicken, sie sagten Danke, der Tweet wurde gesendet - und das war's! Er erschien nirgendwo und verschwand einfach, und die Überwachung zeigte, dass alles in Ordnung war. Die Site gibt eine 200-Anfrage zurück - die API funktioniert. Aber es gibt keine Tweets!
Ich habe ein Lieblingszitat von einem Kunden. Ich habe eine Stunde lang Probleme auf drei Bildschirmen behoben, und er hat geschrien, warum nichts funktioniert. Als ich zu erklären versuchte, welche Probleme ich behebte, sagte mir eine Person, die mit zwei Fingern tippte und nicht verstand, wie man einen Computer benutzt:
"Solange ich weiterhin Geld verdiene, ist es für mich verdammt, dass die Server eingeschaltet sind."
In mancher Hinsicht ist dies sehr richtig, und das Twitter-Beispiel bestätigt dies: Alle Metriken zeigten, dass aus Sicht der Entwickler alles in Ordnung war, aber aus Sicht der Arbeit des Unternehmens war es überhaupt nicht in Ordnung.
Um ehrlich zu sein, sind wir alle schuld. Natürlich sind hauptsächlich die Unternehmen schuld, die Überwachungsprodukte herstellen. Aber wir auch, weil wir traditionell Systemmetriken sammeln. Wir sind es gewohnt, mit kleinen Systemen zu arbeiten - einem, vielleicht zwei Servern. Wenn sie funktionieren, ist alles in Ordnung.
Jetzt haben wir etwas mehr Server als zwei oder sogar zehn, und es reicht nicht aus, nur den Zustand des Systems oder den Zustand des Programms zu messen. Wir müssen die Arbeit von etwas anderem verfolgen.
Zurück zum Angebot: Ich werde dafür bezahlt, dass nicht alles grün ist. Ich werde bezahlt, damit meine Benutzer oder Manager zufrieden sind - jemand sollte mit dem Ergebnis zufrieden sein . Wenn alle Benutzer unglücklich sind, kümmert es niemanden, dass alles grün ist.
Geschäftsüberwachung
Wir sagten, dass Überwachung erforderlich ist, weil sich alles ändert. Aber wenn sich alles ändert, wirken sich Änderungen auf das Geschäft aus: Etwas ist kaputt gegangen - Geld ist nicht mehr eingegangen, etwas wurde repariert - Geld fließt wieder - eine direkte Korrelation. Oder sie beeinflussen es nicht - aber wenn wir das Geschäft nicht überwachen, wissen wir das nicht.
Als lebendes Beispiel ist das Cache-Lesediagramm jedem bekannt.
In 90% der Fälle ist alles in Ordnung, fast alle Anfragen gehen in den Cache. Und plötzlich passierte etwas - und das sehr ernst. Dies ist ein Problem, das um 3 Uhr morgens von jemandem geweckt werden sollte, der es lösen wird. Aber wenn sich die Download-Geschwindigkeit für Benutzer nicht ändert, ist dies wirklich ein Problem?
Im Englischen gibt es den Begriff Beobachtbarkeit - Beobachtbarkeit. Dies sind: Überwachung, Protokollierung, Alarmierung. Daher ist der Begriff Überwachung ein bisschen. Wir wollen alles beobachten - bei Bedarf Systemmetriken auf jedem Knoten sammeln. Aber wir wollen das Geschäft überwachen, weil es alle begeistert. Dies ist ein Indikator für den Erfolg.
Dazu müssen wir:
1. Verstehe das Problem - was genau müssen wir überwachen?
2. Bestimmen Sie die Basislinie - das heißt, es reicht aus, dass sich die Download-Geschwindigkeit des Benutzers nicht geändert hat, sodass niemand mitten in der Nacht aufwacht, wenn das Lesen aus dem Cache nicht mehr funktioniert.
3. Korrelierende Daten sind einer der wichtigsten Faktoren. Wenn Marketing Einkommensdaten sammelt und Sie Daten auf Servern sammeln und diese beiden Beobachtungen nicht vergleichen können, haben sie nur eine sehr geringe Bedeutung.
Normalerweise gebe ich viele Beispiele. Egal wie absurd sie aussehen würden, sie stammen alle aus meinem Leben und ich habe viel Nerven für sie aufgewendet.
Beispiel: Ich hatte einen Client mit 100 Millionen Benutzern. Es war eine Internet-Marketing-Firma, die viele E-Mails verschickte und A / B-Tests verwendete. Für sie haben wir 6.000 Metriken gesammelt.
Alles begann wie immer mit einem Anruf. Das Telefon klingelt - es bedeutet, dass etwas passiert ist.
" Wir haben ein Problem." Etwas funktioniert nicht.
- OK, was genau funktioniert nicht? Worin drückt sich das aus?
- Wir erhielten weniger Einkommen.
- Und?
- Im System funktioniert etwas nicht.
- Ich verstehe es nicht. Wenn Sie weniger Geld verdienen, sprechen Sie mit Ihrem Verkaufsteam. Warum rufst du mich an?
- Nein, ich bin sicher, dass etwas im System nicht funktioniert!
- Okay, mal sehen.
Gott sei Dank hatten wir eine Umsatzmetrik, damit wir sehen konnten. Die Grafik zeigt wirklich, dass ihr Einkommen irgendwann um 15% gesunken ist. Angesichts der Anzahl der Benutzer ist dies ziemlich wichtig.
Okay, ich muss schauen. Zunächst überprüfe ich die Download-Geschwindigkeit - normal.
Wir haben uns die Auslastung der Datenbank angesehen - alles ist in vernünftigen Grenzen, anscheinend hat sich nichts geändert. Dann begannen wir, die CPU-Last, einzelne Knoten und Caches zu untersuchen.
Alles war in Ordnung. Bis wir zu den Metriken des E-Mail-Newsletters kamen. Einer der großen Anbieter hat versehentlich seine Domain auf die schwarze Liste gesetzt. Der Prozentsatz ihres E-Mail-Marketings erreicht die Benutzer nicht mehr, was bedeutet, dass weniger Personen Briefe erhalten, auf die Schaltfläche geklickt, auf die Website gegangen sind und etwas gekauft haben.
Hier ist eine solche Korrelation!
Wir haben das Glück, dass wir diese Metriken hatten. Wenn wir sie nicht hätten, würden wir sie hinzufügen - dies ist eine sehr einfache Antwort.
Der größte Fehler, den die Leute machen, ist zu glauben, dass die Überwachung am Ende des Projekts erfolgen kann. Es ist wie eine Funktion: Um ein eigenes Projekt zu erstellen, eine Überwachung einzurichten - und das ist alles, wir sind bereit!
Die Instrumentierung kann niemals beendet werden. Es gibt immer Probleme, die von Anfang an unbekannt sind. Wie beim Testen können Sie keine Tests schreiben und alles abdecken, da Sie nicht wissen, was „alles“ ist. Wir wissen nicht, wie wir die Zukunft vorhersagen sollen, und wir wissen nicht, wie wir ein Unternehmen vorhersagen sollen. Daher wissen wir nicht, was „alles“ ist.
Ein absolut identisches Beispiel für das, worüber ich spreche. Es war der CEO, der morgens auf einer Konferenz in Paris aufwachte, Kaffee trank, seine Post und seine Gewinn- und Verlustrechnung betrachtete und mich mit demselben Problem anrief: Das Einkommen sank.
Ich erinnere mich gut daran, weil er 9 Uhr morgens hatte und ich 6 Stunden früher, auch am Samstag. Ich bin gerade von einer Geburtstagsfeier nach Hause gebracht worden - aber das spielt keine Rolle. Um 3 Uhr morgens setze ich mich an den Computer und wir beginnen die gleichen Schritte zu machen. Das heißt, wir betrachten die Belastung des Systems, überhaupt die Registrierungsnummer.
Die einzige Abweichung von der Norm, die wir gefunden haben, ist ein geringerer Prozentsatz erfolgreicher Autorisierungen. Das heißt, der Betrag ist der gleiche, aber der Prozentsatz ist etwas niedriger. Ich weiß, dass dies Spam usw. sein kann. Alle anderen technischen Kennzahlen sind jedoch absolut normal. Und wir kamen an den Punkt, an dem wir fast entlang der Linien in der Datenbank gingen und versuchten zu überprüfen, ob etwas mit dem Auge aufgefangen werden konnte. Absolut nichts!
Wir saßen am halben Sonntag, machten auch am Montag weiter, waren uns aber schon sicher, dass das Problem nicht technisch war. Lassen Sie sie es selbst entscheiden. Und hier sitze ich am Montag bei der Arbeit und ein Mitarbeiter der Buchhaltung ruft mich an:
- Hör zu, kannst du mir schnell helfen?
- Was brauchst du?
- Können Sie das American Express-Abzeichen von der Website entfernen?
- Natürlich kann ich! Warum plötzlich?
- Weißt du, wir streiten uns hier mit ihnen und bis wir Amerikaner akzeptieren
Express im Allgemeinen.
"Ich entschuldige mich zu fragen, wann hast du aufgehört, sie zu nehmen?"
- Meiner Meinung nach vor dem Wochenende - am Freitag oder Samstag .
Niemand, der bei klarem Verstand ist, würde jemals eine Metriksammlung über den Prozentsatz der Autorisierungen einer bestimmten Art von Kreditkarte erstellen! Nach diesem Vorfall haben wir uns natürlich gesetzt.
Warum erzähle ich dir das? Sie müssen sich zuerst das Geschäft ansehen, da all diese systemischen Probleme einfach unsichtbar waren. Sie haben mitten in der Nacht niemanden geweckt, wir haben nicht gesehen, dass dies Probleme waren. Es ist leicht, einen Einkommensrückgang zu bemerken, und alles andere muss nachverfolgt werden, damit Sie diese Daten mit Geschäftsdaten korrelieren können.
Erfolg fürs Geschäft
Für ein Unternehmen kann der Erfolg unterschiedlich sein, er hängt von den Zielen ab. Wie kann dies vor allem gemessen werden? Traditionell messen wir die Systemleistung, manchmal als Ingenieure, und vergessen, dass Sie alles messen können.
Zum Beispiel können Sie Ihren eigenen Alkoholismus messen. Ich scherze übrigens nicht. In unserem Büro gibt es ein gezapftes Bier mit vier Zapfstellen. Da wir alle Ingenieure sind, hat mein Kollege beschlossen, Raspberry Pi-Sensoren einzusetzen, um zu sehen, wie viel Bier wir trinken und welches.
Es sieht aus wie ein einfacher Witz, ist aber praktisch, denn wir sehen, wann das Bier zu Ende geht und wir das Fass ersetzen müssen. Im Allgemeinen können wir sehen, wann Menschen trinken, welches Bier sie am liebsten mögen - dunkel, hell usw. Der Höhepunkt ist übrigens mein Geburtstag.
Absolut zufällig haben wir dafür eine andere Anwendung gefunden.
Die Grafik zeigt den Bierkonsum über mehrere Tage und Wochenenden. Am Wochenende nimmt der Alkoholkonsum normalerweise ab und verschwindet fast. Eines Tages kommen wir am Montag an, schauen uns den Zeitplan an und sehen, dass jemand am Samstag ein Viertel Barrel Bier getrunken hat. Die Grafik zeigt die genaue Zeit innerhalb einer halben Stunde. Es stellte sich heraus, dass die Reinigungskräfte, die am Samstag kamen, einen Kater hatten, also waren sie verkatert.
Ein Witz, aber am Ende hatten sie ernsthafte Probleme, weil es im Allgemeinen schlecht ist, bei der Arbeit zu trinken und sogar das Bier eines anderen!
Am Ende können alle Metriken nützlich sein. Sogar diese Metrik, die wir nur für unseren eigenen Fan gesammelt haben, hat sich in etwas anderem als wichtig erwiesen. Aber im Grunde geht es bei den wirklich benötigten Metriken um Geld. Geld ist für das Geschäft am wichtigsten.
In der Regel sind die Kriterien für den Erfolg eines Unternehmens letztendlich mit Geld verbunden:
- Gewinn;
- Einkommen
- Kosten
- Wirksamkeit.
Geschäftsmetriken:
- Registrierung
- Einkäufe;
- Anzeigenansichten
- Umbauten;
- Renditeprozentsatz;
- Menge Bier getrunken
All dies hat ein monetäres Äquivalent. , , — , . , .
. . , , .
, — . , — , — , . , — 99- , SLA .
, , -.
, . , , , . , .
. , . . . , 3 , .
— . , , , , .
.
: , , , - .
, . , , , 50 % « », , .
1 ?
1-2 . . 10 000 , . , 10 000 , - .
1 . 600-700 . , 600 — , . , , . 800 , , — .
, , . 0 , - , ! .
, - . — , .
99- 50- , . , .
, — , DevOps — .
, , .
Value stream mapping — . , . , , , , , . , , .
:
- MTTD (mean time to discovery) — , .
- MTTR (mean time to recovery) — , .
- , .
- / .
, , , , . : « — . , , ».
, , . , .
. , — , , . , . .
— , , . , , , . — .
Am 1. und 2. Oktober findet in Moskau eine Fachkonferenz zur Integration der Entwicklungs-, Test- und Betriebsprozesse von DevOpsConf Russia statt .
Wenn Sie gerade erst anfangen, an den Prinzipien von DevOps zu arbeiten, ist dies eine großartige Gelegenheit, sich von Anfang an bis zu einer erfolgreichen Implementierung echte Arbeitsbeispiele anzusehen und sich von Ideen wie Leons Bericht inspirieren zu lassen. Für fortgeschrittene Fachleute gibt es Berichte mit einem tiefen Eintauchen in das Thema und wichtige Details sowie Diskussionen über neue Produkte.
Kommen Sie und sehen Sie, wie untrennbar Entwicklung, Test und Betrieb sein können .