Danses avec support: types et formes de support. Systèmes de soutien fonctionnant au combat

Bonjour à tous! Je m'appelle Alexander Afenov et je suis le chef d'équipe de l'équipe de traitement des commandes de Lamoda. Aujourd'hui, je veux vous expliquer comment nous soutenons le soutien.

Tout d'abord, parlons de la façon dont il est intégré dans nos processus et comment, en général, nous planifions notre travail, nos sprints et nos itérations.

Ensuite, je vais vous dire d'où peut provenir le support et dans quels types il est divisé.
Je partagerai l'expérience de la façon dont nous, au sein de l'équipe, traitons chaque type de support.

En fin de compte, nous considérons les avantages et les inconvénients des pratiques que nous utilisons et résumons.


Mon équipe a maintenant deux systèmes. Le premier est une chose grande et effrayante appelée Traitement des commandes . Il s'agit d'un système qui automatise le cycle de vie d'une commande, du processus de création à la livraison (ou au retour).

Le service tourne sur PHP 7, enveloppé dans Docker et orchestré par Kubernetes, mais en même temps il est implémenté sur le framework Zend1 et des morceaux de Symfony 2. Ceux qui programment maintenant sur PHP ont peut-être frissonné. Pour le reste, je vais vous expliquer que Zend1 est un framework qui avait une fin de vie il y a un an et demi. Il n'est plus pris en charge et n'a même pas de correctifs de sécurité.

Le projet est volumineux (plus de 150 000 lignes de code), et il ne fait pas beaucoup son travail. Par exemple, non seulement traite les commandes, mais pour une raison quelconque, envoie du courrier, des SMS, des push, transfère des données vers d'autres systèmes. Par conséquent, nous le découpons en microservices distincts.

La première chose que nous avons sortie du monolithe est ce qu'on appelle l' outil de remboursement . Il est le deuxième service géré par mon équipe et est responsable du retour automatique d'argent au client (plus dans le rapport de mon collègue) .

Malgré le fait que l'outil de remboursement dispose d'une pile technologique moderne, il génère toujours un tas de support en raison de l'héritage du traitement des commandes.

Cela se produit du fait que nous avons pris un certain processus métier, qui était basé sur de nombreux fichiers Excel, et l'avons transféré vers un nouveau système qui fonctionne via Kafka, et qui interagit également avec quelques systèmes. Bien sûr, lors de l'introduction d'un nouveau système et de la modification du processus métier, nous avons obtenu un soutien. Et au cours de nombreuses années de travail avec cela, nous avons acquis une certaine expérience.

Je crois que les gens sont divisés en deux catégories: ceux qui ont un système de production qui génère du soutien et les foutus menteurs. Par conséquent, je partagerai des expériences qui peuvent être utiles pour optimiser vos processus. Si les solutions proposées (en combinaison ou séparément) vous conviennent, alors plus de temps apparaîtra pour le développement des fonctionnalités de votre système, l'analyse du backlog technique, et non pour travailler avec le support.

Parler des outils utilisés nécessitera du contexte, nous allons donc d'abord parler des plus élémentaires.

Processus et rôles

Comment travaillons-nous avec le support et quelle place prend-il dans nos sprints?

Les godets proportionnels sont ce que j'appelle nos godets .

Nous prenons 10% du backlog technique pour qu'il ne stagne pas et ne s'accumule pas indéfiniment.

Environ 20% du sprint est pris pour prévoir certains risques. Par exemple, quelqu'un faisait une tâche, mais cette personne a été «heurtée par un bus». Le prochain devra réexaminer le contexte. En conséquence, nous n'entrerons pas dans l'évaluation, et tout sera mauvais.

Ensuite, nous posons le support prévu. Autrement dit, nous savons déjà que quelque chose ne va pas. C'est quelque chose qui ne brûle pas beaucoup et nous allons le réparer.

Mais la chose la plus intéressante est un support non planifié. Autrement dit, nous supposons que quelque chose peut se casser pendant la période d'itération et nous consacrerons du temps aux réparations.

Les 30% restants sont des projets.

Vous avez probablement remarqué que cela se révèle à plus de 100%. Cela est dû au fait que nous essayons toujours de faire plus que nous ne pouvons vraiment. Parfois nous réussissons, parfois pas très.

