🕰️ Timeline: 60+ лет эволюции разработки ПО

Когда компьютеры были размером с комнату

Компьютеры занимали целые здания и стоили миллионы долларов. "Деплой" означал физическую замену перфокарт. Уже тогда появилось разделение на программистов и операторов — первые семена будущего конфликта Dev vs Ops.

Контекст эпохи

1990-е годы — время мейнфреймов IBM, первых персональных компьютеров и зарождения интернета. Программное обеспечение разрабатывалось годами, стоило миллионы долларов и поставлялось на физических носителях — дискетах и CD-ROM.

Типичный проект 1990-х:

• Длительность: 2-5 лет
• Команда: 50-200 человек
• Релизы: 1 раз в 1-2 года
• Стоимость ошибки: катастрофическая (нельзя "обновить" CD-ROM у клиента)

Waterfall породил одни из крупнейших провалов в истории IT:

ITIL (Information Technology Infrastructure Library) — британское правительство создало набор best practices для управления IT-сервисами. ITIL стал стандартом для Ops-отделов по всему миру.

Предшественники Agile: "лёгкие" методологии 1990-х

Agile не появился из ниоткуда. В 1990-х несколько групп независимо искали альтернативы Waterfall:

Все эти подходы объединяло одно: итеративность, люди важнее процессов, адаптация к изменениям.

XP стал первой методологией, которая ввела практики, ставшие основой DevOps:

Scrum принёс итеративную разработку в мейнстрим:

• Спринты 2-4 недели — фиксированные итерации с конкретным результатом
• Daily Standup — ежедневная синхронизация команды (15 минут)
• Retrospective — регулярный анализ: что улучшить?
• Product Owner — один человек отвечает за приоритеты

Технологические сдвиги

Google с самого начала строил культуру, где инженеры отвечают за всё — от кода до инфраструктуры.

Patrick Debois, бельгийский консультант, был в восторге от доклада Flickr. Он организовал первую конференцию, посвящённую сотрудничеству Dev и Ops:

Twitter-хештег конференции #DevOpsDays сократили до #DevOps — так родился термин.

К 2025 году DevOpsDays проводятся в 100+ городах по всему миру ежегодно.

Предыстория контейнеров

Контейнеры не были изобретением Docker. Технологии изоляции существовали десятилетиями:

Solomon Hykes представил Docker на PyCon 2013. 5-минутная демонстрация "The future of Linux Containers" взорвала индустрию. Docker не изобрёл контейнеры — он сделал их простыми.

В 2016 году Google опубликовал книгу "Site Reliability Engineering", раскрыв свои внутренние практики. SRE — это "DevOps с инженерным подходом".

Ключевые концепции SRE:

К 2018-2019 годам стало ясно: безопасность нельзя проверять в конце. DevSecOps интегрирует безопасность во весь pipeline:

Ключевые инструменты эры: Snyk (2015), Trivy (2019), OPA/Gatekeeper (2018), Falco (2016)

Проблема: DevOps работает, но...

К 2020 году DevOps победил, но возникли новые проблемы:

• Cognitive overload: Разработчик должен знать Git, Docker, K8s, Terraform, Helm, ArgoCD, Prometheus... 50+ инструментов
• YAML hell: Тысячи строк YAML для деплоя простого сервиса
• "You build it, you run it" стало "You build it, you suffer"

DORA (DevOps Research and Assessment) под руководством Dr. Nicole Forsgren провела масштабные исследования (2014-2025) и определила 5 ключевых метрик (Rework Rate добавлен в 2025):

Google приобрёл DORA в 2018 году. Метрики DORA теперь встроены в GitHub, GitLab, Azure DevOps.

Model Context Protocol (MCP) — открытый стандарт от Anthropic (2024) для интеграции AI с инструментами и данными.

Ключевые анонсы 2025:

• Kagent (CNCF Sandbox) — first open-source agentic AI для Kubernetes
• AWS Kiro — виртуальный разработчик от Amazon
• Dapr Agents — AI-агенты с stateful workflows
• MCP → Agentic AI Foundation — протокол передан в независимую организацию

🚀 Тренды ближайших лет

Что это означает на практике:

Традиционно разработчики (Dev) и системные администраторы (Ops) работали изолированно. Разработчик писал код и "перебрасывал через стену" в Ops для деплоя. Если что-то ломалось — начиналась игра "это не мой баг".

DevOps Culture ломает эту стену:

