декабря 21, 2025
14 мин. чтения

Вопросы для собеседования на позицию Senior DevOps Engineer: Полное руководство

interview
career-advice
job-search
Вопросы для собеседования на позицию Senior DevOps Engineer: Полное руководство
MB

Milad Bonakdar

Автор

Освойте продвинутые концепции DevOps с помощью исчерпывающих вопросов для собеседования, охватывающих Kubernetes, Terraform, облачную архитектуру, GitOps, безопасность, практики SRE и высокую доступность для опытных DevOps-инженеров.


Введение

От старших DevOps-инженеров ожидается проектирование масштабируемой инфраструктуры, внедрение продвинутой автоматизации, обеспечение безопасности и соответствия требованиям, а также продвижение DevOps-культуры в организациях. Эта роль требует глубоких знаний в области оркестрации контейнеров, инфраструктуры как кода, облачной архитектуры и надежности сайтов.

Это всеобъемлющее руководство охватывает основные вопросы для собеседований старших DevOps-инженеров, уделяя особое внимание продвинутым концепциям, производственным системам и стратегическому мышлению. Каждый вопрос включает подробные объяснения и практические примеры.


Продвинутый Kubernetes

1. Объясните архитектуру Kubernetes и роль ключевых компонентов.

Ответ: Kubernetes следует архитектуре "мастер-рабочий":

Компоненты плоскости управления (Control Plane):

  • API Server: Фронтенд для плоскости управления Kubernetes, обрабатывает все REST-запросы
  • etcd: Распределенное хранилище "ключ-значение" для состояния кластера
  • Scheduler: Назначает поды узлам на основе требований к ресурсам
  • Controller Manager: Запускает процессы контроллеров (репликация, конечные точки и т. д.)
  • Cloud Controller Manager: Интегрируется с API облачного провайдера

Компоненты узла:

  • kubelet: Агент, который обеспечивает запуск контейнеров в подах
  • kube-proxy: Поддерживает сетевые правила для связи подов
  • Container Runtime: Запускает контейнеры (Docker, containerd, CRI-O)
Loading diagram...

Как это работает:

  1. Пользователь отправляет развертывание через kubectl
  2. API Server проверяет и сохраняет в etcd
  3. Scheduler назначает поды узлам
  4. kubelet на узле создает контейнеры
  5. kube-proxy настраивает сеть

Распространенность: Очень часто
Сложность: Высокая


2. Как вы устраняете неполадки пода, застрявшего в состоянии CrashLoopBackOff?

Ответ: Систематический подход к отладке:

# 1. Проверьте статус пода и события
kubectl describe pod <имя-пода>
# Ищите: Ошибки извлечения образа, ограничения ресурсов, сбои проверок работоспособности

# 2. Проверьте логи
kubectl logs <имя-пода>
kubectl logs <имя-пода> --previous  # Логи предыдущего контейнера

# 3. Проверьте ограничения ресурсов
kubectl top pod <имя-пода>
kubectl describe node <имя-узла>

# 4. Проверьте probes liveness/readiness
kubectl get pod <имя-пода> -o yaml | grep -A 10 livenessProbe

# 5. Войдите в контейнер (если он ненадолго остается активным)
kubectl exec -it <имя-пода> -- /bin/sh

# 6. Проверьте образ
kubectl get pod <имя-пода> -o jsonpath='{.spec.containers[*].image}'
docker pull <образ>  # Проверьте локально

# 7. Проверьте ConfigMaps/Secrets
kubectl get configmap
kubectl get secret

# 8. Проверьте спецификацию deployment/pod
kubectl get deployment <имя-развертывания> -o yaml

Распространенные причины:

  • Сбой приложения при запуске
  • Отсутствующие переменные среды
  • Неправильная конфигурация liveness probe
  • Недостаточно ресурсов (OOMKilled)
  • Ошибки извлечения образа
  • Отсутствующие зависимости

Пример исправления:

# Увеличьте лимиты ресурсов
resources:
  limits:
    memory: "512Mi"
    cpu: "500m"
  requests:
    memory: "256Mi"
    cpu: "250m"

# Отрегулируйте время probe
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30  # Дайте приложению время для запуска
  periodSeconds: 10
  failureThreshold: 3

Распространенность: Очень часто
Сложность: Средняя


3. Объясните сеть Kubernetes: Services, Ingress и Network Policies.

Ответ: Уровни сети Kubernetes:

Services: Типы предоставления сервисов:

# ClusterIP (только внутренний)
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

# NodePort (внешний доступ через IP-адрес узла)
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

# LoadBalancer (облачный балансировщик нагрузки)
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

Ingress: HTTP/HTTPS маршрутизация:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls

Network Policies: Управление связью между подами:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

Распространенность: Очень часто
Сложность: Высокая


4. Как вы реализуете автомасштабирование в Kubernetes?

Ответ: Несколько стратегий автомасштабирования:

Horizontal Pod Autoscaler (HPA):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15

Vertical Pod Autoscaler (VPA):

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  updatePolicy:
    updateMode: "Auto"  # или "Recreate", "Initial", "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 2Gi

Cluster Autoscaler: Автоматически регулирует размер кластера на основе ожидающих подов:

# Пример AWS
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
data:
  min-nodes: "2"
  max-nodes: "10"
  scale-down-delay-after-add: "10m"
  scale-down-unneeded-time: "10m"

Распространенность: Часто
Сложность: Средняя


Продвинутый Terraform

5. Объясните управление состоянием Terraform и лучшие практики.

Ответ: Состояние Terraform отслеживает инфраструктуру и имеет решающее значение для операций.

Конфигурация удаленного состояния:

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

Блокировка состояния:

# Таблица DynamoDB для блокировки состояния
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

Лучшие практики:

1. Никогда не коммитьте файлы состояния в Git

# .gitignore
*.tfstate
*.tfstate.*
.terraform/

2. Используйте workspaces для сред

terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

terraform workspace select dev
terraform apply

3. Импортируйте существующие ресурсы

# Импортируйте существующий экземпляр EC2
terraform import aws_instance.web i-1234567890abcdef0

# Проверьте
terraform plan

4. Манипулирование состоянием (используйте осторожно)

# Список ресурсов в состоянии
terraform state list

# Показать конкретный ресурс
terraform state show aws_instance.web

# Переместить ресурс в состоянии
terraform state mv aws_instance.old aws_instance.new

# Удалить ресурс из состояния (не удаляет)
terraform state rm aws_instance.web

5. Создавайте резервные копии состояния перед крупными изменениями

terraform state pull > backup.tfstate

Распространенность: Очень часто
Сложность: Высокая


6. Как вы структурируете код Terraform для больших проектов?

Ответ: Модульная структура для удобства обслуживания:

Структура каталогов:

terraform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── terraform.tfvars
│   │   └── backend.tf
│   ├── staging/
│   └── prod/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   ├── eks/
│   ├── rds/
│   └── s3/
└── global/
    ├── iam/
    └── route53/

Пример модуля:

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-vpc"
    }
  )
}

resource "aws_subnet" "private" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-private-${count.index + 1}"
      Type = "private"
    }
  )
}

# modules/vpc/variables.tf
variable "vpc_cidr" {
  description = "CIDR block для VPC"
  type        = string
}

variable "environment" {
  description = "Название среды"
  type        = string
}

variable "private_subnet_cidrs" {
  description = "CIDR blocks для частных подсетей"
  type        = list(string)
}

variable "availability_zones" {
  description = "Зоны доступности"
  type        = list(string)
}

variable "tags" {
  description = "Общие теги"
  type        = map(string)
  default     = {}
}

# modules/vpc/outputs.tf
output "vpc_id" {
  value = aws_vpc.main.id
}

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

Использование модулей:

# environments/prod/main.tf
module "vpc" {
  source = "../../modules/vpc"

  vpc_cidr             = "10.0.0.0/16"
  environment          = "prod"
  private_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  availability_zones   = ["us-east-1a", "us-east-1b", "us-east-1c"]

  tags = {
    Project   = "MyApp"
    ManagedBy = "Terraform"
  }
}

module "eks" {
  source = "../../modules/eks"

  cluster_name    = "prod-cluster"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnet_ids
  node_group_size = 3
}

Распространенность: Часто
Сложность: Высокая


Облачная архитектура

7. Разработайте высокодоступную многорегиональную архитектуру на AWS.

Ответ: Многорегиональная архитектура для высокой доступности:

Loading diagram...

Ключевые компоненты:

1. DNS и управление трафиком:

# Route 53 с проверками работоспособности
resource "aws_route53_health_check" "primary" {
  fqdn              = "api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier = "primary"
  health_check_id = aws_route53_health_check.primary.id

  alias {
    name                   = aws_lb.primary.dns_name
    zone_id                = aws_lb.primary.zone_id
    evaluate_target_health = true
  }
}

