Мы провели исследование среди IT-компаний и выявили, что в 65% команд до 15 человек за инфраструктуру отвечают непрофильные специалисты, например, backend разработчики.
Проблемы с инфраструктурой решаются долго, разработка задерживается, а бизнес при этом теряет деньги.
Мы провели исследование среди IT-компаний и выявили, что в 65% команд до 15 человек за инфраструктуру отвечают непрофильные специалисты, например, backend разработчики.
Проблемы с инфраструктурой решаются долго, разработка задерживается, а бизнес при этом теряет деньги.
Знакомо? Давайте поговорим!
Оставить заявку
Часто в компании есть только один человек, который может поднять упавший сервер или починить сборку приложения.
И если вдруг этот человек окажется недоступен - бизнес потеряет деньги или перестанет работать на неопределенный срок.
Мы поможем
CI/CD
Возьмем инфраструктуру на себя
Приведем сборку кода к единому стандарту
Задокументируем проделанную работу и предоставим доступы к инфраструктуре
При необходимости передадим знания вашей команде и обучим пользоваться внедренными инструментами
Поздравляем! Теперь, даже если на тимлида или админа упадет метеорит (чего мы, конечно же, не желаем) - на ваш бизнес это никак не повлияет.
Воспользуйтесь DevOps практиками
Оставить заявку
Почему стоит работать именно с нами?
1
Создали и поддерживаем продукты для таких компаний, как X5, СБЕР, Mail.Ru, ПИК
2
Построили отказоустойчивую инфраструктуру для наших клиентов
3
Умеем настраивать окружения для любых команд разработки
4
Документируем каждое действие и осуществляем круглосуточную поддержку
Это не все, что мы умеем
Все услуги
Нам доверяют
Перед нами поставили задачи
Организовать frontend-часть сервиса так, чтобы была возможность подключать большое количество команд для разработки независимых компонентов системы
Возможность отдельного тестирования каждой задачи разработчика
Настроить автоматические релизы в инфраструктуру заказчика
Решения
Настроили интеграцию сторонних команд с помощью Webpack Module Federation и S3, настроили весь CI/CD для максимально быстрого подключения новой команды. Подробнее в нашей статье на Habr
Настроили создание динамических окружений (копий всего проекта) на отдельные задачи: разработчик пушит ветку со своей задачей -> раскладывается копия проекта, доступная по отдельному URL
Настроили автоматические релизы приложений в Openshift с помощью Gitlab CI/CD
Проблемы
Один dev-контур, на котором можно отдать задачу на тестирование – задачи нескольких разработчиков тормозят друг друга
Отсутствие мониторинга
отсутствие автоматических релизов, всегда приходится просить главного разработчика раскатить новую версию
Сервис стал подвергаться DDoS атакам и легко выходил из строя
Отсутствие бэкапов БД и риск полной потери данных при сбое
Решения
Настроили создание динамических окружений (копий всего проекта) на отдельные задачи: разработчик пушит ветку со своей задачей -> раскладывается копия проекта, доступная по отдельному URL
Настроили мониторинг потребления ресурсов, статусов ответов, состояния очереди и времени выполнения отложенных тасков с помощью Prometheus
Перевели все сервисы в Kubernetes и настроили автоматические релизы с помощью Gitlab CI/CD
Настроили защиту от DDoS атак с помощью Cloudflare
Настроили ежедневные бэкапы БД
Проблемы
Отсутствие бэкапов БД (Mongo и Postgres)
“Боевая” база данных переставала работать под нагрузкой прямых запросов от аналитика
Полное отсутствие мониторинга: узнавали обо всех проблемах слишком поздно
Разработчики тратили много времени на поиск серверных ошибок
Отсутствие автоматических релизов
Решения
Настроили бэкапы
Сделали кластеры основных БД: Mongo и Postgres
Настроили мониторинг с помощью Prometheus
Внедрили стек ELK для сбора логов
Настроили автоматические релизы с помощью Gitlab CI/CD
Проблемы
Процесс релизов новых версий жестко завязан на одного разработчика и его приходилось ждать
прогон тестов был только на совести разработчика, автоматически они не запускались. Несмотря на то, что писались автотесты, - ошибки часто попадали в релиз
Приходилось тратить много времени на то, чтобы просмотреть логи с разных машин и найти ошибку
не было полноценного мониторинга: сообщения об ошибках получали уже от пользователей
Решения
Любой заинтересованный участник команды может сделать релиз, не тратя время на ожидание: мы перевели все сервисы в managed Kubernetes и настроили автоматические релизы с помощью Gitlab CI/CD
Стало технически невозможно сделать релиз с ошибками в тестах
Все логи - в одном месте: настроили единое хранилище логов - Loki, интерфейс - Grafana
настроили мониторинг различных метрик приложения с помощью Prometheus: статусы ответов, состояние бд и добавили отправку уведомлений при аномальных метриках