Paramètres de support principaux

Nous évaluons chaque ticket de support selon les paramètres suivants:

1. Criticité pour les entreprises. À quel point cela est-il important pour eux et dans quelle mesure cela rompt-il le processus opérationnel?
2. SLA Combien de temps devrions-nous prendre le problème pour travailler et le résoudre?
3. Priorité

En cas de problème avec les utilisateurs de nos systèmes, ils le signalent au service d'assistance et précisent qu'un incident bloque partiellement ou totalement le processus métier. Le support apporte immédiatement un nouveau ticket au système responsable et le place en priorité .

Criticité et priorité sont des termes différents.

Types de priorité

Blocker - quelque chose a tout cassé, a arrêté l'entreprise. Les commandes ne sont pas créées, elles ne sont pas livrées, les paiements ne sont pas acceptés, etc.

Major est quelque chose de moins important et peut être réparé plus longtemps, car il existe des solutions de contournement, des chemins alternatifs.

Trivial Par exemple, quelqu'un écrit que nos boutons sont d'une couleur désagréable et doivent être repeints. Il y a une forte probabilité qu'un tel ticket ne soit jamais réalisé.

Il existe également un accord de niveau de service , qui est établi par le service d'assistance en collaboration avec l'équipe et le propriétaire de l'entreprise du système. Ils examinent le secteur d'activité en panne dans le cadre d'une plainte spécifique. Si, par exemple, les commandes ont cessé d'être créées (le principal pain de la boutique en ligne), ce problème aura une priorité élevée, que nous appelons P1. P est prioritaire, l'unité est la plus importante.

P1 est un type de SLA, ce qui signifie que nous devons prendre le problème pour travailler dans une demi-heure et le résoudre en quelques heures au plus.

La P2 est quelque chose de moins important que nous devons prendre en quelques heures et décider pendant la journée.

P3-P4 est quelque chose qui est tombé en panne et ne nécessite pas de réparations urgentes. Vous pouvez un jour le faire, le porter à la prochaine itération.

Et ici, nous arrivons à la priorité fixée par l'équipe. Il peut s'agir d'un expert technique, d'un ingénieur de support senior - de toute personne qui s'occupe du problème.

Supposons que nous ayons actuellement 4 tâches avec une priorité commerciale majeure. La personne de l'équipe, en raison de son expertise, met une certaine valeur numérique, que nous appelons priorité détaillée . Sur cette base, le tableau de support sera trié à l'avenir. Autrement dit, au sommet, il y aura les tâches les plus prioritaires pour l'entreprise, qui sont toujours triées à l'intérieur par la compréhension par l'équipe de l'importance de cela et de la rapidité avec laquelle cela peut être fait.

Parmi les principaux paramètres, il semble que l'un des plus importants manque - une description normale . Très souvent, nous avons démarré des tâches de support à partir du système Sentry, où tombent des erreurs, des exceptions, etc. Une personne voit qu'il y a un petit problème et crée un puzzle à Jira. Puisque nos systèmes sont intégrés les uns aux autres, une tâche apparaît dans le traqueur de tâches, dans la description de laquelle il n'y a qu'un lien vers Sentry, et dans le titre il y a un texte d'erreur. C’est tout.

Comment celui qui obtient cette tâche doit-il travailler avec cela? Pas très clair. Si vous avez ajouté une bonne description à cette tâche, cela aiderait grandement et gagnerait du temps.

Qui va tout ratisser?

Et lorsque tout cela est fait, la question se pose: qui va ratisser cet arriéré magnifiquement trié? La réponse est: ingénieur support.

Vous pouvez écouter plus en détail qui est l'ingénieur de support et ce qu'il fait dans mon rapport «Hypothèque technique: quoi et qui devrait diriger l'équipe» avec TeamLeadConf 2018.

Un ingénieur de support est un gars qui prend et corrige les tâches les plus prioritaires à partir d'un backlog de support. Puisque tout est magnifiquement trié, nous pensons que le sommet est le plus important, le plus urgent et le plus "pâtissier". S'il n'y a pas de tâches, il peut faire du backlog technique.

