Вопросы на собеседовании Cloud Architect: архитектура, миграция, безопасность

Введение

На собеседовании Cloud Architect обычно проверяют, как вы принимаете архитектурные компромиссы: надежность против стоимости, управляемые сервисы против переносимости, централизованные стандарты против автономии команд, меры безопасности против скорости поставки. Сильный ответ объясняет бизнес-цель, ограничения, целевую архитектуру, риски и операционную модель после запуска.

Используйте это руководство, чтобы подготовиться к вопросам о мультиоблачной стратегии, миграции, микросервисах, service mesh, аварийном восстановлении, zero trust и оптимизации затрат.

Стратегия мультиоблачности

1. Как вы проектируете стратегию мультиоблачности?

Ответ: Мультиоблачность использует несколько облачных провайдеров для обеспечения отказоустойчивости, оптимизации затрат и избежания привязки к поставщику.

Ключевые соображения:

Архитектурные шаблоны:

1. Активный-Активный:

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

2. Активный-Пассивный:

• Основное облако для производства
• Вторичное для аварийного восстановления
• Экономически выгодно

3. Облачно-агностические сервисы:

• Использовать Kubernetes для переносимости
• Terraform для IaC в разных облаках
• Стандартизированные конвейеры CI/CD

Проблемы:

• Сложность в управлении
• Затраты на передачу данных
• Требования к квалификации
• Согласованные политики безопасности

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

2. Как вы планируете и выполняете миграцию в облако?

Ответ: Миграция в облако требует тщательного планирования, оценки рисков и поэтапного выполнения.

7 R миграции:

Стратегии миграции:

1. Rehost (Lift and Shift):

• Перенести приложение с минимальными изменениями
• Подходит для быстрого выхода из дата-центра
• Часто требует оптимизации после миграции

2. Relocate:

• Перенести платформу или виртуализированную нагрузку без изменения приложения
• Подходит, если целевое облако поддерживает совместимый путь relocation
• Проверить сеть, идентификацию, backup и лицензии

3. Replatform:

• Внести ограниченные изменения, например перейти на managed database или контейнерную платформу
• Балансирует скорость миграции и улучшение эксплуатации

4. Refactor/Re-architect:

• Перепроектировать под cloud-native масштабирование, отказоустойчивость или скорость поставки
• Самый трудоемкий вариант, поэтому подходит для систем высокой ценности

5. Repurchase:

• Заменить приложение SaaS-решением
• Пример: заменить кастомный CRM на управляемую CRM-платформу

6. Retire:

• Вывести из эксплуатации приложения, которые больше не создают бизнес-ценность

7. Retain:

• Оставить систему на месте из-за compliance, задержек, стоимости или порядка миграции

Этапы миграции:

# Инструмент оценки миграции
class MigrationAssessment:
    def __init__(self, application):
        self.app = application
        self.score = 0
    
    def assess_cloud_readiness(self):
        factors = {
            'architecture': self.check_architecture(),
            'dependencies': self.check_dependencies(),
            'data_volume': self.check_data_volume(),
            'compliance': self.check_compliance(),
            'performance': self.check_performance_requirements()
        }
        
        # Рассчитать сложность миграции
        complexity = sum(factors.values()) / len(factors)
        
        if complexity < 3:
            return "Rehost - Низкая сложность"
        elif complexity < 6:
            return "Replatform - Средняя сложность"
        else:
            return "Refactor - Высокая сложность"
    
    def generate_migration_plan(self):
        return {
            'phase_1': 'Оценка и планирование',
            'phase_2': 'Proof of Concept',
            'phase_3': 'Миграция данных',
            'phase_4': 'Миграция приложений',
            'phase_5': 'Тестирование и валидация',
            'phase_6': 'Переключение и запуск',
            'phase_7': 'Оптимизация'
        }

Выполнение миграции:

1. Оценка:

• Инвентаризация приложений и зависимостей
• Анализ затрат (TCO)
• Выявление рисков и ограничений

2. Планирование:

• Выбор стратегии миграции для каждого приложения
• Определение критериев успеха
• Создание планов отката

3. Пилотная миграция:

• Начать с некритичного приложения
• Проверка подхода
• Уточнение процессов

4. Миграция данных:

# Пример: Миграция базы данных с помощью AWS DMS
aws dms create-replication-instance \
    --replication-instance-identifier migration-instance \
    --replication-instance-class dms.t2.medium

