Tänze mit Unterstützung: Arten und Formen der Unterstützung. Unterstützungssysteme, die im Kampf arbeiten

Hallo allerseits! Mein Name ist Alexander Afenov und ich bin der Teamleiter des Auftragsabwicklungsteams bei Lamoda. Heute möchte ich Ihnen erzählen, wie wir Unterstützung harken.

Lassen Sie uns zunächst darüber sprechen, wie es in unsere Prozesse eingebettet ist und wie wir im Allgemeinen unsere Arbeit, Sprints und Iterationen planen.

Dann werde ich Ihnen sagen, woher der Support kommen kann und in welche Typen er unterteilt ist.
Ich werde die Erfahrung teilen, wie wir im Team mit jeder Art von Unterstützung umgehen.

Am Ende betrachten wir die Vor- und Nachteile der von uns verwendeten Praktiken und fassen sie zusammen.


Mein Team hat jetzt zwei Systeme. Das erste ist eine große und beängstigende Sache namens Auftragsabwicklung . Dies ist ein System, das den Lebenszyklus eines Auftrags vom Erstellungsprozess bis zur Lieferung (oder Rückgabe) automatisiert.

Der Dienst läuft auf PHP 7, ist in Docker verpackt und wird von Kubernetes orchestriert. Gleichzeitig wird er jedoch auf dem Zend1-Framework und auf Teilen von Symfony 2 implementiert. Diejenigen, die jetzt auf PHP programmieren, haben möglicherweise einen Schauer bekommen. Im Übrigen werde ich erklären, dass Zend1 ein Framework ist, das vor anderthalb Jahren ein Lebensende hatte. Es wird nicht mehr unterstützt und verfügt nicht einmal über Sicherheitspatches.

Das Projekt ist groß (mehr als 150.000 Codezeilen) und macht vieles nicht. Beispielsweise werden nicht nur Bestellungen verarbeitet, sondern aus irgendeinem Grund E-Mails gesendet, SMS gesendet, Pushs gesendet und Daten an andere Systeme übertragen. Deshalb schneiden wir es in separate Mikrodienste.

Das erste, was wir aus dem Monolithen herausgebracht haben, ist das sogenannte Rückerstattungswerkzeug . Er ist der zweite Service meines Teams und für die automatische Rückgabe des Geldes an den Kunden verantwortlich (mehr im Bericht meines Kollegen) .

Trotz der Tatsache, dass das Refund-Tool über einen modernen technologischen Stack verfügt, generiert es aufgrund des Erbes der Auftragsabwicklung immer noch eine Menge Unterstützung.

Dies geschieht aufgrund der Tatsache, dass wir einen bestimmten Geschäftsprozess, der früher auf vielen Excel-Dateien aufgebaut war, auf ein neues System übertragen haben, das über Kafka funktioniert und auch mit einigen Systemen interagiert. Natürlich haben wir bei der Einführung eines neuen Systems und der Änderung des Geschäftsprozesses Unterstützung erhalten. In langjähriger Arbeit haben wir einige Erfahrungen gesammelt.

Ich glaube, dass die Menschen in zwei Kategorien unterteilt sind: diejenigen mit einem Produktionssystem, das Unterstützung generiert, und verdammte Lügner. Daher werde ich Erfahrungen austauschen, die bei der Optimierung Ihrer Prozesse hilfreich sein können. Wenn die vorgeschlagenen Lösungen (in Kombination oder separat) zu Ihnen passen, bleibt mehr Zeit für die Entwicklung der Funktionalität Ihres Systems, die Analyse des technischen Rückstands und nicht für die Arbeit mit dem Support.

Um über die verwendeten Tools zu sprechen, ist ein Kontext erforderlich. Zunächst werden wir uns mit den grundlegendsten Themen befassen.

Prozesse und Rollen

Wie arbeiten wir mit Unterstützung und welchen Platz nimmt es in unseren Sprints ein?

Proportionale Eimer nenne ich unsere Eimer .

Wir nehmen 10% aus dem technischen Rückstand, damit er nicht stagniert und sich nicht auf unbestimmte Zeit ansammelt.

