Оставьте заявку
Свяжемся с вами в течение рабочего дня
Какую часть инфраструктуры можно проверить
-
Комплексный аудит инфраструктуры
Проверяем инфраструктуру целиком: архитектуру, настройки, эксплуатационные процессы, мониторинг, CI/CD, базовые риски безопасности и другие значимые компоненты. Помогаем понять текущее состояние проекта и определить, какие изменения нужны в первую очередь. -
Аудит Kubernetes
Проверяем состояние Kubernetes-инфраструктуры, конфигурацию кластера и эксплуатационные процессы вокруг него. Ищем проблемы, которые могут влиять на стабильность, безопасность, отказоустойчивость и дальнейшее развитие системы. -
Аудит CI/CD
Анализируем существующие процессы сборки, доставки и развёртывания изменений. Выявляем слабые места, ручные операции и инфраструктурные ограничения, которые влияют на скорость и надёжность выпуска изменений. -
Аудит надёжности и отказоустойчивости
Проверяем архитектуру на критичные точки отказа и оцениваем готовность инфраструктуры к сбоям. Анализируем резервирование, восстановление и другие механизмы, от которых зависит доступность системы. -
Аудит производительности
Ищем инфраструктурные ограничения и узкие места, которые могут приводить к замедлению проекта или проблемам при росте нагрузки. Определяем, какие компоненты требуют дополнительного анализа или оптимизации.
Оставить заявку
Свяжемся с вами в течение рабочего дня
Когда аудит особенно нужен
Сервис работает нестабильно
Возникают сбои, ошибки или недоступность, а причины проблем остаются неочевидными
Проект работает медленно или не выдерживает нагрузку
Нужно найти узкие места и понять, что ограничивает производительность системы
Нужно понять текущее состояние инфраструктуры
Проект работает, но нет объективного понимания его рисков, зрелости и готовности к дальнейшей эксплуатации
Готовитесь к production или росту нагрузки
Нужно заранее оценить, насколько инфраструктура готова к реальной или возросшей нагрузке
Инфраструктура выросла и стала сложнее
Появились новые сервисы, окружения и технологии, а целостного понимания состояния системы уже нет
Не хватает внутренней инфраструктурной экспертизы
Нужен независимый технический взгляд и специалисты, которые сталкивались с аналогичными задачами
Форматы аудита
Бесплатный комплексный аудит
В рамках аудита можем проверить:
инфраструктуру проекта
настройки инфраструктурных сервисов и ПО
CI/CD при наличии
мониторинг и текущую нагрузку
проблемные места в конфигурации и архитектуре
базовые настройки безопасности
Оставить заявку
на бесплатный аудит
Свяжемся с вами в течение рабочего дня
Углублённый аудит
В зависимости от задачи в аудит могут дополнительно входить:
нагрузочное тестирование
анализ стоимости инфраструктуры
аудит СУБД с привлечением DBA
проверка стратегии резервного копирования
детальный анализ отдельных компонентов и процессов
По итогам подготавливаем подробный технический отчёт с выявленными проблемами, оценкой их критичности, рекомендациями и приблизительной оценкой необходимых трудозатрат
Оставить заявку на платный аудит
Свяжемся с вами в течение рабочего дня
Что вы узнаете после аудита
Текущее состояние инфраструктуры
Вы поймёте, какие компоненты работают корректно, где есть ограничения и насколько инфраструктура готова к дальнейшей эксплуатации и развитию
Основные риски
Получите список обнаруженных проблем и понимание, какие из них требуют внимания в первую очередь
Что нужно изменить
Инженеры предложат рекомендации по устранению найденных проблем и улучшению инфраструктуры
С чего начать
Будет понятно, какие изменения приоритетны и какие работы можно планировать дальше
Как мы проводим аудит инфраструктуры
05
Обсуждаем результаты
Передаём выводы и рекомендации. После этого вы решаете, какие изменения внедрять и нужна ли дальнейшая помощь Southbridge
04
Фиксируем проблемы и рекомендации
Определяем риски, их приоритет и возможные варианты дальнейших действий
03
Проверяем инфраструктуру
Инженеры анализируют согласованные компоненты, настройки, процессы и имеющиеся данные мониторинга
02
Получаем необходимые доступы
Состав доступов зависит от устройства проекта и задачи аудита
01
Обсуждаем проект и задачу
Уточняем, что происходит с инфраструктурой, какие есть проблемы и что требуется проверить
Кейсы бесплатных аудитов
Что показал аудит
Инфраструктура имела низкий уровень готовности к продакшен
Её стабильность во многом обеспечивалась знаниями команды, а не выстроенными процессами
Практически отсутствовала автоматизация самой инфраструктуры
Сохранялась высокая зависимость от ручной эксплуатации
Использовались устаревшие компоненты
Задача:
Оценить, насколько инфраструктура после миграции в AWS готова к стабильной эксплуатации, дальнейшему развитию и масштабированию
До аудита
Проект уже был перенесён в AWS и стабильно работал, но не было объективной оценки зрелости инфраструктуры и понимания, насколько её устойчивость зависит от ручных процессов и экспертизы команды
Аудит инфраструктуры после миграции в AWS
Результат
Клиент получил оценку текущего уровня зрелости инфраструктуры, перечень ключевых рисков и понимание следующего этапа её развития.
По итогам аудита были определены приоритетные направления дальнейшей работы: внедрение Infrastructure as Code, автоматизация эксплуатации, повышение отказоустойчивости, улучшение системы мониторинга и системы оповещений, подготовка платформы к дальнейшему масштабированию
По итогам аудита были определены приоритетные направления дальнейшей работы: внедрение Infrastructure as Code, автоматизация эксплуатации, повышение отказоустойчивости, улучшение системы мониторинга и системы оповещений, подготовка платформы к дальнейшему масштабированию
/01
Аудит зрелости инфраструктуры
Executive Summary
Цель проекта заключалась не в построении новой инфраструктурной платформы, а в настройке и миграции существующего проекта в новую инфраструктуру AWS. Соответственно, аудит оценивает не современность используемых технологий сама по себе, а то, насколько созданная инфраструктура позволяет безопасно эксплуатировать перенесенную систему и насколько готова к дальнейшему развитию. Архитектурные материалы подтверждают сохранение существующей структуры приложения при переносе в AWS и использовании управляемых сервисов AWS.
Миграцию можно считать успешной:
Паспорт инфраструктуры
Таблица зрелости
Сильные стороны
Основные риски
Итоговая оценка: средняя зрелость
Для проекта, целью которого являлась миграция в AWS, инфраструктура демонстрирует хороший уровень реализации. Основная архитектура успешно перенесена в облако, критические сервисы переведены на управляемые решения AWS, внедрён автоматизированный деплой и сохранена работоспособность системы.
При этом инфраструктура ещё не достигла уровня зрелой эксплуатационной платформы. Основные ограничения связаны не с качеством миграции, а с отсутствием следующего этапа развития: внедрения Infrastructure as Code, стандартизации эксплуатации, повышения отказоустойчивости и развития наблюдаемости.
Рекомендация
Рекомендуется провести полный аудит инфраструктуры.
Основная цель такого аудита должна заключаться не в проверке качества миграции, а в разработке дорожной карты развития инфраструктуры после успешного переноса в AWS.
Приоритетными направлениями развития являются:
Цель проекта заключалась не в построении новой инфраструктурной платформы, а в настройке и миграции существующего проекта в новую инфраструктуру AWS. Соответственно, аудит оценивает не современность используемых технологий сама по себе, а то, насколько созданная инфраструктура позволяет безопасно эксплуатировать перенесенную систему и насколько готова к дальнейшему развитию. Архитектурные материалы подтверждают сохранение существующей структуры приложения при переносе в AWS и использовании управляемых сервисов AWS.
Миграцию можно считать успешной:
- инфраструктура полностью перенесена в AWS;
- критические инфраструктурные сервисы вынесены в управляемые сервисы AWS;
- сохранена существующая архитектура приложения;
- реализован автоматизированный процесс доставки через Jenkins и AWS CodeDeploy;
- организованы мониторинг и резервное копирование управляемых сервисов.
Паспорт инфраструктуры
Параметр | Значение |
Среда размещения | AWS |
Тип инфраструктуры | EC2 + Managed Services |
Kubernetes | отсутствует |
Основная ОС | Amazon Linux 2, Amazon Linux 2023 |
Container Runtime | отсутствует |
Мониторинг | Zabbix, Sentry |
CI/CD | Jenkins + AWS CodeDeploy |
Git-хранилище | Bitbucket |
Основные технологии | Symfony, React, PHP 8.2, Gearman, Aurora MySQL, DocumentDB, Redis, S3 |
Таблица зрелости
Направление | Проверка | Статус | Влияние | Комментарий |
Архитектура | Разделение ролей сервисов | 🟢Да | Среднее | Frontend, Backend, Gearman, ML и Push Notification выделены в отдельные серверы. |
Архитектура | Использование managed AWS-сервисов | 🟢Да | Высокое | Aurora, DocumentDB, ElastiCache и S3 минимизируют объем сопровождения. |
Автоматизация | Infrastructure as Code | 🔴Нет | Среднее | Следов использования IaC не обнаружено. Для проекта миграции это не критично, но ограничивает дальнейшее развитие. |
Автоматизация | Автоматическая настройка серверов | 🔴Нет | Среднее | Конфигурация серверов поддерживается вручную. |
Безопасность | Использование managed БД | 🟢Да | Среднее | Базы данных переданы AWS. |
Безопасность | Локальный firewall | 🔴Нет | Высокое | На большинстве серверов iptables отключён. |
Безопасность | Современные TLS | 🔴Нет | Среднее | На одном из серверов разрешён TLS 1.0. |
Мониторинг | Мониторинг инфраструктуры | 🟢Да | Среднее | Используется Zabbix. |
Мониторинг | Мониторинг приложений | 🟢Да | Среднее | Используется Sentry. |
Мониторинг | Покрытие мониторингом | 🟡Частично | Среднее | Один из сервисов Push Notification не подключён к мониторингу. |
CI/CD | Автоматический деплой | 🟢Да | Среднее | Используются Jenkins и AWS CodeDeploy. |
Наблюдаемость | Централизованные логи | 🔴Нет | Среднее | Полноценная система хранения инфраструктурных логов отсутствует. |
Отказоустойчивость | Managed Database | 🟢Да | Среднее | Используются Multi-AZ сервисы AWS. Предположение: для основных БД используется штатная отказоустойчивость Aurora. |
Отказоустойчивость | Single Point of Failure приложений | 🟡Частично | Высокое | Большинство прикладных компонентов представлены одним экземпляром EC2. |
Эксплуатация | Актуальность операционной системы | 🟡Частично | Среднее | Используются Amazon Linux 2 и Amazon Linux 2023. |
Эксплуатация | Актуальность прикладного ПО | 🔴Нет | Среднее | Node.js 6. x значительно устарел. |
Эксплуатация | Управление сервисами | 🔴Нет | Высокое | Обнаружен ручной запуск Gearman пользователем ec2-user. |
Эксплуатация | Резервное копирование | 🟢Да | Среднее | Для Aurora используются штатные AWS Snapshots. |
Эксплуатация | Проверенное восстановление | 🟡Частично | Среднее | Предположение: используются штатные механизмы восстановления AWS, однако подтверждения регулярных тестов восстановления не обнаружено. |
Сильные стороны
- Основная цель проекта — миграция инфраструктуры в AWS — успешно достигнута.
- Максимально используются управляемые сервисы AWS, что существенно снижает эксплуатационную нагрузку.
- Архитектура приложения практически не изменилась при переносе, что уменьшило риски миграции.
- Настроен автоматизированный процесс доставки приложений через Jenkins и AWS CodeDeploy.
- Используются отдельные средства мониторинга инфраструктуры и приложений (Zabbix и Sentry).
Основные риски
- Инфраструктура пока не описана в виде Infrastructure as Code.
- Конфигурация серверов зависит от ручных операций.
- Gearman запускается вручную, что увеличивает вероятность эксплуатационных ошибок.
- Используются устаревшие версии Node. js и npm.
- На части серверов отсутствует локальная фильтрация сетевого трафика.
- Разрешён TLS 1.0.
- Большинство сервисов остаются Single Point of Failure.
- Отсутствует централизованная система хранения инфраструктурных логов.
- Не завершена стандартизация конфигурации серверов.
- Масштабирование инфраструктуры потребует дополнительной автоматизации.
Итоговая оценка: средняя зрелость
Для проекта, целью которого являлась миграция в AWS, инфраструктура демонстрирует хороший уровень реализации. Основная архитектура успешно перенесена в облако, критические сервисы переведены на управляемые решения AWS, внедрён автоматизированный деплой и сохранена работоспособность системы.
При этом инфраструктура ещё не достигла уровня зрелой эксплуатационной платформы. Основные ограничения связаны не с качеством миграции, а с отсутствием следующего этапа развития: внедрения Infrastructure as Code, стандартизации эксплуатации, повышения отказоустойчивости и развития наблюдаемости.
Рекомендация
Рекомендуется провести полный аудит инфраструктуры.
Основная цель такого аудита должна заключаться не в проверке качества миграции, а в разработке дорожной карты развития инфраструктуры после успешного переноса в AWS.
Приоритетными направлениями развития являются:
- внедрение Infrastructure as Code;
- автоматизация конфигурации серверов;
- устранение ручных процедур эксплуатации;
- повышение отказоустойчивости прикладных сервисов;
- внедрение централизованной системы журналирования;
- актуализация устаревших компонентов программного обеспечения;
- стандартизация эксплуатационных практик и подготовка инфраструктуры к дальнейшему масштабированию.
Аудит зрелости инфраструктуры
Executive Summary
Цель проекта заключалась не в построении новой инфраструктурной платформы, а в настройке и миграции существующего проекта в новую инфраструктуру AWS. Соответственно, аудит оценивает не современность используемых технологий сама по себе, а то, насколько созданная инфраструктура позволяет безопасно эксплуатировать перенесенную систему и насколько готова к дальнейшему развитию. Архитектурные материалы подтверждают сохранение существующей структуры приложения при переносе в AWS и использовании управляемых сервисов AWS.
Миграцию можно считать успешной:
Паспорт инфраструктуры
Таблица зрелости:
Обозначение статусов:
🟢да / 🟡частично / 🔴 нет
Архитектура
🟢 Разделение ролей сервисов
Влияние: Среднее
Frontend, Backend, Gearman, ML и Push Notification выделены в отдельные серверы.
🟢 Использование managed AWS-сервисов
Влияние: Высокое
Aurora, DocumentDB, ElastiCache и S3 минимизируют объем сопровождения.
Автоматизация
🔴 Infrastructure as Code
Влияние: Среднее
Следов использования IaC не обнаружено. Для проекта миграции это не критично, но ограничивает дальнейшее развитие.
🔴 Автоматическая настройка серверов
Влияние: Среднее
Конфигурация серверов поддерживается вручную.
Безопасность
🟢 Использование managed БД
Влияние: Среднее
Базы данных переданы AWS.
🔴 Локальный firewall
Влияние: Высокое
На большинстве серверов iptables отключён.
🔴 Современные TLS
Влияние: Среднее
На одном из серверов разрешён TLS 1.0.
Мониторинг
🟢 Мониторинг инфраструктуры
Влияние: Среднее
Используется Zabbix.
🟢 Мониторинг приложений
Влияние: Среднее
Используется Sentry.
🟡 Покрытие мониторингом
Влияние: Среднее
Один из сервисов Push Notification не подключён к мониторингу.
CI/CD
🟢 Автоматический деплой
Влияние: Среднее
Используются Jenkins и AWS CodeDeploy.
Наблюдаемость
🔴 Централизованные логи
Влияние: Среднее
Полноценная система хранения инфраструктурных логов отсутствует.
Отказоустойчивость
🟢 Managed Database
Влияние: Среднее
Используются Multi-AZ сервисы AWS. Предположение: для основных БД используется штатная отказоустойчивость Aurora.
🟡 Single Point of Failure приложений
Влияние: Высокое
Большинство прикладных компонентов представлены одним экземпляром EC2.
Эксплуатация
🟡 Актуальность операционной системы
Влияние: Среднее
Используются Amazon Linux 2 и Amazon Linux 2023.
🔴 Актуальность прикладного ПО
Влияние: Среднее
Node.js 6.x значительно устарел.
🔴 Управление сервисами
Влияние: Высокое
Обнаружен ручной запуск Gearman пользователем ec2-user.
🟢 Резервное копирование
Влияние: Среднее
Для Aurora используются штатные AWS Snapshots.
🟡 Проверенное восстановление
Влияние: Среднее
Предположение: используются штатные механизмы восстановления AWS, однако подтверждения регулярных тестов восстановления не обнаружено.
Сильные стороны
Основные риски
Итоговая оценка: средняя зрелость
Для проекта, целью которого являлась миграция в AWS, инфраструктура демонстрирует хороший уровень реализации. Основная архитектура успешно перенесена в облако, критические сервисы переведены на управляемые решения AWS, внедрён автоматизированный деплой и сохранена работоспособность системы.
При этом инфраструктура ещё не достигла уровня зрелой эксплуатационной платформы. Основные ограничения связаны не с качеством миграции, а с отсутствием следующего этапа развития: внедрения Infrastructure as Code, стандартизации эксплуатации, повышения отказоустойчивости и развития наблюдаемости.
Рекомендация
Рекомендуется провести полный аудит инфраструктуры.
Основная цель такого аудита должна заключаться не в проверке качества миграции, а в разработке дорожной карты развития инфраструктуры после успешного переноса в AWS.
Приоритетными направлениями развития являются:
Цель проекта заключалась не в построении новой инфраструктурной платформы, а в настройке и миграции существующего проекта в новую инфраструктуру AWS. Соответственно, аудит оценивает не современность используемых технологий сама по себе, а то, насколько созданная инфраструктура позволяет безопасно эксплуатировать перенесенную систему и насколько готова к дальнейшему развитию. Архитектурные материалы подтверждают сохранение существующей структуры приложения при переносе в AWS и использовании управляемых сервисов AWS.
Миграцию можно считать успешной:
- инфраструктура полностью перенесена в AWS;
- критические инфраструктурные сервисы вынесены в управляемые сервисы AWS;
- сохранена существующая архитектура приложения;
- реализован автоматизированный процесс доставки через Jenkins и AWS CodeDeploy;
- организованы мониторинг и резервное копирование управляемых сервисов.
Паспорт инфраструктуры
- Среда размещения: AWS
- Тип инфраструктуры: EC2 + Managed Services
- Kubernetes: отсутствует
- Основная ОС: Amazon Linux 2, Amazon Linux 2023
- Container Runtime: отсутствует
- Мониторинг: Zabbix, Sentry
- CI/CD: Jenkins + AWS CodeDeploy
- Git-хранилище: Bitbucket
- Основные технологии: Symfony, React, PHP 8.2, Gearman, Aurora MySQL, DocumentDB, Redis, S3
Таблица зрелости:
Обозначение статусов:
🟢да / 🟡частично / 🔴 нет
Архитектура
🟢 Разделение ролей сервисов
Влияние: Среднее
Frontend, Backend, Gearman, ML и Push Notification выделены в отдельные серверы.
🟢 Использование managed AWS-сервисов
Влияние: Высокое
Aurora, DocumentDB, ElastiCache и S3 минимизируют объем сопровождения.
Автоматизация
🔴 Infrastructure as Code
Влияние: Среднее
Следов использования IaC не обнаружено. Для проекта миграции это не критично, но ограничивает дальнейшее развитие.
🔴 Автоматическая настройка серверов
Влияние: Среднее
Конфигурация серверов поддерживается вручную.
Безопасность
🟢 Использование managed БД
Влияние: Среднее
Базы данных переданы AWS.
🔴 Локальный firewall
Влияние: Высокое
На большинстве серверов iptables отключён.
🔴 Современные TLS
Влияние: Среднее
На одном из серверов разрешён TLS 1.0.
Мониторинг
🟢 Мониторинг инфраструктуры
Влияние: Среднее
Используется Zabbix.
🟢 Мониторинг приложений
Влияние: Среднее
Используется Sentry.
🟡 Покрытие мониторингом
Влияние: Среднее
Один из сервисов Push Notification не подключён к мониторингу.
CI/CD
🟢 Автоматический деплой
Влияние: Среднее
Используются Jenkins и AWS CodeDeploy.
Наблюдаемость
🔴 Централизованные логи
Влияние: Среднее
Полноценная система хранения инфраструктурных логов отсутствует.
Отказоустойчивость
🟢 Managed Database
Влияние: Среднее
Используются Multi-AZ сервисы AWS. Предположение: для основных БД используется штатная отказоустойчивость Aurora.
🟡 Single Point of Failure приложений
Влияние: Высокое
Большинство прикладных компонентов представлены одним экземпляром EC2.
Эксплуатация
🟡 Актуальность операционной системы
Влияние: Среднее
Используются Amazon Linux 2 и Amazon Linux 2023.
🔴 Актуальность прикладного ПО
Влияние: Среднее
Node.js 6.x значительно устарел.
🔴 Управление сервисами
Влияние: Высокое
Обнаружен ручной запуск Gearman пользователем ec2-user.
🟢 Резервное копирование
Влияние: Среднее
Для Aurora используются штатные AWS Snapshots.
🟡 Проверенное восстановление
Влияние: Среднее
Предположение: используются штатные механизмы восстановления AWS, однако подтверждения регулярных тестов восстановления не обнаружено.
Сильные стороны
- Основная цель проекта — миграция инфраструктуры в AWS — успешно достигнута.
- Максимально используются управляемые сервисы AWS, что существенно снижает эксплуатационную нагрузку.
- Архитектура приложения практически не изменилась при переносе, что уменьшило риски миграции.
- Настроен автоматизированный процесс доставки приложений через Jenkins и AWS CodeDeploy.
- Используются отдельные средства мониторинга инфраструктуры и приложений (Zabbix и Sentry).
Основные риски
- Инфраструктура пока не описана в виде Infrastructure as Code.
- Конфигурация серверов зависит от ручных операций.
- Gearman запускается вручную, что увеличивает вероятность эксплуатационных ошибок.
- Используются устаревшие версии Node. js и npm.
- На части серверов отсутствует локальная фильтрация сетевого трафика.
- Разрешён TLS 1.0.
- Большинство сервисов остаются Single Point of Failure.
- Отсутствует централизованная система хранения инфраструктурных логов.
- Не завершена стандартизация конфигурации серверов.
- Масштабирование инфраструктуры потребует дополнительной автоматизации.
Итоговая оценка: средняя зрелость
Для проекта, целью которого являлась миграция в AWS, инфраструктура демонстрирует хороший уровень реализации. Основная архитектура успешно перенесена в облако, критические сервисы переведены на управляемые решения AWS, внедрён автоматизированный деплой и сохранена работоспособность системы.
При этом инфраструктура ещё не достигла уровня зрелой эксплуатационной платформы. Основные ограничения связаны не с качеством миграции, а с отсутствием следующего этапа развития: внедрения Infrastructure as Code, стандартизации эксплуатации, повышения отказоустойчивости и развития наблюдаемости.
Рекомендация
Рекомендуется провести полный аудит инфраструктуры.
Основная цель такого аудита должна заключаться не в проверке качества миграции, а в разработке дорожной карты развития инфраструктуры после успешного переноса в AWS.
Приоритетными направлениями развития являются:
- внедрение Infrastructure as Code;
- автоматизация конфигурации серверов;
- устранение ручных процедур эксплуатации;
- повышение отказоустойчивости прикладных сервисов;
- внедрение централизованной системы журналирования;
- актуализация устаревших компонентов программного обеспечения;
- стандартизация эксплуатационных практик и подготовка инфраструктуры к дальнейшему масштабированию.
Что показал аудит
Инфраструктура находится на среднем уровне зрелости
Основные сервисы успешно переведены в managed-решения, однако эксплуатация по-прежнему во многом опирается на устаревшую модель
Отсутствуют Infrastructure as Code и автоматизация конфигурации серверов
Вся production-инфраструктура зависит от одного сервера
Используются устаревшие версии операционной системы и части программного обеспечения
Процесс доставки изменений и эксплуатации требует модернизации
Задача:
Оценить текущее состояние инфраструктуры, определить уровень её зрелости и предложить техническое решение, которое обеспечит отказоустойчивость проекта и возможность его дальнейшего масштабирования
До аудита
За последние годы инфраструктура была значительно модернизирована: база данных, файловое хранилище и часть сервисов были перенесены в managed-решения Яндекс Облака. При этом отсутствовало понимание, насколько текущая эксплуатационная модель соответствует современным требованиям к отказоустойчивости, автоматизации и масштабируемости
Аудит инфраструктуры образовательной платформы
Результат
Клиент получил оценку текущего уровня зрелости инфраструктуры, перечень ключевых рисков и понимание дальнейших шагов по её развитию.
По итогам аудита мы рекомендовали провести полный аудит инфраструктуры, чтобы спроектировать отказоустойчивую архитектуру, подготовить переход на Infrastructure as Code, модернизировать процессы эксплуатации и сформировать дорожную карту дальнейшего развития платформы.
В дальнейшем мы внедрили предложенные рекомендации, подготовили документацию и обучили сотрудников клиента работе с обновлённой системой
По итогам аудита мы рекомендовали провести полный аудит инфраструктуры, чтобы спроектировать отказоустойчивую архитектуру, подготовить переход на Infrastructure as Code, модернизировать процессы эксплуатации и сформировать дорожную карту дальнейшего развития платформы.
В дальнейшем мы внедрили предложенные рекомендации, подготовили документацию и обучили сотрудников клиента работе с обновлённой системой
/02
Аудит инфраструктуры образовательной платформы
Executive Summary
Инфраструктура находится на среднем уровне зрелости.
За последние годы выполнена существенная модернизация:
Паспорт инфраструктуры
Таблица зрелости
Сильные стороны
Основные риски
Итоговая оценка: средняя зрелость
Инфраструктура находится на переходном этапе между классической BitrixVM и современной облачной архитектурой.
Основные инфраструктурные зависимости (БД, S3, Kafka) уже вынесены в managed-сервисы, что существенно снижает эксплуатационные риски. Однако уровень зрелости ограничивается ручным управлением приложением, отсутствием IaC и высокой зависимостью от единственного production-сервера.
Рекомендация
Рекомендуется провести полный аудит инфраструктуры.
Причины:
Инфраструктура находится на среднем уровне зрелости.
За последние годы выполнена существенная модернизация:
- база данных вынесена в Managed MySQL;
- пользовательские файлы перенесены в S3;
- используется Managed Kafka;
- код хранится в GitLab;
- применяется CI/CD;
- часть инфраструктурных сервисов переведена в managed-сервисы Яндекс Облака.
- единственный production-сервер;
- отсутствие Infrastructure as Code;
- деплой через git pull по SSH;
- изменения непосредственно на production;
- отсутствие отказоустойчивости веб-слоя;
- устаревшая ОС и стек ПО.
Паспорт инфраструктуры
Параметр | Значение |
Количество production-серверов | 1 Web/Application |
Среда размещения | Yandex Cloud |
Kubernetes | Не используется |
Основная ОС | CentOS 7 |
Runtime | Apache + PHP-FPM |
Балансировка | отсутствует |
Мониторинг | Yandex Cloud Monitoring |
CI/CD | GitLab CI |
Git | GitLab |
Основные технологии | BitrixVM, MySQL Managed, Redis, Memcached, Kafka, S3 |
Таблица зрелости
Направление | Проверка | Статус | Влияние | Комментарий |
Архитектура | Отказоустойчивость приложения | 🔴Нет | Высокое | Один production-сервер |
Архитектура | Отказоустойчивость БД | 🟢Да | Среднее | Managed MySQL с двумя узлами |
Архитектура | Вынос файлов в объектное хранилище | 🟢Да | Среднее | Используется S3, локальное хранилище практически исключено |
Автоматизация | Infrastructure as Code | 🔴Нет | Высокое | Не используется |
Автоматизация | Конфигурация серверов | 🔴Нет | Высокое | Настройка вручную |
Автоматизация | Документированная инфраструктура | 🟡Частично | Среднее | Настройки разбросаны по системе |
Безопасность | Managed Database | 🟢Да | Среднее | Используется сервис Яндекс |
Безопасность | Приватные S3-бакеты | 🟢Да | Среднее | Пользовательские файлы доступны только после авторизации |
Безопасность | Современная ОС | 🔴Нет | Высокое | CentOS 7 снята с поддержки |
Безопасность | Актуальность ПО | 🔴Нет | Высокое | Устаревшие nginx, Apache, PHP |
Мониторинг | Мониторинг инфраструктуры | 🟢Да | Среднее | Используется мониторинг облака |
Мониторинг | Мониторинг производительности БД | 🟢Да | Среднее | Выявлены проблемные запросы |
Мониторинг | Централизованные логи | 🟡Частично | Среднее | Логи распределены по серверу |
Эксплуатация | Git | 🟢Да | Низкое | Используется GitLab |
Эксплуатация | Production соответствует Git | 🔴Нет | Высокое | На production имеются локальные изменения |
CI/CD | Автоматический деплой | 🟡Частично | Среднее | GitLab CI выполняет git pull |
CI/CD | Immutable deployment | 🔴Нет | Высокое | Сервер изменяется "на месте" |
Эксплуатация | Managed MySQL | 🟢Да | Среднее | Используется сервис облака |
Эксплуатация | Managed Kafka | 🟢Да | Среднее | Используется сервис облака |
Эксплуатация | Managed Object Storage | 🟢Да | Среднее | Используется S3 |
Отказоустойчивость | Балансировщик | 🔴Нет | Высокое | Отсутствует |
Отказоустойчивость | Масштабирование Web | 🔴Нет | Высокое | Один сервер |
Наблюдаемость | Анализ производительности БД | 🟢Да | Среднее | Выявлены тяжелые запросы |
Наблюдаемость | Централизованный сбор событий | 🔴Нет | Среднее | Не обнаружен |
Сильные стороны
- Большая часть тяжелых сервисов уже вынесена в Managed Services Яндекс Облака.
- Пользовательские файлы успешно вынесены в S3 (более 400 ГБ данных и свыше миллиона объектов).
- Используется GitLab и CI/CD.
- База данных уже отделена от приложения.
- Производительность инфраструктуры регулярно анализируется.
Основные риски
- Единственный production-сервер остается единой точкой отказа.
- Используется CentOS 7, поддержка которой прекращена.
- В production присутствуют изменения, отсутствующие в Git.
- Деплой осуществляется через SSH и git pull.
- Отсутствует Infrastructure as Code.
- Нет возможности быстро восстановить инфраструктуру с нуля.
- Большое количество неоптимизированных SQL-запросов.
- В базе имеются крупные таблицы без индексов.
- Настройки распределены по множеству файлов.
- Отдельные сервисы продолжают использовать устаревшие механизмы BitrixVM.
Итоговая оценка: средняя зрелость
Инфраструктура находится на переходном этапе между классической BitrixVM и современной облачной архитектурой.
Основные инфраструктурные зависимости (БД, S3, Kafka) уже вынесены в managed-сервисы, что существенно снижает эксплуатационные риски. Однако уровень зрелости ограничивается ручным управлением приложением, отсутствием IaC и высокой зависимостью от единственного production-сервера.
Рекомендация
Рекомендуется провести полный аудит инфраструктуры.
Причины:
- необходимо разработать целевую архитектуру отказоустойчивого production;
- требуется спроектировать переход на Infrastructure as Code;
- необходимо изменить модель доставки изменений (GitOps/Immutable Deployment);
- требуется сформировать единый подход к эксплуатации, логированию и конфигурации;
- целесообразно подготовить план миграции на современный кластер из нескольких web- и worker-серверов под управлением актуальной версии BitrixVM или альтернативной платформы.
Аудит инфраструктуры образовательной платформы
Executive Summary
Инфраструктура находится на среднем уровне зрелости.
За последние годы выполнена существенная модернизация:
Паспорт инфраструктуры
Таблица зрелости:
Обозначение статусов:
🟢да / 🟡частично / 🔴 нет
Архитектура
🔴 Отказоустойчивость приложения
Влияние: Высокое
Один production-сервер
🟢 Отказоустойчивость БД
Влияние: Среднее
Managed MySQL с двумя узлами
🟢 Вынос файлов в объектное хранилище
Влияние: Среднее
Используется S3, локальное хранилище практически исключено
Автоматизация
🔴 Infrastructure as Code
Влияние: Высокое
Не используется
🔴 Конфигурация серверов
Влияние: Высокое
Настройка вручную
🟡 Документированная инфраструктура
Влияние: Среднее
Настройки разбросаны по системе
Безопасность
🟢 Managed Database
Влияние: Среднее
Используется сервис Яндекс
🟢 Приватные S3-бакеты
Влияние: Среднее
Пользовательские файлы доступны только после авторизации
🔴 Современная ОС
Влияние: Высокое
CentOS 7 снята с поддержки
🔴 Актуальность ПО
Влияние: Высокое
Устаревшие nginx, Apache, PHP
Мониторинг
🟢 Мониторинг инфраструктуры
Влияние: Среднее
Используется мониторинг облака
🟢 Мониторинг производительности БД
Влияние: Среднее
Выявлены проблемные запросы
🟡 Централизованные логи
Влияние: Среднее
Логи распределены по серверу
Эксплуатация
🟢 Git
Влияние: Низкое
Используется GitLab
🔴 Production соответствует Git
Влияние: Высокое
На production имеются локальные изменения
CI/CD
🟡 Автоматический деплой
Влияние: Среднее
GitLab CI выполняет git pull
🔴 Immutable deployment
Влияние: Высокое
Сервер изменяется "на месте"
Эксплуатация
🟢 Managed MySQL
Влияние: Среднее
Используется сервис облака
🟢 Managed Kafka
Влияние: Среднее
Используется сервис облака
🟢 Managed Object Storage
Влияние: Среднее
Используется S3
Отказоустойчивость
🔴 Балансировщик
Влияние: Высокое
Отсутствует
🔴 Масштабирование Web
Влияние: Высокое
Один сервер
Наблюдаемость
🟢 Анализ производительности БД
Влияние: Среднее
Выявлены тяжелые запросы
🔴 Централизованный сбор событий
Влияние: Среднее
Не обнаружен
Сильные стороны
Основные риски
Итоговая оценка: средняя зрелость
Инфраструктура находится на переходном этапе между классической BitrixVM и современной облачной архитектурой.
Основные инфраструктурные зависимости (БД, S3, Kafka) уже вынесены в managed-сервисы, что существенно снижает эксплуатационные риски. Однако уровень зрелости ограничивается ручным управлением приложением, отсутствием IaC и высокой зависимостью от единственного production-сервера.
Рекомендация
Рекомендуется провести полный аудит инфраструктуры.
Причины:
Инфраструктура находится на среднем уровне зрелости.
За последние годы выполнена существенная модернизация:
- база данных вынесена в Managed MySQL;
- пользовательские файлы перенесены в S3;
- используется Managed Kafka;
- код хранится в GitLab;
- применяется CI/CD;
- часть инфраструктурных сервисов переведена в managed-сервисы Яндекс Облака.
- единственный production-сервер;
- отсутствие Infrastructure as Code;
- деплой через git pull по SSH;
- изменения непосредственно на production;
- отсутствие отказоустойчивости веб-слоя;
- устаревшая ОС и стек ПО.
Паспорт инфраструктуры
- Количество production-серверов: 1 Web/Application
- Среда размещения: Yandex Cloud
- Kubernetes: Не используется
- Основная ОС: CentOS 7
- Runtime: Apache + PHP-FPM
- Балансировка: отсутствует
- Мониторинг: Yandex Cloud Monitoring
- CI/CD: GitLab CI
- Git: GitLab
- Основные технологии: BitrixVM, MySQL Managed, Redis, Memcached, Kafka, S3
Таблица зрелости:
Обозначение статусов:
🟢да / 🟡частично / 🔴 нет
Архитектура
🔴 Отказоустойчивость приложения
Влияние: Высокое
Один production-сервер
🟢 Отказоустойчивость БД
Влияние: Среднее
Managed MySQL с двумя узлами
🟢 Вынос файлов в объектное хранилище
Влияние: Среднее
Используется S3, локальное хранилище практически исключено
Автоматизация
🔴 Infrastructure as Code
Влияние: Высокое
Не используется
🔴 Конфигурация серверов
Влияние: Высокое
Настройка вручную
🟡 Документированная инфраструктура
Влияние: Среднее
Настройки разбросаны по системе
Безопасность
🟢 Managed Database
Влияние: Среднее
Используется сервис Яндекс
🟢 Приватные S3-бакеты
Влияние: Среднее
Пользовательские файлы доступны только после авторизации
🔴 Современная ОС
Влияние: Высокое
CentOS 7 снята с поддержки
🔴 Актуальность ПО
Влияние: Высокое
Устаревшие nginx, Apache, PHP
Мониторинг
🟢 Мониторинг инфраструктуры
Влияние: Среднее
Используется мониторинг облака
🟢 Мониторинг производительности БД
Влияние: Среднее
Выявлены проблемные запросы
🟡 Централизованные логи
Влияние: Среднее
Логи распределены по серверу
Эксплуатация
🟢 Git
Влияние: Низкое
Используется GitLab
🔴 Production соответствует Git
Влияние: Высокое
На production имеются локальные изменения
CI/CD
🟡 Автоматический деплой
Влияние: Среднее
GitLab CI выполняет git pull
🔴 Immutable deployment
Влияние: Высокое
Сервер изменяется "на месте"
Эксплуатация
🟢 Managed MySQL
Влияние: Среднее
Используется сервис облака
🟢 Managed Kafka
Влияние: Среднее
Используется сервис облака
🟢 Managed Object Storage
Влияние: Среднее
Используется S3
Отказоустойчивость
🔴 Балансировщик
Влияние: Высокое
Отсутствует
🔴 Масштабирование Web
Влияние: Высокое
Один сервер
Наблюдаемость
🟢 Анализ производительности БД
Влияние: Среднее
Выявлены тяжелые запросы
🔴 Централизованный сбор событий
Влияние: Среднее
Не обнаружен
Сильные стороны
- Большая часть тяжелых сервисов уже вынесена в Managed Services Яндекс Облака.
- Пользовательские файлы успешно вынесены в S3 (более 400 ГБ данных и свыше миллиона объектов).
- Используется GitLab и CI/CD.
- База данных уже отделена от приложения.
- Производительность инфраструктуры регулярно анализируется.
Основные риски
- Единственный production-сервер остается единой точкой отказа.
- Используется CentOS 7, поддержка которой прекращена.
- В production присутствуют изменения, отсутствующие в Git.
- Деплой осуществляется через SSH и git pull.
- Отсутствует Infrastructure as Code.
- Нет возможности быстро восстановить инфраструктуру с нуля.
- Большое количество неоптимизированных SQL-запросов.
- В базе имеются крупные таблицы без индексов.
- Настройки распределены по множеству файлов.
- Отдельные сервисы продолжают использовать устаревшие механизмы BitrixVM.
Итоговая оценка: средняя зрелость
Инфраструктура находится на переходном этапе между классической BitrixVM и современной облачной архитектурой.
Основные инфраструктурные зависимости (БД, S3, Kafka) уже вынесены в managed-сервисы, что существенно снижает эксплуатационные риски. Однако уровень зрелости ограничивается ручным управлением приложением, отсутствием IaC и высокой зависимостью от единственного production-сервера.
Рекомендация
Рекомендуется провести полный аудит инфраструктуры.
Причины:
- необходимо разработать целевую архитектуру отказоустойчивого production;
- требуется спроектировать переход на Infrastructure as Code;
- необходимо изменить модель доставки изменений (GitOps/Immutable Deployment);
- требуется сформировать единый подход к эксплуатации, логированию и конфигурации;
- целесообразно подготовить план миграции на современный кластер из нескольких web- и worker-серверов под управлением актуальной версии BitrixVM или альтернативной платформы.
Что показал аудит
Инфраструктура получила критическую оценку уровня зрелости
Основные проблемы связаны не с Kubernetes, а с организацией эксплуатации и сопровождения приложения
Отсутствуют Infrastructure as Code и полноценная автоматизация инфраструктуры
Выявлены проблемы, влияющие на стабильность работы backend, отказоустойчивость и безопасность
Мониторинг присутствует, но не обеспечивает своевременное обнаружение деградации сервисов
Задача:
Оценить текущее состояние Kubernetes-инфраструктуры, выявить причины нестабильной работы сервисов и определить основные риски для дальнейшей эксплуатации
До аудита
Инфраструктура была построена на современном технологическом стеке с использованием Managed Kubernetes, Managed PostgreSQL, GitLab CI и других облачных сервисов. При этом сервисы работали нестабильно, а причины регулярных сбоев и ограничений эксплуатации оставались неочевидными
Аудит Kubernetes-инфраструктуры сети ресторанов
Результат
Клиент получил объективную оценку состояния инфраструктуры, перечень критических рисков и понимание причин нестабильной работы сервисов.
По итогам аудита мы составили план работ со сроками и оценили предварительную стоимость реализации, включающую устранение причин сбоев backend, закрытие критических уязвимостей, выстраивание современной эксплуатационной модели и повышение отказоустойчивости платформы
По итогам аудита мы составили план работ со сроками и оценили предварительную стоимость реализации, включающую устранение причин сбоев backend, закрытие критических уязвимостей, выстраивание современной эксплуатационной модели и повышение отказоустойчивости платформы
/03
Аудит Kubernetes-инфраструктуры сети ресторанов
Executive Summary
Итоговая оценка зрелости: критическая зрелость
Инфраструктура проекта построена на современном технологическом стеке (Managed Kubernetes, Managed PostgreSQL, S3, GitLab CI), однако уровень эксплуатационной зрелости существенно ниже необходимого для стабильной промышленной эксплуатации.
Наиболее существенные проблемы:
Паспорт инфраструктуры
Таблица зрелости
Сильные стороны
Основные риски
Итоговая оценка: критическая зрелость
Инфраструктура обладает современным технологическим фундаментом, однако эксплуатационная модель не соответствует требованиям промышленной эксплуатации.
Наиболее критичными являются:
Рекомендация
Рекомендуется провести полный аудит инфраструктуры.
Приоритет работ целесообразно выстроить следующим образом:
Итоговая оценка зрелости: критическая зрелость
Инфраструктура проекта построена на современном технологическом стеке (Managed Kubernetes, Managed PostgreSQL, S3, GitLab CI), однако уровень эксплуатационной зрелости существенно ниже необходимого для стабильной промышленной эксплуатации.
Наиболее существенные проблемы:
- отсутствуют requests/limits практически у всех workload’ов;
- наблюдаются признаки утечки памяти backend;
- приложение регулярно перезапускается (десятки рестартов);
- отсутствует полноценный мониторинг и алертинг;
- используются устаревшие версии инфраструктурных компонентов с критическими CVE;
- отсутствует Infrastructure as Code;
- имеются публично доступные административные интерфейсы;
- значительная часть инфраструктуры настроена вручную.
Паспорт инфраструктуры
Параметр | Значение |
Количество кластеров | 1 |
Среда размещения | Selectel Cloud |
Kubernetes | Managed Kubernetes 1.29 |
Основная ОС | Ubuntu 22.04 LTS |
Container Runtime | containerd |
CNI | Стандартный Managed Kubernetes |
Мониторинг | Prometheus + Grafana + Loki |
CI/CD | GitLab CI |
Git-хранилище | Внешний GitLab |
Основные технологии | Kubernetes, PostgreSQL 16, Redis, Ruby on Rails, ArgoCD, NGINX Ingress |
Таблица зрелости
Направление | Проверка | Статус | Влияние | Комментарий |
Архитектура | Поддерживаемая версия Kubernetes | 🔴 Нет | Высокое | Используется Kubernetes 1.29, требующий обновления. |
Архитектура | Отказоустойчивость Control Plane | 🟢 Да | Среднее | Используется Managed Kubernetes. |
Архитектура | Отказоустойчивость ETCD | 🟢 Да | Среднее | Используется Managed PostgreSQL и Managed Kubernetes. |
Автоматизация | Infrastructure as Code | 🔴 Нет | Очень высокое | Признаков Terraform или другого IaC не обнаружено. |
Автоматизация | Автоматическое обновление сертификатов | 🟡 Частично | Среднее | Предположение: управление сертификатами выполняет Managed Kubernetes, однако остальные компоненты обновляются вручную. |
Автоматизация | Единый способ установки компонентов | 🔴 Нет | Высокое | Компоненты устанавливались различными способами. |
CI/CD | Шаблоны CI | 🟡 Частично | Среднее | CI существует, однако доступа для оценки качества не предоставлено. |
CI/CD | Helm или аналог | 🟡 Частично | Среднее | Используются Helm-чарты для части компонентов. |
CI/CD | GitOps | 🟡 Частично | Среднее | Используется ArgoCD, однако его конфигурация требует актуализации. |
Мониторинг | Мониторинг Kubernetes | 🟢 Да | Среднее | Grafana, Prometheus и Loki присутствуют. |
Мониторинг | Alertmanager | 🔴 Нет | Высокое | Канал Telegram настроен, рабочих алертов нет. |
Мониторинг | Сохранение метрик | 🟢 Да | Низкое | Метрики сохраняются. |
Наблюдаемость | Централизованные логи | 🟢 Да | Среднее | Используется Loki. |
Наблюдаемость | Сбор событий Kubernetes | 🔴 Нет | Среднее | Данных о сборе Kubernetes Events нет. |
Безопасность | NetworkPolicy | 🔴 Нет | Высокое | Сетевые политики отсутствуют. |
Безопасность | Ограничение доступа к API | 🔴 Нет | Очень высокое | Kubernetes API опубликован в интернет. |
Безопасность | Внутренние Registry | 🟡 Частично | Среднее | Используются внешние registry. |
Отказоустойчивость | Минимум две реплики критичных сервисов | 🔴 Нет | Очень высокое | Web, Redis, Sidekiq работают в одной реплике. |
Отказоустойчивость | Корректный Rolling Update | 🔴 Нет | Высокое | Обнаружены миграции БД при старте каждой реплики backend. |
Эксплуатация | Резервное копирование | 🟡 Частично | Среднее | Используются Managed PostgreSQL и S3, стратегия резервного копирования приложений не подтверждена. |
Эксплуатация | Проверенное восстановление | 🔴 Нет | Высокое | Информации о регулярных проверках восстановления нет. |
Сильные стороны
- Используется Managed Kubernetes, что снижает эксплуатационные риски control plane.
- Используется Managed PostgreSQL с PG Bouncer.
- Реализована централизованная система логирования (Loki).
- Используется GitLab CI и ArgoCD.
- Используются современные облачные сервисы Selectel.
Основные риски
- Backend регулярно завершается из-за нехватки памяти и, вероятно, утечки памяти.
- Для workload отсутствуют requests и limits, что делает невозможной корректную работу Cluster Autoscaler.
- При каждом запуске backend выполняются миграции базы данных, что создает риск аварий и конфликтов между репликами.
- Используются устаревшие версии Ingress NGINX, ArgoCD и Ruby с критическими уязвимостями безопасности.
- Kubernetes API опубликован через публичный IP.
- Публично доступен CloudBeaver с подключением к базе данных от имени пользователя root.
- Отсутствует Infrastructure as Code, что затрудняет сопровождение и восстановление инфраструктуры.
- Большинство сервисов не имеют отказоустойчивости и запускаются в одной реплике.
- Мониторинг присутствует, однако отсутствует полноценный алертинг и контроль деградации сервисов.
- Используются существенно избыточные системные диски узлов Kubernetes, что приводит к заметному перерасходу бюджета.
Итоговая оценка: критическая зрелость
Инфраструктура обладает современным технологическим фундаментом, однако эксплуатационная модель не соответствует требованиям промышленной эксплуатации.
Наиболее критичными являются:
- отсутствие управления ресурсами Kubernetes;
- ошибки в процессе запуска приложения;
- проблемы эксплуатации backend;
- устаревшие версии инфраструктурных компонентов;
- слабая защищенность административных интерфейсов;
- отсутствие Infrastructure as Code.
Рекомендация
Рекомендуется провести полный аудит инфраструктуры.
Приоритет работ целесообразно выстроить следующим образом:
- Устранение причин падения backend (requests/limits, анализ утечки памяти, изменение процесса запуска приложения).
- Закрытие критических уязвимостей безопасности и обновление инфраструктурных компонентов.
- Построение эксплуатационной модели: IaC, стандартизация CI/CD, мониторинг и алертинг.
- Повышение отказоустойчивости приложений и оптимизация инфраструктурных расходов.
Аудит Kubernetes-инфраструктуры сети ресторанов
Executive Summary
Итоговая оценка зрелости: критическая зрелость
Инфраструктура проекта построена на современном технологическом стеке (Managed Kubernetes, Managed PostgreSQL, S3, GitLab CI), однако уровень эксплуатационной зрелости существенно ниже необходимого для стабильной промышленной эксплуатации.
Наиболее существенные проблемы:
Паспорт инфраструктуры
Таблица зрелости:
Обозначение статусов:
🟢да / 🟡частично / 🔴 нет
Архитектура
🔴 Поддерживаемая версия Kubernetes
Влияние: Высокое
Используется Kubernetes 1.29, требующий обновления.
🟢 Отказоустойчивость Control Plane
Влияние: Среднее
Используется Managed Kubernetes.
🟢 Отказоустойчивость ETCD
Влияние: Среднее
Используется Managed PostgreSQL и Managed Kubernetes.
Автоматизация
🔴 Infrastructure as Code
Влияние: Очень высокое
Признаков Terraform или другого IaC не обнаружено.
🟡 Автоматическое обновление сертификатов
Влияние: Среднее
Предположение: управление сертификатами выполняет Managed Kubernetes, однако остальные компоненты обновляются вручную.
🔴 Единый способ установки компонентов
Влияние: Высокое
Компоненты устанавливались различными способами.
CI/CD
🟡 Шаблоны CI
Влияние: Среднее
CI существует, однако доступа для оценки качества не предоставлено.
🟡 Helm или аналог
Влияние: Среднее
Используются Helm-чарты для части компонентов.
🟡 GitOps
Влияние: Среднее
Используется ArgoCD, однако его конфигурация требует актуализации.
Мониторинг
🟢 Мониторинг Kubernetes
Влияние: Среднее
Grafana, Prometheus и Loki присутствуют.
🔴 Alertmanager
Влияние: Высокое
Канал Telegram настроен, рабочих алертов нет.
🟢 Сохранение метрик
Влияние: Низкое
Метрики сохраняются.
Наблюдаемость
🟢 Централизованные логи
Влияние: Среднее
Используется Loki.
🔴 Сбор событий Kubernetes
Влияние: Среднее
Данных о сборе Kubernetes Events нет.
Безопасность
🔴 NetworkPolicy
Влияние: Высокое
Сетевые политики отсутствуют.
🔴 Ограничение доступа к API
Влияние: Очень высокое
Kubernetes API опубликован в интернет.
🟡 Внутренние Registry
Влияние: Среднее
Используются внешние registry.
Отказоустойчивость
🔴 Минимум две реплики критичных сервисов
Влияние: Очень высокое
Web, Redis, Sidekiq работают в одной реплике.
🔴 Корректный Rolling Update
Влияние: Высокое
Обнаружены миграции БД при старте каждой реплики backend.
Эксплуатация
🟡 Резервное копирование
Влияние: Среднее
Используются Managed PostgreSQL и S3, стратегия резервного копирования приложений не подтверждена.
🔴 Проверенное восстановление
Влияние: Высокое
Информации о регулярных проверках восстановления нет.
Сильные стороны
Основные риски
Итоговая оценка: критическая зрелость
Инфраструктура обладает современным технологическим фундаментом, однако эксплуатационная модель не соответствует требованиям промышленной эксплуатации.
Наиболее критичными являются:
Рекомендация
Рекомендуется провести полный аудит инфраструктуры.
Приоритет работ целесообразно выстроить следующим образом:
Итоговая оценка зрелости: критическая зрелость
Инфраструктура проекта построена на современном технологическом стеке (Managed Kubernetes, Managed PostgreSQL, S3, GitLab CI), однако уровень эксплуатационной зрелости существенно ниже необходимого для стабильной промышленной эксплуатации.
Наиболее существенные проблемы:
- отсутствуют requests/limits практически у всех workload’ов;
- наблюдаются признаки утечки памяти backend;
- приложение регулярно перезапускается (десятки рестартов);
- отсутствует полноценный мониторинг и алертинг;
- используются устаревшие версии инфраструктурных компонентов с критическими CVE;
- отсутствует Infrastructure as Code;
- имеются публично доступные административные интерфейсы;
- значительная часть инфраструктуры настроена вручную.
Паспорт инфраструктуры
- Количество кластеров: 1
- Среда размещения: Selectel Cloud
- Kubernetes: Managed Kubernetes 1.29
- Основная ОС: Ubuntu 22.04 LTS
- Container Runtime: containerd
- CNI: Стандартный Managed Kubernetes
- Мониторинг: Prometheus + Grafana + Loki
- CI/CD: GitLab CI
- Git-хранилище: Внешний GitLab
- Основные технологии: Kubernetes, PostgreSQL 16, Redis, Ruby on Rails, ArgoCD, NGINX Ingress
Таблица зрелости:
Обозначение статусов:
🟢да / 🟡частично / 🔴 нет
Архитектура
🔴 Поддерживаемая версия Kubernetes
Влияние: Высокое
Используется Kubernetes 1.29, требующий обновления.
🟢 Отказоустойчивость Control Plane
Влияние: Среднее
Используется Managed Kubernetes.
🟢 Отказоустойчивость ETCD
Влияние: Среднее
Используется Managed PostgreSQL и Managed Kubernetes.
Автоматизация
🔴 Infrastructure as Code
Влияние: Очень высокое
Признаков Terraform или другого IaC не обнаружено.
🟡 Автоматическое обновление сертификатов
Влияние: Среднее
Предположение: управление сертификатами выполняет Managed Kubernetes, однако остальные компоненты обновляются вручную.
🔴 Единый способ установки компонентов
Влияние: Высокое
Компоненты устанавливались различными способами.
CI/CD
🟡 Шаблоны CI
Влияние: Среднее
CI существует, однако доступа для оценки качества не предоставлено.
🟡 Helm или аналог
Влияние: Среднее
Используются Helm-чарты для части компонентов.
🟡 GitOps
Влияние: Среднее
Используется ArgoCD, однако его конфигурация требует актуализации.
Мониторинг
🟢 Мониторинг Kubernetes
Влияние: Среднее
Grafana, Prometheus и Loki присутствуют.
🔴 Alertmanager
Влияние: Высокое
Канал Telegram настроен, рабочих алертов нет.
🟢 Сохранение метрик
Влияние: Низкое
Метрики сохраняются.
Наблюдаемость
🟢 Централизованные логи
Влияние: Среднее
Используется Loki.
🔴 Сбор событий Kubernetes
Влияние: Среднее
Данных о сборе Kubernetes Events нет.
Безопасность
🔴 NetworkPolicy
Влияние: Высокое
Сетевые политики отсутствуют.
🔴 Ограничение доступа к API
Влияние: Очень высокое
Kubernetes API опубликован в интернет.
🟡 Внутренние Registry
Влияние: Среднее
Используются внешние registry.
Отказоустойчивость
🔴 Минимум две реплики критичных сервисов
Влияние: Очень высокое
Web, Redis, Sidekiq работают в одной реплике.
🔴 Корректный Rolling Update
Влияние: Высокое
Обнаружены миграции БД при старте каждой реплики backend.
Эксплуатация
🟡 Резервное копирование
Влияние: Среднее
Используются Managed PostgreSQL и S3, стратегия резервного копирования приложений не подтверждена.
🔴 Проверенное восстановление
Влияние: Высокое
Информации о регулярных проверках восстановления нет.
Сильные стороны
- Используется Managed Kubernetes, что снижает эксплуатационные риски control plane.
- Используется Managed PostgreSQL с PG Bouncer.
- Реализована централизованная система логирования (Loki).
- Используется GitLab CI и ArgoCD.
- Используются современные облачные сервисы Selectel.
Основные риски
- Backend регулярно завершается из-за нехватки памяти и, вероятно, утечки памяти.
- Для workload отсутствуют requests и limits, что делает невозможной корректную работу Cluster Autoscaler.
- При каждом запуске backend выполняются миграции базы данных, что создает риск аварий и конфликтов между репликами.
- Используются устаревшие версии Ingress NGINX, ArgoCD и Ruby с критическими уязвимостями безопасности.
- Kubernetes API опубликован через публичный IP.
- Публично доступен CloudBeaver с подключением к базе данных от имени пользователя root.
- Отсутствует Infrastructure as Code, что затрудняет сопровождение и восстановление инфраструктуры.
- Большинство сервисов не имеют отказоустойчивости и запускаются в одной реплике.
- Мониторинг присутствует, однако отсутствует полноценный алертинг и контроль деградации сервисов.
- Используются существенно избыточные системные диски узлов Kubernetes, что приводит к заметному перерасходу бюджета.
Итоговая оценка: критическая зрелость
Инфраструктура обладает современным технологическим фундаментом, однако эксплуатационная модель не соответствует требованиям промышленной эксплуатации.
Наиболее критичными являются:
- отсутствие управления ресурсами Kubernetes;
- ошибки в процессе запуска приложения;
- проблемы эксплуатации backend;
- устаревшие версии инфраструктурных компонентов;
- слабая защищенность административных интерфейсов;
- отсутствие Infrastructure as Code.
Рекомендация
Рекомендуется провести полный аудит инфраструктуры.
Приоритет работ целесообразно выстроить следующим образом:
- Устранение причин падения backend (requests/limits, анализ утечки памяти, изменение процесса запуска приложения).
- Закрытие критических уязвимостей безопасности и обновление инфраструктурных компонентов.
- Построение эксплуатационной модели: IaC, стандартизация CI/CD, мониторинг и алертинг.
- Повышение отказоустойчивости приложений и оптимизация инфраструктурных расходов.
Какие доступы потребуются
Минимально необходимый набор зависит от проекта и договоренностей, но обычно это:
Доступ к серверу (SSH, возможно read-only, но тогда будьте готовы предоставлять инженерам конфигурации или доступы, которые недоступны с данным доступом)
Доступ к облачной панели
Доступ к административной панели управления (для CMS-проектов, например, Битрикс)
Доступ к репо с правами просмотр и чтение для проектов с CI/CD (GitLab CI, например)
Доступ к мониторингу (Grafana, Zabbix и тп)
Доступ к базе данных (достаточно read-only для анализа, могут затребоваться доп. доступы или конфигурации)
Работаем с 2007 года
Занимаемся созданием, настройкой, эксплуатацией и развитием IT-инфраструктуры проектов разного масштаба
Ведём подробную документацию
Фиксируем устройство инфраструктуры, выполненные работы и особенности эксплуатации. Используем открытые технологии и не привязываем проект к конкретному поставщику услуг
Вы общаетесь с инженерами напрямую
Специалисты, которые работают с вашей инфраструктурой, напрямую взаимодействуют с вами или вашей технической командой. Это сокращает количество промежуточных коммуникаций и помогает быстрее разбираться в задачах
30+
инженеров в штате
В команде есть специалисты с разными инфраструктурными компетенциями. К проекту можно подключать нужную экспертизу в зависимости от задачи
470+
клиентов
Работали с инфраструктурой компаний с разными технологиями, архитектурой и требованиями к эксплуатации
9 850+
настроенных серверов
Накопили практический опыт работы с большим количеством инфраструктурных конфигураций и сценариев
140+
проектов с Kubernetes
Разворачиваем и поддерживаем Kubernetes-кластеры. Решаем эксплуатационные задачи
Почему Southbridge
Проверить инфраструктуру бесплатно
Заполните форму и кратко расскажите о проекте. Мы свяжемся с вами, уточним детали и договоримся о проведении аудита
Не уверены, в каком состоянии инфраструктура?
Начните с бесплатного аудита. Инженеры проверят основные компоненты проекта, помогут обнаружить риски и дадут рекомендации по дальнейшим действиям
Отвечаем на ваши вопросы
Аудит можно проводить не только после аварий. Он помогает заранее обнаружить риски, оценить состояние инфраструктуры и понять, насколько она готова к росту нагрузки, запуску новых сервисов или дальнейшему развитию продукта.
Бесплатный аудит даёт первичную оценку состояния инфраструктуры и основных рисков. Углублённый аудит предполагает более детальную проверку отдельных компонентов и подробный технический отчёт.
Внешний аудит даёт независимую оценку текущего состояния инфраструктуры и доступ к дополнительным компетенциям. Это полезно, когда нужно проверить архитектурные решения, найти риски или получить дополнительное мнение перед важными изменениями.
Набор доступов зависит от инфраструктуры и задачи аудита. Это могут быть SSH, облачная панель, мониторинг, репозиторий и доступ к БД. Точный список согласовывается перед началом проверки.
Вы получаете список найденных проблем и рекомендации по дальнейшим действиям. После этого можно устранить их своей командой или передать необходимые доработки Southbridge.