# Создать задачу миграции
aws dms create-replication-task \
    --replication-task-identifier db-migration \
    --source-endpoint-arn arn:aws:dms:region:account:endpoint/source \
    --target-endpoint-arn arn:aws:dms:region:account:endpoint/target \
    --migration-type full-load-and-cdc

5. Стратегия переключения:

• Big Bang: Все сразу (рискованно)
• Phased: Постепенная миграция (безопаснее)
• Parallel Run: Запуск обеих сред

Снижение рисков:

• Комплексное тестирование
• Автоматизированные процедуры отката
• Базовые показатели производительности
• Проверка безопасности
• Мониторинг затрат

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

Архитектура микросервисов

3. Как вы проектируете архитектуру микросервисов?

Ответ: Микросервисы разделяют приложения на небольшие, независимые сервисы.

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

Ключевые принципы:

1. Независимость сервисов:

• Каждый сервис владеет своими данными
• Независимое развертывание
• Допускается разнообразие технологий

2. Коммуникация:

# Синхронная (REST API)
import requests

def get_user(user_id):
    response = requests.get(f'http://user-service/api/users/{user_id}')
    return response.json()

# Асинхронная (Очередь сообщений)
import pika

def publish_order_event(order_data):
    connection = pika.BlockingConnection(pika.ConnectionParameters('rabbitmq'))
    channel = connection.channel()
    channel.queue_declare(queue='orders')
    channel.basic_publish(
        exchange='',
        routing_key='orders',
        body=json.dumps(order_data)
    )
    connection.close()

3. API Gateway:

• Единая точка входа
• Аутентификация/авторизация
• Ограничение скорости
• Маршрутизация запросов

4. Обнаружение сервисов:

• Динамическая регистрация сервисов
• Проверки работоспособности
• Балансировка нагрузки

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

• Независимое масштабирование
• Гибкость технологий
• Изоляция отказов
• Более быстрое развертывание

Проблемы:

• Сложность распределенной системы
• Согласованность данных
• Сложность тестирования
• Операционные издержки

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

4. Как вы реализуете service mesh в микросервисах?

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

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

Ключевые особенности:

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

• Балансировка нагрузки
• Прерыватель цепи
• Повторные попытки и тайм-ауты
• Канареечные развертывания
• A/B тестирование

2. Безопасность:

• Шифрование mTLS
• Аутентификация
• Политики авторизации

3. Наблюдаемость:

• Распределенная трассировка
• Сбор метрик
• Ведение журнала доступа

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

# Виртуальный сервис для маршрутизации трафика
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        user-type:
          exact: premium
    route:
    - destination:
        host: reviews
        subset: v2
      weight: 100
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

---
# Правило назначения для балансировки нагрузки
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 2
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Конфигурация прерывателя цепи:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: circuit-breaker
spec:
  host: payment-service
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

Безопасность mTLS:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-read
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend"]
    to:
    - operation:
        methods: ["GET"]

Наблюдаемость с помощью Kiali:

# Установите Istio с дополнениями наблюдаемости
istioctl install --set profile=demo

# Разверните Kiali, Prometheus, Grafana, Jaeger
kubectl apply -f samples/addons/

# Доступ к панели мониторинга Kiali
istioctl dashboard kiali

Сравнение Service Mesh:

Когда использовать:

• Среды микросервисов, где общие политики трафика, идентификации и наблюдаемости оправдывают операционную сложность
• Необходимость расширенного управления трафиком
• Требования безопасности (mTLS)
• Развертывания с несколькими кластерами
• Требования к наблюдаемости

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

Шаблоны проектирования

5. Объясните шаблон Circuit Breaker и когда его использовать.

Ответ: Circuit Breaker предотвращает каскадные сбои в распределенных системах.

Состояния:

1. Closed: Нормальная работа
2. Open: Обнаружены сбои, запросы быстро завершаются неудачей
3. Half-Open: Проверка восстановления сервиса