Que fait-il d'autre?

1. Essaie d'isoler et d'éliminer la cause première , c'est-à-dire la cause première du support. Lorsque vous recevez régulièrement des billets du même type, il convient de se demander pourquoi cela se produit. Très probablement, quelque part il y a un problème qui peut être éliminé, et ainsi arrêter le flux de tâches similaires.

2. Il définit les tâches de correction et de surveillance .
Si l'ingénieur de support ne peut pas résoudre le problème en un jour ou deux au maximum, il définit une tâche distincte pour celui-ci, qui entre dans le backlog de développement. Ensuite, il est évalué par l'équipe et entre dans l'itération en tant que support planifié.

La surveillance joue un rôle important pour nous. Nous suspendons la surveillance non seulement aux mesures que nous sommes habitués à surveiller en continu, mais nous les ajoutons également pour localiser les problèmes les plus anciens. À mon avis, il serait préférable que nous ayons une surveillance inutile, que nous buvons ensuite, que le problème se répète constamment sous la forme de billets de plus en plus nombreux.

3. Recherche de raisons d'automatisation .
Exemple : nous transférons des données vers notre système, qui automatise le travail du service de livraison. Parfois, il s'avère que même avec l'utilisation du canal des lettres mortes et du transfert, nous ne pouvons pas y fournir d'informations. En conséquence, de telles commandes sont suspendues quelque part et doivent être renvoyées.

Il s'agit d'un support typique qui se produit plusieurs fois par semaine. Pour résoudre ce problème, nous avons décidé de créer une page séparée avec le bouton «renvoyer la liste des commandes». Nous n'avons plus ce support. Autrement dit, pensaient-ils, automatisé, il l'a donné au service de support.

Le rôle d'un ingénieur support est transféré chaque semaine à une autre personne - c'est une condition préalable. Faire un tel travail plus longtemps est stress, démotivation et décadence, car vous réparez constamment quelque chose et n’apportez rien de nouveau au système.

La régularité comme source de grâce

Cela semble évident, mais il est souvent oublié de toute façon. Pour que tout fonctionne, il est nécessaire que nos processus soient mis en service et régulièrement observés.

Inspection de l'arriéré

Où allons-nous obtenir un backlog de support magnifiquement trié si personne ne regarde là-bas?

Dans le bon sens, vous devez l'exécuter une fois par mois et fermer les tâches avec un statut trivial (que vous n'obtiendrez probablement jamais). Soyez honnête avec vous-même et avec le client. Si l'arriéré dû à de telles tâches augmente à l'infini, vous devrez ensuite paniquer pour essayer de les fermer. Ce n'est pas très bon.

Apposition prioritaire détaillée

C'est le processus même dans lequel nous évaluons à quel point une tâche est critique. Ce sera alors le bon tri, et l'ingénieur support prendra la bonne tâche d'en haut.

Bataille pour la priorité

Par exemple, ils vous ont assigné une tâche et ont dit: «Les gars, le rapport mensuel n'est pas téléchargé. Nous devons l'avoir dans une semaine, mais cela ne fonctionne pas. Veuillez le réparer. Priorité P1. Vous devez décider dans les 2-3 heures. "

Et vous demandez: «Sérieusement? De quoi parlez-vous les gars? Après tout, il y a une semaine pour le réparer. Revenons à P2 et nous aurons quelques jours. »

Parfois, les gens pensent que nous n'assumerons pas la tâche, ils accordent donc une priorité particulière. Mais cela arrive et vice versa. Par exemple, ils nous écrivent que les commandes ne sont pas créées et mettent la priorité P2. Ce problème est beaucoup plus grave, il convient donc de relever la priorité à P1. Il est utile de négocier sciemment dans les deux sens.

Etablissement de nouvelles tâches

Plus tôt, j'ai mentionné le système Sentry, qui comprend des tâches déjà exécutées par les clients. Cependant, nous anticipons nous-mêmes les problèmes qui se posent et nous mettons nous-mêmes des tâches dans cet arriéré.

Surveillance des performances SLA

Pour ce faire, nous avons des plannings qui montrent que nous avons des tâches, dont le temps va bientôt expirer. Il semble que ces énigmes aient un sens en premier lieu.

