Bonjour, Habr! Depuis dix ans, je supporte les systèmes informatiques Highload. Je n'écrirai pas dans cet article sur les problèmes de configuration de nginx pour fonctionner en mode 1000+ RPS ou d'autres choses techniques. Je partagerai des observations sur les problèmes dans les processus qui surviennent dans le support et le fonctionnement de tels systèmes.
Suivi
Le support technique n'attend pas qu'une application arrive avec le contenu «
Pourquoi pourquoi ... le site est de nouveau en panne?». Le support une minute après le crash du site 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.
Qu'en est-il de la situation où les restes des marchandises de la boutique en ligne ont cessé de provenir du système ERP? Ou le système CRM qui calcule les remises pour les clients a-t-il cessé de répondre? En même temps, le site fonctionne. Le Zabbix conditionnel obtient sa réponse 200. Le quart de travail n'a reçu aucune notification de surveillance et inspecte joyeusement le premier épisode de la nouvelle saison de Game of Thrones.
Souvent, la surveillance n'est limitée que par la mesure de l'état de la mémoire, de la RAM et de la charge des processeurs de serveur. Mais pour les entreprises, il est beaucoup plus important d'obtenir la disponibilité des marchandises sur le site. Une suppression conditionnelle d'une machine virtuelle dans le cluster entraînera l'arrêt du trafic vers elle et la charge sur les autres serveurs augmentera. 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 métier. 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 les systèmes externes
Tout site Web ou application mobile avec un chiffre d'affaires annuel de plus d'un milliard de roubles interagit avec des systèmes externes. À partir du CRM et de l'ERP susmentionnés et se terminant par le transfert des données de vente vers un système Big Data externe pour analyser les achats et offrir au client le produit qu'il achètera définitivement (en fait, non). Chacun de ces systèmes a son propre support. Et souvent, la communication avec ces systèmes provoque de la douleur. Surtout lorsque le problème est mondial et que vous devez l'analyser dans différents systèmes.
Certains systèmes donnent le téléphone ou le télégramme à leurs administrateurs. Quelque part, vous devez écrire des lettres aux gestionnaires ou aller aux dépisteurs de bogues de ces systèmes externes. Même dans le contexte d'une grande entreprise, différents systèmes fonctionnent souvent dans différents systèmes de comptabilité des applications. Il devient parfois impossible de suivre l'état d'une application. Vous recevez une candidature dans un Jira conditionnel. Ensuite, dans les commentaires de cette première Jira, vous mettez un lien vers la tâche dans une autre Jira. Dans la deuxième Jira de l'application, quelqu'un écrit déjà un commentaire que
vous devez appeler l'administrateur conditionnel Andrei pour résoudre le problème. Et ainsi de suite.
La meilleure solution à ce problème serait de créer un espace de communication unique, par exemple, dans Slack. Invitation à tous les participants au fonctionnement des systèmes externes. Ainsi qu'un seul tracker, pour ne pas dupliquer les applications. Les applications doivent être surveillées en un seul endroit, depuis la surveillance des alertes jusqu'à l'affichage des bogues dans les produits. Vous direz que cela est irréaliste et si historiquement arrivé que nous travaillons dans un tracker, et ils sont dans un autre. Différents systèmes sont apparus, ils avaient leurs propres équipes informatiques autonomes. Je suis d'accord et donc le problème doit ê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 le projet (ou le produit) a une telle personne dont le départ en vacances provoque des crampes aux autorités? 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 conteneurs sont installés sur quels serveurs, comment recharger le conteneur en cas de problème, et en effet tout problème complexe ne peut pas être résolu sans lui. L'analyste est le seul à savoir comment fonctionne votre mécanisme complexe. Quels flux de données vont où. À quels paramètres de demandes à quels services, auxquels nous recevrons des réponses.
Qui comprendra rapidement pourquoi il y a des erreurs dans les journaux et corrigera rapidement un bogue critique dans la prod? Bien sûr, le même développeur. Il y en a d'autres, mais pour une raison quelconque, il comprend comment les divers modules du système sont organisés.
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 possible de résoudre le problème sans analyste. Si devops a sélectionné quelques jours dans son horaire chargé et décrit tous les serveurs, services et instructions pour résoudre les problèmes typiques, un problème en son absence pourrait être résolu sans lui. Pas besoin en vacances de finir rapidement votre bière sur la plage 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 chassent des intermédiaires coûteux ou des personnes âgées de projets similaires. Avec le soutien, la situation est légèrement différente. Ils essaient de toutes les manières possibles de réduire ces coûts. Les entreprises embauchent enikeyshikov à bas prix d'hier et se lancent hardiment dans la bataille. Une telle stratégie est possible lorsqu'il s'agit d'un site de cartes de visite d'une usine à Zelenograd.
Si nous parlons d'une grande boutique en ligne, chaque heure d'indisponibilité coûte plus cher que le salaire mensuel d'un administrateur-enikeik. Prenez pour point de départ 1 milliard de roubles de chiffre d'affaires annuel. Il s'agit du chiffre d'affaires minimum de toute boutique en ligne du
TOP 100 pour 2018 . 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 la chose principale, n'est-ce pas? (non, bien sûr, l'essentiel) Il y a encore des pertes de réputation. L'heure de la chute de la célèbre boutique en ligne peut provoquer à la fois une vague de critiques sur les réseaux sociaux et des publications dans les médias thématiques. Et les conversations d'amis dans la cuisine dans le style "N'achetez rien là-bas, leur site est constamment en panne" ne se prêtent pas du tout à la mesure.
Maintenant responsable. Dans ma pratique, il y a eu un cas où l'administrateur de garde n'a pas répondu à temps pour informer le système de surveillance de l'inaccessibilité du site. Par un agréable vendredi soir d'été, le site d'une boutique en ligne bien connue à Moscou était calme. Samedi matin, le produit de ce site n'a pas compris pourquoi le site ne s'est pas ouvert, et il y a eu un silence dans les chats de support et les alertes urgentes dans Slack. Une telle erreur nous a coûté une somme à six chiffres et cet officier de garde a travaillé.
La responsabilité est une compétence difficile à développer. Une personne l'a ou non. Par conséquent, dans les entretiens, j'essaie d'identifier sa présence avec diverses questions qui montrent indirectement si une personne est habituée à assumer des responsabilités. Si une personne répond qu'elle a choisi une université parce que ses parents l'ont dit ou qu'elle change d'emploi parce que sa femme a dit qu'il ne recevait pas beaucoup, 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 sur le produit pendant le fonctionnement, le support les résout d'eux-mêmes. Il essaie de reproduire le problème, analyse les journaux, etc. Mais que faire quand un bug apparaît sur la prod? Dans ce cas, le support démarre la tâche pour les développeurs, et ici le plaisir commence.
Les développeurs sont constamment surchargés. Ils créent de nouvelles fonctionnalités. Corrigez les bugs avec une leçon de vente, dites pas le plus intéressant. Les délais pour terminer le prochain sprint sont passés. Et puis des gens désagréables viennent du support et disent: "Oubliez tout d'urgence, 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 s'exécute pas avec des yeux exorbités et n'écrit pas: "Urgent pour porter cette tâche vers la prochaine version ou le correctif."
Les tâches avec une priorité normale ou faible vont de version en version. À la question "Quand la tâche sera-t-elle terminée?" Vous recevrez des réponses dans le style de: "Je suis désolé, maintenant il y a beaucoup de tâches, demandez aux chefs d'équipe ou à un responsable de publication."
Les problèmes sur le produit ont une priorité plus élevée que la création de nouvelles fonctionnalités. Les mauvaises critiques ne vous feront pas attendre si les utilisateurs rencontrent constamment des bugs. Il est difficile de restaurer une réputation endommagée.
Les problèmes d'interaction entre le développement et le support sont résolus par DevOps. Cette abréviation est souvent utilisée comme une personne spécifique qui aide à créer des environnements de test pour le développement, crée des pipelines CI \ CD et affiche rapidement le code testé en production. DevOps est une approche du développement logiciel lorsque tous les participants au processus interagissent étroitement les uns avec les autres et aident à créer et à mettre à jour rapidement des produits et services logiciels. Je veux dire analystes, développeurs, testeurs et support.
Le soutien et le développement dans cette approche ne sont pas différents départements avec leurs buts et objectifs. Le développement est impliqué dans le fonctionnement et vice versa. La célèbre phrase des équipes réparties: «Le problème n'est pas de mon côté» n'est pas si souvent vue dans les salles de chat, et les utilisateurs finaux deviennent un peu plus heureux.