Ungefähr 20% des Sprints werden für einige Risiken verwendet. Zum Beispiel hat jemand eine Aufgabe erledigt, aber diese Person wurde "von einem Bus angefahren". Der nächste muss den Kontext erneut untersuchen. Infolgedessen werden wir nicht in die Bewertung einsteigen, und alles wird schlecht sein.

Als nächstes legen wir die geplante Unterstützung. Das heißt, wir wissen bereits, dass etwas nicht stimmt. Dies ist etwas, das nicht viel brennt, und wir werden es reparieren.

Das Interessanteste ist jedoch eine ungeplante Unterstützung. Das heißt, wir gehen davon aus, dass während der Iterationsphase etwas kaputt gehen kann, und wir werden Zeit für Reparaturen aufwenden.

Die restlichen 30% sind Projekte.

Sie haben wahrscheinlich bemerkt, dass es mehr als 100% ausfällt. Dies liegt daran, dass wir immer versuchen, mehr zu tun, als wir wirklich können. Manchmal gelingt es uns, manchmal nicht sehr.

Hauptunterstützungsparameter

Wir geben jedem Support-Ticket eine Bewertung anhand der folgenden Parameter:

1. Kritikalität für das Geschäft. Wie wichtig ist ihnen das und wie sehr bricht dies den Geschäftsprozess?
2. SLA Wie lange sollten wir brauchen, um das Problem zu lösen?
3. Priorität

Wenn bei den Benutzern unserer Systeme ein Fehler aufgetreten ist, melden sie dies dem Support-Service und stellen klar, dass ein Vorfall den Geschäftsprozess teilweise oder vollständig blockiert. Der Support bringt sofort ein neues Ticket zum zuständigen System und legt Wert darauf .

Kritikalität und Priorität sind unterschiedliche Begriffe.

Prioritätsarten

Blocker - etwas hat absolut alles kaputt gemacht, das Geschäft gestoppt. Bestellungen werden nicht erstellt, sie werden nicht geliefert, Zahlungen werden nicht akzeptiert und so weiter.

Major ist etwas weniger Wichtiges und kann für eine längere Zeit repariert werden, da es Problemumgehungen und alternative Pfade gibt.

Trivial Zum Beispiel schreibt jemand, dass unsere Knöpfe eine unangenehme Farbe haben und neu gestrichen werden sollten. Es besteht eine hohe Wahrscheinlichkeit, dass ein solches Ticket niemals ausgestellt wird.

Es gibt auch eine Service-Level-Vereinbarung , die vom Support-Service zusammen mit dem Team und dem Geschäftsinhaber des Systems festgelegt wird. Sie untersuchen, welche Branche im Rahmen einer bestimmten Beschwerde zusammengebrochen ist. Wenn zum Beispiel keine Bestellungen mehr erstellt wurden (das Hauptbrot des Online-Shops), hat dieses Problem eine hohe Priorität, die wir P1 nennen. P hat Priorität, Einheit ist das Wichtigste.

P1 ist eine Art von SLA, was bedeutet, dass wir das Problem innerhalb einer halben Stunde lösen und es in höchstens ein paar Stunden lösen müssen.

P2 ist etwas weniger Wichtiges, das wir in ein paar Stunden in Anspruch nehmen und tagsüber entscheiden müssen.

P3-P4 ist defekt und erfordert keine dringenden Reparaturen. Sie können es eines Tages tun und zur nächsten Iteration übergehen.

Und hier kommen wir zu der vom Team gesetzten Priorität. Dies kann ein technischer Experte, ein leitender Support-Ingenieur sein - jeder, der sich mit dem Problem befasst.

Angenommen, wir haben derzeit 4 Aufgaben mit Hauptgeschäftspriorität. Die Person aus dem Team legt aufgrund ihres Fachwissens einen bestimmten numerischen Wert fest, den wir als detaillierte Priorität bezeichnen . Darauf aufbauend wird das Support Board in Zukunft sortiert. Das heißt, oben gibt es die Aufgaben mit der höchsten Priorität für das Unternehmen, die immer noch nach dem Verständnis des Teams sortiert sind, wie wichtig dies wirklich ist und wie schnell Sie es erledigen können.