• Общая ответственность (Shared Ownership) — разработчик отвечает за код не только до merge, но и в production. Если сервис упал в 3 ночи — разработчик тоже получает алерт
• "You build it, you run it" — принцип Amazon: команда, которая написала сервис, сама его эксплуатирует. Это мотивирует писать надёжный код
• Кросс-функциональные команды — в одной команде сидят frontend, backend, QA, DevOps инженер. Нет "отдела тестирования" куда-то там
• Психологическая безопасность — можно признать ошибку без страха наказания. Blameless culture = фокус на "что сломалось в системе", а не "кто виноват"

🔴 Анти-паттерн: "DevOps-инженер" как отдельная роль, которая делает всё за всех. Это НЕ DevOps, это просто переименованный сисадмин.

🟢 Правильно: Каждый разработчик умеет читать логи, понимает как работает Kubernetes, может сам задеплоить свой сервис.

Зачем автоматизировать:

• Скорость — автоматический деплой занимает 5 минут, ручной — 2 часа
• Повторяемость — скрипт делает одно и то же каждый раз. Человек может забыть шаг
• Масштаб — задеплоить на 1 сервер вручную можно. На 1000 серверов — только автоматически
• Аудит — автоматизация оставляет логи: кто, когда, что сделал

Что автоматизируют в DevOps:

🔴 Анти-паттерн: Автоматизировать ВСЁ сразу. Начните с самого болезненного ручного процесса.

Правило: Если делаете что-то вручную больше 2 раз — автоматизируйте.

Откуда это: Lean пришёл из Toyota Production System (TPS) — системы производства Toyota, которая произвела революцию в автомобилестроении.

Ключевые концепции Lean в DevOps:

1. Устранение потерь (Muda)

Потери — это любая активность, которая не добавляет ценности для клиента:

• Ожидание — код ждёт code review 3 дня. Решение: автоматические проверки, SLA на review
• Передача — код передаётся от Dev к QA к Ops. Решение: кросс-функциональные команды
• Частично сделанная работа — 10 открытых PR, ни один не в production. Решение: WIP limits
• Переключение контекста — разработчик работает над 5 задачами одновременно. Решение: focus, лимиты задач
• Дефекты — баги, которые нашли в production. Решение: тесты, code review, статический анализ

2. Маленькие batch sizes (партии)

Вместо релиза раз в месяц с 100 изменениями — релиз каждый день с 2-3 изменениями:

• Легче найти причину бага (меньше изменений = меньше подозреваемых)
• Меньше риск катастрофы (откатить 2 изменения проще, чем 100)
• Быстрее обратная связь от пользователей

3. Continuous Improvement (Kaizen)

Постоянное улучшение маленькими шагами. После каждого инцидента — post-mortem с action items. После каждого спринта — ретроспектива.

Принцип: "What gets measured, gets managed" — что измеряется, тем можно управлять.

Типы метрик в DevOps:

🔴 Анти-паттерн: Измерять всё подряд без цели. 1000 графиков, на которые никто не смотрит.

🟢 Правильно: Выбрать 5-10 ключевых метрик (KPIs), которые напрямую связаны с бизнес-целями. Остальные — для drill-down при расследовании.

Проблема: Знания застревают в головах отдельных людей. "Только Вася знает, как работает этот сервис" — это bus factor = 1 (если Вася уйдёт/заболеет, всё встанет).

Практики Sharing:

• Документация as Code — документация лежит рядом с кодом в Git, обновляется вместе с кодом
• Runbooks — пошаговые инструкции для типовых операций и инцидентов. "Если упал сервис X, сделай шаги 1-2-3"
• Post-mortems — разбор инцидентов с публикацией выводов для всей компании
• Tech Talks — внутренние презентации "как я решил проблему X"
• Pair programming / Mob programming — совместная работа для передачи знаний
• Rotation — ротация инженеров между командами для распространения практик
• Chaos Days — специальные дни для экспериментов и обучения

Инструменты:

• Confluence, Notion, GitBook — для документации
• Slack/Teams — для быстрого обмена информацией
• Backstage — портал разработчика со всей информацией о сервисах

Суть: Максимально ускорить движение работы от идеи до production. Работа должна течь как вода — без застоев и препятствий.

Практики First Way:

• Continuous Integration (CI) — каждый коммит автоматически собирается и тестируется. Нет "накопления" кода
• Continuous Delivery (CD) — код всегда готов к деплою. Деплой — это нажатие одной кнопки
• Маленькие batch sizes — релизы по 1-5 изменений, а не по 100
• WIP Limits — ограничение количества задач в работе. Пример: не больше 3 задач в колонке "In Progress"
• Устранение очередей — автоматизация code review (линтеры, SAST), параллельные тесты

Пример проблемы: Разработчик закончил код в понедельник, но code review занял 3 дня, тесты — ещё 2 дня, деплой в пятницу. Lead time = 5 дней вместо возможных 4 часов.

Решение: Автоматические линтеры + автотесты + автодеплой = Lead time 30 минут.

Суть: Создать быстрые петли обратной связи СПРАВА НАЛЕВО. Информация о проблемах в production должна мгновенно достигать разработчиков.

Практики Second Way:

• Мониторинг — Prometheus собирает метрики каждые 15 секунд. Grafana показывает дашборды в реальном времени
• Alerting — PagerDuty/incident.io будит on-call инженера ночью, если сервис упал
• Логирование — все логи централизованы в ELK/Loki. Можно найти ошибку за секунды
• Tracing — Jaeger/Tempo показывает путь запроса через все сервисы. Видно, где тормозит
• A/B Testing — быстрая обратная связь от пользователей. "Версия A даёт +5% конверсии"
• Feature Flags — можно мгновенно выключить проблемную фичу без редеплоя

Ключевой принцип: Чем быстрее обратная связь, тем дешевле исправить ошибку.

Суть: Создать культуру экспериментирования, где ошибки — это возможность для обучения, а не повод для наказания.

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

1. Blameless Post-mortems (разбор без обвинений)

После каждого серьёзного инцидента проводится разбор:

• Что произошло? (timeline событий)
• Почему это произошло? (5 Whys — копаем до root cause)
• Как предотвратить в будущем? (action items)

Важно: Фокус на системных проблемах, а не на людях. "Система позволила задеплоить без тестов" вместо "Вася задеплоил без тестов".

2. Chaos Engineering (инженерия хаоса)

Намеренно ломаем систему в контролируемых условиях, чтобы найти слабые места ДО того, как они проявятся в реальном инциденте:

• Chaos Monkey — случайно убивает контейнеры/серверы. Система должна выжить
• Latency injection — искусственно добавляет задержки. Работает ли timeout/retry?
• Network partition — симулирует потерю связи между сервисами

3. Game Days (игровые дни)

Специальные дни, когда команда симулирует disaster recovery. "Представим, что AWS us-east-1 полностью недоступен. Что делаем?"

4. 20% Time / Innovation Time

Выделенное время на эксперименты и обучение. Google так создал Gmail и AdSense.

Результат Third Way: Команда, которая не боится экспериментировать, быстрее находит лучшие решения. Инциденты становятся источником знаний, а не стресса.

Что измеряет: Как часто команда успешно деплоит код в production.

Почему это важно:

• Частые деплои = маленькие изменения = меньше риск катастрофы
• Быстрая обратная связь от пользователей
• Показывает зрелость CI/CD pipeline

Как измерять:

Как улучшить:

• Автоматизировать CI/CD pipeline (GitHub Actions, ArgoCD)
• Уменьшить размер изменений (trunk-based development)
• Использовать feature flags вместо long-lived branches
• Автоматические тесты вместо ручного QA

🔴 Анти-паттерн: "Deploy Friday" — деплоить только в пятницу раз в 2 недели. Это Low performer.

Что измеряет: Сколько времени проходит от момента, когда разработчик сделал commit, до момента, когда этот код работает в production.

Типичные узкие места:

🟢 Elite пример: Netflix деплоит код в production через 16 минут после merge.

Что измеряет: Какой процент деплоев приводит к проблемам в production (требует hotfix, rollback, или вызывает инцидент).

Формула:

Что считается "failure":

• Rollback (откат на предыдущую версию)
• Hotfix (срочное исправление в течение 24 часов)
• Инцидент, вызванный деплоем
• Отключение функционала через feature flag

Как снизить CFR:

• Тестирование: Unit → Integration → E2E → Performance → Security
• Code Review: Каждый PR проверяется минимум 1 человеком
• Canary deployments: Сначала 1% трафика, потом 10%, потом 100%
• Feature Flags: Можно отключить фичу без rollback
• Staging environment: Тестирование в среде, идентичной production