2. Репликация базы данных:

# RDS с межрегиональной репликой для чтения
resource "aws_db_instance" "primary" {
  identifier           = "prod-db-primary"
  engine               = "postgres"
  instance_class       = "db.r5.xlarge"
  multi_az             = true
  backup_retention_period = 7

  provider = aws.us-east-1
}

resource "aws_db_instance" "replica" {
  identifier             = "prod-db-replica"
  replicate_source_db    = aws_db_instance.primary.arn
  instance_class         = "db.r5.xlarge"
  auto_minor_version_upgrade = false

  provider = aws.us-west-2
}

3. Репликация данных:

# S3 межрегиональная репликация
resource "aws_s3_bucket_replication_configuration" "replication" {
  bucket = aws_s3_bucket.source.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "replicate-all"
    status = "Enabled"

    destination {
      bucket        = aws_s3_bucket.destination.arn
      storage_class = "STANDARD"
    }
  }
}

Принципы проектирования:

  • Активно-активная или активно-пассивная настройка
  • Автоматизированное переключение при отказе с проверками работоспособности
  • Репликация данных с минимальной задержкой
  • Согласованное развертывание в разных регионах
  • Мониторинг и оповещение для обоих регионов

Распространенность: Часто
Сложность: Высокая


GitOps и CI/CD

8. Объясните GitOps и как его реализовать с помощью ArgoCD.

Ответ: GitOps использует Git в качестве единого источника истины для декларативной инфраструктуры и приложений.

Принципы:

  1. Декларативная конфигурация в Git
  2. Автоматическая синхронизация
  3. Управление версиями для всех изменений
  4. Непрерывное согласование

Реализация ArgoCD:

# Манифест приложения
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/app-manifests
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
    - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

Структура каталогов:

app-manifests/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── patches/
    ├── staging/
    └── production/
        ├── kustomization.yaml
        ├── replicas.yaml
        └── resources.yaml

Kustomization:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
- ../../base

replicas:
- name: myapp
  count: 5

resources:
- ingress.yaml

patches:
- path: resources.yaml
  target:
    kind: Deployment
    name: myapp

Преимущества:

  • Git как контрольный журнал
  • Простые откаты (git revert)
  • Декларативное желаемое состояние
  • Автоматическое обнаружение дрейфа
  • Управление несколькими кластерами

Распространенность: Часто
Сложность: Средняя


Безопасность и соответствие требованиям

9. Как вы реализуете лучшие практики безопасности в Kubernetes?

Ответ: Многоуровневый подход к безопасности:

1. Pod Security Standards:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

2. RBAC (Role-Based Access Control):

# Роль для разработчиков
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: developer
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

# RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: production
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

3. Network Policies:

# Отклонить весь входящий трафик по умолчанию
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress

4. Управление секретами:

# External Secrets Operator
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: app-secrets
    creationPolicy: Owner
  data:
  - secretKey: database-password
    remoteRef:
      key: prod/database
      property: password

5. Security Context:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

6. Сканирование образов:

# Admission controller с OPA
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy
data:
  policy.rego: |
    package kubernetes.admission
    
    deny[msg] {
      input.request.kind.kind == "Pod"
      image := input.request.object.spec.containers[_].image
      not startswith(image, "registry.company.com/")
      msg := sprintf("Image %v is not from approved registry", [image])
    }

Распространенность: Очень часто
Сложность: Высокая


Observability и SRE

10. Разработайте комплексный стек observability.

Ответ: Три столпа observability: Метрики, Логи, Трассировки

Архитектура:

Loading diagram...

1. Метрики (Prometheus + Grafana):

# ServiceMonitor для метрик приложения
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-metrics
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

2. Логирование (Loki):

# Promtail config для сбора логов
apiVersion: v1
kind: ConfigMap
metadata:
  name: promtail-config
data:
  promtail.yaml: |
    server:
      http_listen_port: 9080
    
    clients:
      - url: http://loki:3100/loki/api/v1/push
    
    scrape_configs:
      - job_name: kubernetes-pods
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - source_labels: [__meta_kubernetes_pod_label_app]
            target_label: app
          - source_labels: [__meta_kubernetes_namespace]
            target_label: namespace

3. Трассировка (Jaeger):

# Инструментирование приложения
from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

# Настройка трассировки
trace.set_tracer_provider(TracerProvider())
jaeger_exporter = JaegerExporter(
    agent_host_name="jaeger-agent",
    agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(jaeger_exporter)
)

