Bonjour, Habr ! Depuis dix ans, je maintiens des systèmes informatiques de haute charge. Je ne vais pas parler dans cet article des problèmes de configuration de nginx pour fonctionner à plus de 1000 RPS ou d'autres aspects techniques. Je vais partager des observations sur les problèmes dans les processus qui surviennent dans le support et l'exploitation de tels systèmes.
Surveillance
Le support technique n'attend pas que la demande arrive avec le contenu « Pourquoi... le site ne fonctionne-t-il encore pas ? ». Le support doit déjà voir le problème une minute après la chute du site et commencer à le résoudre. Mais le site n'est que la pointe de l'iceberg.. Sa disponibilité est l'une des premières choses surveillées.
Que faire dans une situation où les stocks de produits de la boutique en ligne ne parviennent plus depuis le système ERP ? Ou le système CRM, qui calcule les réductions pour les clients, a cessé de répondre ? Le site, à première vue, fonctionne. Un Zabbix hypothétique reçoit sa réponse 200. L'équipe de garde n'a reçu aucune notification de la surveillance et continue joyeusement de regarder le premier épisode de la nouvelle saison de « Game of Thrones ».
Souvent, la surveillance se limite à mesurer l'état de la mémoire, de la RAM et la charge des processeurs. serveurs. Mais il est beaucoup plus important pour les entreprises d'obtenir la disponibilité des produits sur le site. La chute d'une machine virtuelle dans le cluster entraînera un arrêt du trafic à destination de celle-ci et augmentera la charge sur d'autres serveurs. L'entreprise ne perdra cependant pas d'argent.
C'est pourquoi, en plus de surveiller les paramètres techniques des systèmes d'exploitation sur les serveurs, il est nécessaire de configurer des métriques commerciales. Des métriques qui influencent directement l'argent. Différentes interactions avec des systèmes externes (CRM, ERP, etc.). Nombre de commandes sur une période donnée. Authentifications des clients réussies ou échouées et d'autres métriques.
Interactions avec des systèmes externes.
Tout site ou application mobile ayant un chiffre d'affaires annuel supérieur à un milliard de roubles interagit avec des systèmes externes. Cela va des CRM et ERP mentionnés précédemment à la transmission des données de vente à un système externe de Big Data pour analyser les achats et proposer au client un produit qu'il va certainement acheter (en réalité, ce n'est pas le cas). Chaque système de ce type a son propre support. Et souvent, communiquer avec ces systèmes peut être pénible. Surtout lorsque le problème est global et qu'il faut l'analyser dans différents systèmes.
Certain systems provide the phone number or Telegram of their admins. In some places, you need to email managers or go to the issue trackers of these external systems. Even within a large company, different systems often operate under different ticketing systems. Tracking the status of requests can sometimes become impossible. You receive a ticket in one arbitrary Jira. Then you put a link to a task in another Jira in the comments of this first Jira. In the second Jira, someone is already commenting in the request that you need to call a conditional admin, Andrey, to resolve the issue. Et ainsi de suite.
An optimal solution to this problem would be to create a unified communication space, for example, in Slack. Inviting all participants in the process of managing external systems. And also having a single tracker to avoid duplicating requests. Requests should be tracked in one place, starting from monitoring notifications to deploying bug solutions in production. You might say that this is unreal and that historically we have worked in one tracker, while they use another. Different systems emerged, each with its own autonomous IT teams. I agree, and that's why the problem needs to be addressed at the level of the CIO or product owner.
Every system you interact with should provide support as a service with a clear SLA for resolving issues by priority. Not just whenever a conditional admin Andrey finds a moment for you.
The person is a bottleneck.
Is there someone on the project (or product) whose absence on vacation causes panic among the management? This could be a devops engineer, analyst, or developer. After all, only the devops engineer knows which servers have which containers, how to reboot a container in case of a problem, and any complex issue cannot be solved without him. The analyst is the only one who knows how your complex mechanism works: which data streams go where, under what parameters requests to which services are made, and what responses we will receive.
Who will quickly understand why there are errors in the logs and promptly fix a critical bug in production? Of course, that same developer. There are others, but for some reason, only he understands how the different modules of the system are structured.
The root of this problem is the lack of documentation.. En effet, si tous les services de votre système étaient décrits, il serait possible de résoudre le problème sans analyste. Si le devops prenait quelques jours sur son emploi du temps chargé pour décrire tous les serveurs, services et instructions pour résoudre les problèmes courants, le problème en son absence pourrait également être résolu sans lui. Il n'est pas nécessaire de rapidement finir sa bière à la plage pendant les vacances et de chercher du wi-fi pour résoudre un problème.
Compétence et responsabilité des employés du support
Dans les grands projets, les entreprises ne sont pas avares sur les salaires des développeurs. Elles chassent des mid-level ou seniors coûteux venant de projets similaires. La situation est un peu différente en ce qui concerne le support. Ces dépenses sont réduites autant que possible. Les entreprises embauchent des techniciens peu coûteux d'hier et se lancent confiantes dans l'arène. Cette stratégie est viable lorsqu'il s'agit d'un site vitrine d'une usine à Zelenograd.
Si l'on parle d'une grande boutique en ligne, chaque heure d'arrêt coûte plus qu'un salaire mensuel d'un technicien. Prenons pour point de départ 1 milliard de roubles de chiffre d'affaires annuel. C'est le chiffre d'affaires minimum de toute boutique en ligne du classement . Divisons ce montant par le nombre d'heures dans l'année et nous obtenons plus de 100 000 roubles de pertes nettes. Et si l'on ne compte pas les heures nocturnes, on peut facilement doubler ce montant.
Mais l'argent n'est pas le principal, n'est-ce pas ? (non, bien sûr que c'est le principal) Il y a aussi des pertes de réputation. Une heure d'interruption d'une boutique en ligne bien connue peut provoquer une vague d'avis sur les réseaux sociaux, ainsi que des publications dans des médias spécialisés. Et les discussions entre amis autour d'un plat de cuisine comme « N'achète rien là-bas, leur site ne fonctionne jamais » ne se mesurent tout simplement pas.
Passons maintenant à la responsabilité. Dans ma pratique, il y a eu un cas où l'administrateur de garde n'a pas réagi à temps à l'alerte du système de surveillance concernant l'indisponibilité du site. Un agréable vendredi d'été, le site d'une célèbre boutique en ligne de Moscou était silencieusement hors service. Le samedi matin, le responsable de ce site ne comprenait pas pourquoi le site ne s'ouvrait pas, tandis que dans les supports et les alertes urgentes sur Slack, c'était le silence. Cette erreur nous a coûté une somme à six chiffres, et ce responsable a perdu son poste.
La responsabilité est une compétence difficile à développer. Il est soit là, soit il ne l'est pas. C'est pourquoi lors des entretiens, j'essaie de déterminer sa présence à travers diverses questions qui montrent indirectement si la personne est habituée à assumer des responsabilités. Si quelqu'un répond qu'il a choisi son université parce que ses parents le lui ont dit ou qu'il change de travail parce que sa femme dit qu'il ne gagne pas assez, alors il vaut mieux ne pas s'associer avec de telles personnes.
Interaction avec l'équipe de développement
Lorsque des problèmes simples surviennent pour les utilisateurs en production, le support les résout par ses propres moyens. Il essaie de reproduire le problème, analyse les journaux, etc. Mais que faire lorsque un bug apparaît en production ? Dans ce cas, le support crée une tâche pour les développeurs et c'est ici que les choses deviennent intéressantes.
Les développeurs sont constamment débordés. Ils se consacrent à la création de nouvelles fonctionnalités. Corriger des bugs en production n'est pas forcément ce qui les intéresse le plus. Les délais pour terminer le sprint en cours sont serrés. Et là, des personnes désagréables du support arrivent et disent : « Arrêtez tout de suite, nous avons des problèmes ». La priorité de ces tâches est minimale. Surtout lorsque le problème n'est pas critique et que la fonctionnalité principale du site fonctionne, et que le responsable des versions ne court pas avec des yeux écarquillés en disant : « Il faut absolument inclure cette tâche dans la prochaine version ou le hotfix ».
Les tâches avec une priorité normale ou basse passent d'une version à l'autre. À la question « Quand la tâche sera-t-elle effectuée ? », vous recevrez des réponses du style : « Désolé, il y a beaucoup de tâches en ce moment, demande à des chefs d'équipe ou au responsable des versions ».
Les problèmes en production ont la priorité sur la création de nouvelles fonctionnalités. Les avis négatifs ne tarderont pas à arriver si les utilisateurs rencontrent constamment des bugs. Il est difficile de réparer une réputation ternie.
Les questions d'interaction entre le développement et le support sont gérées par DevOps. Cet acronyme est souvent utilisé pour désigner une personne spécifique qui aide à créer des environnements de test pour le développement, à établir des pipelines CI/CD et à déployer rapidement le code testé en production. DevOps est une approche du développement logiciel dans laquelle tous les participants au processus collaborent étroitement et aident à créer et à mettre à jour plus rapidement des produits et services logiciels. Je parle des analystes, des développeurs, des testeurs et du support.
Le support et le développement ne sont pas des départements distincts avec leurs propres objectifs et missions dans cette approche. Le développement est impliqué dans l'exploitation et vice versa. La célèbre phrase des équipes distribuées : « Le problème n'est pas de mon côté » est moins fréquente dans les discussions, et les utilisateurs finaux deviennent un peu plus heureux.
Source : habr.com