from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "closed"
    OPEN = "open"
    HALF_OPEN = "half_open"

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60, success_threshold=2):
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.success_threshold = success_threshold
        self.failures = 0
        self.successes = 0
        self.last_failure_time = None
        self.state = CircuitState.CLOSED
    
    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time > self.timeout:
                self.state = CircuitState.HALF_OPEN
                self.successes = 0
            else:
                raise Exception("Circuit breaker is OPEN")
        
        try:
            result = func(*args, **kwargs)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            raise e
    
    def on_success(self):
        self.failures = 0
        if self.state == CircuitState.HALF_OPEN:
            self.successes += 1
            if self.successes >= self.success_threshold:
                self.state = CircuitState.CLOSED
    
    def on_failure(self):
        self.failures += 1
        self.last_failure_time = time.time()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN

# Использование
breaker = CircuitBreaker()
result = breaker.call(external_api_call, user_id=123)

Сценарии использования:

• Вызовы внешних API
• Подключения к базам данных
• Коммуникация микросервисов
• Интеграции со сторонними производителями

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

Архитектура, управляемая событиями

6. Объясните архитектуру, управляемую событиями, и когда ее использовать.

Ответ: Архитектура, управляемая событиями (EDA), использует события для запуска и обмена данными между отвязанными сервисами.

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

Основные понятия:

1. Событие:

• Неизменяемый факт, который произошел
• Содержит релевантные данные
• С отметкой времени

2. Производитель событий:

• Публикует события
• Не знает потребителей

3. Потребитель событий:

• Подписывается на события
• Обрабатывает асинхронно

4. Шина/брокер событий:

• Маршрутизирует события
• Примеры: Kafka, RabbitMQ, AWS EventBridge

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

from kafka import KafkaProducer, KafkaConsumer
import json
from datetime import datetime

# Производитель событий
class OrderEventProducer:
    def __init__(self):
        self.producer = KafkaProducer(
            bootstrap_servers=['localhost:9092'],
            value_serializer=lambda v: json.dumps(v).encode('utf-8')
        )
    
    def publish_order_created(self, order_id, customer_id, items, total):
        event = {
            'event_type': 'OrderCreated',
            'event_id': str(uuid.uuid4()),
            'timestamp': datetime.utcnow().isoformat(),
            'data': {
                'order_id': order_id,
                'customer_id': customer_id,
                'items': items,
                'total': total
            }
        }
        self.producer.send('order-events', value=event)
        self.producer.flush()

# Потребитель событий
class InventoryEventConsumer:
    def __init__(self):
        self.consumer = KafkaConsumer(
            'order-events',
            bootstrap_servers=['localhost:9092'],
            value_deserializer=lambda m: json.loads(m.decode('utf-8')),
            group_id='inventory-service'
        )
    
    def process_events(self):
        for message in self.consumer:
            event = message.value
            if event['event_type'] == 'OrderCreated':
                self.reserve_inventory(event['data'])
    
    def reserve_inventory(self, order_data):
        # Логика резервирования инвентаря
        print(f"Резервирование инвентаря для заказа {order_data['order_id']}")
        # Публикация события InventoryReserved

Шаблон Event Sourcing:

# Хранить события вместо текущего состояния
class EventStore:
    def __init__(self):
        self.events = []
    
    def append(self, event):
        self.events.append(event)
    
    def get_events(self, aggregate_id):
        return [e for e in self.events if e['aggregate_id'] == aggregate_id]

# Восстановление состояния из событий
class OrderAggregate:
    def __init__(self, order_id):
        self.order_id = order_id
        self.status = 'pending'
        self.items = []
        self.total = 0
    
    def apply_event(self, event):
        if event['type'] == 'OrderCreated':
            self.items = event['data']['items']
            self.total = event['data']['total']
        elif event['type'] == 'OrderPaid':
            self.status = 'paid'
        elif event['type'] == 'OrderShipped':
            self.status = 'shipped'
    
    def rebuild_from_events(self, events):
        for event in events:
            self.apply_event(event)

CQRS (Command Query Responsibility Segregation):

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

• Слабая связанность
• Масштабируемость
• Гибкость
• Аудит (event sourcing)
• Обработка в реальном времени

Проблемы:

• Итоговая согласованность
• Эволюция схемы событий
• Сложность отладки
• Обработка дубликатов событий

Сценарии использования:

• Обработка заказов электронной коммерции
• Аналитика в реальном времени
• Обработка данных IoT
• Коммуникация микросервисов
• Системы аудита и соответствия требованиям

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

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

7. Как вы проектируете стратегию аварийного восстановления?

Ответ: DR обеспечивает непрерывность бизнеса во время сбоев.