Unter den Hauptparametern scheint einer der wichtigsten zu fehlen - eine normale Beschreibung . Sehr oft haben wir Support-Aufgaben vom Sentry-System aus gestartet, bei denen Fehler, Ausnahmen usw. auftreten. Eine Person sieht, dass es ein kleines Problem gibt, und erstellt in Jira ein Puzzle. Da unsere Systeme miteinander integriert sind, wird im Task-Tracker eine Aufgabe angezeigt, in deren Beschreibung nur ein Link zu Sentry vorhanden ist, und im Titel befindet sich ein Fehlertext. Das ist alles.

Wie soll jemand, der diese Aufgabe bekommt, damit arbeiten? Nicht sehr klar. Wenn Sie dieser Aufgabe eine gute Beschreibung hinzufügen, hilft dies erheblich und spart Zeit.

Wer wird alles harken?

Und wenn all dies erledigt ist, stellt sich die Frage: Wer wird diesen schön sortierten Rückstand harken? Die Antwort lautet: Support Engineer.

In meinem Vortrag „Technische Hypothek: Was und wer sollte Teamleiter?“ Mit TeamLeadConf 2018 können Sie genauer hören, wer der Support-Ingenieur ist und was er tut.

Ein Support-Ingenieur ist ein Mann, der die Aufgaben mit der höchsten Priorität aus einem Support-Backlog übernimmt und behebt. Da alles schön sortiert ist, glauben wir, dass oben das Wichtigste, Dringendste und „Backende“ ist. Wenn es keine Aufgaben gibt, kann er einen technischen Rückstand machen.

Was macht er sonst noch?

1. Versucht, die Grundursache , dh die Grundursache der Unterstützung, zu isolieren und zu beseitigen . Wenn Sie regelmäßig Tickets des gleichen Typs erhalten, sollten Sie überlegen, warum dies geschieht. Höchstwahrscheinlich gibt es irgendwo ein Problem, das behoben werden kann, wodurch der Fluss ähnlicher Aufgaben gestoppt wird.

2. Es legt die Aufgaben für die Korrektur und Überwachung fest .
Wenn der Support-Techniker das Problem nicht in ein oder zwei Tagen lösen kann, richtet er eine separate Aufgabe dafür ein, die in den Entwicklungsstau eingeht. Dann wird es vom Team ausgewertet und als geplante Unterstützung in die Iteration aufgenommen.

Die Überwachung spielt für uns eine wichtige Rolle. Wir hängen die Überwachung nicht nur an Metriken auf, die wir für die fortlaufende Überwachung gewohnt sind, sondern fügen sie auch hinzu, um die am längsten laufenden Probleme zu lokalisieren. Meiner Meinung nach wäre es besser, wenn wir unnötige Überwachung hätten, die wir dann tranken, als das Problem würde sich ständig in Form von immer mehr Tickets wiederholen.

3. Suche nach Gründen für die Automatisierung .
Beispiel : Wir übertragen Daten an unser System, wodurch die Arbeit des Lieferservices automatisiert wird. Manchmal stellt sich heraus, dass wir selbst bei Verwendung des Dead Letter-Kanals und der Weiterleitung dort keine Informationen liefern können. Infolgedessen hängen solche Befehle irgendwo und müssen erneut gesendet werden.

Dies ist eine typische Unterstützung, die mehrmals pro Woche erfolgt. Um dieses Problem zu lösen, haben wir beschlossen, eine separate Seite mit der Schaltfläche "Auftragsliste erneut senden" zu erstellen. Wir haben diese Unterstützung nicht mehr. Das heißt, sie dachten, automatisiert, gab es dem Support-Service.

Die Rolle eines Supportingenieurs wird jede Woche auf eine andere Person übertragen - dies ist Voraussetzung. Eine längere Arbeit ist Stress, Demotivation und Verfall, da Sie ständig etwas reparieren und nichts Neues in das System bringen.

Regelmäßigkeit als Quelle der Gnade

Es scheint offensichtlich, aber es wird trotzdem oft vergessen. Damit alles funktioniert, müssen unsere Prozesse in Betrieb genommen und regelmäßig beobachtet werden.

Überprüfung des Rückstands

Woher bekommen wir einen schön sortierten Support-Rückstand, wenn dort niemand hinschaut?

