Les administrateurs de bases de données, un sacerdoce n'en sont plus

Remarque : ce billet d'ingénierie a été écrit par notre DBA, Silvia Botros et a été initialement publié sur le blog Sysadvent en décembre 2016.

Les entreprises ont eu et avaient besoin d'administrateurs de bases de données pendant des années. Les données sont l'un des actifs les plus importants d'une entreprise. Cela signifie que de nombreuses entreprises, une fois qu'elles ont atteint le point où elles doivent pouvoir évoluer rapidement, ont besoin de quelqu'un pour s'assurer que l'actif est bien géré, performant pour les besoins du produit et disponible pour être restauré en cas de sinistre.

Dans un sens traditionnel, le travail du DBA signifie qu'elle est la seule personne ayant accès aux serveurs qui hébergent les données, la personne de référence pour créer un nouveau cluster de bases de données pour les nouvelles fonctionnalités, la personne pour concevoir de nouveaux schémas et la seule personne à contacter en cas de problème lié à la base de données dans un environnement de production.

Étant donné que les administrateurs de base de données ont traditionnellement des rôles uniques, leur temps est compté, il devient plus difficile d'avoir une vue d'ensemble lorsque les tâches quotidiennes sont accablantes. Il est courant de recourir à des outils fragiles comme bash pour toutes sortes de tâches opérationnelles dans le domaine DBA. Besoin d'une nouvelle configuration de base de données à partir d'une installation propre du système d'exploitation ? Prendre, valider ou restaurer des sauvegardes ? Faire pivoter des partitions ou des données obsolètes ? Lorsque votre outil le plus couramment utilisé est le script bash, tout ressemble à un clou. Je suis sûr que de nombreux lecteurs préparent des tweets pour me dire à quel point bash est puissant, mais veuillez conserver votre commentaire jusqu'à ce que j'aie évalué mon raisonnement.

