Le devoir est un élément important de la plupart des organisations modernes. Après tout, il arrive souvent que le problème arrive à 3 heures du matin. Mais qui devrait être de service? Et comment organiser ce processus pour qu'il ait du sens?
Regardez sous le chat, Baruch Sadogursky (
@jbaruch ) et Leonid Igolnik (
@ligolnik ) racontent une histoire d'horreur à propos d'un officier de service malchanceux. Rappelez-vous Vasya, qui a toujours dû
corriger les bugs à trois heures du matin? Ce n'est que le début.
Le matériel a été préparé sur la base du discours de Baruch et Leonid lors de la conférence d'automne DevOops 2017.
Donc en service. À titre d'exemple, prenons l'hypothèse Vasya, qui a travaillé dans une certaine entreprise il n'y a pas si longtemps, environ un an. Aujourd'hui est vendredi et il se trouve que Vasya est de service. Tout se passe bien: Vasya dort et ses rêves sont magnifiques.
Bien qu'il ne se doute de rien, son collègue du support technique reçoit un appel d'un client. Il dit que lundi il devra montrer au PDG une démonstration très importante, mais quelque chose ne fonctionne pas. Besoin urgent de résoudre le problème. Le support a fait tout ce qu'il pouvait (a suggéré de l'éteindre et de l'allumer) et a aggravé ce problème au préposé.
Vasya est seul de service pour l'ensemble du projet, il devra le faire. Un ingénieur du support technique le réveille et essaie d'expliquer le problème avec des mots très simples: "Quelque chose ne fonctionne pas là-bas, quelque chose ne va pas."
Vasya écoute son collègue, réfléchit à ce qui s'est passé et prend la seule bonne décision ...
L'ingénieur de support est offensé, mais demande toujours au client d'attendre jusqu'à lundi. Le client n'est pas d'accord avec cet état de fait et transmet le problème au responsable du support. Maintenant, il appelle Vasya et dit que ce n'est pas grave: "Pourtant, l'affaire est importante, le client est inquiet, c'est nécessaire." Vasya est une personne responsable. Cela doit être nécessaire: café et danse (cherchez quelque chose dans les journaux).
Dans les journaux, tout s'est avéré loin d'être simple. Tout d'abord, Vasya cherchait une personne ayant accès au bon journal pendant 15 minutes. Il l'a trouvé et a obtenu un journal. Mais comment? Pour envoyer un mail au format .doc, bien sûr. Vasya est responsable, jeune et lit le journal dans Word: rien n'est compris du tout. Mais il existe des mots clés que vous pouvez rechercher dans la base de connaissances. Vasya s'accroche à des choses intéressantes pendant environ 20 minutes, apprend beaucoup de choses intéressantes, mais rien n'est nécessaire pour le moment.
Que fait Vasya ensuite? Vous devez chercher quelqu'un, mais Vasya est un jeune ingénieur et c'est effrayant de réveiller Senior. Par conséquent, il décide que vous devez appeler un collègue, le même junior.
Un collègue est un bon ami, avec un chagrin de moitié, il comprend le problème et commence à le résoudre. Après deux à trois heures de travail, ils ont trouvé un correctif. Il doit être immédiatement remis en production. Mais comment? Il y a un tableau de contrôle des changements, qui se réunit le lundi une fois toutes les deux semaines. Mais cette option ne convient pas, vous en avez besoin de toute urgence.
Naturellement, vous ne pouvez pas déployer en production, il n'y a pas de racine. La seule option est donc d'envoyer un fichier jar avec deux classes et un paragraphe d'explications par e-mail. Ces gars entreront en production via ssh et là, ils mettront ce fichier jar dans WebSphere dans le bon répertoire. Et maintenant, à 6 h 7 du matin, vous pouvez enfin vous coucher avec un sentiment d'accomplissement.
Lundi, Vasya vient travailler et voit une photo inhabituelle. Le PDG criait au VP de l'ingénierie parce que le client criait au PDG parce que son PDG lui criait dessus. Il s'avère qu'il n'a pas été possible de résoudre le problème.
Les autorités ont quatre questions: "Que s'est-il passé vendredi?"; "Pourquoi ai-je entendu parler de cela par le patron lundi?"; "Pourquoi le correctif a pris six heures?" et "Qui est à blâmer?" Des Ops sont appelés dans la salle, qui disent que ce n'est pas leur problème. Vasya et l'autre femme de chambre sont appelées dans la pièce, qui dit également: «Rien n'a fonctionné.» Tout ce jeu de pommes de terre se poursuit jusqu'au déjeuner.
Comme il est temps de dîner, la décision est prise: "D'accord, c'est cassé par lui-même, personne n'est à blâmer." La fin de l'histoire.
Organisons un petit débriefing: passons par ce cauchemar et essayons de donner des réponses à toutes les questions.
Qui devrait être en service
Les administrateurs système (ou un mot plus à la mode - SRE) peuvent être en service. Ils font ça depuis plusieurs années, ils ont tout bien réglé. DBA peut être en service, ceux qui sont engagés dans la messagerie le peuvent. Si vous avez de la chance, le NOC (Network Operation Center) est de service - c'est alors que tous ces gars sont mis dans la même pièce. Ils ont des carnets de course qui disent quoi faire dans une situation difficile.
Tout est clair avec ces gars, ce sont des pros en service. Mais, malheureusement, DevOps a la deuxième partie de l'équation, qui ne veut pas vraiment être en service. Comment faire la deuxième partie? Oui, et s'il est nécessaire de forcer, car les pros doivent être conscients de l'importance du devoir.
Il y a deux raisons pour lesquelles les gens ne veulent pas être en service. L'une est quand oui:
Personne ne veut être en service quand tout va mal. La solution à ce problème est assez simple:
Vous devez écrire du bon code, tout est simple. Mais cela doit également être appris. Une nouvelle question se pose: "Comment apprendre?". Vous devez mettre vos doigts dans la douille - #painisinstructional. La douleur aide.
Le devoir améliore à lui seul la qualité du code. Le même Vasya lundi corrigera très probablement ses erreurs afin de ne pas s'asseoir une autre nuit à la recherche d'erreurs.
Obstacles en service
En service, certains obstacles ne devraient pas exister. Passons en revue le fiasco de Vasya vendredi. Rappelez-vous comment il a lu les journaux dans un document Word?
Nous aimons tous les produits Microsoft, mais vous ne pouvez pas le faire dans le monde moderne. Il y a des choses évidentes sur les journaux que tout le monde devrait comprendre.
Le point principal est le nombre d'outils qui résolvent ces problèmes: Logstash, Loggly, Sumo logic, Kibana. Ils doivent être utilisés.
Revenons à la question de l'accès: pourquoi ne pas donner accès au journal? La réponse est des données sensibles. On a promis aux clients de protéger les données contre les fuites. Cela signifie que les journaux ne peuvent être montrés à personne ou que vous devez utiliser des systèmes avec la fonctionnalité de masquage des données. Il cache lui-même des données personnelles et ne les montre pas à une personne sans le niveau d'accès requis. Tous les outils d'analyse de journaux d'aujourd'hui ont cette fonctionnalité.
Un autre avantage de ces outils est que le «suivi des pauvres» peut être construit sur eux. Par exemple, dans les journaux, après avoir vu un certain nombre d'erreurs (la file d'attente est pleine, etc.), vous pouvez déclencher une allergie.
Qui détermine l'importance du problème
Comment comprendre, aller en service ou courir de toute urgence pour résoudre le problème? Qui nomme la gravité? Qui décide de l'importance du problème? Résout le support. Pourquoi? Parce que le soutien a une vision du problème. Il sait à quel point tout est mauvais.
De plus, aujourd'hui, presque toutes les entreprises travaillent sur le principe de la «livraison continue», de sorte que tous les clients reçoivent toutes les fonctionnalités en même temps (et en même temps des bugs). Supposons qu'il existe un bogue qui pour le client ressemble à "Quelque chose ne fonctionne pas là, ça va." Dans le même temps, le support voit des centaines d'alertes sur le problème, ce qui est évidemment grave.
Le client est également impliqué dans la détermination de l'importance du problème. Mais il y a un problème - le client ne croit pas toujours que son petit problème sera réparé et accorde la plus haute importance. La gravité commence à être utilisée comme outil de manipulation. Mais si la définition de gravité est construite correctement et que le client comprend ce qu'est le SLA, cela ne se produit généralement pas. Il s'agit d'un processus d'apprentissage mutuel lorsque les clients commencent à comprendre ce qui est vraiment très important et ce qui est tout simplement important.
Les clients doivent avoir la possibilité de montrer leur importance car le fabricant du produit ne comprend pas toujours le contexte du problème.
SLA - une garantie de réponse et de solutions en une journée, mais peut être plus rapide. Cela, encore une fois, dépend du contexte.
Défis organisationnels
Vasya n'a pas compris le problème jusqu'au bout. Bien sûr, il vient de se réveiller, et un collègue du support technique a également mal expliqué. Il n'est traité que d'une seule façon: un ticket. Un ticket est un numéro de référence qui indique de quoi il s'agit. Cela est nécessaire pour Vasya, car au lieu d'un téléphone, le support pourrait dire à Vasya "Ouvrez notre système de gestion des billets et consultez le numéro de billet 42". Cela est nécessaire pour plusieurs raisons. Tout d'abord, Vasya, au lieu d'écouter un collègue endormi, se réveillera, ira lire un billet et comprendra à quel point c'est important. Deuxièmement, il peut y avoir plus d'un problème.
Il y a une autre difficulté qui affecte l'image globale: Vasya doit être trouvé. Comment le support sait-il que Vasya est en service aujourd'hui? Et s'il ne connaît pas Vasya non plus. Il est important de trouver la bonne personne. La solution est Virtual Extension avec différents préfixes pour l'ingénieur, la production, etc. Eh bien, ou d'autres systèmes plus sophistiqués. Avec cette solution, vous n'avez pas à deviner où appeler au milieu de la nuit, tout bascule automatiquement.
Encore plus pratique est Escalation Chat dans Slack, Telegram, Skype, n'importe où. Le titre du chat est le numéro du même ticket. Toute communication sur ce ticket entre les bonnes personnes se fait dans cette salle de chat. L'une des caractéristiques les plus utiles d'un tel chatik est que vous n'avez rien à dire à ceux qui rejoignent le travail après un certain temps. Vous pouvez simplement lire quelles décisions ont déjà été prises.
Eh bien, un pont téléphonique virtuel, qui peut être comparé à un lieu de rassemblement en cas d'incendie: tout le monde sait où aller en cas de problème. Soit dit en passant, dans les systèmes modernes comme Zoom ou Bluejeans, toutes les fonctionnalités nécessaires sont déjà intégrées.
Chemin d'escalade
Vasya avait peur d'appeler le seigneur, car ils sont terribles. Que faire avec ça? Parlons du chemin d'escalade. Vous devez toujours savoir qui et quand se réveiller ou décoller du travail. Cela devrait être parfaitement clair pour tout le monde: pour celui qui se réveille et pour celui qui se réveille. Vous devez également savoir où appeler si le premier chemin d'accès n'a pas fonctionné. Un bon chemin d'escalade va jusqu'au PDG de l'entreprise.
Il y a des communications qui devraient provenir du PDG. Il doit être conscient des problèmes critiques.
Gestionnaire de courses
Le prochain poste intéressant est celui de gestionnaire de garde. Il n'a pas besoin d'être un technicien et de participer à la résolution d'un problème. Tout d'abord, Vasya au milieu de la nuit ne peut rien dire d'utile au client. Le responsable de service peut vous aider dans cette situation. De plus, il peut s'engager dans la coordination, la gestion de projet dans une situation difficile, la gestion des ressources. Après tout, le travail doit se dérouler sans heurts.
Accès à la production
Dois-je donner à Vasya l'accès à la production? Après tout, tous ne sont pas de brillants ingénieurs, et il y a certaines choses que je ne voudrais pas apprendre, les clients seront offensés. Ceci est résolu en utilisant le processus de déploiement. Si le processus est configuré correctement, Vasya peut cliquer sur le bouton, ce qui entraînera la désactivation de son code de production. Si vous disposez d'un pipeline de livraison continue normal, cela peut très probablement être fait automatiquement (tous les tests réussiront). Sinon, dans de nombreuses entreprises, la décision est prise par un ingénieur ou un gestionnaire principal. Il examine, évalue le risque du code et prend une décision.
Et même avant l'apparition du correctif, des outils documentés pour le dépannage devraient être impliqués. L'un des problèmes les plus courants en service: il commence à penser comment activer le débogage ou modifier le niveau des journaux. En même temps, il n'y a aucun problème avec tout le reste. Il est conseillé d'avoir des solutions documentées aux problèmes.
Changement de devoir
Parlons maintenant du processus de devoir, qui prend généralement une semaine. À un moment donné, il est nécessaire de changer. Pour changer efficacement, cela doit être fait à un certain moment. Il est nécessaire de tout planifier clairement et il est souhaitable de pouvoir transférer efficacement les problèmes à la prochaine personne de service. Dans de nombreuses entreprises, cela se fait comme un rallye standard, ou une page est créée dans laquelle le préposé tient un petit magazine.
D'autres problèmes
Il existe divers autres problèmes qui doivent être résolus. L'un d'eux est la certification de l'accès à la production. Il est conseillé de procéder à une certification élémentaire afin qu'une personne montre qu'elle comprend ce qui est possible et ce qui ne l'est pas.
Comment le traduire?
Mais comment apporter tout cela à l'entreprise? Vous devez comprendre que cela prendra un certain temps.
Nous devons commencer par les gars seniors en service. Ils ont de l'expérience et savent quoi et comment réparer. Le seigneur a moins de problèmes: il y a accès aux journaux, etc.
Il est conseillé de commencer en petite équipe. Si l'équipe est déjà grande, vous devez en créer une petite à l'intérieur. De plus, lorsque tout commence à bien fonctionner, vous pouvez faire honte au reste.
Conclusions
Nous passons à l'essentiel. Malgré le fait que nous, les techniciens, sommes amoureux de la technologie, la chose la plus importante n'est pas les produits et technologies utilisés dans l'entreprise, mais le sentiment de la personne de service `` Je suis impliqué dans le processus d'amélioration du produit '' (ou du devoir lui-même). Beaucoup comprennent que vous devez être en service, mais vous voulez voir des améliorations. Les gens doivent savoir que grâce à eux et à leurs améliorations, les choses s'améliorent.
PS
Nous voulons recommander un livre intitulé Drive. Il s'agit d'un livre sur la motivation des personnes qui travaillent dans des professions comme la nôtre. Cette motivation se compose de trois composantes principales et (spoiler) aucune d'entre elles n'est de l'argent.
Déjà ce dimanche, Baruch et Leonid présenteront un rapport «#DataDrivenDevOps» au DevOops 2018 à Saint-Pétersbourg. Venez, il y aura beaucoup de choses intéressantes: voici les reportages , voici John Willis , et voici une soirée avec BoFs et karaoké . Vous attend!