Auf eine gute Weise müssen Sie einmal im Monat darauf stoßen und Aufgaben mit einem trivialen Status schließen (den Sie höchstwahrscheinlich nie erreichen werden). Seien Sie ehrlich zu sich selbst und dem Kunden. Wenn der Rückstand aufgrund solcher Aufgaben unendlich wächst, müssen Sie später in Panik geraten, um zu versuchen, sie zu schließen. Das ist nicht sehr gut.

Detaillierte Prioritätsbefestigung

Dies ist genau der Prozess, in dem wir bewerten, wie kritisch eine Aufgabe ist. Es wird dann die richtige Sortierung sein und der Support-Techniker wird die richtige Aufgabe von oben übernehmen.

Kampf um Priorität

Zum Beispiel stellen sie eine Aufgabe für Sie ein und sagen: „Leute, der monatliche Bericht wird nicht hochgeladen. Wir müssen es in einer Woche haben, aber es funktioniert nicht. Bitte beheben Sie es. Priorität P1. Sie müssen sich innerhalb von 2-3 Stunden entscheiden. “

Und Sie fragen: „Ernsthaft? Worüber redet ihr? Immerhin gibt es eine Woche, um das Problem zu beheben. Lassen Sie uns auf P2 herabstufen, und wir haben ein paar Tage Zeit. “

Manchmal denken die Leute, dass wir die Aufgabe nicht übernehmen werden, deshalb legen sie besonderen Wert auf eine hohe Priorität. Aber es passiert und umgekehrt. Zum Beispiel schreiben sie uns, dass Bestellungen nicht erstellt werden und setzen P2 Priorität. Dieses Problem ist viel schwerwiegender, daher lohnt es sich, die Priorität auf P1 zu erhöhen. Es ist nützlich, wissentlich in beide Richtungen zu verhandeln.

Etablierung neuer Aufgaben

Ich habe bereits das Sentry-System erwähnt, das Aufgaben enthält, die bereits von Kunden ausgeführt werden. Wir selbst antizipieren jedoch die auftretenden Probleme und werfen selbst Aufgaben in diesen Rückstand.

SLA-Leistungsüberwachung

Zu diesem Zweck haben wir Zeitpläne, die zeigen, dass wir Aufgaben haben, deren Zeit bald abläuft. Es scheint, dass diese Rätsel in erster Linie Sinn machen.

Support Engineer Support

Ein Support-Ingenieur zu sein ist ein ziemlich deprimierender Prozess, daher sollte eine Person helfen. Wie können wir ihm das Leben leichter machen?

Übertragen der Rolle auf den nächsten im Team

Wir müssen einen Zeitplan einhalten, wer dies nächste Woche tun wird. Es treten jedoch Grenzmomente auf. Zum Beispiel nahm eine Person am Freitag eine Aufgabe an und hatte keine Zeit, sie zu erledigen. Er kann nächste Woche Zeit verbringen, aber es ist besser, die Aufgabe einem neuen Support-Ingenieur zu übergeben. Wenn Sie das Backlog-Raking zwei Wochen lang in die Länge ziehen, ist die Person höchstwahrscheinlich ziemlich demotiviert. Sie werden dies beim nächsten persönlichen Treffen sehen :)

Helfen Sie dabei, die Ursache des Problems zu finden

Die Leute harken gerne nur Aufgaben, konzentrieren sich aber nicht darauf, die eigentliche Ursache zu finden. Es lohnt sich, die Frage zu stellen: „Wenn Sie die Aufgabe geschlossen haben, warum ist das Problem dann ursprünglich aufgetreten?“. Diese Vorgehensweise wird dazu beitragen, die Ursache zu finden, sie zu beseitigen und möglicherweise in Zukunft den Fluss solcher Unterstützung zu beseitigen.

Das Bedürfnis nach einem "frischen Look"

Wenn eine Person für einen bestimmten Zeitraum kein sichtbares Ergebnis erzielen konnte, sollte diese Aufgabe auf eine andere übertragen werden. Jemand anderes kann das Problem von der anderen Seite betrachten, was zur Lösung des Problems auf andere Weise führen kann.