⚠️ Парадокс: Высокий CFR при высокой Deployment Frequency — это нормально на начальном этапе. Важен тренд: CFR должен снижаться со временем.

Что измеряет: Сколько времени нужно для восстановления сервиса после инцидента (outage, degradation, security breach).

Формула:

Из чего складывается время восстановления:

Как ускорить восстановление:

🟢 Elite практика: "Rollback, don't debug" — сначала откати, потом разбирайся. Пользователи не должны ждать, пока ты найдёшь баг.

📊 7 Team Profiles (DORA 2025)

Вместо классической классификации Low/Medium/High/Elite — новые архетипы команд на основе throughput, stability и team well-being:

🔑 Ключевой инсайт: AI не чинит команду — он усиливает то, что уже есть. Сильные команды становятся ещё эффективнее, слабые — получают усиление существующих проблем.

📈 Хорошая новость: ~40% команд попадают в профили 6-7. AI-революция доступна не только элите.

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:                          # Триггер: при каждом push
    branches: [main, develop]
  pull_request:                  # И при каждом Pull Request
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest       # На какой машине запускать

    steps:
    - name: Checkout code        # 1. Получить код
      uses: actions/checkout@v4

    - name: Setup Node.js        # 2. Установить Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20'
        cache: 'npm'             # Кеширование для скорости

    - name: Install dependencies # 3. Установить зависимости
      run: npm ci                # ci - быстрее чем install

    - name: Run linter           # 4. Проверка стиля кода
      run: npm run lint

    - name: Run tests            # 5. Запустить тесты
      run: npm test -- --coverage

    - name: Build                # 6. Собрать приложение
      run: npm run build

    - name: Upload artifact      # 7. Сохранить артефакт
      uses: actions/upload-artifact@v4
      with:
        name: build
        path: dist/
                        

Результат: Каждый push проверяется автоматически. Если что-то сломано — разработчик узнает за 5-10 минут, а не через неделю от QA.

Как работает: Поочерёдно обновляем каждый инстанс приложения. Пока один обновляется — остальные обслуживают трафик.

Плюсы: Не нужны дополнительные ресурсы, zero downtime.

Минусы: Временно работают обе версии одновременно (может быть проблемой для stateful приложений).

Инструменты: Kubernetes Deployment (по умолчанию), AWS ECS, Docker Swarm.

Как работает: Есть две идентичные среды: Blue (текущая production) и Green (новая версия). Деплоим на Green, тестируем, потом переключаем весь трафик.

Плюсы: Мгновенный rollback (просто переключи трафик обратно), можно протестировать Green перед переключением.

Минусы: Нужно 2x ресурсов, сложно с базами данных (нужны backward-compatible миграции).

Инструменты: AWS Elastic Beanstalk, Kubernetes + Istio, Azure Deployment Slots.

Как работает: Сначала направляем маленький процент трафика (1-5%) на новую версию. Мониторим метрики. Если всё ОК — постепенно увеличиваем до 100%.

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

• Error rate (5xx ошибки)
• Latency (p50, p95, p99)
• CPU/Memory usage
• Business metrics (conversion, revenue)

Инструменты: Argo Rollouts, Flagger, Istio, AWS App Mesh, Linkerd.

Что это: Переменные в коде, которые включают/выключают функционал БЕЗ нового деплоя. Код уже в production, но "спит" за флагом.

// Пример кода с feature flag
if (featureFlags.isEnabled("new-checkout-flow", userId)) {
    // Новый checkout (тестируем на 5% пользователей)
    return renderNewCheckout();
} else {
    // Старый checkout (95% пользователей)
    return renderOldCheckout();
}
                        

Типы feature flags:

Инструменты: LaunchDarkly, Unleash (open source), Split, Flagsmith, ConfigCat.

⚠️ Важно: Feature flags = технический долг. Удаляйте флаги после полного rollout! Иначе через год будет 500 флагов и никто не знает, какие активны.

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

• Dockerfile — текстовый файл с инструкциями для создания образа
• Image — готовый шаблон (read-only), из которого создаются контейнеры
• Container — запущенный экземпляр image (read-write layer сверху)
• Registry — хранилище образов (Docker Hub, ECR, GCR)
• Layer — каждая инструкция в Dockerfile создаёт слой (для кеширования)

# 1. Базовый образ — начинаем с готового образа Node.js
FROM node:20-alpine

# 2. Рабочая директория внутри контейнера
WORKDIR /app

