ClickCease Minimiser les temps d'arrêt de la base de données

Table des matières

Rejoignez notre populaire bulletin d'information

Rejoignez 4 500+ professionnels de Linux et de l'Open Source !

2 fois par mois. Pas de spam.

Minimiser les temps d'arrêt de la base de données

Le 21 février 2023 - L'équipe de relations publiques de TuxCare

Pour protéger leurs données, les entreprises doivent impérativement veiller à ce que leurs bases de données bénéficient des dernières mises à jour de sécurité. Les systèmes de bases de données non patchés peuvent conduire à des exploits contre les opérations du système central, y compris les applications frontales. Les pirates informatiques exploitent souvent les hôtes, y compris les bases de données, pour en faire des plateformes de lancement de leurs attaques.

C'est pourquoi les organisations donnent la priorité à la correction des vulnérabilités pour se protéger. Cependant, le maintien des correctifs pour les vulnérabilités des bases de données peut impliquer des temps d'arrêt pour appliquer les mises à jour de sécurité, ce qui peut entraîner des interruptions d'activité que personne ne souhaite gérer.

Heureusement, il est possible d'appliquer des correctifs aux bases de données sans mettre les systèmes hors production ou sans avoir à planifier une fenêtre de maintenance. C'est ce qu'on appelle l'application de correctifs en direct. Mais avant d'en parler, examinons de plus près les temps d'arrêt des bases de données.

Pourquoi la disponibilité des bases de données est-elle si importante ?

Les applications d'entreprise, les plateformes orientées client et les analyses de données dépendent fortement des performances, de la disponibilité et de la sécurité des bases de données. Si les données des clients sont exposées à des failles de sécurité ou si la base de données tombe en panne pendant un travail de réplication, cela aura des conséquences sur l'intégrité des données. 

En outre, les problèmes d'intégrité de la base de données peuvent conduire au non-respect des lois sur la conformité et la confidentialité, sans parler de la perte de confiance des consommateurs. Ajoutez à cela les conséquences financières du nettoyage du gâchis qui suit un incident de sécurité de base de données, et toute entreprise pourrait atteindre le point de non-retour. Le coût d'une seule violation de données aux États-Unis en 2022, par exemple, était de 9,44 millions de dollars (IBM).

Les revenus des entreprises reposent sur leurs services d'applications et de bases de données hautes performances et critiques. Ainsi, tout impact sur leurs utilisateurs, leurs partenariats et leur écosystème de chaîne d'approvisionnement en raison de pannes de bases de données ou de violations de la sécurité fera perdre à l'entreprise bien plus que des revenus. 

Quelles sont les causes de l'indisponibilité des bases de données ?

Plusieurs circonstances prévisibles et imprévisibles, y compris des vulnérabilités courantes exploitées par des cybercriminels au sein des réseaux, des bases de données et des applications frontales, pourraient entraîner l'indisponibilité de tout système. 

Les organisations programment souvent une fenêtre de contrôle des changements pour effectuer une maintenance critique de leurs bases de données, des systèmes frontaux correspondants et des réseaux associés. La plupart du temps, un temps d'arrêt imprévu des données peut survenir parce que la mise à niveau a échoué, parce que les administrateurs des opérations secrètes et des bases de données n'ont pas prévu de plan de retour en arrière dans leur plan de maintenance planifiée, ou même parce qu'une catastrophe naturelle s'est produite - notamment des pannes de courant ou des dommages aux installations. 

Temps d'arrêt lié à la maintenance

La mise à niveau de tout système informatique est un processus complexe. Même avec les procédures de contrôle des modifications et de fenêtres de maintenance les plus complètes, une maintenance planifiée pourrait se transformer en une panne inattendue. Lors d'une interruption programmée, si les différents SecOps, DevOps et sysadmins ne parviennent pas à saisir toutes les dépendances, cela pourrait entraîner une interruption inattendue de la production.

Pendant quelles opérations cela peut-il se produire ?

  • Mises à jour des bases de données et du réseau : La mise à jour des bases de données est importante pour les organisations. Il complique la mise à niveau des bases de données et les routines de maintenance du réseau, ce qui expose à des pannes imprévues et à des complications techniques.
  • Entretien de routine : La maintenance des systèmes de bases de données comprend plusieurs étapes de correction et de mise à niveau :
    1. Application de correctifs de sécurité pour les bases de données à code source ouvert
    2. Mise à jour des tables de données et des procédures stockées
    3. Effectuer une réplication des données vers un système de sauvegarde avant d'appliquer les correctifs.

Les systèmes de bases de données se trouvent également au bas de la plupart des piles d'applications au sein d'une organisation, de sorte que tout système, frontal ou dorsal, est inévitablement amené à travailler avec les données contenues dans une base de données, à les compléter ou à les modifier, quelque part. Lorsque cette dépendance est indirecte, il est même possible qu'une panne de base de données entraîne des perturbations dans des systèmes qui, à première vue, pourraient en être déconnectés - par le biais d'une API ou d'une application de passerelle tierce.

La complexité de la mise à jour des bases de données peut entraîner des temps d'arrêt imprévus. Les correctifs des fournisseurs provoquent parfois une corruption imprévue des tables de la base de données ou des procédures stockées, ce qui entraîne des interruptions de service non planifiées. Les ingénieurs en charge des opérations secrètes et des bases de données SQL testent souvent les correctifs des fournisseurs et effectuent les mises à jour sur leurs plates-formes de développement, d'assurance qualité et de test pour s'assurer que le logiciel de mise à niveau fonctionne comme prévu. Souvent, des problèmes qui n'ont pas été détectés par l'assurance qualité font surface sur les systèmes de production, ce qui entraîne des temps d'arrêt imprévus. 

