Серверы и инфраструктура

Когда нас зовут

• Инфраструктура есть, но держится на одном человеке, и документации нет
• Нужно развернуть всё с нуля и непонятно, с чего начинать
• Выбираете между облаком и своими серверами и хотите понять разницу в деньгах
• Одна поломка кладёт весь сервис: запасного пути нет
• Кодовая база лежит у стороннего сервиса, и это перестало устраивать
• О сбоях узнаёте от клиентов, а не от мониторинга
• Нужно понять, насколько всё это безопасно, пока не случилось

Что входит в работу

• Поддержка готовой инфраструктуры: принимаем как есть, разбираемся и ведём дальше
• Развёртывание с нуля — в облаке или на своих серверах, по вашему решению
• Расчёт стоимости владения: сколько инфраструктура будет стоить в месяц при разных вариантах
• Голый Linux, Docker или Kubernetes — выбираем по задаче, а не по моде
• Отказоустойчивость: дублирование узлов, автоматическое переключение, проверка восстановления
• Защищённое хранение кодовой базы: свой git-сервер, разграничение доступов, резервные копии репозиториев
• Мониторинг двух уровней — состояние инфраструктуры и работа самого приложения
• Автоматизация выкатки: из ручной операции в повторяемую и обратимую
• Почта: SPF, DKIM, DMARC и разбор недоставок — самая частая тихая поломка
• Аудит инфраструктуры, включая безопасность: что открыто наружу, кто имеет доступ, где данные

Как идёт работа

1. 1 Разбор. Смотрим, что есть сейчас: что запущено, что открыто наружу, где хранятся данные и код. Часто первый осмотр находит то, о чём не подозревали.
2. 2 Варианты и деньги. Показываем два-три пути с расчётом ежемесячных затрат по каждому. Решение за вами, и оно принимается с цифрами на руках.
3. 3 Работы. Изменения по шагам, с резервными копиями и проверкой после каждого. Ничего не делается «одним большим переключением».
4. 4 Передача. Документация, доступы и порядок действий при аварии. Инфраструктура не должна держаться на одном человеке — включая нас.

Вопросы, которые задают чаще всего

Вы DevOps-инженеры

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

Облако или свои серверы — что выбрать

Это вопрос денег и требований, а не убеждений. Мы считаем стоимость владения по обоим вариантам с учётом роста нагрузки и показываем разницу в месяц. Часто выясняется, что на текущем объёме дешевле одно, а после роста — другое; тогда и планируем переезд заранее.

Нам нужен Kubernetes

Чаще всего нет. Если сервисов немного и нагрузка предсказуемая, Docker на обычном Linux-сервере проще и дешевле в сопровождении. Kubernetes оправдан, когда сервисов много, они масштабируются по-разному и команда готова его обслуживать. Мы умеем и так, и так, и скажем прямо, если он вам не нужен.

Что значит защищённое хранение кодовой базы

Свой git-сервер под вашим контролем вместо чужого сервиса: разграничение доступов по проектам, журнал действий, резервные копии репозиториев с проверкой восстановления. Код перестаёт зависеть от чужих правил и тарифов.

Как вы проверяете отказоустойчивость

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

Что входит в аудит безопасности

Что открыто наружу и почему, у кого есть доступ и как он выдаётся, где лежат персональные данные и не утекают ли они в логи, актуальны ли версии. По итогам — список находок с приоритетами: сначала то, что угрожает данным, потом удобство.

Мы на шаред-хостинге, вы с таким работаете

Да, и это отдельный навык: там нет root, часть утилит недоступна, а провайдер может молча поменять настройки. Разберёмся в имеющихся условиях и скажем, когда шаред перестанет вам подходить.