# 3. Копируем файлы зависимостей ОТДЕЛЬНО (для кеширования!)
COPY package*.json ./

# 4. Устанавливаем зависимости
#    Если package.json не изменился — этот слой берётся из кеша
RUN npm ci --only=production

# 5. Копируем исходный код
COPY . .

# 6. Создаём непривилегированного пользователя (security!)
RUN addgroup -g 1001 appgroup && \
    adduser -u 1001 -G appgroup -D appuser
USER appuser

# 7. Открываем порт (документация)
EXPOSE 3000

# 8. Команда запуска
CMD ["node", "server.js"]
                        

Команды Docker:

# Собрать образ
docker build -t my-app:1.0.0 .

# Запустить контейнер
docker run -d -p 3000:3000 --name my-app my-app:1.0.0

# Посмотреть логи
docker logs my-app

# Зайти внутрь контейнера
docker exec -it my-app sh

# Остановить и удалить
docker stop my-app && docker rm my-app
                        

Что такое Pod: Минимальная единица деплоя в Kubernetes. Pod — это "обёртка" вокруг одного или нескольких контейнеров.

Почему не просто контейнер?

• Pod — это группа контейнеров, которые должны работать вместе
• Контейнеры в одном Pod делят сеть (localhost работает между ними)
• Контейнеры в одном Pod могут делить volumes (общие файлы)
• Pod имеет один IP-адрес на все контейнеры внутри

Пример: Основной контейнер (nginx) + sidecar-контейнер (filebeat для логов) в одном Pod.

# Пример простого Pod
apiVersion: v1
kind: Pod
metadata:
  name: my-app               # Имя Pod'а
  labels:
    app: my-app              # Метки для поиска и селекторов
spec:
  containers:
  - name: app                # Имя контейнера
    image: nginx:1.25        # Docker-образ
    ports:
    - containerPort: 80      # Порт внутри контейнера
    resources:               # Лимиты ресурсов (ВАЖНО!)
      requests:              # Минимум ресурсов (для scheduling)
        memory: "64Mi"
        cpu: "250m"          # 250 millicores = 0.25 CPU
      limits:                # Максимум (если превысит — убьют)
        memory: "128Mi"
        cpu: "500m"
                        

⚠️ Важно: Pods эфемерны! Они могут быть убиты в любой момент. Никогда не храните данные внутри Pod без Persistent Volumes.

Что такое Deployment: Объект, который управляет множеством одинаковых Pod'ов. Вы говорите "хочу 3 копии nginx", Deployment следит, чтобы всегда было ровно 3.

Что умеет Deployment:

• Declarative updates — вы описываете желаемое состояние, Kubernetes приводит к нему
• Scaling — увеличить/уменьшить количество реплик
• Rolling updates — обновить версию без downtime
• Rollback — откатить на предыдущую версию
• Self-healing — если Pod умер, создаст новый

# Пример Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3                 # Хотим 3 копии
  selector:
    matchLabels:
      app: my-app             # Какие Pod'ы этот Deployment контролирует
  template:                   # Шаблон Pod'а
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:v1.2.0
        ports:
        - containerPort: 8080

# Команды:
# kubectl apply -f deployment.yaml    # Создать/обновить
# kubectl scale deployment my-app --replicas=5  # Масштабировать
# kubectl rollout undo deployment my-app        # Откатить
                        

Проблема: Pod'ы эфемерны — их IP-адреса меняются при рестарте. Как другим сервисам найти ваше приложение?

Решение — Service: Стабильный endpoint (имя + IP), который автоматически направляет трафик на живые Pod'ы.

Типы Service:

Проблема: У вас 10 сервисов, каждому нужен отдельный домен или path. LoadBalancer на каждый = дорого.

Решение — Ingress: Один LoadBalancer + правила маршрутизации HTTP трафика.

Пример Ingress:

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

Популярные Ingress Controllers: NGINX Ingress, Traefik, HAProxy, Istio Gateway, AWS ALB Ingress Controller.

• Монолит — нет микросервисов, нет mesh
• Меньше 10 сервисов — overhead не оправдан
• Нет команды для поддержки — mesh требует экспертизы
• Простые требования — базового K8s networking достаточно

Правило: Начинайте без mesh, добавьте когда действительно нужно.

⚠️ ВАЖНО: Ingress NGINX Retirement (Ноябрь 2025)

