Bonjour Habr! Je supporte les systèmes informatiques Highload depuis dix ans. Je n'écrirai pas dans cet article sur les problèmes de configuration de nginx pour qu'il fonctionne en mode 1000+ RPS ou d'autres choses techniques. Je partagerai mes observations sur les problèmes de processus qui surviennent lors du support et du fonctionnement de tels systèmes.
Surveillance
Le support technique n'attend pas qu'une requête arrive avec le contenu « Quoi Pourquoi... le site ne fonctionne plus ? » Une minute après le crash du site, le support devrait déjà voir le problème et commencer à le résoudre. Mais le site n'est que la pointe de l'iceberg. Sa disponibilité est l’une des premières à être surveillée.
Que faire dans le cas où les marchandises restantes d'une boutique en ligne n'arrivent plus du système ERP ? Ou le système CRM qui calcule les remises pour les clients a-t-il cessé de répondre ? Le site semble fonctionner. Conditionnel Zabbix reçoit sa réponse 200. L'équipe de service n'a reçu aucune notification de la surveillance et regarde avec plaisir le premier épisode de la nouvelle saison de Game of Thrones.
La surveillance se limite souvent à mesurer uniquement l’état de la mémoire, de la RAM et de la charge du processeur du serveur. Mais pour les entreprises, il est bien plus important d’obtenir la disponibilité des produits sur le site Web. La panne conditionnelle d'une machine virtuelle du cluster entraînera l'arrêt du trafic vers celle-ci et une augmentation de la charge sur les autres serveurs. L'entreprise ne perdra pas d'argent.
Par conséquent, en plus de surveiller les paramètres techniques des systèmes d'exploitation sur les serveurs, vous devez configurer des métriques commerciales. Mesures qui affectent directement l’argent. Diverses interactions avec des systèmes externes (CRM, ERP et autres). Le nombre de commandes pour une certaine période de temps. Autorisations client réussies ou non et autres mesures.
Interaction avec des systèmes externes
Tout site Web ou application mobile dont le chiffre d'affaires annuel dépasse un milliard de roubles interagit avec des systèmes externes. En commençant par le CRM et l'ERP mentionnés ci-dessus et en terminant par le transfert des données de vente vers un système Big Data externe pour analyser les achats et proposer au client un produit qu'il achètera certainement (en fait, pas). Chacun de ces systèmes a son propre support. Et souvent, la communication avec ces systèmes est source de douleur. Surtout lorsque le problème est global et qu’il faut l’analyser dans différents systèmes.
Certains systèmes fournissent un numéro de téléphone ou un télégramme à leurs administrateurs. Quelque part, vous devez écrire des lettres aux responsables ou accéder aux trackers de bugs de ces systèmes externes. Même dans le contexte d'une grande entreprise, différents systèmes fonctionnent souvent dans des systèmes comptables d'application différents. Il devient parfois impossible de suivre l’état d’une demande. Vous recevez une demande dans un Jira conditionnel. Puis dans le commentaire de ce premier Jira vous mettez un lien vers le problème dans un autre Jira. Dans le deuxième Jira de l'application, quelqu'un est déjà en train d'écrire un commentaire qui vous devez appeler l'administrateur conditionnel Andrey pour résoudre le problème. Et ainsi de suite.
La meilleure solution à ce problème serait de créer un espace unique de communication, par exemple dans Slack. Inviter tous les participants au processus d'exploitation de systèmes externes à se joindre. Et aussi un seul tracker pour ne pas dupliquer les applications. Les applications doivent être suivies en un seul endroit, depuis la surveillance des notifications jusqu'à la sortie de solutions de bugs à l'avenir. Vous direz que c'est irréaliste et qu'il est historiquement arrivé que nous travaillions dans un tracker et eux dans un autre. Différents systèmes sont apparus, ils avaient leurs propres équipes informatiques autonomes. Je suis d'accord, et le problème doit donc être résolu d'en haut, au niveau du CIO ou du propriétaire du produit.
Chaque système avec lequel vous interagissez doit fournir une assistance en tant que service avec un SLA clair pour résoudre les problèmes par priorité. Et pas quand l'administrateur conditionnel Andrey a une minute pour vous.
Homme goulot d'étranglement
Est-ce que tout le monde sur un projet (ou un produit) a une personne dont le départ en vacances provoque des convulsions chez ses supérieurs ? Il peut s'agir d'un ingénieur DevOps, d'un analyste ou d'un développeur. Après tout, seul un ingénieur DevOps sait quels serveurs ont quels conteneurs installés, comment redémarrer le conteneur en cas de problème et, en général, tout problème complexe ne peut être résolu sans lui. L’analyste est le seul à savoir comment fonctionne votre mécanisme complexe. Quels flux de données vont où. Sous quels paramètres de demandes, quels services, lesquels recevrons-nous des réponses.
Qui comprendra rapidement pourquoi il y a des erreurs dans les journaux et corrigera rapidement un bug critique dans le produit ? Bien sûr, le même développeur. Il y en a d'autres, mais pour une raison quelconque, lui seul comprend le fonctionnement des différents modules du système.
La racine de ce problème est le manque de documentation. Après tout, si tous les services de votre système étaient décrits, il serait alors possible de résoudre le problème sans faire appel à un analyste. Si Devops prenait quelques jours sur son emploi du temps chargé et décrivait tous les serveurs, services et instructions pour résoudre les problèmes typiques, alors le problème en son absence pourrait être résolu sans lui. Vous n’avez pas besoin de finir rapidement votre bière sur la plage pendant vos vacances et de chercher du Wi-Fi pour résoudre le problème.
Compétence et responsabilité du personnel de soutien
Sur les grands projets, les entreprises ne lésinent pas sur les salaires des développeurs. Ils recherchent des intermédiaires ou des seniors coûteux issus de projets similaires. Avec le soutien, la situation est un peu différente. Ils essaient de réduire ces coûts par tous les moyens possibles. Les entreprises embauchent les travailleurs Enikey d'hier à bas prix et se lancent hardiment dans la bataille. Cette stratégie est possible si nous parlons d'un site Web de cartes de visite d'une usine de Zelenograd.
Si nous parlons d'une grande boutique en ligne, chaque heure d'arrêt coûte plus que le salaire mensuel d'un administrateur Enikey. Prenons comme 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 d'après la notation . Divisez ce montant par le nombre d'heures par an et obtenez plus de 100 000 roubles de pertes nettes. Et si vous ne comptez pas les heures de nuit, vous pouvez doubler le montant en toute sécurité.
Mais l’argent n’est pas l’essentiel, n’est-ce pas ? (non, bien sûr, l'essentiel) Il y a aussi des pertes de réputation. La chute d'une boutique en ligne réputée peut provoquer à la fois une vague de critiques sur les réseaux sociaux et de publications dans les médias thématiques. Et les conversations d'amis dans la cuisine du style « N'achetez rien là-bas, leur site Web est toujours en panne » ne peuvent pas du tout être mesurées.
Passons maintenant à la responsabilité. Dans ma pratique, il y a eu un cas où l'administrateur de service n'a pas répondu à temps à une notification du système de surveillance concernant l'indisponibilité du site. Par un agréable vendredi soir d'été, le site Web d'une boutique en ligne bien connue de Moscou était tranquillement installé. Samedi matin, le chef de produit de ce site n'a pas compris pourquoi le site ne s'ouvrait pas, et il y avait un silence dans les chats d'assistance et de notifications urgentes dans Slack. Une telle erreur nous a coûté une somme à six chiffres, et à cet officier de service son travail.
La responsabilité est une compétence difficile à développer. Soit une personne l'a, soit non. Ainsi, lors des entretiens, j'essaie d'identifier sa présence par diverses questions qui montrent indirectement si une personne est habituée à assumer ses responsabilités. Si une personne répond qu’elle a choisi une université parce que ses parents l’ont dit ou qu’elle change de travail parce que sa femme a dit qu’elle ne gagnait pas assez, alors il vaut mieux ne pas s’impliquer avec de telles personnes.
Interaction avec l'équipe de développement
Lorsque les utilisateurs rencontrent des problèmes simples avec un produit pendant son fonctionnement, le support les résout lui-même. Essaie de reproduire le problème, analyse les journaux, etc. Mais que faire lorsqu’un bug apparaît dans le produit ? Dans ce cas, le support confie la tâche aux développeurs et c'est là que le plaisir commence.
Les développeurs sont constamment surchargés. Ils créent de nouvelles fonctionnalités. Corriger les bugs des ventes n’est pas l’activité la plus intéressante. Les délais approchent pour terminer le prochain sprint. Et puis des personnes désagréables du support viennent dire : « Arrêtez tout immédiatement, nous avons des problèmes. » La priorité de ces tâches est minime. Surtout lorsque le problème n'est pas le plus critique et que la fonctionnalité principale du site fonctionne, et lorsque le gestionnaire de versions ne court pas les yeux exorbités et n'écrit pas : "Ajoutez de toute urgence cette tâche à la prochaine version ou correctif."
Les problèmes de priorité normale ou faible sont déplacés d’une version à l’autre. À la question « Quand la tâche sera-t-elle terminée ? » vous recevrez des réponses du style : « Désolé, il y a beaucoup de tâches en ce moment, demandez aux chefs d’équipe ou au responsable de la version. »
Les problèmes de productivité sont plus prioritaires que la création de nouvelles fonctionnalités. Les mauvaises critiques ne tarderont pas à arriver si les utilisateurs tombent constamment sur des bugs. Une réputation endommagée est difficile à restaurer.
Les problèmes d'interaction entre le développement et le support sont résolus par DevOps. Cette abréviation est souvent utilisée sous la forme d'une personne spécifique qui aide à créer des environnements de test pour le développement, construit des pipelines CICD et met rapidement en production le code testé. DevOps est une approche du développement logiciel dans laquelle tous les participants au processus interagissent étroitement les uns avec les autres et contribuent à créer et mettre à jour rapidement des produits et services logiciels. Je veux dire les analystes, les développeurs, les testeurs et le support.
Dans cette approche, le support et le développement ne sont pas des départements différents avec leurs propres buts et objectifs. Le développement participe à l’exploitation et vice versa. La célèbre phrase des équipes distribuées : « Le problème n'est pas de mon côté » n'apparaît plus si souvent dans les chats et les utilisateurs finaux deviennent un peu plus satisfaits.
Source: habr.com