Tout cela ressemble-t-il à votre description de poste en tant que DBA ? La description du poste parle-t-elle en détail de la mise à niveau des serveurs, de la création et du test des sauvegardes et de la surveillance ? La plupart des offres d'emploi DBA typiques s'assureront de dire que vous devez configurer et configurer des serveurs de base de données "multiples" (car on s'attend à ce que les DBA les fabriquent à la main) et automatiser les tâches de gestion de base de données avec des scripts (fabriqués à la main).

S'agit-il vraiment d'une approche évolutive pour ce qui est souvent une équipe d'une seule personne dans une organisation en pleine croissance et au rythme rapide ?

Je suis ici pour affirmer que votre travail n'est pas d'effectuer et de gérer des sauvegardes, de créer et de gérer des bases de données ou d'optimiser des requêtes. Vous ferez toutes ces choses dans le cadre de votre travail, mais l'objectif principal est de rendre les données de votre entreprise accessibles et évolutives. Il ne s'agit pas seulement pour l'entreprise d'exécuter le produit actuel, mais aussi de créer de nouvelles fonctionnalités et d'apporter de la valeur aux clients.

Pourquoi

Vous voudrez peut-être demander, pourquoi ferais-je tout cela? Il existe un argument en faveur de la poursuite de l'exécution traditionnelle du rôle de DBA : la sécurité de l'emploi, n'est-ce pas ? De nos jours, de nombreuses organisations technologiques effectuent une ou plusieurs des actions suivantes :

• Ils sont formés de nombreuses petites équipes
• Ils fournissent des fonctionnalités en créant de nombreux micro-services à la place d'un ou de quelques services plus importants
• Ils adoptent des méthodologies agiles pour accélérer la livraison des fonctionnalités
• Ils combinent les opérations et l'ingénierie sous une même direction
• Ils intègrent les ingénieurs d'exploitation aux développeurs le plus tôt possible dans le processus de conception
• Un silo DBA au sein des opérations signifie que l'équipe des opérations est moins habilitée à aider à déboguer les problèmes de production dans sa propre pile, est parfois incapable de répondre et de résoudre les problèmes sans assistance, et franchement moins crédible pour exiger des collaborations plus étroites et plus précoces avec les équipes d'ingénierie si elles ne le sont pas. ne pratiquent pas ce qu'ils prêchent à l'intérieur de Tech Ops.

Alors, que peut-on faire pour briser ce silo et faciliter le débogage pour d'autres personnes, aider à faire évoluer la couche de base de données et donner aux ingénieurs les moyens de concevoir des services qui peuvent évoluer ? La plupart des magasins émergents ont au plus un DBA interne. Le seul administrateur de base de données peut-il être « présent » dans toutes les réunions de conception, approuver chaque modification de schéma et être disponible pour une empreinte de base de données tentaculaire et sans cesse croissante ?

Les DBA ne peuvent plus être des gardiens ou des magiciens. Un DBA peut et doit être une source de connaissances et d'expertise pour les ingénieurs d'une organisation. Elle doit aider les équipes de livraison non seulement à fournir des fonctionnalités, mais à fournir des produits qui évoluent et leur permettent de ne pas craindre la base de données. Mais comment un administrateur de base de données peut-il y parvenir tout en gérant au quotidien la couche de données ? Il existe un certain nombre de façons dont vous, le DBA, pouvez vous préparer à l'excellence.

Gestion de la configuration

C'est très important. Les DBA ont tendance à préférer les outils de la vieille école comme bash pour la configuration de la base de données. J'y ai fait allusion plus tôt et je n'ai rien contre l'utilisation de bash lui-même. Je l'utilise beaucoup, en fait. Mais ce n'est pas le bon outil pour la configuration du cluster. Surtout si le reste des opérations n'utilise PAS Bash pour gérer le reste de l'architecture. Il est vrai que les ingénieurs d'exploitation connaissent aussi Bash, mais s'ils gèrent le reste de l'infrastructure avec un outil comme Chef ou Puppet et que les bases de données sont principalement gérées par des scripts écrits à la main par le DBA, vous leur imposez un obstacle pour fournir aide lorsqu'un changement urgent est nécessaire.

Plus encore, il devient plus difficile d'aider les équipes d'ingénierie à se servir elles-mêmes et à s'approprier la création des nouveaux clusters dont elles ont besoin pour la nouvelle fonctionnalité « foo ». Vous devenez le « bloqueur » pour terminer le travail. Se familiariser avec la gestion de la configuration dans votre entreprise est également un avantage à double sens. Au fur et à mesure que vous vous familiarisez avec la gestion de l'infrastructure, vous apprenez à connaître les normes de l'équipe, vous vous familiarisez avec la pile et êtes en mesure de collaborer sur les changements qui affectent finalement l'échelle du produit.

Un DBA qui est à l'écoute du produit et de l'infrastructure de l'organisation d'ingénierie dans son ensemble est inestimable.

Runbooks

Ceci est techniquement un sous-ensemble de la documentation que vous devez écrire, mais d'après mon expérience, il s'est avéré beaucoup plus utile que je pense qu'il doit être signalé séparément. Quand je dis runbooks, je dis spécifiquement un document écrit pour un public qui n'est PAS un DBA. Il existe de nombreux problèmes de base de données de production que nous pouvons rencontrer en tant que DBA qui sont simples à déboguer et à résoudre. Nous avons tendance à sous-estimer cette mémoire musculaire et nous tombons dans le schéma du « envoyez-moi simplement la page » et nous « nous occupons des choses ».

Si votre équipe d'exploitation est comme la mienne où vous êtes le seul administrateur de base de données, cela signifie probablement qu'un autre membre de l'équipe est la première ligne de défense lorsqu'un événement lié à la base de données s'affiche. Une documentation simple sur la façon d'effectuer le débogage initial, la collecte de données, peut grandement contribuer à rendre le reste de l'équipe des opérations à l'aise avec la couche de base de données et plus familier avec la façon dont nous la surveillons et la déboguons. Même si cet événement entraîne toujours la pagination du DBA, lentement mais sûrement, le runbook devient un endroit où tout le monde peut ajouter les connaissances acquises.

De plus, j'ajoute un lien vers la section runbook associée (utilisez des ancres !) aux descriptions de page qui vont au téléavertisseur. Ceci est extrêmement utile pour quelqu'un qui est appelé par un hôte de base de données à 3 heures du matin pour trouver un point de départ. Ces choses peuvent sembler petites, mais d'après mon expérience, elles ont largement contribué à briser les barrières mentales pour mon équipe d'exploitation travaillant sur la couche de base de données lorsque cela était nécessaire.

Par préférence personnelle, je les écris sous forme de documents de démarquage dans mes référentiels de livres de cuisine de chef. Cela s'inscrit parfaitement dans un modèle de demande d'extraction, de révision et de fusion, et devient une partie intégrante du modèle de livres de recettes des bases de données. Au fur et à mesure que les équipes d'ingénierie commencent à créer les leurs, les runbooks deviennent un modèle familier à mesure que de nouveaux clusters de bases de données apparaissent partout.

Visibilité

Nous aimons nos écrans de terminaux. Nous les aimons. Les outils les plus populaires dans MySQL Land sont toujours des outils terminaux qui vivent directement sur les hôtes de la base de données et qui nécessitent une connaissance préalable de ceux-ci et de leur utilisation. Je parle de choses comme innotop et le shell MySQL. Celles-ci sont correctes et toujours utiles, mais elles sont créées pour les administrateurs de base de données. Si vous ne voulez pas être le gardien de questions telles que "y a-t-il un décalage de réplication en ce moment ?" vous devez disposer de meilleurs outils pour rendre la santé de tout cluster, actuelle et historique, disponible et facile à digérer pour tous les membres de l'équipe. J'ai quelques exemples dans ce domaine :

Orchestrateur

Nous utilisons des réplicas en lecture pour répartir cette charge loin du principal, ce qui signifie qu'une fois que le décalage atteint un certain seuil, il devient un événement de support client. Il est important de permettre à tous les membres de l'entreprise de savoir plus facilement à tout moment si un cluster connaît un décalage, quels sont les serveurs de ce cluster et si l'un des hôtes est tombé en panne. Orchestrator est un excellent outil à cet égard, car il permet de visualiser les clusters et leur santé à une fenêtre de navigateur.

Grafana/Graphite

Les métriques de la couche DB doivent vivre au même endroit que les métriques du reste de l'infrastructure. Il est important pour l'équipe de pouvoir juxtaposer ces métriques côte à côte. Et il est important d'avoir un moyen simple de voir les métriques historiques pour n'importe quel cluster de bases de données. Bien que vous puissiez avoir une préférence personnelle pour les cactus ou le munin, ou les modèles artisanaux que vous avez écrits au fil des ans, si les métriques que vous utilisez pour enquêter sur les problèmes ne sont pas au même endroit que le reste des métriques d'infrastructure, cela crée une barrière pour d'autres ingénieurs occupés - et ils seront moins enclins à utiliser votre outillage plutôt que celui qui est utilisé ailleurs. Graphite est largement utilisé pour ingérer des métriques dans les équipes d'infrastructure modernes, et Grafana est un frontal de tableau de bord largement utilisé pour les métriques et les analyses.

Performances des requêtes

Nous utilisons VividCortex pour suivre nos requêtes sur des clusters critiques et bien que cet article ne soit pas censé être une publicité pour un service payant, je dirai que vous devez permettre d'inspecter l'effet des déploiements et des modifications de code sur l'exécution des requêtes et performances de requête quelque chose qui n'a pas besoin d'un accès spécial aux journaux et de les analyser manuellement. Si VividCortex n'est pas une possibilité (même si, sérieusement, ils sont géniaux !), il existe d'autres produits et outils open source qui peuvent capturer même le journal lent et le mettre dans une page Web facile à lire pour que les non-DBA puissent l'inspecter. et voir l'effet de leur code. Le point important ici est que si vous fournissez les moyens de voir les données, les ingénieurs utiliseront ces données et feront de leur mieux pour que les choses restent efficaces. Mais rendre cet accès disponible fait partie de votre travail et non une astuce DBA spéciale.

Combattez la fatigue des téléavertisseurs

De nombreuses organisations n'intègrent pas la mise à l'échelle de la couche de base de données comme un impératif très précoce dans la conception de leur pile, et elles ne le devraient pas. Au début d'une entreprise, vous ne devriez pas vous soucier de la façon dont vous limiterez les appels d'API si personne n'utilise encore l'API. Mais il convient de considérer quelques années plus tard, lorsque le produit a gagné du terrain, et que cet appel API qui atteignait une table de quelques milliers de lignes par une poignée de clients est maintenant une table de plusieurs millions de lignes, et quelques clients ont créé des tâches cron qui inondent cette API tous les matins à 6 heures du matin dans votre fuseau horaire.

Il faut beaucoup de travail pour changer la couche d'application de n'importe quel produit afin de protéger l'infrastructure et, dans l'intervalle, permettre à une activité de base de données intempestive d'entraîner une fatigue du téléavertisseur est un grand danger pour vous et le reste de l'organisation des opérations. Familiarisez-vous avec des outils tels que pt-kill qui peuvent être utilisés en un clin d'œil pour empêcher un hôte de base de données d'avoir des temps d'arrêt majeurs en raison d'un volume imprévu. Faites connaître l'utilisation de cet outil et communiquez l'action et ses effets à l'équipe d'ingénierie de la participation, mais il est malsain d'essayer d'absorber la douleur de quelque chose que vous ne pouvez pas changer directement et cela ne sera finalement pas bénéfique pour aider les équipes d'ingénierie ' apprendre à gérer les douleurs de croissance.

Le travail d'un DBA est unique à bien des égards par rapport au reste de l'équipe des opérations, mais cela ne signifie pas qu'il doit s'agir d'un sacerdoce magique que personne ne peut approcher. Ces étapes contribuent grandement à rendre votre travail transparent, mais le plus important est d'aborder votre travail non pas en tant que gardien d'un jardin d'or d'hébergeur de bases de données, mais en tant qu'expert en la matière qui peut fournir des conseils et aider à développer les ingénieurs avec lesquels vous travaillez et fournir plus valeur pour l'entreprise que les sauvegardes et le réglage des requêtes (mais ceux-ci sont amusants aussi !).

Un merci spécial à la merveilleuse équipe des opérations de Sendgrid qui continue de m'apprendre beaucoup de choses, et à Charity Majors pour avoir inventé le titre de ce post. Et consultez plus d'articles sur les administrateurs de base de données ici.