• 12 ноября 2025 объявлено о retirement проекта Ingress NGINX
• После марта 2026: нет релизов, багфиксов, security updates
• Причина: 1-2 maintainers + CVE-2025-1974 (IngressNightmare)
• Рекомендация: мигрировать на Traefik или Gateway API

Идемпотентность — это когда запуск одного и того же кода 1 раз или 100 раз даёт одинаковый результат. Если уже есть 3 сервера и вы запустите код снова — ничего не изменится (не создаст ещё 3).

Что это: Числовые измерения, собираемые через регулярные интервалы (обычно 15-60 секунд).

Типы метрик:

Ключевые метрики (USE и RED):

• USE (для инфраструктуры): Utilization, Saturation, Errors
• RED (для сервисов): Rate, Errors, Duration
• Golden Signals (Google SRE): Latency, Traffic, Errors, Saturation

Что это: Текстовые записи о событиях с timestamp. Самый детальный, но и самый "шумный" источник данных.

Структурированные vs Неструктурированные:

# Неструктурированный лог (плохо для поиска):
2024-01-15 10:30:45 ERROR Failed to process order 12345 for user john@example.com

# Структурированный лог (JSON — хорошо для поиска):
{
  "timestamp": "2024-01-15T10:30:45Z",
  "level": "ERROR",
  "message": "Failed to process order",
  "order_id": "12345",
  "user_email": "john@example.com",
  "trace_id": "abc123",           // Связь с трейсами!
  "error_code": "PAYMENT_DECLINED"
}
                        

Уровни логирования:

• DEBUG — детали для разработки (НЕ включать в production!)
• INFO — важные события (старт, стоп, успешные операции)
• WARN — потенциальные проблемы (retry, deprecated API)
• ERROR — ошибки, требующие внимания
• FATAL — критические ошибки, приложение падает

Проблема: В микросервисной архитектуре один запрос проходит через 10-50 сервисов. Как понять, где тормозит?

Решение — Distributed Tracing:

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

• Trace — весь путь запроса от начала до конца
• Span — одна операция внутри trace (один сервис, один DB query)
• Trace ID — уникальный ID, который передаётся между сервисами
• Parent Span ID — связь между spans (кто вызвал кого)

🔥 Burn Rate — подробное объяснение

Burn rate — безразмерная величина, показывающая как быстро сервис потребляет error budget относительно целевого периода SLO.

Multi-Window, Multi-Burn-Rate алерты

Google SRE рекомендует использовать два окна для каждого уровня серьёзности — это снижает ложные срабатывания:

Логика двух окон:

IF (burn_rate_long_window > threshold) AND (burn_rate_short_window > threshold)
  THEN ALERT

// Пример для P1 (page):
IF (error_rate_1h / error_budget > 14.4) AND (error_rate_5m / error_budget > 14.4)
  THEN PAGE_ONCALL

🎯 Зачем два окна?

• Long window — подтверждает устойчивость проблемы (не spike)
• Short window — подтверждает актуальность (проблема прямо сейчас, не час назад)

⚠️ Ограничение: Multi-window подход плохо работает для low-traffic систем (ночь, выходные, мало пользователей) — нужны адаптированные подходы.

Что делает: Анализирует ИСХОДНЫЙ КОД без запуска приложения. Ищет паттерны уязвимостей.

Что находит:

• SQL Injection: query = "SELECT * FROM users WHERE id = " + userId
• XSS: innerHTML = userInput
• Hardcoded secrets: password = "admin123"
• Небезопасные функции: eval(), exec()

Плюсы: Находит проблемы ДО запуска, показывает точную строку кода

Минусы: Много false positives, не видит runtime-проблемы

Инструменты: SonarQube (бесплатный), Checkmarx, Semgrep, CodeQL (GitHub)

Что делает: Проверяет ЗАВИСИМОСТИ (npm packages, Python libraries) на известные уязвимости.

Почему это важно: 80-90% кода современных приложений — это open source зависимости. Log4Shell (CVE-2021-44228) затронул миллионы приложений через одну библиотеку.

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

Инструменты: Snyk, Dependabot (GitHub), OWASP Dependency-Check, Trivy

Что делает: Тестирует ЗАПУЩЕННОЕ приложение, отправляя вредоносные запросы.

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

• Сканер "атакует" приложение как хакер
• Отправляет SQL injection в формы: ' OR 1=1 --
• Проверяет XSS: <script>alert(1)</script>
• Ищет открытые endpoints, sensitive data exposure

