Pourquoi on ne peut pas l’utiliser pour éteindre un incendie maintenant
Déformation professionnelle : quand le travail forme de mauvaises habitudes
J’ai déjà écrit que dans le domaine de l’informatique, avec des centaines de commutations par jour, ce ne sont pas les habitudes domestiques qui déterminent notre approche du travail, mais au contraire, le travail nous forme à la réactivité immédiate face aux problèmes, souvent sans analyse suffisante des conséquences.
J’ai trouvé pour vous plusieurs exemples de comment les gens succombent au plaisir du résultat immédiat, à l’exemple de l’achat impulsif. Malheureux, au moment du clic, ils pensaient que l’achat en un seul clic était la seule étape vers la résolution du problème.
Qui a fait cela ?Imaginez cela : les CTO et les PM des grandes entreprises agissent exactement de la même manière. Ils commandent à leurs équipes DevOps une « solution à la hâte ». En recevant enfin la « boîte » tant attendue avec les dernières technologies (Apache Kafka, stockage objet S3, base de données partitionnée, recherche sémantique), ils ne découvrent même pas la mauvaise nouvelle : le produit ne vient pas avec d’instructions d’installation, de configuration ou d’utilisation. Il n’y a pas de scripts de déploiement, ni de possibilités de scaling, de monitoring de la performance. Et surtout — personne n’a prévenu l’équipe DevOps que ces technologies allaient être intégrées.
Trois mois après la commande, au lieu d’un soulagement attendu, le responsable se retrouve face à un nouveau cercle de problèmes. Son dépit peut être exprimé ainsi : « La boîte est arrivée… mais après trois mois de livraison, j’ai oublié pourquoi j’avais commandé. » La quête de victoires rapides se transforme en chaos opérationnel, tandis que l’absence de planification stratégique transforme les technologies en sources d’infinites difficultés.## Nous avons besoin de Kafka pour la prochaine version
Quelqu’un des tech leads a lu un article sur Habr concernant « la transmission en temps réel des événements en flux », a hoché la tête et a déclaré que nous avons besoin de Kafka. Sans appel à des propositions. Sans revue de l’architecture. Sans participation des DevOps. Reconnaissable ?
Oui, Kafka est open source. Oui, elle est scalable. Mais demandez à toute équipe qui l’a exploitée dans des clusters : la maturité de Kafka n’est pas linéaire — c’est une fonction en escalier.
- 0–6 mois : « Tout fonctionne ! » — Équilibre caché des partitions, charge inégale sur les brokers, latence incontrôlée
- 6–12 mois : « Pourquoi les latences augmentent-elles ? » — Répartition manuelle, éteindre les incendies, responsabilité fragmentée
- 12+ mois : « Qui est responsable de cela ? Comment pouvons-nous même l’éteindre ? » — « Naissance des zombies » avec des coûts non prévus pour un support externe
Sans automatisation, observabilité et gestion du cycle de vie de toute l’écosystème Kafka, Kafka ne fournit pas des flux de données, mais des flux d’alertes dans Telegram.## Stockage compatible S3 ? Parfait. Protégez-le maintenant
L’équipe Ozon a passé des mois à reconfigurer Lusca sur un stockage compatible S3 — pas parce que S3 est complexe, mais parce que la mise en œuvre d’une forte cohérence au-dessus d’une architecture événementielle, la gestion des processus en arrière-plan de la base de données, et la restauration de teraoctets de données — ce sont des tâches exigeant une expertise approfondie et du temps.
Même pire : si vous déployez cela dans des conteneurs sans hygiène DevSecOps — sans scanner les images, sans stockage des secrets, sans politiques de réseau L7 — vous ne créerez pas un stockage. Vous créerez un vecteur de vulnérabilité et un défaut technique.Incendie.
Sharding de la base de données : point de non-retour
On shard uniquement après avoir épuisé le scaling vertical, l’optimisation des requêtes, les niveaux de caching et les réplicas pour la lecture. C’est la dernière option.
Faire cela de façon incorrecte entraînera des « shards chauds », des retards de réplication et des échecs de requêtes entre shards. Surtout si la clé de sharding est choisie de manière inappropriée. Faire cela sans outils DevOps pour le backup, le monitoring et la redistribution — on échangera l’évolutivité contre la résilience.
Le principe est que nous ne pourrons pas « dés-sharder ». Une fois que cette solution est mise en œuvre, on ne peut pas en sortir sans un véritable cauchemar.
Et maintenant, le vrai problème — pas technique, mais organisationnel
Aucun benchmark ne dira que le point le plus faible dans un DevOps moderne n’est pas les ressources intellectuelles, la mémoire ou la vitesse d’exécution des opérations. Parce que c’est — le délai dans la prise de décision causé par les problèmes de roadmap.Dans certaines entreprises, il n’existe pas de roadmap DevOps, voire aucune stratégie du tout, car la stratégie est confiée aux démonstrations de solutions « sur le terrain ».
À quoi conduit une culture d’exécution réactive ?
- Après que le CTO ait signé l’ordre de développement, les ingénieurs reçoivent non pas de spécifications, mais un simple « Automatisez cela sur 100 serveurs » — sans documentation, sans architecture claire, sans couverture de tests.
- Et trois mois plus tard : « Pourquoi est-ce si lent ? Et pourquoi avons-nous même construit cela ? »
Ceci n’est pas du leadership, c’est une évitement de la responsabilité.
Les équipes DevOps dans les organisations réactives consomment leur énergie, poursuivant des fantômes dans les logs et les graphiques, corrigant ce qu’ils n’ont jamais conçu, et défendant ce qu’ils n’ont jamais possédé.Et quand quelque chose casse ? La faute incombe aux personnes, pas aux processus. Ce n’est pas DevOps, c’est une équipe de voyants, YasnoOps. Une culture DevOps mature ne demande pas qui a fait erreur. Elle demande ce qui a causé la panne et corrige le système, pas en cherchant le coupable. Dans votre cas, le système, c’est l’absence de roadmap et l’absence d’implication des DevOps lors de la prise de décision.
Contexte russe : vitesse contre stabilité
Entre 2023 et 2024, le marché SaaS en Russie a atteint plusieurs trillions de roubles, mais ce n’est pas un marché stable et prévisible, c’est une « casserole à haute pression ». La course à paraître moderne détruit les fondations nécessaires pour être vraiment moderne.Nous devrions, en théorie, avancer dans la direction définie par GOSTech. Vers le logging unifié, les API certifiées, le monitoring, les exigences de la FSIT et l’intégrité de la chaîne d’approvisionnement. Mais comment intégrer ces standards dans une architecture construite en hâte et fondée sur des décisions impulsives ? Comment garantir la sécurité si les équipes DevOps n’ont pas été impliquées dans la conception ?
Cette entreprise continue de considérer l’infrastructure comme une question secondaire. Ce n’est pas un échec d’ingénierie. C’est un échec de gestion des attentes.
Comment changer la situation ?
La solution réside dans un changement de posture :
- De « Construisons cela maintenant pour la vente » → « Sommes-nous prêts à posséder cela dans un avenir proche ? »
- De la vitesse d’intégration des fonctionnalités → à la résilience de la plateforme
- De DevOps comme équipe de secours → à DevOps comme co-architecteLes grandes entreprises ont parcouru ce chemin. Elles publient leurs roadmaps. Elles reportent les lancements pour garantir la stabilité. Elles mesurent la maturité opérationnelle, et non seulement les dates de livraison.
Elles comprennent la simple vérité : la vitesse sans contrôle n’est pas de la flexibilité, c’est un dérive. Et cela est particulièrement inacceptable dans les logiciels corporatifs, où sont en jeu des secrets d’État.
Pour sortir de la crise, il faut un changement
- De la gestion réactive à la planification proactive – élaboration d’une roadmap DevOps, implication de toutes les parties prenantes dès les premières étapes.
- Des exécutants vers des partenaires stratégiques – reconnaissance du DevOps comme une composante incontournable du développement produit.
- De déploiements chaotiques vers une transformation structurée – mise en œuvre progressive des technologies avec pilotage et identification itérative des lacunes.
- Et alors, le bouton « Acheter » ne sera plus cliqué automatiquement
Car, dans les réalités contemporaines, surtout dans le contexte de GosTech, ignorer la maturité opérationnelle n’est pas seulement un risque, mais une erreur stratégique.