Support Engineer Support

Être un ingénieur de support est un processus plutôt déprimant, donc une personne devrait aider. Comment pouvons-nous lui faciliter la vie?

Transférer le rôle au prochain de l'équipe

Nous devons garder un calendrier de qui fera cela la semaine prochaine. Cependant, des moments limites se produisent. Par exemple, une personne a pris une tâche vendredi et n'a pas eu le temps de la terminer. Il peut passer du temps la semaine prochaine, mais il vaut mieux confier la tâche à un nouvel ingénieur de support. Si vous traînez sur le ratissage de l'arriéré pendant deux semaines, la personne sera probablement assez démotivée. Vous le verrez lors de la prochaine réunion personnelle :)

Aidez à trouver la source du problème

Les gens aiment simplement ratisser les tâches, mais ils ne se concentrent pas sur la recherche de la cause profonde. Il vaut la peine de se poser la question: «Si vous avez clôturé la tâche, alors pourquoi le problème est-il apparu au départ?». Cette pratique aidera à trouver la cause, à l'éliminer et, éventuellement, à se débarrasser du flux d'un tel soutien à l'avenir.

La nécessité d'un «nouveau look»

Si une personne pendant une certaine période de temps ne pouvait pas obtenir un résultat visible, cette tâche devrait être transférée à une autre. Quelqu'un d'autre pourra regarder le problème de l'autre côté, ce qui peut conduire à la solution du problème d'une manière différente.

Mais une telle approche peut cacher certains aspects psychologiques intéressants. Autrement dit, en prenant une tâche d'une personne et en la confiant à une autre, vous risquez de dire qu'il sait mieux, alors il s'en sortira. Ces choses sont mieux présentées d'une manière différente. Concentrez-vous sur le fait que nous devons tous résoudre des problèmes avec le système, et ne pas nous prouver lequel de nous est le plus cool.

Développement d'outils d'automatisation

Ceux qui sont souvent des ingénieurs de support comprennent qu’ils «cuisent» déjà en effectuant les mêmes tâches typiques. Récemment, l'un de nos développeurs a son propre mini framework sur Go. Il va dans différentes bases de données, recueille des données, pousse quelque chose dans Kafka. Ainsi, il a pu automatiser autant que possible cette tâche et faciliter la vie des autres.

Sources d'assistance

Il y a tellement de soutien que nous ne pensons parfois pas à son origine si souvent?

Stabilisation de nouveaux systèmes et processus

Si vous avez apporté quelque chose de nouveau, il est fort probable qu'il sera mal utilisé. Vous rencontrerez de nouveaux problèmes par vous-même et votre backlog de support sera immédiatement réapprovisionné en tickets ou tickets.

Prise en charge des anciens systèmes

Par exemple, notre monolithe. Il ne peut pas rester immobile, comme nous ajoutons toujours, réécrivons quelque chose en lui. Bien sûr, cela conduit à la création d'un nouveau support.

Défaillance technique

Par exemple, le réseau s'est déconnecté. Vous semblez ne pas être à blâmer, mais ils viendront certainement vous demander pourquoi les commandes n'ont pas été créées. Il faudra réparer, réparer, modifier quelque chose. Une intervention manuelle sera nécessaire et, par conséquent, de nouveaux tickets dans l'arriéré sont fournis.

Facteur humain

Nous avons eu un cas où quelqu'un a pu produire un message dans RabbitMQ que notre consommateur a raccroché, et tout a cessé de fonctionner. Cela ne s'est jamais produit au cours des 7 dernières années, mais ici, cela a réussi en quelque sorte :)

Le facteur humain qui a conduit à l'échec

Quelqu'un avec les mots «je vais le réparer maintenant» a retiré le disque dur du serveur sur lequel la facturation tournait. En conséquence, nous avons obtenu ce que nous avons obtenu. Ce n'est pas l'expérience Lmoda, mais un vrai cas de ma pratique.

Types de support

Demande d'analyse

Lorsqu'ils demandent régulièrement le statut de quelque chose dans la base de données, ils demandent à télécharger, à collecter un rapport pour une certaine période, etc. C'est un peu ennuyeux, vous avez donc une bonne raison de penser à l'automatisation et de simplement fournir une interface utilisateur ou d'étudier la structure de l'entreprise.