Плюсы: Находит реальные уязвимости, мало false positives

Минусы: Нужно запущенное приложение, не показывает строку кода

Инструменты: OWASP ZAP (бесплатный), Burp Suite, Acunetix

Что делает: Сканирует Docker images на уязвимости в базовом образе и установленных пакетах.

Пример:

$ trivy image nginx:1.21

nginx:1.21 (debian 11.2)
Total: 127 (CRITICAL: 3, HIGH: 25, MEDIUM: 54, LOW: 45)

Best practices:

• Используйте minimal base images (Alpine, Distroless)
• Регулярно пересобирайте images для получения security patches
• Блокируйте деплой images с CRITICAL уязвимостями

Инструменты: Trivy, Grype, Clair, Snyk Container

🚨 Известные Supply Chain атаки

Эволюция хранения секретов

🔐 Vault Architecture

External Secrets Operator (ESO)

• Secrets в Git — даже в .gitignore может утечь
• Shared secrets — один API key на всех разработчиков
• Never rotate — "работает — не трогай" с паролями
• Secrets в логах — случайный log.info(config)
• Secrets в Docker image — ARG/ENV в Dockerfile

SPIFFE Architecture

Zero Trust Principles

Sigstore Components

Golden Path Example: New Microservice

Документация проходит те же проверки, что и код:

Правило: PR без обновления docs = incomplete PR. Docs review часть code review.

SPACE Framework

Developer Portal Landscape 2025

Key DX Metrics to Track

Типы Cognitive Load (Team Topologies)

Circuit Breaker Pattern

Publish/Subscribe (Pub/Sub)

GitOps Workflow

ArgoCD Architecture

• Secrets в Git — даже зашифрованные, лучше External Secrets Operator
• kubectl apply в CI — это уже не GitOps, а Push CD
• Один репо на всё — отделяйте app code от k8s manifests
• Игнорирование drift — если selfHeal отключён и кто-то правит руками
• Нет environments — dev/stage/prod должны быть разделены (разные paths или ветки)

Deployment Strategies Evolution

SLI → SLO → SLA Pipeline

Типичные SLI и их формулы

Error Budget Calculation

Error Budget Decision Tree

Почему Chaos Engineering работает

5 принципов Chaos Engineering

• Chaos без мониторинга — если не видите метрики, не поймёте результат
• Начинать с production — сначала staging, потом production
• Нет "красной кнопки" — всегда должен быть способ остановить эксперимент
• Blame game — цель найти слабости системы, не виноватых
• Chaos ради chaos — каждый эксперимент должен проверять гипотезу

Incident Timeline

Incident Response Team

Ключевой вопрос: Что управляете вы, а что — провайдер?

Зачем нужны несколько AZ?

High Availability (HA) — если один датацентр выходит из строя (пожар, наводнение, отключение питания), ваше приложение продолжает работать в других AZ.

# Пример: Deployment в Kubernetes с распределением по зонам
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  template:
    spec:
      # Распределяем pods по разным AZ
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: my-app
      containers:
        - name: app
          image: my-app:v1.0

Результат: Если AZ-a упадёт, 2 реплики в AZ-b и AZ-c продолжат обслуживать трафик.

История и философия

AWS появился в 2006 году — первый публичный cloud. Amazon построил инфраструктуру для своего e-commerce и понял, что может продавать её другим. Философия AWS: "Всё как сервис" — для любой задачи есть managed service.

Ключевые цифры:

• 200+ сервисов — больше всех на рынке
• 32 региона, 102 AZ — глобальный охват
• ~31% рынка — лидер по выручке

История и философия

Azure запустился в 2010 году как "Windows Azure" — облако для .NET. Сегодня это универсальная платформа, но с глубокой интеграцией в экосистему Microsoft: Active Directory, Office 365, Teams, GitHub.

Ключевые цифры:

• 60+ регионов — больше всех провайдеров
• ~24% рынка — быстрорастущий (#2)
• GitHub + Copilot — лучший AI для разработки

История и философия

GCP — это облако от создателей Kubernetes, TensorFlow, Borg. Google построил инфраструктуру для поиска, YouTube, Gmail и открыл её для всех. Философия: инновации и data-first.

Ключевые цифры:

• ~11% рынка — #3, но быстро растёт
• Лучшая сеть — собственный submarine fiber
• BigQuery — gold standard для analytics