Pour éviter cela, les SysAdmins et les DBAs SQL devraient demander une fenêtre de contrôle des changements, même pour la plus petite routine de maintenance, afin d'éviter tout arrêt de production non planifié.

Tout comme les mises à niveau des bases de données mentionnées ci-dessus, la décision de migrer vers une autre plateforme peut également entraîner des pannes inattendues. La simple migration vers le cloud présente plusieurs risques pour les opérations de base de données, notamment une réplication incomplète des données en raison de la latence imprévisible du réseau. L'échec de la migration de la réplication des données pourrait avoir de graves conséquences pour une organisation qui tente de revenir à un état stable positif pour les opérations des applications et des bases de données.

Qu'en est-il des autres types de temps d'arrêt non planifiés ?

Dans de nombreux cas, l'indisponibilité de la base de données peut résulter d'événements qui échappent encore davantage au contrôle des équipes informatiques/de sécurité :

  • Coupures de courant/catastrophes naturelles: Outre les problèmes inattendus concernant la base de données et d'autres systèmes informatiques pendant une fenêtre de contrôle des changements, les catastrophes naturelles, notamment les tremblements de terre, les inondations et les incendies, peuvent provoquer des coupures de courant et l'accès aux installations essentielles. L'impact et la durée de ces catastrophes naturelles sont difficiles à prévoir.
  • Défaillance du serveur ou du stockage: Les systèmes de base de données s'appuient sur le réseau pour la connectivité, les serveurs hébergeant l'application de base de données et le niveau de stockage pour héberger les fichiers de données réels. Toute défaillance au sein de ces couches peut entraîner une interruption de la production. Les grappes de stockage et les serveurs prennent en charge une conception HA et le basculement. Cependant, les entreprises ne testent souvent ces capacités qu'après la configuration initiale, si un client ou un mandat de sécurité l'exige.
  • L'erreur humaine : Tous les systèmes critiques, y compris les bases de données, les réseaux, les applications et les opérations, sont maintenus par des ingénieurs humains. L'erreur humaine est l'un des principaux facteurs d'exposition d'une organisation aux attaques cybercriminelles. Les erreurs de correction et de configuration conduisent à l'exploitation des vulnérabilités, ce qui peut entraîner une perte de données et l'indisponibilité des systèmes.

Mesure du temps de fonctionnement des bases de données et des systèmes

Les organisations de l'industrie technologique se mesurent souvent à l'aide de l'échelle des "cinq neuf" en fonction des niveaux de temps d'arrêt disponibles et acceptables. Une organisation va promouvoir sa disponibilité à cinq neuf comme un avantage concurrentiel sur son marché respectif. 

En outre, les organisations s'efforceront d'offrir une disponibilité de cinq neuf par le biais d'une gestion complète des correctifs, des opérations de sécurité et des processus globaux de gestion informatique. 

AWS a publié sur son site web un graphique qui présente les niveaux acceptables de temps d'arrêt :

En outre, il ne suffit pas que 0,001 % des temps d'arrêt se produisent, il faut aussi savoir quand une telle panne se produit. Il est très différent qu'une panne survienne en dehors des heures normales de travail ou pendant le pic d'activité des ventes pendant une période de vacances. Et s'il y a une chose que les professionnels de l'informatique ont apprise au fil des ans, c'est que, selon la loi de Murphy, la panne survient toujours au moment le moins attendu et le moins souhaité.

Moderniser la gestion des correctifs pour réduire au minimum les pannes

Les organisations qui souhaitent réduire la complexité des correctifs de sécurité des bases de données et le risque d'erreur humaine ont transformé numériquement leur approche des correctifs de vulnérabilité en adoptant le live patching par le biais de TuxCare. La solution de patching en direct de TuxCare pour les bases de données, appelée DBCare, permet aux équipes de déployer des patches sur les systèmes de bases de données sans avoir besoin de redémarrer ou de programmer des temps d'arrêt - éliminant complètement les pannes liées aux patches.

De plus, DBCare prend en charge MySQL, MariaDB et PostgreSQL, qu'ils se trouvent dans un centre de données sur site ou dans les offres AWS Aurora ou Relational Database Services (RDS).

Un autre composant critique du live patching de TuxCare est le support de l'automatisation complète et le support d'une option de déploiement air-gap en boucle fermée. Notre technologie de patching en direct fournit les mises à jour de sécurité les plus récentes tout en ne nécessitant qu'une interaction humaine minimale, ce qui permet de réduire les erreurs et l'exposition aux vulnérabilités.

TuxCare offre également des correctifs en direct pour les bibliothèques partagées, les environnements de machines virtuelles, les dispositifs IoT et toutes les distributions Linux d'entreprise populaires - contrairement à de nombreuses alternatives de correctifs en direct qui ne sont fonctionnelles que pour une seule ou quelques distributions.

Programmez une conversation avec l'un de nos experts pour obtenir une explication personnalisée sur le fonctionnement de l'automatisation des correctifs en direct de TuxCare.

Résumé
Minimiser les temps d'arrêt de la base de données
Nom de l'article
Minimiser les temps d'arrêt de la base de données
Description
Il est possible de maintenir les bases de données à jour sans avoir à programmer une fenêtre de maintenance. Mais, avant, plongeons dans les temps d'arrêt des bases de données.
Auteur
Nom de l'éditeur
TuxCare
Logo de l'éditeur

Vous cherchez à automatiser la correction des vulnérabilités sans redémarrage du noyau, temps d'arrêt du système ou fenêtres de maintenance programmées ?

Découvrez le Live Patching avec TuxCare

Devenez rédacteur invité de TuxCare

Commencer

Courrier

Rejoindre

4,500

Professionnels de Linux et de l'Open Source
!

S'abonner à
notre lettre d'information