Ein solcher Ansatz kann jedoch einige interessante psychologische Aspekte verbergen. Das heißt, wenn Sie eine Aufgabe von einer Person übernehmen und einer anderen geben, riskieren Sie zu sagen, dass sie es besser weiß, damit sie damit fertig wird. Solche Dinge lassen sich am besten anders darstellen. Konzentrieren Sie sich auf die Tatsache, dass wir alle Probleme mit dem System lösen müssen und uns nicht gegenseitig beweisen müssen, wer von uns cooler ist.

Entwicklung von Werkzeugen zur Automatisierung

Diejenigen, die häufig Support-Ingenieure sind, verstehen, dass sie bereits „backen“, wenn sie dieselben typischen Aufgaben ausführen. Vor kurzem hat einer unserer Entwickler sein eigenes Mini-Framework für Go. Er geht zu verschiedenen Datenbanken, sammelt Daten, pusht etwas in Kafka. So konnte er diese Aufgabe so weit wie möglich automatisieren und anderen das Leben erleichtern.

Support-Quellen

Es gibt so viele Unterstützungen, dass wir manchmal nicht darüber nachdenken, woher sie so oft kommen.

Stabilisierung neuer Systeme und Prozesse

Wenn Sie etwas Neues mitgebracht haben, wird es höchstwahrscheinlich falsch verwendet. Sie werden auf neue Probleme stoßen und Ihr Support-Backlog wird sofort mit Tickets oder Tickets aufgefüllt.

Unterstützung für ältere Systeme

Zum Beispiel unser Monolith. Er kann nicht still stehen, wie wir immer hinzufügen, etwas in ihm umschreiben. Dies führt natürlich zur Schaffung einer neuen Unterstützung.

Technischer Fehler

Zum Beispiel wurde das Netzwerk getrennt. Sie scheinen nicht schuld zu sein, aber sie werden sicherlich zu Ihnen kommen und fragen, warum keine Aufträge erstellt wurden. Es wird notwendig sein, etwas zu reparieren, zu reparieren, zu modifizieren. Manuelle Eingriffe sind erforderlich, und daher werden neue Tickets im Backlog bereitgestellt.

Menschlicher Faktor

Wir hatten einen Fall, in dem jemand in RabbitMQ eine Nachricht erstellen konnte, dass unser Verbraucher aufgelegt hat und alles nicht mehr funktioniert. Das ist in den letzten 7 Jahren noch nie passiert, aber hier ist es irgendwie gelungen :)

Der menschliche Faktor, der zum Scheitern führte

Jemand mit den Worten "Ich werde es jetzt reparieren" zog die Festplatte von dem Server heraus, auf dem die Abrechnung lief. Als Ergebnis haben wir bekommen, was wir haben. Dies ist nicht die Lmoda-Erfahrung, sondern ein realer Fall aus meiner Praxis.

Support-Typen

Analytics-Anfrage

Wenn sie regelmäßig nach dem Status von etwas in der Datenbank fragen, fragen sie nach dem Hochladen, dem Sammeln eines Berichts für einen bestimmten Zeitraum usw. Dies ist etwas ärgerlich. Sie haben also einen guten Grund, über Automatisierung nachzudenken und einfach eine Benutzeroberfläche bereitzustellen oder die Struktur des Unternehmens zu studieren.

Zum Beispiel habe ich nicht sofort herausgefunden, dass die meisten unserer Bestelldaten in der Oracle-Datenbank der D & A-Abteilung gespeichert sind und alles von dort abgerufen werden kann. Eine solche Unterstützung wird entweder über Schnittstellen automatisiert oder an die Analyseabteilung übertragen.


Datenänderungsanforderungen

Situationen sind anders und unvorhersehbar. Nehmen wir an, unser Kunde würde seine Bestellung mit einer Karte bezahlen. Als der Kurier ankam, überlegte er es sich anders und beschloss, dies in bar zu tun. Oder irgendwo gab es beispielsweise ein automatisiertes Problem, das von Hand geändert werden muss. Wir müssen diese Daten korrigieren.

Zu diesem Zweck versuchen wir, neue API-Handles zu erstellen, Schnittstellen zu erstellen und diese Aufgaben maximal aus der Entwicklung und aus unserem Operations-Team zu entfernen. Dies ist eine gefährliche Praxis, die wir durch die Verbesserungen der Benutzeroberfläche und der API beseitigen.

