Оставьте заявку
Свяжемся с вами в течение рабочего дня
Подключение в рабочие дни с 10:00 до 19:00 мск
Не ждём договоров и предоплаты в критической ситуации
Когда вы можете обратиться
Инцидент в инфраструктуре
Инфраструктура полностью или частично недоступна: перестал работать сайт или сервис, возникли проблемы с базой данных, кластером, облачным провайдером или произошёл другой критический сбой.
DDoS-атака
На компанию идёт DDoS-атака, и требуется помощь с подключением защиты, анализом ситуации и восстановлением стабильной работы.
Другая атака или подозрение на взлом
Компания столкнулась с атакой или подозревает компрометацию инфраструктуры и не понимает дальнейший порядок действий
Оставить заявку на срочную помощь
Свяжемся с вами в течении часа в рабочее время с 10−19 мск.
Когда подойдет услуга
Если в штате нет собственной команды
Если внутренней экспертизы недостаточно для решения проблемы
Если нужны внешний взгляд и дополнительные ресурсы во время аварии
Если простой сервисов напрямую влияет на выручку и бизнес-процессы
Кейсы
3/ Восстановили кластер Rancher после истечения сертификатов Kubernetes
Клиент обратился с неработающим кластером Rancher. Мы нашли причину — истекшие сертификаты Kubernetes — и полностью восстановили работоспособность кластера и проектов.
Время работ — 4 часа
1/ Восстановили работу сайта после сбоя базы данных
Сайт перестал работать, причины были неизвестны. Мы подключились к расследованию, нашли проблему в базе данных и восстановили работу сервиса.
Время работ — 10 часов
4/ Запустили приложение после неудачного внедрения
Клиент обратился с приложением в Google App Engine, которое не удалось запустить. Мы подключились к задаче, провели полную диагностику и нашли сразу несколько причин, которые мешали его работе. Исправили ошибки конфигурации и инфраструктуры, устранили проблему безопасности и довели приложение до рабочего состояния.
Время работ — 4 часа
2/ Провели аудит PostgreSQL и нашли причины ошибок под нагрузкой
Во время пиковых нагрузок сайт выдавал ошибки 5xx. Провели аудит производительности PostgreSQL, выявили узкие места и подготовили рекомендации, которые позволили снизить нагрузку на сервер и повысить стабильность работы.
Время работ — 14 часов
Кейс № 2 — провели аудит PostgreSQL и нашли причины ошибок под нагрузкой
Клиент обратился с запросом на аудит и тюнинг производительности базы данных PostgreSQL, так как сайт выдавал ошибки 5xx при пиковой нагрузке. Цель аудита сместилась в сторону общего анализа производительности, проверки настроек базы данных под текущую нагрузку и поиска узких мест, которые могут вызывать проблемы в будущем.
Со стороны DBA были проведены работы по следующему плану:
Время работ: 14 часов.
Со стороны DBA были проведены работы по следующему плану:
- Получить доступ к логам и найти проблемные места.
- Сопоставить временные интервалы логов и графиков, чтобы понять, какие события происходили в базе данных в этот момент.
- Проверить конфигурационные параметры и подготовить рекомендации по их настройке.
- Собрать информацию из pg_stat_statements.
- Проанализировать pg_stat_activity и графики, чтобы определить причину проблемы.
- Подготовить список рекомендаций.
Время работ: 14 часов.
Кейс № 4 — провели аудит PostgreSQL и нашли причины ошибок под нагрузкой
После завершения работ предыдущего подрядчика приложение так и не удалось запустить. Клиент обратился к нам, чтобы разобраться в причинах и довести внедрение до рабочего результата.
Во время диагностики были выявлены и устранены несколько независимых проблем.
Время работ: 4 часа.
Во время диагностики были выявлены и устранены несколько независимых проблем.
- Приложение прослушивало порт 3001, тогда как Google App Engine направляет запросы только на порт 8080.
- Была найдена и настроена передача переменных окружения в контейнер.
- Сборка в облаке занимала около 15 минут, а деплой — еще 5−8 минут, поэтому каждая проверка требовала времени.
- После первой попытки запуска в приложение были добавлены новые функции, из-за чего появилась зависимость от FireBase.
- Для работы FireBase требовался файл с учетными данными. Клиент случайно разместил его в публичном репозитории GitHub, из-за чего получил уведомление от Google о потенциальной угрозе безопасности.
- В итоге выяснилось, что FireBase использовался только для коротких ссылок, поэтому зависимость была полностью удалена.
- Затем приложению потребовался Redis для кэширования. Была настроена передача параметров через переменные окружения и подключен Serverless VPC Access Connector для связи приложения с Redis.
Время работ: 4 часа.
Как мы работаем
Начинаем работу сразу
В критической ситуации начинаем работу сразу, без ожидания договора, оплаты и других формальностей. Документы оформляем параллельно с устранением инцидента.
Анализируем инцидент и подключаем специалистов
Мы быстро включаемся в работу, анализируем причины инцидента и привлекаем специалистов с необходимой экспертизой. Наша задача — как можно быстрее восстановить работу системы.
Что мы можем гарантировать
Мы гарантируем:
- оперативное подключение к инциденту
- вовлечение опытных инженеров
- максимальные усилия для поиска и устранения проблемы
Время приёма обращений
Мы принимаем обращения по рабочим дням с 10−19 мск. Если инцидент произошёл вечером, ночью или в выходной день — всё равно напишите нам. Мы не можем гарантировать подключение вне рабочего времени, но, если будет возможность, постараемся помочь.
Важно понимать: заранее невозможно знать причины аварии и её масштаб. Как и в медицине, без диагностики невозможно назначить лечение. Поэтому Д О анализа системы мы не можем гарантировать конкретный результат или сроки устранения инцидента. Однако у нас есть опыт решения сложных технических проблем, с которыми не смогли справиться внутренние команды клиентов.