Par exemple, je n'ai pas immédiatement découvert que la plupart des données de commande que nous avons sont stockées dans la base de données Oracle du département D&A, et tout peut être obtenu à partir de là. Un tel support est soit automatisé via des interfaces, soit transféré au service analytique.


Demandes de modification des données

Les situations sont différentes et imprévisibles. Disons que notre client allait payer sa commande avec une carte. Lorsque le courrier est arrivé, il a changé d'avis et a décidé de le faire en espèces. Ou, par exemple, quelque part il y avait un problème automatisé qui doit être changé à la main. Nous devons corriger ces données.

Pour ce faire, nous essayons de créer de nouveaux descripteurs d'API, de créer des interfaces et, au maximum, de supprimer ces tâches du développement et de notre équipe d'exploitation. C'est une pratique dangereuse, et nous nous en débarrassons grâce aux améliorations de l'interface et de l'API.

Réparation des processus d'affaires

S'il y a un besoin direct d'éditer quelque chose dans la base de données, alors il y a un processus métier buggé. Cela peut se produire soit pour une raison liée à l'informatique, soit en cas de problème dans l'entreprise. Là et là, des ajustements sont nécessaires. Dans ce cas, vous devez vous adresser au client professionnel et déterminer si cela peut être fait différemment, ou demander un développement pour réparer le processus métier.


La fonctionnalité X a cessé de fonctionner

C'est mon type de support préféré, car c'est le plus compréhensible. Autrement dit, nous avions une sorte de chose dans la prod, mais elle s'est cassée et doit être réparée. Découvrez dans quelle version est morte et pour quelle raison. Réparez et fermez le ticket. Tout est simple.

Mais il existe un autre support - la fonctionnalité X ne fonctionne pas . Cela peut ressembler à la même chose, mais dit en d'autres termes. Mais ce n'est pas le cas.

Dans cette situation, ils viennent à vous et disent que cette chose ne fonctionne pas. Vous passez un jour ou deux à le trier. Ce n'est que plus tard que vous avez réalisé que cela n'a jamais fonctionné ici . Ce n'était tout simplement pas dans votre système.

D'une autre manière, j'appelle ce type de support «renard» quand quelqu'un rusé veut glisser une demande de fonctionnalité sous le couvert d'une tâche de support. C'est une histoire régulière qui est très douloureuse. Si vous n'arrêtez pas de tels moments, il s'avère que votre ingénieur de support ou vous-même introduisez de nouvelles fonctionnalités, et les vrais problèmes du backlog de support restent non résolus.

Incident majeur

Ce n'est que l'histoire du cercueil et du feu de tourbe, quand quelque chose s'est brisé si mal dans les systèmes informatiques qu'un processus métier spécifique est apparu.

Étude de cas de notre pratique: nous, en raison d'une erreur dans le code et des tests automatiques imparfaits, avons commencé à envoyer une certaine note sur le statut de la commande au service de messagerie externe, à cause de laquelle les gens ne pouvaient pas récupérer leur commande au point de ramassage. Elle a touché des milliers de clients. Nous devions reprendre toutes les commandes, dépenser de l'argent dessus. Nous n'avons pas pu les vendre et la fidélité des clients a été perdue. Il s'agit d'un gros incident qui a nui à l'entreprise.

Cela vaut la peine de travailler avec de telles choses d'une manière spéciale, et je vais vous expliquer comment nous procédons.

Comment savoir que quelque chose se passe?

L'option la plus courante dans l'industrie est d'apprendre des utilisateurs . Il est, bien sûr, le pire, car cela signifie qu'ils "font cuire" déjà. , , .

, , .

— . , . , - , , , Rabbit.

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



, . , shovel-plugin, . , major .

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

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

, , .

Lamoda , . , - , CTO. , , .

— . , , .



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

?

, , . , - . , , , .

, 16.55, , 40 . , , .

?

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

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

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

/fix versions .

. — , — .

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

. , , , . , .

, , , , -. .

?

— . , .

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

, . , , , - , IT .

Sweet spot

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