Ключевые метрики:

• RTO (Recovery Time Objective): Максимально допустимое время простоя
• RPO (Recovery Point Objective): Максимально допустимая потеря данных

Стратегии DR:

Пример реализации:

Автоматизация:

# Скрипт автоматического переключения
def initiate_failover():
    # 1. Остановить записи в основной
    stop_primary_writes()
    
    # 2. Повысить вторичную базу данных
    promote_secondary_to_primary()
    
    # 3. Обновить DNS
    update_route53_failover()
    
    # 4. Запустить сервисы региона DR
    start_dr_services()
    
    # 5. Проверить работоспособность
    verify_dr_health()
    
    # 6. Уведомить команду
    send_alert("Failover completed to DR region")

Тестирование:

• Регулярные DR-учения с учетом критичности нагрузки
• Автоматизированное тестирование
• Документированные инструкции
• Обзоры после инцидентов

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

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

8. Как вы реализуете безопасность с нулевым доверием в облачной архитектуре?

Ответ: Нулевое доверие предполагает отсутствие неявного доверия, проверяйте все.

Принципы:

1. Явная проверка
2. Доступ с наименьшими привилегиями
3. Предполагать нарушение

Реализация:

Компоненты:

1. Идентификация и доступ:

# Пример: Политика условного доступа
policies:
  - name: "Требовать MFA для конфиденциальных приложений"
    conditions:
      applications: ["finance-app", "hr-system"]
      users: ["all"]
    controls:
      - require_mfa: true
      - require_compliant_device: true
      - allowed_locations: ["corporate-network", "vpn"]

2. Сегментация сети:

• Микросегментация
• Service mesh (Istio, Linkerd)
• Сетевые политики

3. Шифрование:

• Данные в состоянии покоя
• Данные в пути
• Сквозное шифрование

4. Непрерывный мониторинг:

• Обнаружение угроз в реальном времени
• Анализ поведения
• Автоматизированный ответ

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

Оптимизация затрат

9. Как вы оптимизируете затраты в нескольких облачных провайдерах?

Ответ: Стратегии оптимизации затрат в мультиоблачной среде:

1. Размещение рабочей нагрузки:

• Анализ моделей ценообразования
• Учет затрат на передачу данных
• Использование региональных различий в ценах

2. Зарезервированная емкость:

• AWS Reserved Instances
• Azure Reserved VM Instances
• GCP Committed Use Discounts

3. Spot/Preemptible Instances:

# Сравнение затрат: заполнить актуальными значениями из cloud calculators
def compare_options(options):
    return sorted(options, key=lambda option: (
        option["monthly_cost"],
        option["operational_risk"],
        option["commitment_months"]
    ))

4. Мониторинг и управление:

• Унифицированные панели мониторинга затрат
• Оповещения о бюджете
• Распределение затрат на основе тегов
• Автоматизированная очистка ресурсов

5. Оптимизация архитектуры:

• Serverless для переменных рабочих нагрузок
• Политики автоматического масштабирования
• Многоуровневое хранилище
• CDN для статического контента

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

Заключение

На собеседовании Cloud Architect ценят практичность решений больше, чем заученные диаграммы. Подготовьтесь объяснять:

1. Мультиоблачность: зачем нагрузке нужен более чем один провайдер и какую сложность это добавляет
2. Миграция: варианты 7R, поиск зависимостей, поэтапный cutover, rollback и оптимизация после миграции
3. Микросервисы: границы сервисов, владение данными, API-контракты, отказоустойчивость и операционные затраты
4. Service mesh: когда mTLS, политики трафика и наблюдаемость оправдывают дополнительный платформенный слой
5. Шаблоны проектирования: circuit breaker, saga, CQRS, идемпотентность, повторы и таймауты
6. Event-driven системы: контракты событий, порядок, дубликаты, эволюция схем и eventual consistency
7. Аварийное восстановление: RTO/RPO, региональная стратегия, runbook, тесты и доказательства восстановления
8. Безопасность: доступ от идентичности, least privilege, шифрование, сегментация, логирование и мышление assume breach
9. Оптимизация затрат: rightsizing, commitment-планы, теги, очистка простаивающих ресурсов, передача данных и FinOps governance

В ответе сначала назовите бизнес-ограничение, затем компромисс и способ проверки дизайна в production.