Reparatur von Geschäftsprozessen

Wenn direkt etwas in der Datenbank bearbeitet werden muss, liegt ein fehlerhafter Geschäftsprozess vor. Dies kann entweder aus IT-Gründen geschehen oder es kann ein Fehler im Geschäft auftreten. Sowohl dort als auch dort sind Anpassungen erforderlich. In diesem Fall müssen Sie zum Geschäftskunden gehen und besprechen, ob dies anders möglich ist, oder die Entwicklung anfordern, um den Geschäftsprozess zu reparieren.


Feature X funktioniert nicht mehr

Dies ist meine Lieblingsunterstützung, weil sie am verständlichsten ist. Das heißt, wir hatten etwas im Produkt, aber es ist kaputt gegangen und muss repariert werden. Finden Sie heraus, in welcher Veröffentlichung und aus welchem ​​Grund gestorben ist. Reparieren und schließen Sie das Ticket. Alles ist einfach.

Es gibt jedoch noch eine andere Unterstützung - Funktion X funktioniert nicht . Es mag wie das gleiche aussehen, aber mit anderen Worten gesagt. Dies ist jedoch nicht so.

In dieser Situation kommen sie zu Ihnen und sagen, dass dieses Ding nicht funktioniert. Du verbringst ein oder zwei Tage damit, es zu klären. Erst später wurde Ihnen klar, dass dies hier nie funktioniert hat . Es war einfach nicht in Ihrem System.

Auf andere Weise nenne ich diese Art von Support „Fuchs“, wenn jemand, der schlau ist, eine Feature-Anfrage unter dem Deckmantel einer Support-Aufgabe ablegen möchte. Dies ist eine regelmäßige Geschichte, die sehr schmerzhaft ist. Wenn Sie solche Momente nicht anhalten, stellt sich heraus, dass Ihr Support-Techniker oder Sie selbst neue Funktionen einführen und die tatsächlichen Probleme aus dem Support-Backlog ungelöst bleiben.

Großer Vorfall

Dies ist nur die Geschichte des Sarges und des Torffeuers, als etwas in IT-Systemen so schlimm kaputt ging, dass ein bestimmter Geschäftsprozess entstand.

Fallstudie aus unserer Praxis: Aufgrund eines Fehlers im Code und unvollständiger automatischer Tests haben wir begonnen, eine bestimmte Notiz über den Status der Bestellung an den externen Kurierdienst zu senden, aufgrund derer die Leute ihre Bestellung am Abholpunkt nicht abholen konnten. Es hat Tausende von Kunden betroffen. Wir mussten alle Bestellungen zurücknehmen und Geld dafür ausgeben. Wir konnten sie nicht verkaufen und die Kundenbindung ging verloren. Dies ist ein großer Vorfall, der das Geschäft verletzt hat.

Es lohnt sich, auf besondere Weise mit solchen Dingen zu arbeiten, und ich werde Ihnen sagen, wie wir das machen.

Wie kann man herausfinden, dass etwas passiert?

Die in der Branche am häufigsten verwendete Option besteht darin, von Benutzern zu lernen. Er ist natürlich der Schlimmste, weil es bedeutet, dass sie bereits „backen“. , , .

, , .

— . , . , - , , , Rabbit.

, , , . , . , , Rabbit MQ. , 16 , , .



, . , shovel-plugin, . , major .

- , , - . , , , -. , .

, 5 . , , . . , - brainstorm. , .

, , .

Lamoda , . , - , CTO. , , .

— . , , .



, 13.05 -. 13.13 , . 14.50 . - 1,5 , , . , 1,5 .

?

, , . , - . , , , .

, 16.55, , 40 . , , .

Warum passiert das?

, . , . , . , - CI/CD , . , , , , , , .

— . — . , , , – . , , , IT , .

preventive actions . , - , , , . . preventive actions. , , .

/fix versions .

. — , — .

, , Major Incident. , , , , , . , , Major Incident.

. , , , . , .

, , , , -. .

?

— . , .

Lamoda , IT. , , - - , , IT-. , 80% , , , . .

, . , , , - , IT .

Sweet spot

, , , , . , . , , , , . , .