INFRASTRUCTURE POUR L'APPLICATION
Environnement clair.
Restauration vérifiée
Nous concevons et configurons l'infrastructure pour l'application : hébergement, conteneurs, publication des changements, surveillance et sauvegardes. Nous convenons du coût des ressources et vérifions le scénario de restauration.
TÂCHE
SCÉNARIO
DONNÉES
VÉRIFICATION
LANCEMENT
TRANSFERT
au lancement et à la transmission
PLACEMENT
PUBLICATION
RESTAURATION
réalisés
du studio
modèles
Premier Partner
marketing, analytique
Architecture pour exigences du projet
D'abord, nous analysons l'application, les données et l'interruption de travail admissible. Nous déterminons quels composants sont critiques, où ils peuvent être placés et quel budget d'exploitation est disponible. Chaque projet n'a pas besoin d'un cluster ou de Kubernetes.
Nous décrivons l'environnement et la procédure de publication des modifications : build, vérifications, gestion de la configuration et des secrets. Si l'architecture le permet, nous séparons les environnements de test et de production et préparons une procédure de retour à la version précédente.
Pour la restauration, nous définissons une perte de données acceptable et un temps de retour au service cible. Nous configurons la copie vers un stockage externe et vérifions la restauration. La réplication aide à la disponibilité, mais ne remplace pas une sauvegarde indépendante.
- Schéma des composants et estimation des coûts des ressources
- Environnement et configuration reproductibles
- Pipeline de sortie avec vérifications et retour
- Sauvegardes externes et vérification de la restauration
- Métriques, notifications et manuels d'utilisation
Environnement
Versions et configuration décrites
Publication
Chaque modification a des vérifications et un chemin de retour
Copies
Il existe une source de restauration indépendante
Observation
La panne est liée à une notification claire
La tolérance aux pannes est vérifiée par scénario
La présence de plusieurs serveurs ne garantit pas la disponibilité. Nous vérifions la défaillance d'un composant, le basculement et la restauration selon un plan convenu ; les objectifs et les résultats réels sont présentés séparément.
L'infrastructure, qui peut être accompagné
La complexité de l'architecture doit correspondre aux exigences et aux capacités de l'équipe.
Configuration répétable
Nous décrivons les versions, les paramètres et les ressources. Nous utilisons des conteneurs et du code d'infrastructure là où ils simplifient le déploiement et le contrôle des modifications.
Version vérifiée
Nous convenons des contrôles de préparation et de la procédure de basculement. Les migrations de données nécessitent un plan distinct : le retour à l'ancien conteneur ne restaure pas toujours l'ancien schéma de base.
Restauration et coût
Nous comptons non seulement les serveurs, mais aussi le stockage, le trafic, les journaux et la réserve. La fréquence des copies et le temps de récupération sont vérifiés par rapport aux exigences métier.
Selon les exigences vers un environnement de travail
Avant l'achat des ressources, nous fixons les limites, les objectifs de récupération et le budget.
Audit d'application
Nous collectons les dépendances, les données, le profil de charge et l'infrastructure actuelle. Nous vérifions les exigences de placement et d'accès.
Schéma et budget
Nous choisissons la composition des composants et la redondance. Nous évaluons les dépenses régulières et convenons des objectifs de restauration.
Préparation de l'environnement
Nous décrivons la configuration, les rôles et les secrets. Nous configurons les serveurs ou les services gérés dans le volume choisi.
Pipeline de sortie
Nous ajoutons l'assemblage, les tests et le basculement de version validé. Pour la base de données, nous définissons une procédure de migration séparée.
Copies et surveillance
Nous configurons le stockage, les délais de conservation, les métriques et les routes de notification. Nous vérifions l'accès aux sauvegardes.
Vérification et transfert
Nous effectuons le scénario convenu de restauration et de publication. Nous transmettons le schéma, les instructions, les accès au propriétaire et le plan de support.
Déploiement, configuration et surveillance
Le stack est choisi en fonction de l'application, de la charge et des conditions d'exploitation.
Conteneurs
Docker et Compose pour les projets appropriés. Nous envisageons un orchestrateur lorsque les exigences justifient sa complexité.
Configuration en tant que code
Ansible ou Terraform dans le volume convenu. L'état, les accès et les secrets nécessitent un stockage sécurisé distinct.
Métriques et copies
Prometheus, Grafana ou services disponibles du fournisseur. Nous vérifions les notifications et confirmons la sauvegarde par restauration.
— COÛT
Tarifs
sur l'architecture cloud
D'un serveur unique à une infrastructure distribuée. Nous choisissons le niveau de redondance selon les besoins du projet.
| Composition des travaux | VPS/VDS Start Un serveur et une configuration opérationnelle de base 35 000 ₽ jusqu'à 7 jours | POPULAIRE Cloud global Conteneurs, configuration et pipeline de déploiement 70 000 ₽ jusqu'à 14 jours | HA Cluster Enterprise Cluster avec vérification des pannes convenues à partir de 130 000 ₽ à partir de 20 jours |
|---|---|---|---|
|
Serveurs
|
Un VPS | Jusqu'à 3 serveurs | Cluster selon un schéma convenu |
|
Conteneurs
|
Installation et configuration selon les spécifications | Transfert des composants convenus | Images et orchestrateur selon les spécifications |
|
CI/CD
|
Non inclus | Pipeline de base | Pipeline et basculement par architecture |
|
Copies de sauvegarde
|
Archivage et stockage externe | Copies quotidiennes ; conservation 30 jours | Copies incrémentielles dans 2 régions selon la consigne |
|
Surveillance
|
Métriques de base du serveur | Tableau de bord et notifications | Métriques, notifications et journaux |
|
Réplication de base
|
Non inclus | Non inclus | Réplication et vérification de la commutation |
Coût unique de conception et de configuration. Les ressources cloud, les licences, le trafic et l'exploitation ultérieure sont payés séparément. La disponibilité et les objectifs de restauration dépendent du schéma convenu ; une publication continue n'est pas possible pour toutes les modifications.
— QUESTIONS ET RÉPONSES
Tout ce qui est important
avant le lancement
Composition des travaux, ressources initiales, ordre d'approbation et conditions de lancement.
-
Kubernetes est-il nécessaire pour un petit projet ?
Pas nécessairement. Un serveur ou Compose peuvent couvrir les besoins avec moins de complexité. Nous choisissons l'orchestrateur en fonction du nombre de composants, des exigences de mise à l'échelle et des capacités de maintenance. -
Comment le fournisseur est-il choisi ?
Nous comparons l'accessibilité des services et des paiements, l'hébergement des données, les exigences réseau, le support et le coût. Nous choisissons un fournisseur spécifique après vérification des conditions du projet ; une seule géographie de serveurs ne confirme pas toutes les exigences de données. -
Peut-on mettre à jour sans interruption ?
Pour une architecture appropriée, il est possible d'organiser une bascule vers une version éprouvée. Les modifications de schéma de données, les opérations longues et les incompatibilités de version nécessitent un plan séparé et parfois une fenêtre de maintenance. -
Quelle est la différence entre une sauvegarde et une réplique ?
La réplique prend en charge une autre copie de travail des données et peut répéter une modification erronée. La sauvegarde permet de revenir à l'état enregistré choisi. Un stockage indépendant, des droits et une vérification de la restauration sont nécessaires. -
Quels sont les objectifs de récupération ?
Nous fixons combien de données il est permis de perdre après une défaillance et en combien de temps le service doit être rétabli. Selon ces exigences, nous choisissons la fréquence des copies et l'architecture. Nous confirmons les objectifs par un test, et non seulement par une inscription dans le schéma.