Le facteur temps - la rapidité d'exécution des commandes, du travail, des accords - est important dans les affaires. Les clients et les partenaires s'attendent à une collaboration longue et prévisible. Dans une entreprise traditionnelle, cela est influencé par le travail des employés, les actions des fournisseurs, la situation géographique de l'entreprise, l'état des équipements, etc. Localiser et contrôler tout cela est une tâche difficile.
Tout est un peu plus clair dans le domaine informatique. Une partie importante des processus peut être automatisée et confiée à un programme ou un script. Encore mieux, si le produit est implémenté en tant que service Web - la principale leçon est de soutenir la disponibilité et le développement du produit.
L'un des principaux produits de notre société est un service Web. Tout a commencé avec la mise en œuvre de l'idée de deux personnes, puis l'entreprise a grandi: PM (il est également programmeur Web), programmeur de base de données, administrateur système (avec peu d'expérience en développement), testeur et deux autres personnes impliquées dans les ventes et le référencement. Le système est mis en œuvre en tant qu'interface Web et base de données associée. L'utilisation du service implique le dépôt et le retrait d'argent stocké dans une "monnaie virtuelle". Pour des raisons de sécurité, le serveur Web et la base de données sont déployés sur leurs serveurs.
Étant donné que le service est lié à l'argent, le niveau de confiance des utilisateurs dans le système est important. Tout d'abord, c'est une question de sécurité et de protection du système contre le piratage. Cependant, il est difficile pour un client ordinaire (surtout pas versé dans les subtilités de l'informatique, des protocoles sécurisés et du cryptage) d'évaluer le niveau de sécurité du système. Si une situation négative (piratage) ne s'est pas produite, le travail n'est pas visible.
L'accessibilité du système est plus évidente pour le client: si l'utilisateur a transféré un certain montant sur le compte virtuel et ne peut pas se connecter plusieurs fois au site, la crédibilité du système est compromise et le client est probablement perdu (parfois plusieurs à la fois - le négatif se propage rapidement). Et les utilisateurs impliqués avec beaucoup de difficulté, rencontrant une erreur au lieu de la page principale du site, sont peu susceptibles de revenir non plus.
Comprendre la gravité de cette situation n'est pas venu immédiatement. Au début, le nombre d'utilisateurs était faible, les capacités du serveur et du canal étaient abondantes, et donc les «plantages» étaient rares. De plus, la fonctionnalité était souvent testée et affinée dans un premier temps dans un souci d'optimisation, et le développeur lui-même était responsable de la surveillance des serveurs associés au service pendant les heures de travail. Le nombre d'utilisateurs pendant les heures creuses était relativement faible - les clients d'autres fuseaux horaires étaient alors pratiquement absents.
Progressivement, l'essentiel du service a été achevé. Les améliorations sont devenues minimes et, par conséquent, l'attention principale des développeurs a été transférée vers un autre projet. La responsabilité du contrôle du système a été déléguée à l'administrateur du système, en plus de ses autres responsabilités. Des notifications ont été envoyées par e-mail et SMS à l'administrateur en cas de panne du serveur. De telles mesures à l'époque semblaient suffisantes.
Le produit a commencé à prendre de l'ampleur et le nombre d'utilisateurs a augmenté. De nouvelles idées ont surgi, certaines ont été mises en œuvre immédiatement, certaines ont été reportées à l'avenir. Le service a été traduit dans d'autres langues et a progressivement pénétré de nouveaux marchés, ce qui a notamment entraîné une augmentation du nombre d'utilisateurs la nuit. La charge du serveur augmentait progressivement, bien qu'elle soit encore loin de la limite technique du fer.
Une fois le calme terminé. Dans la nuit de vendredi à samedi, les utilisateurs ont commencé à rencontrer des problèmes d'accès à la page principale du site, ils ont souvent été rencontrés par l'erreur 503. Le problème était simple, mais, comme il se doit, l'administrateur n'était pas disponible vendredi soir, et donc le SMS est resté non lu. Néanmoins, le problème a été résolu relativement sans douleur. Le développeur a également reçu un SMS et a pu communiquer avec l'administrateur et le réveiller, et après 3 heures, le problème a été résolu. Le «temps d'arrêt» total était de 5 heures.
Lundi, il y a eu un compte rendu de ce qui s'est passé. L'analyse des données de trafic du site a montré une image désagréable - un vendredi "problématique", le trafic a diminué d'un tiers par rapport à l'année dernière, mais les baisses importantes samedi et dimanche étaient encore plus désagréables, malgré l'absence de problèmes techniques ces jours-ci, le trafic a chuté de 15%.
Cela a renforcé la compréhension de la nécessité d'une surveillance 24h / 24. Du point de vue logiciel, nous avons choisi
Zabbix , qui devait être installé et configuré par l'administrateur système. Cela a pris environ une semaine - le reste des tâches n'a pas abouti et tout s'est fait en parallèle. Il y avait une question d'organisation - qui surveillera exactement?
Au début, je devais prendre une telle décision - déplacer les heures de travail des employés existants (de ceux qui comprenaient cela - c'est-à-dire l'administrateur système et le développeur) afin que, un par un, quelqu'un contrôle le serveur la nuit.
Cette décision a été forcée et n'a pas duré longtemps. Premièrement, le travail de deux personnes ne fournit toujours pas de contrôle 24h / 24 - il y a des intervalles de temps dans lesquels une défaillance est également probable. Deuxièmement, peu de gens aiment travailler la nuit, et l'insatisfaction a augmenté, de plus, la distraction du programmeur a presque stoppé le développement lui-même. Par conséquent, après une semaine, ils ont abandonné l'idée et ont commencé à réfléchir davantage.
Embauche de personnel supplémentaire pour surveillerBien sûr, une telle décision est la plus intransigeante - le contrôle constant des personnes sélectionnées donne un bon résultat. Mais travailler dans ce mode nécessiterait une recherche de 3 administrateurs système supplémentaires. De plus, ils devraient être suffisamment qualifiés pour résoudre les problèmes, mais la plupart de leur temps serait de toute façon perdu - la société est petite, il y a peu de serveurs et il n'y aurait presque rien pour les occuper. En outre, de nombreuses personnes doivent également être contrôlées, ce qui serait un mal de tête supplémentaire.
Les deux options n'ont pas fonctionné. Il n'a pas été possible de concentrer les efforts et les moyens sur eux. Mais le besoin de surveillance n'a pas disparu. C'est l'un des problèmes de croissance - il y a un besoin qui ne peut être réalisé par nous-mêmes. Une solution est venue d'externaliser.
Pendant la transition, des doutes ont surgi, le principal étant la sécurité et la confidentialité des informations mises à la disposition de quelqu'un d'autre et la qualité du service, ne va-t-elle pas empirer, au contraire? Mais il s'agit plutôt de trouver un exécutif responsable et de signer le NDA.
Du coup, on est passé du côté technique ça n'a pas été difficile. Un mois plus tard, nous avons décidé de vérifier comment les choses se passaient - en vérifiant les journaux sur les serveurs. Nous sommes satisfaits des résultats - au cours du mois, il y a eu trois graves pannes qui pourraient potentiellement «remettre» le serveur, mais les partenaires ont résolu les problèmes en une demi-heure. De plus, tous les échecs se sont produits dans l'intervalle allant d'une heure du matin à quatre heures du matin - une croissance géographique progressive du produit affecté.
Le travail de notre administrateur système a changé et s'est assoupli. Sans être distrait par la surveillance, il s'est concentré sur DevOps. Nous avons concentré nos efforts et le développement s'est accéléré. Il s'est avéré réaliser ce qui avait été reporté depuis longtemps, grâce à notre
partenaire .