tracer = trace.get_tracer(__name__)

# Использование в коде
with tracer.start_as_current_span("process_request"):
    # Ваш код здесь
    pass

4. Правила оповещения:

# PrometheusRule
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: app-alerts
spec:
  groups:
  - name: app
    interval: 30s
    rules:
    - alert: HighErrorRate
      expr: |
        sum(rate(http_requests_total{status=~"5.."}[5m]))
        /
        sum(rate(http_requests_total[5m]))
        > 0.05
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "High error rate detected"
        description: "Error rate is {{ $value | humanizePercentage }}"
    
    - alert: HighLatency
      expr: |
        histogram_quantile(0.95,
          rate(http_request_duration_seconds_bucket[5m])
        ) > 1
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "High latency detected"

5. Мониторинг SLO:

# SLO definition
apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevel
metadata:
  name: api-availability
spec:
  service: "api"
  labels:
    team: "platform"
  slos:
    - name: "requests-availability"
      objective: 99.9
      description: "API requests should succeed"
      sli:
        events:
          errorQuery: sum(rate(http_requests_total{status=~"5.."}[{{.window}}]))
          totalQuery: sum(rate(http_requests_total[{{.window}}]))
      alerting:
        pageAlert:
          labels:
            severity: critical
        ticketAlert:
          labels:
            severity: warning

Распространенность: Часто
Сложность: Высокая


Аварийное восстановление

11. Как вы реализуете аварийное восстановление для кластера Kubernetes?

Ответ: Комплексная стратегия DR:

1. Стратегия резервного копирования:

# Velero backup schedule
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
  namespace: velero
spec:
  schedule: "0 2 * * *"  # 2 AM daily
  template:
    includedNamespaces:
    - production
    - staging
    excludedResources:
    - events
    - events.events.k8s.io
    storageLocation: aws-s3
    volumeSnapshotLocations:
    - aws-ebs
    ttl: 720h  # 30 days

2. etcd Backup:

#!/bin/bash
# Скрипт автоматического резервного копирования etcd

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

# Загрузить в S3
aws s3 cp /backup/etcd-snapshot-*.db s3://etcd-backups/

# Очистить старые резервные копии
find /backup -name "etcd-snapshot-*.db" -mtime +7 -delete

3. Процедура восстановления:

# Восстановить etcd из snapshot
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \
  --data-dir=/var/lib/etcd-restore \
  --initial-cluster=etcd-0=https://10.0.1.10:2380 \
  --initial-advertise-peer-urls=https://10.0.1.10:2380

# Восстановить приложение с помощью Velero
velero restore create --from-backup daily-backup-20231125
velero restore describe <restore-name>

4. Multi-Region Failover:

# Terraform для многорегиональной настройки
module "primary_cluster" {
  source = "./modules/eks"
  region = "us-east-1"
  # ... configuration
}

module "dr_cluster" {
  source = "./modules/eks"
  region = "us-west-2"
  # ... configuration
}

# Route 53 health check и failover
resource "aws_route53_health_check" "primary" {
  fqdn              = module.primary_cluster.endpoint
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3
}

5. RTO/RPO Targets:

  • RTO (Recovery Time Objective): < 1 час
  • RPO (Recovery Point Objective): < 15 минут
  • Регулярные DR drills (ежемесячно)
  • Документированные runbooks
  • Автоматизированное переключение при отказе, где это возможно

Распространенность: Часто
Сложность: Высокая


Service Mesh

12. Объясните архитектуру service mesh и когда ее использовать.

Ответ: Service mesh предоставляет инфраструктурный уровень для связи между сервисами.

Основные компоненты:

Loading diagram...

Реализация Istio:

# Virtual Service для маршрутизации трафика
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1
      weight:
Newsletter subscription

Еженедельные советы по карьере, которые действительно работают

Получайте последние идеи прямо на вашу почту

Похожие посты

Decorative doodle

Выделитесь перед рекрутерами и получите работу мечты

Присоединяйтесь к тысячам тех, кто изменил свою карьеру с помощью резюме на базе ИИ, которые проходят ATS и впечатляют менеджеров по найму.

Начать создание

Поделиться этим постом

Сократите Время Написания Резюме на 90%

Средний соискатель тратит более 3 часов на форматирование резюме. Наш ИИ делает это менее чем за 15 минут, ускоряя переход к этапу подачи заявки в 12 раз.